Who are likely to be the biggest users of this appliance ?

Large Enterprises
Companies that are adept at running their datacenters and looking to dip their toes in cloud computing will find this notion of a private Azure cloud appliance very appealing. In addition to modernizing their application stack to make it more “Service Oriented” and Cloud friendly, they get most of the advantages that Azure provides them without worrying about privacy and compliance. One thing they will miss out is the dynamic elasticity that they would have got from the public Azure cloud.

Service Providers
This is an area which will likely see explosive growth and mass adoption. I predict providers rolling out purpose built clouds catering to industries, regions etc. At this time, many business details like cost, licensing terms, country availability, SLAs etc are not clear and are likely in the process of being defined.  Service providers can and probably will roll out custom clouds which cater to specific industry needs like HIPPA/PCI compliance. There is a strong chance that we might soon see clouds for Financial Services, Healthcare, Retail Payments, etc.

Government Agencies
Apps.gov is a good example that many Federal, local and State agencies have already started consolidating their data centers and application procurement for common functions. For the last couple of years the Federal Government has been in the forefront of defining Cloud Computing requirements albeit on the Infrastructure as a Service side. The Azure appliance will be interesting to the government for several reasons including data security , privacy and compliance reasons.

Why the Azure appliance wont be ubiquitous in the near future:

1. Dependency on new  purpose built hardware: Although we don’t know what the appliance would cost, requiring customers to buy hardware along with the appliance instead of just making it run on existing hardware will make it a much harder decision. The promise of the cloud was to move away from having to buy significant hardware and invest in managing them in-house. The appliance does just that unless Microsoft evolves it over time.
2. Scale: The bar for using the appliance is hundreds/thousands of servers. While this might make sense for a handful of large enterprises or ISVs, it is a significant barrier for most businesses.  This leads me to believe that the appliance will be more popular with the service providers first who can build “clusters” of special purpose clouds aimed at specific verticals.
3. Operations: Running an appliance that has 1000+ servers is not for the faint of heart. You need to have sophisticated processes ,tools ,skills etc to pull it off. Add the complexity of the new world of private clouds, it will take quite a ramp up before organizations can be mature enough to roll out enterprise wide private cloud offerings that take into account automatic provisioning, metering, chargebacks, dynamic scaling etc.

While it is still early days, I predict that the appliance will continue to lower the barrier to adoption and push the “fence sitters” to try the public Azure on their non-critical assets to get acquainted with the cloud model. Another trend we can expect to see gaining ground is that of “hybrid clouds” or “sometimes cloud”  where businesses can use the cloud to process excess capacity needs or use cloud to augment existing capabilities.

One thing is clear with the Azure appliance announcement – Microsoft is no longer afraid to cannibalize Windows Server licenses and perhaps is seeing the potential of winning over new converts to its cloud. Though Amazon has a head start, the cloud computing game is just getting started and Microsoft is a market definer in many categories including the one we are discussing here – Private PaaS Clouds.

Cloud Computing enables a tremendous amount of flexibility and scalability for deploying and managing your applications on the cloud. With this flexibility comes a list of items that have to be managed more closely compared to traditional systems.  Availability, Security, privacy, location of cloud services and  compliance are just some of the aspects of the cloud that have to be monitored and managed closely.

Governance in the Cloud is about defining policies around managing the above factors and tracking/enforcing the policies at run time when the applications are running. Different cloud vendors have varying degrees of flexibility when it comes to giving their clients access to the underlying infrastructure. It becomes imperative for businesses to understand these capabilities and define policies that mirror the needs of the business.

Governance Policy Definitions

During the design and development stage, it is important to establish rules and policies around how the various services in the cloud are going to be monitored and managed. The Quality of Service ( QoS ) of the underlying Cloud infrastructure and the Service Level Agreement ( SLA) levels of both the platform as well as the application have to be monitored and tracked. Additionally, defining access policies to control the roles in the organization who have access to the cloud environment is a key component of defining establishing governance policies. For example, Governance policies should be defined for the following

1. Role based access to establish control over who  has access to deploy and manage cloud assets
2. Metrics for monitoring the application’s performance and other business critical KPIs
3. Rules for defining critical levels of the metrics define above
4. Service Levels ( SLA ) of both the application as well as the underlying infrastructure
5. Quality of Service Levels

Governance Policy Enforcement
One of the main attractiveness of the cloud is the ability to reduce the “Time to Market” significantly. Cloud gives businesses the ability to roll out changes to applications almost instantaneously compared to tradition models. This capability comes with its own set of issues around versioning, upgrades and compatibilities of services. Well defined and enforced policies are a must to ensure robustness of the cloud based application. Policies can be enforced through the following

