Migrate Your Engineering Team to the Cloud

Introduction

For the typical enterprise, most of the discussion around migrating traditional IT to the cloud or to on-premise cloud-native technologies resolves around infrastructure and operational cost savings. (I’m a cloud optimist, so for the duration of this post I’m going to assume that cloud migration does still save, not cost, money.)

During the discussion, there might be some lip service paid to things like IT delivery velocity. But how do you start to unlock that value? Specifically, how do you take a classically trained and experienced IT organization and “lift and shift” the engineers to the cloud? I’ve seen a few different approaches. If you’re doing a cloud migration, chances are you are using one of these strategies whether you’ve thought about it or not. Since it’s always best to make mindful decisions on engineering approaches, let’s have a closer look at each.

Training

The classic Fortune 500 approach to up-skilling or re-skilling an organization — IT or otherwise — is to hire some experts to come onsite or maybe even send folks away for some good-old-fashioned training. To many of you (especially the younger among you), this may sound like a radical concept, because very few companies are willing to make that kind of investment anymore. At best, they may provide a Coursera subscription along with a strong implication that you mostly use it on your own time.

There are multiple reasons why professional training is not the in-thing in the corporate world anymore. I’m not going to dive into what those are here, but I wanted to mention cloud training as a possibility in the interest of completion.

Mentoring

One of the best options for growing the cloud-native skills of your IT organization is to hire a few people who have done cloud work at a high level before and have them work side-by-side. Somebody with a few years of hands-on cloud experience at an Amazon or Google can help engineers who are new to the cloud to select and set up the right tools and processes as well as avoid common pitfalls in the areas of cost, security, performance, reliability, and more.

On the U.S. West Coast, experienced Big-Tech and 2010’s unicorn cloud engineers are now relatively common. In Seattle or San Francisco, there’s a good chance that your Starbucks barista can crank out a VPC from scratch with properly configured public and private subnets, a load balancer, and NAT and Internet gateways.

Outside the U.S. West Coast, these cloud-experienced folks can be significantly harder to come by. You can try to recruit them, but not coincidentally, the West Coast is one of the most expensive places on the planet, so these people will expect to get paid (by which I mean, really get paid), even after the tech layoffs of 2023-2024 (even the Starbucks barista). So depending on your pay scale and budget, the mentoring option may or may not be a realistic option for your organization.

Baby Steps

If your engineers are coming from a traditional IT background, they are probably used to provisioning, testing, and deploying on bare-metal or virtual machine infrastructure. So it’s only natural that their first impression when moving to the cloud might be to spin up a few VMs and go for it by deploying and managing their current applications and databases — the classic “lift and shift” approach.

In the cloud world, going directly to infrastructure-as-a-service (IaaS) is a bit like jumping into the deep end of the pool in terms of complexity and associated product and project risk. Instead of starting with IaaS, there’s a better way to get your team’s feet wet in the cloud, which is to build a few projects on a platform-as-a-service (PaaS) offering. Compared to managing VMs and virtual networking, there’s a lot less to go wrong (especially when it comes to security) by starting out on Heroku, Digital Ocean, or one of the cloud providers’ higher-level serverless app-builder platforms. And most of the cloud skills your engineering team will develop there are very portable should you decide to start employing IaaS in the future.

Winging It

This is the default option: You set your engineers off to work with some general strategic direction to “move to the cloud” or “go cloud-native”, and you let them figure it out. I’m less opposed to this approach than you might think after reading the previous sentence. There are a lot of good tutorials, documentation, and other resources that clever and experienced engineers can use to get building in the cloud relatively quickly and successfully.

But be aware that if you go the route of letting your engineers find their own way in the cloud, they will make some mistakes. If you’re not convinced, have a look at the list of AWS products or the unholy mess that is the CNCF Cloud-Native Landscape (warning: will cause high browser CPU usage) and see if you think that any human being can be expected to select the best set of cloud ecosystem building blocks from scratch. You have to be prepared to allow your engineers safe space to make mistakes (including customer-facing mistakes) as they learn. That’s always good advice for software engineering leaders, but doubly so when it comes to starting out with cloud technologies.

Wrap-Up

What strategies have you used to support your IT engineers as they get up to speed in the cloud? Reach out and let me know what good ideas you have!