08 Nov 2022

The Operational Answer to Realising Effective Public-sector Multi-cloud (Guest blog from Hashicorp)

Author: Duncan Greenwood, VP EMEA, Hashicorp

In the decade since the UK Government announced its cloud-first public sector IT policy, multi-cloud has dawned but operational hurdles are limiting its potential.

More than £12bn has been spent on cloud services through the UK Government's G-Cloud framework. But it is central government departments that are leading the charge, with wider public sector adoption reportedly patchy.

Make no mistake, the appetite for multi-cloud innovation is palpable, with adoption expected to grow. Organisations are excited by the prospect of infrastructure modernisation, better citizen experience, cost savings, and better individual and data security.

Back in 2020 many organisations struggled to realise the business outcomes promised by multi-cloud, according to analyst IDC. Two years on it seems little has changed, with common concerns including costs for 94%, the shortage of cloud-native skills a number-one concern, and ongoing worries about increased risk of cyber attack, according to the 2022 HashiCorp State of Cloud Strategy Survey. A Vanson Borne study with Nutanix found public and private sectors still struggling, with a resounding 87% saying simplified management and operations would go a long way to helping hit their goals.

It’s clear why organisations are crying out for this simplicity. Different clouds look and behave differently because providers employ different APIs. Each service provider employs its own set of APIs to deliver different implementations of foundational services. Services that are similar and considered a “standard” — such as Kubernetes runtimes — vary wildly in implementations. Higher-level services, such as databases or serverless runtimes, diverge even further. As a result, individual teams operate as islands within the larger organisation. Leaders find it difficult to optimise costs, security becomes a struggle, and outcomes are uneven.

Platform not parts

A popular way to overcome this situation is to deliver cloud services consistently with minimum burden on the development teams. Here, leaders commit to a cloud operating model whereby individual cloud service providers and services appear — to your developers at least — as a single system. Implementing a cloud operating model entails creation of a common, logical architecture that lets developers easily connect to services and service providers. The foundation of this architecture is a set of common APIs that developers plug into to simplify provisioning, security, networking, and other capabilities. This model works best when developers can tap into APIs via self-service, rather than a ticketing system.

Most organisations adopt a cloud operating model on three main areas.

The first is provisioning. Teams should implement infrastructure and services as sets of code, patterns, and practices that can be controlled and centrally governed. Layered into these are code for compliance, governance and workflow — policy as code. Finally there’s automation: using a policy engine to deploy applications built according to your code-based policies. This is faster, more reliable, and more consistent than implementing runbooks that form part of traditional, ITIL ticket-based systems and manual processes.

It’s worth noting the typical public sector IT environment will contain a large base of heritage applications as it moves to the cloud and organisations may be unwilling — or unable — to move everything at once. It therefore pays to be able to implement a form of orchestration capable of serving all types of workloads — from long-running batches to short-lived containers. This serves practical purposes while helping organisations move closer towards their strategic goal of cloud native.

Next is identity-based security: a trusted IP address and perimeter firewall are no longer sufficient to handle the ephemeral nature of cloud infrastructure. A more flexible and rigorous model of application-level security is required that treats all network traffic as suspicious - known as Zero Trust. Enforcing Zero Trust Security is predicated on securing everything based on trusted identities, and improves enterprise security posture, reduces likelihood of a breach, and accelerates secure multi-cloud adoption.

The third capability is networking - arguably one of the toughest nuts to crack when establishing your cloud operating model. Different runtimes, the shift to dynamic IP addresses, complex microservice architectures all hamper consistent connectivity, security, and reliability. The key is to architect a networking layer that is focused on services, and supports multiple runtimes. The core of this architecture is a common registry that forms a foundation for service connectivity that ultimately enables the shift to a service mesh pattern.

Conclusion

Multi-cloud has huge potential for a sector facing digital change with spending and budget pressures. Realising its benefits, however, requires a change of strategy: it means running separate systems as a single platform. Operationalising multi-cloud means turning developers into a platform team with a reliable and consistent platform experience using unified tools, processes and workflows.

It takes a cloud operating model to achieve that.