Since we first started offering AppLogic last year, one of the questions users have asked about is how to test application performance. As it turns out, this hasn’t been an easy question to answer . . . until now.

Why has this been a problem? With any virtualization based system, including AppLogic and our friends at Amazon’s EC2, it’s not quite as simple as start your app and hit it with traffic. The reason for this is that all current hypervisors use a leaky-bucket scheduler. Whenever there are spare CPU cycles, they’ll be given to whatever virtual appliances are running. So, if an appliance (or image) happens to run on a physical node with no other appliances, it’ll get all available CPU cycles. If another appliance is later started on that same node the hypervisor will give it its share, but that’ll reduce the cycles available to the first. The effect of this is that performance isn’t always consistant.

In normal operation this isn’t an issue, but when trying to predict operations costs it can be critical. For online services computing is the largest part of COGS. Therefore, if you’re offer by a factor of 2 or more in the amount of users a given set of resources can support your pricing spreadsheet is going to have some potentially fatal flaws causing you to set your pricing at an un-profitable level.

In AppLogic 2.0 we’ve added a simple extension to enable resource capping. AppLogic overides the hypervisor scheduling, capping the resources for your appliances at the level you specify. You can then run your performance tests and know exactly what level of resources are required to support your user base.

Resource capping is a simple little feature that I expect will find a lot of use.

We started taking registrations for our AppLogic 2.0 beta over the weekend and already we’re getting some traction. New features in the utility computing platform include monitoring, SMP appliances as well as a pre-packaged scalable LAMP application.

While monitoring is the most visual new feature, SMP appliances is what most registrants are getting excited about. Being able to scale each virtual appliance from 1% of a CPU and as little as 16MB of memory to 4CPUs and 8GB of memory, a 400X range of resources. Unlike one-size-fits-all solutions, AppLogic enables you to tailor the performance of your application while still being efficient in your over all resouce usage.
We’ll be putting out some benchmarks next month that promise to be very exciting.

Our partners at Layered Technologies just announced their new Strongbox utility storage solution. Unlike competing services that require custom code or writing to a vendor specific API, StrongBox can be mounted on client systems so it appears like a local volume on your computer or server. Jeremy, Layered’s CTO, is quoted as saying “You can literally drag and drop files into Strongbox from your desktop.”

Tier1 Research said Strongbox could “. . . fulfill T1R’s wishlist . . .” for a service that ” . . . will beat the pants off of Amazon’s S3 utility storage product.” (The arrangement of the quotes is mine, but I think it’s in keeping with their meaning.) I’m biased of course because Strongbox runs on AppLogic, but I agree with Tier1.

Jeremy and his team at Layered have put together a great service and I can’t wait to join the beta.

We’ve started using the alpha version of AppLogic 2.0 for our Grid University training sessions so if you want to get a sneak peek of the upcomming system you can attend any of the twice weekly classes.

While on that note, in preparing for Tuesday’s GridU session I was working with one of our support engineers to balance the resources between the database and an array of web servers in the sample app so we could saturate the database’s write throughput. The new monitoring system in AppLogic 2.0 is tailor made for this. It let’s you create custom dashboards for each app by building graphs from any of hundreds of counters the system keeps on all appliances in your application. So once our app was up and running I set up a monitoring dashboard with database reads and writes on one graph, inbound and outbound traffic on another, free memory on a third, and finally cpu utilization for the database and all web servers in a fourth graph. Then we fired up the new traffic generator appliance he’d just built and started tuning our application.

Using the dashboard we could see at a glance that our first attempt at resource allocation wasn’t working. Our array of web servers was saturated but the database wasn’t even close to saturation. We added addtional resources to the front end, watched for a minute and then decided to add still more resources to the array. Success!

The total elapsed time to tune our application once it was up and running, including building the dashboard, was less than thirty minutes. I won’t even venture a guess how long this would have taken in the past.

