Why virtualized servers are like apples, and how they work

With fall around the corner here in the U.S., our thoughts at Google Cloud are turning to … baking. Apple pies, applesauce, apple crisps—we’ve got it all covered. 

Because, for us, when we think of apples, what comes to mind is virtualization, which is the way computer servers are divided up to be more efficient. No, really. Bear with us while we explain why. Most of the computers running the applications you use, like email and web browsing, are not just one computer. They’re a set of computers, divided up into virtual computers, also called virtual machines. (There are millions upon millions of VMs in the world, so you have an idea of the scale.) 

When this concept first arrived, it changed computing entirely. Instead of one computer in one physical box (remember those desktop towers we all used to have at work?), that one physical box could now hold multiple computers that members of the IT team managed through software (called a hypervisor). So the one computer that held all of the HR department’s applications and files, for example, could now also hold the finance team’s applications and files too, without having to buy another computer. Here’s where the apples come in: If you think of a single, non-virtualized computer as a single apple, virtualization is that apple, but sliced up. 

But what about virtualization in the cloud?
In the years since virtualization was invented, it’s come a long way, especially as the cloud has come into the picture. Now, each of those virtual computers (known as virtual machines, or VMs) don’t need to be managed by that special software on-premises, but can actually be moved to the cloud and managed there. So there are different ways a company might choose to move their VMs—usually containing most or all of the applications and data that actually run their companies—into the cloud. They might just move those apple slices as is from their grocery store package (on-prem) to a plate (the cloud). 

But they might want to update those servers to work better in the cloud and be more efficient, so people get the information they need easily and quickly. In that case, they may modernize the servers—so those apple slices might now be mixed with some cinnamon and baked into a pie. You can still make out the actual slices, but they’re different from raw slices and have different pros and cons. Or, the IT teams moving the virtual servers might go even further with changing and modernizing them, so now they’re applesauce. You can’t make out the individual servers, or slices, anymore. But they maintain the same data and information they had before, but that data can be used and accessed more easily and by more computers and users than before. 

What we find at Google Cloud is that moving those sliced apples into the cloud as they are is a good place to start. They’re familiar, and look like they did before, so it’s a successful first step in the overall move to cloud. From an IT perspective, it’s easier to keep managing those apple slices because you’re already familiar with them. 

But, eventually, your business might yearn for something beyond apple slices. And that’s when you have to start cooking a little bit. A logical step might be to turn those virtual machines into containers instead, which is somewhat akin to baking an apple pie. There are clearly similarities you can see between the virtual machines and your new containers, but it’s still different—and tastier. And, from IT’s perspective, easier to manage, since there aren’t as many separate tools to keep track of. Plus, containers let you pack even more applications in because you can use fewer computing resources for each container vs. those virtual servers you started with.

We see lots of different journeys to cloud and those are just two examples. For us, though, we like to help customers plan how they’ll get all those servers to the cloud. So no matter what you want to do with your “apple slices,” we’ll figure out the best recipe for you based on your goals, requirements and constraints.