Once again, the day opens with short keynotes. 

Starting us off is James Staten of Forrester.  James gives us two words to think about in respect to cloudonomics: Down & Off.  When the application (resource) isn’t in use, you can turn it off.  When you turn it off, you aren’t paying. 

James says to write applications in components that are as small as possible.  Only turn on what you need, when you need it.  James is describing cloud applications that have a zero footprint until a request is made.  [Sounds event-driven to me.  I like it.]

In the same respect, monitor performance thresholds to determine when an instance can be turned off.  Make “down” and “off” part of your design. 

[Of course, need to be smart in “systems management” with a hyper distributed, small component architecture.  Need to understand/monitor/manage the collective, to complete transactions].

Scott Baker, Director of Systems Engineering and Operations, Eventbrite

Scott is buzzing through a history of datacenter building and love.  However, he’s learned to love the cloud.  A favorite point of the crowd is “To have agile development, you need to have agile operations”.  The cloud, according to Scott, provides agile operations.

Oriol Vinyals, PhD Student, UC Berkeley, Microsoft Research Fellow: Building the Overmind: AI and Cloud Computing

Oriol is looking at artificial intelligence, Starcraft and the Cloud.  Starcraft, according to Oriol, is a strategy game.  To win, you need to gather resources, produce units and attack your opponent.  Starcraft, apparently, is a good AI problem to solve.

Challenges: long horizon, concurrent, partially observable (don’t see the complete board), and real-time.

Connections to cloud computing: resources, tasks, opponents & weapons (users & servers).

Oriol shows videos of swarms and defenders responding, you can see parallels to cloud computing and effective management of resources.

Marvin Wheeler, Chief Strategy Officer, Terremark, on the Open Data center Alliance.  From the website:

“The Open Data Center Alliance is an independent consortium comprised of leading global IT managers in a wide range of vertical segments, who have come together to provide a unified vision for long-term data center requirements.

In support of its mission, the Alliance is developing and delivering an Open Data Center Usage Model Roadmap, which defines Usage Model requirements to resolve key IT challenges and fulfill cloud infrastructure needs into the future. This vendor-agnostic roadmap serves as the foundation for member planning of future data center deployments, and relies on open, interoperable, industry-standard solutions.”

Marty Kagan, President and Co-Founder, Cedexis on Cloud Performance Data

Cloud Bakeoff: Amazon EC2, Google App Engine, Joyent, Rackspace and Windows Azure.  Bitcurrent is publishing a study.  EC2 East wins for HTTP request, but need to factor in request origin for best performance.

Neal Sample, Vice President, Architecture, Technology Product Management, Developer Program, eBay

Neal waled through models and curves on cloud bursting.  eBay has moved from 2000 servers down to 800 servers, with excess requests bursting to the public cloud.  By reducing infrastructure costs, eBay has been able to redirect that investment into business intelligence, providing additional value to the business.

Session Abstract: In many ways, Big Data is what clouds were made for. Computing problems that are beyond the grasp of a single computer—no matter how huge—are easy for elastic platforms to handle. In this session, big data processing pioneer Colin Clark will discuss how to discover hidden signals and new knowledge within in huge streams of realtime data, applying event processing design patterns to events in real time.

Speaker – Colin Clark, CTO, Cloud Event Processing

Colin opens talking about high velocity, big data.  Then, gives his Complex Event Processing Criteria:

1. Domain Specific Language
2. Continuous Query
3. Time/Length Windows
4. Pattern Matching

Example of what Colin is talking about: “Select * from everything where itsInteresting = toMe in last 10 minutes”

How much data does that return? How much processing will it take? 

Limitations of current CEP solutions: memory bound, compute bound and black box.  Using CEP, can analyze data in-flight, but have limitations. Other challenge is time series analysis.

A technique available for time series analysis is symbolic aggregate approximation (SAX). 

Colin is describing the construction of a “SAX word” from a days worth of IBM trading.  Then, search history for that same word, to find a pattern.

Getting closer to solving the high velocity, big data problem.  But, still too much data to process.  So, the next element in cloud event processing is Map/Reduce. 

Still though, need to address the real-time (event-driven) aspect.  Brings us to virtualized resources (cloud).

