<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>George Reese on O&apos;Reilly Broadcast</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/" />
<link rel="self" type="application/atom+xml" href="http://broadcast.oreilly.com/atom.xml" />
<id>tag:broadcast.oreilly.com,2008-08-07://53</id>
<updated>2011-10-12T08:34:02Z</updated>

<generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.21-en</generator>

<entry>
<title>API Versioning</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/10/api-versioning.html" />
<id>tag:broadcast.oreilly.com,2011://53.47325</id>

<published>2011-10-12T08:34:02Z</published>
<updated>2011-10-12T08:34:02Z</updated>

<summary>API versioning is something a lot of API designers don&apos;t worry about until the second version of their API. API versioning, however, is a controversial subject with strong opinions on both version representation and behavior. </summary>
<author>
<name>George Reese</name>

</author>

<category term="apis" label="APIs" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="programming" label="programming" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="restfulservices" label="restful services" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
API versioning is something a lot of API designers don&apos;t worry about until the second version of their API. API versioning, however, is a controversial subject with strong opinions on both version representation and behavior. 
</content>
</entry>

<entry>
<title>The EC2 API as a De Facto Standard</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/08/the-ec2-api-as-a-defacto-standard.html" />
<id>tag:broadcast.oreilly.com,2011://53.47016</id>

<published>2011-08-09T21:11:46Z</published>
<updated>2011-08-09T21:11:46Z</updated>

<summary>The argument for EC2 as a defacto standard is, at some level, the same as it is for any defacto standard: through the EC2 API, you eliminate the need for others to learn some custom API and you can leverage the existing, sizable ecosystem. But there is no such thing as the EC2 API. EC2 is actually many different APIs and adopting the EC2 API as a standard ultimately implies supporting all of those APIs.</summary>
<author>
<name>George Reese</name>

</author>

<category term="apis" label="APIs" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="aws" label="aws" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="ec2" label="ec2" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
The argument for EC2 as a defacto standard is, at some level, the same as it is for any defacto standard: through the EC2 API, you eliminate the need for others to learn some custom API and you can leverage the existing, sizable ecosystem. But there is no such thing as the EC2 API. EC2 is actually many different APIs and adopting the EC2 API as a standard ultimately implies supporting all of those APIs.
</content>
</entry>

<entry>
<title>The Good, the Bad, and the Ugly of REST APIs</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/06/the-good-the-bad-the-ugly-of-rest-apis.html" />
<id>tag:broadcast.oreilly.com,2011://53.46564</id>

<published>2011-06-04T22:19:33Z</published>
<updated>2011-06-04T22:19:33Z</updated>

<summary>I&apos;ve never seen a perfect REST API. But I have seen some of the most horrible mistakes repeated over and over again by people building heavily consumed APIs. Here&apos;s a list of the Good, the Bad, and the Ugly of REST API design.</summary>
<author>
<name>George Reese</name>

</author>

<category term="apis" label="APIs" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="tips" label="tips" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
I&apos;ve never seen a perfect REST API. But I have seen some of the most horrible mistakes repeated over and over again by people building heavily consumed APIs. Here&apos;s a list of the Good, the Bad, and the Ugly of REST API design.
</content>
</entry>

<entry>
<title>The AWS Outage: The Cloud&apos;s Shining Moment</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html" />
<id>tag:broadcast.oreilly.com,2011://53.46231</id>

<published>2011-04-23T17:12:35Z</published>
<updated>2011-04-23T17:12:35Z</updated>

<summary>So many cloud pundits are piling on to the misfortunes of Amazon Web Services this week as a response to the massive failures in the AWS Virginia region. If you think this week exposed weakness in the cloud, you don&apos;t get it: it was the cloud&apos;s shining moment, exposing the strength of cloud computing.</summary>
<author>
<name>George Reese</name>

</author>

