Independent Deployments

With a large monolithic application, fast reliable deployments can be problematic. When updating a feature or fixing a bug in a monolithic application, we typically need to build and deploy the entire application. Even the smallest change to a library or component will require a redeployment of the entire application, including all those other components that have not changed. Depending on the size, technologies, and processes used, building and deploying an update can take a significant amount of time. In some situations it can take many hours to push out a new build for even small changes or bug fixes. Not only is our update potentially held up by other changes that need to be deployed with it, those other changes may cause deployment failures and require a rollback of the deployment. If we could decouple changes to one feature of the application from others, these problems could be avoided.

As a monolithic application grows, so does the fear of making changes, and as a result, all development slows down. Businesses and IT departments avoid touching large monolithic applications due to the increased risk of failure and long roll-back processes. This results in a stalemate situation where an update is required but is not implemented due to the perceived risks. By decoupling changes to one component of the application from other components, only the parts that changed need to be released.

In a microservices-based architecture, each microservice is built and deployed independently of the other services, provided we are able to maintain loose coupling between the services. This means that we can deploy a critical bug fix to our payment processing component (or microservice) completely independently of other changes needed by the catalog service. If the changes to the catalog need to be rolled back, they can be rolled back while our payment processing bug fix remains in production. This makes it possible for large applications to remain agile, and to deploy updates more quickly and more often. A microservices design removes the coordination overhead, as well as the fear factor of making changes. Quite often change advisory boards are no longer needed and changes happen far more quickly and efficiently.

Not only do the smaller services enable these separate deployments and updates, given that we only have to build a small part of the application, build times can be much faster. Depending on the size of the application, this can be significant, even with parallel builds and tests.