From MVM to Multi-Tenant JVM

Last month, at the JVM Language Summit, Ryan Sciampacone from IBM shared his experience with extending IBM J9 JVM to host multiple applications.  You can view his talk on Oracle Media Network. You can also download a copy of his presentation here. Ryan goes into fairly good details about the challenges and lessons learned, so I recommend taking a look at it.
Across the world in Ireland, Waratek recently announced availability of Waratek Cloud VM for Java.   This JVM extends OpenJDK (HotSpot VM) with a virtualization layer that isolates applications in Java Virtual Containers.  In addition to application isolation, Waratek’s solution offers a container management interface based on Virsh, and resource monitoring… I think this is a very cool solution that could potentially shape ideas to JVM multi-tenancy implementation.  You can watch a presentation on their solution here, and find more information on their solution here. 
-----
Background: The current model of one JVM per application is inefficient.  It leads to JVM sprawls and inefficient usage of infrastructure resources.
The JVM specification defines the JVM as an abstract computing machine. It describes the Class file format,  machine instruction set, rules/constraints on class loading, etc., but contains no requirements or models for the implementation of the JVM’s internal processes, task management or resource management for secure sharing of the JVM by multiple applications. 
Over the last decade, before multi-tenancy had become such a popular (and overused) term, there have been a number of related efforts to address the issues:

• JSR 121: Application Isolation API  – Proposes a language construct called “Isolate” as the means to instantiate isolated Java applications on the JVM.  The spec also addresses isolate-to-isolate communication. 
• JSR 284: Resource Consumption Management (RCM) API – Since there will be different applications sharing a JVM, there needs to be a way to make sure a rogue app does not impact the performance of another app.   JSR 284 proposes a standard API to bind RCM policies to applications running on the JVM.  This JSR is quite interesting, as it has provisions for resource reservation as well setting constraints / quota for resource consumption.

Sun had a couple of reference implementations (MVM, MVM2).  For a complete list of related papers, visit Project Barcelona.) 
SAP also did its own implementation of application isolation scheme by implementing a pool of VMs and a dispatcher to schedule work in the VMs (see Process Attachable Virtual Machines,  Virtual Machine Container).
-----
Java multi-tenancy
There are two usecases for JVM multi-tenancy:

N.B. In the diagram above, I specify App, but App Server should be implied as well.
In option B, you have multiple applications using the JVM.  This is pretty straight forward.  In option A, you have a situation where multiple customers or business units (i.e. shared services) need to share the application securely.
In the case of option A, let’s assume an application has been implemented as a multi-tenant solution using JEE framework.  The App Server interfaces with the underlying JVM to provision new tenants (new isolates).  As part of the tenant provisioning, the App Server uses the RCM interface to set tenant policies.  The JVM monitors the RCM policies, and takes appropriate action.  As application requests hit the App Server, the App Server uses some tenant context scheme to determine which isolate it should go to….As the request flows through the different tiers of the JEE solution, the App Server makes sure only the tenant only accesses the JEE resources that it is authorized to use.  In case of an isolate loop or application runtime environment crash, the JVM applies RCM policies to handle the situation…
In the example above, we can see that there are requirements for the JEE framework as well as JVM runtime to support multi-tenancy.  And, we also should not forget that there re other languages running on the JVM.  Additional requirements may need to be considered.
-----
So, where are we now?
The JCP will standardize multi-tenancy in the Java Platform, but this will probably not happen in JDK8 given the current schedule and the focus for JDK8 (productivity, modularity, performance).
There should be more information available by Jan 2013. 
-----
Final thoughts
With JDK8, there will be a new Java module system (Jigsaw) replacing the old JAR format and class loading from Classpath…  The new format will contain metadata about the packages, classes, and dependencies using a new set of annotations (i.e. version, imports, exports, …), and reflection APIs to improve class loading and sharing, performance,… For some background, have a look at JSR 294 and JSR 277.   This will play an important supporting role in implementing multi-tenancy support in the JVM efficiently.
Clearly, JVM multi-programming / multi-tenancy capabilities will bring economic benefits to both enterprise customers and vendors. It think it might also trigger a new wave of JVM innovations like Waratek.

Enterprise Architects should consider multi-tenancy design patterns & best practices to deliver better shared solutions

Recently, I came across a few good research papers on Cloud and Multi-tenancy design patterns. Typically, the primary audience for such articles is architects and technologists working for service providers (IaaS, PaaS, SaaS, BPaaS…) or software vendors. However, enterprise architects can also apply these architectural principles and patterns to build more cost-effective and easier-to-maintain shared solutions.

In this post, I won’t bore you with an introduction of different Cloud services and taxonomy. I assume you’ve heard it all already. If not, have a look here or just google “Cloud Computing”. My intention is to explain multi-tenancy and key characteristics, review some of the patterns and organize them in logical groups, and provide some references for further examination.

Background
For the last decade, large multi-national enterprises have progressively consolidated IT organizations / functions into Global Shared Services. This is a common strategy to reduce costs by eliminating redundancies, improve operational efficiencies by reducing technology stacks, vendors, and required skills through portfolio rationalization and standardization.

In such organizations, Enterprise Architects are routinely involved in building cost-effective shared solutions. These solutions are used by different business units around the globe requiring BU-specific look & feel, application behavior, and compliance with local customs & regulations.

In the enterprise, a common approach to building shared solutions involves deploying multiple instances of an application or package to accommodate BU-specific functional customizations and non-functional requirements (i.e. load, performance, security…) on a shared infrastructure.

Instances are typically separated in different logical partitions or virtual machines, have their own dedicated resources (application server, middleware, database…), and are configured to meet BU-specific requirements.

Over time, what started out as a common code-base application supporting all BUs diverges into multiple code branches, sometimes so different, that they essentially become different applications. In this case, while infrastructure costs are contained, operational and maintenance complexities and costs grow.

There is a better approach. If applications are designed based on multi-tenancy, the level of “sharedness“ moves higher in the stack. The higher it moves, the better efficiency and asset utilization is gained.

