1. Cloud Computing. The hardware cost for development was less than $750. That figure included the cost of a laptop. In an economic climate where startups have to do more with less, how can you beat that?
   • We used Google App Engine for the most part but not exclusively.
   • For confidential documents, we used Amazon S3, preferring to go directly between the browser and Amazon, bypassing Google. Any doubts about whether Google will mine those documents were neutralized.
2. Staying conceptual with the implementation.
   • Google App Engine was great for helping us stay conceptual. They take care of scalability, backups, OS versions, patches. All the stuff that drags you down.
   • Amazon EC2 is too low level. One has to worry about scalability, backups, OS versions, patches. So we go up a level with Rightscale and BitNami.
   • For the same reason, we would consider Amazon RDS over doing our own database management.
3. Open Source Software. Most notably, jQuery. Their slogan is “write less, do more”. The reality matches the slogan. A rich milieu of available software allowed us to assemble components rather than write code. A couple of times we were bitten by it too. A month after we had integrated a component, the developer decided not to support it any more. We switched away. So one has to stay agile but that’s the name of the game anyway.
4. Staying conceptual with the requirements. This was the second-biggest factor: working with a team that trusts you, things don’t need to be written down to an excruciating level of detail. You hear the requirement in vague terms, you implement it, and if you had misunderstood, well, change quickly. Keeping the Agile Manifesto in mind.
5. Tracking shifts in business strategy. This was the biggest factor. The business strategy changed at least a couple of times during the project. The development was continuous, however. We were surprised to discover that the changes forced us to re-factor the code as it was re-purposed to fit the changing strategy — but very little of the code was thrown away. The re-factoring may have made it more modular, actually. By the time the business strategy had settled, we had software components that were well-tested already. Only the final integration was left to do.

Your mileage will vary, of course, but these are the factors that made us successful for this project.

1. Cloud Development for Google App Engine
2. Cloud Development for Amazon EC2
3. Managing software delivery from outsourcers
4. Managing evolution of database configurations
5. Performance and Stress Testing
6. Security Testing

In this introductory post, I want to cover activities that cross all platforms. The premise of Cloud Development is that the company does not own any hardware. Under these circumstances, how does software development get done?

Tight control over source code is essential. This need does not go away with Cloud Computing. It becomes more important! It used to be that if you lost track of the latest source, you could always look at the working machine. No longer, not consistently anyway. In the Google App Engine support forum, there is a predictable weekly request from someone or the other for Google to help them retrieve their latest source code. The answer is always the same (no, can’t be done).  The team needs to use the source repository frequently to build from.  The source repository should be backed up, versioned and secure. What should be under source control? Everything! That includes source code (duh!), install scripts (Rightscale scripts, for example, for creating an environment), security settings,  even database configurations. This last item will require further discussion; more on it in a subsequent post.

The issue tracking database is the team’s second most important asset, after source code. It too needs to be backed up, versioned and secure^†.

The bad news — at least the concern — is lock-in. Is a business locked in once they have grown? Do we have choices in case Amazon (or whoever) decides to raise their prices? Will the customers be able to take their business elsewhere if that happens?

There are a number of vendors out there providing cloud computing services:

1. Amazon, of course.
2. Rackspace
3. GoGrid

Others will follow.  IBM has made announcements regarding Cloud Labs, Microsoft is working on Azure, etc. But I want to focus on Amazon, Rackspace and GoGrid in this post. They offer services that are somewhat analogous, each has the equivalents of S3 and EC2.

All three have RESTful APIs accessible from a range of languages. They perform similar functions, yet the API for each is different. It always happens this way. the vendors are trying to compete and innovate. Lock-in is not a big consideration at this stage, maybe it will be later.

So how can we insure against lock-in? Standardization, of course. If the APIs for the three cloud vendors were the same, lock-in wouldn’t be as much of a problem. Early Stage IT serves a different market and we intend to stay focused on that market. However, if there is a venture that aims to build a standard API, as RogueWave did in its marketplace many years ago, we would be supportive partners.

For background reading, check out InfoWorld’s reviews of some cloud services.

We have seen this movie before. Client-Server was all the rage when web technologies came into vogue. All of a sudden, we didn’t have to visit every desktop to “do an install”. Once the trend got going, the cost savings became quite compelling. It took a number of years but eventually most of the applications were rewritten to be web centric. The installation problems moved from user desktops to the company’s servers. 

Virtualization is the next step in that continuum. The cost of managing your applications on your servers is getting felt and, slowly but surely, applications are getting SaaSified. They will probably need to be rewritten, just like they were in the transition from Client-Server to the web, but that will take time, effort and investment. The venture guys are reluctant to fund a new company unless it is a SaaS company. 

What I don’t know is whether the economy is helping the trend or hurting it, which is why it is difficult to assess when SaaS will become the dominant trend. It might be helping by creating the pressure to reduce cost. It might be hurting by reducing overall investment. Time will tell.

What does it mean for early stage companies?

• If your needs can be met with a SaaS solution, it’s a no-brainer.  Go for it.  SaaS is typically priced by number of users and at the early stage you don’t have too many of them anyway.
• Consolidate your other needs into a Minimum Viable Platform (MVP).  This requires choosing your applications with an eye to how they will be operated.  Once you have picked the MVP, look into using a standard hosting service or a data center.  Prices vary from $10/month to $5,000/month so if the burn rate is important, make judicious choices.  Call us, we can help.
• If faced with the choice between an inadequate SaaS solution and a strong web solution, look at your requirements again and decide on the best way forward.
• If faced with the choice between an inadequate SaaS solution and a strong client-server solution, be very careful.  As Yoda would say, The Force is not with you.

Copyright © 2009, J Singh