Monolithic vs. Microservice CD Pipeline Process
Monolithic vs. microservices pipeline processes requires some big changes. Microservice pipelines will change the way we do push software updates across the life cycle. Kubernetes and microservices will drive us away from our old pipeline models to a much leaner method of software development. When I say a Kubernetes pipeline, I’m not referring to a particular set of tools but instead exposing the difference between what we do in a monolithic vs. microservice pipeline process.
The biggest difference between monolithic vs. microservice is the continuous integration step. In monolithic, the continuous integration process is where we do most, if not all, of our software configuration management. This is the first step in a monolithic CD pipeline and where we do decision making about what goes into our binary or binaries. We resolve code branches, pull down files, and execute a compile/link script that specifically defines the shared libraries and objects that will go into our deliverable. This deliverable is generally not re-compiled at every state in the CD process. In addition, the application is built with an infrastructure in mind such as a specific version of Oracle and Tomcat.
When we do the release, we send all the objects from the build. The build it is pushed to test, and then moved to a production staging area where the Ops teams decide when to move it out to production environments. When the build is monolithic, the deployment is monolithic. When we deploy, we update physical servers, VM images, Cloud Images or a Docker Container with the entire set of objects from the build. Our continuous delivery pipeline orchestrates this build and release process, centralizing the logs and pushing the process from Dev to Test and Test to Prod.
Image 1: Our monolithic pipeline
Kubernetes and microservices are not just disrupting how we create and release software, they are obliterating it. Monolithic vs microservices is no longer an option. This latest trend is being driven by two primary features of the Kubernetes architecture: fault tolerance and high availability with auto scaling. Both are required for creating modern software that can satisfy the consumers demand for more data faster. IoT, big data, machine learning and AI all require the bigger processing power, stability, and responsiveness offered by Kubernetes. When I say Kubernetes is a shift as big as the move from the mainframe to distributed platforms, I’m not exaggerating.
A Kubernetes pipeline looks very different. Even the concepts of Dev, Test and Prod environments go away.
Ok – did your head just explode?
Good, because now you have an open mind.
A New Way ahead
Microservices offer a completely new way of approaching software design and deployment, one that is truly continuous. Microservices should be seen as the last mile of agile because they allow smaller updates to be independently deployed and shared across the organization. With a microservice architecture, we are not just applying coding fixes in an incremental fashion that then kicks of a monolithic build. Instead we are pushing those smaller changes across the entire pipeline independently. In other words, microservices fit extremely well into an agile methodology where the goal is smaller incremental updates that happen daily or even hourly. The concepts of siloed environments and our old monolithic pipeline habits begin to fade as microservices move us into a truly continuous practice. Our monolithic application is broken into individual, independently deployable services. A single microservice alone only performs a highly specialized function of the application. A package of microservices becomes a ‘logical’ application, but you no longer release an entire application.
Differences between Monolithic vs microservice pipelines
Lets start with the big one. The compile/link process that drove the Continuous Integration practice goes away. With a microservice you will not have builds that last for hours. Instead, your build will be a small compile followed by the creation and registry of a container. In addition, the concept of branching and merging code may go away. Will we be branching a 300 line Python script? Probably not. The discussion around ‘release candidate’ also changes. Every new container becomes a release candidate. A new release candidate may be the trigger for the workflow. The number of pipeline workflows will change. A monolithic vs microservice comparison shows moving from a few dozen workflows for different application versions to a few hundred workflows for every microservice. And in the same way, every microservice may have its own repository. The discussion on poly vs. mono repositories is far from over. I’m sure we will hear much more on that topic. And most important, microservices will be updated at a much higher rate than a full application. This is their super power.
Difference between Monolithic vs Microservices Releases
When we look to the future and compare monolithic vs microservice releases, we see a big change coming. As teams developing on Kubernetes gain more experience, they will begin moving away from dev, test and prod silos. Service Mesh will become part of the Kubernetes pipeline and will perform the request routing, which will control user access to microservices. All end users will be defined to use a single cluster, which will contain multiple versions of a single microservice to serve dev, test and prod end users. A new version of an application will be deployed, one that brings with it ONLY a new version of a microservice, v2 for example. The Kubernetes pipeline will instruct Service mesh to route some users (dev or test) to access the application that includes the v2 of the microservice. Once approved for release, service mesh will be updated to enable all users access to v2.
Image 2: A single environment to rule them all
When this process becomes the norm, teams can quickly perform an incremental update of an application and deploy it just once. Once the new microservice (which creates a new version of the application) is ready for prime time, the Kubernetes pipeline will instruct service mesh to route all users of the application to begin using the v2 of the microservice. Now you can see how our pipeline (dev, test, prod) becomes a bit blurred, or maybe just a bit more continuous, and with that more agile. A rollback is simply an instruction to the service mesh to re-route users. A roll forward is the same.
There are so many questions that still need to be answered. For example, will each microservice have its own workflow? How do you aggregate the monolithic equivalent of an application? How do we version a microservice? How do we track relationships?
I know we have spent lots of time sorting out a life cycle process to manage our monolithic pipeline, but eventually it must go. Kubernetes and the new Kubernetes pipeline is ushering in a much better way. Our job is to begin seeing this new way, and therefore begin breaking down the old patterns so a new, faster method of creating software is allowed. My advice, just keep your mind open and together we will create a Kubernetes pipeline process that drives innovation to end users faster then ever before. It’s about time.
- Domain Driven Design Catalog to Tame Microservice Sprawl
- Microservice Architecture and Your Logical Application
- Microservice Configuration Management
- Continuous Deployment and DevOps at Scale
- Register for DeployHub Team
- Reverse Proxy Setup for SaaS Deployments
- DeployHub Team User Guide
- The Hipster Store Tutorial
Ortelius Open Source Project
All Continuous Delivery and DevOps Blogs
- Continuous Deployment Blogs
- Understanding a Microservice Pipeline
- Microservice Continuous Integration – Where’s the Build?
- Working with Helm for your Microservices Releases
- Kubernetes Pipeline Challenges
- Managing Embedded Configurations
- Questions and Answers on managing a K8s Pipeline
- Running Safe Blue / Green Deployments
- The DeployHub Jenkins Plug-in
- Setting Up the Jenkins Plug-in
- The DeployHub CircleCI Orb
- Creating a Continuous Feedback Loop
- Release Agents – the Enemy of Continuous Deployments
- DeployHubs Release Architecture
- Why we need Application Packages for CD
- Agentless Deployments with DeployHub’s Engine
- Version Jumps and Tracking
- Blogs on Microservice Configuration Management
- Database Updates in Your Continuous Delivery Process
- Database DevOps and DeployHub