Microservice Applications: Building Software in a Cloud Native Environment

 

A Shift in How We See Applications

Microservice applications are vastly different from monolithic applications. They are so different that we should define what we call an ‘application.’ In a microservice architecture, the term application can be confusing. When your monolith has been broken into dozens (if not hundreds) of independently deployed services, then what is the ‘application?’ Is a service an application or a collection of services an application? This article serves to define microservice applications and review application packages and their components in a collective view.

What is a Microservice Application?

With a microservices architecture, the term “application” is sometimes used to represent a single microservice, and sometimes it represents a complete software solution delivered to an end-user. 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. The components are compiled and statically linked into a single .jar, or a collection of .dlls and .exes. 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, an application version is still delivered to your end-users.

Application Complexities

One of the complexities of microservices is the loss of the application package and the ability to track changes in the application 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 to easily answer these questions and track your microservice application supply chain and versions over time.

As you decompose your monolithic application into several independently deployed components, you 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.

We don’t want to wait for an incident report to learn that something went wrong. Knowledge is key to eliminating confusion and risk when components are being released via the CI/CD Pipeline all day long.

A Logical Microservice Application View

A ‘logical’ view of your microservice application’s versions is critical for understanding your changing supply chain. DeployHub allows you to define your application package based on what microservices it uses. With DeployHub, development teams define their ‘Application Package’ in two ways, using the CI/CD command line interface (CLI) or via the application baseline designer. You can 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. 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. The CLI can integrate into your CI/CD pipeline to automatically create and increment the application version when a new version of a microservice is updated.

You can also subscribe to a microservice, so you are notified when a new version of that microservice has been created. As applications consume microservices, 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 architecture diagram

Application Baseline Package Designer Diagram

Microservice Versioning Whitepaper

Microservices at scale offer new challenges in managing your software supply chain. DeployHub is solving the challenge through microservice versioning.

Download

Cloud-Native SBOMs

DeployHub makes it simple to create an aggregated SBOM for each software system you deliver to end users, even in a decoupled microservice architecture. DeployHub consolidates all Software Bill of Material (SBOM) and CVE reports for every version of your ‘logical’ application. The aggregation of this information provides a view of all open-source packages so your teams can easily mitigate supply chain security risks as soon as possible.

Database as Components

Because DeployHub sees everything as a Component, a database update is no different. DeployHub allows you to add a DB component as part of your microservice application configuration.

Conclusion

Microservice applications are a collection of lower-level components, each with an independent release cadence. Each time a lower-level component changes, your complete software solution has a new version and new SBOM / CVE. Tracking your microservice applications and versioning their differences is a must for understanding supply chain risk, blast-radius impact, and inventory usage across all of your environments. As you move into a cloud-native architecture, you will need to evolve your DevOps Pipeline to automatically track what application is using what services, generate application-level SBOMs and provide the needed insights to understand your software solutions configurations and potential issues as soon as a change occurs. Microservice catalogs, such as DeployHub, automatically governs your overall supply chain and tracks critical changes as they occur all day long.

Further Reading

Get Started – Give DeployHub a Try: