Skip to main content

Continuous Deployments – DeployHub Strengthens DevOps

Continuous deployment is the process of pushing updates to runtime environments (physical, cloud, Kubernetes) from development through production.  It is the heart beat of DevOps.  Continuous deployments can be orchestrated by a continuous delivery orchestration engine such as Jenkins, Tekton, CircleCI, Puppet Relay, etc. The truth about continuous deployments is that development teams and productions teams cannot seem to agree on the best options.  Most deployment processes written by development teams support the dev/test environments, but will not meet the requirements of Production teams. For this reason, continuous delivery seems to fail at the point where a production deployment is needed. This failure prevents the continuous delivery process from achieving its ultimate DevOps goal which is fast, safe and repeatable deployments from development through production. DeployHub addresses this issue and provides features for helping development and production teams collaborate around the release logic and processes.

Continuous Deployments for Hybrid DevOps Environments

It is clear, moving from monolithic development to microservice development will not happen in one ‘big bang.’  All DevOps teams migrating to microservices will go through a process where they must support both models.  And in some cases, this will require deploying to a variety of endpoints from physical servers, to AWS, to Google Cloud.  DeployHub supports a hybrid release model allowing you to automate releases for both monolithic and microservice architectures. DeployHub can call external deployment engines or use it’s internal agentless deployment engine to perform the lift of updates from repositories to endpoints.  While microservice deployments generally call Helm, Ansible or Operators, monolithic deployments and database updates may call the DeployHub engine to perform the update.  The critical data which is where was the component deployed to and by whom is tracked by DeployHub.

Continuous Deployments moving to DevOps @ Scale

We are in a massive shift in terms of how we drive DevOps and deliver software faster to end users.  The future of DevOps will require that the existing roadblocks to full continuous deployment (all the way to production) must be removed.  Microservices are designed to be released frequently, a feature that drives business agility.  Deployments must be as agile as our development.  DeployHub handles high frequency deployments by using versioning and dependency management to perform incremental updates of components.  Incremental updates is required in a microservice environment.  What DeployHub adds to the process is tracking these more granular changes and pushing independently deployed objects while not loosing the perspective of the whole .  Competing Application Release Automation solutions are designed for monolithic releases, an all or nothing process. These traditional tools cannot meet the demand of a microservice architecture where built-in configuration management is required.  While yes, they can update a container to a cluster, they cannot provide the feedback that shows all the parts that will be impacted by that change.  DeployHub can track hundreds of ‘micro’ updates, show the difference across clusters, and support a release model that you feel good about.  What you get with DeployHub is the ability to update just one component or microservice, but track the changes of all impacted applications providing you with clear data to make hard data-driven decisions before you hit ‘go.’

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.  So as you release microservices, your challenge is tracking.  DeployHub gives you the ability to version your entire Kubernetes death star, across all clusters.  While you may not be at this level now, we are all aspiring to build 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.

Continuous Deployments and Mircosrvice DevOps

Amazon and Netflix Death Stars



Continuous Deployments, DevOps and the Microservice Death Star

Your not to distant future will have your DevOps teams pushing shared microservices across multiple clusters that will immediately impact multiple ‘logical’ applications.  Your continuous deployment process will require the ability to perform ongoing configuration management of the changes providing a clear picture of what versions of the application your customer is using.  The complexity with DevOps and microservices is that you no longer are linking a static binary.  Your applications are completely dynamic and depend on what was deployed to any particular cluster.  In other words, we just shifted our continuous integration to the runtime environment.  DeployHub is designed to track changes as they are moved across clusters.


DeployHub’s Microservice Release Maps



DeployHub is designed to provide you a release automation solution that can support your existing monolithic needs, but also provide a road-map for meeting tomorrow’s microservice demands.  It is ready to delivery continuous deployments at scale, providing developers the control they need and operations the insight and audit they require.  DeployHub can break down the barriers that prevents a continuous delivery pipeline that can push software updates across the full life cycle.  While we may have the luxury of time in a monolithic practice to write and manage multiple deployment scripts that service the specific needs of development, test and production separately, in a microservice architecture that luxury goes away and DevOps at scale is required to meet the new demands of a modern architecture.