Cloud Concepts and Terminology
As a consultant who was working on Office 365 migrations shortly after it was released (well, renamed), I have worked on a log of migrations. Migrations are a always a project that can be difficult to manage if not done properly. As with any project, planning for a migration is extremely important. I’m writing this guide to provide guidance to consultants, IT workers, and IT Managers tasked with migrating companies to the Cloud.
You don’t necessarily have to follow these recommendations if they don’t match business requirements. Also note that it may be much easier to migrate to the cloud using other methodologies. However, an easier migration doesn’t necessarily result in a quality result. This guide, in my opinion, will allow a good balance of ease and stability after migration.
Because this is a very large subject, I will be breaking this into a number of posts to keep it from being too long. This initial post will cover some terminology and basic cloud concepts. If you would like a quick primer on what the cloud is, visit my post on Office 365 to get a basic understanding of the concept.
Why is it Called “The Cloud”?
In the beginning, the IT guys created network diagrams. And they looked and beheld that they did not care about the stuff that wasn’t in their network. And…okay, maybe I should stop writing about it like that (But it was funny, huh?). Anyway, when IT guys document networks, we have to account for the stuff that is on the Internet. Unfortunately, we really don’t know what the Internet “looks” like (Nobody really knows what the whole Internet looks like) and we can’t document it. As a result, the Internet is usually shown with a cloud icon like this:
Except that when IT guys draw things out on paper (it does happen sometimes) it doesn’t look that good. So when marketing guys were talking to IT guys (happens less than IT guys working with paper) the term “cloud” was used in the meeting about selling business quality IT services and infrastructure over the Internet and the marketing guys were like, “That’s brilliant!” and no one felt like trying to explain things to them (Thanks a lot, Jeff).
In short, “The Cloud” is a buzzword. It is not a remotely new concept. You’ve been using cloud services for years already. Think of your email address. Yahoo, Gmail, Hotmail, Live mail, etc. all follow the exact same “cloud” model, but provide their services for “Free.” On the Internet, free generally means, “We sell your information to pay for our service.”
At any rate, once Amazon, Microsoft, and Google started selling email, document sharing, server infrastructure, and collaboration suites using the same model as “free email,” but under a per-month or pay-for-what-you-use cost model, things in the IT industry started changing quickly, and the need for a different way of designing IT architecture became necessary. Suddenly, the IT architecture design documentation needed to map things in the cloud out to implement a more modern approach to business IT infrastructure.
Infrastructure Types
There are a few different “types” of infrastructure deployment that can be used these days. The three primary types are on-prem, hybrid, and cloud. There’s also the mildly confusing duo of public vs. private cloud. Each of these infrastructure types has some advantages and disadvantages associated with them.
On-Prem
On-prem is short for on-premises and refers to any systems that are under an organization’s complete control. In a traditional on-prem environment, everything from power to Internet connectivity are purchased and managed by the organization itself. A company that has a bunch of equipment in a data-center or a doctor’s office with a server in the closet and everything in between is considered on-prem. All responsibility for these systems rests with the organization, and if those systems fail they have to get them running again. If you want to have on-prem email you have to build and maintain and email server. You also have to have IT staff to administer this infrastructure. On-prem deployments are *expensive*. However, absolutely every bit of an on-prem deployment is under the organization’s control and they can make it work however they want or need it to work. The easy way of explaining this is that on-prem is expensive but customizable.
Cloud
Cloud solutions are the primary focus of this guide, and if you haven’t figured it out by now, I’ll spell it out more explicitly here. Cloud infrastructure is shared and standardized. In my Office 365 post I mentioned earlier, I compared cloud infrastructure to cake. If you want a piece of cake, you either have to buy a piece of cake from a bakery or bake your own cake. Baking your own cake is more expensive (in terms of your time and resources combined) but you get to have the whole cake and make it however you want, but you also have a *whole cake* and if you eat it all yourself you will get sick and possibly fat. Buying a cake takes less effort on your part because the cake is made by the baker, who then splits the cake up into individual portions. You get exactly the amount of cake you want, but you don’t have much control over how it looks and tastes. You’re also sharing that cake with however many people buy pieces of cake. With that example, an on-prem solution is like baking a cake yourself. Cloud solutions are like buying just a single piece of cake.
The typical cloud environment is developed entirely by a company that sells cloud services. They buy or rent space in a data-center, purchase equipment, pay utility bills, buy IP addresses, and all the other stuff necessary to have an IT infrastructure. They then separate that infrastructure into chunks that they can sell. The typical chunks that you’ll see most often are Compute (access to processors and RAM), Storage (drive space), and Connectivity (access to the Internet, VPNs, etc.). There are also different “types” of cloud service that can be purchased (I’ll go into this later). Each chunk of cloud infrastructure is sold to different organizations, and there is no way to easily control whether that data exists on the same hard drive as some other company’s data. In some cases, an organization may have one group of users’ data stored in a data-center in California while the rest of their users are in a data-center in Texas. But this reality is not apparent to end users or even IT administrators managing those users. Cloud solutions work regardless of where the data is physically located. In addition, all of that data is highly redundant and always available.
For instance, Office 365 has a Service Level Agreement in their contract with customers to provide 99.9% uptime or they will pay a service credit of up to 100% (depending on how much of an interruption occurred). Note, this is *per month*, meaning that downtime of 44 minutes in a month qualifies any impacted client for a 25% service credit. In reality, uptime is, on average, 99.97%-99.99% over the last 3 years. Now, it’s important to note that this number accounts for the whole of Office 365, which accounts for over 155 million users. For the most part, Office 365 failures don’t affect the entirety of those users. Some Office 365 cloud failures can last days or more, but only affect an extremely small percentage of the users that exist. For instance, early in 2019 there was a significant failure that prevented access to email for a number of users in Europe and the East Coast. That failure lasted 2 days, and each affected client effectively received a free month of service as a result. So living in the cloud sometimes means you have to wait for your cake fix because the baker’s oven doesn’t work (This analogy breaks down quick).
Hybrid
Hybrid infrastructure implements both on-prem and cloud environments together. In most cases, this just involves connecting the on-prem infrastructure to the cloud infrastructure that the organization has purchased. This is usually done with a Site-to-Site Virtual Private Network (VPN). In other cases, like with Office 365, the hybrid infrastructure is much more intertwined to allow full functionality between the on-prem and cloud environments. The most obvious example of this is how Exchange Online and Exchange Server work in a hybrid scenario.
Normally, Exchange Server likes to keep information for the people who use it to itself. You can’t normally view the calendar of company 1’s users if you work for company 2. You also can’t have company 2 receive emails with company 1’s email addresses (company2.com can’t receive emails addressed to company1.com). These limitations make it difficult for an organization to have some of their users in the cloud and some on-prem. However, with some careful configuration involving a special form of Federation and manipulation of send and receive connectors, plus some accepted domain tricks, it’s possible to make Exchange Online and an on-prem Exchange server deployment work together as if they were the same Exchange organization. Hybrid capabilities like this aren’t particularly common (and are almost all part of Microsoft’s push to get people into the cloud), but they are fine examples of what can be accomplished with a Hybrid cloud model.
Multi-Cloud
This is a weird concept, but one that bears mention in this post simply because it’s becoming more common. Multi-Cloud is an infrastructure strategy that involves using multiple cloud providers to implement a single business’s (or business partnership’s) IT infrastructure. This infrastructure takes advantage of more recent innovations and third party solutions that allow companies to take the Hybrid Cloud idea to merge infrastructure across cloud providers.
A single example of this would be if a company had their email services in Office 365, File storage in Amazon Web Services (AWS), and collaboration tools with Webex’s cloud platform. A setup like this is redundant, but we’re using this as an example. Sometimes companies have existing history with a specific software solution and they decide that they want to continue using that solution in the cloud. Multi-cloud strategy would allow a company like this to integrate the Office 365 suite with Webex for meeting scheduling and planning, then utilize third party tools or a VPN link to back-end file server infrastructure in AWS to provide file sharing services through the Windows Server Message Block (SMB) protocol (that’s what powers the traditional Windows file sharing functionality). This solution would provide a company with a complete, cloud-only solution that meets their specific wants and needs without relying entirely on a single solution provider.
More often, however, Multi-cloud is meant to allow businesses to take advantage of a specific cloud platform without having to deal with some of the disadvantages of that platform. A more realistic example could be something like this: A startup business wants to implement a SaaS offering that provides their clients with a secure business solution. The employees of the company have experience in different parts of the cloud. Employee 1 has a lot of Office 365 experience but no Azure infrastructure experience aside from Azure Active Directory, Employee 2 has some AWS infrastructure experience but isn’t experienced with user directory and federation techniques, and Employee 3 has a lot of knowledge with some of Google Cloud Platform’s Database capabilities.
This company has a couple of choices, they can choose to spend time and money training their employees to use a single cloud provider to develop the back-end infrastructure for their application or they can use Employee 1’s experience to build and manage the company’s email platform, then build an Azure AD based user directory for their application. Employee 3 can build a database structure for the application using Google Cloud Platform. Employee 2 can use his knowledge to build an AWS-centered server infrastructure that reads user data from Azure AD and stores application specific information in the Google Cloud Platform Database that Employee 3 built. With a multi-cloud approach this company can get to market in a fraction of the time it would take for their employees to develop the knowledge they need to build the same infrastructure in a single cloud platform.
Cloud Service Categories
So now that you know why it’s called the cloud and some of the different infrastructure strategies that are available, let’s take a quick look at what types of things are sold as “Cloud” services. Each of these are referred to with “as a Service” and represent different levels of responsibility shared between the business and the cloud provider. The levels are shown here in a descending list, with business responsibility levels increasing as we go down the list:
1. Software as a Service (SaaS)
SaaS solutions are fully packaged applications that provide a complete solutions to businesses. When using SaaS, businesses are not responsible for Hardware Infrastructure or Server OS management. Application controls are usually available, but are often significantly more limited than a comparable on-premise version of that software solution. Some SaaS solutions you may be familiar with include Office 365 (Exchange online, SharePoint online, etc), G-Suite, and Salesforce. Some SaaS solutions allow high levels of customization (Salesforce) or a single service (Exchange Online). SaaS solutions in the cloud have been a major part of business and individual Internet use for years. Every web-mail platform (Gmail, Yahoo Mail, Hotmail, etc) is considered a SaaS solution.
2. Platform as a Service (PaaS)
Platform as a service is an interesting cloud deployment solution. PaaS environments provide a full suite of back-end solutions designed to allow full application development. These Platforms are often used to create custom Line of Business tools and applications or full SaaS solutions that a resold to end users. Most people are not familiar with PaaS platforms because they are generally only implemented and used by software developers. PaaS solutions that are most common include LAMP (Linux, Apache, MySql, PHP) stack, .NET platform, and Ruby on Rails. There are plenty of other PaaS solutions out there, but they are always meant to provide the back-end infrastructure required to create custom applications.
3. Infrastructure as a Service (IaaS)
IaaS provides system virtualization, management, and deployment tools that allow businesses to build fully functional Virtualized infrastructure in the cloud. This includes Server OS installation and setup, Software Defined Networking controls, VPN connections to on-premises environments, and other back-end infrastructure tools. In essence, this level of cloud service allows companies to deploy server and network infrastructure in the cloud. The point of this level of service is to remove the hardware management burden from businesses. IaaS environments are usually deployed with redundant servers that the Cloud provider manages and controls. The business simply creates Virtual Machines and network infrastructure to support applications installed on those systems.
Keep Reading!
In the tradition of multi-part IT blogs, there’s supposed to be a part at the end that makes the thing easier to navigate, so here we go:
AC Brown’s Guide to the Cloud – Part 1 – The Basics
AC Brown’s Guide to the Cloud – Part 2 – Cloud Architecture
AC Brown’s Guide to the Cloud – Part 3 – Shared Responsibility Model
AC Brown’s Cloud Guide – Part 4 – Cloud Service Providers
