A Recipe From Vanilla Cloud To Tutti Frutti

Cloud computing is a plain dish. A single scoop of cloud computing in the form of a basic cloud service instance comprising compute, storage, analytics and other functions is an essentially vanilla-flavored dish. But like any comparatively blank surface, a plain vanilla scoop of core cloud paves the way to accoutrements, enhancements and embellishments.

There is a lot of sense in this approach i.e. Cloud Services Providers (CSPs) do offer specific optimizations to custom-align clouds in one direction or another, but these specialisms are still considered to be factory-made alignments that position a cloud one way or another before it hits the real (okay, virtualized) world of usage.

Getting a cloud fixed and ready for production workloads – especially in heavily regulated industries like financial services and healthcare - takes a little more finesse and flavoring.

Starting point: cloud landing zones

There are a number of general components that every cloud will exhibit, regardless of the workload that it will be deployed with or the services that it will be interconnected to. Technologists like to call these elements of cloud the ‘landing zones’ and we can count a few examples here.

Chris Astley is head of connected engineering at KPMG UK. Explaining that platform configuration monitoring will be central to any organization’s initial landing zone definition, Astley says that firms need to have a strategy from the beginning to automate this function; it forms part of what the business should have in its ‘policy as code’ or ‘continuous compliance’ framework and playbook.

“This is all about understanding how a business will monitor and fix misconfiguration, enforce correct configuration and flex the framework for new services,” said Astley. “Deeper into the flavoring process, a business will need to think about how its cloud estate integrates with enterprise-wide security tooling like vulnerability management, threat detection & analysis, the Security Operating Centres (SOC) and so on.”

He points to networking and says that firms will need to plan for a highly segregated and distributed network in their cloud estate.

Speaking from experience gained working on a large number of implementations, the KPMG team has underlined how important it is to understand an organization’s integrations – with on-premises facilities (not only datacenter but offices, for instance) and other cloud services that the business may be consuming in a Software-as-a-Service (SaaS) model. Firms will need to plan for how new services deployed to the cloud will achieve secure and performant connectivity.

Navigating segregated distribution

“As the ingredients and flavors build, let’s also make sure that we bring in Identity and Access Management (IAM) – and make sure this is fit for a cloud context. A lot of on-premises tooling will not form a natural fit for a cloud environment; this is because it will fail to focus on IaaS (infrastructure) and the PaaS (platform) services in the cloud, which are often the most valuable, so new tooling might be needed. Even with IaaS it’s likely that the nature of a cloud environment will be highly segregated and distributed, so once again, tooling that is perfect for an on-premises datacenter is often a poor fit,” clarified Astley.

As we build towards a more textured, more ingredient-rich and hopefully a more palatable cloud, we can start to think about shoring up business foundations. In terms of cloud, if we’re being fancy, we might call these tools operational resilience functions; equally, we might just call it backups, failovers (i.e. switching to redundant stand-by systems) and Disaster Recovery (DR) technology.

Tutti frutti - all the ingredients

As we start to build up the tutti frutti multi-ingredient cloud, KPMG’s Astley warns us not to think of each landing zone as a singular solitary thing. He explains that, in a cloud context, it’s far better to have a set of base components, in code (Infrastructure-as-Code, or IaC), which can be instantiated to form new landing zones specific for the workloads or applications that a company is looking to deploy.

“This separation of base zones has benefits around segregation of duties and the ability to operate teams in parallel, whilst still remaining consistent and compliant,” he said. “Then there will be workload or service-specific activities related to many of the above. In particular each time a new service in a cloud provider is to be consumed, we will need to integrate it with our policy as code / continuous compliance frameworks and implement the policies needed. If this has been done in an easily extensible way, it should be a very short timeframe to achieve (days, not weeks or months).”

We also need to think about how we setup our cloud-wide components, because this is critical to the pace of the development of the workloads that are being deployed. They should be easily consumable and, critically, their use should come with a ‘license to operate’, which by default means the workload is fit for purpose. This takes a huge amount of time out of development lifecycles and takes the strain off of assurance functions.

Extra sauce, multi-cloud layers

According to KPMG’s Astley, as soon as we then layer in multi-cloud, new considerations come to play, such as how to avoid duplication of effort; how our workload placement strategy keeps up - and, from a policy and security perspective, how do we ensure consistent reporting and the ability to respond to incidents?

Fortunately, there are some good solutions to these challenges which don’t impact on the value but crucially they should be considered upfront when starting with an organization’s first cloud to get the most benefit.

The KPMG team tell us that we need to keep orchestration tooling agnostic to the platform. A business needs the platform native services to gather data, but have a central place to store and produce dashboards and reports. The business can then leverage again the cloud-native services to automate a lot of the responses to incidents like availability/downtime, security, etc.

“When you use a platform-specific service on a particular workload or project, do it consciously. These services, especially some of the data-storage/processing and AI services, offer the most value from the cloud providers, so should be encouraged. But how loosely-coupled your application is from those services can be influenced and this would make any future migration to another cloud that much easier,” concluded Astley.

The construction of the tutti frutti enriched, augmented and extended cloud is a logical steps for all organizations, but they must first order vanilla and then look for the flavors that suit the implementation at hand.

Chocolate sprinkles anyone?