HOW TO AVOID THE MOST COMMON CLOUD PITFALLS

Cloud Computing has become ubiquitous in the current day Technology landscape. All organisations consume some form of Cloud Service ranging from SaaS, through IaaS, PaaS, Serverless to Micro-services. However for many companies, the ability to leverage cloud capabilities and be able to realise the business benefit of the new wave of technology innovation such as Artificial Intelligence (AI), Machine Learning (ML) and Robotics Process Automation (RPA) has not been possible. This is due the creation of a new “legacy” of Cloud services where a combination of disparate architectures, manual operating policies and procedures and a lack of identifying the right technical skills profiles required has led to a significant obstacles. Considering that organisations are 17x more likely to increase cloud spend than reduce it over the next 12 months[i] it is critical that these Cloud pitfalls are avoided, or mitigated.

COMMON CLOUD PITFALLS :

1.     Cloud Strategy 

Cloud Strategy is a very good starting point. It is multifaceted and does cover a range of mistakes in an organisation’s approach to Cloud Computing. Firstly, there needs to be an honest discussion about what a “Cloud Strategy” is. A lot of organisations state that they have a “Cloud First” strategy. Or “moving everything to the Cloud” and “It’s all or nothing.”  These do not constitute a Strategy. They are statements, tag-lines. A well developed and thought out Cloud Strategy needs to flow from the overall Business and be embedded in Technology strategy documents. Targeted benefits need to be distinguished to support the overall business ones and actively measured and reported on periodically.

A robust Cloud Strategy is built by first getting in place the essential building blocks. Get it wrong and it can become a very costly, disjointed and a siloed affair. When done right, however, the strategy will be well founded, tie into the wider corporate strategy and be fully adopted. Executive mandate, sponsorship and funding for strategy execution will follow and your organisation will unlock the benefits of cloud capability and the significant value associated around AI, ML & RPA. Considering 30% of all Cloud spend[ii] is wasted it is wise to get the strategy right.

Other misconceptions that have an impact to instituting an effective Cloud Strategy are :

-        â€œIt’s too late for a Cloud Strategy.” The basic premise of this, is that due to the fact an organisation already has Cloud Computing then its too late. All (worthwhile) strategies are constantly evolving to meet the new and future requirements – it’s never too late !!

-        Thinking your Cloud Implementation/Adoption/Migration plan is a Cloud Strategy. A plan is a set of actions and deliverables within a set timeframe. Your Cloud Strategy will be multi-faceted and much more nebulous in terms of definitive outcomes within certain areas e.g. creation of Cloud Centre of Excellence to drive business benefits from Cloud services by covering:

1. Cloud Governance: organisational policy standards and standardisation of tools for financial and risk management as well as Automation and orchestration capabilities (e.g. DevOps/DevSecOps pipelines, automating Application & Infrastructure delivery)
2. Brokerage: Assist internal teams/functions/business units in selecting CSPs, architecting the cloud solution(s) and collaborate with the sourcing team for contract negotiation and vendor management.
3. Community: Raise the level of cloud knowledge in the organisation and capture and disseminate best practices through a knowledge base, source code repository, training events, outreach throughout the organisation, and more.

-        Having a single-vendor strategy and/or outsourcing your Cloud Strategy to a hyper scale CSP. If one thing is clear about Cloud Computing it is that it is not homogenous. No one size fits all. The vast majority of organisations will have a hybrid and multi-cloud strategy and landscape. In future this will evolve in a Distributed Cloud architecture where the Control Plane (your automation and orchestration capabilities) will need to manage seamless across these various localities (On-prem DCs, Co-los, CSP, Edge compute, IoT). In this context you need to own your Cloud Strategy, and not just be an interested party.