An email blast from Derrick Harris at Grid Today lead me to a great article by Paul Strong, Distinguished Research Scientist at eBay labs regarding the need for grid computing in building large commercial applications. Few companies know more about scaling commercial apps than eBay so I’ll simply quote a couple pieces and let you read the rest for yourself:

” . . . Google, eBay, Yahoo! and Amazon cannot fit into single instances or clusters of traditional databases or file systems. All of these applications or services treat the network as the platform, hence the assertion that infrastructures, such as eBay’s, are, in fact, grids.”

“While these Internet behemoths are at the extreme end of things, almost all application developers and datacenters are using similar techniques to scale their services. ”

“What’s missing is the crucial element of integration — a horizontal layer of software that allows these vast sets of resources to be presented to applications or services in a consistent way, as a platform. This allows those resources to be effectively harnessed and shared, and to deliver the required scaling, throughput, efficiency and so forth. In fact, this software may be viewed as a meta-operating system.”

Of course, AppLogic is just such a meta-operating system and Paul’s article is well worth a read.

I was reading a white paper from ThinkStrategies today about a new
service that offers to escrow technology from SaaS providers for their subscribers. Jeff Kaplan is the principle at ThinkStrategis and I’ve always found him pretty perceptive, but after reading the paper and thinking about this for a couple hourse I’m uncertain just how effective traditional code escrow can be for SaaS.

The concept behind putting the technology in escrow is simple; the supplier puts the source code and documentation into escrow and if the supplier ceases operation or fails in some significant obligation the customer can retrieve the code, build a functional system, and maintain the technology for themselves.

In practice, though, it’s never so simple. Despite the agreement it’s often necesary to sue before getting the code. Even in the bast of circomstances, it can take months. Plus, despite requirements that complete documentation and all needed compilers and libraries be escrowed with the code, the material recieved is almost always incomplete. Despite all that, I know of projects where it’s been invaluable.

Still, I can’t help feeling that SaaS represents a different situation for a few reasons.

First, with a traditional software license the customer has a running system to use during the time it takes to retrieve the code. With SaaS, however, the supplier’s hosting provider is likely to shutdown their systems so the customer will be without access to a functioning system for months.

Second, the customer has no experience running the system. Imagine Salesforce turning over their code to a customer; what’s the likelihood the customer could build a running system from it. Seems like a stretch for the typical customer and even for the largest subscribers I suspect it would take months.

Third, and possibly more importantly, the customer often isn’t in possesion of a current data set.

Even if the customer eventually get sthe code and manages to build a running system, the business impact could be catastrophic. Therefore, the value of a traditional escrow seems dubious at best for SaaS.

I think there’s a better way.

What customers really want isn’t the code, but simply continued access to functionality and data in the event the provider ceases operations. So, to determine a better solution let’s consider what happens when a SaaS provider declares bankruptcy? For starters, their assets, including servers are often frozen awaiting disposition. Their colo provider will deny them access to their facilities and may terminate internet access. In essence, the application and data are locked in limbo.

Utility computing provides a new opportunity for providing continuity to customers. Because applications aren’t bound to physcal assets any longer they can be migrated easily. Plus its a simple matter for someone other than the supplier to take over operation of the application. No escrow, no lawyers, no rebuilding, no reverting to backups. I need to spend a little more time thinking the details through, but I think there’s an opportunity to provide customers a better solution.

I’ve written more than once about the surprising capital intensity of offering SaaS on a large scale.
In last week’s eWeek, Eric Lundquist wrote
The route to SaaS could be bumpy highlighting the capital appetite of many of the internet’s big
players. In my earlier post on lessons from Google in SaaS economics I discussed what a typical SaaS provider could afford to pay for infrastructure per month on a server basis. Eric goes a step further, though, and brings up the fact that in previous capital intensive businesses it wasn’t the initial investement that crippled companies but their innability to reinvest. As he puts it:

“Technology executives will have to learn what steel mill executives discovered long ago: Capital investment is not a one-time event. That server farm you built last year will soon require another big round of investment to stay current and efficient.”

