Download as PDF, PPTX
Uploaded bySequoia Capital
Better Software—Faster: Ten Best Practices from Sequoia's Microservices Summit
The document provides 10 best practices for implementing microservices based on insights from a Microservices Summit. It recommends: 1) Determining if an application truly needs to be broken into microservices; 2) Focusing on continuous delivery and automation before microservices; 3) Appointing a small team to guide architectural decisions and standard adoption. It also recommends 4) Aligning services to business processes, 5) Starting with a monolith and decomposing incrementally, 6) Moving pieces incrementally without replacing the monolith, 7) Creating a shared service repository, 8) Applying comprehensive monitoring, 9) Improving security and governance for more surfaces/complexity, and 10) Potential rewards of microservices include increased speed, agility
In this document
Powered by AI
Introduction to best practices from Sequoia’s Microservices Summit with notable participants listed.
Evaluate if microservices are needed based on complexity and team size; too many microservices can hamper productivity.
Highlight the importance of continuous delivery and automation ahead of adopting microservices.
Advocate for a dedicated team to manage architectural decisions and maintain standards in microservices.
Emphasize using bounded contexts and aligning microservices with business processes for efficient operations.
Discussion on starting new products as monoliths before gradually breaking them into microservices.
Take a gradual approach to break down monoliths into microservices to prevent loss of functionality.
Recommendation to create a shared repository for all services to enable better application development.
Need for comprehensive monitoring in microservices due to increased complexity and fragmented tools.
Address the enhanced complexity of microservices that heightens the necessity for security and governance.
Successful microservices adoption leads to faster development cycles and significant cost reductions.
Information on additional resources for understanding microservices and accessing ecosystem maps.
More Related Content
Similar to Better Software—Faster: Ten Best Practices from Sequoia's Microservices Summit
Better Software—Faster: Ten Best Practices from Sequoia's Microservices Summit
- 1. TEN BEST PRACTICES Sequoia’sMicroservices Summit Takeaways MATT MILLER | @MCMILLER00
- 3. Microservices Summit 2016 AMGEN APCERA CAA CITI COMMONWEALTH B ANK OF AUSTR ALIA CONFLUENT CR ATE IO CUMULUS DATAWIR E D ISNEY D OCKER D R OPBOX ED MUNDS EVENTBRITE EX-AMAZON EX- G OOGLE EX- G ILT G OLD MAN SACHS HP IB M INSTACART K ISMATIC LINK EDIN MEDALLIA METASWITCH MICR OSOFT MINIO MONG ODB MOR G AN STANLEY NASDAQ NG NIX OK TA PAYPAL QUALCOMM R ED LOCK SALESFORCE SAR ATOGA SPEED SHIPPABLE SPR INGPATH SQUARE STACK ROX SYSD IG TALK DESK THOUG HTWORKS TWITTER VER IZON VMWARE WELLS FAR GO
- 4. Determine if youreally need microservices INSIGHT 1 Not every application is complicated enough to warrant being brokeninto microservices. Martin Fowlerand Ryan Murray from Thoughtworks cite a “microservice premium” where in many use cases the complexity of microservices hampers the productivity of your team. There comes a point when your application becomes very complex or your team begins to grow past 50-75 engineers that the benefits of this architecture begin to take off.
- 5. Put your housein order INSIGHT 2 Continuous delivery and automation are more important than microservices. Smallagile teams who canintegrate their work frequently, at least daily, are an important precursor to microservices. Being able to automate your systems and push code updates regularly are critical to dealwith the complexity you will incur with this architecture.
- 6. Appoint a masterartisan INSIGHT 3 If youdo not design and manageyour evolution to microservices the result can be an uncontrollable sprawl. It is critical to have a person or a smallteam responsible for controlling architectural decisions and helping to ensure standards adoption. Google has a small team of artisans who understand how pieces fit together and help guide the creation of newservices. Alex Roetterfrom Twitterrefers to this oversight as “applying the right amount of salt” You never want to overpower the great innovation that is coming from the bottom up.
- 7. INSIGHT 4 Teams shouldhave bounded context and systems should follow the ordinary flow of business. Melvin Conway first came up with this principle in 1967 and it holds true today. Whenyour services are notdirectly mapped,it makestroubleshooting or re-architecting in the future far more difficult. Microservices should map to business processes Organizations which design systems…are constrained toproduce designs which are copies of thecommunication structures ofthese organizations. Melvin G. Conway – 1967
- 8. Start every newproduct as a monolith INSIGHT 5 It is impossible to know the best wayto divide up a monolith until you can observe its usage.Once you have a sensefor how your product will be used you can decompose from there. Today there is a bit of trial and error on sizing your services. There may be an opportunity for someone to help with this process through software in the future.
- 9. Move incrementally INSIGHT 6 Don’tthrow away the monolith. This canhave disastrous results. Takeone piece ata time and break it off. Once the piece is working, move to the nextnatural piece. A few companies havefounda moreaggressive approach can lead to lost functionality andmake diagnosingissuesdifficult.
- 10. Create a sharedrepository INSIGHT 7 Consider creating one large shared repository of all services for teams to use in application development. You don’twantto have two or three active versions of a common service in use. Your artisan(s) should help in managingthis repository.
- 11. Apply more comprehensivemonitoring INSIGHT 8 More pieces to managetelemetry very important. The microservices monitoring landscape is very fragmented. There is not a clear winnerand some companies are building their own products. Microservices require a muchmore comprehensive monitoring effort than you have had with your monolith.
- 12. Improve security andgovernance INSIGHT 9 More surfaces and complexity increase the needfor security andgovernance. Consider how you will authenticate who can speak to whom and identify illegitimate traffic. Who has the authority to work on certain services? Canall services be used for all tasks in your company? How are shared services billed or managed?
- 13. Reap the rewards INSIGHT10 When successfully implemented,microservices delivers huge increases in the speed and agility in which companies can build and deploy software. The cost required to deliver an application is muchless and your systems will become more resilient. Developmenttime can gofrom months to weeks. Companies like Airbnb, Disney,Dropbox,GE, Goldman Sachs, and Twitterhave seen development lead times cut by as much as 75%when using microservices.
- 14. FOR MORE ONMICROSERVICES AND OUR LATEST MICROSERVICES ECOSYSTEM MAP VISIT: seq.vc/microservices