So, assuming I captured this correctly: High velocity, big data = CEP + SAX + Streaming Map/Reduce + virtualized resources, which equals Cloud Event Processing’s Darkstar.

Today, Darkstar is working on Wall Street, doing market surveillance at the exchange.  Speaking with Colin in the hallway, we discussed non-capital market prospects as well.

Speaker – Jinesh Varia, Technology Evangelist, Amazon Web Services

Jinesh is doing a nice job describing the evolution of a fictional (dating) website that is live only 3 hours a week.  In telling the story, he is walking through the site’s evolution, the developer’s knowledge of patterns (really good design practices) and the related AWS cloud offerings (patterns of use).

Pattern #1: Design for failure and nothing will fail

Pattern #2: Always edge cache your static data (Amazon CloudFront)

Pattern #3: Implement elasticity

Next challenge for the developer is dealing with scale.  Principles of elastic cloud architectures:

1. Resilient to reboot & re-launch: automatically re-launch and restart
2. stateless: extract stateful components and make them stateless
3. Packable into an AMI
4. Decouple: Isolate the components using Amazon SQS (queues). Decouple code with deployment and configuration.

Jinesh calls out the Netflix Chaos Monkey pattern. 

Elasticity also means scale-out.  So, the developer adds Elastic Load Balancer and create an Auto Scaling Group.

Pattern #4: Leverage Multiple Availability Zones (Feature on RDS, creates a standby slave)

Pattern #5: Isolate read and write traffic; Isolate static and dynamic traffic (Use RDS read replica)

Pattern #6: Automate your in-cloud Software Development & Deployment Lifecycle (Automate using cloud APIs – scripts)

Scripts provide: repeatability, savings (suspend/resume), productivity, and freedom to experiment.

Interesting point, used to “move” from staging to production.  With cloud, you can make Stage into Production, and then drop the current Production instances.  Saves time, reduces errors.

Pattern #7: Cache as much as possible (Memcache in new cache tier)

Pattern #8: Hardening security at every stage (infrastructure security, application security and services security)

Pattern #9: Go Global Quickly with a Single API

Pattern #10 Keep optimizing and see the savings in the next month’s bill (example, use reserve instances)

Started with single node architecture, now global, scaleable, fault tolerant application, while minimizing run-time cost.

Good session.

Cloudonomics: Private, Public, or Hybrid?

How should one quantify the ROI, costs, and benefits of cloud alternatives? What are the cost drivers of private, public, and hybrid delivery models, and how will they evolve over time? Is pay-per-use good or bad? What are the main cognitive biases in enterprise decision-making?

Speaker – Joe Weinman, Communications, Media, and Entertainment Industry Strategic Programs, HP

I’m starting the tracks with Joe Weinman’s cloudonomics session.  Joe’s session last year was a favorite of mine, so I’m back for more insights.

Joe is talking about some common cloud points/arguments that aren’t so clear.  A few comments:

• Economies of scale are the key to cloud benefits.  Designing building your own server, is not an economy of scale. Locating near rivers and cheap power is not an economy of scale, it’s an economy of location. 
• For larger companies, Capex vs. Opex is an accounting decision.  You can reserve cloud instances and then capitalize that expenditure.  Depends on what you need.
• The end-state is probably going to be a hybrid cloud, some owned, some on-demand.

How to quantify value?

1. unit cost reduction
2. total cost reduction
3. opportunity cost reduction
4. time & profitability improvement
5. revenue growth
6. customer experience enhancement
7. customer satisfaction / loyalty
8. risk reduction
9. competitive vitality
10. life or death – winner take all dynamics

See Joe’s Meteorology slide, captured & posted by Randy Bias.

Joe referenced his 10 laws of cloudonomics. I also liked his 10 laws of behavioral economics.

Vapor or Cloud: virtualize or defer. Virtualization won’t give you 100% utilization.  Defer, is deferring the workload.  Not possible in consumer, event-driven workloads (tax filing, holiday shopping, sports event).

Hybrid: “Own the base, rent the spike”.

All other things being equal, if cloud services cost less than enterprise IT, then, use them.

If cloud services cost more than enterprise IT, then, don’t jump to conclusions.  Need to consider demand spikes / patterns.  Best to see Joe’s papers that demonstrate the math, decision factors.

Some architecture options for Hybrid Clouds:

