Skip to main content

Microservice Applications, Microservice Patterns and Your Application Package

Microservice applications are vastly different from monolithic applications. In fact, they are so different that we should define what we call an ‘application.’ In a microservice architecture, the term application can be a bit confusing as the goal is to break up the monolithic application into smaller parts. The term application is sometimes used to represent a single microservice other times an application is a collection of microservices.

In an effort to clarify terms, DeployHub uses the terms ‘Components’ and ‘Applications.’ A microservice, database update, infrastructure change, file update, etc. are all Components. An ‘Application’ is a collection of ‘Components.’ Therefore in DeployHub, your microservice applications are a collection of loosely coupled ‘Components’ that make up your software project.

In the monolithic world, we rely on the build step of the Continuous Integration workflow to create the binaries that represent a version of your software project as a whole. All of the components are compiled and statically linked into a single .jar, or a collection of .dlls and .exes. The binaries are then carefully moved through the dev, test, and prod states of the life cycle – all together. All of the linking is done at development in the build.

With microservices, the linking is done dynamically via APIs at the dev, test, and prod runtime environments. Their usage across different software projects define your microservice patterns. But as the saying goes, “the more things change, the more things stay the same.” While your application is a collection of loosely coupled microservices, it is still an application that is delivered to your end-users.

Microservice Application Complexities

One of the complexities of a microservice application is the loss of the application package and microservice versioning. Because microservices are loosely coupled it can be hard to see how your software project is defined as a complete package.

The need to track changes in your software project and understand what version of each Component you are using is still required. Without this data, we are out to see without the North Star pointing the way. Remember, each time a microservice is updated, it creates a new version of your application, and you may not know when that happens. In other words, microservice patterns are constantly changing based on new updates. In a microservice application, you will find yourself asking questions like:

  • “What version of a microservice is this version of my application using?”
  • “Who is using my microservice?”
  • “When can I deprecate the service?”
  • “Who created this microservice?”

DeployHub manages this level of data in order to easily answer these questions and track your application versions over time.

DeployHub manages your software project by putting the microservice application package back into the picture. As you begin to decompose your monolithic application into several independently deployed components, you begin to realize the need to track service to application relationships, including their versions. At DeployHub we believe that a microservice update with versioning is the safest and most efficient method of getting the job done. And capturing that information before anything is deployed is the safest way to manage change. What we don’t want to do is wait for an incident report to learn that something went wrong. Knowledge is key to eliminating confusion and risk when releasing components into a Kubernetes cluster.

A Logical Microservice Application View

A ‘logical’ view of your microservice application and application versions is a critical piece of understanding your microservice patterns. DeployHub allows you to define your application package based on what microservices you use.  With DeployHub, you define your ‘Application Package’ using an application baseline designer. You use the microservice baseline designer to define a logical view of your application’s Baseline Version.  The Application Baseline is then used to track and progressively version your application changes over time. Each time a microservice version is updated, a new application version is created.  Once a baseline is defined, you can integrate with a CD pipeline to automatically track the version changes using DeployHub’s automated configuration management.

 

microservice architecture

Microservice Application Baseline Package Designer Diagram

 

Automated Configuration Management

You may be thinking, “Do I have to update the application package 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 available. You can also subscribe to a microservice which then notifies you if a new version of that 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 microservices.

Microservice Application Maps

Once you have defined your microservice application’s baseline to DeployHub, it will provide you the visualization maps needed to understand your applications dependencies (Bill of Material), Difference Maps based on Cluster and microservice Impact Analysis. This data can help you deploy your microservices confidently and without waiting for an incident report to tell you that something went wrong.

 

 

Dependency Map

Microservice Application Dependency Map

Difference Report based on Cluster

Microservice Application Difference Report based on Cluster

 

impact analysis

Application Impact Analysis

Microservice Applications and Database Updates

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 architecture.

Conclusion

You can expect to be managing thousands of microservices as you move into a cloud-native architecture. For this reason, you need a method of versioning and tracking your applications across the pipeline and your clusters. DeployHub’s microservice catalog tool provides you a method for versioning your applications based on the new versions of microservices they consume and understands your microservice patterns. It integrates with your CI/CD process to continually update new versions of your services that in turn creates new versions of your microservice applications, tracking new release candidates over time.

With our inventory system, you always know the versions of microservices your application is dependent upon.  You have the insights on the meta data to resolve issues and confidently manage a rapidly changing application based on microservices.

DeployHub Key Features

Meet the Co-Founders

Get Started

Ortelius Open Source Project