Matt Miller
If we trace a path that starts with Gutenberg’s use of moveable type to Malcom McLean’s invention of the shipping container, we start to recognize a very interesting pattern: Each new layer of abstraction and standardization creates tremendous value out of the resulting increases in scale and efficiency.
Today’s digital innovators can trace a similar historical path that starts with mainframe computers and monolithic applications and then, step-by-step, reveals software’s interchangeable parts until we arrive at today’s cloud-based era of microservices and continuous integration.
Microservices is an approach to building software that shifts away from large monolithic applications toward small, loosely coupled and composable autonomous pieces. The benefit of this abstraction is specialization, which drives down costs to develop and drives up agility and quality — while operating much more resilient systems.
This approach is not new; Amazon and Google have been using it for more than a decade. Container technologies (like Docker), APIs and the availability of cloud infrastructure have made microservices something that is now practical for a much broader set of companies.
Companies like Airbnb, Disney, Dropbox, GE, Goldman Sachs and Twitter have seen development lead times cut by as much as 75 percent when using microservices. The concept sounds simple enough, but doing it is harder than it looks. This has given rise to a whole new ecosystem of companies and open-source software to help people with this transition.
Sixty engineering leaders gathered recently at Sequoia’s Microservices Summit to share stories about what it took to implement microservices at companies like Google, Amazon, Microsoft, Twitter, Netflix, Disney, Wells Fargo, Dropbox, Amgen, Citi, Nasdaq, Medallia, HP, Okta, Gilt, Instacart and many others.
Here are the 10 best practices for building and deploying microservices.
Determine if you really need microservices
Not every application is complicated enough to warrant being broken into microservices. Martin Fowler and 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.
Put your house in order
Continuous delivery and automation are more important than microservices. Small, agile teams who can integrate 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 deal with the complexity you will incur with this architecture.
Appoint a master artisan
If you do not design and manage your evolution to microservices, the result can be an uncontrollable sprawl. It is critical to have a person or a small team responsible for controlling architectural decisions and helping to ensure standards adoption.
Google has a small team of master artisans who understand how pieces fit together and help guide the creation of new services. Twitter’s Alex Roetter refers 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.
Map your microservices to business processes
Teams should have 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. When your services are not directly mapped, it makes troubleshooting or re-architecting in the future far more difficult.
Start every new product as a monolith
It is impossible to know the best way to divide the monolith until you can observe its usage. Once you have a sense for 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 in the future for someone to help with this process through software.
Move incrementally
Don’t throw away the monolith. This can have disastrous results. Take one piece at a time and break it off. Once that piece is working, move to the next natural piece. A few companies have found a more aggressive approach can lead to lost functionality and can make diagnosing issues difficult.
Create a shared repository
Consider creating one large shared repository of all services for teams to use in application development. You don’t want to have two or three active versions of a common service in use. Your artisan(s) should help in managing this repository.
Apply more comprehensive monitoring
More pieces to manage make telemetry very important. The microservices monitoring landscape is very fragmented. There is not a clear winner, and some companies are building their own products. Microservices require a much more comprehensive monitoring effort than you have had with your monolith.
Improve security and governance
More surfaces and complexity increase the need for security and governance. Consider how you will authenticate who can speak to whom and identify illegitimate traffic. Who has the authority to work on certain services? Can all services be used for all tasks in your company? How are shared services billed or managed?
Reap the rewards
When successfully implemented, microservices deliver huge increases in the speed and agility in which companies can build and deploy software. The cost to deliver an application is much less, and your systems will become more resilient. Development time can go from months to weeks.
If this sounds daunting, consider the alternative: longer development cycles, more brittle infrastructure and slower innovation than your competitors. Microservices are not for everyone, but — if implemented effectively — the results can be transformational in the creation of enduring companies.
Comment