#deployhub

The best companies have shifted from monolithic software development to microservices, and yours will be next. But what does that mean, and are you ready for the shift from managing a datacenter to a Deathstar?

Yes, a Deathstar.  How are you planning to navigate yours?

With a modern architecture, there’s a Kubernetes cluster with nodes and pods running individual containers. Each execute a microservice, talking via APIs.  That alone opens up a ton of questions we need to address. Where are our applications, which version of a service is the application using, and lastly who is using my microservice? In other words, microservice configuration management just became critical.

In the monolithic world, software configuration management is performed mainly at the version control and compile step. Source objects were stored in version tools, then a compile/link process put it all together and we automated with continuous integration. In microservices, all the linking is done at runtime, and source becomes small snippets that need no branching and merging. It can be a right mess.

What then is the solution?

According to Cloud Foundry, “Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.” The ability to easily deploy between two environments is easily supported by DeployHub through the definitions of DeployHub Environments. Your DeployHub Application (collection of components like microservices) can be assigned to multiple Environments and deployed in a ‘rolling’ fashion or in this popular Blue-Green round robin process. With DeployHub, you define both Environments for your Application and push your deployments accordingly. DeployHub will track the endpoint history, of each Environment, including versions of each component that was released, Application Version, date, time and User. It is important to understand that in order for your Blue-Green deployments to become ‘active’ to your end users, you will need a load balancer that redirects users after the deployment has been successfully completed. DeployHub is not a load balancer, but it can communicate with your load balancer as a ‘post’ deployment step to re-route users.

DeployHub and Cloud Foundry

Blue-Green deployments are most commonly associated to Cloud Foundry. Cloud Foundry is an open source cloud platform as a service (PaaS) on which developers can build, deploy, run and scale applications on public and private cloud models.

Developers interact with Cloud Foundry by running a command line tool (cf) which then interacts with the Cloud Foundry Endpoint. With DeployHub, you release a new Application (or make changes to an existing Application) using the “cf push” command to upload the Application to the Cloud Foundry Endpoint. Cloud Foundry supports multiple “spaces”. Each space can be configured individually and can be used as different target types (for example, Dev, Test, and Production).

Since DeployHub is an agentless solution, it can deploy to Cloud Foundry by executing the ‘cf’ command automatically as part of the deployment process. DeployHub can extract your Application code from any Repository and push the changes up to the Cloud Foundry Endpoint. It can then track which version of the Application and associated Components is installed in which Cloud Foundry space.

Installing Cloud Foundry’s ‘cf’ Command Line Interface (cf CLI) on the same server as DeployHub allows the execution cf commands easily. An Application contains one or more Components, any one of which can have a Custom Action containing a cf command that targets the designated Clound Foundry Endpoint. For instance, a Cloud Foundry application named my_app could be started by writing a script named startMyApp.sh that looks like:

#!/bin/sh

cf api https://myexample.com

cf auth myname mypassword

cf target -o myorg -s myspace

cf push `my_app` -c null

If this script resides within the /scripts directory of the DeployHub installation, it can be called by putting “/scripts/startMyApp.sh” into a Procedure, placing it within an Action, and putting the name of the Action into a Component’s Custom Action field. Deploying the Application that contains the Component causes the Action to be called, which runs the script and starts the Cloud Foundry Application named my_app.

Cloud Foundry is ideal for Blue-Green deployment strategies. In such a scenario, Production is mirrored across two distinct environments — “blue” and “green”. End Users point to one of these Environments whilst deployments are made to the other. Once testing is complete on the deployed Environment, users are switched over to this Environment and the deployment is performed again to the other Environment. This maximizes uptime and minimizes the risks in performing a Rollback.

DeployHub supports such a Blue-Green deployment strategy. Both Environments can be targeted individually as part of two separate deployments or you can deploy to both with DeployHub deploying to the second Environment automatically following successful test and switch-over.