Of course, if you’re reading my posts you probably know I believe there is another way.
And, in a strange coincidence, Google’s datacenter in The Dalles hints at that solution. You see, Google chose The Dalles because nearby aluminum manufacturers had shuttered their plants. Those plants, in turn, had been drawn to the area in an earlier technology revolution by an abundance of cheap electricity.

Just as the steel mills didn’t build their own power plants, SaaS providers starting today don’t need to build their own datacenters. It was technology advancements in giant turbines and damn construction that provided abundant cheap power so manufacturers could stop building their own power stations a century ago. SaaS and Web 2.0 providers now have access to grid technology that enables utility computing meaning they can stop building their own datacenters. After all, there are providers who specialize in building infrastructure and they are brutally efficient at it.

Joe McKendrick, contributing editor to Database Trends
and Applications magazine, quotes Robert Reid, group vice president for Oracle’s CRM On Demand service in a recent blog entry on
SaaS adoption:

“Most IT organizations spend 70 to 80 percent of their time updating, patching, and maintaining applications,’ said Reid. ‘Where I think the real value is being able to understand the business requirements, and then proposing, here’s the best way for the corporation to utilize technology to achieve their goals. SaaS allows IT to elevate itself into being business partners with line-of-business units. SaaS helps IT professionals to do what they really want to do the most - have an impact on the business, as opposed to just doing patches, and maintaining things, and upgrading systems.’

I think he’s dead on with both the facts and his assessment. Sys admins are a creative group who got into what they thought was cutting edge technology. Unfortunately, they’ve been bogged down in the morrass that we as an industry sold them with our “every problem can be solved with just another layer of management” methodology. (why we persue that course is an entry for another day)

When showing AppLogic to people for the first time customers often ask whether the reduction in time spent managing applications will result in layoffs. I think it’s just the opposite, IT people are inherently creative. Once free of dealing with servers and OS’s and middleware those skills will be freed for better use. For instance, we have numerous large-scale issues to solve as an industry as we convert once in-house applications to online services. How are these services connected. How are they secured. These are complex issues that will require creative solutions. Therefore, as we make that transition, I expect employment will actually go up.

When the dotcom bubble burst, one of the casulties was investment in hosting. Exodus had been one of the poster children of the new world order and for many folks it’s bankruptcy closed a chapter in internet business models. Over the past twelve months though, we’ve seen that perception change.

When 3tera first started working on AppLogic we didn’t envision selling it through hosting providers. Frankly, like most of the industry, hostng never really occured to us. Rather, we were on a standard Enterprise Software trajectory - to simplify the deployment and maintenance of applications in the enterprise datacenter. Along the way, though accidently discovered hosting.

Like all startups we struggled constantly to keep costs down. One way we decided we could do that was not to build our own datacenter. Instead, we’d rent dedicated servers to test AppLogic during development. That turned out be a fateful decision.

During one my first calls to hosting companies I decided to show them why we needed certain capabilities, so I fired up a Webex session and gave them an impromptu demonstration of AppLogic. I was talking with the VP of Sales, who quickly turned my demo around and made a sales pitch about why he wanted to be able to sell AppLogic. We made a few more calls with similar results and just couple weeks later, in Decmber 05, 3tera shifted our go-to-market strategy 180 degrees. We poured our efforts into partnering with hosting providers. At the time investors told us we were crazy. “Hosting’s dead” was repeated time and again on visits to Palo Alto.

Of course, hosting was far from dead. We found vibrant entrepreneurs growing 40%/yr without huge injections of capital. The market was more developed than I’d ever imagined, with players both large and small finding ways to differentiate. The whole segment though, just wasn’t getting much PR.

Today, however, hosting’s making a comeback in popular awareness. Over the past year, one industry stalwart after another has
rediscovered hosting, culminating in Sun, “the dot in dotcom,” attempting to restablish itself through partnerships with hosting providers. Competition is always good, so we’re happy to see Sun in the market.

After six years, it appears the rest of the world has discovered hosting is hot again.