Avoiding the Multi-Cloud Value Traps

THE TECHNOLOGY VALUE GAP

‍

Many articles refer to the technology value gap. The ‘Value Gap’ is reached when investment and progress on the technical front no longer appear to generate business value. Note that the “value” is the perception of value derived from ongoing evidence. For example, a cloud provider can support increasing performance for additional costs, which can be measured. But the value to the business for that increasing performance may diminish as the costs rise.

‍

The value curve can, and has been used to compare different cloud service providers, evaluating performance, scalability, reliability, cost etc. The same evaluation can and should be performed as part of a multi-cloud strategy and specifically on the deployment patterns chosen.

‍

The value curve can, and has been used to compare different cloud service providers, evaluating performance, scalability, reliability, cost etc. The same evaluation can and should be performed as part of a multi-cloud strategy and specifically on the deployment patterns chosen.

‍

There are 4 key attributes of Cloud that need to be considered that surprise even experienced and seasoned technical people unique to Cloud and different to more traditional on-premises architectures:

1. Scope of services utilised - Cloud provides a broad range of varied services, each with their own technology stacks
2. Shared Responsibility Model - each of the services has its own SLA’s, governance and architecture vary
3. Elasticity of Cloud - variability of Cloud spend making it more difficult to set budgets
4. Deployment Patterns - there are 6 key deployment patterns (and combinations of these) - each with their own perceived value, complexity

‍

It is the combination of these four key attributes together with the fact that there are multiple deployment models or patterns, that leaves many organizations not deriving value from Cloud. In this article, we will focus on the deployment patterns, as this is often misunderstood and the prime instigator of value traps.

‍

MULTI-CLOUD DEPLOYMENT STRATEGIES

There are primarily 6 multi-cloud deployment patterns. Organizations would typically choose one of these. The first four patterns described in the diagram below are different methods of choosing where to host specific or all workloads. The last two, parallel and portable, refer to scenarios where usage or adoption for the platform or specific solutions need to operate across or be portable across cloud providers. Adoption of these patterns requires careful attention, as it is in these that the technology value trap can occur. Once the patterns are committed, it is very difficult, even with a maturing Cloud delivery model, to reduce the higher total cost of ownership and to improve perceived value

‍

‍

Technology value trappings include poor alignment of deployment patterns to business value. Skills are diverted and diluted to sustain these architectures for solutions that will increase complexity and risk, increase cost and slow down delivery. Even with a maturing operating model it can be very difficult to move the value line and affect the iron triangle constraints.

‍

We’ll now take a look at common value trappings related to deployment patterns.

‍

VALUE TRAP #1 - DEPLOYMENTS FOR MULTI-CLOUD RESILIENCY

‍

‍

Considerations

Organisations may want to spread a load as a means to provide a multi-cloud level of resiliency. Organizations may decide to provide a segmented or choice approach, providing a level of flexibility in terms of where systems may be hosted. They may also consider a parallel deployment pattern. Spreading a workload or workloads across multiple Clouds is a risky exercise. The benefits and justification for not keeping this to one Cloud should be clear and unambiguous.

‍

• Service levels - the deployment, underlying capabilities and skills required are diverse, with a potential risk that the effect is that the system is dependent on both Clouds operating fully. It is also difficult, even
• Contiguous systems are systems that have a level of interconnectedness - either at a data, application or system level. Often the scope of services and interconnectivity of different systems is not considered, with performance, reliability and duplication of systems built and supported by different teams and skills.
• Transactional systems have small increments of data that can be latency sensitive. Ensure the transactional systems are not spread across multiple CSPs. This also adds complexity, and especially latency with any data movement.

TRUE VALUE

True value is derived when a service is required to behave as a shared service, providing services to other systems spread across Clouds. This is often a requirement in Merger and Acquisition scenarios or in partnerships or services across enterprises.

The deployment pattern ensures that centralised deployment and observability are provided, whilst the services provided in each Cloud only require the services hosted in that Cloud. Data quality issues are controlled to ensure no duplication, redundancy or data integrity issues exist between the Cloud Services.