It should be noted that this is appropriate for those organizations that operate at a higher level of IT maturity, as change and release management, and availability and scalability, get more complex.


What is a multi-tenant application?
A multi-tenant application is a shared solution (i.e. CRM) used by different tenants (organizations, BUs). It is a single application with scalable resources to meet the performance demands of tenants.

As each tenant has its own specific functional requirements, the single multi-tenant application can support tenant specific customization at different layers of the architecture (persistence, workflow, component integration, security, UI).

Since multi-tenant applications run on shared infrastructure, it is important to isolate tenants from each other to protect information security, and prevent rogue actions or failure in one tenant’s execution environment does not impact other tenants’ availability.

Finally, since we’re talking about a single code-base running in shared environment, maintenance and updates must be continuously performed without requiring any downtime.

[Note: These are the key concepts behind multi-tenant applications. I am not going to include things like subscription-based licensing or utilization-based billing. Those are in the realm of Software-as-a-Service offering and operation.]

So, the main idea behind multi-tenancy is to provide a single code-base, polymorphic application that is customizable and scalable to meet the demands of different tenants:

In the diagram above, on the left (A) we have a single code-base, single instance, and single DB application supporting different tenants. On the right (B), we have a single code-base and single DB, but multiple instances supporting different tenants. This is not the same as an enterprise deploying multiple instances in their shared solution implementation.

In this case, the reason for “multiple instances” is related to the underlying infrastructure hosting the multi-tenant application. It is related to how its request handling, provisioning, and scalability strategies have been implemented.

In A, there is probably a cluster or grid of compute nodes powering the application. In B, as new application requests arrive, the underlying infrastructure provisions an execution environment (i.e. servlet container) and dispatches the request to the container to run the requests.

Here are some references which you might find useful:
· http://www.computer.org/portal/web/csdl/doi/10.1109/CEC-EEE.2007.4
· https://www6.software.ibm.com/developerworks/offers/techbriefings/cc4d-replays/session2_dcarew.pdf
· http://www.ibm.com/developerworks/webservices/library/ws-multitenantpart2/index.html

Multi-Tenancy Design Patterns & Realization
In this section, I am going to describe some of the key multi-tenancy design patterns and organize them into logical order:

Requirement	Description	Patterns, Approach, and Techniques
Tenant Isolation (Infrastructure)	Tenant isolation is quite broad and multi-dimensional. It is primarily motivated by security and tenant availability and performance.	At the infrastructure layer, tenant execution environment may be separated by virtual machines Higher up, in the application server layer, each tenants may get their own server (Take a look at this WSO2 paper) In the future, OSGi bundles? (See OSGi4C – RFP 133) SOA provides a natural choice for multi-tenant and cloud applications (i.e. reusable components, composite apps). Take a look at this paper by Frank Leymann, et al on combining different multi-tenancy patterns in Service-Oriented applications.
Tenant Isolation (Data)	In a multi-tenant environment, a single database contains data from multiple customers. Tenants should only be able to see their own data.	SQL operations are qualified using tenant_id to return only tenant-specific data. For added security & audit, another field such as user may be required to for authorization and logging. References: http://msdn.microsoft.com/en-us/library/aa479086.aspx
Customization	As previously discussed, the single code-base multi-tenant application must provide some degree of customization and use extension to facilitate adoption. The customizable configuration items range from UI to workflow to database schema. For different layers, different techniques are applied to make the changes. Here is a good reference on approach / methodology including assessing customization needs for a multi-tenant application.	Most SaaS solutions offer a metadata repository and a configuration service. A self-service UI panel is provided to the administrator on the tenant side to make the configuration changes. Wizards are also provided to constrain / guide configuration changes. For most configuration items, change is automatic. On the fly code generation techniques (i.e. templates), and dependency injection are also used to create tenant-specific code at runtime.
Maintenance & Upgrade	Applying patches or system upgrades for a single instance multi-tenant solution running on a shared platform gets quite complex. In the enterprise, change management and release strategies must factor in availability SLAs.	The same principles and best practices as continuous integration and delivery apply here Force.com development lifecycle offers good best practices for release testing and promotion which can also be applied to a multi-tenant solution in the enterprise. Obviously, it is important to be able to roll back to a previous stable point if things go wrong, so here are some general tips: · An on-demand provisioning infrastructure provides an important capability for multi-tenant operation and management. Now, for an enterprise it doesn’t have to get as sophisticated as Amazon or Google, but try to understand the gaps, build a business case, and take appropriate steps. · Similarly, investment in a CMDB solution also plays an important role in developing capabilities to manage change requests effectively and reduce deployment errors and others… · Template-based configuration and deployment…This is an important configuration and change management best practice. · Regular incremental backups (i.e. system snapshots) are also important to enable recovery in the event of rollbacks….

The above have direct linkage to the solutions that are built in enterprise shared services. BUs must be isolated for both technical operational and regulatory reasons. Enterprise architects must find ways to design solutions that share more and cost less in ongoing operation and maintenance. And, the systems typically have high availability requirements.

What’s also important to note is that the there is often no reference model for building shared solutions. This is a big gap. Multi-tenancy patterns and principles can be a big help.

Final thoughts
This is quite a fluid area. Multi-tenancy is still relatively a new concept. The ideas There are a lot of open questions from design -> operation. Enterprise Architects should have this on their radar, as they engage with new projects – or – refactor old implementations.

What do you think?

Google excludes scheduled maintenance from its Google Apps SLA, but not Google App Engine

Back in July of 2010, I wrote about how Cloud Service Providers exclude scheduled downtime from their service level agreements.  Last Friday, Google made a significant change to their SLA for Google Apps by removing scheduled downtime from their Google Apps SLA:

• Exclusion of scheduled downtime from availability SLA
• Exclusion of intermittent downtime (periods of less than 10 minutes) from availably SLA

Obviously, it is good news for Google Apps customers.  It highlights Google’s infrastructure & operational maturity (in this case, for Google Apps specifically).  

