Ortelius Battles Microservices Sprawl with Configuration Mapping, Version Control

When developing a traditional, monolithic application, the versioning is flat and linear. As you make a change to the code and check it into a git repository, you build a new version of that application and give it a new version number. The code changes are closely linked to the application itself. With microservices, however, these changes happen to individual components that may be part of numerous applications and deployments, and tracking them is not quite so simple.

Ortelius, the open source microservice management platform originally developed by DeployHub and OpenMake Software, was created with this problem in mind and earlier this month joined the Continuous Delivery Foundation (CDF) as an incubating project to help solve the problem where it manifests most — in the continuous delivery pipeline.

“When microservices showed up, and I started looking at how it disrupts the continuous delivery pipeline, I realized it disrupts the most core step, the continuous integration step,” explained Tracy Ragan, Ortelius executive director and DeployHub CEO, in an interview. “That is because of the simple fact that microservices are loosely coupled and they’re linked at runtime. Instead of linking them into a binary, at the development stage, you’re waiting to do the link step all the way up production. That, in essence, causes so much complexity around microservices.”

A change in a single microservice, Ragan explained, has a cascading effect that is hard, if not impossible, to represent in a version control system such as git.

“There’s a scaling problem with microservices. When you’re thinking about trying to manage several hundred microservices moving across the continuous delivery pipeline independently all day long, we need a little more than git to be that backend repository,” said Ragan. “The problem with git is it’s flat, it’s not relational. So for example, it’s really hard in git to say ‘I’ve updated a microservice, now show me every application that’s impacted by it, and go automatically kick-off that CD pipeline.’ That is what we’re addressing.”

With Ortelius, a change to a microservice creates a new version, and then that new version creates a new version of every application that consumes it. These differing versions trickle down not only to these individual applications but also depending on where they are deployed, such that the same application on a different cluster has a different version because you might have different mixes of microservices on that cluster. Ortelius offers a relational view of what’s happening across clusters, enabling users to see where applications have been updated with a new version of a microservice and where they have not. Beyond handling versioning, Ragan says Ortelius can help with a problem she dubs “microservices sprawl.”

“Oftentimes, companies don’t understand that maybe a microservice is already out there that they could reuse. When you don’t have a way to organize them and manage them, you don’t know what’s out there, so you write it yourself, which was the big mistake we made years ago in object-oriented programming,” said Ragan.

Ortelius was first created in March 2019, based on a codebase from OpenMake Software, but Ragan said it wasn’t until June 2020, after cleaning up the code, that they began to really promote it. Now, however, Ragan said that the project has 120 members with 25 core contributors from 12 companies. With its admission to the CDF, Ragan said that they look forward to working closely with the other member projects in working to solve the unique problems posed by microservices to the continuous delivery pipeline and beyond. In fact, Ragan sees Ortelius as uniquely positioned to handle other issues as well, such as troubleshooting the issues that can arise upon deployment.

“One of the big problems that we hear from our users is their confidence level in deploying a microservice. They say that the problem with microservices is that they have to deploy them in order to find out if there’s a problem, and they find out about the problem via an incident report. We want to try to stop that to some extent,” said Ragan.

Furthermore, Ragan sees a potential for Ortelius to enable the sharing of microservices not only across applications and deployments but companies and organizations, much in the same way that open source software packages are shared today.

“Imagine some time in the future, when companies are really embracing microservices, and we’re starting to share open source microservices. We need a place to share and organize them, and that is what Ortelius potentially can become because it already has that domain structure,” said Ragan. “The domain structure allows high-level domains to be shared down to lower-level domains. A private company could have their own domain inside of Ortelius and still see all of the open source projects that they would like their developers to have access to, in an organized fashion, with all their deployment metadata, so everybody doesn’t have to write their own Helm chart, or define how it needs to be deployed, and what the value pairs are to do so.”

Feature image by Raphaël Biscaldi on Unsplash.