Going cloud, going offshore - it's all about IT automation

Two major trends impacting enterprise IT worldwide is

• The move towards cloud-based IT service delivery (from dedicated or virtualized server deployments inside customers data centers or with 3rd party DC operators), and
• Global sourcing of IT operations and service delivery, or off-shoring when handing over IT operations and delivery to "offshore" IT suppliers

Both of them are concerned with or aims to, I would argue, reduce IT cost through increased IT automation.

The journey from legacy, classic server environments to cloud-based IT service delivery models can be depicted as in fig 1 below.

Here, various IT systems with a enterprise customer or let's say with a IT service provider, are in various stages of being run on classic, legacy IT environments on virtualized server platforms or maybe has made the leap to a VM IaaS/PaaS setup with a cloud service provider.  

For legacy IT environments, typically one IT system are running on a dedicated hardware and database platform, and IT budgeting is usually done based on CAPEX upfront, 3-4 years write-off period.  Legacy IT environments would be based on IT systems popular 10-20 years ago, i.e. SUN servers running Solaris, HP servers running HP-UX, IBM servers running AIX etc, even pre MS WinServer pre 2012 server on COTS Intel servers.

Some of these IT systems or business applications running on them would be able to make the leap onto virtualized IT-platforms, either as part of a major server consolidation projects that most enterprise IT departments would be running since the dot.com era. Leading candidates or candidate of course being VMWare, with freeware hypervisors like KVM and Zen, additional hypervisors form Citrix, Parallels and others being utilized also.

When a critical mass of virtualized servers were reached, the creation and utilization of server instances could be viewed as OPEX and on a per month, week basis, the cost of each new VM being incremental.  Also when a critical mass of CPU cores on a number of physical servers were reached, it was each to provision VMs from a pool of available CPU cores, over-commit on VM cores that were scheduled to being put into production or assign cores to VMs for dedicated VM resources and instances.  At a higher price than pool-VMs. 

With virtualized servers, server or VM provisioning and configuration could be dramatically automated and lead times for VMs were/are dramatically lower than installing dedicated, physical servers - seconds and minutes versus days and weeks.  VM re-configuration could also be done on the fly with "instant" re-sizing of VM CPU cores, memory and disk-space changes and allocation.  A significant higher degree of automation and IT-production levels were achieved with virtualized servers, leading to lower IT cost overall (per VM, per IT employee, per production unit etc).

Some IT workloads and IT systems has made the transition onto private or public cloud infrastructures, leading to a even higher degree of IT automation than traditionally available from both virtualized or legacy IT environments,  Between highly virtualized and automated IT environments and cloud based IT-delivery there aren't really a clear cut switch-over or demarcation line, but I guess cloud based IT delivery are seen as having a higher degree of auto-scaling and capacity on demand than a single location VM-environment.  Plus a higher degree of self-serve support and options for IT management than a on-prem solution.  IT departments did server virtualization for themselves and to meet corporate cost targets, while cloud IT delivery are available to a wider audience with an associated price plan, service catalog and SLA accessible in a way not always seen with corporate IT departments.

For many end-users, business applications delivered as a SaaS-solution, represents state of the art in automated IT delivery, "just" insert the data and press play. While cloud IaaS or PaaS-delivery would be state of IT-automation for IT-departments and developers.

In many ways, outsourcing and offshoring of IT operations and service delivery, can be seen as an IT automation drive also.

If we apply a onshore (on-prem) and offshore dimension to illustration above, we have a lineup as depicted in figure 2.

Corporate IT systems are, in addition to various state of "physical to cloud"server platforms, in different states of being managed and operated onshore locally (on-prem with customer, with 3rd party local IT-provider) or with a offshore, seen from the customers point of view, IT provider performing day to day operations, maintenance and incident management.

These day to day operations and maintenance work are being performed inside or based on well-defined work packages and by personnel that has specific module certifications on various Microsoft, Oracle, SAP, HP, RedHat, EMC/VMWare etc IT platforms and systems.  In turn this means that IT management are removed from specific personal skill-sets or knowledge, and one set of work tasks lets say on a Oracle DB can be performed interchangeably by different Oracle-trained personnel, and one reaches a new level of IT automation where the personal/personnel factor is taken out of the IT operations equation.  Work tasks gets increasingly specific and well specified, customers avoid customer specific adaptations and developments as far as possible, i.e IT work and delivery gets boxed in and turned into work modules specified down to the minute.

Put another way, part of the cost benefit of offshore IT delivery are down to the modularization of IT work tasks and IT operations that offshore providers have achieved compared to in-house IT,

Thus the transition B in figure 2 is part of an overall mega-trend that uses IT automation to reach lower IT production costs, and it will be interesting to see how the IT service delivery business unfolds between offshore IT-providers and cloud-based IT delivery.  Or more likely, how offshore IT-providers use cloud-based delivery options (their own private cloud services, mix of public clouds) to reach new IT automation levels and increased market share.


Erik Jensen, 19.11.2014