I also think the announcement is important, because it sets a higher standard for service delivery.  By raising the bar, Google also intensifies competitive pressure on service providers such as Microsoft to offer more robust Cloud services.  Ultimately, both customers & the industry should benefit from this.

However, as I discussed in my July post, for infrastructure & platform services such as Google App Engine for Business, scheduled maintenance still remains excluded in all SLAs:

• GAE: http://code.google.com/appengine/business/sla.html
• AWS: http://aws.amazon.com/agreement/
• Azure: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=72193dd2-eeaa-4054-93f6-f6b725cf76af&displaylang=en#QuickDetails
• RackSpace: http://www.rackspacecloud.com/legal/sla/
• GoGrid: http://www.gogrid.com/legal/sla.php
• …

It is 2011.  If we mark the beginning of Cloud Computing by the initial public release of EC2 (2006), I think enough time has passed for Cloud service providers to do a better job of managing planned outages in a non-service-disruptive way. 

--------
Sidebar - I am a regular user of AWS, GAE, Force.com… I have been using these services for more than a couple of years.  To be fair, I have never received any emails from any of the major cloud for scheduled downtime.  I have received a few from other service providers.  So, I would say that they are all doing a pretty good job operationally (a lot better than probably what most enterprises would do), and make sure the services are always up, and almost always perform well :-].  So, they just have it in the SLA agreements for legal protection & liability.   

Never-the-less, when it comes to migrating or designing enterprise solutions, depending on the application type and use-case, this can become an issue, and require both technical implementation & operations planning.

A quick & dirty look at web traffic trends on AWS, Azure, Force.com, GAE, and IBM Dev/Test cloud

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.

Comparing aws, azure, force, gae, and ibm

View more presentations from babak hosseinzadeh.

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!

A brief look at Oracle and its Cloud Strategy

For the last couple of years, Oracle has shown a consistent strategy to Cloud Computing.  It has made strategic acquisitions such as Virtual Iron to gain x86 virtualization management software, and has also made investments in new products such as Virtual Assembly Builder to facilitate configuration and governance of virtual environments.

Oracle has made clear that it intends to be a provider of technology to both enterprise customers and service providers.  That it does not plan to be a public cloud provider/operator like AWS or Savvis.  Instead, Oracle works with public cloud services as a distribution and delivery partner. 

[Note: See AWS/Oracle announcement of  support for Oracle middleware and apps on EC2 using Oracle VM images.]

---------

This post is a brief look at Oracle and its cloud strategy.  First, I will review Oracle business, financial, and what it brings to Cloud Computing.  Next, I will provide a 5-minute SWOT analysis of Oracle Cloud Strategy.

Oracle business

Oracle’s goal is to be the world’s most complete, open and integrated enterprise software and hardware company.  In FY2010, it booked more than $26B in revenue.  The company breaks down its revenue as follows:

• Software
• New software sales
• Software license renewals & support contract
• Hardware
• Hardware sales
• Hardware support & maintenance contract
• Services
• Consulting
• Education
• On Demand

Here is their revenue trend for the last 5 years:

• Oracle made over 32% of its 2010 total revenue ($26,821 million) from database & middleware renewal, and about 16% from Fusion apps renewal.  This is due to the fact that almost 90% of Oracle customers renew contracts.   [Renewal has a margin of 85%, and is the key factor to Oracle’s overall profitability.]
• Oracle’s On Demand, which is where it offers hosted Fusion application, has also contributed to about 3% of total revenue.  This segment has shown steady growth.  In fact, since 2005, it has grown almost 3 times.  [This is a key area to future growth for Oracle especially considering all the investments they have been making to standardize Fusion apps on Fusion middleware and continue to “SaaSify” the applications.]

Oracle Cloud Business Strategy

As stated earlier, Oracle intends to be primarily a Cloud technology provider/enabler as opposed to a service operator.  This was further evidenced as it halted the rollout plans for Project Caroline after the Sun acquisition.

For enterprise customers, Oracle is addressing the needs for private cloud by providing integrated machines such as Exadata and Exalogic.  These machines help customers consolidate workloads and scale up/down as demand grows.  Oracle also continues with new products and enhancement of its middleware and enterprise management solution to enable customers build private clouds on their own hardware.

I think Oracle will be forced to change their cloud strategy for the following reasons:

• According to analysts, about 10% of IT budget is spent on external cloud services and that percentage will keep growing (see Gartner’s survey).  Oracle needs to pay attention to this shift in enterprise IT spending, if it plans to increase marketshare and revenue.  Large customers struggle with supporting workloads in the cloud, so they look for a vendor to not only help them move workloads to the Cloud, but also provide support and management.  So, they look for hosted managed private clouds.  Oracle could address this need by leveraging Sun assets such as Caroline to offer such services.  This would position it well for future growth.   
• It is common knowledge that Oracle wants to reach $100B in revenue in the next 10 years.  Cloud Computing, including integrated systems, is a key growth strategy for Oracle.    Oracle needs to diversify to reach that level of revenue in the next decade.  It can’t rely on acquisitions to make that happen.  Let’s assume Oracle acquires CA.  That would only boost Oracle’s revenue by $4B.  

Sidebar: Let’s play the following scenario.  Let’s assume that on average with every Exalogic Oracle charges $1M for hardware and $3M for software. Furthermore, let’s assume a %20 maintenance revenue per box / year.  If Oracle sold 1000 units every year for the next 3 years, they would book a total of $12B in combined new hardware and software + $4B in maintenance.  Everything else constant, by 2014, Oracle’s revenue would grow by $16B to $42B.  Can they do that? 

Oracle Cloud Solution

The following diagram describes Oracle’s cloud solution model:

Oracle models its solutions based on different Cloud service offering.   The diagram is pretty self-explanatory.  At the IaaS level, Oracle Sun hardware,  and virtualization technologies (Virtual Iron + Sun).  Oracle offers other capabilities that are not listed in this diagram such as Virtual Desktop Infrastructure (VDI) and Oracle VM Virtual Box.

In the PaaS layer, Oracle uses a combination of virtualization to isolate workloads and management deployment + grid technologies to enable dynamic resources and scaling for applications.

