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”.
Tagged as:
Amazon,
AWS,
SNS
Posted by brenda michelson at 3:41 pm in Cloud Watch, IaaS, cloud offering, event processing | Permalink
| Comments(0)
| Trackback URL
Per usual, James Urquhart published a thought provoking post on cloud computing and geopolitics. Recently, as part of my 100-day cloud watch, I’ve pointed out the importance of cloud computing environment location in respect to data residence. In his post, James goes further, or perhaps better stated, starts earlier. Raising awareness on the paths that data travels, to reach its destination:
“How would an application operator deploy applications at a minimum "distance" from users in a network sense, without finding themselves passing data through a country that would jeopardize the safety of that data? Again, the path your data takes between two physical locations may not be the path you expected.
You are already seeing some examples of how the governments and corporations are trying to mold the Internet and "the cloud" to fit into human geopolitical realities. Countries like China, Iran, Pakistan, and others have demonstrated their willingness to control the Internet transoms over their nation’s borders, and to apply technology to controlling the "border traffic" at those crossing points.”
In his post, James makes some great observations on computing versus world boundaries, and poses a challenge for cloud computing, networking, business and political leaders:
“What’s missing, however, is any form of formal infrastructure within the Internet/Intercloud itself to "automate" mapping the human world to the computer world. Is this even possible, I often wonder. Can we (or, more to the point, should we) try to "codify" the laws and regulations of the world into digital form, allowing computer networks and applications to self-regulate?
What would the political fallout of such a system be?
In cloud computing, "virtual" geography and "physical" geography are both extremely important, and it’s up to humans to keep the two aligned. Because this is complex and prone to error, it may be one of the great business opportunities to come out of the disruption that cloud computing is wreaking on IT practices.”
Read his post. Remember it’s not just the destination, but also the journey that counts.
Tagged as:
geopolitics,
intercloud,
James Urquhart,
location
Posted by brenda michelson at 11:38 am in 100-days, Cloud Watch, adoption, data, networks | Permalink
| Comments(0)
| Trackback URL
Continuing my survey of the cloud computing surveys, I’ve been staring at the results from the June 2009 CIO Magazine cloud computing survey, wondering what I’m missing. The responses that have me scratching my head are related to cloud computing drivers, budget spend and budget reductions. Snapshots of the three questions follow.
[Click on pictures to enlarge].
As you can see, the first question shows reduce hardware and staffing costs as the primary drivers of cloud computing. The second question attempts to quantify this savings (% budget reduction) over time. Take note of the Average (Mean) line. The expected reductions are 5.6%, 7.6% and 9.3% over 1, 3 and 5 years respectively. As a former Senior IT leader with budget responsibility, I recognize that 5.6-9.3% budget savings aren’t easy to come by, and certainly add up as savings, or provide an alternative source for strategic investments.
So, all good. Until you review the Average (Mean) line of the projected spend question. That line shows on-demand service expenditure as 5.6%, 8.0% and 10.2% of budget over 1, 3 and 5 years respectively. Comparing the spend against savings, you’ll see the spend is equal to, or greater than, the projected savings.
Ok. Initial years IT spend outpacing projected savings isn’t exactly a newsflash. IT is a long-term investment, and return isn’t immediate. Certainly, if respondents are building on-premise cloud computing environments, you would expect a longer time period to savings, with a more sustainable savings stream.
However, this survey focused on “on-demand services”, as in ‘from away’:
“The way most CIOs define cloud computing today is as a Software-as-a-Service-like arrangement where your company does not own the software, hardware or any specific equipment run by the provider. Access to the cloud vendor’s systems takes place over the Internet in some secured way and for that access, customers pay a subscription fee that rises or falls with the level of use. Cloud computing offerings are often referred to as “on-demand services”, “cloud services”, “Software-as-a-Service (SaaS)”, etc.”
Translation: a subscription (rental) economic model. If that’s the case, then this survey shows that on average, organizations are paying more in rent than they expect to recoup as savings. Obviously, no CIO is consciously making that call, spend $1.00 to save 90 cents, indefinitely. Something is missing, and I don’t think it’s me.
Rather, there are business value benefits the survey didn’t consider, such as shortening time to value, increased focus on core capabilities, extending a value chain, or even the creation of short-term business innovation spaces.
So, this is a long-winded way of saying, do benchmark analysis, but then do your own math. In doing that math, don’t limit your sights to the IT side of the equation.
Tagged as:
business drivers,
CIO Magazine,
enterprise considerations
Posted by brenda michelson at 5:21 pm in 100-days, Cloud Watch, adoption, economics | Permalink
| Comments(0)
| Trackback URL
Last week, in discussing findings from the BT Global Services Enterprise Intelligence survey, I wrote about why cloud computing environment location matters:
“Many of the clouderati will tell you that the physical location of the cloud computing environment shouldn’t matter to adopters. While technically and architecturally this might be true, given appropriate and reliable network connections, there are business implications of physical location. Most notably, regulatory and compliance concerns for cloud-resident data.”
Today, via Twitter, I became aware of an Interactive Data Protection Heat Map, published by Forrester, and shared on their Infrastructure & Operations Professionals blog:
“To help you grasp the varying scope of regulatory requirements at a high level, we’ve also created an interactive privacy heat map that denotes the degree of strictness — highlighting scope of protection, affected entities, ‘adequacy’ standards met, and heavily surveilled countries — across national data protection regulation.”
The map is in Flash, go check it out.
Tagged as:
enterprise considerations,
Forrester
Posted by brenda michelson at 2:31 pm in 100-days, Cloud Watch, adoption, data, regulatory | Permalink
| Comments(0)
| Trackback URL