14548 (15520) Enmienda de modificación. Sección 14

Let’s begin with a discussion about broad types, or patterns, of high-scale applications and how they do or don’t fit well into the model of cloud computing. The categories we’ll consider are called transference, internet scale, burst compute, and elastic stor- age. These are the most common application patterns that motivate a move to the cloud to deal with high scale (lots of users, lots of compute, lots of data, or rapid swings of any of these). We’ll look at these in order, first defining the category followed by a short discussion of the issues to watch out for.

5.1.1 Transference

Transference is when you take an existing on-premises application and move it to the

cloud as is. This pattern is typically driven by economic factors (as you’ve read earlier in this book). It can be cheaper to use cloud resources than to run these applications in-house if you’re not fully employing virtualization for higher utilization in your local data center. Commodity services, such as email, CRM , and other packaged applica- tions, are candidates for this pattern.

Zillow.com —a website dedicated to providing consumers accurate expected home values on any U.S. residential address—is a small business that moved its application as is to the cloud because it couldn’t afford the servers needed to process the large number of changes in home values across the entire country when the housing market bubble burst. It had a huge spike in compute work it needed to accomplish but didn’t want to buy the necessary servers because they would be excess capacity in a few weeks.

When the transference pattern is the appropriate one to use, you need to watch out for customizations that work in your local data center but that the host/cloud doesn’t support. For example, if the application depends on a custom device driver you built for Linux, you won’t be able to transfer this application to a cloud: cloud providers won’t allow you to re-create that device driver modification in their Linux implementation. This aside, you’ll find no other design issues with this pattern, and it won’t get further coverage in this chapter.

5.1.2 Internet scale

The internet scale design pattern involves creating an application for the cloud that has the ability to handle huge numbers of users, such as YouTube , Flickr , or Facebook ,

without requiring the corresponding substantial capital investment from day one. This is a common pattern for prototyping new applications because it allows a significantly lower entrance cost (no servers are being purchased). It also lets you start very small yet expand when needed.

When Facebook started, it was run off a single server and serviced only Harvard University students. Facebook built its own data center on its way to supporting 400 million users. If the cloud had existed, the company would have avoided a few growing pains caused by data center and application limitations along the way. Twitter also started as one guy on one server; and because it resonated with people, it grew at an unprecedented pace. It faced many outages because of scaling problems . If you’re a small company with big visions of building a service that people want, you need to think hard about starting in the cloud with a strong, scalable design.

Finally, designing for and starting in a cloud is applicable as a risk-mitigation measure for applications with unpredictable growth. One of the most challenging design issues for this application pattern, when the application does have to scale, revolves around the database structure: without care, it quickly becomes the database that prevents scale. You’ll see how to address this issue in detail later in this chapter.

5.1.3 Burst compute

Applications that fit the burst compute pattern have the ability to handle additional compute capability on an as-needed basis without idle, over-provisioned resources. Applications ideal for this pattern have large swings in capacity requirements, particu- larly if the spikes are somewhat rare.

A good example is the site Eventseer.net. It routinely bursts out to Amazon ’s cloud to statically generate changed pages on its 600,000-page site because it doesn’t have the capacity internally to do this fast enough.

The burst compute pattern is driven by the economic factors of the cloud. The cost of additional hardware capacity required to support this pattern internally is prohibitive. Real bursts of load can be handled cost effectively in the pay-only-for-what- you-use cloud model. You’ll read about cloudbursting as a nice solution for the burst compute application pattern later in the chapter.

5.1.4 Elastic storage

In the elastic storage application pattern, applications have the ability to grow expo- nential ly from a storage perspective. Although local storage is relatively cheap, its management is fairly expensive. As a result, using a cloud platform can be a cheaper alternative to local storage management . But using this pattern requires careful thought and planning for accessing the data. For instance, if you’re using the cloud purely to store data, but processing it locally, performance may be unacceptable; that would make this pattern not applicable.

5.1.5 Summarizing the application patterns

Table 5.1 summarizes the five major cloud application patterns. Note that the sense of the word design we’re using in this chapter is the act of working out the form of some-

thing. And the word architecture is the structure and organization of a computer’s hardware or system software.

Table 5.1 Summary of the five major cloud-scaling application patterns, their major issues, and the section in which they’re discussed

Pattern Description Major issues Section

Transference Existing on-premises application moved to the cloud as is for economic benefits

Application customizations may not transfer or work.

N/A

Internet scale New web-facing applications with unpredictable growth

Database design can throttle growth; consider sharding.