-        Exit strategy. The common consensus is that you need to think about your exit strategy from a CSP. It is good practise to have this and to address various key elements such as Data ownership, Data movement (geo-restrictions – technically, commercially & regulatory), Security & architecture considerations by workload/application, portability of code/data and skills). However, by putting the thought and consideration into your Cloud Strategy and thus by extension in your architectural patterns then a lot of this can be mitigated upfront.

-        Assuming its an IT only strategy. With the advent of IT Consumerisation, no longer do non-technical employees believe that they do not have an input into technology that affects their area of the organisation. This trend will only growth exponentially with new capabilities such as Low Code (LCDPs) and No Code platforms (NCDPs) which will lead to an explosion in business design and delivered apps. By bringing these talents within the wider organisation (through a Cloud strategy and an accompanying Cloud Centre of Excellence) will head off a whole host of issues in future.

For more information on how to build a Cloud Strategy please do have a look at recent LINKEDIN article I co-authored on this topic : 

https://www.dhirubhai.net/pulse/how-build-cloud-strategy-from-ground-up-brian-king?trk=portfolio_article-card_title

2.     Cloud Implementation/Adoption/Migration – Lift & Shift as a destination not a stopover

We all know that the world isn’t perfect, and that compromises are needed. Whether these are due to a combination of available budget, talent/skills, time and executive support or other considerations, they are a fact of business life. However, we need to be cognisant of the fact that the most common Cloud Implementation/Adoption/Migration route can be lead you down a dead end.

The “lift and shift” is an attractive proposition especially where there is a definitive event deadline such as a Data centre lease or Co-location contract renewal that cannot be moved. The issues of a Lift and Shift approach are not immediately realised or felt. These come to light further down the road and are:

o   By Lift and Shift and not refactoring any of the migrated applications, the benefits of Cloud (eg scalability, flexibility, elasticity, availability, agility & reliability) are not being full realised;

o   You’ve moved your existing Data Centre operating policies and processes into a Cloud landscape – these are not go to be effective over time;

o   The required skills sets and technical knowledge is different and these need to be mapped and covered in any successful migration;

o   The Cloud cost model is completely different to that of a legacy On-premise Data centre. 

I do appreciate that Lift and Shift is typically seen as a stepping stone, one which will be for a short period of time. Unfortunately, this is rarely the case. This “time versus benefit” equation has been very well visualised by Forrest Brazeal in his article “The Lift and Shift shot clock.”[iii].

https://acloudguru.com/blog/engineering/the-lift-and-shift-shot-clock-cloud-migration

3.     Lack of Automation & Orchestration

A lack of Automation & Orchestration capabilities with an organisation’s Cloud architecture is a very common occurrence. Whilst this is a manageable situation in a simplified architecture (eg. Hybrid Cloud with one CSP provider with limited number of applications), it becomes an untenable situation at any real scale. Key issues that need to be address include:

o   Provisioning standardised virtual Cloud architectures with Global CSPs (AWS, Azure, GCP)

o   Provisioning standardised compute/storage/networking builds within minutes rather than hours/days

o   Real time visibility of Cloud Assets (via Central Management Database “CMDB”” – see Operating Model & Processes)

o   Automated compliance on Data governance (eg. Data Geo-location capabilities)

However, the main issues that results from this, is a lack of ability to drive further Cloud benefits (Scalability, flexibility, elasticity, availability, agility & reliability) and also unlock further innovations (AI, ML, RPA and IoT) due to manual operating constraints.

4.     Security Implications 

A number of years ago, its was a common occurrence that the corporate Cyber Security strategy and the Cloud strategy (if there was one) were widely different in their approaches. However, with Cloud becoming so ubiquitous this has changed.  Cloud & Security go together – the future is Secure Access Service Edge and how to bring security to the sessions (data), rather than data to security. Zero Trust, or rather no implied trust, is replacing the traditional perimeter focused models. Cloud is a key enabler of this. If you want to look into Zero Trust in further detail here is a link to a previous LinkedIN article :