1. Pure Utility Cloud
2. Mixed-Rate Hosting/Cloud
3. Cloudbursting
4. Front-End / Back-end – leave back-end, move front-end to cloud

Caveat: Remember the data.  If it costs more to move (network) the data payload than the resource savings, don’t do it.

Next point: Time is money, the value of on-demand.  Paper (pdf) & Abtract:

"Cloud computing and related services offer resources and services “on demand.” Examples include access to “video on demand” via IPTV or over-the-top streaming; servers and storage allocated on demand in “infrastructure as a service;” or “software as a service” such as customer relationship management or sales force automation. Services delivered “on demand” certainly sound better than ones provided “after an interminable wait,” but how can we quantify the value of on-demand, and the scenarios in which it creates compelling value?

We show that the benefits of on-demand provisioning depend on the interplay of demand with forecasting, monitoring, and resource provisioning and de-provisioning processes and intervals, as well as likely asymmetries between excess capacity and unserved demand…"

Smooth Operator: the value of demand aggregation Paper (pdf) & abstract:

“In industries such as cloud computing, lodging, and car rental services, demand from multiple customers is aggregated and served out of a common pool of resources managed by an operator. This approach can drive economies of scale and learning curve effects, but such benefits are offset by providers‘ needs to recover SG&A and achieve a return on invested capital. Does aggregation create value or are customers‘ costs just swept under a provider‘s rug and then charged back?

Under many circumstances, service providers—which one might call "smooth" operators—can take advantage of statistical effects that reduce variability in aggregate demand, creating true value vs. fixed, partitioned resources serving that demand.”

I think I’ll download some of Joe’s papers for the flight home. 

The conference opens with short keynotes and a panel discussion on private clouds. 

First up, fittingly, is Werner Vogels, CTO of Amazon. Werner opens with a riff on “the map isn’t the territory” and “the model isn’t reality”.  From there, he goes to the 3-layer SaaS – PaaS – IaaS model.  That model, is just a model.  It shouldn’t restrict our view or understanding of cloud computing.  Everything as a (cloud) Service.  You should be able to use any service as if it is a cloud itself.  This is thinking behind Elastic Beanstalk.  “Let 1000 platforms bloom”. 

Via the cloud, enterprises and startups have access to the same software services.  Werner calls out security services and big data services.  Analytics is typically a domain of enterprise, but the cloud gives access to deep analytics to startups.

Werner’s pitch today, “the ecosystem is what defines the cloud”.  He is calling out some ecosystem examples.  It should be noted though, that the twitter back channel is mixed positive and negative.  There has been a running joke on twitter that “every time Jeff Barr writes a new post, a startup [AWS related service] dies”.  On the other hand, Amazon’s expanding offerings, enables many business and software startups.  So, it depends on your perspective.

Next, Dr. Lew Tucker, now with Cisco, on “The network is the computer, once again”.  Lew is working his way to the Internet of Things, but hasn’t called it that.  He sees “a world of many clouds”, media, government, industry etc.  But, the underlying technology model will be the same. This brings him to Cisco’s position on the new data center, insulate infrastructure and run it as a service. And you know, the network is king in this new model.

Now, Randy Bias of Cloud Scaling.  Randy is talking about enterprise cloud myths.  1. enterprises aren’t using Amazon 2. enterprises want to move legacy to the cloud, not develop greenfield apps.

What he is seeing, working on, is greenfield applications on public clouds for enterprise clients.  Enterprises aren’t moving legacy to the cloud.  This isn’t an outsourcing exercise.

Randy is walking through Amazon growth trends, “Amazon is winning”.  Randy’s takeaways: go commodity, serve greenfield, embrace the change.

Now, Alistair Croll is moderating a mini-panel on private clouds.  The panelists are:

• Matt Thompson, General Manager, Developer and Platform Evangelist, Microsoft
• Mathew Lodge, Sr. Director, Cloud Product Marketing, VMware

This is a contrast to Randy Bias’ talk.  Both panelists talking about porting existing applications to the cloud, and the need to port applications between public and private clouds.

Alistair: Data has surface tension, data wants to be together.  In respect to the cost of moving data around. 

In some cases, public cloud is front-end, data is in the back-end (private cloud).  – Matthew Lodge

