Whether it’s leaving home for work or heading out on holiday, all journeys begin from somewhere. The journey to cloud is no different.
Inside your corporate IT estate, you may already have a mix of legacy, traditional, virtualised or cloud-based solutions but are looking to move towards a more elastic and dynamic footprint. How do you achieve this?
Within this post, I’ll give an overview of what the journey might look like, provide some markers to help along the way and explore what happens once you’ve reached your initial destination.
Phase 1: Planning
Moving to a cloud-based operating model and environment should always start with a phase of assessment. Plan to bring clarity to where you are starting from and where you are looking to get to regarding overall landscape and business outcomes.
Some of the key drivers to achieving this are executive sponsorship, a shared vision of goals, and engagement from staff and leaders (both business and technical) from all parts of your organisation.
Often accomplished via a series of workshops, it’s important to ensure that views, concerns, and areas of expertise are captured, understood and replayed. All parties should understand the areas of focus that are most important to your business.
From the workshop attendees, and potentially others within your organisation, you should also look to form a smaller core team of contributors, often referred to as a Cloud Centre of Excellence. This group is comprised of both business and technical staff and will lead the organisation on the cultural and technical journey as well as define the initial set of fundamental principles, standards and governance to follow.
Phase 2: Assessment
The next step of the journey should begin to assess what your current landscape looks like and how this may map to a cloud-based architecture.
If an IT estate is large, distributed or not well understood, customers look to leverage organisations and tooling who specialise in asset discovery (like Cloudscape from our partner RISC Networks) to accelerate information gathering and basic analysis of the current technical landscape and dependencies. Other information to obtain during this step includes:
- Who uses an application?
- When and how do they use it?
- What are their pain points?
- Failure recovery (RTO/RPO) details
When you gather this initial set of information and metrics, the combination of business requirements and technical detail allows for the categorisation of applications and associated infrastructure into a set of migration strategies or buckets (commonly referred to, and covered well in the AWS Cloud Migration pages as the 6 R’s):
These specify the route you are most likely to take to migrate each application. Combined with details around the complexity and urgency to migrate (such as the closure of a physical location), these enable you to build out an overall migration plan.
Phase 3: Architect
Following the categorisation of applications and derivation of the overall plan, the next and often overlapping stage is to look at the cloud architecture required for reaching your destination. This may be limited to a single cloud provider or potentially a hybrid multiple provider approach.
Within the architect phase, one of the first areas to tackle is the selection of a core set of design principles and tooling. This is important on two counts:
- It enables you to create the foundations and basis for your cloud landing zone, or “base camp,” which your applications will use to inform their initial cloud design. This is particularly important for applications you may be looking to rehost, which are likely to maintain a number of their current characteristics and undergo a “lift and shift” approach to migration.
- It defines the guide rails regarding technology and approach where you may be looking to move towards the introduction of a more agile approach to delivery leveraging options such as automation, containerisation or microservices within public cloud.
When creating the architectural foundations for success, it is important to iterate, experiment and promote the derived architecture and tooling within your organisation. For most customers I have worked with, this involves identifying one or more applications and using these to prove out design assumptions and operational functionality. Additionally, educating technical and business staff via activities such as workshops and mentoring on what is expected of the architecture, the processes around it and how they can build upon it.
Phase 4: Build
The focus of the journey should now turn to building out the required cloud environments for your applications and migrating as appropriate.
Often Architect, Build and Assessment operate on an iterative cycle as items identified during the build phase require further assessment and subsequently architecture and design changes:
As your landscape begins to become more cloud focussed, and staff learn how to operate it, you should see an increase in the cadence of delivery of applications within it and the beginning of iterating and optimising what’s already been delivered. This leads to the next phase.
Phase 5: Run
Within the run phase, the use of your new cloud landscape should be business as usual. Workloads should successfully run within it, ideally resembling the goals you were initially targeting and working towards.
But is that the end of the journey?
Well, yes and no. Yes, in that you’re hopefully celebrating reaching or nearly achieving your original goal, but….
Phase 6: Optimise and Evolve (aka where next?)
As you near the end of a journey (such as a holiday) you start to think: where next? The journey to cloud, particularly an optimised one, is no different.
Looking back, you should see a different organisation now than when you first started. An organisation which has begun to embrace the new processes, methods of working and technologies introduced during the journey; an organisation where people are keen to continue to evolve and optimise the systems it uses, both in efficiency and effectiveness.
From a process perspective, this is the evolution and adaption of the agile ‘assess à architect à build’ methodology put in place during the journey. Those lessons learnt, and knowledge gathered begin optimising both existing and new workloads.
Technically, this can mean a number of things, from looking to right-size the compute needed to run a particular workload, to leveraging more PaaS technologies or transforming a workload to move towards the use of container-based or serverless architectural patterns.
Whatever your next step is, it should be one that you and your business take together, which leads to bigger and bolder actions in the future. Or, as Buzz Lightyear might say, a step that leads you “to infinity and beyond!”