What is the Cloud?

The cloud can seem like a mysterious, abstract concept. But what does it really mean?

Setting the Stage: Traditional Types of Hosting Environments

To get started, let’s talk about some more “traditional” ways that applications are “served” to users via computers. The most basic way is this: you simply install it on your laptop or desktop. You’re probably at least somewhat familiar with how that works. In the old days, it involved putting a CD-ROM or floppy disk in the drive. Nowadays it generally involves downloading the application from an official app store or a website. But either way, when you’re done, the application is living on your computer, and to use it you just open it up and it starts.

Now, let’s imagine we want that application to live somewhere else. Maybe this is a business application, like a database or email server, and we don’t want it living on every staff member’s computer, we want a central server that holds the data and to have everyone’s workstations link up to that server so that we’re all working with the same information. That’s a fairly common business need, and there are a bunch of ways we might do this.

The most basic way is what we might call a “shared” environment. We have a server (either our own in our office or one we’re renting somewhere) and we install all the applications we need to share on that server and configure all our staff workstations to talk to this server for data when they need to. Imagine this a little bit like when you shared an apartment with two other people in college or grad school. It works, but there’s definitely some “tragedy of the commons” that happens, especially around things like dishes and who’s responsible for cleaning the shared bathroom, right? The same idea is going to apply to our “shared” server. If one of the applications uses way more of the servers resources than others (maybe it really processor intensive, so it’s always hogging the CPU, or it uses a lot of bandwidth), the other applications are going to get crowded out — metaphorically, it’s that roommate taking too long in the shower who always makes you late for work. They’ll be slower to respond, crash more often, and cause your staff to bang their head against their desk with increasing regularity.

So, how do we fix this? The next step up in complexity is a tactic known as “virtualization.” In virtualization, we take our server, and pretend it’s actually four servers. Or six. Or however many different applications we need to run on it. And we assign a certain amount of the servers resources to each of those pretend, aka, “virtualized”, servers. So each one gets a guaranteed percentage of the server’s resources (in terms of CPU, RAM, bandwidth, etc). This is like upgrading from that 3-bedroom apartment with your college roommates to a single all to yourself. You are still in a building with other people, and that building still has some common spaces (like the elevator or the main lobby), but those aren’t yours to worry about because you have your own space inside your apartment. This is a much better situation in terms of guaranteeing each app can stand on its own. But it does have certain limitations. Eventually, there are no more apartments left in the building. Similarly, eventually there just isn’t any more space on the server. And if you have an app that needs more than you can give it while still making room for your other apps, you’re gonna need a bigger boat.

So what do you do? You buy (or lease) a new server, of course. You can do the same thing with that server, treating it as a “virtualized” one that splits up resources amongst a variety of apps. Or, you can “dedicate” a particular server to one app that is especially resource intensive. This is like getting it a whole house all its own. And you can expand out the virtualization/dedicated server models as much as you need. This is how companies come to have big server rooms in their basements.

What Makes the Cloud Different From Traditional Environments

So if that’s the traditional “lay of the land”, what makes the cloud different? I’ve heard the cloud referred to simply as “someone else’s computer,” but that isn’t really a good definition because it doesn’t capture what is different about leasing a server from a traditional hosting company vs. using Amazon Web Services or Google Cloud. What makes the cloud different is its “dynamism,” sometimes referred to as “ephemerality” or “disposability.” Now what does that mean? When you install a server in your server room or lease a server from a traditional hosting company, it is generally a long-running project. You are either purchasing a piece of equipment or paying a fixed monthly or annual lease. Either way, the intent is for that server to stay running as long as it works. And that is presumably because you intend to be running the applications you are installing on it for a long time, too.

Now, imagine that you have some applications you only need to run occasionally. Some examples: you have a dedicated application for payroll that only needs to run for a few hours every two weeks. Or you are a media company and you need to run a very high intensity application for processing super hi-definition video, but only once at the end of each project. You could run these in a virtualized or dedicated server environment, but you’d be paying for a lot of down time. But with a “cloud” server, you can spin it up and down on demand. Now, when you need it, you have the server to run that application for a few hours, and when you’re done running it, you spin the server down and don’t pay for it anymore. How nice is that?

Now, it gets even more fun (for techy people like me): let’s imagine we have an application with a few moving parts. It’s got a big database that stores a lot of information in it, and then it has a “portal” that serves that information to users. That’s a fairly standard architecture for a lot of types of programs, ranging from email systems to financial software (all of which may have other components, too). Now, these different moving pieces may have different “intensity” levels — one may consume a lot of RAM, another may consume a lot of raw computing power or network bandwidth, for example. Further, they may “scale” differently with use: the portal may get bogged down faster by more users than the database, say. So here’s where the cloud comes in: we can run those components on different “cloud” devices, each optimized for the kind of work the component needs. Then, we can “scale” those cloud services independently of one another. So maybe we need 8 copies of the portal running to keep up with all our users, but only 3 of the database. Combining those two features (optimized infrastructure, scaled independently) is a little tricky/expensive in a virtualized of dedicated environment, but it’s exactly what the cloud is built for. And, when our workforce all goes home at night, we can scale down the extra copies so that we don’t have to keep them running 24/7.

