When Worlds Collide #2: HTML5 + Cloud = Elasticity²

In a previous post I’ve written about the dual revolutions going on in web applications: HTML5 and devices on the front end, and cloud computing on the back end—how they influence each other and are together changing the design of modern web applications. In this post I’ll talk about an aspect both share, elasticity.

Elastic Scale of the Cloud

Elasticity is a term frequently used in cloud computing. Amazon Web Services even named their compute service “Elastic Compute 2”. Elasticity means we can allocate or drop resources at will: if we need more servers or more storage, we ask for the resources we want and have them minutes later, ready to use. If we’re done with a resource, we release it and stop paying for it. This is all self-serve, mind you: there’s no bureaucratic process or personnel to go through. Elasticity is one of those defining characteristics that sets true cloud computing apart from traditional hosting.

Using the Windows Azure platform as an example, there are several levels of elasticity available to us. The elasticity most often spoken of is the ability to change the number of VM instances in the roles (VM farms) that make up your hosted cloud application. There are other areas we can consider elastic as well: we can make our individual VMs larger or smaller, choosing from 5 different VM sizes that give us varying amounts of cores, memory, and local storage. We can choose from a variety of database sizes. We can even scale our application to a global level by deploying it to multiple data centers around the world and using a traffic manager to route access, based on locale or other criteria.

Elastic scale can be enlisted manually, where you simply request the changes you want interactively; or it can be automated, where you programmatically alter the scale of your cloud application. You might change the size of your deployment based on activity levels you are monitoring; or you might be able to anticipate load changes by something very predictable like the calendar and well-known seasonal patterns of behavior. Elasticity isn’t just important for scale reasons: it’s also an essential ingredient in the cloud’s cost model, where you only for what you use and only use what you need.

You can think of the cloud, then, as a very big rubber band: one that lets you run as small as a tiny, barely-costs-anything “caretaker” deployment all the way to global scale that can service millions. A change you could put in effect the same day you discerned the need for it, by the way.

Elastic Experiences in HTML5

Although we often use different words for it, web applications can be elastic too—but in a different way. Modern web sites can and should be responsive: that is, adaptive to a variety of devices, screen sizes, aspect ratios, and input methods. The philosophy, movement, and features behind HTML5 promote and enable this notion of elastic experience. While it’s not uncommon today to implement web applications individually for browsers and mobile devices (either as m. sites or native device applications), where we’re heading is to more typically implement a site once that runs on a PC browser as well as a touch tablet or phone. As our world becomes more and more about smaller devices and larger screens, and using more than one device to access that world, this “write once, run anywhere” approach is simply to going to make more and more sense and minimize expense. Not always, but much of the time.

The elasticity of experience is not only about adapting to smaller size or larger screens, though: there are a host of related considerations. Layouts have to change to suit aspect ratio and orientation; the form of input and navigation can vary from mouse and keyboard to touch; some font choices are unusable or look ridiculous on extremely small or large displays; some functional aspects (such as the availability of JavaScript) aren’t always available. What is needed then is more than mere fluid layout: applications need to make intelligent decisions about many things in order to maximize their usefulness and usability in whatever context they find themselves. Historically there has been a widespread belief in the need for “graceful degradation,” where you give up features and aspects of the intended experience with more limited devices; the new thinking turns this around to say we begin with a very decent and tuned experience even on limited devices and practice “progressive enhancement” as we get larger screens and the availability of more features. For a very good treatment of this subject, see Ethan Marcotte’s inspiring article and book on Responsive Web Design.

So you can also think of web sites done in the spirit of HTML5 as a rubber band, too: one that’s all about the elasticity of layout, navigation, and progressive enhancement, providing good experiences without compromise that bring out the best in whatever device you happen to be using today. Actually, a more fitting analogy than a rubber band is a gas. A gas? That’s right; remember what you learned about gases in high school physics? A gas will expand in volume to fill its container no matter what its size and shape. Go and do likewise. And you thought you’d never use Boyle’s Law in real life!

Elasticity Squared: The Combined Effect

As we’ve seen, both the front and the back end of modern web applications share this characteristic of elasticity. There are even more dimensions of elasticity we could discuss, such as the elasticity of data, but we’ll save that discussion for another time.

In software design, as in many areas of life, there is often the “can’t see the forest for the trees” problem where you have to decide whether to focus on the big picture of how you serve your user constituency vs. the individual experience you are providing. All too often one gets attention and not the other on projects. When you join the new web with cloud computing, you bring together two disciplines that naturally pay attention to each area. Together, HTML5 and cloud computing bring elasticity to both the individual and the community they are a part of.

Next: When Worlds Collide, Part 3: HTML5 + Cloud = Location, Location, Location