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?

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:

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.

Workload Analysis in Cloud Computing

Not all workloads are the same, and not all Clouds are the same!

Different applications have different set of requirements and characteristics.  Some Clouds (i.e. GAE or Heroku) are natural fits for certain class of workloads (i.e. WebApps) whereas for other types of workloads (i.e. batch), other Cloud services (i.e. AWS) are more appropriate.  In some cases, the business operation and/or legal requirements may require a completely different deployment (i.e. private Cloud). In a previous post, I referred to workload analysis in the context of approach to Cloud adoption. In this post, I thought to share some ideas about it.

The aim of Workload Analysis in Cloud Computing is to look at different aspects or characteristics of an enterprise application to determine the feasibility of moving or porting the application to the Cloud.  This analysis also provides input to implementation approach, Cloud service selection, and an initial business value assessment (i.e. cost reduction, IT simplification)…

The following proposes some guidelines in workload classification & characterization:

Workload Category: At a high-level, there are two kinds of applications in the enterprise:

1. Custom Applications – This class of applications are developed and maintained by the enterprise.  The enterprise has control over its design, technology selection, implementation,  infrastructure requirements, maintenance, and overall portfolio roadmap. 
2. Packaged Apps – For this class of application, the respective vendor is in control of its implementation, packaging, release, supported configurations, product plans, etc.

In the case of Custom Apps, If an enterprise is considering to deploy an application to the Cloud to achieve cost reduction or simplifying IT by delegating the infrastructure operation/maintenance to an IaaS, there is flexibility from simply taking the application pretty much as is to the Cloud –> re-factoring the application to leverage Cloud services (i.e. RDS).  In the former, the potential is substantial savings in infrastructure cost and business value in terms of new hardware & software purchase avoidance –> potential for much better SLAs and a lot more cost savings by reducing or totally eliminating the burden of additional FTEs (i.e. Database Administrators).

For Packaged Apps, the enterprise may or may not be able to move the solution to the Cloud due to licensing restrictions, technical infrastructure requirements, complex integration issues with other back-ends, etc… [it is good to check the packaged vendor for any existing or future plans for SaaS offering…]

Next, there are a set of general characteristics or attributes to consider when analyzing the applications:

• Workload Type: In general, there are two types of workloads: Batch or Online.  It is important to consider this differentiation for the following reasons:
• There are different resource requirements and considerations. As an example, batch workloads may require specific capacity in terms of storage and compute resources (i.e. vCPU, memory) to finish the job in a timely fashion whereas for online workloads network bandwidth may be more critical…
• There are differences in programming models.  As an example, some batch jobs may be implemented over a framework like Hadoop whereas for some online workloads a PaaS like Force.com may be the best choice. 
• Workload Frequency:  Sometimes, a workload may run at month-end or every quarter.  I like to note this attribute in the analysis for investment cost / benefit analysis.
• Workload Cost: It is important to capture the total cost of workload including hardware, software, application maintenance and support, etc.  I think it would be even more useful to develop a cost allocation model reflecting percentages in infrastructure, software, application development, support and maintenance, etc…  This information is useful in Cloud service selection.
• etc…

So, in summary, it is good practice to develop a consistent approach/process for analyzing workloads in Cloud Computing adoption.  This analysis has a range of use from business case justification to Cloud service selection. 

Also, as described in previous post, there are several sources of information to aid in workload analysis (i.e. Project Portfolio Repository, any existing server/application consolidation or decommissioning analyses, issues log or problem management database, etc). 

Finally, I highly recommend an excellent presentation that David Chou posted on his blog on patterns of moving to the Cloud…