Ortelius for Microservice Management – Re-Imagining Continuous Integration

575 VIEWS

· · ·

We continue moving toward a Service Oriented Architecture with microservices in a cloud native environment. In the process, we say goodbye to monolithic methods and practices. This is the case for Continuous Integration (CI). Ortelius is an open source microservice management catalog that addresses this evolution.

Continuous integration is the process of merging, compiling, and linking code to create a ‘deployable’ release candidate on a high frequency basis. This no longer exists. 

Most important to understand about microservices is related to the CI build step. It will shift to creating a container image that may involve code scanning, transitive dependency management, and possibly security checks. Objects may or may not be compiled. But most important is the loss of the ‘link’ step. The ‘link’ step in the software build is what created our monolithic binary, and now that is gone. Instead, microservices are independently deployed and are ‘linked’ at runtime via APIs. This small difference has a huge impact on how we manage the continuous delivery pipeline. In fact, we lose our concept of a ‘Bill of Material,’ difference reports, and even the application’s release ‘version.’ And dependency management has a completely new dimension. 

What is Ortelius?

Ortelius is an open source microservice management catalog governed under the  Continuous Delivery Foundation as an incubating project. The Ortelius open-source project evolves the DevOps pipeline by adding an automated configuration management step to the process. This step creates your logical application versions, displays BOM reports for the application version, and generates difference reports between any two versions, based on a cluster.

Ortelius was designed to centralize microservice configurations providing critical data, such as a microservice’s blast radius before it is ever deployed. Ortelius stores critical metadata about microservice usage, ownership, application relationships and cluster inventory across the entire lifecycle. In so doing, it establishes a central catalog of microservice configuration and deployment data.  

Diagram, timelineDescription automatically generated

A microservice ‘Blast Radius’

Ortelius performs version control of the microservices running in your container and rolls that versioning data up to all consuming ‘logical applications.’ Ortelius’s versioning tracks the container SHA, who is using it, who created it, and the microservice’s relationship to all consuming applications. 

Microservice Organization

When Ortelius was created, there was a particular focus around the organization of microservices. This included the implementation of a Domain Driven Design, relational database and versioning engine.  Grouping ‘like’ microservices together in a Domain structure encourages the reuse of microservices and reduces the sprawl. The versioning component creates the revision history to understand and track changes. The relational backend database pulls it all together. 

Ortelius uses the concepts of Domain, Environment, Application, and Components to manage objects. Some of these terms we’ve seen before; Environment and Application, for example. But Domains and Components are new concepts, which relate to how your Services are organized.  

Just to make sure we are all on the same page, an Environment is a collection of endpoints. This is where your Application is going to be deployed. Most traditional Application Release Automation solutions use these terms and concepts for doing software deployments. To support microservices, Ortelius uses the concept of Components and Domains to construct a complex grid of service-to-application relationships, based on versions.

Ortelius defines an Application as a collection of Components. Your microservices map directly to Components. A Domain is both an object unique to Otelius and a concept used to organize Microservices based on lines of business or ‘problems’. This is often referred to as Domain Driven Design (DDD).

Conclusion

Microservices are changing the way we develop, build, and deploy software. While solving solving many problems, microservices are also creating new challenges around trackingand versioning the use of Services in large Kubernetes clusters. New methods of managing microservice configurations are required to track what is in the ‘Microservice Soup.’ Ortelius is one such solution. Its microservice management design creates a single source of truth of all your microservice configurations across all clusters, with built-in support for integrating into your continuous delivery pipeline for continuous configuration management.


Tracy Ragan is CEO and Co-Founder of DeployHub. DeployHub is the first microservice management platform, designed to facilitate the sharing, relationship mapping and deployments of microservices. DeployHub is a primary contributor to the Ortelius Open Source Project. Tracy is expert in configuration management and pipeline life cycle practices with a hyper focus on microservices and cloud native architecture. She currently serves as a board member of the Continuous Delivery Foundation (CDF) where she is the elected General Member Representative.


Discussion

Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

%d bloggers like this: