Whatever the right specification, the core notion is that we would treat each layer differently, understanding that the lower-level or primitive layers support the layers above, so they should be extremely fault-tolerant and scalable. The higher layers are closer to the application instances or solutions and are treated accordingly. You can work the same angle with security and governance -- each layer is treated differently based on its purpose and mission.
There's no magic here or anything new. We've been layering architecture for years, and I'm sure the layering concept is on the white boards of most cloud computing providers. But it needs to be explicit in the services, too. If we can map most cloud computing services to clearly understandable domains, we can begin to manage and evaluate those layers differently, considering the differing degrees of importance.
As a result, we may have fewer consequences when failure does occur.
This article, "The lesson from the Amazon outage: It's time to layer the cloud," originally appeared at InfoWorld.com. Read more of David Linthicum's Cloud Computing blog and track the latest developments in cloud computing at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.