Microservice Release with Tracking
A microservice release is a fairly straight forward activity. The difficult part of a microservice release is tracking its usage and relationships. And because microservices are immutable, you don’t replace the microservice like you do with a monolithic application’s binary. This means that multiple versions of a microservice could be running simultaneously in your cluster, with different versions of applications running different versions of the microservice. This way of releasing microservice creates a challenge. When you release, you always move forward leaving the older versions still running and available. After all, your application team may not manage those services, someone else does. So the results is a deathstar of microservice versions that require navigation. Take a look at these deathstars. Your microservice implementation will grow just as big.
Amazon and Netflix Death Stars
Yes, such microservice death star diagrams are now part of the conversation and show the depth of complexity in a microservice architecture:
So, if microservices are more complicated than say a standard Service Oriented Architecture, why move to them? The reason is simple. Microservices allows developers to implement changes more safely, efficiently and quickly. No doubt about it. Microservices are the apex of agile software development. They allow for small, independently deployable services to move freely to production and bring innovation to end users fast. To receive the benefit of microservices, our way of versioning and tracking configurations must shift from a ‘version, compile/link’ process to a configuration management of deployed objects at run-time.
Navigating the Microservice Deathstar
Let us be clear, the microservice deathstar itself is not the problem, it’s how we navigate and understand it that must evolve.
While the microservice death star is a broad look at our entire universe, we need a method of tracking the different applications that are running inside a single cluster. Your cluster is a collection of Pods that are running microservices. A specific configuration of Pods makes up an application. Each new microservice release creates a new version of your application, without you knowing about the change. Great, until there is an issue. Then you need to know. This is the new microservice release challenge.
DeployHub feeds deployment meta data of each microservice to deployment engines and locks the configuration to the cluster, with application and service mapping. This allows you to easily view any application running in your cluster, and visualize the changes overtime.
DeployHub’s Microservice Release Maps
DeployHub versions and tracks database updates, environment variables, Kubernetes configurations, infrastructure components, application artifacts, and other critical parts of your microservice release. In other words, DeployHub treats your entire configuration as code and versions it. By versioning these individual parts, DeployHub can reliably report a configuration management change, who made the change and the impact of the update.
Microservices are changing the way we develop software, which directly impacts how we perform a microservice release. While solving many problems, microservices are also creating new challenges around tracking, versioning and releasing the use of services in large Kubernetes clusters. New methods of managing microservice configurations are required to track what is in the microservice deathstar. DeployHub is that new method.
To begin tracking your microservice death star, sign up with DeployHub Team. This option is based on the open source Ortelius Project. It is provided for free and hosted for high performing development teams who want to manage Services in the new modern architecture.
- FREE Team Sign-up – A hosted version deploys to unlimited endpoints by unlimited users.
- Get Involved in the OS Project –Co-create the best, open source continuous deployment platform available.