Fudge Sunday - Cloud in Public: Impact Mappingby Jay Cuthrell
This issue is part 5 of a 5 part series
- Fudge Sunday - Cloud in Public: Status Dashboards
- Fudge Sunday - Cloud in Public: Engineering SLO
- Fudge Sunday - Cloud in Public: DevCommsOps
- Fudge Sunday - Cloud in Public: Mean Time To RCA
- Fudge Sunday - Cloud in Public: Impact Mapping
As of this issue, we now have historical perspectives and definitions for status dashboards, Engineering SLO, DevCommsOps, and Mean Time to RCA. Next, let’s talk about the increasing importance of dependency mapping across hyperscale public cloud service providers and consider business value engineering and customer journeys.
Impact Mapping in practice
Over the past four weeks, we covered Who, What, Where, and When for cloud companies that “write it down” to pursue goals for The Perfect Team. This issue will get to the final remaining question: Why.
To get an understanding of Impact Mapping, you could start with a book of the same title. For now, assume Impact Mapping answers the question, Why.
The answer? “Because that’s what the business needs.”
Impact Mapping can be challenging because the public cloud is increasingly less about public access than private considerations for the public of specific places. Effectively, this means that Impact Mapping should consider the technology stack and the operating geography for the laws or regulatory landscape that may also evolve.
+15 years: Hyperscale public cloud service providers invest to enable globally diverse infrastructure to support well-architected frameworks.💰☁️
+15 months: GAIA-X Policy Rules and Architecture of Standards support geopolitical data sovereignty and balkanization frameworks.⚖️🤔 https://t.co/hv5wZJfOyA
Let’s restate how we got here
Thinking back to our first issue and the inspiration for this series, Impact Mapping is meant to combine the “Service architecture documentation” and “Documented service dependency maps” from the blog post from @cloudpundit.
The “Service architecture documentation”
“helps us understand the ways a service is and isn’t resilient, so we can design accordingly”
The “Documented service dependency maps”
allow us to see the chain of dependencies for each of the services we use, allowing us to think about if Service X is really the best fallback alternative if Service Y goes down, as well as inform our troubleshooting"
When looking for evidence of Impact Mapping in hyperscale public cloud service providers, we can survey public information. Once again, the list is in no particular order or weighting other than shorter names to longer names.
IBM Cloud Impact Mapping examples:
- IBM Cloud Architecture Center promotes seven architectural decision points to achieve 1. Open hybrid cloud platform, 2. Data Fabric, 3. Business Automation, 4. Observability, 5. Security, 6. Regulated workloads, 7. IBM Z (which calls out 1.)
- IBM Clouds’s principles of chaos engineering is a call to action for learning to use Gremlin and applying the lessons learned.
- IBM Cloud’s Terraform scripts offer an Infrastructure as Code (IAC) way to build with resilience in mind on IBM Cloud.
Alibaba Cloud Impact Mapping examples:
- Alibaba Cloud’s Well-Architected Framework promotes a “three pillars” approach to achieve 1. Reliability, 2. Security, and 3. Performance
- Alibaba Cloud’s ChaosBlade offers an open-source approach to chaos engineering based upon the internal Alibaba Cloud Application High Availability Service (AHAS), MonkeyKing (fault drill platform), and chaos engineering tool.
Microsoft Impact Mapping examples:
- Microsoft Azure Well-Architected Framework promotes a “five pillars” approach to achieve 1. Reliability, 2. Security, 3. Cost Optimization, 4. Operational Excellence, 5. Performance Efficiency
- Multicloud Solutions provides an AWS and Azure comparison chart to promote choice, flexibility, mitigate risk, and map dependencies.
- Azure Monitor VM insights and Service Map collects and analyzes the telemetry associated with VMs and applications
- Chaos engineering is a call to action for learning about canary releases, test in production, fault injection, and applying lessons learned.
Amazon Web Services Impact Mapping examples:
- AWS Architecture Center (Well-Architected Framework) promotes a “five pillars” approach to achieve 1. Operational Excellence, 2. Security, 3. Reliability, 4. Performance Efficiency, 5. Cost Optimization
- AWS Cloud Map (Service discovery for cloud resources) creates and maintains custom maps of applications that includes updated location for dynamically changing application resources.
- AWS Fault Injection Simulator and AWS CodePipeline represent a call to action to adopt chaos engineering principles and apply the lessons learned.
Google Cloud Platform Impact Mapping examples:
- Google Cloud Architecture Framework promotes a “six pillars” approach to achieve 1. System Design, 2. Operational Excellence, 3. Security (Privacy and Compliance), 4. Reliability, 5. Cost Optimization, 6. Performance Optimization.
- Google Blog posts are a call to action for learning about chaos engineering, SRE principles, Disaster Recover Training (DiRT), and applying the lessons learned.
Oracle Cloud Infrastructure Impact Mapping examples:
- Oracle Cloud Infrastructure Best Practices Framework promotes a “four pillars” approach to achieve 1. Security (and Compliance), 2. Reliability (and Resilience), 3. Performance (and Cost Optimization), 4. Operational Efficiency
- Oracle Cloud Service Mapping provides an AWS, Azure, and Google Cloud comparison chart to promote choice, flexibility, mitigate risk, and map dependencies.
- Oracle Cloud Blog posts are a call to action for building multicloud networks for business continuity using Oracle Maximum Availability Architecture (MAA) and chaos engineering concepts.
- For this sampling, there was no access to consoles (portals) required.
- IBM Cloud information linked to IBM Services for frameworks references which made “pillars” comparisons difficult.
In summary, there are incredibly stark variations amongst the hyperscalers in expressing Impact Mapping. Further, it is reasonable to expect the market will drive demand for standards that normalize the variations or promote wider adoption of approaches such as the C4 model.
- Oracle Cloud emphasis is on 1. Security (and Compliance) whereas Alibaba Cloud, AWS, and Azure place emphasis on 2. Security and Google Cloud at 3. Security (Privacy and Compliance)
- AWS emphasis is on 1. Operational Excellence whereas Google Cloud has 2. Operational Excellence and both Azure and Oracle Cloud has 4. Operational Excellence (Efficiency)
- Alibaba Cloud and Azure emphasis is on 1. Reliability whereas Oracle Cloud has 2. Reliability (and Resilience), AWS has 3. Reliability, and Google Cloud has 4. Reliability
- Google Cloud emphasis is on 1. System Design curiously with no comparable pillars to others since the end goal is to drive towards documentation, decoupling, and managed services adoption before seeking similar pillars of other frameworks.
- Azure and Oracle Cloud emphasis is on 3. Cost Optimization whereas AWS and Google Cloud has 5. Cost Optimization
- Emphasis on Performance is the last or next to last pillar for Alibaba Cloud, Azure, AWS, Oracle Cloud, and Google Cloud.
- Looking back across these five newsletter issues, (stark) variations discovered seem to mirror similar findings from my blog post from March 2021 Multicloud March on low latency high bandwidth connectivity options.
Cloud in Public findings on Status Dashboards, Engineering SLO, DevCommsOps, Mean Time to RCA, and Impact Mapping will not be static. As such, we want to understand what the Who, What, Where, When, and Why means in terms of business value engineering.
So, let’s get a quick overview of business value engineering and think about the customer journey.
Each hyperscale public cloud service provider will have to anticipate customers at various stages of a journey from status quo to one cloud or the eventuality of mutlicloud. So, having a business value engineering framework in place will ensure the following:
- Key business initiatives prioritization
- Key stakeholders in a living RACI matrix
- Structured Decision-making frameworks applied (Facts, Alternatives, Commitments, etc.)
- Predictions are possible because data, telemetry, and instrumentation enable the proper well-architected framework underpinned with the right technology at the right time
- Continuous improvement drives this back to step 1 again and again.
To state this another way, let’s loosely paraphrase Dean of Big Data Bill Schmarzo on the essential nature of step 4 and the WHILE.
The hyperscale cloud service provider must help customers achieve their initiatives WHILE they are conducting their present operational reality.
Help might come from so-called cloud pricing calculators like AWS Pricing Calculator, Azure Pricing Calculator, Google Cloud Pricing Calculator, Oracle Cloud Cost Estimator, IBM Cloud Cost Estimator, or Alibaba Cloud Price Calculator. However, in each example, there is no solid connection to Impact Mapping that permits building the business case with accurate modeling well in advance of OPEX decisions in any quantified manner.
Eventually, each hyperscale cloud service provider inputs from real-time pricing API or their calculators and estimators will become a consideration for business value engineering tools. So, keep an eye on tools companies for Impact Mapping updates for business value engineering (by alphabetical order) such as DecisionLink ValueCloud, Mainstay Advisor Value Platform, MediaFly Value Story Alinean, and VisualizeROI.
Ultimately, partnering with customers in business performance improvement terms is the only way hyperscale public cloud service providers will have an enduring competitive advantage. As such, each hyperscale public cloud service provider will need to make strategic investments that help the customer uncover the highest value opportunities to leverage the proper well-architected framework that is underpinned with the right technology – and at the right time.
I am linking to my disclosure.
✍️ 🤓 Edit on Github 🐙 ✍️
Get Fudge Sunday each week