Microservice Blueprint – A New Way of Defining Your Application

A Microservice Blueprint – the New Way of Configuring your Software Application

With microservices, a new way of assembling and tracking application components is required. Our old way of compiling monolithic applications is replaced by a process of defining a collection of microservices that defines the application. This process is what we call a ‘microservice blueprint.’ In a microservice architecture you will find yourself asking question like, “What version of a microservice is this version of my application using?”, “Who is using my microservice”, “When can I deprecate the service?”, or “Who created this microservice?”  With a microservice blueprint answers to these and other similar questions are available to everyone at anytime.  While you may no longer have the ability to manage your application as a complete package, DeployHub gives you a way to replace that process through its microservice blueprint features and it all starts with a ‘baseline.’

As you begin to decompose your monolithic application into several independently deployed objects, you begin to realize the need to track service to service and service to application relationships, including their versions. Some Site Reliability Engineers may do this using a Helm script or a Kubernetes Deployment YAML file. Others might trace logs to see transactions between microservices. At DeployHub we believe that a microservice blueprint, with versioning, is the safest and most efficient method of getting the job done. And capturing that information just before the release step is the best way to track your service relationships (with versions) running in your cluster.

Microservice Blueprint – a Logical View

A microservice blueprint is the process of defining a ‘logical’ view of your application as a whole. With a microservice implementation you know longer have an ‘application.’  Your application is composed of a set of services. Some services are written by the application team and others are reused from a pool of available and approved services.  But from your End User’s perspective, they are using a particular ‘application version.’  For example, a bank will have a ‘Teller’ application with a particular version.  The key to recognizing your application version is the ability to track the versions of the microservices is consumes. This is what a microservice blueprint is and achieves. While you no longer compile and link a big fat binary, you still need to know what your software application looks like, and the version of the services on which it depends. With DeployHub, an application is a collection of Components.  A Component can be anything or do anything.

Microservice Blueprint Defines the Map

With DeployHub you use the microservice blueprint feature to define a logical view of your application’s Baseline.    The microservice blueprint is then used to track an version your application changes overtime and its dependencies.  DeployHub uses a blueprint designer to get the job done. Once a baseline is defined, you can integrate with a CD pipeline to automatically track the changes overtime.

 

application to microservice packaing

Microservice to application definition – Base Version

 

Automated Configuration Management

So yes,  you may be thinking, “Do I have to update the microservice blueprint every time a new version of the microservice is released?”  Now that would be time consuming.  The answer is no. Once your Baseline has been defined, your CD process will call DeployHub to automatically increment the application version if a new version of a microservice it consumes is deployed.  You can also subscribe to a Baseline version of a microservice which then notifies you if a new version of a microservice has been created.  As microservices are consumed by applications, DeployHub tracks the dependencies.  It can tell you at any point in time which version of the microservices your application is consuming, how many different versions have been deployed to your Kubernetes cluster, and who is using the same microservice.

 

Database Updates and Your Microservice Blueprint

Because DeployHub sees everything as a Component, a DB update is no different. Well that is not completely true.  If you define a Component as a DB update, you will be given the option of defining both a roll-forward step and a roll back step.  This allows DeployHub to track the incremental changes of each associated DB schema.  DeployHub allows you to add a DB update as part of your microservice blueprint.

Conclusion

You can expect to be managing thousands of microservices in your Kubernetes cluster, which is why you need a microservice blueprint. Tracking what version of an application uses what version of a microservice is obfuscated. A microservice blueprint solves this problem.  DeployHub provides you a method for managing your microservice inventory along with all deployment configuration details.  It integrates with your CI/CD process to continually update new versions of your microservices that in turn creates new versions of your applications.  With our inventory system, you always know what version of a microservice your application version is dependent upon.  You have the insights on the meta data to resolve issues, and expose the level of impact a new microservice version may create.

 

Get Started

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.

Key Features