At the top layer, Oracle and non-Oracle apps can be deployed on this platform.  Oracle Fusion apps are optimized for Oracle Fusion middleware. 

Finally, on the right hand side, there is the management layer…The slide is a cut and paste of Richard Sarwal’s presentation at Oracle OpenWorld.  In that presentation, Richard also mentioned that there other capabilities and solution that Oracle will be offering in the next year (i.e. self-service portal, metering & charge-back, etc)

Oracle Cloud SWOT

In terms of integrated systems, Oracle will face competition primarily from IBM CloudBurst and Acadia.  On the middleware side, IBM offers a similar set of offerings based on WebSphere and Tivoli (i.e. WebSphere CloudBurst, WebSphere Virtual Enterprise, Tivoli Cloud Management stack).   Oracle will face competition from VMware vFabric.   IBM has embraced VMware as a virtualization partner (on x86)whereas Oracle decided to acquire its own virtualization.  That has been a source of friction between the two vendors.

In terms of deployment and support, IBM offers more choices than Oracle:

• IBM & Oracle both offer enterprise-owned cloud
• IBM offers managed private cloud services (using customers assets), but Oracle does not.  A customer would have to get a managed services contract from an Oracle partner like Wipro.
• IBM offers IBM-hosted private cloud, but Oracle does not.  A customer would have to sign a contract with an Oracle Cloud provider like Savvis that offers both hosting and support services.
• IBM offers a public cloud where multiple tenants share the same infrastructure. This is useful for certain workloads (i.e. email, public website) and cloud scenarios (development and testing).  Oracle doesn’t offer that.  A customer would have to find a Pay-As-You-Go provider like AWS.

So, here is a quick SWOT of Oracle Cloud:

Let me know what you think? 

Do you think Oracle can reach $100B in the next 10 years through an acquisition only strategy?   What other challenges do you see in Oracle’s cloud strategy, and selling its middleware machine into the enterprise?

Cloud Services & Availability SLA – Should scheduled maintenance be excluded from the measurements?

Availability SLA is an important criterion to enterprise customers when selecting a Cloud service provider.  If the service provider doesn’t offer appropriate SLAs, they often don’t even make it to the “short list”. 

As an example, Amazon’s EC2 availability SLA is 99.95%. Amazon also offers transparency by providing a website that publishes up-to-the-minute status on their services and any related issues.  In the case of AWS, Amazon makes the following exclusions:

Amazon EC2 SLA Exclusions

The Service Commitment does not apply to any unavailability, suspension or termination of Amazon EC2, or any other Amazon EC2 performance issues:

• (i) that result from Service Suspensions described in Section 7.1 of the AWS Agreement;
• (ii) caused by factors outside of our reasonable control, including any force majeure event or Internet access or related problems beyond the demarcation point of Amazon EC2;
• (iii) that result from any actions or inactions of you or any third party;
• (iv) that result from your equipment, software or other technology and/or third party equipment, software or other technology (other than third party equipment within our direct control);
• (v) that result from failures of individual instances not attributable to Region Unavailability; or
• (vi) arising from our suspension and termination of your right to use Amazon EC2 in accordance with the AWS Agreement (collectively, the “Amazon EC2 SLA Exclusions”).

If availability is impacted by factors other than those explicitly listed in this agreement, we may issue a Service Credit considering such factors in our sole discretion.

Here is section 7.1 from AWS agreement:

• “…suspended for the duration of any unanticipated or unscheduled downtime or unavailability of any portion or all of the Services for any reason, including as a result of power outages, system failures or other interruptions…”
• we shall also be entitled, without any liability to you, to suspend access to any portion or all of the Services at any time, on a Service-wide basis:
  • (a) for scheduled downtime to permit us to conduct maintenance or make modifications to any Service;
  • (b) in the event of a denial of service attack or other attack on the Service or other event that we determine, in our sole discretion, may create a risk to the applicable Service, to you or to any of our other customers if the Service were not suspended; or
  • (c) in the event that we determine that any Service is prohibited by law or we otherwise determine that it is necessary or prudent to do so for legal or regulatory reasons (collectively, “Service Suspensions”).

…To the extent we are able, we will endeavor to provide you email notice of any Service Suspension in accordance with the notice provisions set forth in Section 15 below and to post updates on the AWS Websites regarding resumption of Services following any such suspension, but shall have no liability for the manner in which we may do so or if we fail to do so.

So, if there is any outage unintended or intended by Amazon, those numbers may not be included in their service availability measurements.  In fairness to Amazon, I haven’t experienced much outage or remember any notices for scheduled maintenance.   Never-the-less, if it occurs, it won’t be counted as an outage.

You can find EC2's SLA at http://aws.amazon.com/ec2-sla/.
--------------------------------
The other day, I received the following notification from GoGrid:

In this case, customers basically had no administration access to their running servers for 4 hours. 

GoGrid claims to offers 100% uptime in their SLA, but there are some exclusions as follows:

1. downtime during scheduled maintenance or Emergency Maintenance
2. outages caused by acts or omissions of Customer, including its applications, equipment, or facilities, or by any use or user of the Service authorized by Customer
3. outages caused by hackers, sabotage, viruses, worms, or other third party wrongful actions
4. DNS issues outside of GoGrid's control
5. outages resulting from Internet anomalies outside of GoGrid's control
6. outages resulting from fires, explosions, or force majeure
7. outages to the Customer Portal
8. failures during a "beta" period

According to item #1, scheduled maintenance is not included as part of their availability SLA.

Rackspace also claims to offer 100% availability in their SLA, but they also exclude scheduled maintenance from their availability measurement.

So, I appreciate the difference between scheduled maintenance and an unexpected outage.  However, from an availability perspective, I think scheduled maintenance should be included in the availability measurements and reporting.  Otherwise, it is misleading clients.

The Cloud service provider has options to manage for continuous availability.  That is under their control.  Regardless of scheduled vs. unscheduled service outage, the business impact may be no less even if the subscriber is aware of an outage in advance.

