Last week, I attended an event sponsored by SDForum on Cloud Computing called "Cloud Computing and Beyond: The Web Grows Up (finally)"   For me, being a Cloud Computing provider myself, I expected the highlight of the event to be Forrester's James Staten's opening keynote address on trends in Cloud Computing (you can find the slides here .)  And, it didn't disappoint: James's usual gift for clearly summarizing trends and futures made for an interesting talk. 

However, the highlight of the event for me turned out to be the panel on users' views of Utility Computing.  Given the nature of the audience - mostly tech-savvy software entrepreneurs - I expected a great deal of details about how these companies were using Cloud Computing.   What found out was that most of them are customers of Amazon's EC2 service, and what I heard instead of technical details was their strategies for mitigating the risks of dealing with Amazon.   Each of the companies using EC2 had developed intense internal expertise on Amazon's service.  That's right, you read correctly: on Amazon's service.  Not on Cloud Computing in general (though there are those who argue that EC2 and Cloud Computing are the same thing) but rather on the intricate technical and organizational details of dealing with Amazon and its service as well as optimizing their use of it.

It wasn't a surprise to me that these companies, dependent on Amazon for their success, would get to know the service well.  What did surprise me was the lengths to which they went to mitigate the risks.   Generally, if you have doubts or fears about something, you want to learn all you can about it.  These companies showed incredible technical depth at understanding EC2's characteristics and peccadillos.  They asserted that it was critical to their success.   But this seems to me to be in direct conflict with the ideal of Cloud Computing, which is the democratization of information technology; in other words, lowering the barriers of entry.   I think this is an admission that Cloud Computing technology in any form is still not polished enough for completely casual use.  At ENKI, we realized this early on and decided to strive to be the "onramp to the Cloud" by providing all the services necessary to use our cloud without having to know anything about Cloud Computing.  In fact, we have customers - software startups, generally - who don't even have any technical people on salary.   We - with their outsourced development team - just take care of all that for them.  Naturally, there is a labor cost to that, but it's certainly less than hiring dedicated Cloud Computing Experts to manage your cloud provider.   

It has been said that you should keep your enemies close to you.  The idea is, that way you'll know what they're doing so they can't hurt you.   These companies have taken a similar approach to dealing with Amazon.  Each of them admitted to having high-level contact with Amazon's management and knowing the management hierarchy at Amazon well.  They felt this was critical to their success.  However, Amazon doesn't even answer the phone for their regular customers, so how can the average entrepreneur expect to use EC2 successfully?   Fortunately, there are third parties out there that simplify the interface to EC2, but yet these successful startups had instead chosen to take the extreme step of building a personal relationship with Amazon.   At ENKI this comes naturally since our value proposition is to build a partnership with our customer that automatically builds the personal connections.  

