Since the introduction of EC2 in 2005/2006, a lot has happened. New service providers such as Google App Engine (GAE) and Force.com have emerged. Existing hosting providers such as GoGrid & RackSpace have transformed to cloudify their service delivery model. And, existing platform vendors such as IBM and Microsoft have raced to implement or acquire solutions to respond to this fundamental shift.
Different types of vendors are competing for market positions. Some are new: Abiquo, Nimbula, Cloud.com (formerly VMOps)… And, some are mature: VMware, Novell/Attachmate, CA, BMC, DELL, … [The vendor landscape is big and complex, and includes other types of vendors including systems integrators…]
As we close 2010, I thought it would be interesting to look at some usage trends of the big names in the Cloud market.
The statistics come from Alexa. It uses its own methods for capturing HTTP traffic, and normalizing the data. As such, it is important to note that it does not include non-web app workload deployed on these cloud services. In addition, it is common for enterprises to use DNS aliasing (CNAME) to map to a custom URL. So, it is important to consider traffic to custom URLs would not be included in the following presentation.
The intent is to provide some ideas about usage and future trends, as these vendors battle it out for dominance and market share.
Please send me any comments or questions at babakh@yahoo.com.
Wish everyone a Happy New Year!
Showing posts with label Google. Show all posts
Showing posts with label Google. Show all posts
Wednesday, December 29, 2010
Tuesday, November 16, 2010
More on VMforce - Part Deux
I blogged about VMforce a couple of times back in April. In August, VMware/SpringSource and SalesForce.com provided more details about this service in a couple of webinars to introduce Spring framework to Force.com developers, and Force.com & VMforce to Java developers:
VMForce–Cloud Computing for Java Developers
Basically, VMforce enables developers deploy JEE webapps on Force.com, and access Force.com database to persist data using standard JEE interfaces (JPA):
SpringSource offers the tooling (STS) to easily build and deploy Spring-based applications to VMforce. Force.com implements a JPA adapter to provide secure, multi-tenant access to Force.com database.
On the development/tooling side, it doesn’t seem the Force.com Eclipse Plug-in can be installed on STS (yet). Once they work this out, both sets of developers can install one Eclipse to implement either JEE/Spring apps or Apex.
I think the significance of VMforce is beyond merely extending Force.com with Java EE support or providing extensibility for Apex applications. VMforce is significant, because it will support the most common approach to Cloud migration by customers. Customers need a reliable service from a reputable, enterprise-ready service provider to move their existing applications to the cloud as is without much re-factoring. This is going to be the trend for the next few years. VMforce is a key strategy to meet that need.
And, of course with Spring framework programming model (abstraction, dependency injection), there is a good story for platform lock-in and change management.
What is not completely clear so far is how VMforce will meet monitoring and on-premise integration requirements for customers.
----
Side note:
As I am writing this, I can understand how Google and SalesForce have partnered with SpringSource today to enable implementation of Cloud apps using the framework (i.e. skills). However, this framework is based on “legacy Java EE” development and deployment. Java EE, as it exists today, does not cover Cloud distributed programming model and patterns, and I don’t know if it could be easily extended to support them. The problem here is that customers may have to invest in migration in the future.
However, there is no practical alternative available today. Until there is standardization around Cloud development, deployment, and interoperability, Spring-based development seems to be a logical approach.
----
Thoughts/Comments?
Saturday, July 31, 2010
Are you considering your application migration options carefully when moving to the Cloud?
So, you’ve heard about the Cloud. You’ve done some prototyping on AWS, Rackspace, GoGrid, Joyent, GAE, Force.com, Engine Yard,…
You show it to your boss. Bada Bing Bada Boom!
This is very timely, because the boss has just come out of a meeting with IT finance. He’s got a big problem justifying the cost of running the company’s website for $2M / year. He’s also pounded daily by business, because he has been unable to meet the availability and performance SLAs despite spending a lot on the infrastructure... So, you’ve just given him a brilliant idea. He checks with Legal, and asks you to look into moving the website to the Cloud.
As an experienced architect, you lift up the hood to take a good look inside the WebApp. You familiarize yourself with the code, dependencies, packaging, etc… After your analysis, you break down the options as follows:
In option1, you settle on an infrastructure as a service (IaaS) provider, and just move the application as-is over. Unfortunately, the issues that had already existed with the application will be all propagated (i.e. poor image loading / bundling, deprecated code, unsupported utility jars, packaging). However, in option1, you’ll be able to reduce the infrastructure and operations costs dramatically, and improve SLAs (i.e. availability, auto-scaling) quickly without a lot of efforts.
In option2, you’d still subscribe to an IaaS. You will have the opportunity to clean up the application a little. You might even re-factor the application to use Cloud services (i.e. persistence layer). If time permits, you might even make some changes in the infrastructure in term of content caching & media delivery (i.e. CDN). With this approach, you will have an opportunity to make quick, incremental improvements to the existing application without spending too much money.
In option3, you might consider an IaaS or a PaaS. In this context, the selection is primarily dependent on the application requirements, control over the infrastructure, execution environment customization, etc
With option3, the approach may range from just rewriting the application using its existing design to complete re-implementation. In the case of just rewrite, it can be very straight forward and relatively quick (using the right frameworks, reusing existing components and graphics, etc). The disadvantage is that you’re constraint by the original design, and will not be able to introduce any enhancements or new capabilities.
With redesign/rewrite approach, you’ll need more time to design the solution, but you’ll be able to introduce new capabilities.
So, here is a diagram to summarize:
The Time axis is self-explanatory. It reflects effort and costs. The Value axis is an indicator of business value. That ranges from cost-effective & enhanced IT service delivery to offering new business capabilities and possibilities.
I am leaving some details out, but you get the idea. Let me know what you think. Tell me about your experience.
You show it to your boss. Bada Bing Bada Boom!
This is very timely, because the boss has just come out of a meeting with IT finance. He’s got a big problem justifying the cost of running the company’s website for $2M / year. He’s also pounded daily by business, because he has been unable to meet the availability and performance SLAs despite spending a lot on the infrastructure... So, you’ve just given him a brilliant idea. He checks with Legal, and asks you to look into moving the website to the Cloud.
As an experienced architect, you lift up the hood to take a good look inside the WebApp. You familiarize yourself with the code, dependencies, packaging, etc… After your analysis, you break down the options as follows:
Options | Pros | Cons |
| Option 1: Move the application as is | Quick | Inherits the issues that already exist with the application The performance of the application may just marginally improve due to the application architecture & implementation |
| Option 2: Re-factor the application; then move | Potentially fixes some of the application issues Potentially fixes some of the application infrastructure issues | Takes more effort than option 1, and requires more time May introduce some dependencies on the target Cloud Will probably require learning a few new things |
| Option 3: Rewrite à Redesign/rewrite the application | Full application refresh: New application & infrastructure architecture & design, and implementation Removes the implementation constraints that existed in previous options thereby allowing to leverage/offer new capabilities (i.e. social computing) | May be more involved than the previous options (time, cost) |
In option1, you settle on an infrastructure as a service (IaaS) provider, and just move the application as-is over. Unfortunately, the issues that had already existed with the application will be all propagated (i.e. poor image loading / bundling, deprecated code, unsupported utility jars, packaging). However, in option1, you’ll be able to reduce the infrastructure and operations costs dramatically, and improve SLAs (i.e. availability, auto-scaling) quickly without a lot of efforts.
In option2, you’d still subscribe to an IaaS. You will have the opportunity to clean up the application a little. You might even re-factor the application to use Cloud services (i.e. persistence layer). If time permits, you might even make some changes in the infrastructure in term of content caching & media delivery (i.e. CDN). With this approach, you will have an opportunity to make quick, incremental improvements to the existing application without spending too much money.
In option3, you might consider an IaaS or a PaaS. In this context, the selection is primarily dependent on the application requirements, control over the infrastructure, execution environment customization, etc
With option3, the approach may range from just rewriting the application using its existing design to complete re-implementation. In the case of just rewrite, it can be very straight forward and relatively quick (using the right frameworks, reusing existing components and graphics, etc). The disadvantage is that you’re constraint by the original design, and will not be able to introduce any enhancements or new capabilities.
With redesign/rewrite approach, you’ll need more time to design the solution, but you’ll be able to introduce new capabilities.
So, here is a diagram to summarize:
The Time axis is self-explanatory. It reflects effort and costs. The Value axis is an indicator of business value. That ranges from cost-effective & enhanced IT service delivery to offering new business capabilities and possibilities.
I am leaving some details out, but you get the idea. Let me know what you think. Tell me about your experience.
Saturday, January 09, 2010
What apps are likely to move to the Cloud…
Earlier this week, IDC published an interesting survey on what applications are likely to move to the Cloud. I thought about blogging about this, because they made some good points & observations in their analysis, and it also follows my previous post on application and workload analysis for Cloud Computing nicely.
I am not going to repeat what’s said in their survey, but wanted to add a couple of points before moving any application to the Cloud:
Finally, in the overblown world of Cloud Computing where “Cloud” is myopically restricted to only a few forms such as AWS, GAE, Force.com, etc, it should be noted that many companies have already been using Internet-based services routinely for more than a decade. These services have been used to fulfill simple functional requirements such as address normalization or tax calculation to more complex business processes (i.e. risk analysis) or business process outsourcing (i.e. order fulfillment) where enterprise data is typically hosted on an external service provider or tightly integrated with the service provider. So, in addition to the list of application types that IDC has presented in their survey, hosted solutions and/or BPOs represents another class of candidate applications for “Cloud Computing”.
I am not going to repeat what’s said in their survey, but wanted to add a couple of points before moving any application to the Cloud:
- Cost: What is the current annual cost of maintaining and running the existing application? For most enterprises, cost reduction is the key driver for Cloud, so establishing the cost should probably be one of the first activities in any migration. [N.B. If the Cloud is considered for new applications, a similar cost analysis should be performed to estimate the initial cost of building the application + estimating the annual ongoing maintenance and operation. It would be best to breakdown the costs in terms of infrastructure, operation, and solution development & maintenance.]
- Cloud Selection: Different Clouds offer different capabilities and different charge-back models. As an example, with Google App Engine, you can upload your web app to Google’s infrastructure. You’re not charged unless the application serves requests. Now, contrast that with EC2. Obviously, you must launch your AMI to start your application, so you’re billed for CPU usage even if the application is sitting idle. Please note that I am not suggesting GAE is better than AWS. They are different platforms for running different types of applications, and offer different capabilities. So, Cloud selection is a very important consideration not only with regards to costs, but also in terms of building, delivery, and management of the target solution.
Finally, in the overblown world of Cloud Computing where “Cloud” is myopically restricted to only a few forms such as AWS, GAE, Force.com, etc, it should be noted that many companies have already been using Internet-based services routinely for more than a decade. These services have been used to fulfill simple functional requirements such as address normalization or tax calculation to more complex business processes (i.e. risk analysis) or business process outsourcing (i.e. order fulfillment) where enterprise data is typically hosted on an external service provider or tightly integrated with the service provider. So, in addition to the list of application types that IDC has presented in their survey, hosted solutions and/or BPOs represents another class of candidate applications for “Cloud Computing”.
Subscribe to:
Posts (Atom)