1. Change Management Reports to track and log the changes happening to the cloud assets
2. Alerts and Notifications to ensure that changes are captured and bubbled up to the decision makers in a timely fashion
3. Threshold based actions based on pre-defined rules. For example, automatically increasing the footprint ( read # of load balanced Cloud instances ) if the performance of the system is below certain threshold levels

The next frontier in Cloud Computing is clearly Platform as a Service ( PaaS ) which enables businesses to deploy “applications” on the cloud rather than move “servers” to the cloud. PaaS platforms should have the basic plumbing pieces necessary for application like persistence, workflow, identity, storage , authorization etc. Cloud Vendors like Salesforce, Amazon , Google etc are smart enough to figure out that PaaS is where the long tail of Cloud adoption is going to come from – so they are rushing to offer PaaS but there is one problem. Platforms are hard.Not every company can build platforms that are complete, compelling and sustain it version over version. Only a handful of companies truly understand how to do it and have done it for a considerable amount of time – Microsoft, IBM and to some extent Oracle ( with their BEA acquisition ) are the big ones.

But this is the cloud- the rules have to be different right ? Well, not completely. Traditional platforms are hard – Platforms on the cloud might be harder. So it is in this context , VMWare’s recent announcements of partnerships with Salesforce.com and Google are very interesting and might change the game. Until now, the biggest concern companies had with PaaS was lock in. If you wrote on Force.com or on Python to Google App Engine or to a lesser degree to the Windows Azure platform with .NET, you are stuck with that PaaS provider. There was little portability across cloud platforms.

So what did Google App Engine and VMWare announce at Google IO ?
VMWare acquired a set of Java development tools a little while ago called SpringSource which helped developers build enterprise Java applications. What VMWare announced with Salesforce.com and Google recently is that once you have a cloud application written in Java using the Spring framework, it will seamlessly run on the Google PaaS platform as well as in the Salesforce vmForce PaaS platform. so in essence, write once , run anywhere in the cloud. Wait, if you have VMWare’s vShephere internal clouds, it will even run on premise ! No lock in and full portability. Sounds great in theory but how many businesses are developing using Spring as their preferred development platform ? I would be shocked if it is even close to 5% of all Java shops. the promise of portability has never worked and I doubt if the cloud is going to be any different but it is a great marketing story !

This is just the beginning- I am positive that other Java frameworks for the cloud will emerge soon ( Are Oracle and IBM listening ? ). Microsoft on the other hand doesnt have to worry about these things. They have only only one platform to worry about -> .NET and can focus their energies on evolving the PaaS platforms rather than the development tooling and expand the lead on the PaaS market.

One thing is clear – PaaS  is the next frontier in Cloud Computing. The PaaS gold rush is truly on   –     Who will build the next Levis Strauss in this gold rush?

-Paddy Srinivasan @Cumulux

Cyclical businesses

An online shopping site knows the travails of the tide and its turn. On Christmas Eve, such a website could receive two million hits. And before they can relax, New Year brings another three million. And then there is a pause when visitor count comes down to a trickle. But can that business dismantle its three-hundred-server infrastructure by the second week of January? Or is there Valentine’s Day to watch out for? Does that mean you have to spend on the hardware and twiddle thumbs between peak traffic periods?
For starters, it takes a non trivial time to get infrastructure ready for deployment by leasing the servers. And, you pay for this on a monthly basis. March through October is this business’ lean time. That means wages for full-time employees looking after the hardware & an IT team that develops and maintains applications. Cloud computing can provide elegant solutions.

As a corollary to the above, think of yourself as an advertiser during Super Bowl. You flash your web site address watched by millions on TV, and are confident of a million hits over 48 hours, compared to the average daily of a few hundreds. You don’t want to invest capital on equipment to support folks visiting your site for those two days! Hop onto the cloud and hop off when you are done.

Smooth delivery of content

If what you offer on your site is rich content delivery,  that is another good reason to consider an offering from the cloud. Assume that traffic to your site is pretty high (again, thanks to the ad during Super Bowl) and streaming your content requires pretty good bandwidth: you certainly wouldn’t want your visitors waiting to be done, before they make way for others in queue. So, folks logging on from Beijing would be served up content from a location, in the cloud obviously, in Singapore while those logging in from Nairobi would get the same from a server in Johannesburg. This constitutes what is commonly called the Content Delivery Network. Both Microsoft Azure and Amazon have CDN offerings on their cloud platforms that are much more cost effective to their traditional counterparts from the likes of Akamai.

And, imagine what this could do to the costs of complying with your board’s disaster recovery plan? If you have mission-critical applications running, a distributed network helps you keep one end up even if another goes down. Earthquakes or Volcanic ash, God forbid, in one part of the world? Worry not – another part of the world lights up! And, at costs incomparable to those you would spend if you set up sites all on your own across the globe.

1. Compliance: Businesses that are serious about moving to the cloud in many industries will need the data centers to be certified for standards such as HIPAA & PCI. It is also not clear if the Azure data centers are SAS 70 II compliant which is a starting point for most compliance needs. There is some information here but it is not conclusive at the moment for Azure.
2. Geo Affinity: Currently, there is limited ability currently to instruct Azure where to run the applications, store data etc. This is a critical need to tackle regulations in most countries like the “Patriot Act” which mandate certain sensitive data to be located with the United States only.
3. Role Based access: Azure currently doesn’t have the notion of Role based access to its portals, deployed applications, billing etc. As larger businesses adopt Azure, they need to compartmentalize access to specific areas of functionality to people in specific roles. For example, the developer and an IT Pro need to set up solution environments for testing / production etc while a “Business User” might need to review billing and download usage reports once a week.
4. Multi tenancy : As with most platforms, Azure does not provide multi tenancy out of the box. It provides all the tools essential to creating multi tenant applications. An excellent example of a multi tenant application is “Riviera”, a solution that Microsoft and Cumulux built to showcase these capabilities in Azure. Check out http://code.msdn.microsoft.com/riviera
5. Dynamic Scalability: Azure provides APIs to manage you application’s foot print on the cloud and even allows you to pick the size of the Virtual Machine that will run your application’s fabric ( at deployment time ) but it doesn’t do it automatically for you. One of the biggest promises of the cloud is its innate ability to be elastic. In other words, the cloud’s ability to stretch and contract based on the load on your application. This functionality is not available out of the box and has to be done manually or by using 3^rd party software.
6. Enterprise Service Level Agreement (SLA) : Azure does provide SLAs for applications that are running on its platform. In fact it has a different SLA for its various components like Compute, Storage and App Fabric which is all great but it leaves a lot of gaps. For example, you need to have at least 2 instances running for the SLA to be in effect. The compute SLA is for 99.95% uptime which equates to about 4.38 hours of downtime per year- pretty good for a cloud operating system in its version 1.
7. Billing Visibility: This is an area which will receive plenty of coverage once businesses start adopting Azure for real world mission critical applications. Businesses need to know how much they are consuming and have the ability to set thresholds based on usage.
8. Licensing: Currently, Azure is available for commercial use only through credit card based purchases. Thought it is certain to evolve into other purchasing models including standard purchase orders , many companies are going to be hamstrung from trying out Azure until there are developer versions ( maybe with constrained functionalities ) available. Including Azure to standard Enterprise Agreements will ensure a faster adoption rate in larger enterprises as it eliminates long purchasing cycles that are prevalent in this space.
9. Auditability – Azure currently does not provide any audit trail for its data, applications and other artifacts in the system for archival and compliance purposes. This is critical in many verticals such as healthcare &  financial services.
10. Portability  - Having the ability to move data and applications is critical for companies to pursue “Sometimes Cloud” or “Parallel Cloud” strategies . In the “Sometimes Cloud” paradigm, applications use Azure as a spill over to their existing application to handle peaks in loads. In the “Parallel Cloud” strategy, ISVs might offer both an on premise as well as a cloud based version of the software depending on the nature of their end customers.

First, let’s look at the macro-view of the software industry and what this trend means to a majority of software vendors trying to position their products to medium to large enterprises. The terrain of the Enterprise software space is being flattened for ISVs of all sizes to compete on an equal footing. For example, in the business applications space, relatively smaller ISVs can now compete with the major ones such as SAP and Oracle. Traditionally, unless the ISV is an established leader in the space or an extremely innovative provider of a scarce product, both of which are outliers, enterprise sales cycles are complex. They are also fraught with discussions with the numerous IT, security and compliance teams in the Enterprise which need convincing that the ISVs’ software is worthy of real estate in the precious confines of the data center. Cloud Computing, and Azure in particular, change this perception as ISVs no longer need to jump through the loops of IT czars to get acceptance in the Enterprise. They now have a chance to veer away from other issues that often had the propensity to hijack the decision-making process and help CIOs focus whether on the ISVs’ solution is a match for the business problem.

Product Engineering
Product Engineering in most established ISVs follows standard engineering processes which  include product research, planning, architecture/ design , development, testing , release and the like. While these are still critical in the cloud paradigm, the turnaround is expected to be much more rapid. These would have to be carried out in smaller,, iterative cycles to ensure that product innovations are hitting the market in a continuous and incremental manner.

Service Models
Next, ISVs can now offer new application service models to their customers with Service Level Agreements that are supported by the cloud vendors. This also includes compliance aspects such as SAS 70 Level 2 certification which most leading cloud vendors offer today. This goes a long way in assuaging the IT gatekeepers that when there is a disruption in service, there is a remediation plan, backed up by guarantees from the world’s largest software companies and not by a boutique ISV. This thinking is yet to get broad acceptance but it is safe to assume that this will be a critical part of most cloud adoption plans.

Independent Software Vendor to Independent Service Vendor
ISVs have to morph from being a shrink-wrapped vendor of software bits (that are typically supported by VARs and Systems Integrators as the first line of defense) to a service provider who will have to provide the services on an ongoing basis with a Service Level Agreement that has to be honored day in and day out. This a major philosophical shift in business model for most ISVs as being a “Service Provider” means many structural, organizational and financial changes to their operating model. It will be no longer acceptable to push out updates once a year or 18 months. Cloud-based software will be expected to have a much quicker refresh cycle and customers will expect innovation to be delivered to them faster.

Channel Strategy
ISVs have to adopt the selling and distribution model of their software to fit the needs of the cloud. Traditionally, most ISVs have relied on a partner channel to sell, implement and service their products to the end-customer. Though this might still happen, the distance between the customer and the ISV will be significantly reduced by the new model. In the new business model of “pay as you go”, the ISV has to convince its channel partners to buy into this revenue model. As this might not suit all partners, new channel partners might have to be nurtured.

In summary, the cloud offers tremendous opportunities for ISVs but it will need them to embrace the full implications to take advantage of the paradigm shift. It is more than just making a “cloud” version of their product available for customers. The cloud model has to be accepted in all the critical phases of the product lifecycle including product engineering, sales, services and partnerships. ISVs that are agile enough to embrace this shift in computing will reap the rewards.

All major platforms offer the “use what you need, pay for what you use” model. Additionally, pricing is based on three key dimensions – Storage, Bandwidth and Compute. Storage is measured as average daily amount of data stored (in GB) over a monthly period. Bandwidth is measured by calculating the total amount of data transferred in and out of Platform Service through transaction and batch processing. Generally, data transfer between services within the same platform is free in many platforms. Compute is measured as the unit of time where an instance (application or machine) is running and servicing requests.

1 – Amazon Compute instance cost varies depending on the CPU Type
2 – Google charges compute time based on the amount of time the instance is processing transactions
3 – Microsoft charges compute time based on amount much time the instance is deployed

It is apt to highlight here that routine and recurring costs in terms of technical support and management are equally important and must not be ignored. For example, an enterprise working exclusively with Microsoft software should think twice before migrating to Google’s cloud offering just because they will save pennies. The migration cost may, in fact, be prohibitively high. In the end, you may also be compromising on efficiency. Based purely on operational cost, Google may be most economical but not by much.

Summary

Having viewed the strengths and weaknesses of each of these offerings, along with their pricing strategies, you are now in a position to evaluate them in the context of your needs.

Amazon provides the best options in terms of flexibility. Salesforce.com on the other hand offers only applications which have undoubtedly stormed the cloud with its popularity. (You must notice that applications provided by salesforce.com are niche applications meant for a small audience). Custom applications can be built on the force.com platform but they are native to that platform with zero portability.

Detailed analysis
Let’s take five different scenarios to understand how valuable each offering is, in that context:

On-premise application unchanged in the Cloud
This is characterized by multi-tiered legacy systems, or Java- and .Net-based applications.
If you choose Amazon, you could treat the machine instance as another server in the datacenter and do the necessary changes to configuration. With Google, however, you would need significant refactoring of application and data logic for your existing Java application. With Microsoft, you could re-factor data if your existing application is an ASP.NET. Else, your refactoring effort could be significant depending on the complexity of your application.

Web Application
Here, the assumption is moderate-to-high traffic with a back-end store and load balanced tiers.
Choosing Amazon gives you the same flexibility as the option above, but you would have to manually configured scalability and elasticity. With Google, you can use dynamically scalable features of AppEngine and scripting technologies to build rich applications.
Microsoft allows you to build scalable web applications using familiar .NET technologies. Scaling up or down is purely driven by configuration, aided by additional platform services such as Identity and Messaging.

Parallel processing, computational application
Here, we assume automated, long-running processes with little to no user interaction. Amazon requires you to configure multiple machine instances depending on the scale needed and then manage the environment. Features such as MapReduce allow for easier developing and deploying of compute-intensive applications. Google’s platform has minimal built-in support for building compute-heavy applications. Certain application scenarios such as image-manipulation are easier to develop with built-in platform features. Microsoft scores here. With worker roles and storage features such as Queues and Blobs, it is easy to build a compute-heavy application that can be managed and controlled for scalability and elasticity.

Application in the Cloud interacting with on-premise data
Applications in Amazon’s EC2 server cloud can easily be configured to interact with applications running on-premise. That’s a thumbs-up. However, Google offers no such support to allow for this scenario. You can render this possible through each application using an intermediary store to communicate with the on-premise application but that’s not a scenario Google App Engine promotes actively.Microsoft scores high again here. With features such as Service Bus to Sync platform components, it is possible to build compelling integration between two environments.

]]> http://azuredecisions.com/2010/04/01/comparing-cloud-platforms/feed/ 0 http://azuredecisions.com/2010/03/30/saas-paas-iaas-understanding-the-cloud-topology/ http://azuredecisions.com/2010/03/30/saas-paas-iaas-understanding-the-cloud-topology/#comments Wed, 31 Mar 2010 01:54:18 +0000 Cumulux http://azuredecisions.com/?p=36