What is your experience with Cloud service providers?   Do they explain the SLAs clearly?  Do you think scheduled maintenance should be included or excluded?

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.

A review and analysis of IBM Test & Development Cloud, and opportunities

IBM finally GA'd its Development & Test Cloud last week: http://www.ibm.com/cloud/enterprise
In addition to a public cloud service offering, IBM is also providing an option to deploy such an infrastructure-as-a-service model on-premise (private cloud): http://www-935.ibm.com/services/us/index.wss/offering/midware/a1030965

I believe Cloud Computing is critical to IBM’s future growth.  It may even be the only solution to declining revenues in some of IBM’s business segments.    I will share some opinions below after a quick solution review.

The IBM cloud is built on Rational & Tivoli components.  Rational provides design, development, testing, and application lifecycle management & governance, and Tivoli enables automated resource provisioning & service management (self-service request management, performance monitoring, usage metering, billing):

IBM Test & Development Cloud

I think there is an opportunity for IBM’s Cloud to be a huge success for the following reasons:

Virtualization
For IBM public cloud, KVM powers the virtualization layer.  The on-premise solution is virtualization technology agnostic: KVM, PowerVM, and VMWare.

• In a previous post, I made the observation that most large enterprises cannot standardize on a single virtualization infrastructure.  They have to deal with multiple virtualization technologies.   While there seems to be some gaps in IBM’s on-premise solution (ex. no Xen or Hyper-V support), I think IBM is in a much better position than VMWare or Oracle to unify management across different virtualization technologies.   This would be a a big competitive differentiator and value to the enterprise.
• Secondly, in the world of Cloud Computing, vendors are primarily focused on x-86 platform.  All other platforms are ignored.  If IBM can extend their public cloud to support pSeries and maybe even zSeries (mainframe-as-a-service ?), this would also be a huge competitive differentiator.  This would allow more workloads to be moved to the Cloud and benefit customers.  As an example, customers would be able to move some of their mainframe batch jobs to the Cloud to save MIPS.

OS Coverage
The initial set of OS images are limited. In the initial public offering, IBM only offers Red Hat & Novell images.  There are no Windows images (yet ?).  I think it is just a matter of time for IBM to offer Windows images on their public cloud.

As I said above, the on-premise solution can support AIX images now, and maybe zOS in the near future (why not?).  If IBM were to offer AIX & zOS VMs in the Cloud, it would not only be able to realize a new revenue stream and possibly revive that segment, but keep customers from migrating to other platforms.  I think this could open new opportunities.  The challenge is how to do this in a balanced way without cannibalizing the existing customer base, and creating incentives for IBM sales teams to execute after those opportunities.

Pricing
IBM’s cloud “infrastructure pricing” is competitive to AWS.  However, for IBM software, there are different licensing & subscription options:

Customer scenarios	Software	Infrastructure
	Charge	Charge
You "bring your own IBM license" ("BYOL")	Prepaid for software license	Per VM per hour
You own an IBM software license and can use the pre-built IBM images in the portal catalog
You "pay-as-you-go" ("PAYG")	Per Image per hour	Per VM per hour
You choose the desired software, accept the license terms online, and receive a monthly usage bill
You "bring your own software and licenses"	Prepaid for software licenses	Per VM per hour
You bring your own software or software for which you hold valid licenses and install them on the servers you provision
You want to test "pre-release" software	No charge for restricted use	Per VM per hr
From time to time, pre-released software images will be made available on a temporary basis for test (non-productive) use
You are an eligible ISV/SI developer	No charge or by usage	Per VM per hr
You can use selected IBM "development use only" ("DUO") software for development, test, proof of concept and sales demos on the IBM Cloud
Options available vary by software package.

IBM hasn’t published detailed pricing on their software subscription pricing (PAYG), but it would be a fair to assume it will be less than what they charge on Amazon.  [N.B. on AWS, IBM only offers a very small subset of its software primarily targeting ISVs for development & testing as opposed to enterprise customers.]
Now, let’s talk about the market and the opportunity for IBM.

Market maturity, opportunity & customer addressability
Since the recession a couple of years ago, Cloud Computing has gained more momentum in the enterprise.  IDC estimates spending on Cloud services in the range of $42B by 2012. 
If you look at early Cloud providers such as Amazon or Google, while I have enormous respect and appreciation for the innovation and technical design and delivery of the services, I argue they haven’t been able to gain traction in the enterprise space.  The only exception is SalesForce.com [take a look towards the bottom of this post.].  They have done well, because the founder had an enterprise software background.

As an example, if you look at Google’s enterprise business in 2009, it booked around $209M (that includes revenue from their search appliance + Google Apps).  In a previous post, I estimated AWS revenue to be around $200M / year.    If you compare these numbers with IBM SWG, MSFT or Oracle software revenues, I think it would be easy to conclude they haven’t captured a big marketshare in the enterprise space.  I think this is fundamentally due to their lack of business relationship, partnerships, and investments in sales & marketing.

So, I think this is a good time for IBM to enter the market.

In terms of opportunity and access to market, IBM is a global company with delivery centers around the world. It has business segments that align well with customers considering or transitioning to Cloud Computing. To understand the potential opportunity for IBM better, let's look at some numbers. 

IBM Development & Test Cloud is an offering from Global Technology Services (GTS):

The numbers above are in millions.  In 2009, GTS revenue was around $37B with a gross margin of around 35%.

There are several business lines in GTS:

• Strategic Outsourcing (SO) – This segment offers outsourcing services to commercial and public sector.  In 2009, IBM’s SO revenue was $19.3B.
• Integrated Technology Services (ITS) – This segment offers different IT services (project based) from IT strategy –> middleware services –> infrastructure services.  In 2009, ITS’ revenue was $8.7B.
• Business Transformation Outsourcing (BTO) – This segment focuses primarily on business process outsourcing (BPO), and “IT transformation” services.  In 2009, BTO’s revenue was $2.2B.
• Maintenance – This segment offers product maintenance and support services.  In 2009, GTS maintenance revenue contribution was almost $7B.

