Cloud Architecture (Part I)

Hesam Seyed Mousavi, September 11, 2013

Image

Source: Microsoft architectural resources

This article focuses on the development of cloud-native applications. A cloud-native application is architected to take advantage of specific engineering practices that have proven successful in some of the world’s largest and most successful web properties. Many of these practices are unconventional, yet the need for unprecedented scalability and efficiency inspired development and drove adoption in the relatively small number of companies that truly needed them. After an approach has been adopted successfully enough times, it becomes a pattern. In this article, a pattern is an approach that can be duplicated to produce an expected outcome. Use of any of the patterns included in this article will impact the architecture of your application, some in small ways, some in large ways.

Historically, many of these patterns have been risky and expensive to implement, and it made sense for most companies to avoid them. That has changed. Cloud computing platforms now offer services that dramatically lower the risk and cost by shielding the application from most of the complexity. The desired benefit of using the pattern is the same, but the cost and complexity of realizing that benefit is lower. The majority of
modern applications can now make practical use of these heretofore seldom used patterns.

The architecture patterns described in this article were selected because they are useful for building cloud-native applications. None are specific to the cloud. All are relevant to the cloud.

The Cloud-Native Application

This is a article for building cloud-native applications, so it is important that the term be defined clearly. First, we spell out the assumed characteristics of a cloud platform, which enables cloud-native applications. We then cover the expected characteristics of cloudnative applications that are built on such a platform using the patterns and ideas included in this article.

Cloud Platform Defined

The following characteristics of a cloud platform make cloud-native applications possible:

• Enabled by (the illusion of) infinite resources and limited by the maximum capacity of individual virtual machines, cloud scaling is horizontal.
• Enabled by a short-term resource rental model, cloud scaling releases resources as easily as they are added.
• Enabled by a metered pay-for-use model, cloud applications only pay for currently allocated resources and all usage costs are transparent.
• Enabled by self-service, on-demand, programmatic provisioning and releasing of resources, cloud scaling is automatable.
• Both enabled and constrained by multitenant services running on commodity hardware, cloud applications are optimized for cost rather than reliability; failure is routine, but downtime is rare.
• Enabled by a rich ecosystem of managed platform services such as for virtual ma chines, data storage, messaging, and networking, cloud application development is simplified.

While none of these are impossible outside the cloud, if they are all present at once, they are likely enabled by a cloud platform. In particular, Windows Azure and Amazon Web Services have all of these characteristics. Any significant cloud platform—public, private, or otherwise—will have most of these properties.

The patterns in this article apply to platforms with the above properties, though many will be useful on platforms with just some of these properties. For example, some private clouds may not have a metered pay-for-use mechanism, so pay-for-use may not literally apply. However, relevant patterns can still be used to drive down overall costs allowing the company to save money, even if the savings are not directly credited back to specific applications.

Where did these characteristics come from? There is published evidence that companies with a large web presence such as eBay, Facebook, and Yahoo! have internal clouds with some similar capabilities, though this evidence is not always as detailed as desired. The best evidence comes from three of the largest players—Amazon, Google, and Microsoft who have all used lessons learned from years of running their own internal high capacity infrastructure to create public cloud platforms for other companies to use as a service.

Cloud-Native Application Defined

A cloud-native application is architected to take full advantage of cloud platforms. A cloud-native application is assumed to have the following properties, as applicable:

• Leverages cloud-platform services for reliable, scalable infrastructure. (“Let the platform do the hard stuff.”)
• Uses non-blocking asynchronous communication in a loosely coupled architecture.
• Scales horizontally, adding resources as demand increases and releasing resources as demand decreases.
• Cost-optimizes to run efficiently, not wasting resources.
• Handles scaling events without downtime or user experience degradation.
• Handles transient failures without user experience degradation.
• Handles node failures without downtime.
• Uses geographical distribution to minimize network latency.
• Upgrades without downtime.
• Scales automatically using proactive and reactive actions.
• Monitors and manages application logs even as nodes come and go.

As these characteristics show, an application does not need to support millions of users to benefit from cloud-native patterns. Architecting an application using the patterns in this article will lead to a cloud-native application. Applications using these patterns should have advantages over applications that use cloud services without being cloudnative. For example, a cloud-native application should have higher availability, lower complexity, lower operational costs, better performance, and higher maximum scale.

Windows Azure and Amazon Web Services are full-featured public cloud platforms for running cloud-native applications. However, just because an application runs on Azure or Amazon does not make it cloud-native. Both platforms offer Platform as a Service (PaaS) features that definitely facilitate focusing on application logic for cloud-native applications, rather than plumbing. Both platforms also offer Infrastructure as a Service (IaaS) features that allow a great deal of flexibility for running non-cloud-native applications. But using PaaS does not imply that the application is cloud-native, and using IaaS does not imply that it isn’t. The architecture of your application and how it uses the platform is the decisive factor in whether or not it is cloud-native.

A cloud-native application is not the best choice for every situation. It is usually most cost-effective to architect new applications to be cloud-native from the start. Significant (and costly) changes may be needed to convert a legacy application to being cloudnative, and the benefit may not be worth the cost. Not every application should be cloudnative, and many more cloud applications need not be 100% cloud-native. This is a business decision, guided by technical insight.

Source: Microsoft architectural resources

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s