Skip to main content
Microservice Applications

Microservice Applications

Microservice Applications: A New Way of Building Software

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. This article serves to define microservice applications, and review application packages, application maps, development, and more.

What is a Microservice Application?

With a microservices architecture, the term “application” is sometimes used to represent a single microservice other times an application is a collection of microservices.

How is this Different from a Component?

In an effort to clarify these concepts, DeployHub uses the terms ‘Components’ and ‘Applications.’

  • Components: Your supply chain, such as a microservice, database update, infrastructure change, file update, etc., are all Components.
  • Applications: An application is a collection of components. Therefore in DeployHub, your microservice applications are a collection of loosely coupled Components.

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 development, 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, the application is still delivered to your end-users.

Microservice Application Complexities

One of the complexities of microservice applications is the loss of the application package and the ability to track changes over time. Because microservices are loosely coupled it can be hard to see how your application changes unless you practice microservice versioning. The need to track changes in your software project and understand what version of each Component you are using is still required.

Remember, each time a microservice is updated, it creates a new version of your application. For this reason, you will find yourself asking several important questions, for example:

  • “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 microservice application supply chain and versions over time.

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 changing supply chain. DeployHub allows you to define your application package based on what microservices you use.

Defining Your Application Package

With DeployHub, development teams define their ‘Application Package’ using a microservice application baseline designer, much in the same way as they did with monolithic applications. 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, based on changes in the underlying Components.

Each time a Component is updated, a new Application version is created. Once a baseline is defined, you can integrate with a CD pipeline to automatically track the new versions by triggering DeployHub’s automated configuration management at the time an image is created, or registered.

 

microservice architecture diagram

Application Baseline Package Designer Diagram

 

Automated Configuration Management

You may be thinking, “Do I have to update the microservice application package every time a new version of a 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 SBOMs

Once you have defined your application’s baseline to DeployHub, it will provide you the visualization maps needed to understand your microservice applications Software Bill of Material (SBOM), 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.

 

 

Microservice Application Dependency Map Diagram

Microservice Application Dependency Map

Difference Report based on Cluster

Application Difference Report based on Cluster

 

impact analysis

Application Impact Analysis

Microservice Applications and Database Updates

Because DeployHub sees everything as a Component, a database update is no different. Well, that is not completely true. If you define a Component as a DB update, for example, 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 components in your software supply chain as you move into a cloud-native architecture. For this reason, you need a method of versioning and tracking your applications when they are impacted.

DeployHub’s microservice catalog tool provides you with a method for versioning your applications based on the new versions of Components they consume. It integrates with your CI/CD process to continually update new versions of your microservices that, in turn, create new versions of your microservice applications, tracking new release candidates over time.

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

If you have any more questions about microservice applications, you can contact the team at DeployHub.

DeployHub Key Features

Next Post
Close Menu