IBM has C-level relationships in Fortune companies in all industries.   Some of these companies have already entrusted IBM with their IT infrastructure and mission critical systems.  This puts IBM in a huge advantage over other service providers. 

As SO contracts are renewed, and as ITS engages customers in IT strategy and middleware services, IBM should also be able to harvest opportunities for both private cloud as well as public cloud. 

[N.B.  The cool thing about Cloud services is that they are not like SO contracts (i.e. fixed).  Once you sign up a customer, as long as you’re meeting your SLAs, and manage the offering in terms of features/capabilities, you should be able to maintain a profitable recurring revenue stream (i.e. reduced sales & marketing costs, reduced infrastructure costs through efficient multi-tenant delivery).]

Consider this....If IBM were to convert 10% of 2009 GTS revenue from existing base to Cloud, let's say over the next 3 years, they would make about $3B in Cloud revenue by 2013…Now, that’s revenue & marketshare.

Here is another reason why Cloud could help IBM.    IBM Software Group booked $22B of revenue in 2009:

SWG revenue breaks down as follows:

• Cross-brand middleware:  This is combined revenue from WebSphere, Tivoli, Lotus, Rational, Information Management worth over $12B.  IBM doesn’t break down the revenue by brand. 
• Other middleware: This include legacy middleware such as CICS & IMS.  IBM made over $4.6B there.
• Operating Systems: This includes software such as zOS, AIX, AS/400, & TPF.  In 2009, the OS revenue was > $2.1B.  This is dependent on how IBM’s hardware group (Systems & Technology Group) performs.
• Product Lifecycle Management (PLM): I think it is a joint venture with Dassault Systems.
• Other: This includes all IBM Software Group services (aka Lab services).  In 2009, the revenue for this part was $1.4B.

As you can see above, except for lab services, x-brand middleware is the only segment that’s been reporting growth. There are two reasons for this:

• Acquisitions: IBM has made some big acquisitions in this space: (i.e. Cognos for $5B, FileNet for $1.7B, Sterling Commerce for $1.2B…).  Acquisitions help IBM book new business.
• Renewal rates: This is recurring revenue from existing customers.  I was told by a software sales exec, average renewal rates for a successful enterprise software company is around 98% (depending on the product, maturity, etc).   So, this is helping IBM SWG maintain revenue and marketshare.

I haven’t heard of any new notable products out of SWG lately.  So, looking at the above, I think it is fair to conclude acquisitions have been the primary vehicle for growth in SWG.  So, with Cloud Computing, SWG  should be able to develop a new revenue stream.

So, for SWG, I think Cloud Computing can offer the following benefits:

• Use Cloud as a sales & delivery channel for SMB.  This would be very helpful to IBM.
• Offer a viable alternative to clients looking at other sourcing options
• In the beginning, I think Cloud can offer a parallel revenue stream for SWG particularly for WebSphere, Tivoli, and Rational
• Compete with other private cloud vendors and public cloud service providers
• Partners and alliances help IBM realize almost a third of its total revenue.  SWG gains a lot from these GSIs and ISVs.  SWG can offer new solutions to these partners to help grow its revenue.  Also, help ISVs cloudify their solutions.

All of the above should help IBM sustain growth.

[N.B. There is some difference between private and public clouds in terms of revenue.
Software is a high margin business.  In the case of IBM SWG, the gross margin for SWG was 86%.  The reason for this is software licensing & maintenance costs.  With public clouds, this is radically different. It is a volume business.  For IBM to be profitable in the public cloud space, they must sign up more and more customers.  On the private cloud side, they should be able to do better.]
----------------------
IBM is building a good story here.  From SWG side, with WebSphere CloudBurst, the recent acquisition of Cast Iron, and Rational Software Delivery Services, IBM is putting together all the asset to enable Cloud Computing for the enterprise.  On the GTS side, IBM is in a good position to create opportunities, and work with enterprise customers to help transition to Cloud.

Finally, from a competitive perspective, in the enterprise space (as opposed to consumer space), I don’t think IBM needs to worry too much about AWS or Google.  As long as IBM prices its public cloud offerings from GTS, Lotus, etc competitively, and maintain a close relationship with enterprise accounts, I think they should be able to do OK.

In the enterprise space, I think SWG should keep an eye on Oracle and VMWare on one side, and MSFT on the other.  GTS will have to worry about the usual competitors such as CSC, HP/EDS, etc...

More on VMForce

As expected, VMware and Salesforce unveiled more details on VMForce offering yesterday:

VMForce is a service that allows developers write any Java applications using SpringSource framework (AOP-based programming model and reflective abstraction, SpringSource Tool Suite, SpringSource TC Server), and deploy to a virtual environment using vCloud.  The deployed code runs on Force.com infrastructure and virtualized and managed using vSphere.
You can read the key announcements at the following:

• http://cloudblog.salesforce.com/
• http://blog.springsource.com/2010/04/27/vmforce-spring-cloud/

At first glance, the model looks very similar to SpringSource CloudFoundry offering which facilitates implementation and management of application on AWS.   There is a difference.  With CloudFoundry, VMware virtualization is not involved, as Amazon uses Xen. 
This is good for VMware and SpringSource.  With such moves, they are aggressively  moving to position SpringSource as a “common application stack”.  As enterprises increase the migration of their workloads to the Cloud, VMware/SpringSource can be a great enabler offering value-adds such as preventing vendor lock-in, code & skills portability, etc…
As I mentioned in my previous post, this is also good for Salesforce, because it enables them to host non-CRM related apps on their platform. 
The only question that I am struggling with is the revenue model/rev share.  Force.com pricing is clear and VMForce should help them increase subscribers. However, I am not sure how VMware will be able to make a sustainable business out of this, especially since SpringSource (open-source, cloud infrastructure, etc).   As far as I know, the CloudFoundry pricing is still unknown.  
How do you view in comparison to Azure and GAE?  Microsoft & Google own both the infrastructure and the application middleware.  It seems to me that application framework and tooling would not be the major revenue contributors. Thoughts/comments?

IBM POWER7: Smarter Systems for Smarter Planet