<category term="aws" label="aws" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="designforfailure" label="designforfailure" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="nosql" label="NoSQL" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
So many cloud pundits are piling on to the misfortunes of Amazon Web Services this week as a response to the massive failures in the AWS Virginia region. If you think this week exposed weakness in the cloud, you don&apos;t get it: it was the cloud&apos;s shining moment, exposing the strength of cloud computing.
</content>
</entry>

<entry>
<title>The Whole Cloud, Part II: Suitability for the Cloud</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/04/the-whole-cloud-part-2-suitability-for-the-cloud.html" />
<id>tag:broadcast.oreilly.com,2011://53.46166</id>

<published>2011-04-16T18:23:28Z</published>
<updated>2011-04-16T18:23:28Z</updated>

<summary>In my discussion of the Whole Cloud, I assumed as fact that a mature cloud computing infrastructure leverages all kinds of clouds. Given the amount of energy put into arguments on the subject, it&apos;s obviously not a given to most people. Today, I want to talk about how these different &quot;pieces of cloud&quot; can be integrated together from a decision-making perspective</summary>
<author>
<name>George Reese</name>

</author>

<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="iaas" label="iaas" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="paas" label="paas" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="saas" label="saas" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
In my discussion of the Whole Cloud, I assumed as fact that a mature cloud computing infrastructure leverages all kinds of clouds. Given the amount of energy put into arguments on the subject, it&apos;s obviously not a given to most people. Today, I want to talk about how these different &quot;pieces of cloud&quot; can be integrated together from a decision-making perspective
</content>
</entry>

<entry>
<title>The Whole Cloud</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/04/the-whole-cloud.html" />
<id>tag:broadcast.oreilly.com,2011://53.46158</id>

<published>2011-04-15T03:47:01Z</published>
<updated>2011-04-15T03:47:01Z</updated>

<summary>A few companies are currently well positioned to create a view of cloud computing that encompasses all aspects of cloud from IaaS to SaaS, public cloud and private cloud, internal and external. A mature cloud infrastructure, however, will be made up of all pieces of the cloud puzzle.</summary>
<author>
<name>George Reese</name>

</author>

<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="iaas" label="iaas" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="paas" label="paas" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="private_cloud" label="private_cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="saas" label="saas" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
A few companies are currently well positioned to create a view of cloud computing that encompasses all aspects of cloud from IaaS to SaaS, public cloud and private cloud, internal and external. A mature cloud infrastructure, however, will be made up of all pieces of the cloud puzzle.
</content>
</entry>

<entry>
<title>A Proposal for Cloud State Notifications</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html" />
<id>tag:broadcast.oreilly.com,2011://53.46065</id>

<published>2011-04-02T16:36:13Z</published>
<updated>2011-04-02T16:36:13Z</updated>

<summary>The cloud ecosystem needs a mechanism besides polling that enables monitoring, management, and automation tools to learn about changes in the state of cloud resources. This proposal attempts to define a simple protocol for notifying those tools through a push notifications system rather than polling.</summary>
<author>
<name>George Reese</name>

</author>

<category term="apis" label="APIs" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
The cloud ecosystem needs a mechanism besides polling that enables monitoring, management, and automation tools to learn about changes in the state of cloud resources. This proposal attempts to define a simple protocol for notifying those tools through a push notifications system rather than polling.
</content>
</entry>

<entry>
<title>Cloud Culture: How Cloud Attitudes Differ in Europe and North America</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2010/12/cloud-culture-how-cloud-attitudes-differ-in-europe-and-north-america.html" />
<id>tag:broadcast.oreilly.com,2010://53.43762</id>

<published>2010-12-31T02:03:46Z</published>
<updated>2010-12-31T02:03:46Z</updated>

