Insights

We’re kicking off an interview series, called Level-Up, with standout engineering leaders to learn what’s top of mind for them. Check out the full interview at the bottom of this post. And let us know who we should talk to next!

Let's explore Backstage, the problems it attempts to solve, and considerations to make before bringing it into your organization.

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.

Our software ecosystems grow more complex every year. With new frameworks, dependencies, and technologies to help automate or simplify every step of the development life cycle, keeping track of requirements that provide reliability and security can become difficult. And that’s why production readiness reviews and checklists help eliminate cognitive load. They let you focus more on features or potential failure points.

Kubernetes is great because of its almost limitless configurability. But this configurability makes it hard to ensure that best practices are followed consistently across your cluster.

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.

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?

Let’s get DevOps to mean Service Ownership again. We broke DevOps. And it’s preventing us from building. When the first cloud providers emerged in the mid-2000s, they unlocked a new superpower: the ability to near-instantly provision hardware. Service-oriented architecture and microservices developed as a new architectural pattern. As a result, DevOps emerged as a practice to organize engineering teams around those new services - combining development and operations responsibilities onto the same team.