Each of the panelists underscored the need for trust between cloud vendors and customers and pointed out that a great deal more transparency was necessary if that trust was going to develop successfully. I think the trust is key, because as the panelists illustrated, the cloud vendor becomes part of their customers' value delivery system - a role that traditionally was kept in-house (at much greater cost, of course.)   Putting myself in the cloud vendors' shoes (!) I can understand the barriers to transparency, which include such necessities as hiding the internal technology used to deliver the cloud services in order to maintain its security for all users.  (I've had $45 a month customers demand to get a tour of our data centers!)  And then there's always the software engineer's number one Achilles' Heel, which is lack of modesty: it's hard to say "I don't know" when a customer asks you a question - after all, you want to look like you know what you're doing!  Yet, these and other barriers will need to be overcome if Cloud Computing is going to move forward smoothly.  The cost savings from shared infrastructure that it offers are drawing in lots of customers, but the trust between customers and vendors must be cultivated if the revolution is to move beyond the casual user and SMB space into the mission critical enterprise market.

Somehow, when I wrote the first article on deploying SaaS applications to the Cloud, I thought I was done.  I'd answered almost all the questions that I got from customers on this topic at the time.  Since then, I've had many more discussions, so another article is warranted!

We get a lot of customers from overseas who want to deploy SaaS at far lower per-seat prices than the typical $50/seat/month that U.S. SaaS providers seem to have standardized on.  At the same time, most of those companies are wanting to go live with an application that was written on a single PC as a development environment, focused on a single customer at a time.  In other words, those applications are single-tenant.  Yet, deploying just one instance per end customer of such an application in a virtual private server (VPS) is expensive.  In the LAMP world (as an example) it's difficult to get a system to run reliably in less than 512MB of RAM, and if it experiences any significant use you really want 1 GB, which can run upwards of $125/month in most cloud computing services (single unit quantities - most providers offer quantity discounts).  So, at $50/seat, it doesn't take many seats per customer to pay the operations cost, but if you want to go with the industry benchmark of 25% of revenue spent on operations, you end up having to sell 10 seats per customer to turn an acceptable profit.  However, many SaaS startups are thinking 2-5 seats per customer.   So, to be viable, costs have to come down.  And my customers in developing countries, such as Latin America, are thinking $10-$20/seat, which makes the finances even tighter.

As I mentioned before, the two options for meeting the operations cost targets are reducing the cost per application instance in the single-tenant model, or making your application multi-tenant.  Since my last blog article, we've tried some additional successful ways to reduce the single-tenant instance costs.   They center around Virtuozzo and its free open-source sibling, OpenVZ.  The cost problem with single-tenant SaaS hosting is that you have to pay to store the executable code that is common to all your customers over and over in the server's memory, once per customer's VPS.   Virtuozzo solves this problem by breaking the VPS (or a hardware server) up into multiple pseudo-virtual-machines called "containers" that can share the operating system, middleware, and application software.   For example, under LAMP, Linux, Apache, MySQL, PHP, any mail transfer agent, and even the application code can all be shared.  This means that each container need only hold the memory needed for that specific instance of the application to run, which can be as little as 100 MB.  It also means that maintaining software and operating system is easy because there's only one copy to update.  Even your SaaS application need only be stored once, so updating multiple containers with a new version is easy.  

This changes the economics completely.  If you assume that LAMP needs 300MB for shared operating system and code, then at 100MB/customer you could put 7 customers onto a single 1GB virtual machine.  If you assume 4 seats per customer, that would be 28 seats.  That same $125 for the cloud-hosted VPS now creates $560 of revenue at $20/seat, resulting in an operations percentage of revenue of 22%.  If you go with a 4GB VPS, the economics get even better at 17%  Because Virtuozzo is about $100/mo per server, the percentages will be a bit higher than with OpenVZ, but Virtuozzo offers graphical management tools that simplify managing multiple containers.  Both Virtuozzo and Open VZ allow you to customize the memory and CPU available to particular containers, opening the possibility of selling your SaaS services at varying price/performance points for increased profit.  Provisioning a new customer with Virtuozzo is very simple: you ask it for another container with your default common software visible, and you're done.

You may be wondering why you would use *two* virtualization solutions: the cloud-provided VPS, and then Virtuozzo on top of it.  The answer is that the hardware virtualization is an integral part of the Cloud Computing service and used to provide the other features of Cloud Computing that are important to SaaS providers: scalability, uptime (through automatic re-provisioning of failed VPSes), and security.  It is possible to lease Virtuozzo containers from hosting companies who run it directly on racked servers, but then you give up control over the reliability and CPU allocation you need to provide a professional SaaS service. 

There is also some news to report on making your SaaS application multi-tenant, which would eliminate the need for Virtuozzo.   A couple of LAMP customers of mine were able to quickly retrofit limited multitenant capabilities to their single-tenant applications by putting each of their customers on a custom domain, using Apache virtual hosts to direct the customer's traffic to a separate code base on the same Apache installation, and using the domain name to determine the database name in MySQL so that different customers couldn't see each others' data.    This allowed them to do something similar to Virtuozzo's containers in that only the PHP code for each end customer needed to be stored repeatedly, not Apache, Linux, or MySQL.   You can only do this for a limited number of times before you run out of memory, so realistic upper limits on the number of end customers per VPS seem to be around 20-30.   You can potentially extend this to a larger number by sharing PHP code between virtual hosts, but you have to examine the security issues carefully.  This method, because it relies on a fixed structure to hold the multiple end customers' code, makes administration difficult.  Also, since CPU is shared across all the end customers, one customer - whether through normal use or due to a software bug - can bring down your entire VPS's collection of end customers.

Once again, the tradeoff between single-tenant deployment and its quick time-to-market versus the efficiency of multi-tenant is evident.  However, Virtuozzo/OpenVZ breathes a bit more life into the single-tenant approach.

With all of these economization tools in your quiver, I have come up with a recommendation for how to make the most of your operations dollar/pound/euro/yen as your SaaS service grows:

1. Beta phase: deploy onto individual VPSes (gets you into beta fast)
2. Ramp phase: deploy into Virtuozzo containers to save money.
3. Volume phase: when you have enough customers to enjoy the savings in resources and the centralized administration, rewrite application to be multi-tenant and deploy all customers to one instance of the app running on a highly scalable VPDC and scale the VPDC up as customer count grows. This phase is optional if the cost model of phase 2 is workable.
4. Mature phase: move resource-hogging customers out of the VPDC into their own VPS – and charge them more for the performance!

Clearly one implication of this is that when you make your application multi-tenant, you can also easily set the number of tenants to be one!