The Year of The Bots

3933 VIEWS

· · · · · ·

We’re now three to four years into DevOps, depending on your point of view—which means we have just a few years left before the acronym comes under fire, and its replacements are queued up. Just as I fought the term “DevOps,” I’m almost certain I’ll fight whatever the new term is, regardless of its relevance. And the replacement process has already begun.

The “NoOps” movement is still ticking, although it’s essentially been squashed; “DevSecOps” seeks to be the mature replacement of “DevOps.” Then there’s “AIOps” (which from what I gather on one end is replacing developers all together, while the other is making automation autonomous).

For the record, they’re all BS

How we define methodologies and the technology to support them doesn’t matter—at all. The continuum of improvement is never broken. Each generation is simply an easier way to have a conversation about how to improve what we do. So if you weed through the BS of the labels, you quickly realize that the value is simply that, with one word, the person you are chatting with can be on the same page with you. It’s a language tool, which isn’t really sexy (to those of us in the tech field, anyway).

So “AIOps” here we go. The term makes sense. Automation has served as the glue that has taken us from ITSM to ALM to DevOps. So improving automation makes sense—and the DevOps generation of tooling has added tremendous functionality and data to make better automation possible. (Consider anomaly detection in logging platforms like SumoLogic, LogEntries/Rapid7, and DataDog, along with pipeline automation with tools like CodeFresh, CodeShip, and Werker, as well as bots mostly developed by you.)

This data and an obsession with automation are what will make bots smarter and even more popular.

The year of the bots

My current prediction is that in 2017, bots will be a huge focus. And perhaps, just maybe, the catalyst for the “DevOps” replacement. Maybe it’s not AIOps. maybe it’s BotOps. (Still horrible.) Maybe a word-compounding genius will come up with something that blows all our minds.

I’m not the only one who’s thinking about this. In a recent interview, LogiGear CEO Hung Nguyen told me, “I think that AI is going to be a big part of the next generation of development tools.”

Here are three reasons I believe bots are the next phase.

    1. Bots are currently mostly developed in-house. So vendors are going to come in and make that process easier. And as they do, engineering resources and free time will be spent on finding ways to use them more frequently.
    2. Quality, support and maintenance are still bottlenecks for the more frequent releases in a DevOps-optimized delivery chain. Bottlenecks always need to be addressed. And bots are a logical way to offload manual effort in application testing, common maintenance, and customer support.
    3. Bots are already being used, and people love them! Many of the people I talk to, including those at a recent panel I hosted at the PagerDuty summit that included Airbnb, Cisco, DataDog, and Slack engineering leadership, are crazy about how effective bots have been for them in chat and automation. And we all know we are only scratching the surface.

So right now (unlike the early days of DevOps), if you are interested in modern delivery chains, you’ve probably already considered or are already using bots. We need more.

How to use them

    1. Support—We can use bots in support to first respond to users before they even know there is a problem, and react to issues a specific user may face when using an application, even before a ticket is filed. They can be used (and already are) in some conversations with customers, answering common questions. This practice is pretty well established, but getting smarter. (And it’s called “ChatOps.”)
    2. Self-healing—This is where cloud AI comes in—where we allow bots to learn common infrastructure issues, and how to respond without involving anyone. They can provide more elaborate alerting. The bot can serve as the first “person” on your call down list.
    3. CI and CD—More CI and CD automation driven by bots—getting information about current builds, etc.
    4. Testing—More testing of releases by bots that can learn common user behavior, run ongoing exploratory testing, and even build whole service virtualization architectures.

So if you are going to build a new tool today, you might think about something around bot building. Automation is the place to go, versus yet another logging or release automation platform.

The terminology may get to me, but, regardless, there will be a replacement for DevOps (even though DevOps is a mode of operation, instead of a thing). In 2017, the bot obsession will expand. And in 2018, it will become a market. Its job will not be to replace IT and development, no matter how appealing that drama is. The job will instead be to get QA, Support, and Maintenance up to speed with continuous development, and to mitigate IT fire drills so you can sleep better.


is a bad-coder-turned-technology-advocate who understands the challenges and needs of modern engineers, as well as how technology fits into the business goals of companies in a demanding high-tech world. Chris speaks and engages with end-users regularly in the areas of modern AppDev, Site Reliability Engineering, DevOps, and Developer Relations. He was one of the original founders of the developer marketing agency Fixate IO, and currently works as a Sr. Manager in HubSpot’s Developer Relations team.


Discussion

Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

Menu
Skip to toolbar