Picking the right words to describe cloud assets is kind of important

The work of any given IT department is remarkably broad. And within each functional team, vocabularies around technology can be quite unique. This is fine when different groups don’t have to work together much, but when they get together to solve problems, one great challenge has to do with making sure specific IT terms mean the same thing to everyone.

And if that isn’t challenging enough, take traditional IT terms and then figure out how they all translate into the ‘cloud’. I’ll give an example. Take the distinction between IaaS and PaaS. The way this is often described is that with PaaS you don’t have to worry about patching an operating system. With IaaS, this is the customers’ responsibility, not the cloud service provider’s. But the scope of cloud is much bigger than the VM example. And not understanding this can have serious ramifications.

Let’s say you go out into cloud console for your tenant. (This would be the place where you log in to spin up a virtual machine, for example.) Whether you like it or not, the very moment you spin up a VM in the cloud you’ve created the beginnings of a network topology. Not knowing this can cost you dearly later.

Cloud infrastructure is not just VM’s. There’s a whole world of storage, networking and compute services, too, which we often overlook as being IaaS. Why does this matter? Because knowing and understanding this is also the beginning of securing it. Consider where each of these pieces live in a traditional on-prem model, and what controls are in place to protect the confidentiality, integrity and accessibility of these assets. That same diligence has to be transferred to the cloud. For example, protecting your firewall configurations is not unlike protecting your security group configs on a subnet or VM instance.

Also, how do you track changes to these assets? Whatever diligence you apply in traditional IT models, this same diligence is required in the cloud. This includes reviewing and validating configurations on these virtual assets. Think about what would happen if any one of these virtual assets, like a subnet or a whole virtual network were to be deleted. Where would you be and what controls do you have in place to keep this from happening? And in the unfortunate case that it does happen, how would you know how it happened and who did it?

Because it is so much easier to set up infrastructure in the cloud, it is also that much easier to abuse said infrastructure either intentionally or unintentionally. Getting everyone on the same page around the vocabulary for cloud infrastructure is the beginning of fully understanding how to secure this environment. Let’s decide on our critical cloud vocabulary and make sure we all share the same deep understanding of the words we use to describe this environment.

Study both AWS and Azure for High-level Cloud Understanding

Recently, I’ve found it’s not enough to simply say, “I’m an AWS person” or “I’m an Azure person” when it comes to learning and understanding the cloud. The greatest benefits in learning surface from seeking a high-level understanding of cloud platforms, in general.

These two leading cloud providers, AWS and Azure, are distinct enough from each other, but fundamentally there are features that neither of them can avoid if they are going maintain market share, or simply be able to provide viable solutions to their customers.

When folks spin up a VM instance at AWS or in the Azure portal, they are likely to overlook a few critical things. 1) These environments are networks unto themselves, 2) Where you might’ve been operating a private cloud in the past, which is essentially a traditional data center, you’re now using a public cloud, and 3) Where you might envision you’re life getting simpler with cloud, it’s actually getting more complicated.

When folks spin up a VM instance at AWS or in the Azure portal, they are likely to overlook a few critical things. 1) These environments are networks unto themselves, 2) Where you might’ve been operating a private cloud in the past, which is essentially a traditional data center, you’re now using a public cloud, and 3) Where you might envision you’re life getting simpler with cloud, it’s actually getting more complicated.

With point #1, AWS and Azure both provide ways for their customers to create networks. There may be slight differences in how these networks are set up, but the concepts are the same. Azure calls theirs virtual networks and AWS describes them as virtual private cloud or VPC instances. (Oracle calls theirs virtual cloud network or VCNs.)

Call it what you want, it is a network. And if you don’t know that, you’re likely in for a world of hurt later when you need to scale or secure your cloud environment. And if you can’t do the same thing in AWS as you do Azure on this front, then you don’t really understand the fundamentals. And if you try another cloud platform and find you simply can’t fine tune networks the way you like, then you’ll know why AWS and Azure are leaving them behind.

With point #2, you are now participating in the use of a public data center. This means it is exceedingly easy to expose your services in ways you maybe didn’t intend. Take a careful look at how AWS and Azure overlap or don’t overlap in their approach to exposing services. If you only ever had you head in AWS you might assume that certain settings are always set to be public and the same might be true of Azure.

They’re both evolving from month to month on their approach to how they handle default public exposure, so I won’t go into too much detail. But if you work with them simultaneously when you’re learning, you’ll make fewer assumptions and as more critical questions than you would otherwise.

With point #3, generally speaking, your life as an IT professional who uses the cloud to build IT infrastructure, services and to take advantage of pre-built applications, is about to get a bit more complicated. Why? Because now in addition to all the systems you need to support locally, which help you move data in an out of the cloud, you need to manage the cloud as well. And if you’re using a service that “manages itself” you need to manage perpetual change just to keep up with it.

Understanding integration in both AWS and Azure will help you make fewer assumptions about the way things should be and, again, think critically about the fact that much of the design is actually up to you. You can’t afford to turn of your critical thinking skills. Having the courage to ask tough questions is even more important than it has been in the past. So if someone asks you, should I learn AWS or Azure, or (name your favorite alternative), the answer should be “yes”. There is no “or” if you’re going to be the master of your own cloud destiny. 🙂