As a Service: The many faces of the cloud
Last month I happened across this amusing, and ironic, poem[now defunct, the original poem can be found here] describing the dichotomy that exists in trying to define cloud computing. Go ahead and read it, I'll wait, it's worth the time. Seriously. I am not going to define cloud computing again. I've done that already and the point of this discussion is not what is cloud computing but rather how the cloud is beginning to separate into distinct models, each serving a different set of needs. The common theme between these models is "as a service". Some "thing" traditionally relegated to the local IT data center is being offered in the cloud, as a service. The list is growing, but it appears that we'll likely end up with three service models for the cloud: software, infrastructure, and platforms. SOFTWARE AS A SERVICE (SaaS) Software as a Service (SaaS) was pioneered and proven as a successful model by salesforce.com, and has since been duplicated successfully by myriad other vendors. The SaaS model works on the assumption that all enterprises need is the ability to customize and integrate software (which is, for the most part, true of a wide variety of software offerings) and need not (a) reinvent the wheel or (b) worry about the actual implementation/deployment details. SaaS is a good choice when: You need software to support common business processes like customer relationship management You need some customization but it is primarily at the data level and not at the application logic level The software in question needs to support a geographically diverse pool of employees PLATFORM AS A SERVICE (PaaS) Platform as a Service (PaaS) is a somewhat emerging concept that is gaining traction for several reasons. PaaS is based on the premise that you want or need a development and deployment platform in the cloud and are willing to essentially outsource the platform to a cloud computing provider because you want to ultimately deploy the application you are developing in the cloud. PaaS moves the development and deployment platform "into the cloud". For a good example of a PaaS, check out Bungee or Google App Engine. PaaS is a good choice when: You want to deploy an application into the cloud but aren't interested in dealing with a virtualized infrastructure You want to try out an application to test adoption or interest but don't have the budget to invest in the necessary infrastructure You would otherwise build a departmental level applications that would traditionally be served from an unmanaged server hiding under someone's desk You're a startup whose offering will be a web based application INFRASTRUCTURE AS A SERVICE (IaaS) Lastly, we have Infrastructure as a Service (IaaS). IaaS is what most people think of when they hear the term "cloud computing". This model essentially leases out infrastructure resources on which applications are deployed. The applications are then able to scale up and down as necessary, on-demand, using the provider's infrastructure - saving the organization a lot of capital expenditures and operating expenses in acquiring, deploying, configuring, and managing the infrastructure. IaaS often takes the form of virtualized computing environments, leveraging virtual images to alleviate the typical problems associated with remote hosting of applications in aligning operating systems, application servers, hardware, and other application specific details with the needs of the customer. Virtualized computing environments allow the customer to configure and deploy the application in a virtual image locally and then execute it within a remote environment without worrying about the underlying server and network infrastructure. BlueLock and Amazon EC2 are good examples of IaaS providers. IaaS is a good choice when: You need a second data center for disaster recovery only but the investment in land, building, and infrastructure is too costly You have a need for seasonal capacity but the revenue generated during those times would be diluted or erased by investing in the infrastructure to support the rushes You want to leverage geographical based global load balancing to better serve international visitors but wish to avoid the investment in multiple data centers or hassle of co-locating servers around the globe You want to use the cloud to host bandwidth or storage intense resources (video, images) and integrate them with your applications to offset the cost of more bandwidth or a new storage infrastructure. Yes, cloud computing is very much part of the buzzword bingo game today (I failed to win, as you can see, but I'll try harder next time), but there are real benefits and valid reasons for looking into it right now. Don't let the hype surrounding cloud computing distract you from the potential benefits, but don't drink the kool aid too deeply, either, and commit to a model that isn't a good fit for you and your needs.Cloud Computing: The Last Definition You'll Ever Need
The VirtualDC has asked the same question that's been roaming about in every technophile's head since the beginning of the cloud computing craze: what defines a cloud? We've chatted internally about this very question, which led to Alan's questions in a recent blog post. Lori and others have suggested that the cloud comes down to how a service is delivered rather than what is delivered, and I’m fine with that as a long term definition or categorization. I don’t think it’s narrow enough, though, to answer the question “Is Gmail a cloud service?” because if Gmail is delivered over the web, my internet connection is my work infrastructure, so therefore…Gmail is a cloud service for me? No, it's not. It may be for the developers, if they're using cloud computing to develop and deploy GMail, but for you it's naught but cloudware, an application accessed through the cloud. From the end-user perspective it's a hosted application, it's software as a service (SaaS), but it isn't cloud computing or a cloud service. The problem here, I think, is that we're using the same terms to describe two completely different things - and perspectives. The real users of cloud computing are IT folks: developers, architects, administrators. Unfortunately, too many definitions include verbiage indicating that the "user" should not need any knowledge of the infrastructure. Take, for example, Wikipedia's definition: It is a style of computing in which IT-related capabilities are provided “as a service”, allowing users to access technology-enabled services from the Internet ("in the cloud") without knowledge of, expertise with, or control over the technology infrastructure that supports them. It's the use of "user" that's problematic. I would argue that it almost never the case that the end-user of an application has knowledge of the infrastructure. Ask your mom, ask your dad, ask any Internet neophyte and you'll quickly find that it's probably the case that they have no understanding or knowledge (and certainly no control) of the underlying infrastructure for any application. If we used the term "user" to mean the traditional end-user, then every application and web site on the Internet is "cloud computing" and has been for more than a decade. FINALLY, IT REALLY IS ALL ABOUT *US* The "user" in cloud computing definitions are developers, administrators, and IT folks. Folks who are involved in the development and deployment of applications, not necessarily using them. It is from IT's perspective, not the end-user or consumer of the application, from which cloud computing can be - and must be - defined. We are the users, the consumers, of cloud computing services; not our customers or consumers. We are the center of the vortex around which cloud computing revolves, because we are the ones who will consume and make use of those services in order to develop and deploy applications. Cloud computing is not about the application itself; it is about how the application is deployed as how it is delivered. Cloud computing is a deployment model leveraged by IT in order to reduce infrastructure costs and/or address capacity/scalability concerns. Just as an end-user cannot "do" SOA, they can't "do" cloud computing. End-users use applications, and an application is not cloud computing. It is the infrastructure and model of deployment that defines whether it is cloud computing, and even then, it's never cloud computing to the end-user, only the folks involved in developing and deploying that application. Cloud computing is about how an application or service is deployed and delivered. But defining how it is deployed and delivered could be problematic because when we talk about how we often tend to get prescriptive and start talking in absolute checklists. With a fluid concept like cloud computing that doesn't work. There's just not one single model nor is there one single architecture that you can definitively point to and say "We are doing that, ergo we are doing cloud computing." THE FOUR BEHAVIORS THAT DEFINE CLOUD COMPUTING It's really about the behavior of the entire infrastructure; how the cloud delivers an application, that's important. The good thing is that we can define that behavior, we can determine whether an application infrastructure is behaving in a cloud computing manner in order to categorize it as cloud computing or something else. This is not dissimilar to SOA (Service Oriented Architecture), a deployment model in which we look to the way in which applications are architected and subsequently delivered to determine whether we are or are not "doing SOA." DYNAMISM. Amazon calls this "elasticity", but it means the same thing: this is the ability of the application delivery infrastructure to expand and contract automatically based on capacity needs. Note that this does not require virtualization technology, though many providers are using virtualization to build this capability. There are other means of implementing dynamism in an architecture. ABSTRACTION. Do you need to care about the underlying infrastructure when developing an application for deployment in the cloud. If you have to care about the operating system or any piece of the infrastructure, it's not abstracted enough to be cloud computing. RESOURCE SHARING. The architecture must be such that the compute and network resources of the cloud infrastructure are sharable among applications. This ties back to dynamism and the ability to expand and contract as needed. If an application's method of scaling is to simply add more servers on which it is deployed rather than be able to consume resources on other servers as needed, the infrastructure is not capable of resource sharing. PROVIDES A PLATFORM. Cloud computing is essentially a deployment model. If it provides a platform on which you can develop and/or deploy an application and meets the other three criterion, it is cloud computing. Dynamism and resource sharing are the key architectural indicators of cloud computing. Without these two properties you're simply engaging in remote hosting and outsourcing, which is not a bad thing, it's just not cloud computing. Hosted services like Gmail are cloudware, but not necessarily cloud computing, because they are merely accessed through the cloud and don't actually provide a platform on which applications can be deployed. Salesforce.com, however, which provides such a platform - albeit somewhat restricted - then fits into the definition of cloud computing. Cloudware is an extension of cloud computing but they do not enable businesses to leverage cloud computing in the same way as an Amazon or BlueLock or Joyent. Cloudware may grow into cloud computing, as Salesforce.com has done over the years. Remember when Salesforce.com started it was purely SaaS - it simply provided a hosted CRM (Customer Relationship Management) solution. Over the years it has expanded and begun to offer a platform on which organizations can develop and deploy their own applications. Cloud computing, as Gartner analysts have recently put forth, is a "style of computing". That style of computing is defined from the perspective of IT, and has specific properties which make something cloud computing - or not cloud computing as the case may be.Cloud Computing: It's the destination, not the journey that is important
How the cloud acts and is used is more important than where it physically resides Cloud computing and SOA suffer from the same lack of prescriptive architectures. They are defined by how they act rather than what they are, or from what they are composed. They are, in a way, existential technology that cannot be confined to a simple architectural diagram but require instead a set of properties or ways of acting in order to be recognized. To over simplify and paraphrase Jean-Paul Sartre's concepts of existentialism, we define ourselves (mankind) through our actions. To apply this to technology is a fairly easy thing: some technology is defined through what it does rather than what it is. Cloud computing is nothing but the way in which an infrastructure deploys and delivers applications. That will surely irritate cloud purists as much as the impure use of object-oriented principles used to annoy me when I was first developing applications. But with age and experience comes wisdom, and the hind-sight to see that there are many roads which lead to the same end. Unlike many philosophical theories, with technology it often is the destination and not the journey that is important. Definition of Cloud Computing The First Principle of Existentialism "Gartner defines cloud computing (hereafter referred to as "cloud") as a style of computing where massively scalable IT-related functions and information are provided as a service across the Internet, potentially to multiple external customers, where the consumers of the services need only care about what the service does for them, not how it is implemented. Cloud is not an architecture, a platform, a tool, an infrastructure, a Web site or a vendor. It is a style of computing. Many architectures can be used to support its implementation and use. For example, it is possible to use cloud in private enterprises to build private clouds, but there is only one public cloud based on the Internet." SOURCE: GARTNER RESEARCH ID: G00157908 28 MAY 2008 Man is nothing but what he makes of himself. SOURCE "ESSAYS IN EXISTENTIALISM" JEAN-PAUL SARTRE 1965 The First Principle of Cloud Computing Cloud computing is nothing but the way in which an infrastructure deploys and delivers applications. Many pundits argue that the "cloud" in "cloud computing" is the Internet, and only the Internet. But it's telling that almost every application architecture diagram offered up uses the same "cloud" 'to represent the network, whether it's internal or external to the organization. That "cloud" represents abstraction, obfuscation, and is meant to show that there is a network responsible for delivering the applications depicted, it's just too complex (or sensitive) to be depicted in a diagram or, as is more often the case, the folks responsible for application infrastructure aren't concerned about the network infrastructure supporting the applications. Which brings us back full circle to the definition of cloud computing, which includes a lack of concern regarding the implementation details of how applications get delivered. As Gartner has posited, the cloud is not an architecture, a platform, a tool, or an infrastructure. It's not a web site, it's not a vendor. "It is a style of computing." It is a deployment model, much in the same way SOA is a style of computing; it is a deployment model and not a prescriptive architecture. It defines itself by how it acts, not what it is. If it is used to deliver applications in a way that is transparent, that does not require the end-user to understand (or concern themselves with) the underlying infrastructure - application and network - then it likely fits under the moniker "cloud computing". If the same principles used by vendors like Amazon, BlueLock, Joyent, and Microsoft are used by organizations to implement a dynamic, scalable on-demand application and network infrastructure, does it really matter where that infrastructure physically resides? If Microsoft deploys an application in its own cloud, in its data center, and then makes use of that cloud for internal organizational applications, is it still cloud computing? Yes, of course it is. So why should it matter if an enterprise does the same thing? It's still cloud computing based on how the infrastructure acts and what it delivers, not where it is or who uses it. What's important is what the cloud infrastructure does. Scalability, transparency, supporting an on-demand computing model. That's what cloud computing is, whether it's implemented as SaaS (Software as a Service) or as IaaS (Infrastructure as a Service) or using automated virtualization solutions within the data center. As long as the infrastructure you build out is capable of providing the benefits of cloud computing: efficiency, scalability, and agility, you're doing cloud computing. That sounds a lot easier than is, because you have to scale while being efficient, and you have to be agile without sacrificing scalability, and you have to do it in a way that the end-user (who may be a developer) doesn't need to know how its implemented. So rather than worry about how, worry about what. At the end of your implementation is your infrastructure agile? Is it scalable (transparently)? Is it efficient? Is it abstracted? Does it support on-demand computing without sacrificing those properties? If it is, then you've reached your cloud computing destination.
DevCentral Top5 08/28/2009
I submit to you my second attempt at this week's Top5 after a vile BSoD swooped down and smote my first attempt into a pile of fiery ash. There were a couple announcements this week on DevCentral along with the expected awesome technical content. I'll try to touch on those as well as a couple other things that you should definitely check out in this week's DevCentral Top5: Announcing F5 Management Pack 1.4 for Microsoft System Center Operations Manager 2007 http://devcentral.f5.com/s/weblogs/sfisher/archive/2009/08/25/announcing-f5-management-pack-1.4-for-microsoft-system-center-operations.aspx The hard-working, quick-moving management pack team here at F5 brings you the newest version of the Management Pack for SCOM. This version includes increased platform support, auth roles integration, built-in discovery, device config and more. If you haven't looked into what the Management Pack can do for you, I highly suggest you take a look. You can check out all sorts of things that the package can be used for in the frequently updated tutorials on DevCentral. If you're using SCOM and have F5 devices, this is definitely something you should look into. DevCentral Weekly Roundup Episode 100 - The Century Mark http://devcentral.f5.com/s/weblogs/dcpodcast/archive/2009/08/27/devcentral-weekly-roundup-episode-100-the-century-mark.aspx The weekly podcast is not new to the Top5, but this week's is particularly special. This week we crossed the century mark with our 100 th podcast. It took us longer than 100 weeks, but we made it. We've grown immensely as a community and as a team in that time and it was fun to take a few minutes to reminisce on our favorite moments in time with DC. Listen to Jeff talk about electrical storms in Malaysia, Joe talk about sumo wrestling in Japan, and other things that are at least somewhat related to DC and the technology, I promise. Whether you've been with us for years or you're new to DevCentral, this one's a fun look at where we've been and perhaps some hints at where we're going. Survey iPod Touch Winners + Thanks for the Fantastic Response http://devcentral.f5.com/s/weblogs/JeffB/archive/2009/08/27/6076.aspx Jeff extended a hearty thank you to all of the respondents to the most recent DevCentral survey, and I wanted to point it out and extend mine as well. We got some absolutely fantastic results, with over 500 people responding with some very interesting and useful information. This kind of thing is amazingly useful to driving the DevCentral community forward and making sure we're doing so in a direction that makes the most sense for the members. This one isn't a super deep technical post but it's noteworthy just the same and I wanted to call it out. I'm sure you'll be seeing some snippets of this info as we absorb it and choose bits to share, so keep an eye out and thank you again for your involvement. The End of DNS As We Know It http://devcentral.f5.com/s/weblogs/macvittie/archive/2009/08/28/the-end-of-dns-as-we-know-it.aspx Lori talks about the imminent death of DNS as we know it, foretelling the rise of GSLB in its place. Given the up and coming infrastructures that seemingly all rely on multiple points of data storage/processing interacting together to deliver a given application, I can see where she'd get that impression. While I'm not quite ready to get the nails out for the coffin, and to be fair that's not what Lori is saying either, I do completely agree with her in that DNS was not designed to handle the demands of the distributed architectures of today and certainly not those of tomorrow. As such it's going to have to be replaced sooner or later. There are already serious pain points when dealing with DNS for applications that demand more of it than it is prepared to deliver, and those issues are only going to continue getting worse, not better. GSLB seems to be the natural successor, with many people already well on-board. Are you ready for the change? If not, it might be time to start thinking about it. The Importance Of Integration In The Future Of The Cloud With BlueLock http://devcentral.f5.com/s/weblogs/interviews/archive/2009/08/25/the_future_of_the_cloud_with_bluelock.aspx Tune in as Ken Salchow talks with Pat O'Day from BlueLock about cloud computing, F5's role in making some of the features BlueLock offers possible, and how important integrating that technology with server virtualization technology is to them. If you're looking for an inside scoop on what at least one cloud provider is up to, what they're thinking and how they're doing what they do, this is a pretty cool look at just that. It also provides some solid insight into how virtualization of both the hardware and network resources is vital to making the scaling that clouds are so famous for possible. I enjoyed getting to hear from the horse's mouth how these technologies are being put to use today to produce a robust platform for your application. That's the Top5 for this week. If you've got questions, comments or otherwise, don't hesitate to drop me a line. You can always check out previous editions of the Top5 here - http://devcentral.f5.com/s/Default.aspx?tabid=101 #ColinCloud Today is Just Capacity On-Demand
We won’t have true cloud computing until we have a services-based infrastructure and standardization of cloud management frameworks. We may call it “cloud” today, but what we really have with the offerings today is “capacity on demand.” We don’t actually have all the pieces necessary to execute on the vision that is “cloud computing.” We’ve almost completed server standardization through virtualization but we haven’t really begun to standardize network and infrastructure services. And we’re certainly nowhere near ready to standardize on the cloud and application frameworks that will enable a seamless Intercloud. The term “utility” has many meanings. One of them is an “economic term referring to the total satisfaction received from consuming a good or service.” The utility of cloud computingcompute on-demand services today is fairly middling on the “W00T” scale from an enterprise consumer perspective. On a scale of 1 to 10 I’d say we’re at about 3 today. We’re at compute resources as a service, at capacity on demand, but we’re not at infrastructure as a service. We’re not even really close yet.
