In recent years a new age of development tools and practices have emerged: DevOps and Cloud Native became the king and queen of our industry, starring in every discussion, article and conference. This wave of innovation is without a doubt a welcome advancement to the once dull world of infrastructure IT and Operations, but how far exactly are we in the course to the Cloud Native Devops dream, and what's ahead of us?
Continuous Integration and Continuous Deployment (or Delivery), a.k.a CI/CD, had brought us significantly closer to the Cloud Native DevOps vision. CI/CD tools are already helping many organizations to build, package, and ship software in an automated manner. But at the root of every CI/CD tool lies an established fallacy: the concepts of *Deploy* and *Release* are being conflated into a single phase. So "Shipping" code to production now means both installing it on the servers (Deploy), and exposing it to users (Release).
This blend of concepts is not only confusing, but it also hinders many of the benefits of the Cloud Native DevOps vision:
Reducing risk
We all know that "plan for failure" is the new norm, and when things go wrong coupling Deployment with Release can lead to tremendous damages. The reality is that shipping software is still considered a stressful occasion that has to be executed painstakingly, especially with complex distributed microservices environments.
Enabling advanced release strategies
Canary, Blue/Green, A/B testing, API versioning and other advanced release strategies are considered the holy grail of progressive companies. But given the release/deploy confusion, even with sophisticated CD tools it is still hard to reach and nonetheless require heavy investment.
Shift Right
Not too long ago, a best practice called "Shift Left" promoted the idea of testing early in order to reduce the cost of fixing issues. Testing early is obviously a good advice but at the same time Shift Left also promoted the addition of artificial test environments into the development process. The notion of multiple cascading test environments made sense for that time, but is less obvious today because:
- Software Development processes has evolved from structured and serial (Waterfall) to loose and dynamic (Agile), which affects our perception of the multi-environment workflow.
- Replicating the production environment is difficult for even experienced teams due to the increasing complexity of distributed microservices applications.
- Multi-environment testing slows the deployment process significantly.
In addition, testing early means testing simpler use cases. This is useful, but it doesn't diminish testing more complex, realistic use cases. Would you board a new plane that was only dry-tested in the garage, before it actually flew?
These are some of the drivers behind a change we see today toward "Testing in Production" approach. We went so far as to coin this as "Shift Right". Shift Right extends Shift Left to address how modern processes look like today. Shift Right is all about starting to treat production as a valid environment for testing, as long as it's done wisely.
Continuous Release
So we have discussed several factors that demonstrate how coupling Deploy and Release into a single phase hinders progress. We know how current tools (predominantly CI/CD) are being abused to try and workaround this situation. It is time to break free of this paradigm and start talking about the next set of tools that will complete the Cloud Native DevOps vision: Continuous Release (CR).
Because CR is detached from CD, you can now deploy into production in full velocity with confidence, which was a primary motivation of embracing DevOps in the first place.
Consider a pipeline consisting of CI->CD->CR. Each phase is focused on achieving a single goal and therefore using the best tools to achieve that goal. Let's discuss the CR phase:
- You group different service deployments by versions into a release.
- You expose releases individually by connecting traffic segments to them, a configuration that can be dynamically evolving.
- Multiple versions of the same services coexist in the same production environment, since exposing them is an independent phase.
- Work in progress safely live in production, allowing faster feedback loop and consistent verification of behavior.
A side effect of adding CR is that you relieve your CD to do what it was originally meant to do - to facilitate fast and often deployments. This becomes trivial when we defer the complication of releasing those deployments to a later dedicated phase.
Integrated approach
Before starting Bevyx, we actually thought long and hard about how to achieve Continuous Release using the tools that we had, especially CD tools. After exhaustive market research and POCs, we began to recognize a typical aspect that most existing CD tools have in common: They are all peripheral workflow engines, external to the target environment, which orchestrate their pre-programmed processed by invoking the target system public APIs. This paradigm worked very well for CI, and even for simple CD flows, but is not necessarily the best way to design a CR solution.
Consider an alternative approach where the release solution is embedded into the target environment (e.g. as a layer in the technology stack). We believe that this approach could provide a better foundation for a Continuous Release solution which by nature is much more intricate. Continuous Deployment tools tried to manipulate the production from the sidelines, Continuous Release solutions control the production from within.
How do you get to Continuous Release?
Resourceful tech companies have been practicing Continuous Release for quite some time now by dedicating valuable engineers to solve these problems for them internally. Some applications were built from the ground up with releasability in mind, and some teams built entire subsystems to support it. This is obviously out of reach for most companies, even technology oriented companies.
An alternative approach is one based on a recent addition to the Cloud Native stack - the "Service Mesh". The Service Mesh adds a layer of intelligent, customizable routing on top of your microservices network. "Istio" is such Service Mesh project started by Google, IBM and Lyft which recently graduated to 1.0 and is gaining popularity and interest.
While Service Mesh is a common layer that has many benefits, we think that its also the best place to start building a Continuous Release solution. This is why we decided to build Remesh, our Continuous Release solution, on top of Istio.
If you found this post interesting, check out Remesh, and stay tuned for our future projects from Bevyx!
Bibliography:
