Fit for purpose cloud architecture helps unlock cloud value

Motorcycles have taught me many great lessons applicable to my life and work as a quality engineer. I was recently wondering why many organizations aren’t achieving their expected outcomes from Cloud investments, and one of those motorcycle lessons recurred to me. Let me explain.

When I bought my first motorbike many years ago, the salesperson, an ex-design engineer, explained that motorbike design involves complex technical trade-offs and design decisions to balance and optimize often conflicting technical specifications. He told me achieving all the specifications would be impossible or prohibitively expensive. The functionality of all the models—commuter, sports or touring bikes—are similar but are designed for different purposes and provide a different experience for riders.

Buy the ‘wrong’ model and you don’t reach your usage and experience goals. Your purchase would be a ‘failure.’

It occurred to me that a similar thing could happen with when organizations are setting up Cloud. They may not be unlocking and maximizing value from Cloud adoption because their Cloud Continuum system is not designed and architected for expected business outcomes. 

Why cloud outcomes and expectations differ

An Accenture report recently found that just 37% of companies had fully achieved their expected outcomes from Cloud. So, why is this so? Lack of vision, strategy, execution, skills, stakeholder management, or some combination of all? From my first motorcycle purchase experience, I wondered: could it be a design problem? Are businesses choosing the right Cloud Continuum system design for expected business outcomes?

Now, why is this critical? Cloud promises immense benefits such as scalability, agility, reliability, elasticity, etc. Over the last decade, hyperscalers have developed hundreds of cloud services to harness the best computing technologies. But will running application workloads on Cloud automatically unlock business value?

Definitely not.

It’s like asking whether I would be satisfied by buying a fuel-efficient commuter motorbike when I’m looking for speed.

Cloud for purpose architecture design

Cloud continuum applications must be designed and architected to derive the maximum business value from the underlying Cloud resources. Conversely, business goals must drive the system design and architecture ‘decisions’ of the specific instance of the Cloud Continuum of an organization. 

As an example, a Cloud-based algorithmic trading platform must be designed for a low latency, real time response. Why? A 1-millisecond advantage in trading applications can be worth $100 million a year to a major brokerage firm, by one estimate. To achieve a specified latency, an architect must choose from various design options, apply calculated tradeoffs, and make an optimized decision. But, the architect must also keep cloud resource costs in mind as, very low latency could escalate cloud costs. So, it’s not just the functionality that drives differentiation. It is critical how well the functionality is delivered.

Designing a motorbike involves complex tradeoffs. Ditto on Cloud. A low latency design goal conflicts with scalability. A high data availability could conflict with data consistency.

So, what wins? Ultimately, the unique business goals of an organization drive the Cloud Continuum design decisions. Just as an algorithmic trading platform must be designed for low latency real-time response and high data consistency, a retailer platform must be designed and architected for user experience, elasticity, and scalability. For merchandise display and purchase recommendations, data availability is prioritized over consistency.

Three critical imperatives for Cloud adoption

First, Cloud applications must be architected to unlock the intended business value from the underlying cloud resources. Secondly, cloud being distributed and heterogeneous means it could also fail in unpredictable ways. So, the applications must be architected to be resilient to external perturbation conditions. Third, system design must optimize the use of Cloud resources commensurate with the value gained from business services delivered by it.

Just like the technical specifications for motorbikes—fuel efficiency, acceleration, etc.—Cloud Continuum applications are characterized by ‘Quality of Service’ KPIs such as scalability, latency, response time, throughput, resource efficiency, resiliency, availability, security, resource efficiency etc. Functional richness alone is not sufficient.

Cloud architecture requires unique designs

The challenge? Cloud Continuum is a distributed system. System design of a distributed system is hard. A distributed system is a collection of independent components located on different machines that communicate with each other over a network to achieve common goals. Distributed systems fail in unpredictable ways. The behavior is non-deterministic, especially under extreme conditions.

Cloud Continuum architects must apply complex trade-offs and optimizations to make design decisions under great uncertainty. The runtime consequence of the design decisions cannot be easily envisaged during the design stage. Often Application QoS attributes are mutually conflicting. You never get it right the first time. An iterative, empirical, simulation-driven approach is required, powered by observability and analysis tools.

Can the architects not use standard design and architecture templates? Yes, to some extent. But every organization is unique; hence the system design decisions must reflect the unique needs and objectives of the organization.

Don’t these imperatives apply to on-prem? Yes, they do. But as organizations adopt ‘Cloud is the business’ paradigm, these become more critical for the Cloud Continuum.

Cloud quality engineering is a game changer

Cloud Quality Engineering must adopt a continuous, iterative and experiment-driven architecture-aware approach to characterize Application QoS and discover QoS breach and degradation modes early in the lifecycle.  A constant feedback loop of experiment, evaluate, discover, and improve cycle will progressively optimize the design and architecture to be fit enough to deliver business outcomes.

Cloud is a powerful technology that can transform business models, enhance customer value, and help organizations stay competitive; however, mere Cloud adoption does not guarantee this. System design and architecture decisions must unlock value from Cloud, avoid failures and optimize Cloud resource costs. Finally, Cloud Quality Engineering techniques must be adapted to these unique challenges of Cloud to enable Cloud success.