I recently had the pleasure of participating in the Cloud Roundtable discussion hosted during Tech Field Day Extra at VMworld 2019. This discussion included several of my fellow Tech Field Day delegates along with notable representatives from Dell Technologies, VMware, and Intel.
What was the purpose of our discussion? To settle the debate around cloud architecture, governance, and multi-cloud, once and for all! While we may not have achieved this goal in the course of one hour, our conversation touched on many important points that are worth consideration.
Based on our discussion, it’s clear that these topics present a challenging reality many of us must deal with. Below are a few points I believe will assist with making this reality a more pleasant one.
Success Starts With an Understanding of Requirements
I hate to sound like a broken record, but I can’t help but emphasize this point every chance I get: a solid understanding of both functional and non-functional requirements is critical to the success of any technical initiative. Because of the potential complexity and operational impact of a multi-cloud approach, I believe this point is especially important.
While technology itself is exciting, too often discussions begin with a proposed technical solution, work backward and attempt to force-fit the technology to the objective. At best, this type of approach can lead to lost time and frustration working through mistakes and rectifying them after the fact. At worst, the business can experience costly downtime, revenue, and reputation loss.
Fortunately, these consequences can be easily avoided by understanding the answers to a few key questions before selecting an architecture. These questions include (among others):
- What goal is the business attempting to achieve?
- How does the application respond to failures?
- What level of uptime is required for the application?
- How does traffic flow between components, and how do they scale?
- Where are the users of the application located?
- Who will be responsible for managing and maintaining the platform after implementation?
Without addressing these points, it will be difficult to ensure that the chosen architecture, multi-cloud or otherwise, will meet the goals of the business.
For those looking for an expanded discussion of this topic, I (selfishly) recommend listening to Datanauts episode 168: Why Design Process Matters For Data Centers And The Cloud, which can be found on the Packet Pushers network.
Architecture is a Shared Responsibility
When I say architecture is a shared responsibility, I don’t mean this in the sense that stakeholders should play the role of a technical architect and make decisions directly. Rather, responsibility is meant to indicate that relevant stakeholders (including executives), application owners, IT staff, and users all have a vested interest in the success of the architecture.
This begins with a belief that their input and expectations will be seriously considered and integrated into the final product. If this belief is not present, those responsible for operating and using the solution will likely have a negative experience.
Aside from the impact on operators and users, it can be difficult for an architect to consider all possible viewpoints when key decisions are being made. While this ability is something every architect should try to cultivate, relying on it excessively presents a risk and can lead to decisions being made using invalid assumptions.
Because of the importance of shared architecture responsibility and stakeholder input, some governance frameworks explicitly include guidance in this area. And this is for good reason. Shared ownership encourages investment of effort, more meaningful participation from all parties, and leads to better outcomes.
Industry usage of the term multi-cloud is confusing
If you are in the IT industry and have exposure to cloud technologies, you’ve likely run across the term “multi-cloud” being used to describe multiple architecture approaches:
- Distribution of components of a single application across multiple cloud platforms
- Independent use of separate cloud platforms to support separate applications
Each of these approaches looks completely different in practice and the implications for business, architecture, and operations teams are different, as well. Because of this, use of a common term is not helpful to communication. While usage of separate terms won’t resolve the situation entirely, this would assist in eliminating some of the confusion when multi-cloud is discussed, and that would be a good start.
Multi-Cloud Isn’t Automatically the Answer
Lastly, multi-cloud is a non-trivial platforming decision, not just a handy conversation-starter. As with all significant decisions made during formation of an architecture, it’s worth the effort to determine if the decision supports the goals of the organization.
Too often, multi-cloud is spoken of as if it is the obvious answer and positioned as a panacea that must be pursued. For many customers, this simply isn’t true.
Before making the decision to travel down the multi-cloud path, it’s useful to consider whether needs would be better served by developing a higher level of expertise on a single platform. The slight advantages gained through use of a multi-cloud strategy can quickly be outweighed by the burden of correctly architecting on, operating across, and governing multiple platforms.
Like many other things in life the simpler answer, although less exciting, is often the best.
Conclusion
As with all things affiliated with Tech Field Day, the broad base of viewpoints and experiences represented added a great deal to the conversation. I hope you will take the time to read all the posts in this series to get a glimpse into the thoughts of the other participants, as well.
If you have a counterpoint to any of the assertions made here, feel free to reach out to me on Twitter at @semi_technical. Open discussion is a good thing, and I look forward to continuing it!
