The End of DevOps

For at least the last decade, every executive was going crazy about devops. What sounds like a revolutionary, wholesale concept also had some substantial economic benefits, such as removing the need for sysadmins or ops specialists. Also, it was a nice euphemism of handing developers their own dogfood as many engineers allegedly did not care too much about the challenges that running their code would create.

However, the result was that developers became defocused and overwhelmed with the duties of running their code, resulting in less stable applications and countless hours invested not in coding, but in taking care of infrastructure challenges. We are about to change this for the better and remove infrastructure from the list of things to consider.

In itself, the idea is brilliant: make people who build things also maintain them. The expectation was that developers would feel more ownership for the applications they create and also be more efficient since they would cover the development process from end to end. Having one team to code and another team to take the code and run it seemed very waterfally in the agile age. Just throwing the code across the fence and let delivery / operations / admins figure out what to do with it was just not en vogue anymore (and, of course, it was also unfair).

I remember the days when we still had sysadmins. It didn’t help their reputation that some of them actually felt like a supernatural entity (aka “God”) and behaved accordingly. One of the first duties as a project manager was to make friends with the sysadmins, bordering on worshiping (“Sysadmin day”) if you wanted your projects delivered and maintained with care. The term “BOFH” wasn’t entirely unwarranted with some members of the profession.

So no wonder that especially the executive level of companies happily embraced the idea of removing this job from their teams and let the developers do the job. As far as I remember, most engineers also were open to the idea as there was a lot of friction between dev and ops. If something broke, the responsibility was passed between the two parties like the proverbial hot potato, which didn’t help create a team of teams living ownership for code.

As more and more developers got in charge of managing code in production, however, many drawbacks appeared. First of all, most developers don’t know as much about infrastructure as they know about coding, their primary profession (exceptions apply, of course). With this comes the obligation to do research, experiments and incremental improvements on infrastructure, which is time-consuming and not necessarily something every engineer is fond of, or good at.

As a result, the time-to-market in my observation actually increased instead of creating more efficiency, or the number of problems identified in production created an excess of technical debt that engineering teams had to address. Even the best code quality can’t ensure perfect execution in production.

Secondly, with devops came fundamental security and availability concerns. You need profound and highly specific knowledge to make sure you don’t expose your network or confidential data, as well as provide a reliable fallback or backup solution if disaster strikes. Fortunately, it seemed like companies like Amazon, Microsoft or Google were providing an easy, cost-efficient way out.

Amazon, Microsoft, and Google quickly realized that there was a growing demand for “infrastructure as a service” where detailed knowledge of infrastructure is no longer needed - you just combine lego bricks of services and run them in the existing cloud environment. Admittedly, it is a very neat idea, but it creates its own problems as well.

In theory, as a developer you can leave all the heavy lifting to e.g. Amazon and focus on what you do best, which is code creation. In reality, however, you are facing a crazy number of individual services with fancy names that you have a challenge remembering. The whole set-up has become so complex that you need consultants to guide you through the service jungle.

Even if you have identified the services that would help you, you also need to understand them first - read the docs, try stuff, debug, repeat (and not every behavior can be explained even by the manufacturer). With the promise of not having to deal with infrastructure anymore, there came the price of excess service complexity. The feedback we have been receiving for WunderGraph is that it’s awesome you can build your application locally with WunderGraph in an hour, but it takes days to deploy to AWS (in this example) and get it to run. This can be a very frustrating experience and contradicts our goal of creating the best developer experience possible.

Regardless, many developers rely on AWS, Azure, and GCS because there is no real alternative. Until WunderGraph Cloud arrives, that is.

After playing around with the term “serverless” for a while (which sparked some interesting discussions around how an application can be truly serverless in the first place if it is indeed running on some kind of server somewhere), we realized that what we actually need to build to bring simplicity back to the life of developers is an infraless environment.

The goal is simple: deliver a back-end platform with no need to think about infrastructure at all. The developer experience should be one similar to the early days of coding when it was enough to copy your PHP script to a webserver folder, and live it was. Database connection? Three lines of code, and you were done. You could instantly deploy and run your application.

With WunderGraph Cloud, we remove the burden of dealing with infrastructure matters for developers (hence “infraless”). This will have three profound effects also executives will love:

1. Developer efficiency will increase dramatically as they can focus on code / value creation with 100% of their time.
2. Security and performance issues related to poor infrastructure configuration are nonexistent.
3. Developer satisfaction will increase substantially as they don’t have to cover ops duties anymore.

But for us at WunderGraph, what matters first and foremost is the developer experience. Infrastructure should not be something a developer has to think about.

WunderGraph Cloud allows developers to focus on their actual trade again without forcing them to adopt a role that is not inherently part of their job. As an agile evangelist, I have to admit that I was a strong believer in the idea of devops ever since the concept appeared. What I did not recognize or simply considered an issue of adoption was my developer’s unease with being responsible for running their applications in production. Surely that could be fixed with training, and there were tools and consultants to help us along the way - or so I thought. I was suffering from the same managerial ignorance like a lot of execs are when they think they know the way, and all the others simply didn’t see the light just yet.

Many dollars spent on consultants and training later I have to admit that I made a mistake. Good developers will always try to adopt new concepts, and also being fully responsible for one’s code without having to put up with annoying questions from non-coding sysadmins certainly has its appeal. But it didn’t help that in almost all cases, no developer was really keen on doing something that was not related to coding. If you’re a composer, you usually don’t want to build and operate the concert halls in which your music is to be performed. It would also be a waste of your talent because all the time you have to dedicate to non-composing will reduce the time in which you can be truly creative. That’s not saying you’d be bad at designing a concert hall, but unless you’re a true polymath, it’s likely that there’s someone being better suited for the job.

To be clear: this is not a pledge to bring back a sysadmin role. It’s a pledge to remove this part entirely through automation. In terms of the concert hall, WunderGraph instantly provides you with the perfect venue for your masterpiece, no matter if you need an opera house or a small and intimate chamber.

At the end of the day, engineers can focus entirely on what they can do best and love the most: creating code, solving real problems and delivering value to their users. And besides being able to deliver much faster, the company will save a lot of time and money that it doesn’t have to spend on consultants or cloud services nobody truly understands or remembers the name of. :)