The complexities of multi-cloud consistency

In a multi-cloud world, the distinction between operational and functional consistency is more important than ever

Consistency. In the world of technology, we use this term to describe the characteristic of equivalency. Something is consistent if it behaves the same way over time or in varying conditions. Consistency continues to be problematic for enterprises operating in a multi-cloud world. According to F5 Networks’ 2019 State of Application Services report, that’s most (87 percent) of you.

Certainly, the variation in deployment rates across data centre and cloud for application services points to a simple cause: not deploying application services consistently.

But that’s not the only cause of inconsistency. Plenty of folks, according to the same survey, are deploying application services on-premises and in the public cloud, but still struggle with consistency – particularly that of security.

This demands a deeper dive into what “consistency” means, because I suspect that part of the problem lies in the failure to recognise that there are two different layers of consistency and both matter.

Application services are not application delivery controllers

At the heart of this discussion on consistency is the difference between an application delivery controller (ADC) and an application service.

The ADC is a platform that delivers application services. That ADC is a system unto itself, much in the same way that Kubernetes is a system unto itself. Kubernetes is a platform for deploying and operating containers. An ADC is a platform for deploying and operating application services.

That’s important, because platforms (or systems, if you prefer) carry with them a separate notion of consistency than do the “things” they deploy and operate. Consistency is at the operational layer; that is, the management and operation of the platform and the application services it delivers.

Functional consistency

This is distinctly different from functional consistency, which is offered by each application service. Functional consistency comprises the capabilities of the application service. This is usually what folks are referring to when they indicate a challenge with multi-cloud consistency, because it’s the most visible.

Functional consistency is particularly difficult to achieve when deploying application services from different providers. A web application firewall (WAF) or anti-bot service from one vendor is not necessarily functionally equivalent to a WAF or anti-bot service from another vendor.

For example, if one WAF is able to provide bot defense but another is not, you are not functionally consistent. This will make it more difficult to enforce policies that rely on identifying and blocking bad actors using automated bots to attack.

Functional inconsistency is also seen in capabilities around detecting malicious content. Signature sets may be different across different services, which can lead to inconsistent protection. By standardising services across all properties, functional consistency can be realised and the benefits of consistent protection achieved.

Operational consistency

The second, and less often mentioned, source of inconsistency is at the platform layer. That’s the ADC for a significant number of enterprise organisations.

When moving to the public cloud, many organisations opt (intentionally or accidentally) to employ cloud-native options for application services. This is often because developers build cloud-native services into apps because it is faster and easier. It can also result from operational siloes, where teams are organised into cloud-specific teams. An operational team familiar with one cloud’s native services will tend to default to their use.

This leads to multiple operational models because no two cloud providers offer the same set of APIs or operational consoles. This leads to process differences and completely separate workflows that are unfamiliar to others in the organisation and require cloud-specific skills to manage. This approach places extra burdens on experts with cloud and service-specific skills because the pool of expertise remains small.

That immediately introduces operational inconsistency at the platform layer. The way that you provision, onboard, and operate those application services is operational, and introduces operational debt the moment you hook into the first API.

You’re probably not using cloud-native application services on-premises. Which means you now have two different application services platforms to deal with. They have different methods of management, analytics, monitoring, everything.

It’s like using two different ADCs on-premises. While some very large organisations make that work; over the years most organisations standardise on a single ADC platform.

Operational consistency and the ability to replicate application service policies across all applications has been a driving factor for that decision. A single platform provides consistency across both operations and functions. A single ADC will offer the same services with the same functional capabilities in all environments. This enables organisations to standardise operations, management, and policy enforcement across cloud properties.

This approach has extended benefits in that familiarity with the platform means a larger pool of expertise from which to draw on when deploying new apps or troubleshooting problems across multi-cloud environments.

But when moving to cloud, some have forgotten why they standardised on an ADC platform in the first place: operational consistency and support. Introducing additional platforms necessarily increases the burden on operations and impairs the quest for consistency.

Consistency needs standardisation

Standardisation can be a scary term for some folks who believe it stifles innovation. But scarier is a free-for-all that might encourage innovation, but in the long term is unsustainable and creates a chaotic operational environment.

With IT under pressure to deliver value to the business, increasing operational staff in order to maintain multiple platforms and menagerie of application services seems orthogonal to the goal of achieving multi-cloud consistency.

Standardisation – especially at the operational layer – is a key component to innovation because it alleviates the burden on staff to focus on operating platforms and encourages collaboration on policy and architecture, instead.

By ensuring both operational and functional consistency across properties, organisations can achieve the consistency of policy they desire without breaking their budgets.