Defining a Cloud Reference Architecture

Joe Kinsella -

Reference architectures are used to define best practice templates for implementing hardware and/or software solutions. While they have traditionally been associated with physical infrastructure, they are just as indispensable in the cloud. A well defined reference architecture can be a critical tool for managing cost, performance and maintainability of your cloud infrastructure.

Objectives

Reference architectures can take many forms - e.g. a document, diagram, spreadsheet, code. At a minimum, the reference architecture should answer the following questions about an application architecture:

  • What cloud infrastructure needs to be deployed?
  • How is this infrastructure logically assembled?
  • How does this infrastructure scale up or down with usage?
  • How much does it cost?

A typical structure for a reference architecture will include the following:

  • Bill of materials - This should define the compute, storage and other services required by the different functional areas of an application. It should include specifics, such as instance types, virtual cores, memory, local storage, and attached storage.
  • Logical deployment model - Details on how to deploy this infrastructure, including use of cloud network and security controls such as firewall policies, VPCs, and VLANs.
  • Scale model - This defines the key criteria for scaling your applications (e.g. # of simultaneous users, # transactions per second), in order to allow modeling of infrastructure at different scales.
  • Cost model - This details the costs of the infrastructure, decomposed by categories relevant to your business. This should also model the different cloud pricing mechanisms you plan to take advantage of (e.g. reserved pricing, spot pricing).

Implementation

In my pre-cloud experience, most reference architectures became obsolete by deployment. The slower pace of change with physical infrastructure makes it much less critical to maintain an up to date blueprint for hardware and software infrastructure. But with the cloud, changes can occur to daily or even hourly that affect cost, performance and maintainability of infrastructure - potentially impacting both customers and business plans.

To ensure your cloud reference architecture stays relevant, capture it in two forms: an electronic document that can be shared between the business and technical teams, and automation code that implements this blueprint. The electronic document (e.g. spreadsheet) will enable clear communication and transparency across teams, allowing for the broader organization to engage in the micro-decisions that affect application infrastructure in the cloud. But once the document is in place, it is critical to codify it through your automation infrastructure (e.g. Chef, Puppet). As changes are made to the architecture, they can be reflected back in the code; as configuration changes are made to the code, they can be reflected back in the blueprint.

I know someone out there is thinking: do we really need an electronic document to capture our reference architecture? Isn’t code documentation?  Ah... no. ;)

Conclusions

A cloud reference architecture can be an essential mechanism to drive alignment between engineering, operations, product management and finance. For engineering, it represents the recommended deployment configuration to ensure application scalability and reliability. For operations, it provides the blueprint for what needs to be deployed, and a playbook for managing performance and cost. For product management, it allows definition of cost of goods, and captures important non-functional requirements around performance and scale. For finance, it is an analysis tool, allowing forecasting of expenses based on growth.

Take the time to invest in a reference architecture to get the most scalability, supportability and cost effectiveness out of your cloud infrastructure.