Cloud infrastructure vendors provide design guidance, but more help is needed

As I lamented last week, the unabated innovation AWS exhibited again this year at re:Invent, while a testament to the company's aggressiveness and persistence, has a dark side in the complexity it adds to an already crowded services portfolio. As I wrote,

It’s hard to fault a company for putting out too many products and updating them too fast. However, it can lead to a problem familiar to consumer products companies, namely choice overload.

Another cloud observer later noted on Twitter the similarity between consumer product micro segmentation and the variety of cloud services, writing,

I said that it's not just that cloud providers offer a huge variety of stuffing flavors, but that the user gets the choice of stuffing thickness with millimeter-increment precision.

Not to over trivialize since there's an enormous difference between application infrastructure and cookies, but the common factor is the risk of too much choice, which in the case of complicated products like cloud service leads to analysis paralysis or outright waste from overprovisioning.

Even those organizations wanting to do a rigorous job of IaaS design and sizing must confront the complexity of different, and non-uniform instance sizes, myriad configuration choices and complicated billing options, as I detailed in this column, noting that:

 

Such an increasingly competitive environment means that more enterprise users will be hedging their bets with a multi-cloud strategy, looking to avoid lock-in and reduce costs. However, as RightScale’s analysis points out, the lack of uniformity in cloud services and complexity of pricing and discount models means that IaaS isn’t close to being a commodity. No one will be doing cloud arbitrage anytime soon.

Cloud vendors haven't completely ignored the design problem

I characterized AWS as building an online superstore where everything's available, but the buyer is on the hook to find what's best and warned that,

...its technology- and the architecture-agnostic explosion of products without an opinionated stance on best practices and implementation misses a significant need for advice how best to incorporate them into an enterprise.

In retrospect, that's a bit unfair, since AWS and its competitors do provide architectural blueprints for different application scenarios. The AWS Architecture Center has gradually expanded from a limited set of greenfield AWS blueprints into an active micro-site that's added reference deployments for a wide variety of applications, customer case studies and technical dives into scenarios like microservices.

The foundation of AWS's architectural guidance is the so-called Well-Architected Framework, a set of design rules providing "architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud." Originally built around four elements, the latest document adds a fifth pillar, namely:

• Operational Excellence, specifically, how to automate to improve efficiency, repeatability and promote continuous development and integration.
• Security, which doesn't just include the usual data protection techniques, but processes like risk assessments and mitigation strategies that improve security.
• Reliability and building redundant, fault-tolerant systems using distribute cloud services.
• Performance Efficiency which includes using higher-level native cloud services for things like databases, analytics, and machine learning instead of DIY compute instances, along with the use of lightweight, autoscaling serverless designs that minimize overhead.
• Cost Optimization which focuses on workload measurement to increase usage-based, versus recurring, spending and techniques to track and assign resource usage and costs to different applications and business units.

While the AWS advice is sound, it's the sort of mom-and-apple-pie truisms one sees in an IBM Redbook or J2EE design handbook without the design details. Better utility to IT practitioners comes from the AWS Quick Starts and Reference Architectures that can bootstrap cloud deployments of popular applications or use cases.

Quick Starts are automated, highly available reference deployments that securely configure and run the computer, network, storage, and other services required for a particular workload. Reference Architectures are blueprints illustrating complex designs for common enterprise use cases like Web hosting, batch processing, DR or e-commerce built with native AWS services. For example, the model for a log analysis system uses S3 for file storage, EMR (Hadoop cluster service) for data analysis and RDS as a results repository. As a reference design, the AWS documents don't include details so IT architects still face a multitude of decisions about service and network configurations.

Microsoft has long published software design patterns for developers, but in response to customer confusion recently extended its architectural guidance to cloud designers in the form of the Azure Application Architecture Guide. Echoing comments, I made about the proliferation of services and options on AWS, one of the Azure team wrote, "We see all of these new services and industry trends as a great opportunity, but at the same time, they can be a source of confusion for customers."

The Azure design process starts with the selection of an architectural style, such as N-Tier, microservices-based or event-driven application, with the guide offering relevant software design patterns, technologies and Azure services for each. Like AWS, the Azure guidance is based on a set of widely-known principles like security, availability, and scalability, but includes a much broader catalog of design styles/patterns.

Again, the Azure guide is a design reference, not a detailed how-to, but like AWS, Azure also has a set of quick start, automated templates for deploying particular applications or types of infrastructure. Indeed, the Azure gallery is enormous, with more than 600 from both Microsoft and contributors.

Not to be outdone, Google Cloud also has a set of tutorials, architecture guides and documentation for implementing different scenarios, such as mobile app backends, data analysis or Windows-based lift-and-shift. Although Google Cloud supports service templates using its Deployment Manager, it doesn't yet provide the type of canned application environments delivered by the AWS and Azure quickstarts.

My take

The three major cloud providers are addressing the problem facing enterprise infrastructure designers and application developers when migrating systems or designing for the cloud with architectural principles and design blueprints. However, there's much left to do. As illustrated at re:Invent, each continues to add services and options faster than most enterprise IT people can assimilate them.

As the cloud evolves from an era of experimental dynamism to one of predictable productivity, providers must devote as much time, effort and attention to usability, convenience, and practicality with both technological and educational services that address the quotidian needs of the business user.

Chief among these is lowering the barriers to effective, efficient and optimal use of the countless services they have spent recent years creating. Migration services and architectural guides are a useful start, but amidst the hype over new services, they seem like afterthoughts. Many organizations are still waiting for the cloud's iPhone moment where providers unleash the technology's power and flexibility while masking much of the complexity.