You’re doing cloudops planning too late

I often remember fondly the days of the waterfall software development life cycle. Each task had a beginning and an end. One work product was the input for the next documentation or code, and while it took much longer and had very little opportunity to change directions, it was easier to plan around.

Those days are over. Today’s cloud development—or development altogether—is iterative, agile, and can change at a moment’s notice. Often amplified by very robust devops toolchains, our approach to development these days is both automated and fluid, and that’s a step in the right direction if you ask me.

But some things are falling by the wayside. Often operations planning is either done at the last moment or not at all. Developers push out code and data structures to ops, and the ops teams must figure out quickly how to make the thing run successfully long term. Many ops and cloudops positions are going unfilled these days because they’re becoming the IT jobs that set you up for failure.

Ops planning should occur early in the process, at the design stage at least. While we’re at it, security and governance planning should occur at the same time, but that’s a topic for another blog. Doing ops planning early in the process allows for sound ops practices to be built into the systems, either net new or migrated to the cloud. There should be nothing left to chance in how the processes and storage systems will avoid typical ops problems, such as outages or performance and general usability issues. If no or little ops planning is done, it’s not a matter of if you’ll see problems, but of how many you’ll see before you kick it back to the dev teams.

Developers and application designers and architects look at me like I’m asking them to climb Mount Everest when I recommend that ops planning happen before a single line of code is written or migrated. In their defense, usually ops planning is the last step before cloud application deployment in most IT shops. They believe that the issues that the cloudops teams will deal with are “their problem,” and that things can be solved by iterating solutions “until they figure it out.”

Although you can solve any problem with enough time and money, we don’t have that much time and money. A more cost-effective approach is to complete cloudops planning while the application can still be changed easily, considering the mechanisms for operations, monitoring, and observability that are better designed into the solutions, rather than added later as an afterthought.

This can cut ops costs in half and make the deployment of net-new or migrated applications a success in the eyes of the business. The alternative is going through a series of issues that must be corrected ongoing, causing cost productivity to suffer and users to start thinking differently about “this cloud thing.”

The trouble is many cloud solution developers out there believe that adopting agile and devops means getting it wrong many times before getting it right once. That’s never the objective of agile or devops. This is about learning from our mistakes and adjusting to make solution development and deployment a much more cost-efficient process. Thinking about ops planning early and often is one item on the list of how to be successful with this cloud solution development stuff. Trust me.