By Anton Smit
If you were to walk up to five different colleagues and ask them to describe DevOps, you would get five different answers. Implementing CI/CD pipelines, an engineer using the correct tools for automated testing and deployment to some form of automated cloud deployments. These are correct however they convey the depth that the word DevOps has and how it has become a key sector in the IT industry today.
Taken from redhat.com, Devops is an approach to culture, automation, and platform design intended to deliver increased business value and responsiveness through rapid, high-quality service delivery. In other worlds, the entire process from Application Design, testing, building and deploying is entirely streamlined to ensure that Developers can continue what they are doing while ensuring minimal downtime.
This can be explained further in an example. Your Development Team has a React Application that continuously needs updates applied to it. They assure you that their code is bug free, and “pushing it to production” is not an issue. Your Operations team needs some form of surety that the production environment will be as fault tolerant as possible. A possible solution for this would be to ensure that systems, integration and unit tests are written for the application and checked before implementing into production. This can then be achieved using some popular CI tools such as Jenkins or Travis CI (The latter which is extremely intuitive to use). Once things start coming together, how do you decide to deploy to production with as minimal downtime as possible, or none at all? This is where you can make or break your CI/CD workflow.
One possibility is by leveraging a Canary deployment. This process moves a small subset of users / traffic to your canary (which in our case is the QA deployment with the updated code). Leveraging this method will assist with ironing out issues early on and potentially saving your Company from possible downtime or disruption in production. If your entire pipeline involves working with Microservices, then leveraging a Kubernetes Cluster for this would be ideal. From a high level you could essentially steer 10% of traffic to your canary pods, and 90% to your production pods. When a company deems it safe to continue, you can increase the number of canary pods to eventually become the new Production environment.
The Blue-Green Deployment is an alternative strategy that can be used, while still utilising microservices, if Kubernetes cannot not be leveraged.
This essentially means that you will always have two production instances running. Users’ traffic however will only be steered to the Green Deployment allowing your Development team to perform updates to the Blue deployment without affecting production. This allows for reduced downtime, as once all tests have been done on the Blue deployment, production traffic may be instantly shifted. One downside to this is keeping databases synced across the deployments.
In conclusion having a DevOps mindset is not only about how fast and efficiently you are able to have updates rolled out to production. It is also ensuring that in the process of performing this delivery you are certain that your production environment has the highest uptime achievable as well as being fault tolerant so that minimal subscriber impact is achieved.