Benefit of microservice architecture is that it breaks big problems into smaller ones, and those pieces of code can be shipped separately. If anything goes wrong, the impact of that also becomes smaller, which means the whole system doesn't have to bear the downtime. Another thing that matters is the batch size, that is, how fast we are releasing a microservice. It could be 1 month, 2 months, 6 months, and so on. In traditional ways, the release process is not done often. Because of this, developers are less well versed in releasing, which leads to more mistakes. There are many manual steps, such as shutdown, setup/update infrastructure, deployment, restart, and manual tests. The more the number of manual steps, more are the chances of mistakes. The whole release process is more laborious, cumbersome, and time consuming.

If the release is happening after a very long time, then it is likely that something will go wrong among the different components together, such as version conflicts, incompatible components, and so on. However, it is hard to see what change is causing the problem, because there have been a lot of changes. The point is that those problems are discovered too late. We get feedback too late, because we are not relearning regularly.

On the other hand, a vendor like Amazon releases once in a week or some others multiple times in day. So, how frequently we are releasing, impacts the downtime and also reduces the maintenance windows. To maintain the balance between maintenance window and batch size, we have to work on zero downtime.

This chapter covers the following topics:

• Continuous integration
• Continuous delivery
• Configuring tools for CI and CD with our microservices
• Dockerizing our microservices
• Using open source CI tools with our Dockerized microservices