https://www.dhirubhai.net/pulse/how-operate-within-zero-trust-security-concept-brian-king?trk=portfolio_article-card_title

Currently there are a key security implications that need to be considered. Again these are due to oversights and admissions in other areas but manifest themselves in security breaches:

o   Owing to a lack of Automated Application and Infrastructure deployment, a majority of deployments are manual. This increases the likelihood of human error, which in a Cloud environment has major risks. Recent significant security breaches at organisations such as Equifax, Marriott (was actually Starwood but Marriott acquired them and took on the liability), British Airways and Avon all have a common theme. This was that Cloud resources had public IPs left exposed due to human error. By automating this deployment and compliance capability these issues can be resolved and avoided (eg. Cloud security posture management (configuration), Cloud Workload Protection Platform (CWPPs), and through automated infrastructure as a code.

o   CSP/Client security RACI. It goes without saying that having a clear understand of what your CSPs will be provisioning, managing and monitoring from a security perspective is critical. This needs to be mapped out and incorporated into your security operations policies and processes.

5.     Operating Model

It’s self-evident that the move to a true Cloud Native architecture will result in a complete transformation of your Operational Model and associated processes and procedures. These need to be embedded within your new service stack whatever it is. Even if you are not transforming all the way to a Cloud Native architecture, then this should be your target. Understanding the impacts to your new service stack for Hybrid, Multi, Distributed cloud and all of the various flavours of services (eg. Iaas, Paas, serverless, micro-services, DevSecOps) is critical. Additionally, mapping out the service provision that will be managed by the CSP and the elements that will be managed within your organisation and by whom is a very useful process. I would recommend aligning this with the ITIL v3 service framework to ensure that there is a coherent approach. A ‘RACI Model by Activity’ will also help clearly set out the various responsibilities.

A good example of the various change is around Incident & Change management (“I&C”) processes. The I&C will fundamental change due to the nature of Cloud services – what characteristics of the services that you capture will change in the CMDB (eg. The CMDB will transform from an Asset register of sorts to a dynamic repository of service elements). How I&C are managed within the organisation will also need to be re-profiled with the various business stakeholders.

6.     Talent & Skills

In my experience this is the area that is most commonly overlooked in Cloud transformations. It is understandable why with all the various employment regulations and associated workplace rules to adhere too (especially when there is a multi-country/geographic scope to consider). However this is a critical area in any transformation effort. At a minimum a comprehensive mapping exercise of current and required skills, expertise and knowledge will allow a better informed judgement of how to provision what is required - either through up-skilling internal, contingent resourcing, Business Process outsourcing of specific repeatable tasks etc. It is clear that key competencies within the Cloud Strategy, Architecture, Security and Procurement domains should be retained internally.

CONCLUSION

Cloud services have become a bedrock of all IT functions in last decade. They have provided real, tangible benefits to organisations’ that have been able to harness these services, ranging. From IT modernisation, Improved efficiency & productivity, increased data security and enabling digital business strategy.[iv] In the future, Cloud will evolve from a transactional capability to be “The Foundation for Business Innovation.” Cloud will create new business models and revenue streams rather than merely serve existing ones.[v] Being able to truly exploit these opportunities will move from a technical issue to a business imperative. 

Author : Brian King has experience of 20 years in the IT Consulting space, supporting senior IT leaders with IT transformation & Turnaround.

If you need help in creating a bespoke Cloud Strategy or Programme inception for Cloud Enablement, or a review of your current Cloud Computing architecture feel free to reach out for an exploratory chat.

[i] Gartner survey “How do you expect your organisation’s cloud spend to change in the next 12 months ?” 2020

[ii] Flexera ‘State of the Cloud” report 2020

[iii] A Cloud Guru “Brazeal: The lift-and-shift shot clock” 21st February 2020

[iv] Gartner “The Future of Cloud Computing for IT Leaders” 2020

[v] Gartner “The Future of Cloud Computing for IT Leaders 2020