Dos and Don’ts for DevOps in a Microservices project

Moving traditional and manual processes to automated ones is a necessary thing to do for the modernization of systems. However, doing so may require a lot of rework and it may also lead to delays. That’s one of the reasons why DevOps makes the use of CI/CD practices compulsory, and focuses on automation. The main result is a streamlined pipeline and delivery.

Manual processes in legacy systems are tedious and time-consuming. Moreover, it is difficult for different teams to efficiently coordinate work using legacy systems. For that difficulty, DevOps establishes an easy and self-governing tool chain that simplifies the development and operation environment. This tool plays a major role in the modernization process. It helps developers to build, test and deploy repeatedly using automation and integration.

If you are working in a Microservices project, here is a list of things to seek, and things to avoid if you want to aim for success:

DO:

1. Containerize your microservices. Containers and microservices often go hand-in-hand. With containerized microservices, you can deploy and manage individual services independently, without affecting services hosted on other containers. Containers also offer platform-independence and interoperability that blend exactly with the goals of microservice architecture. You will be able to avoid monolithic common issues, mainly its reliability.

2. Have a separate build for each microservice and automate the deployment process. An essential aspect to accomplish the DevOps model is to enhance efficiency by enabling automation. With automation tools like Jenkins, you can automate DevOps workflows by facilitating Continuous Integration and Continuous Delivery (CI/CD).

Monolithic applications require a full restart to roll out updates but microservices lead to a lesser downtime and support an early release with high availability support.

3. Eliminate any practices where source code is built multiple times. Even if the software has to be built, packaged, or bundled, you should execute that step only once and promote your binaries. Most successful CI implementations include the build process as the first step in the CI/CD cycle to package the software in a clean environment. This eliminates oversights and reduces the chance for errors to be introduced and/or missed anytime later. Further, the resulting artifact should be versioned and uploaded to the artifactory server each time so that whenever it is pulled the build does not change and can be used in every stage of your workflows and environments.

4. Run tests in containers. This approach allows the quality assurance team to reduce the number of environment variables and changes present between the development and production environments. The primary advantage of using such ephemeral testing environments is that they add agility to your CI/CD cycle. The QA team does not have to pull a build from an artifactory server and run it in a separate testing environment; instead, it can run tests against a container image inside CI/CD pipeline. It is much easier to spin up containers (they have no separate installation or configuration requirement) and also destroy them when not needed.

5. (Run microservices in isolated infra) Deploy your microservices separately. Doing so helps save time while coordinating with multiple teams during regular maintenance or upgrade efforts. You also do not want a single service to use an unfair amount of resources while impacting other services, just because they’re sharing resources. The recommendation is to use a dedicated infrastructure to host each microservice. Doing this isolates each microservice from faults in other components, thus helping in fault tolerance and avoiding a full-blown outage.

6. Release software in a release-ready state. More often releases are possible if the software is in a release-ready state, after you have tested it in a production-like environment. The best practice here is to add a deployment stage, which closely resembles the production environment before the release. Some release best practices include:

• Canary deployment. Releasing to a group of users, test results, check metrics and rolling out to the wider population if successful (or roll it back if it’s not and iterate).
• Blue-Green deployment. Start with two identical production environments. One is live in production and the other is idle. With a new release roll out the changes are deployed to the idle environment. Then switch environments, containing the new release one becomes the live environment. If something goes wrong, roll back to the other environment (the one with the previous release version). If all is well, the environments are paired for future releases.
• A/B Testing. A/B testing is similar in flavor to Blue/Green deployments, but A/B testing is a way of testing features within the application for things like usability. The better performing variant of the feature wins. This is not a release methodology.

7. Implement automated cleanup and rollback procedures. Do it directly into the CI/CD pipeline to ensure no longer used resources are cleared as soon as their purpose is complete, preventing those resources from becoming abandoned. Saving resources and money is what you aim at once everything is done.

8. Keep an eye on your services. Once deployed, check and recheck everything is working fine and as expected. Best practice is to collect metrics of your services and compare them with previous releases. Errors, response timing and any other indicator must be considered as reflection of your work.

DON’T:

1. Don’t make your developers create and maintain plumbing work to keep pipelines together. Expecting developers to write and manage endless ad-hoc scripts takes them away from doing what they’re good at — innovating. Cloud and microservices will only make pipelines more difficult to maintain. The time is right to look at tools built for automating and managing end-to-end delivery.

2. Don’t think that your current tools will “just work” in the cloud. Not getting the people and tools you need to make DevOps work in the cloud will likely lead to failure. Leveraging vendor expertise where it’s available can expedite cloud adoption and minimize some of the technology hurdles.

3. Don’t create complex pipelines. If you create it with complex dependencies, you won’t be able to avoid hard readiness. Pipelines should be as easy to read and maintain as possible. Everyone should read and understand the complete workflow/pipeline.

4. Don’t believe that cloud providers have all the services and tools you need. It’s not a good idea to lock yourself into a single cloud platform. Your applications should be deployable on multiple clouds. A well-designed software development process is cloud-agnostic.

CONCLUSION:

This article is a first approach to help you get a better understanding of what you should do and what you should avoid when creating pipelines for your microservices applying best practices.

There is no right or wrong answer when discussing the creation of a perfect pipeline. You will need to spend some time by applying Do’s and Don’ts for DevOps in Microservices before you succeed, after applying and refactoring several times your code by different approaches.

Roberto Crisial — Principal DevOps Engineer @ Spark Digital