Yesterday I attended an IBM event on POWER7 in Los Angeles.  The event was designed to show how POWER7 is a game changer in terms of form factor, massive parallelism and performance, virtualization, workload consolidation, integrated systems management, high availability,  energy consumption, and overall costs.

First, Ross Mauri gave an introduction to POWER series and innovation over the last decade.  He shared a lot of interesting metrics in terms of clients, migration patterns and experiences, key aspects of the system and overall score relative to competition… and he also shared some information on POWER7+, and POWER8 roadmap.  Next, John Shedletsky (VP, IBM SWG) gave a presentation on how IBM software is integrated and optimized on POWER7, and shared some case studies and competitive analysis in terms of workload performance and scalability, and cost.  Finally, Stan Pachura (CIO, The PMI Group) shared his experience with POWER7.  He described how PMI had been able to upgrade to POWER7, and consolidate iSeries & BI workloads without incurring any additional costs.

Some of the vendors mentioned in the presentations included HP, SUN (Oracle), and VMware :-)  Here is a link to the presentations:
https://www-950.ibm.com/events/wwe/grp/grp017.nsf/v16_agenda?openform&seminar=584RYCES&locale=en_US

Technology-centric approach to Enterprise Cloud Computing doesn’t work

There is a lot of Internet chatter and conversation on Cloud Computing.  Since 2007, Google Trends shows growing increase in Cloud search keywords:

Majority of these articles and posts though are primarily focused on technologies (i.e. virtualization, dynamic provisioning, security, management & automation, metering & chargeback) that enable building a Cloud infrastructure or platform.  Technology decisions and effective implementation are absolutely necessary, but building, operating, offering, and managing a Cloud transcend technology. 

Cloud Computing doesn’t arrive in a box of CDs.  It is an evolution in IT competency and operational model (i.e. Incident Management, Asset Management, Configuration Management, Change Management, Performance & Capacity Management, SLA Management).  A technology-centric approach to Cloud Computing does not address IT operational gaps.

One of the fundamental requirements for Cloud transition is IT standardization.  Standardization is key to IT simplification and cost reduction, and requires an analysis of both IT and application portfolio.  In this regard, an analysis of the various workloads, performance characteristics, HW/SW compatibility & infrastructure requirements, application strategy such as any decommissioning, re-hosting, or outsourcing plans,… and review of enterprise architecture are necessary to establish standard configuration templates.  Without such an analysis, it would be very difficult to determine the right set of services to offer in the enterprise.  A technology-centric approach to Cloud Computing does not address IT standardization.

As I said in a previous post, there are different entry-points to Cloud Computing.   There are a couple of implications here.  First, organizations choose different strategies and approaches for IT cloudification based on their priorities.   Second, organizations are at different levels of IT maturity.  Some may have experience building and running CoEs. Some may have experience operating & managing shared services centers. Finally, some may already be running a Cloud (or have already implemented an on-demand and utility-based shared infrastructure way before the term “Cloud” was in vogue.) So, there is a lot of considerations in terms of organizational maturity, alignment, change management that are essential to a successful Cloud transition. These are not addressed by a technology-focused approach to Cloud Computing.

These were just some examples.  So, next time when you get a visit from a vendor, showing you a quick demo of 1000-node cluster, with dynamic scaling may be including spillover to EC2, a nice management interface, etc, a question to consider is how do I operationalize this? 

Oracle, AmberPoint, and the SOA Management ecosystem

Earlier this morning, Oracle announced it had entered into an agreement to acquire AmberPoint.  AmberPoint will be integrated and managed under Oracle’s Enterprise Manager division, and over time will be ported to the EM management framework.

For both existing customers and new prospects, this is positive news on many levels (i.e. broader/deeper capabilities after integration with EM, removing any doubts or concerns over vendor financial stability, product viability, solution’s strategic fit in the enterprise, etc).  AmberPoint will fill the gaps in Oracle’s SOA management capabilities today, and should play a key role for Oracle Cloud management in the future. With Oracle’s sales and distribution channels, AmberPoint will be able to reach new markets and extend market share.

In SOA management business, AmberPoint and SOA Software were the only key niche players left.  This acquisition puts Oracle in direct competition with SOA Software.  It will end the Oracle and SOA software partnership.  Looking forward, SOA Software is likely either going to get acquired – or - has to figure out a different product and partner strategy to compete. 

In terms of acquisition, the usual suspects for SOA Software include IBM, Microsoft, CA, HP, BMC or possibly even SAP.   Any of these vendors should be able to take their solutions and integrate them as part of a broader ESM/BSM solution.  SOA Software assets could help accelerate with that.  As far as product strategy, I think SOA Software will have to break away from just “SOA management” targeting enterprise customers into broader Cloud management also targeting Cloud service providers: self-service, asset/portfolio management, Cloud operational governance (quota, policies, SLA, billing, …) configuration, provisioning, automation…  They can do some of that on their own or go to market with new partners.

In summary, Oracle’s acquisition is definitely good for customers.  It also forces the other player to consider solutions and strategies.

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:

• 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.

There are many other considerations such as service provider’s alignment with the enterprise in terms of operations, support, compliance, SLA, and technical fit of the Cloud service vis-a-vis the application, etc…
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”.

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…

The enterprise has to deal with a mixed bag of virtualization vendors…

A couple of weeks ago, I was at Oracle Open World and attended a good session on JRockit (JRockit: What’s new & What’s coming).  The presenters were from JRockit lab in Sweden, and they presented many things from  new features, JVM performance, JRockit Mission Control (JRMC), JRockit Real Time (JRRT), and JRockit Virtual Edition (JRVE).   JRVE is a JVM that sits directly on bare metal hypervisor (it eliminates the OS layer, thus offering better performance, and simplification in terms of installation, configuration and maintenance).

Back in the BEA days, they showed a prototype of WLS VE running on JRVE at VMWorld in 2007.   That version was running on VMWare’s ESX.  With this version, it only supports and is certified on Oracle VM… Not a big surprise, if you think about it.  Since Oracle’s acquisition of Virtual Iron, Oracle has been optimizing its stack on its own virtualization infrastructure…

