Becoming Hybrid: Selecting a Cloud Platform

All right, this is where things start to get more fun. To this point we’ve done a lot of talking about things NOT cloud platform related, including requirements gathering and environment assessment. This was necessary because it’s difficult, if not impossible, to ensure you make the correct cloud platform decision without understanding the requirements of your organization and what you’re working with from an application standpoint. With those items out of the way, we can dive in to the attributes of public and private cloud platforms that might make them appealing for use within your new architecture. The level of appeal, though, should be linked to the platform’s ability to meet your requirements and be less about the appeal of platform features themselves. There are interesting technical aspects of each platform to consider, so this should be one of the more enjoyable phases of the journey. Let’s get started by talking about the primary cloud platforms (or methods of consumption) available and what considerations might lead you to employ them in your architecture.

Platform Selection

There’s a lot to think about before deciding to place an application on one platform vs. another. For simplicity’s sake, we’ll focus on a few example discussion points that might appear during the requirements gathering phase and align them to the platform or approach best suited to meet these requirements. The items covered here aren’t comprehensive, but they should be a good starting point as you begin to assess which path forward is the most suitable.

Public Cloud

There are now a couple of ways to go about consuming public cloud services. The one we’re all most familiar with involves consuming these services natively as they’re offered from the provider through their own management console and tools. Underneath the hood, your applications will run on the software and infrastructure the public cloud provider originally intended them to. More recently, though, some public cloud providers have partnered with popular data center software vendors (like VMware) to run software within the physical infrastructure of the public cloud provider. The result is offerings like VMware Cloud on AWS allowing you to build a virtualized data center wherever you’d like, on infrastructure you don’t own, while maintaining operational consistency with what you run in your data center. First, we’ll look at these public approaches and examine which common use-cases they align best with.

“Native” Public Cloud

Here we’re talking about consumption of services natively within a public cloud provider like AWS or Azure as they are “out of the box,” including virtual machines, cloud storage, networking services, or managed services elements. Considerations that might lead you to select this approach include:

• The application requires a scale of deployment, global distribution, or level of elasticity you can’t provide within your own data center(s)

If scale and global distribution are important to your application, public cloud can be an excellent answer. You can deploy wherever your users are and scale as much as required to meet their needs, without investing in hardware and facilities yourself.

• The application will still function at an acceptable level if it’s not hosted physically near the applications and data in your existing data center.

If the application you’re considering placing within the public cloud has minimal dependency on applications and data running in your own data center(s), this can be a great option. If some communication is required, things can still work well, you just need to provision enough network connectivity between your data center and the cloud to meet these requirements.

• The application will be constructed using Platform-as-a-Service (PaaS) or Software-as-a-Service (SaaS) elements

Generally, if you plan to use public cloud managed services within your application, either in PaaS or SaaS form, you’ll typically be better off if you place the rest of your application there too.

• High availability of your application is handled at the application or database layer, decreasing the importance of hypervisor-based availability improvement mechanisms like VMware HA or FT.

The hypervisor hosts running natively in a public cloud environment are standalone, so if you’re accustomed to running a service on a single VM and relying on VMware HA to save you if there’s host failure, you’re going to be out of luck. If your application leverages load balancing or some other high-availability mechanism at the app layer, though, it would be a good candidate for placement in the public cloud.

• There would be little to no benefit if the underlying hypervisor platform and management tools matched the ones used in your own data center.

If you aren’t heavily invested in the VMware ecosystem from a tools and skills standpoint, and if you also don’t require single-tenant/dedicated infrastructure, why bother with a managed vSphere-based environment like VMC on AWS? Just run your application natively in the public cloud. The same goes for Microsoft-equivalent offerings.

“Operationally-Consistent” Public Cloud

For this approach, we’re going to focus on VMware Cloud on AWS, as this is the most popular offering customers are considering in this category. But the same general logic applies to any public cloud provider now offering a VMware-based platform hosted within their physical facilities. Considerations that might lead you to select this approach include:

• The application runs best in a vSphere-based environment, but you no longer wish to maintain this type of data center environment yourself.

VMC on AWS is a fully managed offering, which means you’re no longer responsible for providing, troubleshooting, or maintaining the hypervisor, network, and hardware layers. You’re also not responsible for providing the facility. If most of your VM inventory isn’t well-suited for public cloud deployment, but you’d like to realize these benefits, this type of approach can be a great fit.

• Your organization has existing investments VMware-related software and employee skillsets they would like to retain use of.

Although you’re no longer responsible for deployment and maintenance of the hypervisor and hardware with VMC on AWS, VMware administration skills are still useful here for day-to-day operation. And most software designed to work with VMware-based environments will still work when paired with VMC on AWS. This is one of the key benefits of this type of solution.

