I just read a very nice post on the profile for a cloud server by Ernest de Leon, the Silicon Whisperer. Here is the opening paragraph:
"With the massive push toward cloud computing in the enterprise, there are some considerations that hardware vendors will have to come to terms with in the long run. Unlike the old infrastructure model with hardware bearing the brunt of fault tolerance, the new infrastructure model places all fault tolerance concerns within the software layer itself. I won’t say that this is a new concept as Google has been doing exactly this for a very long time (in IT time at least.) This accomplishes many things, but two particular benefits are that load balancing can now be more intelligent overall, and hardware can be reduced to the absolute most commodity parts available to cut cost."
I'm on board in a big way with this message until Ernest starts talking about the steps that are taken at failure:
"When there is a failure of a component or an entire cloud server, the Cloud Software Layer can notify system administrators. Replacement is as simple as unplugging the bad server and plugging in a new one. The server will auto provision itself into the resource pool and it’s ready to go. Management and maintenance are simplified greatly."
And I think to myself that there is no way we can operate at cloud scale if we continue to think about racking and plugging servers. If we really want to lower the cost of operational management, which is a big part of the appeal of cloud, we have to start thinking about the innovations that should happen throughout the supply chain.
Commodity parts are great, but I want commodity assembly, shipping, and handling costs as well. The innovations in cloud hardware will be packaging and supply chain innovations. I want to buy a rack of pre-networked systems with a simple interface for hooking up power and network and good mobility associated with the rack itself (i.e. roll it into place, lock it down, roll it out at end of life). Maybe I even want to buy a container with similar properties. And when a system fails, it is powered down remotely and no one even thinks about trying to find it in the rack to replace it. It is dead in the rack/container until the container is unplugged and removed from the datacenter and sent back to the supplier for refurb and salvage.
Let's use "cloud" as the excuse to get crazy for efficiency around datacenter operations. I agree with Ernest that the craziness for efficiency with netbooks has led to a great outcome, but let's think crazy at real operating scale. No more hands on servers. No more endless cardboard, tape, staples, and styrofoam packaging. No more lugging a server under each arm through the datacenter and tripping and dropping the servers and falling into a rack and disconnecting half the systems from the network. My cloud server is a rack or a container that eliminates all this junk.
Thursday, November 19, 2009
Monday, November 9, 2009
Virtualization is not Cloud
After spending the early part of last week at the Cloud Computing Expo, which is now co-located with the Virtualization Conference and Expo, I feel compelled to proclaim that virtualization is not cloud. Nor does virtualization qualify for the moniker of IaaS. If virtualization was cloud/IaaS, there would not be so much industry hubbub surrounding Amazon's EC2 offering. Nor would Amazon be able to grow the EC2 service so quickly because the market would be full of competitors offering the same thing. Cloud/IaaS goes beyond virtualization by providing extra services for dynamically allocating infrastructure resources to match the peaks and valleys of application demand.
Virtualization is certainly a valuable first step in the move to cloud/IaaS, but it only provides a static re-configuration of workloads to consume fewer host resources. After going P2V, you have basically re-mapped your static physical configuration onto a virtualization layer – isolating applications inside VMs for stability while stacking multiple VMs on a single machine for higher utilization. Instead of physical machines idling away on the network, you now have virtual machines idling away, but on fewer hosts.
To transform virtual infrastructure to IaaS, you need, at a minimum, the following:
Self Service API – if an application owner needs to call a system owner to gain access to infrastructure resources, you do not have a cloud. Upon presentation of qualified, valid credentials, the infrastructure should give up the resources to the user.
Resource Metering and Accountability – if the infrastructure cannot measure the resources consumed by a set of application services belonging to a particular user, and if it cannot hold that user accountable for some form of payment (whether currency exchange or internal charge-back), you do not have a cloud. When users are charged based upon the value consumed, they will behave in a manner that more closely aligns consumption with actual demand. They will only be wasteful when wasting system resources is the only way to avoid wasting time, which leads us to our next cloud attribute:
Application Image Management – if there is no mechanism for developing and configuring the application offline and then uploading a ready-to-run image onto the infrastructure at the moment demand arises, you do not have a IaaS cloud. Loading a standard OS template that does not reflect the configuration of the application and the OS combination used for testing and development prevents rapid application scaling because configuration can cost the owner hours/weeks/days/months of runtime cycles. Too much latency associated with setup results in over-allocation of resources in order to be responsive to demand (i.e. no one takes down running images even with slack demand because getting the capacity back is too slow). See my post on Single Minute Exchange of Applications.
Network Policy Enforcement – if an application owner cannot allow or deny network access to their virtual machine images without involving a network administrator or being constrained to a particular subset of infrastructure systems, you do not have a cloud. This requirement is related to the Self Service API and it also speaks to the requirement for low latency in application setup in order to be dynamic in meeting application demand fluctuations. True clouds provide unrestricted multi-tenancy (and therefore higher utilization) without compromising compliance policies that mandate network isolation for certain types of workloads
There maybe other requirements that I have missed, but in my mind, this is the minimum set. Any lesser implementation leads to the poor outcomes that are currently the bane of IT existence – VM Sprawl and Rogue Cloud Deployments.
VM sprawl results from lack of accountability for resource consumption (or over-consumption), and it also results from inefficient setup and configuration capabilities. If I don't have to pay for over-consumption, or if I cannot respond quickly to demand, I am not going to bother with giving back resources for others to use.
Rogue cloud deployments, unsanctioned by IT, to Amazon or other service providers result from lack of self service or high latency in requests for network or system resource configuration. Getting infrastructure administrators involved in every resource transaction discourages the type of dynamic changes that should occur based upon the fluctuations in application demand. People give up on the internal process because Amazon has figured it out.
True clouds go beyond virtualization by providing the necessary services to transform static virtual infrastructure to dynamic cloud capacity. These extra services eliminate the friction and latency between the demand signal and the supply response. The result is a much more efficient market for matching application demand with infrastructure supply.
Virtualization is certainly a valuable first step in the move to cloud/IaaS, but it only provides a static re-configuration of workloads to consume fewer host resources. After going P2V, you have basically re-mapped your static physical configuration onto a virtualization layer – isolating applications inside VMs for stability while stacking multiple VMs on a single machine for higher utilization. Instead of physical machines idling away on the network, you now have virtual machines idling away, but on fewer hosts.
To transform virtual infrastructure to IaaS, you need, at a minimum, the following:
Self Service API – if an application owner needs to call a system owner to gain access to infrastructure resources, you do not have a cloud. Upon presentation of qualified, valid credentials, the infrastructure should give up the resources to the user.
Resource Metering and Accountability – if the infrastructure cannot measure the resources consumed by a set of application services belonging to a particular user, and if it cannot hold that user accountable for some form of payment (whether currency exchange or internal charge-back), you do not have a cloud. When users are charged based upon the value consumed, they will behave in a manner that more closely aligns consumption with actual demand. They will only be wasteful when wasting system resources is the only way to avoid wasting time, which leads us to our next cloud attribute:
Application Image Management – if there is no mechanism for developing and configuring the application offline and then uploading a ready-to-run image onto the infrastructure at the moment demand arises, you do not have a IaaS cloud. Loading a standard OS template that does not reflect the configuration of the application and the OS combination used for testing and development prevents rapid application scaling because configuration can cost the owner hours/weeks/days/months of runtime cycles. Too much latency associated with setup results in over-allocation of resources in order to be responsive to demand (i.e. no one takes down running images even with slack demand because getting the capacity back is too slow). See my post on Single Minute Exchange of Applications.
Network Policy Enforcement – if an application owner cannot allow or deny network access to their virtual machine images without involving a network administrator or being constrained to a particular subset of infrastructure systems, you do not have a cloud. This requirement is related to the Self Service API and it also speaks to the requirement for low latency in application setup in order to be dynamic in meeting application demand fluctuations. True clouds provide unrestricted multi-tenancy (and therefore higher utilization) without compromising compliance policies that mandate network isolation for certain types of workloads
There maybe other requirements that I have missed, but in my mind, this is the minimum set. Any lesser implementation leads to the poor outcomes that are currently the bane of IT existence – VM Sprawl and Rogue Cloud Deployments.
VM sprawl results from lack of accountability for resource consumption (or over-consumption), and it also results from inefficient setup and configuration capabilities. If I don't have to pay for over-consumption, or if I cannot respond quickly to demand, I am not going to bother with giving back resources for others to use.
Rogue cloud deployments, unsanctioned by IT, to Amazon or other service providers result from lack of self service or high latency in requests for network or system resource configuration. Getting infrastructure administrators involved in every resource transaction discourages the type of dynamic changes that should occur based upon the fluctuations in application demand. People give up on the internal process because Amazon has figured it out.
True clouds go beyond virtualization by providing the necessary services to transform static virtual infrastructure to dynamic cloud capacity. These extra services eliminate the friction and latency between the demand signal and the supply response. The result is a much more efficient market for matching application demand with infrastructure supply.
Thursday, October 22, 2009
EC2 Value Shines at Amazon
On the heels of Randy Bias' excellent analysis of the market adoption of EC2 (well 3 wks later but I only read it this week), I thought I would publish the findings of the survey that we conducted on AWS value. While we do not have a huge sample size for the survey (24 responses), I do believe the answers provide some insight into the terrific uptake that Randy describes.
The large majority of respondents (92%) identified themselves as providers of some type of technology application as opposed to enterprise users. I think this mostly reflects these folks friendliness to survey requests versus enterprise users – not a lack of enterprise consumption of AWS. Those in the market with services are more likely to answer surveys due to their empathy for the pursuit of market information. Enterprise users typically have little empathy for the pursuit of information that makes them easier targets for marketers such as myself.
Almost all identified themselves as senior management in their organizations (61%), with 9% claiming middle management and the remaining 30% “breaking their back for the man.” Interestingly, the distribution of the AWS experience curve was not as skewed to the near term as I would have expected. Typically, for a hot/new service, you would expect the majority of the users to be early in their experiences. I consider early to be 6 months to a year. For our respondents, 50% had been using the service for more than a year, with the remaining 50% split 10/20/20 at the 3 month, 6 month, and 12 month experience intervals. I would have anticipated a curve more skewed to 3 to 6 months.
The most popular service of the five we surveyed is S3 (92%), with EC2 (88%) just behind. EBS trailed at 58%, with SimpleDB and SQS bringing up the rear with 17% and 21% respectively of respondents indicated they use these services. Since every EC2 user must use S3, I find the popularity of EC2 to be the most interesting, but not surprising, finding in the survey. It supports Randy's analysis, and it reflects the market generally. The amount of compute cycles sold in the form of hardware on a dollar value basis far outstrips the amount of storage sold on a dollar basis. Also, while there are several storage offerings in the market relative to S3 functionality, few providers have cracked the code on providing compute cycles via a web API with hourly granularity and massive scale in the manner of EC2. EC2 is delivering the big value to Amazon within the AWS portfolio.
To summarize the rest of the responses, scalability was the most important competitive feature followed closely by low cost and pay-as-you-go pricing. Content delivery applications were the most popular workload, with no clear-cut number 2 coming close. Users are spending between $100 and $1000 per month and almost all (67%) plan to add more workloads in the future. Many would like to see an API-compatible AWS capability running on other networks ranging from “my laptop” to their private network to service providers that might be competitive with Amazon. Check out the details for yourself.
My bottom line on this and other indicators in the market is that Amazon's approach to IaaS is effectively the modern datacenter architecture. The market growth of cloud services for compute, storage, messaging, database, etc. will largely reflect the current market for those capabilities as represented by respective sales of existing hardware and licensed solutions. But the availability of these lower friction “virtual” versions of hardware and licensed software will dramatically increase the total market for technology by eliminating the hidden, but real, costs of procurement inefficiencies. When services similar to EC2 run on every corporate and service provider network, we will have more computing and more value from computing. And the world will be a better place.
The large majority of respondents (92%) identified themselves as providers of some type of technology application as opposed to enterprise users. I think this mostly reflects these folks friendliness to survey requests versus enterprise users – not a lack of enterprise consumption of AWS. Those in the market with services are more likely to answer surveys due to their empathy for the pursuit of market information. Enterprise users typically have little empathy for the pursuit of information that makes them easier targets for marketers such as myself.
Almost all identified themselves as senior management in their organizations (61%), with 9% claiming middle management and the remaining 30% “breaking their back for the man.” Interestingly, the distribution of the AWS experience curve was not as skewed to the near term as I would have expected. Typically, for a hot/new service, you would expect the majority of the users to be early in their experiences. I consider early to be 6 months to a year. For our respondents, 50% had been using the service for more than a year, with the remaining 50% split 10/20/20 at the 3 month, 6 month, and 12 month experience intervals. I would have anticipated a curve more skewed to 3 to 6 months.
The most popular service of the five we surveyed is S3 (92%), with EC2 (88%) just behind. EBS trailed at 58%, with SimpleDB and SQS bringing up the rear with 17% and 21% respectively of respondents indicated they use these services. Since every EC2 user must use S3, I find the popularity of EC2 to be the most interesting, but not surprising, finding in the survey. It supports Randy's analysis, and it reflects the market generally. The amount of compute cycles sold in the form of hardware on a dollar value basis far outstrips the amount of storage sold on a dollar basis. Also, while there are several storage offerings in the market relative to S3 functionality, few providers have cracked the code on providing compute cycles via a web API with hourly granularity and massive scale in the manner of EC2. EC2 is delivering the big value to Amazon within the AWS portfolio.
To summarize the rest of the responses, scalability was the most important competitive feature followed closely by low cost and pay-as-you-go pricing. Content delivery applications were the most popular workload, with no clear-cut number 2 coming close. Users are spending between $100 and $1000 per month and almost all (67%) plan to add more workloads in the future. Many would like to see an API-compatible AWS capability running on other networks ranging from “my laptop” to their private network to service providers that might be competitive with Amazon. Check out the details for yourself.
My bottom line on this and other indicators in the market is that Amazon's approach to IaaS is effectively the modern datacenter architecture. The market growth of cloud services for compute, storage, messaging, database, etc. will largely reflect the current market for those capabilities as represented by respective sales of existing hardware and licensed solutions. But the availability of these lower friction “virtual” versions of hardware and licensed software will dramatically increase the total market for technology by eliminating the hidden, but real, costs of procurement inefficiencies. When services similar to EC2 run on every corporate and service provider network, we will have more computing and more value from computing. And the world will be a better place.
Wednesday, September 16, 2009
Apps.gov = Huge Step Forward for Cloud Computing
Apps.gov is nothing short of a huge milestone for the ultimate acceptance of the cloud computing paradigm shift. What is Apps.gov? According to the web site's home page:
After taking a look at the manufacturer listings in each category of the Apps.gov store, the dominant providers that stand out appear to be Salesforce.com and Google. So we dug a little deeper, and here's what we turned up.
Google and Apps.gov
Google's presence in Apps.gov includes 22 products at the time of this writing. Products include Google Apps, along with the company's search and message search products. A notable missing piece was Google App Engine for building custom applications.
FISMA Compliance and Apps.gov
The Federal Information Security Management Act (FISMA) is a title of the E-Government Act that, according its web site, "requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source." Here are some additional links about FISMA if you are interested.
One would assume that FISMA complaince would be an important requirement for inclusion on Apps.gov. But apparently not so. We couldn't find any mention of FISMA at Apps.gov, nor is FISMA mentioned in the blog announcement of Apps.gov. We contacted the site, but have not yet heard back with a statement on this subject. We'll update this post if we get some feedback.
But again, we dug a little deeper with the Apps.gov dominant providers, Google and Salesforce. Google has definite FISMA compliance plans, as the following excerpt covers in the Official Google Enterprise Blog:
We couldn't find any such compliance statement from Salesforce.com, so we asked Dan Burton, Salesforce.com's Senior Vice President of Global Public Policy. While Mr. Burton would neither confirm nor deny the company's FISMA compliance road map, he pointed out that several US federal government agencies already use many Salesforce applications and that the sheer number of Salesforce solutions in Apps.gov is a testament to the overwhelming trust that the federal government has in Salesforce systems.
And we'd be remiss if we didn't mention Amazon. Well, at least one can imagine where Amazon will fit into Apps.gov by visiting the Cloud IT Services section of the site. We guess it's coming soon.
Apps.gov is your source for cloud computing applications designed to help your agency harness the power of today's technology. Whether it's Business or Productivity Applications, Cloud IT or Social Media solutions, Apps.gov is the place to get your government agency in the cloud.
After taking a look at the manufacturer listings in each category of the Apps.gov store, the dominant providers that stand out appear to be Salesforce.com and Google. So we dug a little deeper, and here's what we turned up.
Salesforce and Apps.gov
Salesforce's significant presence in Apps.gov includes a 111 products at the time of this writing. The list includes a broad range of products in Saleforce's portfolio, including the ubiquitous Salesforce CRM package and Force.com platform for building custom web applications.Google and Apps.gov
Google's presence in Apps.gov includes 22 products at the time of this writing. Products include Google Apps, along with the company's search and message search products. A notable missing piece was Google App Engine for building custom applications.FISMA Compliance and Apps.gov
The Federal Information Security Management Act (FISMA) is a title of the E-Government Act that, according its web site, "requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source." Here are some additional links about FISMA if you are interested.One would assume that FISMA complaince would be an important requirement for inclusion on Apps.gov. But apparently not so. We couldn't find any mention of FISMA at Apps.gov, nor is FISMA mentioned in the blog announcement of Apps.gov. We contacted the site, but have not yet heard back with a statement on this subject. We'll update this post if we get some feedback.
But again, we dug a little deeper with the Apps.gov dominant providers, Google and Salesforce. Google has definite FISMA compliance plans, as the following excerpt covers in the Official Google Enterprise Blog:
- FISMA certification for Google Apps. In July, we announced our intent to secure certification for Google Apps to demonstrate compliance with the Federal Information Security Management Act (FISMA), the law defining security requirements that must be met by all US Federal government information systems. Our FISMA process is nearing completion. We will submit a Certification and Accreditation (C&A) package to the U.S. Government before the end of this year. Upon review and approval of the Google Apps C&A package, agencies will be able to deploy Google Apps knowing that it is authorized to operate under FISMA.
- Dedicated Google cloud for government customers in the US. Today, we're excited to announce our intent to create a government cloud, which we expect to become operational in 2010. Offering the same services and features as our existing commercial cloud (such as Google Apps), this dedicated environment within existing Google facilities in the US will serve the unique needs of US federal, state, and local governments. It is similar to a "Community Cloud" as defined by the National Institute for Science and Technology. The government cloud will allow Google to manage and meet additional government policy requirements beyond FISMA.
We couldn't find any such compliance statement from Salesforce.com, so we asked Dan Burton, Salesforce.com's Senior Vice President of Global Public Policy. While Mr. Burton would neither confirm nor deny the company's FISMA compliance road map, he pointed out that several US federal government agencies already use many Salesforce applications and that the sheer number of Salesforce solutions in Apps.gov is a testament to the overwhelming trust that the federal government has in Salesforce systems.
Who's Missing from the Party?
It shouldn't surprise anyone that both Salesforce and Google, two of the early leaders in cloud computing, are significant players at Apps.gov. But what is surprising is who is not on Apps.gov. Where's Oracle, Microsoft, IBM, VMWare, and many others? See this blog for some background on those that are missing from the party.And we'd be remiss if we didn't mention Amazon. Well, at least one can imagine where Amazon will fit into Apps.gov by visiting the Cloud IT Services section of the site. We guess it's coming soon.
Tuesday, September 8, 2009
Cloud Attraction Survey
I labeled this blog The Cloud Option because of my belief that the best reason to build an application with a cloud architecture is to manage application demand risk. The cloud option allows you to align application demand with infrastructure supply to protect against a demand forecast that is certain to be inaccurate. While I believe my value hypothesis will prove to be correct in the long term, I think there may be far more basic attractions associated with the near term value driving cloud demand.
With that in mind, I have built a short (12 question) survey that I offer to AWS users (as I believe AWS represents the most successful, high demand implementation of cloud computing by far thus far). If you are a current AWS consumer, please take 2 minutes to fill out the survey. I'll post the results on the blog in a week or two. Thanks for helping me assign value to the cloud option!
With that in mind, I have built a short (12 question) survey that I offer to AWS users (as I believe AWS represents the most successful, high demand implementation of cloud computing by far thus far). If you are a current AWS consumer, please take 2 minutes to fill out the survey. I'll post the results on the blog in a week or two. Thanks for helping me assign value to the cloud option!
Wednesday, September 2, 2009
Latest Gmail Outage Again Fuels Cloud Computing Luddites
By Steve Bobrowski
What's a Luddite? I remember looking this up once, and here's one of the definitions I found at Webster's:
Change scares people, making them feel uncomfortable and uneasy for many reasons. But in the world of technology, we must embrace change, for it is inevitable and fast-paced. And IT change usually happens for the better, not the worst.
In this context, my news wires on cloud computing today have been flooded with countless stories written by a bunch of, well, Luddites. Those insisting that the latest Gmail outage is proof that cloud computing system outages threaten the cloud computing paradigm shift. Really?
The truth is that system outages are a fact of life. We all hear about the public system outages, but we rarely hear about those that occur behind the firewall. Rather than trouncing cloud services when they go down, shouldn't the focus be on how long it took them to return to service and then comparing the impact of this event to similar on-premise outages?
For example, when was the last time that your organization's email system went down? Did your IT department have the training, staff, and resources to quickly identify the problem and then fix it? My personal recollection of an internal email system outage: lots of squabbles and finger-pointing among the parties involved, all leading to two days without email and some lost messages. Never mind the ripple effects of lost time and money while our IT staff needed to suspend work on other internal projects.
Google's team of highly-specialized administrators took less then two hours to fix things and I didn't lose any of my mail! In my experience, that's outstanding service. Furthermore, fixing the outage did not require work from any of my company's in-house resources, which were free to continue being productive on internal projects that lead to revenue generation.
Should your organization worry about relying on a cloud application or cloud platform? The answer is simple—applications should reside where it makes the most sense. In some cases, cloud wins, in others, data center wins. But the trend is undeniable that more and more enterprises are outsourcing common business applications such as email and CRM to the cloud because it provides their workers with a better service and more time to work on core business functions.
In summary, don't let the Luddites scare you—the inevitable world of utility-based computing will improve the enterprise's standard of living in many cases, not the opposite, as they would have you believe.
What's a Luddite? I remember looking this up once, and here's one of the definitions I found at Webster's:
Change scares people, making them feel uncomfortable and uneasy for many reasons. But in the world of technology, we must embrace change, for it is inevitable and fast-paced. And IT change usually happens for the better, not the worst.
In this context, my news wires on cloud computing today have been flooded with countless stories written by a bunch of, well, Luddites. Those insisting that the latest Gmail outage is proof that cloud computing system outages threaten the cloud computing paradigm shift. Really?
The truth is that system outages are a fact of life. We all hear about the public system outages, but we rarely hear about those that occur behind the firewall. Rather than trouncing cloud services when they go down, shouldn't the focus be on how long it took them to return to service and then comparing the impact of this event to similar on-premise outages?
For example, when was the last time that your organization's email system went down? Did your IT department have the training, staff, and resources to quickly identify the problem and then fix it? My personal recollection of an internal email system outage: lots of squabbles and finger-pointing among the parties involved, all leading to two days without email and some lost messages. Never mind the ripple effects of lost time and money while our IT staff needed to suspend work on other internal projects.
Google's team of highly-specialized administrators took less then two hours to fix things and I didn't lose any of my mail! In my experience, that's outstanding service. Furthermore, fixing the outage did not require work from any of my company's in-house resources, which were free to continue being productive on internal projects that lead to revenue generation.
Should your organization worry about relying on a cloud application or cloud platform? The answer is simple—applications should reside where it makes the most sense. In some cases, cloud wins, in others, data center wins. But the trend is undeniable that more and more enterprises are outsourcing common business applications such as email and CRM to the cloud because it provides their workers with a better service and more time to work on core business functions.
In summary, don't let the Luddites scare you—the inevitable world of utility-based computing will improve the enterprise's standard of living in many cases, not the opposite, as they would have you believe.
Tuesday, September 1, 2009
Enterprise Demand Driving Vendor Consideration of Internal Clouds
by Steve Bobrowski
So, perhaps the universal business law "the customer is always right" appears to be forcing an evolution of the original PaaS enterprise strategy: on-premise licensing of PaaS technology. Said another way: get your feet wet in your own data center, gain some confidence in PaaS, then scale out or completely outsource your application workload to the cloud. Let's consider some examples of this new micro-trend.
Longjump now licenses their Business Application Platform to essentially run anywhere. This approach provides an option for both the enterprises that handle sensitive, compliance-heavy data (such as the financial services, healthcare, and public sector space) as well as provide ISVs a platform where they can introduce new white labeled SaaS offerings.
"We are not exclusively a cloud vendor and PaaS on-demand is just one vehicle for our customers to derive value from the LongJump platform," LongJump CEO Pankaj Malviya told us. "In fact, our customers take a movable application approach so they can develop on one instance (our PaaS, for example), test on another (a LongJump instance on Amazon EC2), and publish on yet another (LongJump in a private hosting environment). Our real value is helping to streamline application development and delivery and being agnostic to the application infrastructure. With more private cloud options entering the market, there is also less risk for businesses because they still don't have to outlay any hardware to develop and test their applications."
Similarly, Apprenda licenses their SaaSGrid Application Server. Apprenda's CEO Sinclair Schuller told us "We started offering an on-premises version of SaaSGrid for one reason: many customers want the value proposition of a SaaS Application Server. This includes the time-to-market benefits, the multi-tenancy, the trivialized development. However, a large portion of those customers don’t want the cloud delivery model. They want to offer SaaS, but see SaaS on PaaS as impractical with respect to their specific needs. Once a PaaS vendor comes to grips with the fact that the value proposition and the delivery are two different things, it’s only natural to offer the technology across delivery mediums."
We also asked Schuller if SaaSGrid would allow an application to elastically scale-out/in from an on-premise data center to SaaSGrid being hosted in other data centers during times of varying demand. Although there is no commitment to this feature, Schuller did reveal to us "We’ve tested a very early version of this, and we know it works. We plan on moving from a high-level test to introducing cross-network grids in the future."
One can also see the same trend now taking shape in the Infrastructure as a Service (IaaS) space as well. Coincidentally, while I was waiting for correspondence to return from the PaaS vendors above, Amazon.com announced Amazon Virtual Private Cloud (VPC). The idea is to allow any organization to establish a secure, private cloud within Amazon's cloud, a virtual private network (VPN) connection between their data center and their VPC, and then elastically scale using VPC resources as necessary during times of varying demand—see here for more details.
In summary, keep your eye on the emerging trend of new PaaS and IaaS technologies that are available for licensing within your own data center as you consider how you might transition applications from inside your data center to the cloud.
Platform as a Service (PaaS) is an exciting new option that has the potential to revolutionize software application development as we know it. PaaS allows application developers to simply build applications in the cloud, without ever having to worry about hardware acquisition and configuration, software installation, configuration, and maintenance, scalability, availability, backups, recovery, etc. You just sign up and start building, deploy with the push of a button, and pay for your usage as you go.
When Platform as a Service (PaaS) vendors first emerged, their elevator pitch usually went something like this.
Our platform and data center provides you, the builder of custom business applications, a more efficient way to build your applications because we do all the heavy lifting of infrastructure and platform management while you concentrate on building great applications.
In the long-term, I happen to agree with this vision that most PaaS vendors initially expressed in their marketing strategies—but in the short-term, I do not think that this will prove to be a successful business strategy for selling to the enterprise. Moving software development and applications (new or existing) entirely from an on-premise data center to the cloud requires a huge shift in culture and thinking that will not happen quickly. My gut feel appears to have played out so far. Although some enterprises dipped their toes into the waters of PaaS for building some custom applications, I haven't seen an overwhelming number of organizations that appear to have dived in head first yet.
So, perhaps the universal business law "the customer is always right" appears to be forcing an evolution of the original PaaS enterprise strategy: on-premise licensing of PaaS technology. Said another way: get your feet wet in your own data center, gain some confidence in PaaS, then scale out or completely outsource your application workload to the cloud. Let's consider some examples of this new micro-trend.
Longjump now licenses their Business Application Platform to essentially run anywhere. This approach provides an option for both the enterprises that handle sensitive, compliance-heavy data (such as the financial services, healthcare, and public sector space) as well as provide ISVs a platform where they can introduce new white labeled SaaS offerings.
"We are not exclusively a cloud vendor and PaaS on-demand is just one vehicle for our customers to derive value from the LongJump platform," LongJump CEO Pankaj Malviya told us. "In fact, our customers take a movable application approach so they can develop on one instance (our PaaS, for example), test on another (a LongJump instance on Amazon EC2), and publish on yet another (LongJump in a private hosting environment). Our real value is helping to streamline application development and delivery and being agnostic to the application infrastructure. With more private cloud options entering the market, there is also less risk for businesses because they still don't have to outlay any hardware to develop and test their applications."
Similarly, Apprenda licenses their SaaSGrid Application Server. Apprenda's CEO Sinclair Schuller told us "We started offering an on-premises version of SaaSGrid for one reason: many customers want the value proposition of a SaaS Application Server. This includes the time-to-market benefits, the multi-tenancy, the trivialized development. However, a large portion of those customers don’t want the cloud delivery model. They want to offer SaaS, but see SaaS on PaaS as impractical with respect to their specific needs. Once a PaaS vendor comes to grips with the fact that the value proposition and the delivery are two different things, it’s only natural to offer the technology across delivery mediums."
We also asked Schuller if SaaSGrid would allow an application to elastically scale-out/in from an on-premise data center to SaaSGrid being hosted in other data centers during times of varying demand. Although there is no commitment to this feature, Schuller did reveal to us "We’ve tested a very early version of this, and we know it works. We plan on moving from a high-level test to introducing cross-network grids in the future."
One can also see the same trend now taking shape in the Infrastructure as a Service (IaaS) space as well. Coincidentally, while I was waiting for correspondence to return from the PaaS vendors above, Amazon.com announced Amazon Virtual Private Cloud (VPC). The idea is to allow any organization to establish a secure, private cloud within Amazon's cloud, a virtual private network (VPN) connection between their data center and their VPC, and then elastically scale using VPC resources as necessary during times of varying demand—see here for more details.
In summary, keep your eye on the emerging trend of new PaaS and IaaS technologies that are available for licensing within your own data center as you consider how you might transition applications from inside your data center to the cloud.
Subscribe to:
Posts (Atom)
Posts
