上QQ阅读APP看书，第一时间看更新

Foundation for design – the cloud is economic, not technical

Contrary to what most believe, the cloud is not a technological innovation; it is an economic one. Although the cloud is based on virtualization technology, virtualization is not a new technology. Virtualization has been around for more than 50 years, starting with IBM mainframes in the early 60s, namely the CP-40. For decades, we have been trying to match better hardware and system utilization to the task or workload we are working to complete. Virtualization started with scientists and mathematicians from both IBM labs and MIT trying to perform complex calculations. They were trying to get more work done and, at the time, one task was limited to one system. IBM came up with the idea of virtualizing memory, which creates separate instances and completing more tasks could take place in the same amount of time. The birth of virtualization happened around 1963, with the first commercially available virtualized system going to market around 1967.

This book often discusses the fact that strategy, technology, and economics must align for successful design. Cloud computing and virtualization are not technical innovations. They are not strategic innovations, as the strategy of utilizing computing to its fullest extent, at its lowest possible cost, has been around as long as or longer than virtualization. The cloud is truly an economic innovation. The cloud was not a technical problem; it was a billing problem. The problem was that people could not find a way to accurately bill for a fraction of a processor or a fraction of RAM for a fraction of the time; a second, a minute, or so forth. The real innovation came when an instance of compute could be consumed for a period of time at a specified cost, with the ability to shut it off and give it back and only be billed for resources and time used (everyone considers Amazon Web Services as the early IaaS pay-as-you-go model). It is the ability to consume expensive compute on a pay-as-you-go model (OPEX versus CAPEX). It eliminated the need for massive capital up front and extended the growing movement of as-a-service models.

Much time and effort are spent aligning strategy, economics, and technology early in the book, because the cloud requires a new skill set, a new thought process, and a new approach to design. Successful architectures must simultaneously solve for strategic, economic, and technical requirements. A technically perfect design that is too expensive equates to poor design. A technically perfect design that is economically feasible may solve for the wrong strategy, also equating to poor design. All three must simultaneously resolve before the design can be viewed as successful. Because of this, cloud architects require a new thought process: a process of reflection that systematically navigates in layers utilizing discriminating attributes and characteristics rather than service names and marketed functions. Cloud architects need an updated skill set that includes economics and risk strategy, along with their technical prowess. Successful cloud architects must think more like selling CFOs than technical geniuses. Successful cloud architects need to be aware of the associated risks to the business if proposed changes are implemented. What is the impact on the business economically, short-term and long-term? What cultural impact will the changes have in the business, business unit, or pision? Will personnel be affected? Does the company structure need to change? As you can see, technical information is no longer enough for the cloud architect. Cloud architects must be as comfortable in strategy conversations as they are in a technical one. Business finance and economics training are equally as important as, if not more important than, technical training.

Because the cloud is an economic innovation, and not a technical one, we quickly see that technical information will be pushed later towards the end of the thought process. In many cases, technical information becomes the tiebreaker, rather than the requirement. If you start with a good set of non-negotiable, and work through basic ideas and their economic impact, you can quickly see what fits strategically and what doesn't. If there are too many solutions, you can change requirements, potentially optimize strategy, revisit economic requirements, and so on. No one is saying that technical information is not required or valuable. The idea is to use technical detail to fine-tune, optimize, and perfect; think of a modern robot-driven, laser-guided surgical scalpel, as opposed to a medieval broadsword.

The cloud architect thought process is as shown in the following diagram:

Every building project requires a solid foundation. Cloud design is no different. It is costly and difficult to change directions part-way through. Think of a high-rise building. It is tough to be twenty floors into construction and find there was a fatal flaw in the foundation, requiring the whole project to be torn down and started over. In cloud design, several elements create the base for a successful design. Many modern day designers begin with basics, such as storage, compute, or perhaps the network. They gradually get deeper and deeper technically, never knowing if they are headed in the wrong direction or not, unless they get told no by someone else who owns strategy or the project budget. This framework changes that dynamic. Technical elements come later in the process. This updated cloud architect thought process begins with the base of things that are truly non-negotiable. Non-negotiable constraints include things such as legal requirements, geography, sector and industry-specific requirements, project goals, strategic elements, and so on. These limitations form the basis on which everything else is built. If any of these elements can change, they are not true requirements and they certainly cannot be labeled non-negotiable. Once an exact set of non-negotiable are set, we can then look at additional details that will help define overall success factors, including basics such as business drivers, strategy, value prop, economic models, and corporate/industry preferences. Every design will follow the same thought process, beginning with non-negotiable constraints working upward through each layer as data and insight satisfy the objectives and constraints of the previous tier.

Every situation, scenario, design, and component will follow the same thought process and the same line of questioning:

What are the non-negotiable constraints and characteristics?
What are the economic attributes and their impact?
How does this affect strategy?
What is the discriminating technical attributes and characteristics?
Is there an abnormal or excessive risk associated and does it affect economics?