How to pick cloud dev tools and infrastructure

Tools and technology. They make up what a technology solution is, including how something is built, the resources it leverages, and the infrastructure it uses, such as databases, storage, compute, machine learning, analytics, etc.

Lately, I’m seeing a number of project failures that can be traced back to poor dev tool and technology selection. We’ve been dealing with this issue for years and should have figured it out by now. Why are things getting worse?

The reality is that things have changed out there. Those entering the dev, test, and deploy space recently have very little clue how to pick the tools and technology that will work the first time. In other words, how to reduce risk. 

Here some advice:

Avoid being too early or too late. Most of those in the world of development focus too much on the tools, platforms, and other technology first. I’ve seen a tool and/or technology chosen before the developers even knew what they were building and for what purpose.

On the contrary, some wait too long, only to find that some limitation they were unaware of will change a significant portion of the design. For example, the database originally targeted isn’t supported. 

Pick tools and technology in the correct sequence to reduce or eliminate risk.

Understand the business. Too often I’ve heard the nightmare tale of a company standardizing development or infrastructure on a specific vendor and then having that vendor “break bad”—it gets acquired by a larger company that removes support or it is no longer viable and shuts its doors. 

There’s only so much you can do to protect yourself from such situations, but you can ask some key questions up front, such as what your rights are if these business events occur. I’ve seen agreements written that customers have rights to the source code if discontinued, or better yet, the vendor pays for migration to other viable tools and technology.

Another strategy is to use open source options. Here you’ll not only have access to the code but also can leverage other companies that sell and support the same open source systems.

Finally, and most important, is to test the stuff. This does not mean doing a Zoom demo, but testing the actual technology on the actual platforms.

The good news is that these days there are no stacks of discs that show up in your office. Everything is virtual. Moreover, if a vendor is part of a public cloud provider’s marketplace, it should have gone through some basic acceptance testing of how its products run on the cloud platforms and use resources, such as storage, compute, and databases.

More than a few times I’ve saved my bacon by finding some unexpected compatibility issue or missing feature. I was able to switch out the technology before reaching the point of no return.

Two things are not in your favor. First, complexity is increasing because deploying on cloud-based platforms, including multicloud, means about a thousand more factors in how we can build, configure, and deploy solutions in the clouds. Second, an overwhelming number of tools, technologies, and configurations are available.

We need to become much better at making solid choices around the right technology and tools. Let’s get things right the first time. It is possible.