Matt Thompson brings up public data sets, cloud is the best place to aggregate and process public data sets.  [Again, compute where the data lives]

Kevin McEntee, Vice President of Systems Engineering, Netflix

The Netflix story starts in 2008, with the highly publicized systems outage that delayed DVD shipments.  “Went to the cloud looking for high-availability, found agility for business and developers.  Agility by eliminating complexity”.

Kevin calls out work of Fred Brooks, No Silver Bullet.  Need to eliminate accidental complexity.  Netflix 2010, 80% of customer transactions running in the cloud.

In the cloud architecture, there is no single point of control over cloud spending.  Cloud enables running with this business culture, “responsible individuals, worthy of freedom”.

For more on Netflix, see this interview and the Netflix Technology blog.

Now up is Willy Chiu, Vice President, IBM Cloud Labs.  If you’ve followed the Jeopardy! Watson story, then you know what’s being said.  If not, here’s a link.

Todd Papaioannou, Vice President, Cloud Architecture, Yahoo.  This is an end-user story.  Building the Yahoo! cloud to support Yahoo! services.  Todd concentrates on elasticity. 

What are impediments for delivering truly elastic clouds?  Spin-up time is a major issue for ‘spike” events. 15-minutes to spin up a new VM is too long.  So, load shedding is the only current option for them. 

Derek Chan, Head of Digital Operations, Dreamworks Animation SKG

Derek is responsible for overall compute resources at Dreamworks.  Derek is an end-user of cloud computing, not building clouds. 

A single film, 4-5 years, 50+ million CPU hours.  Imagine having a dozen films in flight.  Tremendous peaks and troughs.  Paying for only what they need is tremendous benefit.

In 2003, used HP’s utility rendering service.  Wasn’t a cloud.  Was off-site resource usage.

Need to co-locate compute and data.

In 2010, released 3 CG features in one year.  Leveraged cloud to address the peaks.  Over 7 million compute hours sent to IaaS.

2011, more movies, more cloud.  Increase cloud capacity 10x.  Increasing network bandwidth 3x. 

Artists don’t know, don’t care about where rendering happens.

Cloud stack: RHEL (O/S), RHEV (virtualization), MRG (message queue), WebLogic, Jboss (middleware), deltaCloud (management)

Upcoming challenges: multi-tenancy, completely flex (payment model), cloud storage

Can see the evidence in Kung Fu Panda 2, 20% done in cloud.

The WSJ published an interesting article on commercial farming advances in Japan.  According to the article, “The aim is to bring the concepts of lean manufacturing and continual improvement, or kaizen, to farming.”

The farmers are employing sensors, analytics, real-time location information and cloud computing to optimize planting time, crop rotation, worker productivity and threat (infection) detection.

“…Now the head of a commercial farm in the southern Japanese prefecture of Miyazaki, Mr. Shinpuku is back manning a desk with his eyes glued to a Web browser tracking every movement of his workers who handle 60 different fruits and vegetables across its 100 hectares.

"I don’t want to do this. My eyes will get bad," said Mr. Shinpuku, the 58-year-old president of his commercial farm Shinpuku Seika, which is comprised of 300 different plots of land. "I put up with it, because the benefits are obvious. Without this computer, I can’t do my job."

Shinpuku Seika is among the first farms to implement a Web-based "cloud computing" service developed by Japanese technology firm Fujitsu Ltd. Cloud computing is a loosely defined business term in which companies rent computing power from remote data centers via the Internet instead of buying machines to run software in house.

Shinpuku Seika has placed sensors out in its fields to collect readings on temperature, soil and moisture levels. Fujitsu’s computers then crunch the data and recommend when to start planting or what crops may be well-suited to a specific field.

In the past, farmers would make those decisions based on experience, but Mr. Shinpuku says a data-driven approach prevents younger, less experienced staff from making mistakes that could cost the bottom line.”

The pay-off?  Measured in cabbage of course:

“The system is already paying off for Shinpuku Seika, which generates about 1.5 billion yen ($18 million) in annual revenue. Last year, it doubled the size of its carrot harvest and raised its cabbage output by 12%.”

Read the full article.

If Dogbert can find the time to make astute cloud computing observations, then I can too.  Let the cloud watching (finally) resume.

In mid-May, I tweeted my in-the-moment hypothesis on the most valuable use of cloud computing:

