How and why I use the public cloud to get my work done

Sponsored IT content provided by Veeam

Let’s be honest: As an IT professional, I am not supposed to like the public cloud. Over the years, I have heard horror stories about the cloud taking over our work because everything can be done more quickly while being automated and more cost-effective. If IT professionals don’t watch out, our jobs will be lost and the accountant will take over provisioning resources for various business units with its credit card.

As a technical evangelist, I have the privilege and advantage of speaking with enterprises of all sizes throughout the year. This is one of the discussions that come up often during architectural meetings. Either C-level management is present and tells us to use it because above mentioned advantages or the IT professionals tell me directly that they are getting pushed in that direction.

However, reality proves time after time that on-premises infrastructure — whether or not you call it the private cloud is up to you — is still used the most for production environments. Slowly, we see the adoption of hybrid clouds as certain front-end workloads (as I like to call them) are considered to be moved to the public cloud (for the record, your local service provider is a public cloud also). Websites, worker roles and such are candidates, but the data mainly stays on premises for various reasons.

One of the things I do like to do is discuss how I effectively use the public cloud to my advantage in my work. Below are a few use cases you can consider for yourself.

I need a test/development/acceptance environment

IT professionals worldwide have been struggling with these types of environments for as long as I can remember. In an ideal world, your test, development and acceptance environments are three separate environments, mimicking the production environment the best they possibly can. In reality, most of us never have the resources available to do that, or we don’t even have the time and people to build and maintain it. Enter my first use case for Infrastructure as a Service.

I won’t go into the technical details, but I like to create copies of my production environment in the public cloud and give access to developers, test engineers and more in that environment so they can perform their work. The nice thing about this is that I can do this based on the current running projects and downsize or scale out as much as they like. After a project is finished, that environment can be shutdown (remember, it’s pay-as-you-go), and you don’t have to care further for the resources.

Developers, test engineers and quality control love this approach because it allows them to work on production data (while not being on a production environment), perform testing on scale and so on. This is something I couldn’t do a few years ago with the resources I had for those projects.

Patching, updates and upgrades

This is another scenario that every IT professional is very familiar with. Again, in an ideal world I would have a copy of my production environment to test any patch, update, upgrade, hotfix or anything like that before applying it to my production environment. But again, in reality, most IT professionals don’t have those resources at hand.

Enter the public cloud again. By running copies of my production environment that I can switch off (and even destroy) after testing, I can effectively test and document my change plan that I can hand over to the change advisory board in the company.

Disaster recovery testing

Quick question: How many times are you testing your backups and/or your disaster recovery plans? Weekly? Monthly? Quarterly? Maybe yearly or even never?

IT pros have reason enough for not testing backups: They don’t have the time and people available, they don’t have the resources, they can’t quarantine an environment to test and so on …

Everybody knows that in an ideal world, we should do those tests, but everybody also knows that it just doesn’t work out for most of us in reality.

On a blue Monday a while ago, I experimented with public cloud and discovered another use case for using public cloud resources. There’s more than enough advantages in this scenario: Use the resources you need and only for the time you need them. Restore your backups directly to the cloud and voila! It’s way easier to set up the fabrics (at least the configuration part of it, making sure it is quarantined), and it’s easily broken down, rebuilt again and so on.

How will you use the public cloud?

More and more IT professionals and architects are under pressure to take advantage of the public cloud, sometimes because management believes in the cost effectiveness and sometimes because they have purchased (a lot) of credits, among other reasons.

Whatever the motive is, if you think about your day-to-day work, I am sure you will find a few scenarios where you can use those public cloud resources, even without running production workloads over there.

The three examples above should give you a good starting point and help you effectively perform tasks that you should do but were neglected in the past and do them based on a copy of your production environment in order to mimic the real situation the best you possibly can.