Dear DevOps,

We love you. For years you've helped us set up our production environments, spin up our databases, deploy our code, and monitor our systems. It's been a good run. But things are changing.

It's not you. (And, no, it's not us either.) It's just the way things are. Computers are so good at so many things.

We just don't need you anymore.

See, the specter of automation has been wreaking havoc on everything for a while now — from fast food workers to news reporters.

Maybe you thought machines could never replace you. After all, DevOps engineers are intellectual capital. Heck, you practically created the machines that automation is built upon.

But this has been a long time coming.

Every one of your roles is being superseded by various types of distributed, always-on, always available (and, frankly, smarter) systems. Computers can replicate every one of your skills and reliably perform every one of your jobs.

You DevOps engineers aren't doing anything wrong. But there are several dozen different ways to do everything you do and do it inexpensively, automatically, and redundantly.

Let's break it down.

Web servers are complicated beasts. They're a blend of hardware and software that has a heck of a job to do. We expect servers be on at all times and ready to respond to whatever requests are made to them. It takes a lot of time and attention to get right.

DevOps have been vital to the setup and maintenance of these complex, interoperable puzzle pieces.

When a business needs web space someone needs to get those machines up and running. That means installing operating systems and server programs. It means configuring the various scripting languages and optimizing database systems.

Often times it means setting up multiple iterations of these systems and networking them appropriately.

Once everything is up and running, these systems need to be maintained. That means installing software updates that get pushed out on a daily basis.

Unfortunately (for DevOps), what we've seen over the years is companies that specialize in all of these functions.

Web hosting companies have done a phenomenal job of developing systems that take care of all the complicated pieces of running a networked system. All you really need to do is give a company your credit card number, reserve server space, point domain records to the appropriate addresses and you're good to go. The web host takes care of all the nitty-gritty backend nonsense that we previously would have had to pay an engineer to manage.

As great as web hosting companies have been, even they have been supplanted. Amazon revolutionized the world of server deployment with the introduction of Amazon Web Services in 2006.

For the first time, anybody anywhere could set up a server environment that meets their precise specifications. AWS runs server farms in just about every corner of the globe and provides systems that give you only the precise amount of storage, speed, and processing power you need. And best of all, Amazon manages, upgrades, and provides industry-standard security to each system.

Of course, Amazon isn't alone in this field. Cloud computing has become the service du jour for every major tech company in the world. Microsoft runs its own Azure cloud computing service. Google has Google Cloud Platform. IBM has Bluemix. At last check, there were almost three-dozen major cloud computing platforms all competing to make my life easier and my systems more reliable.

So, you see, it really doesn't make much sense to keep an DevOps engineer around just to keep the server farm churning. The servers can darn well do it themselves.

Another key role in the DevOps universe is code deployment.

While developers produce new features for whatever product they're working on, it's the DevOps' job to help usher that new code into production. This can be as involved and complicated as you can imagine. Transferring code from testing grounds to live environments takes time and finesse - finesse you DevOps have spent years perfecting.

Unfortunately, automation has got you there too.

There is a whole universe of tools available to help make code deployment safe and simple. We even have a term for it: Continuous deployment. It's the programming philosophy that says developers are just as capable of getting their code into production as anybody else — maybe even more so.

Just check out this Continuous Delivery Map [https://automic.com/continuous-delivery-tools] from Automic Software. Right up top are tools like Mercurial and Git — tools developers are already using to keep track of code changes and integrate them into the main branches of their projects.

Right next door we have tools like Chef and Puppet that take the labor out of deployment. They allow us to automate the repetitive parts of code deployment. You know, the parts of deployment we pay you for.

All these tools help us save time and money, but even more than that they keep developers involved in the process of bringing their code to completion. It is ideal to have a developer deploy his or her code into production rather than a detached third party. After all, who better to take care of problems in production code than the people who wrote that code in the first place.

That brings us to testing and monitoring.

Discovering bugs once your code is in production is unavoidable. In any complex system there are bound to be errors. Hunting down these bugs was once a big part of the DevOps' job description. But that too is changing.

System testing and monitoring is a big job. On the monitoring side of things, an always-on production environment requires constant supervision. You need to check your servers for signs of overload as well as making sure processes don't spin out of control. You also need to keep track of various network settings and records so you know when things are set to expire or change in advance of it happening.

You need to watch for any hiccups in the server environment itself, but also in the codebase of your product. Some issues can only arise from real-world scenarios. Unfortunately (again), DevOps are not particularly well-suited to anticipating and discovering software issues before they come up. Your software developers are. And that's why DevOps are ripe to be relieved of these responsibilities.

Similar to the situation with server setup and code deployment, product testing and monitoring is enjoying a period of disruption. Several different services for automated product testing have popped up over the past few years. They all do things a little differently, but they all allow people to shift this responsibility from you DevOps over to automated systems and developers.

One example is API Canary, a tool for developing and deploying recurrent automated testing applications. It uses the concept of Canary Testing — essentially sending out experimental bits of data — to poke at your product's code and look for weaknesses. API Canary is simple to set up and use, which gives software developers the ability to devise their own testing regimen for the products they build.

As much as it may pain you to know, this is a vastly more efficient and effective method for ensuring product stability than the current practice of having DevOps responsible for testing code they may not be all that familiar with in the first place.

All this brings us to today. We have to admit to a difficult truth: We don't need you anymore. We're seeing a great new system that does everything you do, but better.

You'll be fine. You're smart and funny. You'll find something new.

Now, if you'll excuse us, we need to have an uncomfortable chat with the customer service reps.