The document provides an overview of cloud computing by discussing key topics across six parts:
Part one discusses how cloud computing has disrupted IT by democratizing access. Part two covers the history of virtualization. Part three explains how cloud stacks separate concerns between physical infrastructure, virtual platforms, and applications. Part four frames clouds as an on-demand business model compared to traditional IT. Part five outlines the major types of cloud services including IaaS, PaaS and differences between them. Finally, part six notes that in reality, most cloud offerings blend aspects of infrastructure, platforms and software as a service.
30. For much of its history, AT&T and its Bell System functioned as
a legally sanctioned, regulated monopoly.
The US accepted this principle, initially in a 1913 agreement
known as the Kingsbury Commitment.
Anti-trust suit filed in 1949 led in 1956 to a consent decree
whereby AT&T agreed to restrict its activities to the regulated
business of the national telephone system and government
work.
Changes in telecommunications led to a U.S. government
antitrust suit in 1974.
In 1982 when AT&T agreed to divest itself of the wholly owned
Bell operating companies that provided local exchange service.
In 1984 Bell was dead. In its place was a new AT&T and seven
regional Bell operating companies (collectively, the RBOCs.)
http://www.corp.att.com/history/history3.html
63. Virtualization divorces the app from the machine.
One on many
Virtual machine
Physical Physical Physical
machine machine machine
Physical Physical Physical
machine machine machine
64. Virtualization divorces the app from the machine.
One on many (or)
Virtual machine
Physical Physical Physical
machine machine machine
Physical Physical Physical
machine machine machine
65. Virtualization divorces the app from the machine.
One on many (or) Many on one
Physical machine
Virtual machine
Virtual Virtual Virtual
Physical Physical Physical machine machine machine
machine machine machine
Virtual Virtual Virtual
Physical Physical Physical machine machine machine
machine machine machine
100. • 60 seconds per page
Desktop EC2 • 200 machine
Pages 17,481 17,481 instances
Minutes/page 1 1 • 1,407 hours of virtual
# of machines 1 200 machine time
Total minutes 17,481 • Searchable database
Total hours 291.4 26.0 available 26 hours
Total days 12.1 1.1 later
• $144.62 total cost
107. Machine
Image
Web Machine
server Image
Machine instance
108. App Machine
Server Image
Machine instance
Web Machine
server Image
Machine instance
109. Machine
Image
App Machine
Server Image
Machine instance
Web Machine
server Image
Machine instance
110. DB Machine
server Image
Machine instance
App Machine
Server Image
Machine instance
Web Machine
server Image
Machine instance
111. DB Machine
Storage
server Image
Machine instance
App Machine
Server Image
Machine instance
Web Machine
server Image
Machine instance
112. DB
Storage
server
Machine instance
App
Server
Machine instance
Web
server
Machine instance
113. DB
Storage server
Bigger
machine
instance
App
Server
Machine instance
Web
server
Machine instance
114. DB
Storage
server
Machine instance
App
Server
Machine instance
Web
server
Machine instance
115. DB DB
Storage
server server
Machine instance Machine instance
App App
Server Server
Machine instance Machine instance
Web Web
server server
Machine instance Machine instance
116. DB DB
Storage
server server
Machine instance Machine instance
App App
Server Server
Machine instance Machine instance
Web Web
server server
Machine instance Machine instance
Load
balancer
Machine instance
117. Platform as a Service
Google App Engine, Salesforce Force.com,
Rackspace Cloud Sites, Joyent Smart Platform,
(and nearly every enterprise mainframe.)
122. Shared components
Data Processing platform
Storage
API
Others’ Others’
code code
Your Others’
code code
Others’ Others’
code code
123. Shared components
Data Processing platform
Storage
API
Others’ Others’
code code
User Auth
database API
Your Others’
code code
Others’ Others’
code code
124. Shared components
Data Processing platform
Storage
API
Others’ Others’
code code
User Auth
database API
Your Others’
code code
Image Image
functions API Others’ Others’
code code
...
125. Shared components
Data Processing platform
Storage
API
Others’ Others’
code code
User Auth
database API
Your Others’
code code
Image Image
functions API Others’ Others’
code code
...
Big Blob
objects API
126. Shared components
Data Processing platform
Storage
API
Others’ Others’
code code
User Auth
database API
Your Others’
code code
Image Image
functions API Others’ Others’
code code
...
Big Blob Governor
objects API
127. Shared components
Data Processing platform
Storage
API
Others’ Others’
code code
User Auth
database API
Your Others’
code code
Image Image
functions API Others’ Others’
code code
...
Big Blob Governor Console
objects API
128. Shared components
Data Processing platform
Storage
API
Others’ Others’
code code
User Auth
database API
Your Others’
code code
Image Image
functions API Others’ Others’
code code
...
Big Blob Governor Console Schedule
objects API
135. IaaS and PaaS differences
IaaS PaaS
Any operating system you Use only selected
want languages and built-in APIs
Limited by capacity of Limited by governors to
virtual machine avoid overloading
Scale by adding more Scaling is automatic
machines
Use built-in storage
Many storage options (file (Bigtable, etc.)
system, object, key-value)
136. Quota Limit
Governor Apps per developer 10
(usage cap) Time per request 30s
Blobstore (total file size) 1GB
Maximum HTTP response size 10MB
Datastore item size 1MB
Application code size 150MB
Daily cap Emails per day 1,500
(free quota) Bandwidth in per day 1 GB
Bandwidth out per day 1GB
CPU time per day 6.5h
HTTP requests per day 1,300,000
Datastore API calls per day 10,000,000
URLFetch API calls per day 657,084
http://en.wikipedia.org/wiki/Google_App_Engine
147. Service What it does
Elastic Compute Cloud Virtual machines, by the hour
Elastic Mapreduce Massively parallel data processing
Virtual Private Cloud On demand machines within internal IT
Elastic Load Balancing Traffic distribution
Cloudfront Content delivery acceleration
Flexible Payments Service Funds transfer & payments
SimpleDB Realtime structured data queries
Simple Storage Service Eleven nines redundant storage
Relational Database Service On-demand RDBMS
Elastic Block Store Block-level storage (file system)
Fulfillment Web Service Merchant delivery system
Simple Queue Service On-demand message bus
Simple Notification Service System for sending mass notifications
Cloudwatch Monitoring of cloud resources
Mechanical turk Humans as an API
148. Service What it does
App Engine Executing Python or Java code
Bigtable datastore Store data for very fast retrieval
Calendar Data API Create and modify events
Inbox feed API Read a GMail inbox
Contact data API Interact with someone’s GMail contacts
Documents list API Manage a user’s Google Docs
OpenID single signon Use Google authentication to sign in
Secure data connector Link Google Apps to enterprise apps
Memcache Fast front-end for data
Image manipulation Resize, rotate, crop & flip images
Task queue Queue and dispatch tasks to code
Blobstore Serve large objects to visitors
193. Expense reports can no
longer enforce IT
policy.
Wiley GAAP 2010: Interpretation and Application of Generally Accepted Accounting
Principles (By Barry J. Epstein, Ralph Nach, Steven M. Bragg)
194. Airfare
DNS
Cloud
Public
transit
Important
research
Hotel
223. Always on
premise
Private
Compliance-
enforced
Need to track and
audit
Legislative
Data near local
computation
224. Always on Can be done
premise anywhere
Private
Compliance- Testing
enforced
Training
Need to track and
Prototyping
audit
Batch processing
Legislative
Seasonal load
Data near local
computation
225. Always on Can be done Always in
premise anywhere cloud
Private
Partner access
Compliance- Testing
enforced Proximity to cloud
Training services (storage,
Need to track and
Prototyping CDN, etc.)
audit
Batch processing Massively grid/
Legislative
Seasonal load parallel (genomic,
Data near local modelling)
computation
226. Always on Can be done Always in
premise anywhere cloud
Load/pricing engine
Private
Partner access
Compliance- Testing
enforced Proximity to cloud
Training services (storage,
Need to track and
Prototyping CDN, etc.)
audit
Batch processing Massively grid/
Legislative
Seasonal load parallel (genomic,
Data near local modelling)
computation
227. Always on Can be done Always in
premise anywhere cloud
Load/pricing engine
Private
Partner access
Compliance- Testing
enforced Proximity to cloud
Training services (storage,
Policy engine
Need to track and
Prototyping CDN, etc.)
audit
Batch processing Massively grid/
Legislative
Seasonal load parallel (genomic,
Data near local modelling)
computation
228. Virtual machine
(infrastructure cloud)
Always on Can be done Always in
premise anywhere cloud
Load/pricing engine
Private
Partner access
Compliance- Testing
enforced Proximity to cloud
Training services (storage,
Policy engine
Need to track and
Prototyping CDN, etc.)
audit
Batch processing Massively grid/
Legislative
Seasonal load parallel (genomic,
Data near local modelling)
computation
229. Compute task
(service cloud)
Always on Can be done Always in
premise anywhere cloud
Load/pricing engine
Private
Partner access
Compliance- Testing
enforced Proximity to cloud
Training services (storage,
Policy engine
Need to track and
Prototyping CDN, etc.)
audit
Batch processing Massively grid/
Legislative
Seasonal load parallel (genomic,
Data near local modelling)
computation
Cloud computing is an approach to computing that’s more flexible and lets organizations focus on their core business by insulating them from much of the underlying IT work.
At its most basic, it’s computing as a utility – pay for what you need, when you need it, rather than paying for it all up front.
This is what Nicolas Carr talked about in his book The Big Switch.
But clouds can be confusing. Part of the reason is that they’re a big deal, which means everyone wants to be a part of them – even companies who have nothing to do with clouds.
I’m going to try and clear some of this up for you.
First, let’s talk about disruption.
Once, IT was a monopoly.
Today, it’s a free market. The line of business has tremendous choice in what it owns, runs, and uses.
The boardroom loves this: instead of managing machines, they manage services.
But enterprise IT doesn’t like it much, because it forces them to compete, and puts them side-by-side with organizations that spend their entire day doing detailed usage and billing.
It’s not all bad, though. There’s a lot to be learned from a transition from monopoly to a free market.
There were a couple of reasons IT was a monopoly for so long.
First, the machines were expensive. That meant they were a scarce resource, and someone had to control what we could do with them.
Second, they were complicated. It took a very strange sect of experts to understand them. AVIDAC, Argonne's first digital computer, began operation in January 1953. It was built by the Physics Division for $250,000. Pictured is pioneer Argonne computer scientist Jean F. Hall.
AVIDAC stands for "Argonne Version of the Institute's Digital Automatic Computer" and was based on the IAS architecture developed by John von Neumann.
This was also a result of scarcity. When computers and humans interact, they need to meet each other halfway. But it takes a lot of computing power to make something that’s easy to use;
in the early days of computing, humans were cheap and machines weren’t
So we used punched cards,
and switches,
and esoteric programming languages like assembler.
Think about what a monopoly means.
A monopoly was once awarded for a big project beyond the scope of any one organization, but needed for the public good.
Sometimes, nobody wants the monopoly—like building the roads.
For the most part, governments have a monopoly on roadwork, because it’s something we need, but the benefits are hard to quantify or charge back for.
(IT’s been handed many of these thankless tasks over the years, and the business has never complained.)
The only time we can charge back for roads are when the resource is specific and billable: a toll highway, a bridge.
Sometimes, we form a company with a monopoly, or allow one to operate, in order to build something or allow an inventor to recoup investment. This is how we got the telephone system, or railways.
When monopolies are created with a specific purpose, that’s good. But when they start to stagnate and restrict competition, we break them apart.
In fact, there’s a lot of antitrust regulation that prevents companies from controlling too much of something because they can stifle innovation and charge whatever they want. That’s one of the things the DOJ does.
In other words, early on monopolies are good because they let us undertake hugely beneficial, but largely unbillable, tasks.
Later, however, they’re bad because they reduce the level of creativity and experimentation.
Today, computing is cheap. We can buy many times the compute power of the Apollo missions with a swipe of a credit card.
It’s also not complicated. Everyone can use a computer. Because today, the computer is cheap and the human’s expensive we spend so much time on user interfaces, from GUIs to augmented reality to touchscreens to voice control to geopresence.
What used to take a long time to procure, configure, and deploy is now a mouseclick.
The way data centers are designed must reflect this shift from IT-as-a-monopoly to IT-as-an-enabler
That means building a set of platforms that can adapt and adjust:
From rack-and-stack servers to click-and-drag deployment
From underused bare metal to on-demand virtual machines
From procurement and process to self-service and quick decommissioning.
The lesson of monopolies is an important one. When a monopoly set out to build a railroad, it didn’t spend a lot of time asking potential travelers what they wanted.
When you’re building something huge and expensive, you build what you want, and expect people to be grateful for it.
But today’s IT user is driving IT requirements.
They can shop around—choosing SaaS, clouds, and internal IT according to their business requirements.
They’re increasingly able to build the applications themselves, but expect IT to deliver smooth, fast platforms on which to experiment.
As the line of business looks more and more like a consumer in a competitive market—and less and less like a grateful customer of a monopoly—IT has to change its offerings.
It’s an inversion of the traditional IT “pyramid”, where the hardware dictates the platforms, which in turn dictates, the apps, which dictates what users can do.
Today, what users want to do drives the apps they use, which drives the platforms and the hardware.
We’ve had big changes since that time. The first was client-server computing: the idea that not everything lived in a mainframe, and some things worked well on the desktop. Software like Visicalc—the first spreadsheet—were useful for businesses, even those who couldn’t afford a mainframe.
A second big change was the Web. This browser-based model made computing accessible to the masses. As a result, it became part of society, and everyone knew how to work it. These days, you don’t have to teach a new hire how to use a web browser: they know what links do; what the back button is; and so on.
A third change is the move to mobility. This has been bigger overseas, where the mobile phone is the dominant way of accessing the Internet, but it’s still a shift to the always-connected, always-on lifestyles we lead today.
And now there’s cloud computing. Clouds are as big a shift as client-server, or the web browser, or mobility.
The step-function nature of dedicated machines doesn’t distribute workload very efficiently.
Virtualization lets us put many workloads on a single machine
Once workloads are virtualized, several things happen. First, they’re portable
Second, they’re ephemeral. That is, they’re short-lived: Once people realize that they don’t have to hoard machines, they spin them up and down a lot more.
Which inevitably leads to automation and scripting: We need to spin up and down machines, and move them from place to place. This is hard, error-prone work for humans, but perfect for automation now that rack-and-stack has been replaced by point-and-click
Automation, once in place, can have a front end put on it. That leads to self service.
These are the foundations on which new IT is being built. Taken together, they’re a big part of the movement towards cloud computing, whether that’s in house or on-demand.
Okay, so these things mean we have applications that run “virtually” – that is, they’re divorced from the underlying hardware. One machine can do ten things; ten machines can do one thing.
Okay, so these things mean we have applications that run “virtually” – that is, they’re divorced from the underlying hardware. One machine can do ten things; ten machines can do one thing.
Okay, so these things mean we have applications that run “virtually” – that is, they’re divorced from the underlying hardware. One machine can do ten things; ten machines can do one thing.
This is the “technical” definition of cloud computing: virtualized, automated, self-service computing resources. Some people call this a “private cloud”; others think it’s just IT-done-right. Whatever the case, data centers are furiously retooling themselves, much to the enjoyment of companies like VMWare and Citrix.
Part three: Stacks and the separation of concerns
At its most simple, this is all about a “stack” of services. Stacks are a common idea in computing and networking. Basically, they’re a separation of different tasks.
We’re familiar with the idea of a stack. There’s a stack in the postal service.
You worry about the address, and the stamp. The postal service handles the rest—it doesn’t care what’s inside your envelope; and you don’t care what route your letter takes to its destination, as long as it gets there.
You worry about the address, and the stamp. The postal service handles the rest—it doesn’t care what’s inside your envelope; and you don’t care what route your letter takes to its destination, as long as it gets there.
You worry about the address, and the stamp. The postal service handles the rest—it doesn’t care what’s inside your envelope; and you don’t care what route your letter takes to its destination, as long as it gets there.
You worry about the address, and the stamp. The postal service handles the rest—it doesn’t care what’s inside your envelope; and you don’t care what route your letter takes to its destination, as long as it gets there.
You worry about the address, and the stamp. The postal service handles the rest—it doesn’t care what’s inside your envelope; and you don’t care what route your letter takes to its destination, as long as it gets there.
You worry about the address, and the stamp. The postal service handles the rest—it doesn’t care what’s inside your envelope; and you don’t care what route your letter takes to its destination, as long as it gets there.
You worry about the address, and the stamp. The postal service handles the rest—it doesn’t care what’s inside your envelope; and you don’t care what route your letter takes to its destination, as long as it gets there.
But wait -- there’s more! There’s another way to look at cloud computing.
Notice that so far, nothing I’ve said about clouds implies you can’t just run your own. Up until now, they’ve been DIY.
This is the clouds-as-a-business-model definition. In this, cloud computing is a third-party service.
All of the things we’ve seen about cloud technology make it possible to deliver computing as a utility -- computing on tap.
The virtualization provides a blood/brain barrier between the application the user is running, and the machines on which it runs.
That means you can focus on the thing your business does that makes you special
And stop worrying about many of the tasks you really didn’t want to do anyway.
Sharing and economies of scale keep costs down. Cloud providers are poised to make the most of these economies of scale. Consider that in July 2008, Microsoft revealed that it had 96,000 servers at the Quincy facility, consuming "about 11 megawatts"
More than 80% dedicated to Microsoft's Live Search and the remaining for Hotmail
In August, a really good discovery was posted to a blog called "istartedsomething.com":  a screen shot of a software dashboard that illustrates power consumption and server count at each of Microsoft's fifteen data centers, caught in a Microsoft video posted to their web site.
The move towards the cloud business model has a lot to do with the economies of scale that exist when you can concentrate infrastructure, and put it near dams. (There’s a good—if hotly debated argument—that clouds-as-a-business-model are inevitable, because of the economics.)
The move towards the cloud business model has a lot to do with the economies of scale that exist when you can concentrate infrastructure, and put it near dams. (There’s a good—if hotly debated argument—that clouds-as-a-business-model are inevitable, because of the economics.)
The move towards the cloud business model has a lot to do with the economies of scale that exist when you can concentrate infrastructure, and put it near dams. (There’s a good—if hotly debated argument—that clouds-as-a-business-model are inevitable, because of the economics.)
The move towards the cloud business model has a lot to do with the economies of scale that exist when you can concentrate infrastructure, and put it near dams. (There’s a good—if hotly debated argument—that clouds-as-a-business-model are inevitable, because of the economics.)
Cloud providers are thinking at a scale that nearly every enterprise can’t compete with. That’s because operating efficiency, and accounting for everything, are core to their business; whereas making widgets is core to yours.
Self-service means customers can deploy and destroy their own machines.
So while you can build an automated, self-service, on-demand private cloud, there are also many public options (is that a bad word in DC? )
Most of the time, when you hear someone say they’re concerned about the security of cloud computing, they’re talking about public clouds, and the issues that come with putting your data somewhere virtually but not knowing where it is physically.
So far, while I’ve told you a lot about clouds, I haven’t really told you what they are. That’s partly because there are many kinds of cloud computing.We can separate clouds into three distinct groups.
The first is called Infrastructure as a Service, because you’re renting pieces of (virtual) infrastructure.
This is what IT people think of when you say “clouds” – virtual machines I can use for just an hour. Here’s Amazon’s “menu” of machines.
A great example of these clouds in action is what the Washington Post did with Hillarly Clinton’s diaries during her campaign. They needed to get all 17,481 pages of Hillary Clinton’s White House schedule scanned and searchable quickly. Using 200 machines, the Post was able to get the data to reporters in only 26 hours. In fact, the experiment is even more compelling: Desktop OCR took about 30 minutes per page to properly scan, read, resize, and format each page – which means that it would have taken nearly a year, and cost $123 in power, to do the work on a single machine.
In an IaaS model, you’re getting computers as a utility. The unit of the transaction is a virtual machine. It’s still up to you to install an operating system, and software, or at least to choose it from a list. You don’t really have a machine -- you have an image of one, and when you stop the machine, it vanishes.
In an IaaS model, you’re getting computers as a utility. The unit of the transaction is a virtual machine. It’s still up to you to install an operating system, and software, or at least to choose it from a list. You don’t really have a machine -- you have an image of one, and when you stop the machine, it vanishes.
Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk
Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk
Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk
Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk
Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk
Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk
Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk
If you run out of capacity, you can upgrade to a bigger machine (which is called “scaling vertically.”)
If you run out of capacity, you can upgrade to a bigger machine (which is called “scaling vertically.”)
If you run out of capacity, you can upgrade to a bigger machine (which is called “scaling vertically.”)
Or you can create several machines at each tier, and use a load balancer to share traffic between them. These kinds of scalable, redundant architectures are common -- nay, recommended -- in a cloud computing world where everything is uncertain.
Or you can create several machines at each tier, and use a load balancer to share traffic between them. These kinds of scalable, redundant architectures are common -- nay, recommended -- in a cloud computing world where everything is uncertain.
Or you can create several machines at each tier, and use a load balancer to share traffic between them. These kinds of scalable, redundant architectures are common -- nay, recommended -- in a cloud computing world where everything is uncertain.
The second kind of cloud is called Platform as a Service. In this model, you don’t think about the individual machines—instead, you just copy your code to a cloud, and run it. You never see the machines. In a PaaS cloud, things are very different.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.
Here’s a shot of some code running in Google App Engine. I only know that I’m paying by CPU-hour, or for units like bandwidth, email, or storage. This could be one machine whose CPU was used 8%, or a hundred, or a thousand. I don’t know.
I can see the logs for my application. But these aren’t for a single machine -- they’re for the application itself, everywhere.
I can even find out what parts of my code are consuming the most CPU, across all machines.
And even their latency when served to people.
It’s a true, pure utility because you pay for what you use.
This is a very different model from IaaS. On the one hand, it’s more liberating, because you don’t have to worry about managing the machines. On the other hand, it’s more restrictive, because you can only do what the PaaS lets you.
In the case of Google’s App Engine, you have to use their functions and store things in the way they want you to. You get great performance from doing so, but it probably means rewriting your code a bit.
PaaS platforms impose usage caps and billing tiers. Here’s Google App Engine’s set of quotas and free caps.
In the case of Salesforce’s Force.com, you have to use an entirely new programming language, called Apex.
The third kind of cloud is called Software as a Service, or SaaS. Some people argue that this isn’t a cloud at all, just a new way of delivering software. But it’s also what the masses—the non-technologists—think cloud computing means.
(Personally, I think this makes the term “cloud” synonymous with “web” or “Internet”, and therefore a bit useless.)
(Personally, I think this makes the term “cloud” synonymous with “web” or “Internet”, and therefore a bit useless.)
(Personally, I think this makes the term “cloud” synonymous with “web” or “Internet”, and therefore a bit useless.)
SaaS and PaaS are blurring, too, with the advent of scripting languages. Nobody would argue that Google Apps is a SaaS offering; but now that you can write code for it -- as in this example of a script that sends custom driving directions to everyone in a spreadsheet -- the distinction is less and less clear.
But the business model of SaaS is the same as PaaS and IaaS: Sell IT on demand, rather than as software or machines.
It’s the form of cloud computing that gets the most lip service in areas like government, particularly with Google Apps.
This division between PaaS and IaaS is a bit of a fiction. In fact, virtual machines are just one of around twenty “cloud services” Amazon offers – called EC2.
The same is true of App Engine - though these are functions called from code, rather than services you pay for separately, they’re still more than just the code.
This is a really important concept: Clouds aren’t just virtual machines. Clouds are on-demand computing services.
To understand this, we need to talk for a minute about “composed designs.”
When IT architects want to build something, they have a set of proven designs for doing so. A database is an example of this—it’s a combination of storage (disk) and a particular way of arranging things (tables and indexes) and language (structured query language, or SQL). We’ve learned that a database is a good prefab building block, so we use it. The alternative is to build it all, from scratch, writing to the disk itself.
When IT architects want to build something, they have a set of proven designs for doing so. A database is an example of this—it’s a combination of storage (disk) and a particular way of arranging things (tables and indexes) and language (structured query language, or SQL). We’ve learned that a database is a good prefab building block, so we use it. The alternative is to build it all, from scratch, writing to the disk itself.
When IT architects want to build something, they have a set of proven designs for doing so. A database is an example of this—it’s a combination of storage (disk) and a particular way of arranging things (tables and indexes) and language (structured query language, or SQL). We’ve learned that a database is a good prefab building block, so we use it. The alternative is to build it all, from scratch, writing to the disk itself.
When IT architects want to build something, they have a set of proven designs for doing so. A database is an example of this—it’s a combination of storage (disk) and a particular way of arranging things (tables and indexes) and language (structured query language, or SQL). We’ve learned that a database is a good prefab building block, so we use it. The alternative is to build it all, from scratch, writing to the disk itself.
When IT architects want to build something, they have a set of proven designs for doing so. A database is an example of this—it’s a combination of storage (disk) and a particular way of arranging things (tables and indexes) and language (structured query language, or SQL). We’ve learned that a database is a good prefab building block, so we use it. The alternative is to build it all, from scratch, writing to the disk itself.
When IT architects want to build something, they have a set of proven designs for doing so. A database is an example of this—it’s a combination of storage (disk) and a particular way of arranging things (tables and indexes) and language (structured query language, or SQL). We’ve learned that a database is a good prefab building block, so we use it. The alternative is to build it all, from scratch, writing to the disk itself.
There are other examples of “composed designs” in IT, many of them made from several components. For instance, consider the “message bus.” This is a thing you put messages into, and anyone who wants them can grab a copy of the message. Stock exchanges use publish-and-subscribe message busses to move data around.
A third example is called a key-value data store. In this case, I put in a key (say, ”username”) and a value (say, “Palin”). Then it’s stored for me. It’s much less fancy than a database, but also much faster and more scalable, and can be backed up more easily so it’s more reliable.
When architects want to build an application today, they don’t do so by building everything from scratch. Today’s applications are built on the shoulders of giants—message busses, data stores, authentication systems, payment tools, content delivery networks, and so on.
As a result, cloud providers offer a variety of these services. Rackspace has a storage product called Jungledisk; Amazon has S3. The machines that Rackspace or Amazon offer “chew” on data from these storage services.
If you equate cloud computing with just virtual machines, you’re missing the real point. Clouds applications are built from composed designs, and one of the components happens to be virtual machines.
So let’s put this in perspective: There are public and private cloud models. Private ones are about the technology; public ones are about the business of outsourcing at scale.And there are Infrastructure, Platform, and Software offerings—IaaS, PaaS, and SaaS.
If someone wants to have a conversation with me about clouds, they need to pick a tier, and a private or public model. Then we can compare facts.
So let’s put this in perspective: There are public and private cloud models. Private ones are about the technology; public ones are about the business of outsourcing at scale.And there are Infrastructure, Platform, and Software offerings—IaaS, PaaS, and SaaS.
If someone wants to have a conversation with me about clouds, they need to pick a tier, and a private or public model. Then we can compare facts.
So let’s put this in perspective: There are public and private cloud models. Private ones are about the technology; public ones are about the business of outsourcing at scale.And there are Infrastructure, Platform, and Software offerings—IaaS, PaaS, and SaaS.
If someone wants to have a conversation with me about clouds, they need to pick a tier, and a private or public model. Then we can compare facts.
So let’s put this in perspective: There are public and private cloud models. Private ones are about the technology; public ones are about the business of outsourcing at scale.And there are Infrastructure, Platform, and Software offerings—IaaS, PaaS, and SaaS.
If someone wants to have a conversation with me about clouds, they need to pick a tier, and a private or public model. Then we can compare facts.
So let’s put this in perspective: There are public and private cloud models. Private ones are about the technology; public ones are about the business of outsourcing at scale.And there are Infrastructure, Platform, and Software offerings—IaaS, PaaS, and SaaS.
If someone wants to have a conversation with me about clouds, they need to pick a tier, and a private or public model. Then we can compare facts.
So let’s put this in perspective: There are public and private cloud models. Private ones are about the technology; public ones are about the business of outsourcing at scale.And there are Infrastructure, Platform, and Software offerings—IaaS, PaaS, and SaaS.
If someone wants to have a conversation with me about clouds, they need to pick a tier, and a private or public model. Then we can compare facts.
Just knowing these two dimensions makes you smarter than nearly everyone in IT right now. And when you’re discussing IT, insist that others are specific about what they mean. Discussions around privacy and security are vital to public clouds, but most people don’t consider security different in private clouds. Similarly, lock-in is a real concern in PaaS but negligible in IaaS.
Just knowing these two dimensions makes you smarter than nearly everyone in IT right now. And when you’re discussing IT, insist that others are specific about what they mean. Discussions around privacy and security are vital to public clouds, but most people don’t consider security different in private clouds. Similarly, lock-in is a real concern in PaaS but negligible in IaaS.
Just knowing these two dimensions makes you smarter than nearly everyone in IT right now. And when you’re discussing IT, insist that others are specific about what they mean. Discussions around privacy and security are vital to public clouds, but most people don’t consider security different in private clouds. Similarly, lock-in is a real concern in PaaS but negligible in IaaS.
Just knowing these two dimensions makes you smarter than nearly everyone in IT right now. And when you’re discussing IT, insist that others are specific about what they mean. Discussions around privacy and security are vital to public clouds, but most people don’t consider security different in private clouds. Similarly, lock-in is a real concern in PaaS but negligible in IaaS.
Just knowing these two dimensions makes you smarter than nearly everyone in IT right now. And when you’re discussing IT, insist that others are specific about what they mean. Discussions around privacy and security are vital to public clouds, but most people don’t consider security different in private clouds. Similarly, lock-in is a real concern in PaaS but negligible in IaaS.
Just knowing these two dimensions makes you smarter than nearly everyone in IT right now. And when you’re discussing IT, insist that others are specific about what they mean. Discussions around privacy and security are vital to public clouds, but most people don’t consider security different in private clouds. Similarly, lock-in is a real concern in PaaS but negligible in IaaS.
Just knowing these two dimensions makes you smarter than nearly everyone in IT right now. And when you’re discussing IT, insist that others are specific about what they mean. Discussions around privacy and security are vital to public clouds, but most people don’t consider security different in private clouds. Similarly, lock-in is a real concern in PaaS but negligible in IaaS.
Lots of people want to move into this space. Some are e-commerce giants (like Amazon) who know how to run many machines well.
Some are software companies with legions of developers (like Microsoft) who want to move from software licenses to recurring revenues.
Some are managed hosting companies (like Rackspace, Terremark, and Gogrid) who want to sell computing by the hour instead of by the month, and want to have more standardized offerings.
Some are giant service companies (like Google) who want people to create millions of applications and keep people using the Web.
Some are big systems integrators (like IBM) who want to design and run IT for enterprises.
Some are hardware vendors (like Dell) who want to stay in the computing business as it shifts.
Some are telecom providers (like AT&T and Verizon) who want to do more than move packets around, and want to make the best use of their existing data centers.
Some are even government organizations aiming to build infrastructure for the use of the government itself
This isn’t a comfy place to be right now. Cloud computing has what I call a “roofrack” problem.
Cloud computing isn’t something you can easily ignore.
For some applications, particularly those that are bursty or seasonal, the economics are overwhelmingly in its favor.
Cloud providers keep making their stuff better. Amazon introduced roughly 40 new features last year; and in a single month they upgraded their network in New York twice.
And clouds make organizations more agile, because they take procurement from weeks to minutes.
They also remove the false sense of security that came from expense limits.
These days, supercomputing is easier (and cheaper) than booking a flight.
Because there’s no investment, the concept of an ROI doesn’t really make sense.
Even if you’re only going to run a private cloud, you’re dealing with expectations set by the public Internet. Consider an ATM – once, we didn’t mind taking all of lunch to get money out; today, we worry when the bank machine fails to give us our money back in 10 minutes. That’s a bad thing for organizations that don’t handle IT automatically; humans simply can’t move that fast. Efficiency isn’t about how fast you do things; it’s about how many things you don’t have to do because they’re automated.
The Internet has a way of routing around obstacles, so if you try to block people from using them, you’ll likely send your stakeholders underground.
The best thing to do is offer people an alternative. Set up self-service computing internally and see what happens.
It also means surrounding them with composed services like storage and message queues. Fortunately, there is a wide variety of offerings to help with this. Hadoop, Cassandra, CouchDB, Hypertable and others are all tools that handle storage, scaling, and parallel tasks, and that you can deploy internally for your users.
It also means setting up platforms (such as a web server that can handle PHP code, or a Drupal platform for creating social sites, or a Status.net instance for microblogging,
or a Wordpress instance for blogs.)
Finally, it means working with SaaS providers when appropriate, but integrating their applications with your internal data and processes
For IT, and governments, cloud computing is a trigger. It means it’s time to rebalance your computing decisions.
With clouds, there’s a spectrum of IT options. Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Different applications live in different places in this new world.
Here’s a five-step plan for embracing clouds.
First, you need to assess your existing applications. Make a list of everything you’ve got, or plan to have. You should also baseline usage, performance, and other “before” metrics so you can compare them to the results of your efforts after you’ve moved.
Then, you need to rebalance your applications. Evaluate each application along two dimensions: how suitable is the application for migration, and what’s the payoff.
Some applications, like legacy ERPs or old mainframe tools, won’t migrate easily. They’re not well suited to a virtualized, on-demand model where users can spin up resources as needed.
Others, like web front-ends or parallel data processing tasks like analytics, that can be split up, work really well in clouds.
At the same time, some applications won’t benefit much from a cloud model. Something that runs constantly may be more affordable to run in-house.
Other applications may have a massive budget savings when they move to the cloud. Something that happens once a year but needs tremendous computing for the three days it runs is a candidate for clouds. So, too, is something that users are constantly requesting, and that your IT team spends a lot of time managing. Automate it!
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Going forward, we’ll see hybrid on-premise/on demand hybrid clouds that can intelligently move processing tasks between private an public infrastructure according to performance requirements, pricing policies, and security restrictions.
Third step: You have to migrate things to the new environments. This means moving stuff around—hopefully the high-payoff, easy-to-move stuff first. There’s no magic here: you’ll need to make your applications portable, which means virtualizing them; and you may need to modify some code.
Step four is to optimize things. In their new homes, some applications won’t perform as well. You’ll need to compare how they’re doing now to how they were doing before, and tweak things to ensure equivalent performance, uptime, security, and scalability.
Finally, in step five you need to operate things differently. Cloud computing is as much about a cultural shift in IT: you’re operating a self-service business.
You’re not doing the IT work any more; you’re managing the scripts and systems that let users do the IT work themselves. You have a very different relationship with your end users.
You’re providing the environment for them to innovate, giving them turnkey sets of services with which to work. Where they come from is immaterial.
You’re ensuring that the systems you’ve built are functioning properly however end users want to use them, rather than running the applications or data within those systems.
Your end users aren’t necessarily technical -- they’re able to build applications easily, and want the tools to experiment.
At the same time, you’re seeing what tools and processes are getting adopted -- what’s working? what’s popular? -- and doubling down on those things.
You’re giving your users places to experiment.
To some extent, you’re “paving the cowpaths.”
This is an old civil engineering trick: Watch where people walk, then put paths there.
One of the fundamentals of a cloud is the separation of the provider from the user at some layer in the stack
Where that separation happens determines economics, responsibilities, risk, and lock-in