The Realities and Opportunities of Cloud-Based Compute Services That Your Cloud Provider Will Not Tell You About
Cloud pioneer and long-time CTO David Linthicum covers public cloud computing processors, which are usually referred to as central processing units (CPUs), how to pick the platforms needed to operate those processors, and how to obtain the best value from your cloud provider.
This chapter is from the book
This chapter is from the book
This chapter is from the book
There are no secrets to success. It is the result of preparation, hard work, and learning from failure.
— Colin Powell
Now that we’ve covered storage, let’s cover compute. This topic is a bit more complex. In addition to choosing public cloud computing processors, which are usually referred to as central processing units (CPUs), we must pick the platforms needed to operate those processors. The platforms themselves require choices, including operating systems, memory configurations, network connections, and even the need to define some physical storage that needs to exist.
In this chapter, we focus on what these services are, how to understand them, how to pick them, and how to obtain the best value from your cloud provider. We also look at some concepts you need to understand before you pick compute services. These concepts include how cloud hosting works, and how to understand your own requirements so you don’t under- or overbuy. Additionally, we discuss how to find the best deals with known discount approaches, such as leveraging reserved instances or leveraging processors that are considered “off-brand.” Finally, we review some traditional options that we often forget about in the haze of cloud computing migrations. Again, the focus is to provide you with inside information on what to leverage and how to think pragmatically about cloud-based compute.
The Trade-offs of Multitenancy
When you leverage CPUs via a cloud service, you typically share those CPUs with other cloud computing tenants. You get the services that you contract for, but you’re not the only client leveraging that physical resource. You could even be multiplexed across many virtual compute servers and be serviced by several CPUs, memory configurations, and input/output management subsystems.
The problem is that you really don’t know what goes on behind the scenes in terms of how a public cloud provider deals with its tenancy. Providers debated extensively about multitenancy approaches when cloud computing first started. Multitenancy choices in those days were—and still are—“share all,” “share some,” and “share nothing” approaches.
My first cloud consulting firm focused on creating all three types of multitenancy architectures for new and existing software companies looking to become SaaS cloud providers. They needed the ability to deliver multiuser types of services, as well as the ability to deal with resource sharing that includes CPUs, memory, storage, and so on.
It was not unusual during the early days of cloud computing to have traditional software companies approach multitenancy in rather unorthodox ways—especially when they received requests from new or existing clients that wanted to be on a SaaS or other type of cloud. Rather than leverage a true multitenant automated platform, many traditional software providers simply bolted a new server onto the rack of their so-called cloud provider services. They would assign a name and IP, and the client leveraged only that server while leveraging the provider’s “cloud.” This is a classic example of a traditional service disguised to look like a cloud service.
Today, most of us recognize this “bolt-on” model as silly and wasteful. At the time, most clients never understood this was happening. While it’s not a true multitenant architecture, it was an approach that many used to break into cloud computing, and it formed many cloud users’ understanding of a “share nothing” approach.
Although we could pick apart multitenant approaches as we did during the early years of cloud computing, they worked for the most part, and the issues that arose are long since resolved. Most public cloud providers now offer solid multitenant services that optimize performance, even though they multiplex your use of a public cloud across many different physical resources. There are still some multitenant trade-offs to consider:
Performance can be “bursty.” In many cases this is the bursty nature of most Internet connections, in that performance will speed up and slow down based on the demand on the network resources. You can see the same type of performance patterns by looking at the performance of a cloud platform. When asked to do processor-intensive tasks, certainly when there’s not enough memory and CPU power allocated, you’ll see performance that seems as if it’s starting and stopping.
It’s difficult to predict the performance of deeper types of platform use, such as threading. A thread is a flow of execution of tasks found in processes, also called a thread of execution or thread of control. Most advanced operating systems support threading. Here you will see many of the same issues occur as previously discussed, including bursty performance. Also, launched threads may not succeed if the processor was busy for some reason, or if the application expected the thread to return faster than it did.
Many applications that are ported to the clouds using a lift-and-shift approach where a minimum amount of redevelopment occurs. Because the application was not developed and tested on a multitenant platform, its performance can be unpredictable.
Of course, the severity of these trade-offs depends on the cloud provider you use and how the provider specifically approaches multitenancy. These issues need to be worked out beforehand, worked around, or properly fixed after the migration. Many of these trade-offs result in more migration costs for enterprises.
The Realities of Resource Sharing
When it comes to understanding multitenancy, it’s important to understand that all public cloud providers have a different approach to tenancy. What one public cloud provider says may not apply to other providers—even if they say basically the same thing. Public cloud providers consider their approach to multitenancy proprietary to their IP. Although you get some overviews around how a provider approaches tenancy, what occurs in the background or in the native public cloud system that you can’t see is really what determines how the provider carries out multitenancy.
In some cases, you can insist that the public cloud provider reveal how multitenancy is carried out, typically around compliance audits that you need to support. For example, say you’re a government contractor who plans to place government systems on a public cloud provider. These systems may, as part of an audit, insist that the contractor and provider reveal the mechanisms behind multitenancy for a specific cloud they will leverage. You’ll find that some cloud providers are candid, having had to address this issue before. Others are not as forthcoming. If the provider won’t reveal the specific details and mechanisms behind how it approaches multitenancy, and if this won’t meet the needs of the audit, you need to determine that up front or face having to move off that cloud because it was later determined to be noncompliant with an audit.
The moral of this story is that you determine these details up front. Understand what the requirements are for your specific situation and if you need to have a detailed understanding of how the multitenant system manages resources. Figure that out before moving assets to that cloud.
The good news is that, for most use cases, high-level explanations will suffice. In the cases with special audit requirements, it’s usually best to leave these systems in the enterprise data center and save yourself the hassle.
Putting the legal issues aside for now, it’s helpful to understand the basic approaches and mechanisms that public cloud providers leverage for their public clouds, especially compute. These include
Shared is often the default and thus the approach that most cloud customers use, no matter whether they understand the concept or not. Shared means several public cloud computing accounts may share the same physical hardware. For most uses, this type of multitenancy approach is fine, and you won’t even know you’re sharing resources. However, performance issues such as the trade-offs we’ve described previously will come into play if you have special high-end requirements. As you may have guessed, a Shared model is typically the least expensive because you use fewer physical resources, all of which are shared. Figure 3-1 shows what the high-level architecture looks like, where a single physical resource is shared by many tenants. Note: The way you share resources—and how they are shared—is specific to the cloud provider’s multitenant services.
Dedicated Instance is when your instance (that is, running your applications) runs on single-tenant hardware. This approach typically works better for special higher-end requirements, such as applications that tend to saturate the CPUs and other resources. For all practical purposes, it’s as if you host your application on your own server that nobody else uses. Of course, this approach is more costly than the Shared model because you leverage physical hardware that others cannot leverage. Also, you rarely know the physical location of hardware. The provider allocates different servers for your use, and you are typically not assigned a dedicated server.
Dedicated Host is when your instance runs on a physical server with all its capacity dedicated to your use. You have complete control over this isolated server. Functionally, it’s as if you purchased a server, installed it within your data center, and now have exclusive use of it. In many instances, the cloud provider may even let you know where it’s physically located, although those policies differ from cloud provider to cloud provider. This is the costliest of all the sharing options listed here.
)
FIGURE 3-1 Resource sharing for most public clouds means that you share physical resources with many tenants or companies like yourself that need to access compute services. This is often the least expensive approach because the cloud provider can share a few resources with many tenants. As far as the tenants are concerned, they leverage a virtual resource that functions much like a dedicated server.
Costs Versus Consistency
The trade-off with compute models comes down to cost versus consistency. You either pay less to leverage physical servers that are shared with others, or you pay more for the luxury of dedicated hardware to ensure greater consistency. Figure 3-2 depicts the typical cost curve that most enterprises will encounter when purchasing compute resources from a large public cloud provider. None of this should be shocking, considering that as public cloud providers’ costs go up, they will pass the cost for the additional hardware resources, such as storage and compute, on to their customers.
)
FIGURE 3-2 As a rule, costs rise as you share fewer resources in the cloud. However, at some point, the cost begins to level out but never becomes completely flat, or diminishing.
The real question then becomes, What would compel you to use nonshared resources, and how would it even justify the extra costs? In truth, many of those who insist on dedicated instances, and even those who reserve a physical server in a public cloud, typically have no need for them. The extra cost is a classic waste of money.
In many instances, customers pay much more to use a public cloud provider’s dedicated resources than if they owned their own physical server, even with data center rental and maintenance factored into the equation.
In too many instances, I see this become a kind of ego play, in that someone wants to elevate the importance of their workloads to a point where they lose sight of the real goal, which is to get to the true value of cloud computing. The objective is to pay less to securely share most resources and still gain the soft values of cloud computing.
There are a few instances when it’s the right move to elevate workloads and data, when the needs for consistency and control outweigh the cost factors. However, most arguments for uninterrupted performance or security concerns with shared resources prove unfounded or, more often, available within a shared model option. We’re well into our 15th year of leveraging IaaS clouds and pretty much understand what shared and nonshared resources can do, and the cost trade-offs.
Despite the history and provable facts, I still see enterprises demand and deploy nonshared resources for the consistency and control reasons just mentioned. This will lead to a sizable reduction in the value that cloud computing brings to the business. In many instances, it will then lead to cloud computing having negative value that is completely avoidable. Carefully consider the business case and the technical realities before deciding that your workloads are much too important to mingle with others.
Cross-Partition and Cross-Tenant Hacks
It was not long after cloud computing became a thing that alarms began to sound around the possibility that other tenants could reach into your compute instance and grab your data or interrupt your processing. This is called a cross-channel attack, a cross-partition attack, or a cross-tenant attack. For our purposes, we’ll use the terms interchangeably.
These “cross” concerns came from some valid realities, including the fact that you are indeed running on the same physical servers. It’s logical to assume that if something were left misconfigured or a vulnerability overlooked that could be exploited, then someone or some program could purposefully reach through a logical partition and cause problems.
Experiments proved that this scenario could potentially occur, but only if there were a vulnerability on the multitenant system that was known to black hats, and thus could subsequently be exploited. The chances of that occurring, even though there was a chance, were much less than other security risks that typical applications and/or data sets encounter on a traditional platform. So, by moving to cloud, you lower your security risk. The chances that you’ll be hacked tenant-to-tenant are pretty much nonexistent.
The real issue here is that multitenant just seems scary. Your application that processes sensitive, often proprietary data, runs within the same memory set and CPU as other companies’ applications and data. Your cotenants could be a competitor, an illegal business, or the government.
Figure 3-3 depicts the types of attacks that tenants find of most concern, namely, a tenant being able to reach into the workspace of another tenant running on the same physical server. Or a tenant reaching across to another tenant running on another physical compute server.
)
FIGURE 3-3 In the early days of cloud computing, many feared cross-channel, cross-tenant, and cross-partition hacks, or reaching to compute and storage spaces controlled by another tenant—either within the same physical CPU and platform services, or between physical CPUs and other platform services. Much of this concern has been eliminated, but it’s still wise to ask your public cloud provider how this will be managed.
Cross-channel attacks are a false concern for the following reasons:
The public cloud providers became aware of this concern years ago and built specific security measures into their systems to isolate resources used by specific tenants. Of course, providers all do this differently, but they all have their own mechanisms to detect any cross-channel intrusions.
The data that resides within each tenant partition is encrypted at rest and in flight. If, for some reason, a tenant could reach into another partition, the data is worthless given that it’s encrypted. Most public cloud providers encrypt everything to remove this security vulnerability. You maintain your private key, and even the cloud provider can’t see your data without it.
The nail in the cross-channel risk coffin is that tenants can’t launch a machine instance on a specific machine, say, a specific machine where their target runs their data. Lacking the ability to choose the physical server that the tenant will run on, at least in a shared multitenant deployment, means no tenant can leverage standard approaches to access other tenant instances, such as making use of Level 3 memory cache exploitations.
Nothing I say here pushes these possibilities off as a nonthreat, only that there are many other things that should rank higher on your list of concerns in terms of cloud security. In this instance, it’s okay to say, “Nothing to see here.”
Keep in mind that when you play the cloud security game, it’s not about creating an invulnerable security layer. Ultimately, nothing is invulnerable. It’s about removing as much risk as you can, and then prioritizing and paying attention to the more likely threats.