Caution should be exercised when deploying a ‘Choice’ deployment pattern. This may be required in an M&A environment supported by multiple IT departments. It is NOT advised to use the ‘Arbitrary’ deployment pattern in any situation. For the reasons described above it is very likely that this will inevitably result in a value trap.

VALUE TRAP #2 - AVOID CLOUD LOCK-IN BY MAKING SYSTEMS PORTABLE

‍

‍

Considerations

• Building and Deploying the portable abstraction layers - Building a portable landscape required owning a technology stack with layers of components each with risks of lock-in from vendor, technology and standards.
• Committing to each abstraction layer's roadmap - Each layer would need to be committed to - in terms of its roadmap, dependencies and service levels. Consider OpenShift and HashiCorp Terraform - you would need to commit to their roadmap and vendor services.

TRUE VALUE

‍Portability requires a commitment to an architectural stack that the technical team is comfortable with owning the technology roadmap of each layer. Organizations that are technology driven, e.g. Uber, would be able to invest in supporting and maintaining an architectural roadmap ensuring each layer of the architecture does not have its own lock in, for example using a technology stack standard that falls out of favour in the industry.‍ Implementing a container based architecture is a common approach in organizations today to provide a robust and flexible landscape to host a subset of applications that require portability.

‍

VALUE TRAP #3 - AVOID CLOUD LOCK-IN BY AVOIDING CLOUD NATIVE SERVICES

‍

‍

‍

TRUE VALUE

Consider that reasons should be given NOT to use PaaS components, rather than the other way around. These services can reduce TCO, and for each of them consider what truly is lock-in

A key consideration is in the application layer of a system where potentially microservices are utilised. Building a micro-services based architecture with many small components may require a compromise, of using PaaS components, and potentially a portable platform service such as a Kubernetes cluster, to avoid complex inter-application spread across a single Cloud.

‍

Microservices use of PaaS components that offer true value include:

• decoupling components for scalability and quality of service
• asynchronous services to manage queues for transactions or processes
• Language used for portability - e.g. Python

‍

VALUE TRAP #4 - SOFTWARE AS A SERVICE IS ALL ABOUT SIMPLIFYING
‍

‍

• Contiguity - Software as a Service systems should be chosen with clear boundaries, especially in the areas of integration and data flow. Ensure that the geographical location of the service and integration points are detailed by the service provider, or latency and data flows may become problematic
• Portability - SaaS solutions by design create lock-in in terms of processes, procedure and data. Portability is made possible through market migration tools - enabling the move between vendors - but this is typically SaaS to SaaS. 
• TCO Skills base - Generally, moving from PaaS to SaaS is easier than from SaaS to PaaS, as it requires moving back to greater responsibilities on the shared responsibility model
  ‍

‍TRUE VALUE
‍
‍Ensure that there is a clear strategy and architectural consideration of when to use SaaS and when to use PaaS. Organizations would often make a decision for a core system to move to SaaS, but then fall down the rabbit hole of functional fit and alignment, and put aside the need to consider integration and flow across other systems. Architectural patterns, if not carefully added to the weigh-in, may cripple the workings - through latency, security, data stewardship or governance issues. It is not easy to move back from SaaS to a PaaS or IaaS solution as underlying internal technical competencies and capabilities may well have been lost in the process. Choosing a SaaS model is a commitment and potential lock-in to this pattern, and therefore any potential need or capability to ‘roll-back’ to a form of hosted solution needs to be factored in.

‍

CRITICAL MULTI-CLOUD CONSIDERATIONS

The following table describes key considerations for any organization moving to, or in, a multi-Cloud environment.

‍

‍‍

‍

SUMMARY AND CONCLUSION

Multi-Cloud deployment plans are complex and require careful planning. Organizations must understand the potential for value traps, so that the correct decisions, financial commitments and expectations are set, to ensure sustained value from Cloud Services.

‍

‍

‍

Cloud providers offer a more mature solution stack today opon which cross-cloud and multi-cloud technologies, services and architectures can stabilise. And yet still, these 3 traps need to be understood, and an approach formalised, adopted and standardised in business, or the organization will, inevitably trigger the trap.