<summary>Based on the work I have been doing in cloud computing Europe, Asia/Pacific,  and North America, people have been regularly asking me the questions, &quot;How are attitudes towards cloud computing different in Europe?&quot; and &quot;How has cloud adoption differed in Europe from it&apos;s adoption in the United States?&quot; In the spirit of attempting to provide some useful insight, I have decided to attempt to write a blog entry and answer those questions as 2010 comes to an end.</summary>
<author>
<name>George Reese</name>

</author>

<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="technologyinsights" label="technology insights" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Based on the work I have been doing in cloud computing Europe, Asia/Pacific,  and North America, people have been regularly asking me the questions, &quot;How are attitudes towards cloud computing different in Europe?&quot; and &quot;How has cloud adoption differed in Europe from it&apos;s adoption in the United States?&quot; In the spirit of attempting to provide some useful insight, I have decided to attempt to write a blog entry and answer those questions as 2010 comes to an end.
</content>
</entry>

<entry>
<title>Cloud 2011: The Year of the Network</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2010/12/cloud-2011-the-year-of-the-network-in-the-cloud.html" />
<id>tag:broadcast.oreilly.com,2010://53.43734</id>

<published>2010-12-22T21:20:54Z</published>
<updated>2010-12-22T21:20:54Z</updated>

<summary>In spite of all the innovation that&apos;s happened in the recent years in the cloud, cloud networking remains in the dark ages. I expect that 2011 will prove to be the year of the network in the cloud.</summary>
<author>
<name>George Reese</name>

</author>

<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="networks" label="networks" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="predictions" label="predictions" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="security" label="security" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
In spite of all the innovation that&apos;s happened in the recent years in the cloud, cloud networking remains in the dark ages. I expect that 2011 will prove to be the year of the network in the cloud.
</content>
</entry>

<entry>
<title>The Delusion of Private Cloud Security</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2010/08/the-delusion-of-private-cloud-security.html" />
<id>tag:broadcast.oreilly.com,2010://53.41842</id>

<published>2010-08-07T20:40:37Z</published>
<updated>2010-08-07T20:40:37Z</updated>

<summary>The perennial debate on private cloud vs. public cloud continues to flare up anywhere cloud computing is being discussed. One of the most often repeated myths favoring private cloud deployments is that they are &quot;more secure&quot; than public clouds. It&apos;s complete nonsense.</summary>
<author>
<name>George Reese</name>

</author>

<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloud_security" label="cloud_security" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="private_cloud" label="private_cloud" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
The perennial debate on private cloud vs. public cloud continues to flare up anywhere cloud computing is being discussed. One of the most often repeated myths favoring private cloud deployments is that they are &quot;more secure&quot; than public clouds. It&apos;s complete nonsense.
</content>
</entry>

<entry>
<title>The Cloud Computing Mind Map</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2010/06/cloud-computing-mind-map.html" />
<id>tag:broadcast.oreilly.com,2010://53.40187</id>

<published>2010-07-01T02:49:18Z</published>
<updated>2010-07-01T02:49:18Z</updated>

<summary>Getting your brain around all of the components of cloud computing is a huge challenge. There are so many players, and a number of them are performing functions entirely new to IT. A few months ago, I put together a mind map of the cloud computing space I use to help people understand this space. It&apos;s reached a level of maturity that I now feel it appropriate to share it with a wider audience.</summary>
<author>
<name>George Reese</name>

</author>

<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="mindmap" label="mind map" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Getting your brain around all of the components of cloud computing is a huge challenge. There are so many players, and a number of them are performing functions entirely new to IT. A few months ago, I put together a mind map of the cloud computing space I use to help people understand this space. It&apos;s reached a level of maturity that I now feel it appropriate to share it with a wider audience.
</content>
</entry>

<entry>
<title>Failure Is a Feature of Reality</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2010/05/failure-is-a-feature-of-reality.html" />
<id>tag:broadcast.oreilly.com,2010://53.39891</id>

<published>2010-05-14T15:55:35Z</published>
<updated>2010-05-14T15:55:35Z</updated>

