How devops in the cloud breaks down

It’s Tuesday morning and you’re on a Zoom call for the daily scrum meeting. You get the normal updates on progress and barriers to progress, which seem to be repeating patterns from project to project. However, you notice that you only see these issues when public cloud development is involved, and not more traditional development. 

What are these issues and what can you do about them? And why are the problems only in cloud and hybrid development?

First is the obvious issue: talent. To do devops in the cloud, you need devops engineers who understand how to build and use toolchains. More important, you need engineers who know how to build toolchains using cloud-based tools.

Some (but not many) people out there have these skills. I see many companies fail to find them and even pull back devops to traditional platforms just so they can staff up. Sadly, that’s not a bad strategy right now.

Second, the cloud rarely has all the tools you’ll need for most devops toolchains. Although we have a tremendous number of devops tools, either sold by the public cloud providers or by key partners that sell devops cloud services, about 10% to 20% of the tools you’ll need don’t exist on your public cloud platform. You will have to incorporate another provider’s platform, which then leads to multicloud complexity. Of course, the need for those absent tools depends on the type of application you’re building. 

This shortage is not as much of a problem as it once was because devops tool providers saw the cloud computing writing on the wall and quickly filled in the tool shortages. However, it’s often impossible to find everything you need running natively on your preferred provider. Devops engineers typically opt for hybrid approaches, taking a “cloud-first” tactic. They choose tools that run natively on the cloud, if they can be found, but have fallback options on other cloud providers or those dreaded on-premises systems. 

Of course, this brings more complexity to the toolchain, and as code and data fly back and forth between your cloud and other remote systems, security and reliability can become issues if you don’t have people on staff who understand cloud security implementations. Again, you must hire people who understand how to operate these cloudy things.

I can’t throw too many rocks from my glass house. At the insistence of long-ago clients, I force-fit devops into public cloud platforms before they were ready to do devops. It did not turn out well.

The core lesson is that there are no free lunches in computing. Any new path that seems to be more productive and cost-effective—such as the cloud computing consumption models—will have a ton of downsides. 

The lack of tools will likely be solved in the relatively near future because yours is not the only enterprise with this problem, and providers are directing more R&D dollars in that direction. As for skilled staffing shortages, if you can wait for the right talent to move your cloud projects forward, I suggest you seriously consider that option. Your ability to work around and through these issues is what ultimately leads to success. That ability often comes from having the right people in place at the right time.