Kubernetes creates some real pipeline challenges. When you begin your Kubernetes journey, you’ll quickly find that your current CI/CD pipeline is not going to make the grade. Kubernetes is finally moving us away from a monolithic approach to software development towards a service-based approach. This means each microservice will have its own life cycle and be independently deployable. This is the game changer. While you can force your Kubernetes design to handle a monolithic pipeline by defining a separate cluster for Dev, Test, and Prod, this isn’t an optimal approach and dilutes the entire purpose of using microservices in the first place. Don’t let the pipeline challenges stop you from taking full advantage of the microservice architecture.
So before you go down this path, consider the changes that need to be addressed to your CI/CD process to make it a Kubernetes Pipeline. Let’s take a look at four big Pipeline challenges:
- CI/CD Workflows
- Dev, Test, Production Pipeline
- Sharing and organization
- Tracking the monolithic equivalent
DeployHub is designed to address these issues. We will first take a look at each and then cover how DeployHub addresses the problem to support a Kubernetes Pipeline model.
CI/CD Pipeline Challenges
Let’s start with the first and most obvious issue when we move from monolithic to microservices, the CI/CD workflow itself. Now most teams manage a workflow for an entire project, i.e. multiple binaries are pushed through the process. They are compiled, tested, and deployed as a complete unit. I’ve seen some teams manage a workflow for every version of their project, creating multiple workflows, which is always a challenge. So now we must stop thinking in terms of an entire project, and start thinking about a single microservice with multiple versions. How many workflows will this model create? Unfortunately, way too many.
Dev, Test, Production Pipeline Challenges
It’s not my intention to offend anyone, but you must agree that the concepts of siloed Development, Test, and Production environments come from a waterfall practice, not agile. And this waterfall practice is built into our continuous delivery pipelines, with some of the same exact waterfall scripts driving the process under the continuous delivery orchestration engine. With a true microservice architecture, all of this goes away. Service Mesh needs to be called as part of the pipeline to manage the access of new version of a single microservice to end users (creating a new version of the application.) In essence Development, Test, and Production become defined by configurations of microservices and a service mesh manages the access which defines if a developer, tester, or end user is using it.
Service Mesh and Kubernetes
Sharing and Organizing Microservices
The goal of a microservices architecture is to create a high level of sharing and reuse. We tried this once with Object-Oriented programming, but because we were forced to work on a monolithic project basis, most teams could not sort out how to properly share these libraries. I blame bad build scripts for the fall of OOPs. When we lost the UNIX VPATH statement during the early Microsoft days, there was no flexible way to easily bring external libraries into the link step. Microsoft ‘make’ utilities were not capable of incorporating an OOPs approach. So instead, teams started copying these libraries into their own projects and build directories which caused OOPs code to become ‘copied’ code – not shared. We don’t need to make the same mistake with microservices. The secret will be to create a Domain Driven Design around the organization of microservices so sharing becomes easy. The pipeline challenge will be providing developers a way to communicate the availability of new microservices and new versions of microservices.
Tracking the Monolithic Equivalent
Even though we are moving towards the management of individual microservices, the monolithic equivalent is still there, even when you don’t need to recompile and re-release the entire beast. We need a way of aggregating the collection of microservices back to the complete application version. In other words, we must be able to see which ones make up the application versions. And we need to track this based on our streams and branches.
DeployHub – a Single Source of Truth for Modern Software
DeployHub was designed around the concepts of microservices, their management, sharing, and organization. DeployHub allows you to catalog, publish, version and then deploy microservices. Let’s look at how we address our four pipeline challenges:
DeployHub and the CI/CD Workflows
Every team will need to decide how they are going to manage microservices inside their workflow process. In the future, it’s most likely that microservices will have a separate repository and a separate workflow. But the path of least resistance might be to utilize your existing monolithic CI/CD pipeline. DeployHub can support either method:
- Option 1 – Individual Workflows. DeployHub tracks which applications consume each microservice version. It serves as a single source of truth for aggregating the collection of microservices, and their versions to the monolithic equivalent. It deploys the microservice individually but creates a new version of the monolithic application logically.
- Option 2 – Monolithic workflows. DeployHub tracks each component of a monolithic application individually. When a new application release is pushed forward, it determines which microservice (component) needs to be released vs. re-releasing all of the microservices. DeployHub performs iterative releases on a monolithic application, supporting a process that allows a microservice to be independently deployable.
Development, Test, Production Pipeline
DeployHub interacts with Service Mesh to enable certain user groups to access a particular version of a microservice. DeployHub releases your new version to the cluster, and interacts with Service Mesh enabling developers to use the new version of the microservice. The deployment step is only done once. When the developers are ready, Service Mesh provides access to Testers. During Development and Test, the application is comprised of both production microservices and dev/test microservices. When QA testing is completed, Service Mesh is updated to allow production users access to the new microservice. A monolithic deployment to 3 separate environments are no longer needed. The deployment is done only once and users are routed to the appropriate combination of microservices.
DeployHub and Service Mesh
Sharing and Organization
DeployHub is a sharing platform for microservices. A domain driven design is used to define catalogs for organizing microservices. Developers publish their microservices (actually, their pointers to where the microservices are being stored such as Quay, Docker Hub, etc) to DeployHub under a specific domain. Domains can be secured or openly shared across teams, it’s your choice.
Tracking the Monolithic Equivalent
DeployHub uses a ‘Package’ to solve this pipeline challenge. A Package pulls together all the microservices and artifacts of the logical application. Developers select which microservices and objects make-up their application. If using a CI/CD process and a new version of a microservice created, DeployHub receives that information from the Workflow. It then automatically creates a new version of the application, referencing the new version of the microservice. An application is ‘released,’ however, only the microservices that have changed are deployed. This process beats an excel spreadsheet any day.
DeployHub was written to serve as a single source of truth about modern software. Its design moves away from a monolithic application that’s promoted across siloed Development, Test, and Production environments solving critical pipeline challenges. DeployHub sees the pieces and parts of the application individually supporting a Kubernetes architecture where microservices are shared and independently deployed. DeployHub turns your monolithic CI/CD process into a Kubernetes pipeline enabling your team to take full advantage of this new, amazing way of writing software.
- DeployHub’s Version Engine
- Domain Driven Design for microservices
- Microservices and Components
- Drive your Deployment Process using the Jenkins Continuous Deployment Plug-in
- Track Component to Endpoint with a Feedback Loop
- DeployHub and Jenkins – This Demo shows how DeployHub interacts with the Jenkins pipeline (including the blue ocean visualization).
- DeployHub Team Sign-up – The hosted team version can be used to deploy to unlimited endpoints by unlimited users.
- Get Involved in the OS Project – Help us create the best, open source continuous deployment platform available.