At first continuous integration, microservices and containers seem to be isolated topics. Also with DevOps implementation, it’s also not a hard fast rule that CI is only possible if you use microservices or to run micro-services you need to implement container technology. All things can work independently. But in case if you bring these three gems of DevOps toolchain together, new doors of hope and software delivery methods come into light.
With the combination of microservices and containers, we can remove several of the problems that use to exist earlier when working on microservices. Also the concept of immutable deployments helps us further to work easily with microservices.
This implementation allows us to fast test and develop a product which helps us to improve our CI and CD pipelines.
Difference between Continuous Integration, continuous delivery, and continuous deployment.
Continuous Integration: Continuous integration (CI) usually refers to integrating, building, and testing code within the development environment. Whenever developer is developing the code he is required to commit his code back to the shared repository frequently and how frequently? That depends on the project requirement. As soon the code is committed back to the shared repository, it is tested that this new piece of code is not breaking the existing software. Usually, this is done by automated test suits which run on the new piece of code and validate that it’s not breaking anything in the existing build. We create automated ways of testing this new code and its integration with existing and usually call these all steps together as integration pipelines.
On running the pipeline, either your build is going to pass or fail, in case it fails you need to work on your changes and start all over again. This pipeline should run at every commit or push to the repository.
Even if continuous integration pipeline is a success but still you cannot be sure on the production readiness of the build. All that you din in CI pipeline is that you verified that current changes are not breaking the existing test cases and running code is good but still there can be many more things that need to be addressed before you can push your changes to the production.
Below are some steps which shall be there as a part of CI
- Pushing code to repository
- Static code analysis
- Pre-deployment testing(Unit tests, Functional tests)
- Packaging and deployment to the test environment
- Post-deployment testing.(Functional, integration and performance tests)
Integration tests shall always be committed along with the code that is being implemented. To ensure that this happens, you can switch to a development strategy called as TDD (test driven development)
Continuous delivery: The continuous delivery pipeline is in most cases the same as the one we would use for CI. The major difference is in the confidence we have in the process and lack of actions to be taken after the execution of the pipeline. While CI assumes that there are (mostly manual) validations to be performed afterward, successful implementation of the CD pipeline results in packages or artifacts being ready to be deployed to production.
In Simple terms, we can say that each build that passed the continuous delivery phase can be deployed to the production but to actually deploy the same to the production environment can be a political decision.
Continuous deployment: Continuous deployment moves one step ahead and automatically deploys the package to the production environment without manual intervention. All builds that have passed the verification are deployed into the production environment.
Microservices: For any feature introduces the meantime to release for the same into production shall be minimum may be from a day to few days to weeks. The smaller the meantime to release the more benefit an organization will get and will always be ahead of its competitors in the delivery of new features into the market.
Speed can be accomplished through multiple ways. For example, we want the pipeline to be as fast as possible both in order to provide quick feedback in case of a failure as to liberate resources for other queued jobs. We should aim at spending minutes instead of hours from checking out the code to having it deployed to production. Microservices can help accomplishing this timing. Running the whole pipeline for a huge monolithic application is often slow. Same applies to testing, packaging, and deployment. On the other hand, micro-services are much faster for the simple reason that they are much smaller. Less code to test, less code to package and less code to deploy.
Containers: Before the onset of container technology it was really difficult to work with microservices, It was always an easy way to work with the monolithic application as after setting some standards you had to build only a single package and run the same. Working with few micro-services was also an easy option but when the number of micro-services rises to multiple of 10, it becomes difficult to manage microservices.
They might use different versions of dependencies, different frameworks, various application servers, and so on. The number of stuff we have to think about starts rising exponentially. After all, one of the reasons behind microservices is the ability to choose the best tool for the job.
With container technology like that of Docker which you can spin up quickly and can quickly build up environments for your app in a fraction of minutes. Inside the same, you can run your services also. The way containers accomplish this type of a feat is through self-sufficiency and immutability.
Adding some orchestration tool along with containers really make working with microservices really simple and fast as compared to monolithic applications
Conclusion: Continuous deployment, micro-services, and containers each are great tools and used together they open up new doors of possibilities.
With continuous deployment, we can provide continuous and automatic feedback of our applications readiness and deployment to production thus increasing the quality of what we deliver and decreasing the time to market.
Microservices provide us with more freedom to make better decisions, faster development and, as we’ll see very soon, easier scaling of our services.
Finally, containers provide the solution to many of deployment problems; in general and especially when working with microservices. They also increase reliability due to their immutability.