- 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.
- 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.
- Use of On-Prem Landing zone with VCF
- A Multi-Cloud Strategy, Design Frameworks, and Day 2 Operational Thoughts
Recently, I transitioned to a new role. I am now very happy to be working as a Principal Architect with a focus on Multi-Cloud Architecture.
From an architect’s perspective, my interest is always the customer/partner business value, how to identify and develop their requirements into a technical logical design, and then understand the decisions that need to be considered for successful deployment and consumption at scale.
How should an enterprise architect approach the Multi-Cloud World ?
- Develop a strategy
- Develop a service design
- Understand the Business Logic (Plan*)
- Deploy & Configure (Build*)
- Operationalise & improve (Modernise* & Operate*)
* Major Pillars of the VMware Cloud Ready Framework
The amount of information available within technology is potentially overwhelming for any technologist.
How should an enterprise architect even get started?
There are standard design methodologies, alongside vendor-based recommendations for strategies. Technical documentation, videos, books, webinars, and free tiers/credits everywhere? Which one is best?
“Absorb what is useful. Reject what is useless. Add what is essentially your own.“
From a technologist’s point of view, understanding the technology and the features/capabilities is extremely interesting and valuable. It could, however, be very easy to go down a rabbit hole and be lost forever in reading about interesting cloud features that are not relevant to your business.
Understanding the business use case and requirements is key to success. By developing the criteria and ensuring it is able to be practically measured, the initial desired logical state model can be created.
Once the initial logical design has been established, the business to technical decisions are easier to understand and discuss.
With a business requirement-based logical design, the vendor documentation and content review for whatever technology or cloud provider/service becomes easier.
The requirement, to feature, to design decision mapping can be more tightly focused and a service design can be developed with areas such as cost optimization, sizing, capacity, connectivity, security, and sustainability considered at the vendor technology level.
What are the risks and the gaps with the business and service design for operation, and successful consumption?
This is an important area, in which I am particularly interested for my advisory activities as an architect.
Creating the transition states and ensuring a business impact analysis is constructed while navigating a journey to something like a multi-cloud solution can be extremely valuable.
This activity can provide real business insight with areas of operational understanding, and practical ability to migrate or transform applications/workloads.
Design frameworks are extremely useful, but how to apply them while understanding the business impact is an important skill that I am always looking to improve.
VMware Cloud Ready Framework – https://vmc.techzone.vmware.com/vmware-cloud-ready-framework
AWS Well-Architected Framework – https://aws.amazon.com/architecture/well-architected
Google Cloud Architecture Framework – https://cloud.google.com/architecture/framework
Microsoft Azure Well-Architected Framework – https://docs.microsoft.com/en-us/azure/architecture/framework/
- Field Based Discussions on VMware Cloud Foundation at EMPOWER 2022
Last month I had the opportunity to present for the VMware EMPOWER 2022 online conference.
This conference is primarily aimed at VMware partners, and from a technical perspective, the content is filled with field-based knowledge.
One of my technology focus areas is VMware Cloud Foundation. The solution-based approach is of great value from a business and technical perspective. Design and operational impacts and design decisions need to be considered both before and after the solution is deployed.
My solo session, “Enabling Effective Solution-Based Operations with VMware Cloud Foundation,” highlights the importance of logical design mapping, day two operational impacts with physical design decisions, and business impact formulation for VCF upgrades.
Another session that may be useful for technologists interested in VCF is the panel session I was happy to work on with two colleagues from VMware. Dean Lewis, and Ann Bailey. This session walks through the VCF 3.x to 4.x transformation process. With differing viewpoints from Sales, PSO and Advisory areas of VMware, this session gives field advice to those considering a real-life upgrade.
Both sessions are now available for replay at the EMPOWER 2022 website.