FREE MOBILE CLOUD
COMPUTING CONCEPTS - TRAINING_MODULES_WITH_TONS_OF_VIDEOS
Post by Harold McVellion with Hollywood IT Installers
and Builders
Lately I’ve been thinking a lot about Massively Scalable Data Centers.
These are the emerging data centers built by cloud service providers that may contain tens or even hundreds of
thousands of physical server machines. Throw a modest amount of server virtualization on top and you could have more than
a million end nodes in a single brick and mortar facility, or perhaps dispersed across a collection of internet connected
pods. Example: Microsoft, Google, Amazon
What’s interesting to me about this space is not just the massive scale (that too)
but mostly the cloud driven economics, new applications, changing traffic patterns, and the market disruptive architectures
and that will inevitably surface as a result. New start-ups might emerge with unique solutions for these very specific
customers.
Open source projects combined with a dumbed down network may lead to the full scale commoditization
of the network switch. Or perhaps a more intelligent cloud aware network will enable service providers to offer new
products and services, expanding into new markets.
Let’s start with the economics. Why on earth would anyone build and maintain
a facility with a hundred thousand or more servers? That must be incredibly expensive, right? It certainly is!
James Hamilton of Amazon points out: The majority of overall data center costs come from acquiring servers with short amortization cycles — not the network.
The fact
is, this is probably the case for data centers of all sizes; big, medium, and small. And therein lies the economic opportunity
for both the cloud service provider and their customers.
For the IT Manager or Software Developer, why buy a bunch of servers for
“Application X”, absorbing all of that cost and months of deployment effort, when you can instead run your application
today on somebody else’s servers? Paying only for what you really need (CPU, Bandwidth, Storage), and only
pay for the amount you use.
What was once unthinkable (or at best laughable) just five years ago is now
a real option worth serious consideration. Understanding the obvious security concerns, not every application may be
considered today, but other server hungry data crunching apps could be perfect candidates. With time, the security protections
offered by the service provider will only get better, thus creating more opportunities for more applications.
To make a compelling
case, the cloud service provider sets up an infrastructure that can run Application X orders of magnitude cheaper, instantly
provisioned, and backed by the performance and elasticity of a massive data center. The consumer is saving time and
lowering costs, while the service provider is making money.
It’s a win-win. Sounds nice, but
how is this possible? And what does this have anything to do with massive scale?
What makes this work is the universal truth that a
server which is idle and unused is a server wasting money. Think of the server as an “Opportunity”
to achieve a “Result”. As in life, every opportunity has an associated cost, an “opportunity cost”,
being a prerequisite to realizing results.
Furthermore, the opportunity cost is decoupled from the subsequent
results achieved. For example, if you buy a business for $10,000 – whether or not you subsequently make $1 million
or go bankrupt (the result) doesn’t change the fact that your opportunity cost was $10,000.
The same
fundamental principal is true for data centers and servers. Every cost required to get a server in a rack, powered up, cooled,
connected, managed, and ready to begin its first transaction represents the opportunity cost incurred regardless if the server
is subsequently 10% utilized or 100% utilized (the result). The server with 10% utilization has wasted 90% of its opportunity
cost (money).
Higher opportunity costs mean more money wasted.
I’ll refer to this as the “Actual Efficiency”,
which would be calculated as follows:
Result / Opportunity Cost = Actual Efficiency
For the IT Manager or Software Developer who chooses
to purchase and deploy their own servers for Application X, maximizing Actual Efficiency means perfectly predicting the number
of servers required such that all servers are at or near 100% utilization.
The more time and engineering
resources spent calculating these server requirements increases the opportunity costs, thereby lowering the Actual Efficiency
of the effort. Provisioning extra servers as a “cushion” to handle spikes in load also increases opportunity
costs and lowers Actual Efficiency.
To execute perfectly would require guessing with little effort and 100% accuracy,
which of course is not humanly possible. But what if you could eliminate the need to perfectly predict server requirements?
What about that costly “cushion”? Can you remove both from the efficiency equation and make that somebody else’s
problem? Yes.
That’s where the cloud service provider steps in.
The IT Manager or Software Developer
(Consumer) can choose to run Application X on the cloud service provider’s infrastructure, radically simplifying the
opportunity costs to the actual consumption of commodity: CPU, Bandwidth, and Storage.
The cloud service
provider takes on the complexity and costs of calculating and deploying server requirements. Underutilized servers represent
money wasted by the service provider, not the consumer.
Sounds great,
right? However if the service provider is not able to do a much better job of Actual Efficiency than the consumer, remaining
profitable would require passing on higher costs to the consumer, which would ultimately defeat the whole purpose. We
know that this business model is working today, so how is this possible?
Is the service provider that much
smarter than the consumer, super-human or something, perfectly guessing with 100% accuracy? Not necessarily. Rather,
the service provider has some distinct advantages and financial motivations.
1) Excess CPU capacity
can be sold on a global market (advantage)
2) The economies of massive scale (advantage)
3)
Vested interest in efficiency (motivation)
4) Efficiency competition among other service providers (motivation)
For the service
provider, it’s all about Actual Efficiency; the business model depends on it. To remain profitable requires highly
utilized servers and low opportunity costs. In achieving those outcomes, the service provider data center has a distinct
advantage over the typical consumer data center.
Server CPU resources are available to a global market of
consumers, rather than a singular consumer. Furthermore, a global market of consumers provides the opportunity to build
larger, massively scalable data centers, thereby leveraging economies of scale. More servers can be managed by fewer
people, power can be converted more efficiently at Megawatts of scale, and bulk purchasing power can negotiate lower equipment
costs.
Meanwhile,
new application platforms provide the ability to process huge amounts of data in shorter periods of time using a distributed
computing model.
Rather than processing data in a serial fashion on a single machine (Application > OS
> Server), application platforms leveraged in the service provider data center such as Hadoop using computational paradigms like MapReduce allow applications to process large amounts of data in parallel, on many machines at once (Application > Platform
> Lots of Servers), providing incredible performance across an array of low cost throw-away commodity servers. This
means a larger data center with a larger network.
More importantly, given that arrays of servers now collectively
behave as single CPU, the result is significantly more server-to-server (east-west) traffic when compared to the classic serial
processing model.
So if it’s true that massively scalable data centers and highly utilized servers is the way forward, how do
we build the network for this new paradigm? Do we build it the same old way it’s always been done before, just
bigger? I’m afraid it’s not going to be that easy. Given that the applications and traffic
patterns have changed, the scale has changed; it’s time for the network architecture to change as well.
Before we start
to define what this new architecture might look like, let’s take a look at some of the stated goals and requirements
of the new massively scalable data center.
Profitability: Highly utilized servers
Agility:
Any service on any server, at any time. Workload mobility.
Uniform Capacity:
consistent high bandwidth and low latency between servers, regardless of physical location and proximity
Manageability:
Plug & Play, zero touch provisioning, minimal configuration burden, minimal human interaction.
Modularity:
easily expand or shrink with modular building blocks of repeatable pods
Scalability:
millions of IP and MAC addresses from hundreds of thousands of servers each with virtual machines
Profitability
requires highly utilized servers. To have highly utilized servers requires extreme amounts of Agility in workload
placement and mobility. Any pockets of underutilized servers should be able to relieve load from any other servers with
overwhelming load.
A server’s location in the network should be irrelevant to its ability to run any
service at any time. To achieve such Agility assumes transparency from the network not only in the server’s
address (IP/MAC), but also just as important is transparency in performance (bandwidth, latency). A server’s location
in the network should be irrelevant to the performance it can deliver to any assigned service; Uniform Capacity.
In other words,
first and foremost, the network should not get in the way of the cloud achieving peak performance and profitability.
That part should be table stakes for any architecture moving forward.
Today’s current architectures fall way short of that goal.
James Hamilton of Amazon writes: Data center networks are in my way. James perfectly describes from a cloud service provider point of view how today’s data center networks at
large scale result in compromises of Agility, which ultimately affect his Profitability....and the march
to the cloud will only grow....