<summary>All systems fail. In the computing world, the best we can hope for is the creation of redundant systems and backup systems that help minimize the impact of those failures. Where people run into trouble in the cloud is when they believe that &quot;putting a system in the cloud&quot; means not having to worry about redundancy and backup systems. </summary>
<author>
<name>George Reese</name>

</author>

<category term="amazon" label="amazon" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="aws" label="aws" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="backup" label="backup" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloudcomputing" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="disasterrecovery" label="disaster recovery" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="failures" label="failures" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
All systems fail. In the computing world, the best we can hope for is the creation of redundant systems and backup systems that help minimize the impact of those failures. Where people run into trouble in the cloud is when they believe that &quot;putting a system in the cloud&quot; means not having to worry about redundancy and backup systems. 
</content>
</entry>

<entry>
<title>Understanding the Cloud Landscape</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2010/04/understanding-the-cloud-landscape.html" />
<id>tag:broadcast.oreilly.com,2010://53.39775</id>

<published>2010-04-29T22:22:24Z</published>
<updated>2010-04-29T22:22:24Z</updated>

<summary>Making sense out of all of the components of cloud computing confuses even many of the major analysts. It&apos;s easy to understand how Google, Amazon, or SalesForce.com fit into the picture. But who is Eucalyptus and what do they do? Does CohesiveFT compete with enStratus or does it complement enStratus? And what is this vCloud thing anyway?</summary>
<author>
<name>George Reese</name>

</author>

<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="infrastructure" label="infrastructure" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="systemadministration" label="system administration" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="virtualization" label="virtualization" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Making sense out of all of the components of cloud computing confuses even many of the major analysts. It&apos;s easy to understand how Google, Amazon, or SalesForce.com fit into the picture. But who is Eucalyptus and what do they do? Does CohesiveFT compete with enStratus or does it complement enStratus? And what is this vCloud thing anyway?
</content>
</entry>

<entry>
<title>The Five Levels of Cloud Computing</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2010/03/five-levels-of-cloud-computing.html" />
<id>tag:broadcast.oreilly.com,2010://53.39439</id>

<published>2010-03-24T21:01:17Z</published>
<updated>2010-03-24T21:01:17Z</updated>

<summary>We&apos;re at an immature stage in the development of cloud computing. Today, the cloud represents the exception to way organizations manage technology. As the decade progresses, cloud computing will mature and evolve into the core of all IT systems along the path described in these five levels of cloud computing.</summary>
<author>
<name>George Reese</name>

</author>

<category term="architecture" label="architecture" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="taxonomy" label="taxonomy" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
We&apos;re at an immature stage in the development of cloud computing. Today, the cloud represents the exception to way organizations manage technology. As the decade progresses, cloud computing will mature and evolve into the core of all IT systems along the path described in these five levels of cloud computing.
</content>
</entry>

<entry>
<title>The Sacred Barrier</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html" />
<id>tag:broadcast.oreilly.com,2010://53.39221</id>

<published>2010-02-25T04:29:18Z</published>
<updated>2010-02-25T04:29:18Z</updated>

<summary>Should public cloud providers reach into the guest operating system to perform various functions? I&apos;ve always held that a public cloud provider should treat the border between the hypervisor and guest operating system as a sacred barrier that should never be breached. The fear in public cloud computing is giving up control. When a public cloud provider reaches into your virtual machine, you lose too much control.</summary>
<author>
<name>George Reese</name>

</author>

<category term="architecture" label="architecture" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloud" label="cloud" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloud_security" label="cloud_security" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="security" label="security" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="virtualization" label="virtualization" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Should public cloud providers reach into the guest operating system to perform various functions? I&apos;ve always held that a public cloud provider should treat the border between the hypervisor and guest operating system as a sacred barrier that should never be breached. The fear in public cloud computing is giving up control. When a public cloud provider reaches into your virtual machine, you lose too much control.
</content>
</entry>

</feed> 
