In part 1 of this blog I reviewed the recent developments in cloud adoption; now let us dive deeper into the best way forward to meet the challenges…
Why is embracing the cloud so challenging?
The main reason is that for the first time since the early 90s, almost all companies have simultaneously decided to transform their IT estate. The last big change of this scale was when PCs became cheap enough to be deployed on hundreds or thousands of desktops and client-server software was created. Nearly everyone decided at the same time to migrate from central mainframe systems to distributed platforms built on a variety of new software languages, creating the similar challenge of knowledge, experience and available resources.
Whilst perceived to be of enormous impact, the introduction of the Web actually only caused a subset of enterprise applications to be rewritten, and this happened over a fairly long period of time. But of course now, the problem of legacy is far higher than it was 30 years ago, and the skills required to migrate or re-engineer for the cloud are far more complex and broad.
Take for example an article discussing client-server from 1996: “As technology sophistication increases linearly, the design skill requirements increase exponentially. Users are seduced by easy-to-use development tools. Today, anybody with a credit card can purchase visual development tools and create applications. When this is done outside the scope of the centralized IS department, these applications become support nightmares”. Brown observed: “A lot of those people doing those applications don’t have any idea of what they’re doing. They need the design skills”.
All this sounds pretty familiar 20 years on! History is repeating itself and many companies are repeating the same mistakes as before. Back to 2018, we stated some of the likely problems people would face with moving to cloud, and they still sound familiar:
- The evolving skill sets needed to deliver widescale technology estate transformation
- Lack of experienced people on cloud projects
- Changes in operating models (including internal billing and service management)
- Security and environment design
- Public cloud adoption framework and related operating model
- General public cloud (knowledge) capacity
- Where to obtain practical cloud knowledge from (cloud vendor, local consulting, offshore)
- Approaching regulators with their cloud based strategy
- Containerisation knowledge and delivery
- In-depth understanding of the security / compliance requirements of cloud matched to differing regulatory environments
So what is actually going on right now and where are people having issues? Let us start with the challenges and failures that we have seen. They broadly fall into the following categories I have tried to avoid mentioning the obvious ones:
- Delays, delays and more delays
It is taking so long to build the foundations, that the underlying cloud technology has moved on in the meantime. Some teams are having to throw away what they have built, as by the time it is completed, it is already out of date. When you consider that cloud companies can introduce 3 or 4 major releases to their products per day, it is hardly surprising that internal teams are forever chasing their tails.
- The challenge is bigger than you think
Teams are completely underestimating the size of the task to build out anything but the basics for cloud migration. Sometimes the teams are stating that this is a hugely resource-hungry endeavour, but are failing to convince their senior management teams to provide the resources. However even when they do get the resources needed, everyone seems to be ‘learning on the job’ and there is a real lack of experience. This has lead to central teams trying to limit the workloads moving to cloud and the rise of huge amounts of Shadow IT. In a public cloud environment this can be a very risky approach.
- Lack of knowledge in depth and breadth
Not only is the task a large one, but the current knowledge of how to build physical datacentres has been built over literally decades of improvement and skills becoming ever more niche. Just take networking as an example – now you need deep skills in the following: WAN, LAN, firewalls, VPCs, network access, messaging, network costing, network analysis etc. It would be very hard to find those skills in just one person, yet this is just one area that a cloud datacentre requires. The knowledge of how to build a physical datacentre for many large companies is spread across tens, if not hundreds of people. Yet the size of the teams trying to build cloud infrastructure are a small fraction of this.
- Continued use of manual processes
The cloud promises a software defined datacentre, but almost all the people I talk to are still using manual provisioning (via the CSP console) and manual approvals. There is appetite to automate process and reduce the ‘path to production’, but it is a non-trivial task.
- Lack of real experience to operate at scale
As pointed out earlier, most people are attempting this for the first time in their careers and are learning through trial and error. There are very few people around who have a track record of building the required foundational components and the automation required to contemplate large-scale cloud adoption or migration.
Our view remains that the solution to these problems is through creating a ‘Datacenter as Code’ (DaC) solution. I have talked previously about this – you can find the article here. Datacenter as Code builds upon Infrastructure as Code (IaC); if IaC are the ‘lego bricks’ then DaC is the completed model, following the instructions. DaC is a living, running piece of software that automates the building and provisioning of all of your software-defined datacentre assets.
There is a real risk that as an industry we are in the midst of repeating the same mistakes made in the mid-1990s. We have similar constraints on accessing talented staff who have done this work before, and we are all going through the pain at more-or-less the same time. These challenges were at the core of our thinking about how to solve the problem, by creating an open source initiative for the benefit of all. We believe that by creating an automated open source initiative that anyone can use will truly help transform business in many industries – thus Tranquility Base was formed.