Wanting the best from your Cloud investments is much like choosing a PC for your needs. You can have the latest and most expensive, but what exactly do you need it for? What use is a new PC that allows you to produce animated films, if you are a CFO and are dabbling with 100,000 rows of figures in an Excel sheet?

Likewise, the cloud can give you the ability to only store your data or, at a completely different level, manage your infrastructure. Each comes with solutions to your problems. But there may be baggage, too.

Cloud computing options

To make things are easier to understand, here are broadly four different offerings that cloud computing providers have on the market:

1. Infrastructure as a Service
2. Storage as a Service
3. Platform as a Service
4. Software as a Service

Infrastructure as a Service: A fully-outsourced computing environment powered by platform-virtualization offered as a Service. Amazon is a good example, though it also offers other alternatives. It is important to note that no other provider gives the flexibility to install your own operating system. Like two sides of a coin, this too has disadvantages. Hosting in this cloud is far more complex but offers true flexibility. But to manage this set-up, you need to have system managers to configure and operate.

Storage as a Service: You typically have a Hosted Storage environment that is accessible via open Web standards and application libraries. On the surface, storage seems to be a simple matter of dumping data into the cloud. But, there are complications. Managing databases can be an issue. Security concerns are uppermost though all cloud providers are crying hoarse that their storage platforms are as secure as if it were in your own environment.

