Cataloging your Microservices
When we created Ortelius, we knew we needed to address the new microservices architecture. What we saw as critical for Kubernetes pipelines was the ability to:
- Group ‘like’ Services together as a package;
- Support Domain Driven Design (DDD) with sub-domains;
- Services organized based on a ‘business’ or ‘problem’ space;
- Encourage re-use and collaboration of Services;
- Perform continuous deployments without agents for frictionless implementation;
- Track a Service version to an application version, providing a single source of truth.
To provide the framework for managing Services in their Containers, Ortelius uses the concepts of Domain, Environment, Application, and Component. Some of these terms we’ve seen before, like Environment and Application, 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 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 uses Domains to organize them. Ortelius defines an Application as a collection of Components. Your microservices map directly to Components. Your Application could have any combination of Component types, such as application Services and database Services. A Domain is both an object unique to Ortelius and a concept used to organize microservices based on lines of business or ‘problems’. This is often referred to as Domain Driven Design (DDD).
Collaborating for Success
As Developers, we know from our experience around Object-Oriented Programming that sharing and collaborating around the use of Services will become critical for their success. We know we’re failing when each team begins to ‘copy’ and ‘rename’ their own versions of Services. This would be bad. Ortelius provides a collaboration framework so that your Service can be published and shared across teams. This allows them to choose a Service from a Component list. Providing a central repository of the available Components also reduces the temptation of taking an older version of a Service and making it ‘our own.’