Quick aide here: two other terms you may hear that are related to scenario we just outlined of a system with multiple components: “microservices” and “containers.” Microservices is the industry standard term that refers to those individual components — the database and the portal in our example. “Container” is a term for the way we usually run microservices. It’s a way of packaging up an app so that it can be ported around from physical server to physical server (the image is of a shipping container being carried from port to port). It’s a very “cloud-native” way of doing things because we can easily duplicate that container across multiple servers when we need to scale up or scale down.

So that is the promise of the cloud: it’s “on-demand”, meaning you have it when you need it and don’t pay for it when you don’t use it, it’s “highly scalable”, meaning you can add more copies of an app as needed and drop those extra copies when you don’t, and it’s “customizable”, meaning you can tailor the particular pieces of infrastructure you are renting to what you need for your particular application(s). That unlocks some major possibilities that were not really there for traditional models of deployment.

Why Does This Matter?

Of course, it also brings along some added complexities. The cloud adds a level of dynamism through the ability to scale resources up and down on demand that raises some interesting problems. Traditionally, with that server down the hall, you’d have a consistent “address” that the apps needing data could reliably call. It may have been a domain like “myapp.mycompany.com” or an IP address like “123.4.56.789,” but it was consistent and your apps knew where to go. If you’re spinning resources in the cloud up and down on demand, those addresses don’t stay put. So how do your apps keep track of where they are calling home?

Additionally, we want to have a handle on what is running on our resources. We generally frown upon bad stuff running on our servers, whether they are servers we own located in our building or servers running in someone else’s data center. The same applies to the cloud: we want our cloud resources to be used for our business purposes, not (unbeknownst to us) be used for mining bitcoin or sharing sketchy spam messages. Those things are both a waste of our resources (especially money), a hit on our company’s reputation, and a potential risk to the security of our employees/customers and their data. Bad all around. But if servers are spinning up and down all the time, how do we know what we should be watching for potentially bad stuff?

And finally, cloud servers have, by design, no way for us to physically access them. If there’s an issue with a machine in the server room at the end of the hall, our IT staff can literally go in there and work on the machine. Leased servers may or may not come with physical access, but since we are generally keeping them for a long time we don’t mind remotely logging in to do maintenance work or calling up the hosting company and asking them to take a look. But in the cloud, we may only need the server to run for a couple of hours to finish that payroll task, for example. Are we really going to ask IT staff to spend hours configuring it every time we do that? What we need is a different, more efficient, and more hands-off way of managing those cloud resources. We also probably want that method to enable quickly swapping/replacing resources in the event of a problem rather than asking our staff to do a lot of troubleshooting on short-running “disposable” resources.

Solutions exist for all of these problems (and plenty more we haven’t considered), but as you might gather, they aren’t the “traditional” solutions. We need new methods for what is referred to as “service discovery” (letting apps know about each other so they can communicate), “monitoring” (keeping track of what resources we have and how they are being used), and “provisioning” or “managing” (setting up and tearing down cloud resources). To address these issues, “cloud native” solutions have evolved. They can be perceived as adding complexity to the process of working in the cloud, but another way to think of it is that the cloud is a totally different model for running IT infrastructure, and a different model requires different tools. Either way, this is one of the big pain points for companies trying to transition to the cloud: you can’t just go to your existing IT team that is focused on traditional “down the hall” servers and say “Let’s go the cloud!” They are either going to need to learn a whole new way of operating or you are going to need a team that’s already trained in that new operating model. Otherwise, you’re going to just repeat the mistakes that teams before you have already made.

So What the Heck Does It Mean to Talk About Some Service Being “In the Cloud?”

So far we’ve broken down the cloud from a sort of “behind the scenes” perspective: how the cloud is different from a server in your basement, how it requires different tools to manage, etc. But if you aren’t on the IT team at your company, your primary interaction with “the cloud” may be through popular “cloud based” services like Office 365, Google Workplace, or Dropbox. Some of those services even come with apps you install on your computer or phone. So what gives?

When these services describe themselves as “cloud services,” what they mean is that the infrastructure they are themselves running on is cloud infrastructure. So while you may have Outlook or Google Drive installed on your local computer, those applications are talking to Microsoft and Google services, respectively, to do their work (like our traditional database system might have really been talking to the server down the hall to get all its data). When they talk to those services, they are talking to a “cloud service”, with all the tooling that we’ve discussed. What that means for you is this: your data is not tied to one particular physical server. There isn’t a literal server in the basement somewhere with all your emails on it that can be destroyed in a flood or a fire. Your emails in Gmail or Office365 are being stored in cloud-based databases that are replicated and distributed across a lot of different locations. This is both a scaling feature — the more people are using the service, the more they need to scale it out so that it still works for everyone — and a security feature — by spreading things around they can just about guarantee that short of a world-ending crisis, there’s little-to-no chance of your data being permanently lost. Does that make you feel better?

Summary

So we’ve now looked at the cloud two ways: first, from the behind the scenes perspective of how the cloud works at a technical level — it’s a highly dynamic, “on-demand” IT infrastructure that lets you spin resources up and down as needed, opening up a totally different way of deploying applications and services. Second, we looked at the cloud from the end-user perspective of what using a “cloud service” means for you — it means that your data isn’t tied to a particular machine in a particular location but is instead spread across a large fleet of infrastructure that is scaled to both match the needs of the service and provide redundancy for securing the data you’ve put in it. Hopefully this helps you make a bit more sense of what it means to discuss “moving to the cloud” (it’s more than just moving apps to a new server, it involves a totally different set-up) and what it means to be “in the cloud”.