I do a little cloud work, but mostly I end up working with customers that are trying to build and migrate their systems to the cloud. The transition to cloud-first took place quicker than I expected, though certainly the pandemic of the last 3 years has continued to accelerate the moves by many organizations. While not all systems will move, for better or worse, many organizations consider the cloud for everything and then decide to accept or reject the notion for individual cases. That's the cloud-first world I see.

At a recent event, I had numerous people telling me that their groups were mandated to move many systems to the cloud in a lift-and-shift fashion, and many of the technologists weren't happy. That's a conversation for another day, but listening to them and others has taught me a few things. Some of these are experiences I've learned myself, and some are things from others, nuggets gained from their hard experiences.

First, lift-and-shift appears to be a way to get started in the cloud. Some people find this to be an end-goal when they can get systems running without ever worrying about hardware or facilities. While costs can be higher, flexibility and tax considerations can make this worth the effort. Others see this as a first step to moving towards Platform-as-a-Service (PaaS) products and rewriting software, and life-and-shift is a good way to approach this process, but that leads me to the second nugget.

Everything takes longer to get settled in the cloud than you expect. Not that the cloud is slower to build and use resources. The opposite is certainly true as provisioning anything is fast, and upgrades (or downgrades) are incredibly flexible and quick. However, making the move, getting systems running to your satisfaction, decommissioning old systems, and more take longer. It seems most life-and-shift projects end up taking much longer than estimated, and not all of this is the massive data transfers needed to move data assets. Often it's humans that can slow the process, whether through debate on decisions or just getting comfortable with cloud resources through testing. Things take longer.

Maybe the last big thing that I've seen affect many companies is that we have to put better software development techniques and infrastructure configuration in place. The connection to resources is more complex and tenuous than it is on a LAN. We need to better architect software, really architect it as we were told to do so early in our careers with better error handling and retry logic. The cloud is very secure when you set it up right, but you no longer have the castle with high walls that you grew used to in a data center. Instead, you have a series of people and systems that are disparately connected and you need to ensure you protect each one along with the connections between them. That requires lots of configuration work and standards, and likely Infrastructure-as-code. Plus there are new tools to learn and the habit to build of using command line interfaces.

I love the cloud. In many ways, I prefer it over building and managing things on premise. Not for everything, and not for things where I might lose productivity with slow connections. I certainly don't want developer laptops or workstations in the cloud, but having other systems there can remove a lot of the hassles of managing assets that we purchase, track, upgrade, etc. I don't know I'd ever want to buy another physical server in a company I owned, but I also know that at some scales, it might still make sense.

The other thing I've learned about the cloud is there are a lot of unknown unknowns, as well as plenty of known unknowns. Tackling the cloud require a staff that wants to grow and learn with the platform, as well as one that knows when to use the resources they know best and don't add complexity or novelty just because someone wants to try something new. The cloud is worth considering, especially as it seems physical offices and data centers are becoming rarer and rarer in many organizations.