How to Understand AWS Services for On Premises with VMware Cloud for AWS for Hybrid Cloud
Executive Summary
- AWS is being combined with VMware Cloud for AWS to provide hybrid cloud capabilities.
- What this means for on-premises environments.
Introduction
AWS is becoming increasingly popular, but until very recently, there was an extra hurdle if you wanted to introduce AWS into your on-premises environment. And most of the infrastructure globally is by far on-premises. There are an enormous number of virtual machine or VMware instances on corporate data centers, and on-premises virtualizations are one of the ways that allow companies to leverage the cloud.
Our References for This Article
If you want to see our references for this article and related Brightwork articles, see this link.
The advantages of using VMware include the following:
“1. Cost Reduction: While most, if not all, of the remaining advantages, also contain the potential for cost savings, this deserves a mention of its own. Direct cost reductions come in the form of server consolidation, and operational efficiencies that are not available otherwise.
2. Optimize Licenses: Oracle and SQL Server are two prime examples of RDBMS products that license according to underlying hardware specifications. By optimizing the hardware, we can reduce the license footprint, while still gaining the other advantages listed here.
3. High Availability: HA solutions for Oracle and SQL Server databases are complex, costly, difficult to maintain, or altogether non-existent. VMware provides a lower cost, yet highly effective HA solution that is optimal for many workloads.
4. Recoverability: If your DR solution is for the database only, you are missing out on DR coverage for the rest of the application stack required to make that database work. VMware encapsulates the application stack and, when coupled with proper configuration and testing of replication, provides as close to perfect recoverability as any solution can get.
5. Development Process: Developers need systems and data that are like production in every way possible. When they get quick access to production-like development environments, development time is reduced, and features are more robust on release.
6. Test/QA: The optimum environment to test on is production itself. That can be risky, however, since the production system needs to keep your organization running. VMware allows you to provide an exact copy of the production environment to the Test/QA team without impacting your critical systems.
7. Deployment Flexibility: Do you want to move your database workload from one licensed server to another? Do you want the advantages of a private, hybrid, or public cloud environment? Do you want to create live datacenters that are thousands of miles apart, and be able to swing back and forth between them? VMware virtualization, coupled with stretch storage solutions from EMC can facilitate these options.
8. Security: Not only does VMware create a minimalized attack profile with its small footprint hypervisor, but also advanced security features like Trusted Execution Technology from Intel allow virtual machines to validate security down to the chip level.”
Changes Afoot on the On-Premises VMs
As we discussed in the book, there are many changes afoot with these on-premises VMs.
- The number of VMs is being reduced as containers are becoming more prevalent, and containers reduce the need for as many VMs. This reduces “VM bloat” and has the positive consequence of increasing server capacity due to containers’ lower hardware overhead.
- VMs are increasingly ported between on-premises and cloud, whereas in the past, they stayed on-premises. This trend intersects with containers, as containers are more portable than VMs.
AWS, Google Cloud, and Azure are based on Linux LXC, which is operating system-based containerization. A major contributor of containerization code to the Linux kernel was Google.
Yes, you heard it right.
Azure on Linux?
Microsoft Azure works on Linux! All clouds are based on virtualization, and every single server functions as an application server. That is a SQL database, NoSQL database, video broadcaster, and anything else. Cloud providers assign specific instances to servers in proportion to the resources they demand.
And here is the problem. Virtualization or containerization does not apply to SAP. Most of SAP’s products require their own server. The only choice is the physical location of such a server (cloud or on-premise).
This is why SAP’s inclusion of VMs and containers in the SAP Cloud are more of brochureware than anything serious that customers will end up leveraging.
And again, those VMs and containers are actually on AWS, Google Cloud, or Azure. With SAP not offering a PaaS and not doing much more than marking up AWS, Google Cloud, and Azure services by, in many cases, a factor of ten (as we covered earlier in the book).
Infrastructure Efficiency
Curiously, while VMware created great opportunities for infrastructure efficiency, because of the adoption of far lower quality infrastructure tools proposed to IT departments as “standard,” SAP environments suffer from deep inefficiencies. On SAP projects, the client always tells us to make changes in their development system or quality system. However, once we begin using the development system or their quality system, we find that the systems are useless because they are not maintained.
On SAP projects, it is widespread for all of the boxes are years out of synch with each other. If VMware were being used and used correctly, these old instances would be blown away and replaced by recent production copies. However, only some SAP components, like the SAP APO optimizer, can be placed on virtualization. This means that in SAP projects, it is commonly thought that a full system refresh is not possible, and instead, it seems these SAP environments are using some SAP tool to do a “system copy.”
The system copy tool that is used by recommended by SAP. And the outcome of this system copy tool? The result is all the boxes on SAP accounts are far out of date with production, and asking for a recent copy is like asking for the moon. As we have been told on SAP projects…
“It would be nice to make a complete duplicate of an SAP box, but it is not possible.”
This is odd because, on projects where SAP infrastructure tools are not used, this is commonplace. A new image can be made in less than an hour, yet for SAP customers controlled by the SAP paradigm, doing it is planned for weeks. For some strange reason, the SAP System Copy tool works within SAP.
Why would that make any sense?
VMware Versus SAP’s Horrid Infrastructure Tools
VMware copies the entire stack. SAP promotes customers to use SAP software over all other non-SAP software because the SAP software is “standard.” VMware is not standard. If SAP System Copy is the official tool for SAP, customers should implement it according to SAP consulting firms. After decades these SAP consulting companies and SAP “Platinum Consultants” will attest that the best course of action is to go 100% SAP. Anything can be critiqued as not SAP by stating, “it is not standard SAP.”
VMware benefits from being used by all environments and VMware as the company is the premier virtualization vendor globally, and thus know and are capable of all manner of virtualization that SAP is not capable of performing. This gets into an infrastructure efficiency question around what is called the SAP Basis. With Basis on SAP projects, everything seems to take so long and is so hidden. However, when one pops around AWS or Google Cloud, everything is right there, and one has transparency. The fact is that SAP infrastructure efficiency is very low. It is controlled by Basis resources, which are used to the SAP ways of doing things.
There is a growing chorus of companies with on-premises environments that would like to leverage AWS to at least some degree. In response to this, AWS introduced VMware Cloud on AWS.
VMware Cloud on AWS is a full VMware vSphere cloud that is deployed and runs on AWS. We have a screenshot below.
vSphere is VMware’s environment for hybrid clouds. vSphere supports many different types of workloads. (3D graphics, big data, HPC, machine learning, in-memory, and cloud-native) vSphere has been around for years and is widely used. VMware Cloud for AWS is an extension of vSphere for AWS.
Using VMware Cloud for AWS allows on-premises companies to leverage AWS more easily. This means that privately hosted VMware deployment in a data center. VMware Cloud for AWS brings AWS’s Relational Database Service (RDS) to these corporate data center customers. This is designed to make the transition to the cloud more accessible to customers. All the standard databases apply. However, it also allows AWS Lambda, Simple Queue Service, S3, Elastic Load Balancing, DynamoDB, Redshift, and much more.
This is a significant development, simplifying the speed and simplicity of managing the migration to AWS.
How AWS Supports the Hybrid Cloud
AWS begin in the cloud, and for the longest time, the argument was between cloud providers like AWS and Google Cloud versus on-premises. However, AWS’s value proposition has begun to extend to on-premises. Also, the natural connection is through the on-premises virtual machine.[i] This is a massive change in the value offered by AWS. When AWS extends its services into on-premises, it is now leveraging its software and not offering its hardware. A hybrid cloud is when workloads and data reside in both on-premises and the cloud.
AWS has clearly targeted growth into the on-premises environment. The following are a few more examples:
- AWS Firehose
- AWS EC2 or Elastic Computer Cloud
- AWS CodeDeploy
- AWS Storage Gateway
- CockroachRB/AWS RDS
Let us briefly get into each one.
AWS Firehose
AWS Firehose is used for hybrid environments to move the actual data to AWS. The VMWare Cloud on AWS provides a high-performance network through the Amazon Virtual Private Cloud (VPC).
AWS EC2 or Elastic Compute Cloud
EC2 or Elastic Compute Cloud’s console can be used to manage on-premises instances. This means that a single console can provide a company with a full picture of its management. It costs AWS very little to do this, but it makes it even more likely that that customer will enable more AWS services.
AWS Storage Gateway
AWS Storage Gateway can be used for backup and archiving, disaster recovery, cloud data processing, storage tiering, and migration.
This is covered in the following quotation from AWS.
“The gateway connects to AWS storage services, such as Amazon S3, Amazon Glacier, and Amazon EBS, providing storage for files, volumes, and virtual tapes in AWS. The service includes a highly-optimized data transfer mechanism, with bandwidth management, automated network resilience, and efficient data transfer, along with a local cache for low-latency on-premises access to your most active data.”[ii]
The AWS Storage Gateway works in conjunction with VMware (as one example) on the on-premises server. It then connects to the AWS SG service, which then enables the services on AWS.
AWS CodeDeploy
AWS CodeDeploy is a deployment service to compute services such as Amazon EC2, AWS Lambda, and on-premises servers.
This is covered in the following quotation.
“AWS CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during application deployment, and handles the complexity of updating your applications.”
CockroachDB/AWS RDS
Several approaches have come forward to manage this issue, with multiple databases or database copies being deployed in various regions in the cloud and on-premises.
For instance, both CockroachDB and Spanner are sold on the concept of “horizontal scalability.” This is very different from vertical scalability, which is more commonly discussed and is how large a database can become without losing its initial performance characteristics.
How Cloud Spanner compares to other database categories (according to Google).
Both AWS RDS and CockroachDB allow one copy of the database (called a node) to be on-premises, with other nodes of the database to reside in the cloud, with the nodes kept in synch and therefore to allow full distribution of the database. A combination of nodes makes ups a cluster. AWS RDS and CockroachDB can be used on the public cloud or the private cloud and, hence, are presented as supporting hybrid clouds. The difference between the two approaches is that AWS RDS employs a master-slave model, where one database is the master and copies changes to the slave databases. CockroachDB operates under a design where all the nodes are equal.
(Initial image from CockroachDB)
This places the node closest to the customer. For a company with an on-premises node, having a multi-node database like Cockroach DB in the cloud can serve users in regions where the company has no data center. This has a meaningful impact on speed and is a perfect example of one of the benefits of a hybrid cloud, even for companies that plan to keep their on-premises location or locations.
This “need for speed” is covered in the following quotation.
“This problem is compounded by the fact that latencies quickly become cumulative. If your SLAs allow for a 300ms round trip between an app and a database, that’s great––but if the app needs to make multiple requests that cannot be run in parallel, it pays that 300ms latency for each request. Even if that math doesn’t dominate your application’s response times, you should account for customers who aren’t near fiber connections or who live across an ocean: those 300ms could easily be 3000ms, causing requests to become agonizingly slow.
If you need a gentle reminder as to why this matters for your business, Google and Amazon both have oft-cited studies showing the financial implications of latency. If your site or service is slow, people will take their attention and wallets elsewhere.”
The big selling point of multi-node databases is the ability to keep an application up during a node’s failure. After the failure, when the node that failed is brought back up, it is automatically synchronized with the other functional nodes.
The CockroachDB website example shows a node as “suspect” in the upper right-hand corner of the user interface. Of course, with CockroachDB, one (or more) of the nodes can be on-premises.
Also, CockroachDB will allocate the traffic that would ordinarily be directed to Availability Zone 1 to Availability Zone 2. Client A is not directed back to Availability Zone 1 until the changed data from Node 2 and Node 3 (which would be kept in sync) is updated to Node 1. This means the database is “inherently high availability.” That is, no special configuration is necessary to make it high availability.
This is a simulation that shows how multiple nodes interact with one another.
We have been discussing this in the context of database failure. But it applies to the overall availability zone, as is covered in the following quotation.
“Individual datacenters and entire regions also fail, and many teams are caught by surprise when they do. To survive these kinds of failures, you should employ a strategy similar to the one you adapted for networking and availability zone failures: spreading your deployment to more geographies.”
In addition to unplanned downtime, this works the same way for planned downtime. This improves the ability to bring down a node for maintenance, bring the node back up, and have CockroachDB take care of it all. For those that use DropBox and synch across multiple computers, the principle is similar. All of the copying and synchronizing takes place without the user worrying about how that is done. All the user sees is that (after a few minutes if the computer is recently turned on and connected to the WiFi), the files on another computer are the same as the files on the presently used computer.
Although CockroachDB/Spanner is one approach, AWS RDS has a different approach, explained in the following quotation.
“DB instances using Multi-AZ deployments may have increased write and commit latency compared to a Single-AZ deployment, due to the synchronous data replication that occurs. You may have a change in latency if your deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones. For production workloads, we recommend that you use Provisioned IOPS and DB instance classes (m1.large and larger) that are optimized for Provisioned IOPS for fast, consistent performance.”
SQL presents a fundamental problem to horizontally scaled databases. This is the fact that the data in the database has to be available on a single server. Without this, it will not be possible to perform JOIN requests. However, with the cloud, either standard or hybrid, there are multiple instances or nodes of duplicate databases. This is explained in the following quotation.
“Relational databases scale well, but usually only when that scaling happens on a single server node. When the capacity of that single node is reached, you need to scale out and distribute that load across multiple server nodes. This is when the complexity of relational databases starts to rub against their potential to scale. Try scaling to hundreds or thousands of nodes, rather than a few, and the complexities become overwhelming, and the characteristics that make RDBMS so appealing drastically reduce their viability as platforms for large distributed systems.”
AWS RDS uses a master-slave copy scenario where one master is copied to the other slave nodes. CockroachRB, the open-source version of Google Cloud Spanner, is treating all of the nodes as if they are equal in theory. AWS outlines the problem with this in the following quotation.
“In a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy, eliminate I/O freezes, and minimize latency spikes during system backups. Running a DB instance with high availability can enhance availability during planned system maintenance, and help protect your databases against DB instance failure and Availability Zone disruption.”
The reason for this is there are have multiple master-servers; collisions of data will be unavoidable.
Also, performance on read/write will depend on the number of servers. With the master-slave design, that problem is eliminated. However, this means that the databases are not genuinely independent. They rely upon the master database. And the slave databases only provide read access, not write access.
Luckily, any database has about 5% of write requests and 95% of read requests. So, with the single master, you provide a full server only for write requests. If a change is made, that change is sent to the master directly (bypassing the slave). This is considered far more robust than the CockroachDB approach of synchronizing multiple SQL databases.
Notice in this graphic displays the standard master-slave database model. A Public Cloud contains the slave database, while the master stays in the Private Cloud, which is usually on-premises.
Both approaches support a hybrid cloud. And many people think the AWS RDS/Cloud SQL approach is more practical, but this may change as technology continues to advance. It should also be considered that this problem goes away if a NoSQL database is used. This is why NoSQL faster and has no problems with replications.
We know of many projects where NoSQL works like a real-time DB for application, and then data in parallel transformed into a SQL database. For programmers, NoSQL is more beneficial during run-time.
AWS & OpenStack and CloudStack
Up to this point, we have discussed using AWS services and software to control the on-premises environment. However, open-source cloud management projects like OpenStack and CloudStack allow AWS to be accessed and any on-premises resources. This ability to connect to any cloud and any on-premises resources from one UI is sometimes called a “single pane of glass.”
OpenStack is truly impressive. We recommend watching this specific video, which shows how quickly things can be set up in OpenStack.
OpenStack can control AWS, Google Cloud, and other cloud resources, and it also runs on VMware, as explained by VMware.
“VMware Integrated OpenStack is a VMware supported OpenStack distribution that makes it easy to run an enterprise-grade OpenStack cloud on top of VMware virtualization technologies. VMware Integrated OpenStack is ideal for many different use cases, including building an IaaS platform, providing standard, OpenStack API access to developers, leveraging edge computing, and deploying NFV services on OpenStack.”
What AWS’s Hybrid Strategy is Pointed Towards
With AWS pushing into on-premises, this means that AWS is not only offering services that run on its infrastructure but has extended its services to run on customer’s infrastructure. Some have argued that IBM and Oracle have the advantage when it comes to offering a hybrid cloud. This is due to IBM and Oracle already being on-premises in their customer’s accounts. However, neither of these companies demonstrates much of an intuitive understanding of the cloud. They do not offer the ease of use that AWS offers, and once you use AWS for on-premises, you can, of course, use AWS’s cloud services.
The Oracle Cloud appears to have similar issues to the SAP Cloud, as it shows low usability, indicating that, like SAP, Oracle is getting little feedback as to what should be improved.
Oracle has had a long time to figure out the cloud, and they don’t appear to be making progress. Oracle resources have continually told us to “try out the Oracle Cloud.” We have. And we do not want to use it. We suggest Oracle resources that indicate using the Oracle Cloud try it for themselves first before being frustrated when told it is not usable. One has to have the software to be part of the hybrid cloud future. AWS and Google Cloud do.
AWS offering for on-premises is an attempt to put a “straw” into on-premises environments.
That is, they will entice on-premises customers with free items (that cost AWS little to offer) that will make on-premises customers increasingly comfortable with the cloud. As time passes and as more AWS services are used, it will become increasingly difficult for these on-premises customers to justify investments into a more on-premises overhead.
(Graphic from the book Hybrid Cloud for Architects: Build Hybrid Cloud Solutions Using AWS and OpenStack)
This is the future desired state for IaaS providers. They see the hybrid cloud as an intermediate state to taking over the infrastructure of customers.
Elias Khnaser proposes this in the following quotation.
“The public cloud will host most workloads, and you will have just the most important things in the private cloud. So you are going to justify putting something in the private cloud versus putting something in the public cloud, as the prices fall as well.”
Their roadmap shows a large amount of collaboration to make the VMWare Cloud on AWS a success.
The caveat explained by House of Brick is that there may be restrictions. It may require a legal review by each Oracle customer to leverage this new offering due to licensing restrictions.
“From these indications, it seems like a strong possibility that the VMware Cloud on AWS is in compliance with the requirements of the Licensing Oracle Software in the Cloud Computing Environment document published by Oracle. We will be doing more internal analysis of this possibility, as well as consulting with our legal partners, and the legal teams of the clients we are working with. Once we feel confident in making a more definitive statement, we will do so at that time.” – House of Brick Technologies
Conclusion
VMware Cloud for AWS is a may of melding on-premises environments with AWS. This will improve SAP and Oracle environments as VMware Cloud for AWS can serve as a “straw” into these on-premises environments that not only provide access to AWS services but allow AWS services to be used to manage on-premises resources. The overall announcement of VMware Cloud For AWS is a recently announced product as per the time of this book’s publication and is something whose full effect has yet to be discovered.
VMware Cloud for AWS fits directly into the hybrid cloud, which is how different clouds and on-premises environments interact. Also, we addressed the topics of OpenStack and CloudStack, which allow the control of not only AWS but provide a single pane of glass on all resources (cloud and on-premises). AWS’s clear intent is to manage more and more of the customer’s overall stack. Currently, AWS has the bulk of its services towards the stack’s bottom (Network, Storage, Computer, Virtualization, and Operating System). Still, they will increase their top-of-the-stack services in the future.