Blog

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.

More software, more problems? Software is eating the world and that means more people and teams are developing software. To stay current and competitive, modern organizations are scaling their software engineering teams.

The term “DevOps” entered the IT industry in 2009 with the first DevOpsDays event held in Ghent, Belgium. But the world is constantly changing. Since 2009, the IT space has shifted dramatically. Containers, microservices, and “serverless” computing have all taken the world by storm in the last decade. The term “DevOps” has also undergone a sort of transformation, though OpsLevel is bringing it back to its roots of Service Ownership.

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.

Years ago, end-to-end software development involved dividing tasks based on where they fell in the system life cycle. One team wrote the code. Then another team deployed it to production. And yet another team monitored and maintained the service. This led to a lot of friction, needless handoffs, and bottlenecks.

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.

When starting a new job, have you ever asked yourself: How much time should I spend learning about the code? The product? The process? Was I expected to know Technology/Framework/Design Pattern X?Is my ticket taking too long?