Why move your applications to the cloud?

Talking about the cloud and actually moving to the cloud are two very different things. It's important to simplify and de-risk your migration by taking a phased approach and examining individual workloads to work out what's best for your infrastructure. For example, moving a few remote desktops or non-critical applications might be a good place to start - before you then scale from there. And (let's be honest) it's probably true to say that not everything will end up in the cloud anyway, for reasons I'll explain...

Why put applications in the cloud?

For argument's sake, let's say we don't want to worry about high availability ourselves in our own data center because it means we've then got to employ engineers, solution architects, and a whole team of people to support that infrastructure. That's a headache, right? So putting bespoke infrastructure in the cloud might look attractive.

It's potentially cheap and scalable...which means we don't have to keep going out and buying lots more hardware, lots more infrastructure, paying people to implement that infrastructure, and then build out your own solution. You can make all of that somebody else's problem.

And when we're talking public cloud, you can just scale up your credit card bill slightly, and not worry about all the other stuff. So, the main driver for moving your applications to the cloud is probably to reduce your overheads, which most organizations can obviously benefit from.

Workload use case: cloud storage

The first workload I ever started to try and move to the cloud, way back when, was storage (think archive and off-site backups), having promised a local data center I would provide them with a highly available storage array.

I had two choices available to me:

1. Build it small...and expect to scale it up later, meaning costs would inevitably rise; or
2. Build it massive...so I wouldn't have to scale up later, but then I'd end up spending too much money.

And the cloud just took all of those problems away from me. Need 20 gigabytes of storage today? Brilliant. It costs X. And when I need 25 gigabytes next week, it will cost Y. And none of this will require me to reimagine anything, or extend myself to large services and keep big servers running all the time, using up lots of power and taking up wasted space when they're not doing anything.

Surely then, we can largely say that the question of 'to cloud' or 'not to cloud' has been answered? Well, yes, and no...

Things to consider when moving workloads to the cloud

At the end of the day, you've also got to bear in mind that every workload is different, and weigh up the pros and cons for each.

Monolithic applications: probably not for the cloud

A monolithic, big, single server application, probably doesn't suit the cloud because you can't break it up in the way you can with modern applications. You can't have it using different in-built cloud infrastructure (like storage on S3) and then have a Remote Desktop Server database somewhere else.

And this is where a lot of companies made the mistake in the early days of trying to write everything to the cloud. The IT guys tried to lift and shift everything, just as it was in their data center, and then the CTO would get collared by the Chief Financial Officer later on, when they realized their spending had increased tenfold.

Modern applications: likely to work well in the cloud

With the public cloud, if you've got a credit card you can be free and loose with your requirements, and scale up and down as needed. But at the same time, if you lift and shift instances like-for-like, you are not leveraging the cost savings of the cloud.

To achieve that you've got to strip away all your design ideas, and get the app down to its service core, before you can then think about putting it onto their compute architecture. And it's only then that you actually benefit from the cost savings, make it serverless, and start to leverage their own storage system in their own cloud ecosystem.

But...and it's a big but. That's when you experience the biggest con. In that scenario, you're suddenly tied to an ecosystem that you cannot transfer easily to another public cloud.

So the transference of an application that you've designed in AWS to another hyperscaler is difficult. And this is the multi-cloud syndrome that people touch on. You've managed to get rid of all your design ideas and stripped the app down. But on the other hand, you're deeply committed to one branch of the public cloud. There are ways around that, but it's definitely important to try and avoid single vendor lock-in where possible.

Conclusion

As I said earlier, every workload is different and needs to be examined in isolation before you can make an informed decision. However, here are some general takeaways:

1. Costs - You've got to be careful when considering workloads for the cloud and do a full cost/benefit analysis. And if you can't accurately calculate the costs over time, then it probably doesn't make sense to mess with the status quo.
2. Phased migration - Take a phased approach and make sure connected workloads stay together to de-risk your cloud journey.
3. Storage - Using the cloud for redundant archives and backups can be a good place to start when it comes to workload migration because you only pay for what you definitely need, and you're not dealing with high-risk, mission-critical applications.

Nevertheless, with the potential for scalability, flexibility, and efficiency promised by public cloud service providers, you're likely to be grappling with these issues for many years to come!