Reaching for the Cloud

Introduction

‘Cloud-first’ is the new mantra in organisations today. This article attempts to provide practical insights for Cloud adoption, instead of taking a blind leap of faith at the deep end and hoping for the best. These insights surfaced when my AWS certification study churned with 20 years of experience in designing & delivering solutions based on COTS, greenfield and cloud platforms.

Warm Up for the Journey

Embarking on the Cloud Journey is a big deal. Organisations, and not vendors, predominantly bear the risk of moving to cloud. This is very different from the engagement model with ERP & COTS product vendors, where risk-sharing is evenly balanced.

Key rules to remember in times of confusion on the cloud journey:

Rule 1: Cloud Stack is a blind Hulk. Extremely powerful capabilities but needs direction.

So have a clear and actionable strategy with measurable success metrics.

Rule 2: Start Small and Evolve

For a defined Business need, a small subset is really required from the huge cloud stack. Cloud genuinely provides the ability to pick-n-choose components to start small, which was rarely the case with ERP / COTS applications.

Rule 3: Remember the hype cycles

IT waves have always promised utopia. In the past, we had ERP, COTS, BI, Analytics, Agile, eCommerce, multi-channel waves and so on. Now we have Cloud, DevOps, Agile, AI, Machine Learning, OmniChannel etc. Read rules 1 & 2 if you get swayed by the do-or-die cloud hype from vendors.

Which route should I take for the Cloud Journey

I would list 3 simple steps :  Assess, Decide, Operate

1. Assess

Create a clear baseline of ‘As Is’ Business & IT Capabilities. This is a critical step because without a solid 'As Is' ground, the 'To Be' cloud journey can end in a disastrous crash. Organisations often rush through this step in their hurry to be cloud-enabled.

Creating a baseline involves categorising capabilities into Planning, Execution and Support groups. It is driven by functionality, data requirements and user/operational impact.  Categorisation helps assess the Cloud Fit (which we shall see later) for a capability. It brings out whether the capability is an autonomous function embedded with complex rules, or it is a collection of simple discrete events or it is standalone re-used function.  

2. Decide

Having created the Baseline Capability assessment, we now decide what cloud services to use.

The last count of AWS stack, as I am aware of, was 212 services. Every other week, we see ‘ground-breaking’ new services launched. And this can be overwhelming to decide what cloud services are suitable for my organisation's capabilities. In reality, a very small subset of the 212 AWS services can perfectly support the core IT architecture of most organisations. ‘AWS Stack Map’ below illustrates the point. It shows 32 services (many of which are options to choose from) that can support an organisation with a large IT footprint. For smaller organisations, the number of services can be less than 10.

3. Operate

With the As Is Baseline & physical toolkit sorted, the third step is where do I start. There can be 3 broad-brush approaches to start the cloud journey.

• Lift and Shift

In this approach, we lift-and-shift applications from on-premise to cloud infrastructure. The main Business driver here is a significant cost reduction. Typically, this approach should not require direct Business Involvement because we are not changing any functionality.

• Re-develop Existing functions in Cloud

This is a good approach to decouple monolithic on-premise applications using modular microservices. Here, functionality of on-premise application(s) is re-developed using cloud components. The main Business drivers are to improve reliability, performance, flexibility and cost-base of IT solutions to support current & future business needs.

Business involvement in this approach can avoid blindly replicating legacy system mess on the cloud.

• New Solutions in Cloud

This is the cleanest and easiest approach to cloud adoption. New solutions, that do not exist on-premise, are delivered using the cloud components.  In this case, anecdotal benefits of cloud can be realised. Business engagement is the key to success.  

Poor business analysis results in poor solution –whether it is Cloud or on-premise

Cloud Capability Fit

For each approach, the benefits, risks and capability fit is shown in the table below. Green indicates ‘Good fit’ and Amber suggest ‘Extensive Analysis Required’ for capabilities to move over to the cloud.

Illustration – Ecommerce Capabilities on the Cloud

This illustration uses eCommerce as an example to bring together the three steps - Assess, Decide, Operate. We can see how a small subset of the AWS Stack Map can support an eCommerce solution depending on the approach to cloud adoption.

Lift and Shift

An existing on-premise eCommerce solution based on a COTS product with a licensed database can be ported on the virtual environment using EC2 instance, Load Balancers, Auto Scaling Groups and associated components.

Redevelop on cloud/ New Solution on Cloud

Existing eCommerce capability is either re-developed or a New eCommerce solution is developed using Containers (ECS), Load Balancer, Autoscaling Group, RDS or Aurora database and serverless components such as Lambda, DynamoDB, CloudFront etc

End Note

It is important to reiterate that foundation of cloud is basically Infrastructure as a Service. Do not lose Business focus in the midst of snappy terms such as serverless, push-button-scaling, experiment-with-no-collateral-damage, platform-as-a-service, application-as-a-service etc. They simply denote reliable tools to reduce cost and time-to-market, as a result of automating manual operations that would be needed for on-premise infrastructure.

Without a clear business strategy and analysis, cloud can be as good/bad as on-premise solutions with the added risk of vendor lock-in.