I was talking to a customer the other day to ask them about their Virtualization strategy.  This is large company that has deployed different types of servers and OS for different kinds of workload.  Currently, for Microsoft platform, they are using VMWare (when I asked him about Hyper-V, he said no plans yet).  For Linux, they are standardizing on RHT Enterprise Virtualization (KVM)… Oh, not to forget, on the mainframe, they are using zVM.

It occurred to me there is already a myriad of different virtualization tools and technologies deployed in the enterprise.  With Oracle’s solution strategy, there will be compelling reasons for many to deploy yet another virtualization technology in their environment (i.e. Oracle PaaS).  Furthermore, in addition to virtual machines and appliances deployed within the enterprise, many enterprises that adopt Cloud computing (hybrid clouds) will have to deal with additional virtualization infrastructures (i.e. EC2), their set of provisioning APIs and other management interfaces… 

The good news is that major virtualization vendors already support DTMF standardization efforts (i.e. OVF, VMAN) in their solutions or plan to support it.  There are also new standardization efforts around open APIs (i.e. vCloud) to abstract the virtualization technology, and provide a standard programming model to provision and consume virtual resources as well as support those interoperability use cases in the hybrid Clouds…  On the other side of spectrum, there is a growing number of virtualization vendors with provisioning solutions to facilitate packaging, grouping of related VMs (i.e. vApp)  for multi-tiered applications.

So, I don’t think most enterprises can standardize on a single virtualization vendor.  The trick is to figure out a virtualization management strategy that provides unified visibility and control in terms of asset & configuration management as well as infrastructure operation and governance.  Let me know what you think…

The future of SOA is Cloudy…

A couple of months ago, I was at an Oracle event in Redwood Shores.  The event brought together some of Oracle’s marquee customers & Fusion middleware product management team to discuss challenges/issues with regards to SOA, BPM, infrastructure management... and provide an opportunity to learn more details about FMW roadmap and offer feedback…

I seized the opportunity to talk to several customers about their SOA implementation.  Most of the customers (small –> large) had passed the initial stage of SOA readiness assessment, transition planning, and initial service portfolio development.  They had already implemented and deployed multiple enterprise services into production.  The most common issue related to SOA infrastructure management, and making sure it offers the level of resiliency and availability their customers demanded.

SOA introduces additional layers in the already multi-tier distributed applications.  First, you have the SOA management layer that handles performance management and policy enforcement.  Next, you have the Enterprise Service Bus (ESB) that abstracts service endpoints, and offers integration logic intermediation between service consumers and providers.  Finally, there may be integration adapters used to facilitate semantic and protocol integration with backend applications (i.e. SAP).  During a service request, all of these components must be available and fully functional.  Otherwise, the request fails and either the infrastructure must handle automatic management of the exception and re-routing of the service request message to maintain SLAs or the client must re-try the request upon receiving the exception.

Another area of concern is related to capacity management.  It is common practice to use high volume / peak load metrics to calculate capacity.  The result is over-provisioning of resources  (AKA server proliferation) and low utilization of assets.  In terms of IT financial management, the impact is monumental from increased hardware and software licensing costs to additional FTEs to configure & maintain the assets, and finally data center floor space, power consumption, …

So, many customers are already in their next level of SOA maturity.  They are focused more sharply on SOA operational governance.  This is where “Cloud” and SOA converge.

Before we get to that, let’s do a quick review of “SOA business value”.

SOA promises lower IT costs, reduction of IT complexity, business agility, etc… However, rarely is SOA business value measured against metrics related to the above.  The universal measurement for SOA in many organizations continues to be “service reuse”.  The more reuse, the better…Often, it is not even clear at what level of the organization reuse occurs to map and measure the value more clearly, but that’s a whole different blog…

For SOA to deliver lower IT costs, reduction of IT complexity, and agility, it is required to change the infrastructure to be more adaptive and resilient.  Unfortunately, in my experience, this is often not properly considered in SOA programs.  The vendors give you an ESB, and you’re good to run :-[

The “cloudification of SOA” involves the following capabilities:

• Dynamic Resource Management – Rather than over-provisioning to meet peak demand, a private Cloud infrastructure can enable demand-based provisioning.  This enables the enterprise to utilize IT assets more effectively and realize reduction of IT costs in terms of HW/SW/datacenter.  For some workloads, policies can be established to spill over to public Clouds like Amazon (hybrid Cloud). 
• Automation – Automation is a key component of Cloud infrastructure.  Automation is used in a variety of scenarios from automatic scaling to align with resource demands as well as automatic error/exception recovery.  This is a key enabler for service level management.
• Performance Management – Performance visibility and management across different layers of the stack is fundamental to any Cloud infrastructure.  Without it, there is no DRM or automation.  Once the organization is able to capture and correlate performance metrics across different layers and map them to a service request, they can do a better job of capacity management.  This also helps SOA with service performance management and SLA.
• Self-Service capabilities – Finally, this is an area that may not be readily consumable in all organizations, but it is a vision.  The idea is simple.  The goal is to bring the same self-service capabilities available in public Clouds to the enterprise (i.e. self-service service registration, self-service provisioning, self-service resource configuration and policy specification, etc…)   Imagine an environment where you can go to a self-service portal and request a server from a list of pre-configured images, click a button to provision a server in a few minutes rather than a few weeks that typically takes for IT request review/approval, procurement, HW installation and configuration, and delivery… Many companies are looking at this approach or have already implemented initial self-service portals to enable self-service capabilities.  In this scenario, it is possible to communicate IT agility using concrete metrics (i.e. average time to provision a server, # of demands serviced / week, etc)

Here is a conceptual diagram to illustrate the above:

So, to summarize, SOA operational governance and management poses difficult challenges in the enterprise.  The common approach to SOA does not address infrastructure issues to enable realization of SOA business values.  A Cloud Computing approach can help organizations with that.

I would be very curious how many are looking at Cloud as a progression of their SOA programs, and if they are looking at self-service capabilities.  Look forward to comments or questions.