Infrastructure as a Service is the most common, and often, the most compelling reason to move to Cloud Computing. Who wants to manage networks, servers, routers, firewalls, and UPS’? The most basic IaaS offerings involve Virtual Machines – instances of a physical server – with either fixed or dynamic and VM sizing options. The underlying physical infra is taken care of by the IaaS provider. The client consumes and pays for the usage of the virtualization of that infra. A key benefit of a virtualised infrastructure is the ability to deploy applications to multiple data centres and build architectures which are natively Highly Available. Cloud IaaS is essentially the virtualisation of a physical data centre.
AWS and other Cloud providers offer multiple VM sizes and OSs at fixed prices per hour, day, week, or month. The cost per VM rises as the amount of processor, memory, and storage increases. If you have a steady state application, you can buy a fixed term contract (reserve the instance) for 1 or 3 years; significantly decreasing the cost through an up-front payment. In a dynamic resource pricing the customer is charged a fee per unit of processor, memory, and storage which are more configurable and can afford more scalability than fixed-price IaaS offerings. There are CMP (Cloud Management Platforms) vendors such as RightScale, which can help firms price and place workloads into the more compatible Cloud platform.
CMPs may become more prevalent as multi-cloud deployments become easier to use and integrate. An example would be running infrastructure such as Active Directory and SQL based workloads on Azure, connected to and integrated with, workload business applications based on Java and Linux, running in AWS. Comparing VM pricing across Clouds is somewhat complicated. Azure has different definitions of virtual server resourcing, and even what constitutes a multi-data centre deployment, then AWS. This confusion is intentional on the part of Public Cloud providers.
IaaS Architecture
A key aspect of Cloud deployments of an IaaS application involves the creation of one or more server farms within multiple data-centres. This means built-in redundancy and high availability. Most server farms each contain high-density blade servers in order to fit as many physical servers in a single rack as possible. Racks are installed in numerous rows, each one having at least two redundant power distribution units and cables into the data-centre power plant. The power plant also has various power backup resources, such as UPS’, batteries, and backup generators.
Figure Typical IaaS architecture
Multiple pools of servers or server farms are often located in the same data-centre both for expansion and local failover due to maintenance or continued operations during a hardware failure. For most large cloud providers, secondary datacentres are also deployed, as a geo-redundant system for both maintenance and facility-level failure protection. The cost of the datacentre facility, heating and cooling, power, and operations personnel are significant enough by themselves so that choosing one or more Cloud providers can be financially and operationally prudent.
Shared within the racks, or nearby, are the disk and storage systems, often in the form of a SAN or equivalent storage system. The storage systems are normally scalable and independent of the server racks and utilize their own technologies to handle data de-duplication, thin provisioning, backup and recovery, snapshots, and replication to secondary datacentres. Modern storage features afford the cloud provider significant cost savings through technology innovations and the sheer volume and quantity of storage. These savings are passed on to consumers of cloud. These costs are often lower than anything an individual consumer could negotiate and deploy on premises.
Within each physical or blade server in a rack, the cloud provider will have a virtualization hypervisor such as VMware, Microsoft Hyper-V, Citrix, or KVM. The configuration of these hypervisors is normally hidden from consumer visibility by the cloud provider. A cloud provider has significant ways to share each physical server across multiple customers; one physical or blade server can host as many as 20 to 50 customer VMs, each one having its own OS, applications, and disk storage allocation. The cloud provider can use advanced hypervisor con- figurations to automatically scale up processors and memory as needed to the VMs based on workload and usage.
Additional tools give the cloud provider the ability to failover one VM to another physical server within the same rack, a separate rack, or even across datacentres, all without the customer even knowing the shift occurred. This is the promise of high VM availability. It is a perfect example of the technologies within the cloud architecture that benefit both the cloud provider and ultimately, through cost savings and reliability, the consuming organization.
Private and Public Clouds
Preconfigured and specific offerings, such as VMs; including processor, memory, and disk space allocated to each VM might not be the same between providers, so price comparison is not always easy. The key features you should be looking for are fixed or dynamic sizing, costs for expanding or increasing resources, and the ability to control your VMs through a web-based control panel and secure CLI access via encrypted keys. High-quality service providers will have an extensive self-service control panel that puts the consumer in control of the VMs, with the ability to reboot, resize, and potentially take a snapshot and restore them.
In the debate between Private and Public Clouds. Dell Inc, Oracle, IBM and other vendors offer private-cloud deployments, which are usually technology and client specific. They don’t offer the wide array of Java-Linux-Open source tools and open APIs offered by AWS; or the tool sets around SQL, .Net and various APIs one finds in Azure. Private Clouds may be more suitable for reasons around security, operational management access, targeted technology usage, or as part of a hybrid model with some assets deployed into a virtual private public cloud, integrated with critical systems within the private cloud. Both private and public clouds allow firms to exit co-location or data centre management, and access skills and improved infrastructure.
Table: IaaS cloud deployment comparison – Public vs Private Cloud deployments
| Feature | Private | Public |
| VM-based server | √ | √ |
| Selection of OS | √ | √ |
| Choice of VM size (CPU, RAM), storage/disk | √ | √ |
| Ability to dynamically expand resources (CPU, RAM, disk) as needed | √ | √ |
| Ability to configure load balancing, firewalls, and subnetworks | √ | √ |
| Ability to define backup schedule and perform self-restores | √ | √ |
| Deploy containers and micro-services | √ | √ |
| Self-service control panel to manage VMs | ? | √ |
| Self-service control panel to manage Containers | ? | √ |
| Provide OS patches and version upgrades | √ | √ |
| Ability to select from multiple backup and restore schedules and retention times | ? | √ |
| Ability to select from multiple tiers of storage performance (e.g., high-transaction solid-state disks, slower file-based storage) | √ | √ |
| Ability to manage multiple groups of VMs with separate administrators, operators | ? | √ |
| Ability to customize OS templates | √ | √ |
| Ability to customize metering, billing process, ordering/ approval process | ? | √ |
| Ability to install custom OS versions or customer-defined custom OS | √ | √ |
| Meet consumer-specified security controls | ? | √ |
| Consumer has visibility into security logs, real-time security threats, and activities | ? | √ |
| Consumer has detailed real-time view into cloud operating, statistics, metering, and performance | ? | √ |
| Ability to specify where data is stored (by country or datacenter facility) | ? | √ |
|
|
|
|
As the above table makes clear, there can be some significant differences between Private and Public Cloud offerings. Many smaller Private Cloud vendors will not be able to offer multi-Data Centre resiliency, best of breed and accessible security; but they might offer a greater ability to customise machine images at the OS level and deploy customised stacks given that the client should have more access rights and privileges with a Private Cloud deployment. With Private Clouds it is expected that you take on more management and operational duties and work with the provider in this regard. This could afford greater control and customisation of various IaaS aspects, but it also increases your costs and exposure. This is not to say that Private Cloud vendors will not have decent offerings, but only to state that a firm needs to use a checklist when making platform comparisons and ensure that their requirements are met and fully understand how much effort is needed from their side to manage and control their VM, container and App deployments.
==END