Seeing through the clouds
Today AMDH Services Limited finishes it’s engagement with Nottinghamshire County Council on their Cloud Programme. After 4 years working on the Cloud Programme from assisting developing the strategy and business case through to technically leading the delivery of that strategy I finally leave the Council.
Before going into the detail of what we’ve delivered I’d like to start by thanking Ivor Nicholson (ICT Director for the Council 4 years ago) and Adam Crevald (Group Manager for Technical Design & Architecture at the Council) for trusting in a small business to assist in defining the approach ICT would take to its service delivery. For my business and me personally this trust was a fantastic opportunity and it has been good to work with Ivor and Adam over the past few years on this exciting programme of work.
What drove the decision to move to cloud?
The Council had two main drivers for their cloud programme…
An aged data centre that either needed a uplift or to be removed / replaced
A commitment in the overall ICT strategy 2014-2017 to adopt a “Cloud First” approach
This led to an ICT Cloud Strategy, a business case, cost model and ultimately to a paper at the Council’s Policy Committee on 14th December 2016. The paper at Committee is publicly available on the Council’s website here:
This paper explained that in addition to the funds already available to the Council’s ICT department a further £4.1 million would be required in order to facilitate the move to Cloud.
At this stage the shape the Council’s cloud programme would take was relatively unclear as it was very challenging to identify the architecture of the solution without having chosen a supplier or delivery model.
What choices were made?
The strategy paper and associated policy committee paper identified 5 phases for the Cloud Programme – these were:
In practice discovery and requirements capture took from about August 2015 through until December 2016. The Tender phase took about 4 months at the start of 2017, Design & Build / Implementation ran from May 2017 through until November 2019.
The Council chose to use Microsoft Azure and Office 365 as their cloud platforms of choice and did this through the use of an existing contract. AMDH Services Limited were contracted to provide technical leadership on behalf of the Council into the main contract focusing primarily on the overall programme objectives, and the design, implement and migration to Azure and Office 365.
So what has the cloud programme delivered?
Firstly – its important that I acknowledge that we have worked in partnership with the Council and Microsoft throughout the cloud programme in order to deliver the outcomes listed below. The Council has a lot of highly skilled dedicated ICT staff who have worked enthusiastically with us on the below activities for the past few years. The programme has not been delivered as a “them” and “us” activity but as a team activity where we have sat with the Council’s staff to jointly deliver the outcomes.
Our work with the Council included the following items – some of these are still works in progress but most are completed:
Some Lessons Learned
Over the past four years I think I have learnt a fair amount about cloud – not just the technical details around how to migrate services and applications in Azure and Office 365 but also some bigger picture lessons around cloud design, implementation and migration. I’ve picked out a few of these “lessons” to talk about below.
Cost Modelling for Cloud is very challenging: My experience is that its very difficult at the onset to accurately determine how much a cloud project will cost and even more difficult to identify the OPEX costs beyond the project. There seems to be a lack of good tooling at a reasonable cost – for example MS has no tool for Azure that allows you to forecast month by month costs based on what you plan on migrating into Azure in any one month and to manually create this kind of a forecast a lot of guessing is required… so much more than just the VM sku and amount of storage.
Application portfolios on-premise tend not to be pruned: You may find there are a lot of applications you have that are duplicates of each other from the same or different vendors, a lot of applications that are retired, at end of life, near end of life or simply no longer in use. Other applications may have plans for an upgrade or a move to SaaS. Others may not be suitable for moving to cloud. Understanding the full application portfolio and the roadmap for each application is a very long winded but necessary exercise.
Be flexible – one size does not fit all: Moving all applications to IaaS simply doesn’t work. You need to consider retiring applications, merging applications, consolidating servers, moving to PaaS, replacing with a different application, and moving to SaaS as well as moving to IaaS.
Rightsizing of VMs sounds great – but in practise is very hard to convince people to do: Imagine you have a virtual machine with 8 virtual CPU cores and you do some measurements that show it never exceeds 4 virtual CPU cores…. What do you do? On premise it doesn’t really matter – Vmware manages this well and if you are monitoring the platform you probably know how much headroom you have… but in public Cloud you pay a lot more for 8vCPU that for 4vCPU so you want to make the change. But how do you know this pattern is true all year? How do you know there is not a peak utilisation of 8vCPU in June? How do you know whether the vendor required 8vCPU in order for their support to be valid? The fear sets in … you cannot change it as performance might suffer now or in the future. To rightsize requires planning, visibility of the resource utilisation, management commitment and courage.
Beware of the increased latency: Its quite hard to identify in advance of migrating an application to Cloud whether the increased latency will cause the application to not work… and if the application once migrated doesn’t work its quite difficult to work out if this is due to latency. You need a plan to assist with this – how will you find out whether latency will be an issue, how will you measure the effect, what will you do if it is an issue?
Don’t forget licensing: Not all software vendors will support a cloud based implementation, but most simply won’t have specified in their terms and conditions whether they do or not. You either have to take the risk that they may decide to ask you to move the application back to on-premise or ask them in advance about support for public cloud.
Plan to not just move applications but monitor them too: you probably monitor applications on-premise using an on-premise tool, but how will you monitor applications in the cloud? Will you extend your existing monitoring tool or use a different one? If your long term objective is to move everything to a cloud delivery then you need a capable cloud monitoring tool delivered from cloud (maybe not the same cloud…) and this requires investment of time and money.
Plan to improve processes & automation: one of the major “selling” points of public cloud services is the rich automation tooling available. But it can be easy to overlook this and focus on getting the applications into cloud rather than improving the ITIL and business processes that surround the application and allow it to function. It is important to have documented processes and to understand how much time these processes consume, and which would be best suited to automation.
I’m sure are many other things that should be taken away but these are the key things I can think of just now. More on this another time.