• The application would benefit from low-latency access to AWS services (S3, etc.) or other applications you are hosting in AWS.

If your applications run best in a vSphere-based environment, but you’d like to consume other cloud services (like cloud storage or network services) in the most efficient manner, this is a great path to choose. Since your VMC on AWS environment is located inside an AWS facility, services like S3, RDS, and ELB are literally right next door.

Private Cloud

Getting your head around the definition of “private cloud” and reconciling it with industry use (or misuse) of the term can be tough. The official definition says one thing, and each vendor seems to throw it around to mean whatever they want! To account for this, you’ll notice we used a practical definition of hybrid cloud in the first post of this series that states if we have a normal virtualized data center (without all “cloud” attributes) connected to a public cloud environment via network, we have a hybrid cloud. If we go “by the book,” though, a “cloud” should possess all the essential cloud characteristics as defined by NIST. These are:

• On-demand self-service
• Broad network access
• Resource pooling
• Rapid elasticity
• Measured service

With semantics out of the way, let’s talk about two of the primary approaches to “private cloud” and where their use might make sense.

Private-Cloud-as-a-Service

For this deployment model, we’re referring to solutions that provide both the hardware and software required to deliver a fully functional private cloud, with all essential cloud attributes, to the customer as a subscription service. One key example of this is Dell Technologies Cloud. This solution provides a VxRail-based HCI environment running VMware Cloud Foundation, which includes the vSphere hypervisor, vSAN storage capability, NSX software-defined-networking, and vRealize Automation as the cloud management platform, all as a single package. Considerations that might lead you to select this path include:

• Your organization would benefit from a true private cloud environment, but architecting, implementing, and managing this type of solution yourself wouldn’t be realistic.

When you hear “NSX” and “vRealize Automation,” you may not be envisioning a simple experience. And this is for good reason. It can be difficult to get all these components working together yourself so their use is transparent, as consumption of any cloud service should be. Services like Dell Technologies Cloud (with VMware Cloud Foundation) provide all this functionality without requiring you to deploy, manage or troubleshoot the underlying software or infrastructure. And this can be a very appealing route for many customers who want a managed private cloud on locally-deployed hardware.

• Outright purchase of the hardware and software components required for the desired private cloud architecture would not be desirable from a cost standpoint.

One of the intimidating aspects of private cloud is the amount of hardware and software required to make this deployment model a reality, especially if you’re calculating potential consumption over a period of years. With subscription services like Dell Technologies Cloud, you can pay as you go for both hardware and software, so costs increase incrementally with demand.

• A requirement exists to have infrastructure and data reside on premises owned/maintained by your organization.

This is one of the key benefits of private cloud. You get to experience all the benefits of a cloud while complying with company policies (or government regulations) mandating that you control the location of your data.

Typical Virtualized Data Center (aka “Not a Private Cloud”)

Finally, let’s talk about the good-old virtualized data center approach. Considerations that might lead you to retain use of your existing approach somewhat overlap with private-cloud-as-a-service, especially when it comes to possession of your own data, but there are some significant differences, as well. Some factors that may lead you to preserve the existing way of doing things include:

• You have no “need” for cloud-like attributes within your data center, like rapid elasticity, service metering, and on-demand self-service.

“Things are just fine the way they are, thank you very much.” If your organization doesn’t have multiple separate business units consuming IT services, and you don’t do much provisioning of new applications, the business value of a full private cloud deployment may not be there. And that’s OK. Just keep doing what you are doing. Cloud is not appropriate, or useful, in all situations.

• The application requires a hardware/software configuration not supported by public cloud solutions.

Does your legacy application require use of a USB dongle that contains licensing information? Yeah…you’re probably going to need to keep it where it is. For similar cases like these where the basic requirements can’t be met by one of the other deployment approaches, keeping things as they are is a good answer.

• Your software vendor “doesn’t support cloud deployment.”

Also known as “my software vendor doesn’t understand cloud, so it’s easier to say it’s not supported.” We all went through this during the early days of virtualization where software vendors mandated deployment of their software on a physical machine. If this is the case, it’s not recommended to fight it. Just comply. You may need their help if there’s an issue, and that’s probably most important to operation of the business.

Wrap-Up

Selection of the correct platform for hosting an application within your new hybrid architecture can be an interesting exercise. With many new offerings becoming available and reaching a point of maturity where their adoption doesn’t present a risk, it’s never been a better time to be a consumer of cloud services. However, just because new options exist doesn’t mean the existing way of doing things is wrong. The goal should still be to employ the minimum number of platforms to meet the needs of your applications and business. In the next post of this series, we’ll talk about approaches to cloud migration and which method might make the most sense. Should we directly migrate our existing VMs to the cloud, rebuild and selectively migrate our data, or refactor our applications from the ground up? More to come!