“Seems to me, #1 use case (value) of Cloud Computing should be Business or Business Capability Incubation. Cloud as experimentation platform.”

Some 30-odd days later, I find myself reaffirming this sentiment.  Thus, the official entry into my cloud watch record. 

Here we go.  Event Processing and Cloud Computing are natural allies.  Events can be used in the monitoring, notification, and adjustment of cloud computing environments (CCE), and in the monitoring, notification, adjustment of, and in response to, the business capabilities running on those CCEs.   As I’ve mentioned numerous times, I believe event-based data integration will be critical to information, and therefore, business synchronization. 

In addition to being an event generator, and responder, cloud computing can also be a highly efficient, scalable, event processing platform.  For proof, just ask my friend Colin Clark at Cloud Event Processing.

So, it’s with no surprise, but great expectations, that I’m noting the beta release of Amazon’s Simple Notification Service (Amazon SNS).  From the Amazon service page:

“Amazon Simple Notification Service (Amazon SNS) is a web service that makes it easy to set up, operate, and send notifications from the cloud. It provides developers with a highly scalable, flexible, and cost-effective capability to publish messages from an application and immediately deliver them to subscribers or other applications. It is designed to make web-scale computing easier for developers.

Amazon SNS provides a simple web services interface that can be used to create topics you want to notify applications (or people) about, subscribe clients to these topics, publish messages, and have these messages delivered over clients’ protocol of choice (i.e. HTTP, email, etc.). Amazon SNS delivers notifications to clients using a “push” mechanism that eliminates the need to periodically check or “poll” for new information and updates. Amazon SNS can be leveraged to build highly reliable, event-driven workflows and messaging applications without the need for complex middleware and application management. The potential uses for Amazon SNS include monitoring applications, workflow systems, time-sensitive information updates, mobile applications, and many others. As with all Amazon Web Services, there are no up-front investments required, and you pay only for the resources you use.”

From the SNS Functionality Overview, the service appears to be cloud based publish-subscribe:

• “Create a topic: A topic is an “access point” – identifying a specific subject or event type – for publishing messages and allowing clients to subscribe for notifications.
• Set policies for your topic: Once a topic is created, the topic owner can set policies for it such as limiting who can publish messages or subscribe to notifications, or specifying which notification protocols will be supported (i.e. HTTP/HTTPS, email). A single topic can support notification deliveries over multiple transport protocols.
• Add subscribers to a topic: Subscribers are clients interested in receiving notifications from topics of interest; they can directly subscribe to a topic or be subscribed by the topic owner. Subscribers specify the protocol format and end-point (URL, email address, etc.) for notifications to be delivered. Upon receiving a subscription request, Amazon SNS will send a confirmation message to the specified end-point, asking the subscriber to explicitly opt-in to receiving notifications from that topic. Opting-in can be done by calling an API, using a command line tool, or – for email notifications – simply clicking on a link.
• Publish messages / send out notifications: When topic owners have updates they wish to notify their subscribers about, they publish those messages to the topic – which immediately triggers Amazon SNS to deliver this message to all applicable subscribers.”

Of the features list, “scalable” caught my attention:

“Scalable – Amazon SNS is designed to meet the needs of the largest and most demanding applications, allowing applications to publish an unlimited number of messages at any time.”

Largest and most demanding? Tweets, market data, click-stream, blue mussels, Internet of Things … 

Amazon’s SNS is a springboard to industrial strength event processing and the active information tier.  As I said, “here we go”.

As a few of discussed on Twitter last week, there are a dizzying number of cloud computing announcements coinciding with Cloud Connect this week.  Here’s the starter list:

Appistry Addresses Hadoop "Elephant in the Room"

Appistry Announces CloudIQ Storage: A Smarter Approach to Storage for Data-Centric Applications

RightScale Boosts Enterprise Capabilities in its Leading Cloud Management Platform

RightScale Launches One Million Servers in the Cloud

newScale Announces Support for the Cisco Unified Computing System

IBM Extends Development and Test to the IBM Cloud

SOASTA and Enomaly Team to Deliver Cloud Scalability

Eucalyptus Private Cloud Software Integrates with SAN Networks

AppDynamics Now Offers Software-as-a-Service Delivery Option for Application Performance Management