Catalog

When you’re designing a microservice architecture, there are a lot of questions you have to answer. Some of them make themselves apparent very early in the process.

A service catalog is a valuable asset for any growing engineering organization delivering software at scale. But valuable assets aren’t created or earned easily. That’s why, at OpsLevel, we’re always thinking about ways to make building and maintaining an up-to-date service catalog simpler. Recently we upgraded our Discovered Services capabilities to do just that.

Today, Kubernetes is the de facto standard for container orchestration, running in approximately half of all containerized environments. Platform and infrastructure teams of all shapes and sizes are accustomed to operating Kubernetes in order to run their organizations’ microservices (and applications) at any scale.

At OpsLevel we believe Service Ownership is the future of DevOps. We believe this subtle, but important, shift can bring tons of benefits to engineering teams: autonomy, speed, resiliency, and accountability. We build new features in OpsLevel with these characteristics in mind; that’s why we’ve recently launched automatically personalized dashboards for all OpsLevel users.

Enabling Service Ownership is our north star at OpsLevel. We believe that true service ownership is the future of DevOps and a key to building agile, efficient engineering teams. As a part of making service ownership a reality, we’ve recognized that teams own services, not people. But of course, when you need to get something done urgently, you want to talk to a person, not a team. That’s why OpsLevel now supports tracking functional team membership alongside core service metadata.

Distributed microservice architectures are increasingly common today as engineering teams seek to scale both their applications and headcount. But for all the advantages of microservices, they’re not without tradeoffs. One area of concern is the web of dependencies that’s naturally created as more microservices are built and deployed.

You can use OpsLevel’s Git Integrations to run code-level checks against your services, to bring ownership to your repos, and more. While the best way of integrating your repositories with OpsLevel is importing everything, we realize however that some repositories are more important than others. (cough 6-month-old hackday project cough.) Oftentimes these repositories aren’t ready to be archived or deleted, but also don’t need the full OpsLevel experience. Wouldn’t it benice if they almost didn’t exist at all in OpsLevel?

Having strong ownership of your microservices and other running systems is an important pre-requisite to building a DevOps culture. But focusing solely on ownership of services running in production can leave some gaps. There’s a lot of code living outside of any service’s codebase: libraries, internal tools, templates, terraform code, and a lot more. All of these repositories need ownership too.

OpsLevel contains a ton of information about your technical services and systems, but it doesn’t contain all of the information about your business. Fortunately the data in OpsLevel isn’t trapped there! In addition to our existing GraphQL API, we now support extracting all of your OpsLevel data into your ETL pipeline and data warehouse.