How does the cloud change things

It’s important to acknowledge that the cloud changes more than how we host workloads, it fundamentally changes:

• how we purchase and pay for services;
• how we design, build and operate services;
• the skills required to design, build and operate services; and
• our responsibilities when operating services.

Existing model

Under the existing model, costs are usually managed at the infrastructure level. Your organisation purchases all of its infrastructure upfront - servers, storage, networks, licenses, etc. and is responsible for its management. The original purchase of the equipment is an effort-intensive spend exercise funded from your Capital Expenditure (CapEx) budget. The cost of operating your infrastructure – such as power, hardware support and license renewals – is paid through your Operating Expenditure (OpEx) budget.

Your organisation is responsible for maintaining all infrastructure and software assets through their support lifecycle, and refreshing them when they are no longer supported or sufficiently functional. This results in a continuous pattern of refresh activities, usually staggered by asset type to reduce the burden on your budget and staff.

The cost of operating the entire infrastructure platform compute, storage and network services and software – can be calculated with a reasonable degree of accuracy, as each type of infrastructure component is only updated every four to seven years. However, accurately estimating the cost of running a specific service without considerable effort to ‘cost slice’ across the entire technology stack is a time-consuming task that is rarely completed. 

Cloud services

Under the cloud service model, costs are usually managed at the service level. In most cases, cloud services are purchased on a subscription, or consumption basis, and are paid through your OpEx budget. This is because you are paying to use a service, and not purchasing an asset.

Subscriptions

A monthly or annual structure of payment where the customer pays for what they use. This can be either as a debit account or credit.

Consumption

A cost based on service usage, which is charged by:

• time: services like virtual machines (VM) and database instances are charged based on units of time. For virtual servers, you pay a set fee per hour (or fraction of an hour) which is calculated based on the performance characteristics of the server; and
• invocations: these services are charged based on the number of times the function is used. The prices usually change on a sliding scale, becoming more cost effective as usage increases

Existing model

Our service and application development processes follow a product focused approach. Developers use libraries and third-party software packages from a range of vendors to create applications and services.

New capabilities require your team to write code or install software packages to provide extended functionality. Each time you install new software, you assume responsibility for maintaining it. This increases your operational overheads and can often lead to technical debt if insufficient time is dedicated to maintaining your estate. Furthermore, it limits innovation because packages must be installed, tested and purchased prior to use.

Services are hosted on virtual servers on an organisation's internal virtual server platform, usually hosted within an on-premises datacentre. Provisioning and configuring new virtual servers is a manual task, and scaling to cope with production use often requires the manual duplication of existing servers to provide additional capacity an effort that often results in errors.

Cloud service model

With cloud services, the complexity of the underlying infrastructure is hidden. This has resulted in a shift of responsibility, with the cloud service provider taking sole ownership of running the platform, leaving your organisation to focus on the configuration and operation of the services you need. When deploying services to the cloud, you may choose any number of deployment methods, including: running virtual servers, deploying database instances, deploying a serverless service architecture, or nearly any combination of these approaches.

Cloud services shift the focus from infrastructure and software, to data and code. The power of the public cloud is in the simple presentation of powerful, consumable services continuously evolving building blocks upon which to build innovative new cloud services with minimal effort, cost and complexity. Your developers are free to explore and test a rich array of cloud services and features without needing to purchase, install or maintain any of it. Instead, you pay for what they use on a granular and flexible pay-as-you-go model.

To obtain the greatest benefit from using public cloud services, you must approach cloud adoption in the understanding your existing services will likely need to be modernised to function effectively and efficiently. It can be tempting to consider lifting and shifting existing workloads into the cloud by implementing virtual servers – an Infrastructure-as-a-Service (IaaS) offering. This approach should be avoided in most cases because it is not cost-effective and doesn’t allow you to fully leverage the benefits inherent in the other cloud service models. 

One successful migration strategy would be to take a Lift and Shift approach followed closely by optimisation of the application to take advantage of the efficiencies of public cloud for performance improvements and savings in cost and effort. This approach has been proven to be a catalyst for teams to use public cloud services and enables the applications that have been migrated to them to be optimised in a phased approach.

The greatest efficiencies can be obtained through the effective implementation of Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Serverless offerings, where the burden of effort for maintenance and administration falls on the cloud service provider. With these offerings, features such as backup, logging and high availability are usually integrated into the platform, and can be configured at the service level.

Existing model

The roles and skills to manage an on-premises estate have not changed significantly in recent years. The roles have been set for some time, with the introduction of virtualisation technologies (virtual servers) being the last major disruptor.

For most organisations, managing their existing services and infrastructure requires a combination of the roles outlined below.

For specialist skills that fall outside these common roles, organisations partner with consultancies to implement requirements and perform knowledge transfer to internal team(s).

Designing, building and operating cloud services changes the skills requirement for your organisation. These changes, by role, are outlined in this table.

Developing services to take full advantage of the cloud requires your organisation to adopt new development practices and operating models. Your existing applications and services – especially legacy deployments – must be modernised, or re-architected to run efficiently using public cloud services. It is likely that these skills don’t currently exist at scale within your organisation.

The roles of your internal teams are likely to change over time as your organisation progressively migrates services to the cloud and your deployment of services on-premises is reduced. Despite this progressive change, most organisations will continue delivering services on-premises for some time to come, which will require the continuation of existing processes, on a smaller scale, for the foreseeable future.

Existing model

When an organisation runs application and infrastructure services on-premises, the internal teams are responsible for procuring, configuring and maintaining the entire technology stack.

All infrastructure, networks, storage and data are hosted in an environment owned and operated by your organisation, or by a delivery partner that you contract with.

You (or your delivery partner) have full responsibility for operating and managing the entire technology stack. This means you must:

• maintain datacentres: purchase and maintain power, cooling, fire suppression;
• procure hardware: purchase, maintain and support the underlying datacentre technologies, such as: network devices, storage devices, servers and virtualisation platforms;
• security: secure, manage and monitor the physical and logical security of your datacentre; and
• uptime: meet your uptime agreements (SLAs) with your internal customers, by building in enough resilience and redundancy, and continuously monitoring service stability

Cloud service model

Under the cloud services model, your responsibilities vary depending on the services you selected. However, in all cases, your responsibility for maintaining your service - and the associated operational overheads - is reduced significantly.

The illustration below shows your responsibilities when operating under the different cloud service models.

At one end of the spectrum, there is the traditional on-premises service model, where you are responsible for every aspect of the technology stack. This gives you the greatest level of control, but also has the greatest number of drawbacks and the highest operational overheads.

At the other end of the spectrum, the Software-as-a-Service (SaaS) model removes most of the complexity and effort of operating the service. SaaS solutions are standardised, which results in less flexibility and fewer opportunities for service customisation. This can present its own challenges, but in the long-term, creates better business processes, and avoids the type of practices that have resulted in the legacy systems we have today resulting from insufficient IT estate maintenance.

It is important to remember that you must always be responsible with data, even when using SaaS products.