Cloud servers: Hypervised, virtual, becomes elastic.

Besides clouds coming in different flavours (private, public, hybrid, as a infrastructure service, as a application delivery service), the basic cloud IT building block the cloud virtual server or machine also comes in many different flavours.  Or exhibiting a great deal of elasticity, based on cloud servers now typically having multi-core CPUs and workload hypervisors that can span one or many CPU cores with different operating systems or OS images.

This has been, of course, a regular feature of mainframes for many years ago, and was brought into mainstream server computing accessible for many more with mini machines like DEC VAX-series, UNIX-based workstations and, in the Nordics, Norsk Data Sintran based computers for instance.  Looking at the Intel-based server architectures with MS Windows Server OS that overtook these, one had initially 1 CPU (with one CPU core) associated with this one operating system, where the OS could multitask of shift jobs among databases and applications running on that one physical server. Thereafter Intel-based servers become multi-core, i.e. one server CPU having 2 or 4 processing cores, and the OS could work shift or load balance more easily among the server CPU cores once the OS became fully multi-CPU.

Yet another "workload management" shift came when VMware introduced their first hypervisor in 1999 (2001 for servers), meaning that one workload monitor or janitor, introduced between the server CPU core and the OS, could create virtual machines (i.e. VM) and task switch on the fly between different OS images and builds on the VMs one physical server. The VMs one one server could have different number of CPU cores, memory sized and hard disk volumes associated with them, as well as a mix of operating systems, images and configuration.  The VMs could also span CPU cores on many servers, leading to easier ways to do server load balancing, hot-cold or hot-hot fail-over configurations, and, not the least to reduce IT TCO and man-hours, provided a way to migrate and get away from previous 1 application or 1 database equals 1 physical server set-ups.

The introduction of workload and server virtualisation more or less paved the way for today's cloud VM servers and the move away from dedicated servers - per application or per customer install.  Without the development and introduction of proper OS and workload hypervisors like VMware, ZEN and KVM it wouldn't be possible to provision and multi-host customer servers and applications in a cost-effective way, and share available CPU core and memory space among many customer workloads.

After a rather lengthy historical background to cloud virtual servers or VMs, what makes up a cloud VM today?  It's not a fixed property for sure, as multi-core, hypervised server farms with enough memory can be configured and provisioned in a lot of ways.

Currently, the main service offerings for cloud VMs among cloud providers seems to be:

1. Fixed size, fixed price VMs: The standard fare of most cloud providers, offering fixed VM configurations with x number of VM cores, typically 2, 4, 8, 12 cores etc, a fixed size of VM RAM memory and disk space at a fixed monthly cost.
2. Building on this, some cloud providers also support different ways of doing on the fly VM scaling, i.e. adding more CPU cores, memory or disk space for a certain time if certain traffic or capacity thresholds are being met, or being able to load balance between VMs on different servers.
3. Smart servers, i.e. dedicated, single-customer servers with a smallish hypervisor, giving the benefits of hypervised and virtualized workload management, but on dedicated server for increased workload throughput or high-level security environments.
4. Cloud VMs can come with different service and availability levels , for instance best-effort (shared, best-effort throughput), reserved, protected or guaranteed VM capacity, 99,5% towards 99,9999% availability
5. Increasingly cloud VMs are offered in CPU core pools, where the customer signs up for a pool of CPU cores, for instance 8, 16, 32 or 48 and a given pool of VM RAM and hard disk space, and the customer can configure a number of VM capacities with different CPU cores from this CPU pool. Cloud VMs in this setting are typically billed by utilization hours or minutes per month, and can lead to some very cost-effective server or VM hours per month if managed properly and if one knows the cyclic workload that pool VMs are expected to handle.

With this basic overview of cloud VMs, I'll be looking at a the different, or not so different, cloud VM offerings from Amazon AWS, Rackspace, MS Windows Azure, Softlayer and others in an upcoming blog post.

EJ, 22.10.2013

Where does cloud-based IT services and delivery come from?

What are the origins of cloud-based IT services and delivery? The system and business development paths might be said to come from many sources, participants and movements over the years, but the two main ingredients I think are server or CPU core virtualization on the system level and the for ever developing business need for greater IT and service delivery flexibility.  Also there have been two distinct development paths at play; one coming from in-house server consolidation and cost reduction using server virtualization, the other from the hosting services arena where the move from dedicated servers to virtualized private servers (one OS serving many user or services instances) to proper virtualized CPU cores (one hypervisor layer serving multiple, properly walled-in CPU virtual machines with their associated OS).

Both development paths were seeking greater IT service delivery flexibility, one for the internal IT department and it's users, the other for the hosting service provider and service provisioning & production, and both achieved much improved TCO.

Going a bit further into the in-house development path, one traditionally had IT departments using servers for single tasks, i.e. file and print, database hosting, email server, firewall, as work separation made functional sense and CPU's couldn't carry greater work loads.  Beginning around 2002 with VMWare, physical servers could be virtualized, i.e. made to carry multiple work loads, depending on time of day or some basic concurrent task switching, and the server virtualisation movement or consolidation path was started once IT admins saw the server management and cost reduction benefits.  Most companies with a in-house data center or server farm would have migrated to virtualized, consolidated server platform by now.

In the Internet hosting arena, or outsourced IT services arena for that matter, the hosting space evolved from shared hosting (i.e. multiple web domains on a single or load-balanced server) or dedicated servers for some high-capacity work load environments into the ASP market (application service provider) to host and offer higher margin application hosting and delivery.  ASP loads were in most cases tied to core business hours, and ASP servers were left idling outside 08.00 - 17.00.  Also providing dedicated servers were costly, as these servers also typically were hard at work only during specific hours during the day - business hours if the server were covering business area service utilization, 17.00-23.00 or so if the services on the server were geared towards the consumer market.

For both ASP and dedicated server hosting, server and CPU core virtualisation came in as a cost saviour or allowed hosting companies to move away from costly one server for one application or customer environments, and into virtualized work environments were work loads could be shared or shifted between fewer servers throughout the day.  Also proper CPU and OS virtualisation meant greater work load control and configuration than VPS server, where one OS install and config were tasked with serving a range of use cases and applications.  Server virtualisation lead to virtualized server platforms and in due time to virtualzed data centers, that allowed for easier load balancing between servers and data centers for that matter.

With both corporate in-house servers and data centers being virtualized, as well as server platforms for hosters, and the evolved mind-set for virtualized IT service delivery opportunities that comes with this, the next "natural" step seems to be or are the move towards "servers or virtual machines as a service" in the cloud, either in a private cloud delivery mode or in a public cloud delivery mode.  Or a mix of the two modes in a hybrid delivery mode for cloud based IT services.

And that's the topic for the next post in this blog.