DevOps

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.

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?

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?

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.

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.

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.