Your quick guide to a successful cloud architecture
February 24, 2012
Technology vendors like to sell "guaranteed" success for building your own cloud computing service, whether public, private, or hybrid. Don’t believe them. In my consulting work, I find the path to success is not that straightforward.
But there is a path to success, and based on my experience, here’s my set of guidelines for the definition, design, and implementation of cloud computing solutions. It should at least push you in the right direction…
First, focus on the primitives. The best cloud deployments are sets of low-level services that can be configured into solutions. I’ve previously noted that poor API design is a cloud-killer and described the right way to define and design a cloud API. That’s where you need to focus. Good cloud computing technologies are really sets of very primitive API services. It’s the fine-grain design of these services that provides the user with more options — and value.
Second, use distributed components that are centrally controlled. The idea is to create a federated solution that you can configure in many different ways. However, there has to be a central brain controlling it all. Many organizations build their cloud services too tightly or too loosely coupled. You need to find the right balance.
Third, build for tenants, not users. There’s a difference between the two. Multiuser design and architecture, including their underlying mechanisms, are very different than multitenant design and architecture. Allocate and manage resources — do not control access to data or applications.
Fourth, don’t lean too much on virtualization. It’s an enabling technology, not a path to cloud computing architecture. You need to understand the difference. In fact, many cloud deployments don’t use virtualization for the profound reason that it’s not a de facto cloud requirement. Use it where it helps, not just because you think cloud equals virtualization.
Finally, security and governance are systemic. I know I sound like a broken record, but security and governance can’t be an afterthought. You have to build in these capabilities through the architecture, design, and development processes.