September 11th, 2015
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
The term “microservices” only goes back to 2013. I would have trouble saying why I love the style so much, except that I hated dealing with Ruby On Rails and the PHP framework known as Symfony. I was willing to deal with a lot to get away from the pain of those systems. The growth of great package managers also seemed to weaken the need for monoliths.
The trade-offs between modular boundaries and the complexities of distributed systems have been around for my whole career in this business. But one thing that’s changed noticeably, just in the last decade, is the role of releasing to production. In the twentieth century production releases were almost universally a painful and rare event, with day/night weekend shifts to get some awkward piece of software to where it could do something useful. But these days, skillful teams release frequently to production, many organizations practicing Continuous Delivery, allowing them to do production releases many times a day.
“Microservices are the first post DevOps revolution architecture” — Neal Ford
This shift has had a profound effect on the software industry, and it is deeply intertwined with the microservice movement. Several microservice efforts were triggered by the difficulty of deploying large monoliths, where a small change in part of the monolith could cause the whole deployment to fail. A key principle of microservices is that services are components and thus are independently deployable. So now when you make a change, you only have to test and deploy a small service. If you mess it up, you won’t bring down the entire system. After all, due the need to design for failure, even a complete failure of your component shouldn’t stop other parts of the system from working, albeit with some form of graceful degradation.
This relationship is a two-way street. With many microservices needing to deploy frequently, it’s essential you have your deployment act together. That’s why rapid application deployment and rapid provisioning of infrastructure are Microservice Prerequisites. For anything beyond the basics, you need to be doing continuous delivery.
The great benefit of continuous delivery is the reduction in cycle-time between an idea and running software. Organizations that do this can respond quickly to market changes, and introduce new features faster than their competition.
Although many people cite continuous delivery as a reason to use microservices, it’s essential to mention that even large monoliths can be delivered continuously too. Facebook and Etsy are the two best known cases. There are also plenty of cases where attempted microservices architectures fail at independent deployment, where multiple services need their releases to be carefully coordinated . While I do hear plenty of people arguing that it’s much easier to do continuous delivery with microservices, I’m less convinced of this than their practical importance for modularity – although naturally modularity does correlate strongly with delivery speed.