The Value of Infrastructure Agnosticism and Multi-Cloud Design

Having a long-term strategy to provide value while meeting specific design requirements is always a focus for a solution architect. 

With multiple concerns such as datacenter containment, power costs, support dates for each software layer, sustainability goals, and ever-increasing new features, it is easy to design for the immediate requirement and what is needed now without considering the future business risk or operational impact ahead.

In the highly competitive cloud world, features change, develop and so do the costs.   The introduction of a feature that seems to be an answer to your specific business problem could be changed, even deprecated, or potentially lock your business into a situation where you cannot consume another service elsewhere.  In addition, the location and control of data depending on the content is also an important focus (ie sovereignty, competitive partner relationships).

When reviewing requirements with a business, an architect can use this time to understand the appetite and landscape of risk and the need for flexibility.  These long-term aspirations are also an important design factor.

A seemingly simple datacenter consolidation project (i.e., “We want to get out of the hosting datacenter game”) could also have hidden assumptions (i.e., “Once we move to the new platform, we don’t want to be tied to any particular vendor relationship, we want to maintain the ability to financially negotiate, and control our data location.  At the same time, being cloud-like in new applications”).

A long-term strategy will also likely involve multiple technologists, potentially SMEs, and vendors with differing views/focus on specific layers. 

How does an enterprise-focused architect for a business ensure consistency of approach, and control risk/understand operational requirements going forward?

The value of infrastructure agnosticism was a subject of a recent panel discussion webinar I was kindly provided the opportunity to be part of (Thank you, John Marrone).     

The concept of providing a simple consistent platform for applications while respecting business requirements such as locality, current operational skill-set, budget, and security is not new. 

This end-state is often faced with more and more competing design factors especially as you hand over some of the responsibilities (ie Operating system/hardware) to a provider. Yes, you have an SLA and expectation/understanding of a platform you may not have had before in a self-run platform but at what cost/risk?  

You may find a very important business service is now tied to a specific cloud service at a hyperscaler that has an interdependency with another business application that you feel should sit in a different cloud service for licensing or support reasons.   What are the options?  Refactor costs again?  Migrate one, pay more?  Modern examples of standard technical debt.

This type of challenge, for me, is helped by considering the impact, and ensuring abstraction/features are applied at the right time for a business.  Normally at the conceptual and logical phases of enterprise design.

In this example, the logic of the business expectation can be reviewed and applied to a vendor-specific technology. The agreement of specific landing zones mapped to business characteristics and relationships can aid discussion and future design decisions/amendments.

Logical designs such as this can also be used by an enterprise architect to help shape conversations and ensure consistency in approach with the multi-technology SMEs.

Physical diagrams mapped back to business logic and requirements can help ensure cloud features are mapped to business needs and the logical strategy without increasing complicity. Each feature or core service is justifiable and risk assessed to ensure the safety of project service or data.

For example;

• Use of On-Prem Landing zone with VCF
  • Provide local processing and capitalise on in-house capabilities with core VMware technologies
  • Provide automated deployment and a near consistent BOM to other landing zones
  • Consolidate existing datacenter patterns using cloud-like infrastructure topology such as HCI & SDN.
  • The ability to perform refactoring assessments and flexibility for mid-term service hosting responsibilities.
  • Understand and validate migration impact from legacy to another landing zone
  • Develop migration processes for migration to landing zone 2 

• Use of VMware Cloud Service 1 – AVS
  • Reduce impact on operational teams with consistent processes
  • Moving to a consumption-based model in a phased approach
  • Inherited cost optimisation of licensing and vendor support capabilities for legacy windows based applications that are not selected for refactoring at this time.
  • Mobility – ability to migrate back on-premises without additional refactoring or to another VMware Cloud Service using proven migration processes.
  • Ability to reuse landing zone pattern with same processes at another VMware Cloud Service for new locations, and regions without extensive redesign.

This approach of design rationale review, feature consideration, and justification with impact analysis can remain constant throughout the assessment of technology. From the on-premises exit, migration wave planning to new strategic PasS service consumption.

Providing a consistent approach for a solution architect in an ever-changing cloud world.

---