There is a little here on CIOupdate about CIO concerns with cloud security. The article is short and a little overblown in how both sides are represented.
I’m currently talking to CIOs and CISOs at large enterprises and I’m not hearing any ‘panic’ so much as pragmatic concerns about securing cloud usage. The folks who are in charge of evaluating cloud services seem to be more concerned about auditability, accountability, and cost controls than enforcing enterprise security mechanisms on cloud systems.
To paraphrase a VP of Enterprise IT at a Fortune 50 company
This looks like an identity management problem to me. I’m more concerned about knowing what a user stored in the cloud or what servers are in use. How do I remove those files or turn off those servers when that user leaves us?
CloudScale will elegantly enable the secure management of clouds. Best of all, it was developed by infrastructure and security experts!
June 23rd, 2008
If you haven’t noticed, the cloud computing conversation is in full swing. There has been a vigorous discussion recently on both blogs and the Cloud Computing Group around defining ‘cloud computing’ and everyone is taking a swag at it; usually with their own bias. Of course, I already have my own bias (ha!), but Reuven Cohen, CTO of Enomalism, had a recent posting, Describing Cloud, that I want to respond to.
Internet Centric Services
Reuven uses the notion of ‘internet centric software’ to describe cloud computing services and talks about a shift happening from a ’single tenant approach to software development’ to a ’scalable, multi-tenant, multi-platform, multi-network’ approach. I like the notion of ‘internet centric software’ and for me, it says much about the fact that the latest boom is one where people are trying to find new Internet-relevant business models rather than trying to move bricks and mortar online.
Calling it ’software’ still irks me, though. Developers aren’t consuming software in this new world. They are consuming cloud services, adding traditional software development, and putting together all new applications that are greater than the sum of the parts.
The Real Buzzword
What really irks me more is the notion that there is one problem: scale. If there is one buzzword that is more useless or more watered down than ‘cloud computing’, it’s got to be so-called ’scale’. Beyond the fact that it’s misunderstood and treated like a panacea is the fact that it masks a whole set of real, compelling problems and solutions.
On-demand is in Demand
Let me walk you through this. Amazon has already told us that the majority of their AWS customers aren’t startups, but large corporations. Are large corporations building scalable websites?
No. They have other needs. Cloud services value propositions serve both ’scale’ and these other needs.
As I see it, the fundamental value props of cloud services are:
- Scalability
- Elasticity
- Speed
- Reach
Scalability
Everyone knows this one, so I won’t dwell on it too much, except to define it clearly. Scale is the ability of your resources to service demand. A scalable site, system, or business is able to manage resources in such a way that it meets the service, product, or consumer demands as they grow. That’s it. Nothing more. The trick is that most things, online or off, aren’t designed to scale by default. In the simplest terms, it’s your ability to handle the Slashdot or Digg Effect.
Elasticity
This gets lumped in with scalability, but it’s not exactly the same thing. You need elasticity when you have to go from zero to ‘lots’ quickly, but not necessarily because you have a consumer or other uncontrollable demand. For example, you might need to crunch a large amount of data periodically or perhaps you need to do 10 test runs of your application deployment simultaneously. It’s a predictable, quantifiable need that is under your control, but now you can get on-demand resources to service that need, where before you couldn’t. I think the majority of greenfield cloud usage is of this type.
Speed
Easy: “I need 10 servers in the next hour to finish this project on time.” I believe this particular use case is extremely prevalent with enterprise customers right now. There is much less friction in turning on 10 servers on EC2 than trying to get them through corporate IT. Combined with elasticity, you can get tremendous leverage and significantly reduce time to market or time to complete a project.
Reach
This is part of what Reuven was alluding to in the original posting where he says ‘global’. We haven’t seen this as much yet, but will soon. As clouds go global, your ability to more directly reach a given market goes up dramatically. I like to think about the Friendster case.
Friendster is a U.S. bred-and-born social network; one of the first in fact. It had strong initial traction in the U.S., but was eventually eclipsed by MySpace and Facebook. Yet, Friendster is still around, mostly in Asia. In fact, 39% of it’s traffic is from the Philippines. In a world where clouds are global, it will be easy for a Friendster to shift infrastructure as markets shift, resulting in better service to and huge cost savings in serving those markets.
Summary
So what’s the punchline? It’s going to take a while for the terms to settle down, but don’t be overly swayed by the ’scalability’ proposition. Not only is scalability not easy to create, but it’s not just about scale. There are some very powerful ways to gain leverage through the elasticity, speed, and reach that cloud computing services enable.
June 22nd, 2008
I just found an interesting PowerPoint presentation on Cloud Services from Forrester that seems pretty complete, especially as it relates to the enterprise. You can find it here (PPT).
Also, James Urquhart has a nice wrap-up of some of the recent discussion over ‘cloud computing’ terminology.
June 12th, 2008
There seems to be a group myopia around so-called ‘cloud computing’ and it’s definitions. What we’re really talking about are ‘cloud services’ of which, ‘computing’, is only a subset. It gets worse when you have people talking about Software as a Service (SaaS) as a ‘cloud’ service. Things continue to become murkier when the SaaS crowd, bloggers, and reporters start making up new definitions for cloud services using SaaS-like terms such as Platform as a Service (PaaS) and Infrastructure as a Service (IaaS).
Soon we’ll have Hosting as a Service (HaaS), Services as a Service (SVCaaS), and Name Your Flavor as a Service (*aaS, better known as just plain ‘aaS’). Of course SaaS is just the re-hashing of the whole Application Service Provider (ASP) model from the late 90s anyway. You remember?
Let me explain what cloud services are, where they came from, and where they are going.
Cloud Services
Cloud services are not SaaS. They are far more akin to web services and this is part of why Amazon’s cloud services are simply called ‘Amazon Web Services‘. Cloud services encompass a number of different kinds of service, but they share some common attributes with each other and web services, including:
- simple point services meant to be integrated into a larger application
- machine-consumable via network-based APIs (commonly REST or SOAP)
- ‘infinitely scalable’ (meaning: ‘no practical limit’)
- in-the-cloud
- self-service
- on-demand
By contrast, most Software-as-a-Service products are fully-baked applications such as Salesforce.com’s CRM application. Another quick way to identify SaaS is that the user interface is usually the primary interface with the API being an afterthought. In comparison, most cloud services have an API as the first interface and a UI as a
secondary interface if one even exists.
Cloud vs. Web Services
Web services are historically a large business (i.e. ‘enterprise’) based technology trend. SOAP and the WS-* standards defined web services and their consumption. Web services, for this reason, existed mostly behind the firewall and were created and consumed within large organizations. Cloud services are similar to web services, but differ in terms of who uses them and where they are deployed (i.e. ‘in the cloud’).
Cloud services are fundamentally game changing, where web services are just ‘ho-hum’. They are the final democratization and commoditization of ‘web services’ out in the cloud, usually created by many different organizations, and consumed by anyone. This is a natural response to market forces seeking to have more control, scale, and usage from ‘web services’. Web services, like most recent Internet related technologies are more interesting when the power of ‘the net’ is applied. In other words:
web services (’ho-hum’) + network effect == cloud services (’holy cow!’)
If nothing else shows us how much cloud services look like web services, then ‘Amazon Web Services’ product offerings should. A short list of what they provide:
- Compute
- Storage
- Database
- Messaging / Queuing
- Payment processing
- Search
As you can see, these are all simple point applications, consumable via an API, for use as part of a larger application and of minimal use by themselves. They are not even marginally related to SaaS. As individual services they aren’t terribly interesting, but in terms of their ability to provide you leverage for your application, to quickly accelerate some need that you have when initially developing, or to allow you to get a large amount of ‘scale‘ once you grow is of tremendous value.
Clouds as Platforms and Infrastructure (aaS)
This recent RightScale blog entry inspired this post and what I think they are really talking about here is breaking ‘cloud services’ down into two main categories: platform-based models and infrastructure-based models. Both of these are defined fairly well in the RightScale blog posting (other than the association with SaaS terms). What is important to notice is that this isn’t an either/or situation. You don’t need to pick one or the other: platform or infrastructure. You’ll almost certainly wind up using both.
Build your prototype in Google’s AppEngine and have it use Amazon’s Flexible Payment System (FPS) to process payments. Or build it on Amazon’s Elastic Compute Cloud (EC2) and have it use Google Checkout. Do what is right for your application.
Cloud Service Trends
The continued trend is towards self-service, democratized, vote-with-your-dollars, cloud services that can be used to composite together or bolster your application development, decrease time to market, and provide new kinds of software development leverage. This means that cloud service providers, and the developers who build value added services on top of them, need to compete using strategies where their services have inherent synergies (a la the AWS ‘ecosystem’), on service or service level agreements, or by continuing to innovate in advance of competitors. Right now it looks like Amazon is doing this across the board while most others are playing catchup.
The continued driving forces will be ease-of-use, choice, and ability to use cloud services as part of larger applications for startups, small businesses, and soon larger enterprises.
Future of Cloud Services
The future of cloud services is one where you will select and composite the best (or cheapest) services for your application. Some combination of services will be right for your application and the tools that help you build and put together these services will be critical to your success. This means that tools that support multiple providers or abstract them in such a way that ease your ability to integrate and consume them will be clear winners.
May 30th, 2008
I’m quite pleased to see that you can now get OpenSolaris with Amazon’s EC2. OpenSolaris on EC2 means that you can now run your storage and/or databases in the cloud on top of the ZFS filesystem.
Among the number of truly outstanding capabilities of ZFS are, snapshots, cloning, compression and soon encryption. A little known feature is the ability to send a ZFS filesystem as a data stream. More importantly, you can send ‘incremental’ data streams.
What does this mean?
First and foremost it means that replicating data inside the EC2 cloud just got a *lot* easier.
It also means it is now feasible to have a replica of your data off-site at your office or another datacenter without paying exorbitant transfer prices. You’ll pay once to take make a ‘full’ replica and then afterwards you can keep that replica up-to-date by sending ‘incremental’ snapshot streams on an hourly (or more frequent) basis.
This will work quite well and be extremely cost-efficient even with a large dataset as long as you aren’t changing large amounts of data over short periods of time.
Given that a Yottabyte of capacity is on the horizon, this is welcome news for effectively managing your data.
May 7th, 2008
Next Posts
Previous Posts