DevX

Microservices will change. This is inevitable. But how do you manage that change to ensure your consumers don’t feel unnecessary disruption? Alternatively, what best practices can you follow to make migrations easy?

Engineering organizations often look for ways to improve their engineering teams’ efficiency. The more efficient the team, the faster they can ship new features and products to their customer base. From this need for efficiency, combined with developer empathy, we’ve seen the rise of DevOps and site reliability engineering across the industry.

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!

Over the last week, the team at OpsLevel completed its largest HackDay ever. OpsLevelers demoed 15 different projects, spanning everything from our infrastructure and CI/CD pipelines to our Applicant Tracking System and assets for acquiring and onboarding customers. Even our CEO carved out time to write some code–though he admitted his UI was lacking.

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.

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.