Platform as a Service: Higher level application abstractions and platform capabilities like Messaging and Security are offered as a service here. Here again it is a matter of convenience. Not every platform provides all the capabilities. From the management perspective, handling multiple platform providers can prove to be difficult.

Software as a Service: The most mature among the four kinds of offerings, you have here complete-hosted applications offered as a service. This typically works for small enterprises. It may not work for a complex environment which has multiple software running on different platforms.

Impact on IT Management and Application Development

Now, how does choosing one or the other affect the way you manage your IT? Does change management kick in here? Let’s look at what you need to do, to align with the cloud.

So, here’s the deal. Each layer in the cloud brings with it panacea. But it also means a few sacrifices. The Infrastructure Cloud brings you total flexibility – you don’t need to change anything. The baggage here is managing the infrastructure. At the other extreme, we have Platform or Software as a service where there may be considerable change management.

1. What is the minimum expected Service uptime over a year ? How are services outages defined?
2. What are the Standard Operating Procedures during an outage ?
3. How can the Service Levels be monitored on an ongoing basis ?
4. What are the policies for compensating for the downtime ?
5. Is the Cloud Vendor amenable to my Audits if needs arise ?
6. Is the Access to data secure, encrypted and authorized ?
7. Is my company’s data segregated from other customer’s data ?
8. What happens to the copies of data when my contract expires ?
9. Can I specify where my data will reside and my application will run ?
10. Are these policies applicable to backed up data as well ?