Genesis Public Cloud versus VMware

In case you have a VMware background, which is a platform we used for well over a decade, we thought it prudent to describe the differences between the two platforms, and where they fit in the marketplace.

VMware

VMware is a virtual infrastructure platform, originally designed to keep legacy workloads (those that are not scalable and distributed) online, regardless of the state of the underlying physical hardware. Workloads can be migrated between physical servers and physical storage systems without interruption to the workload.

This requires shared storage that is connected to all servers at all times to coordinate the clustered access to the same storage hardware, which is not scalable (up to about 32 physical servers). This creates a bottleneck, but also creates management headaches, as well as various glitches that come up from time to time due to the shared nature of the platform.

Networking was designed to utilize the underlying hardware’s layer segmentation, and thus creates management headaches due to the platform’s configuration being reliant on non-VMware hardware configurations. So, VLANs are tied directly between the VMware hypervisors and the physical switches.

Provisioning of resources is typically done using the UI, but a PowerShell interface is available. VMs are provisioned similar to way that physical servers are provisioned. This is fine for legacy workloads, but creates unnecessary complexity when attempting to automate processes that require compute, network, or storage resources quickly and in fixed units.

Cloud

Cloud is a poor term for a distributed computing platform, where all infrastructure components are virtualized, including cpu, memory, switching, and storage. Cloud platforms succeed in providing a completely virtualized environment, hiding the underlying infrastructure from view of the user.

Being a distributed computing platform, there are many architectural design decisions that are very different from VMware, mostly due to the fact that distributed applications have different requirements than legacy workloads.

Legacy workloads are those that run on a single server and can only scale as big as the one server can be scaled. Uptime is dependent on the application’s crash-resistance as well as physical hardware’s uptime (including servers, storage, and switching).

Proper cloud workloads are distributed, meaning the application is designed to run on many servers and coordinate the balancing of operations within the application such that all servers are utilized as much as possible. When designed optimally, scaling can be infinite, although this is rarely possible in real world scenarios, and highly depends on the problems being solved.

OpenStack, AWS, Azure, and Google Cloud are all cloud platforms, designed for distributed computing. All of these have some level of hardware resiliency to simulate the behavior of VMware, but are far from capable of emulating the features entirely. This is due to the design choices made to optimize for distributed computing workloads rather than legacy workloads.

Systems administration is a complex subject, but includes some fundamental high-level components:: * Compute * Networking * Storage

People have spent time developing careers around each of these components since there are so many ways to choose the pieces available on the market today, including everything from cheap low-end components up to expensive high-end components, and every imaginable possibility in between. What’s worse is that the technology industry changes on a daily basis with new hardware, software, protocols, connectors, cables, configurations, etc., most of which are proprietary, making it nearly impossible to decide what to choose, much less where to concentrate education.

This is where cloud platforms shine – the abstraction of many of these components, eliminating the need to deal with the chaos that the tech industry has created. Cloud is a natural progression to simplify what has become unmanageable for most.

OpenStack

OpenStack was designed as an open source alternative to AWS’ EC2 (elastic compute) and S3 (simple storage service) platforms. Throughout the past 10 years of development, OpenStack has undergone vast improvements in capabilities, matching the features that most public clouds have for simplifying systems administration, including 100 projects that contribute features to the platform.

Companies who provide services on any cloud, or virtualized infrastructure platform, have staff to deal with the chaos of choices created by the tech industry. OpenStack requires the same due diligence, and that is where Genesis comes in.

Genesis has chosen OpenStack as its next-generation platform, in place of VMware, due to its acceptance in the marketplace, but also for its vast features that provide superb abstraction of the physical hardware.

Some benefits include (all of which are non-existent in VMware):

  • Entirely open source
    • all of OpenStack’s code is available on GitHub with the ability for anyone to join the development teams to troubleshoot and/or write new code or patches with a well-established review process. OpenStack is considered to be the largest open source project in existence.
  • Being open source, it can be installed anywhere
    • although we highly suggest you use Genesis to manage this process since it can be daunting due to the size of OpenStack and the number of tweaks that can be made.
  • Multi-tenancy
    • OpenStack is designed to provide Virtual Private Clouds (an AWS term) in the form of Projects
  • IP Address Management (IPAM)
  • Kubernetes support via the Magnum project
  • Continuous Integration and Continuous Development (CI/CD) focused
  • Object storage with S3 API compatibility
  • Scalable metrics collection
  • Prometheus metrics integration
  • Secrets vault
  • Separation of volume (data) management from compute management
  • Forward and reverse DNS management
  • Orchestration via HEAT or Terraform
    • these provide simplified configuration and auto-scaling of resources
    • Additional orchestration is possible using Ansible, Puppet, Salt, or Chef
  • Billing management for resources used in each project
  • CLI, SDK, API, and Web-based UI for all projects

Genesis manages the hardware selection, using best-of-breed vendors, but also tests configurations that are known to work well together. This eliminates the need for clients to decide on the physical components, as well as the data center configuration required, to support a platform.

For clients that need Kubernetes support, but do not want to deal with bare metal provisioning, the OpenStack Magnum project manages the entire process of creating a Kubernetes cluster in an OpenStack Project. This, along with native multi-tenancy, allows the creation of many Kubernetes clusters that are independent from each other, yet can be centrally managed. This provides for an environment where dev, staging, QA, production, and other environments can be provisioned on-the-fly as needed, secured at the project level, so all resources are isolated.