Product

Over the last decade, shrinking feedback loops have been a core part of building and delivering software. Across every phase of development and delivery, software engineering organizations are getting faster answers to questions like:

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.

How we started: thumbnails with smartcropper. In the very early days of OpsLevel, our marketing website was powered by WordPress. Even though our site then was small, WordPress was a pretty big moving part that required more maintenance than it was worth. We found ourselves spending time on upgrading both WordPress and its plugins, debugging when things broke, and managing performance. We also found that drafts were not a great workflow for previewing or staging changes as the live production site wouldn’t always look the same as a draft edit.

Engineering initiatives are a necessity when it comes to ensuring security, reliability, and keeping the lights on within an organization. These can include actions such as upgrading library versions, migrating everyone to a new metrics provider, or upgrading a framework.

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.

We all know that naming things is one of the two hardest problems in computer science (along with cache invalidation and off-by-one errors.) Naming your microservices is extra hard, as they’re almost like children: they’re practically these living, breathing things that you birth into the world and do your best to make sure they’re set up for success in life (i.e. in production.) Ok, perhaps people don’t agonize over the names of their microservices as much as the names of their children, but it’s still a big enough decision.