The 5-3-2 definition of cloud computing. Or is it 5-3-3?

One of the benefits of cloud computing or cloud IT services is that it got a fairly good definition from quite early on.  As opposed to a lot of other IT trends, developments and phenomena (Big Data, UGC, augmented reality anyone?).

The main definitions for cloud IT are based on the following 3 main principles or frameworks:

1. The "5 Essential Characteristics of Cloud Computing" by the National Institute of Standards and Technology (NIST)  in the “Definition of Cloud Computing” publication, namely
• On-demand and self-service
• Ubiquitous network access
• Location transparent resource pooling
• Rapid elasticity, and 
• Measured service with pay per use.
  
2. The three service stacks or the three service delivery methods for cloud IT, namely: 
• Software as a Service (SaaS): Applications delivered as-a-service to end-users in the fashion of the 5 main characteristics listed above
• Platform as a Service (PaaS): System, development and service platform delivered as-a-service, again based on key principles listed in 1, and
• Infrastructure (IaaS): Basic or fundamental IT services like processing, storage and networking delivered and utilized as-a-service, without the need for local HW install, management and involvement by the IT department.
  
3. The deployment or usage model for cloud IT, namely
• Private cloud: Access to and use of cloud IT service for private use only. i.e. for company internal or private home use only. Consumed from public cloud provider or based on internal or 3rd party DCs that are transparent towards the user.  And not Internet facing or exposed in general for general, public access
• Public cloud: General, Internet facing and exposed cloud-based IT service, accessible for anyone. A public IaaS or PaaS can be used to create a private cloud solution for instance in the SaaS-area.
• Hybrid cloud: For most companies it's hard to come by a IT solution that is strictly 100% private, internal only, or 100% public with no personal login or access.  This in turn led to the development of hybrid cloud IT services, where IT services hosted locally or by 3rd party were combined with public cloud service, and one can gain access to private cloud or on-prem IT services through public cloud gateway.
  And this leads to the "old" 5-3-2 cloud definition morphing into the 5-3-3 definition of cloud computing.

This 5-3-2 or now 5-3-3 definition was nicely formulated by Yung Chou of the Microsoft US Developer and Platform Evangelism Team, and illustrated by Chou in figure below.

Some of the listed principles and definitions merits a closer look and discussion besides the development of the hybrid cloud delivery model.

In many cases, one-company private cloud services evolved from IT departments having developed and were running highly efficient server virtualization solution on prem or in 3rd party DCs, and were adding self-serve, compute billing to internal business units, on-demand scaling etc to their service delivery.  As noted in a earlier post ("Where does cloud-based IT services and delivery come from?"), it was then easy to move to a 3rd party cloud service, most server hypervisors supporting transparent VM migration, load balancing or fail-over between on--prem VMs and VMs living with a cloud provider.

But in many cases we also have IT departments boasting that they already have done the cloud exercise when they have moved their server platform to a virtualization platform, and gaining increased management, quicker server deployment and service delivery as well as lower TCO/OPEX towards their users.  Looking at the NIST definition, many such IT shops are still missing self-serve support for business users, lack true cost-based IT accounting and pay per use billing, as well as location transparent resource pooling - many company IT platforms are single-location DCs, and there are built-in location or access restrictions.

Also the true nature of private cloud services seems to be up for debate.  While a public cloud solution are accessible and open for "anyone" based on shared, self-serve, pay as you go infrastructure, are a private cloud service dedicated to an organization inside a private data center or can it be on prem or hosted off premises by a 3rd party DC or hoster?  The answer is probably that all three ways can be used to create a private cloud solution.  Also, as noted above, a public cloud IaaS or PaaS service can in turn be used to provision a private PaaS or SaaS solution, when using reserved instances of VM for instance.

Moving in-house or on-prem servers into the cloud - take 1: Cost Advantages

As detailed in an earlier blog post, the next "natural" step for in-house or on-prem server workload management seems to be "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". 

What are the main drivers for this and what are IT-departments and businesses looking to achieve?

One obvious driver or pull factor is the obvious ease of moving virtualised work loads or virtualized machines (VMs)  from on-prem hypervized servers and on to the the same hypervised set-up with IaaS cloud providers, for use in a private, public og hybrid use mode.

Another driver is the cost of delivery or TCO between on-prem servers/VMs versus multi-hosted cloud based ones.  BAIN & Company (www.bain.com) has a great illustration of this in their 2011 article "The five faces of the cloud" based on a IDC Worldwide Enterprise Server Cloud Computing 2010-2014 forecast.  Around 2010-2011 there was a shift in pricing of cloud based servers versus on-prem servers, with cloud-based servers for the first time achieving cost benefit compared to on-prem ones, projected to reach a 30-40% cost advantage in 2014.

In addition to cost advantges for cloud based VMs, there are numerous other advantages in the areas of more flexible workload management, provisioning time, VM flexibility and auto sizing, load balancing, recovery etc, that I'll try to cover in a upcoming blog post.