In a way, Cloud Computing is the new web2.0, in terms of hype, buzz and activity all around. Every business has something to offer ‘on cloud’. Every consultant is busy selling strategies to cash in on the cloud. And every analyst is preparing a report on the cloud. Every developer is trying to equip to engineer applications on the cloud.

Simply put ..

What is really Cloud computing is all about? Why not look up the definition of Cloud Computing by going to the Encyclopedia on the cloud (??), Wikipedia.

The term cloud is used as a metaphor for the Internet, based on how the Internet is depicted in computer network diagrams and is an abstraction of the underlying infrastructure it conceals. – Wikipedia

Cloud computing is an example of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet. – Wikipedia

Though Cloud Computing could be everything for everybody (just like Web2.0), most stakeholders would agree to confine Cloud Computing in three forms.

Three Forms of Cloud Computing

1. Software-As-A-Service (SaaS)

Refers to Software Applications offered over the internet as a service. SalesForce.com is an excellent example and one of the most successful SaaS offerings. BaseCamp for Project Management, Google Apps are few other successful and well known SaaS offerings.

2. Infrastructure As A Service (IaaS)

Refers to Servers, Storage and Networks offered as a service over the internet.  Most Internet hosting providers fall in to this space. Amazon ECS, Rackspace, AT&T, Akamai are very good examples. They offer servers, databases, storage area networks, networking gear, content delivery networks as a service.

3. Platform As A Service (PaaS)

These providers offer Infrastructure as a Service with a limitation or leverage (depends on what you are looking for) that all applications must be built and run on top of their often proprietary platforms or technology stacks. PaaS inherently include IaaS. Google App Engine, Microsoft Azure, SalesForce Force.com are fine examples for this service.

SaaS and IaaS have been offered in the market for a while. Though there are lots of advances in the technicalities of managing them and lot more new players in the market, these services are not entirely NEW.

What is new in Cloud Computing is the third service, Platform-As-A-Service (PaaS). Not only Infrastructure to run your Business applications but a full platform to develop those applications. It is quite unlikely that these PaaS offerings (at least initially) will not provide a smoother migration for Enterprises to adopt Cloud Computing as this means re-developing most of their business applications.

Easier Adoption Path for Enterprises

For most enterprises, the only option that make sense at this point is IaaS. Instead of running their own data centers, applications can be moved to a public Cloud or a private cloud or managed cloud with little to no impacts. Cost of migrating to a Cloud will be quite insignificant and offer the best level of cost savings, while not forcing a vendor lock-in as applications run on generic platforms. This is the best option.

Or Enterprises can migrate to SaaS offerings, if there are comparable applications are available. For instance, instead of running your own CRM solution on premises, can migrate to SalesForce.com.  But it is a big question for how much generic application like SalesForce.com can offer unique capabilities for each organization, a primary reason why Enterprises developed their own software in the first place. Vendor + Application lock-in is implicit. All Employees and Customers need to be retrained in new sets of applications. Extensive customization is required.

The latest entry in to Cloud Computing, the PaaS is the most Unlikely path of migration of any Enterprise application to the cloud, as this needs re-architecture of their applications and Migration of application software as well  along with data migration. And this would be quite expensive and time consuming for any non-trivial, uncommon business application. Vendor + Platform lock-in is implicit.  Need to retrain Software Development groups and it could be quite extensive as the Platform could be significantly different from generic platform most software developers are comfortable with.

That’s my 2 cents on the Cloud. You can read a little more on the Wikipedia. Or anywhere on the Cloud (:-)).

If you look at the definition on Wikipedia, that is what Cloud Computing is all about. Isn’t it?

Cloud computing is an example of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet. – Wikipedia

If you agree in principle that Cloud Computing = HaaS, then there is nothing really NEW about it. It must be as old as the concept of renting a server or the first internet Hosting company. And, all internet (as well as in house applications) that we know of did scale as needed. They are all in principle dynamically scalable. Didn’t they?

Then why so much undue buzz about Cloud Computing?

Is it because now there are more players in the hosting market? Amazon, Microsoft, Google, Rackspace … etc.

Or is it because of the new Billing model of hosting services that charges based on actual usage rather than a fixed cost?

Rackspace, Google, SalesForce, Amazon, Microsoft, Yahoo, Sun, Ning and FriendFeed.

Will add more notes on the discussion shortly.

Well, that is not quite true. While number of Employees in the organization may not change so often, their usage patterns are much like any web application startup.

For instance, take an enterprise with 10,000 employees. The enterprise IT department has developed an intranet web application for Performance Reviews. The web application will be accessed by Employees and Managers at the beginning of the year to set Goals. And will be accessed in December to appraise performance with respect to the set goals. The application will also be accessed sparingly by employees and managers through out the year to make necessary status updates, follow ups on action plans etc.

Typically, IT department will design the system such that it can handle the load during the worst peak hours.  In most Enterprises, the most productive day to get any thing done is the Last day. So, the system shall be designed to handle the load of all 10000 employees accessing the system in a single day.  Assume that need 5 servers to handle the load. So what happens to those 5 servers for the rest of the year?

If the enterprise uses a cloud service (could be an in-house, partner or a public cloud service), the firm can run the least possible configuration throughout the year and scale up to 5 servers during the last few days of the year or whenever they need (like a mid-year reviews in June/July).

There are many Enterprise applications that are normally run with a fixed infrastructure designed to take care of peak loads. For instance Expense reporting applications (normally accessed only at end of month), Payroll applications(normally accessed only at the beginning of the month or once in a fortnight) and even Email servers(normally accessed only during office hours). Most Enterprise applications are not accessed all-the-time. Cloud service is a perfect target for all those applications and could save an enterprise a huge chunk of their budgets.

So, Cloud Computing will benefit businesses large and small alike. In many cases, larger the enterprise, larger will be the savings if Cloud computing is used.

Let us see if there is a simpler way to define ‘Cloud Computing’ or simply cloud. Wikipedia, the Britannica for today’s world says,

Cloud computing is a paradigm of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.

And if that doesn’t make any sense to you, watch this IBM advertisement that appears to have the intent of explaining what really cloud is all about.

What do you think about ‘Cloud’ now?

If you are inclined for more Technical or Business jargon, watch videos on this page where some of the Tech/Business celebrities in Software industry explaining the concept of ‘Cloud Computing’. The list of celebrities include Larry Ellison (Oracle), SalesForce, Eric Schmidt (Google), Steve Balmer (Microsoft), Werner Vogels(Amazon) and of course an Analyst that knows it all (anything for that matter).

Check out videos here.

Hope it made sense now.

Scaling Rails Applications In The Cloud

Listen to the MP3 of the presentation here.

Watch slide 23, the non-RDBMS bonus carefully. If you have read about my previous post on this topic, Shifting Away From Tables, To Entity Models, the point comes home pretty convincingly in this presentation.

However, recently another paradigm is taking shape, called as Domain Driven Development, DDD for short, that emphasizes the importance of modeling a business in the domain of the business itself rather than dictated by abstractions tied to tables. DDD clout calls them “Entities” (not Tables).  In certain ways, I read this shift from RDBMS to Entity model as “shift from horizontal (table) abstractions to hierarchical (entity) abstractions”.

While Entity models may provide a better modeling, in a well designed database model, based on my experience, most of you may not find any obvious issues with current table models. And definitely no need to remodel your systems to embrace entity models, right away.

There may be lots of players in the Industry that are supporting Entity frameworks, but based on my current and recent work, two companies I must mention here.

Microsoft

Microsoft released ADO.NET based Entity framework and even made it easier to create those entity models from existing RDBMS tables. And almost every .NET project I have looked at recently is buzzing about DDD, ACL (Anti corruption layer) and Entity framework. LINQ is something can not be omitted, of course.

And on its Cloud offering, Windows Azure, Microsoft is providing both options. Azure Storage (read non-RDBMS and optimized for cloud) and Azure SQL (read SQL Server running on the cloud). That makes transitioning from an in-house application to the cloud smoothly.

Google App Engine

And Google App Engine doesn’t support RDBMS abstraction at all but only support Entity models. (No JOIN support in App Engine will force you to think different and prefer one over the other, whether you like it or not).

Google App Engine team aptly explains the scalability reasons behind moving away from RDBMS and creating its own BigTable.

Back to the Future for Data Storage

Building a massive, distributed datastore which can service requests at an extremely high throughput is something that we’ve focused on at Google. We created something called Bigtable that underlies the datastore in App Engine. The design for Bigtable focused on scalability across a distributed system so it may operate a bit differently than databases you’ve worked with before, such as not supporting joins. This isn’t an accident — when you build a system that can scale to the size that Bigtable can there’s no way to do a general purpose join on data sets that size and still have them be performant.

So does this mean the end of RDBMS abstractions?

As I mentioned earlier, I don’t see any reason to remodel existing systems right away. The abstraction in Entity models could still be carried out with existing Table models. Unless you got huge data sets and you have faithfully using the deepest normalization possible. And of course, only if the top most concern you have is scalability or performance.

And I am pretty sure RDBMS systems will stay for a longer time, as almost all data is currently stored in some form of RDBMS system. But Software modeling via RDBMS abstractions for sure, will change.

I have been developing a community application, ‘Yes to Politics’ for friends in Andhra Pradesh, India to interact with politics in some strangely different way. More about this app later, let me share about data migration.

I have around 28000 entities in a model and trust me, I tried to cover all my needs in the design of the model up front.  Well, software development doesn’t work that way. I realized I needed another property in the model and I needed to give some default value too.

When you add a new property to an existing model, Google App engine doesn’t fill the default value for the existing set of entities. So when you access that new property on existing rows, you will meet with exceptions as they never existed for them. You can check if that property exist before accessing it. Well, Python provide no way to do it. The only way to find whether that property exists or not is by accessing it and catching an exception when it doesn’t exist. Not a cool way, but that’s almost the best method we got.

And, you can not use that new property in queries too that need to search in the existing set of entities. There is a way we can fix it.

Define your new property and then loop through all your entities and set this new default value.  This is no easy job to do on Google App engine. First, you need to setup a new URL and a HTTP handler to take care of this maintenance. Second, you can only update so many entities in one go without exceeding restrictions in terms of time and processing power. So you need to split the task in to easier bits, say, update 10 entities at a time and create a handler to auto refresh every few seconds to take care of all updates. And then run that handler in the browser and wait till it is finished.

I have about 28000 entities and that would mean I have to call that handler almost 2800 times (10 entities at once) and better give some wait between calls to make App Engine restrictions happy. For my model, 5 sec between each call worked fine. Any quicker, App Engine throws an exception. And it took about 25 minutes for me to finish the process.

I thought it will be anyway one time task so didn’t regret waiting that long. But then after all that is done and happily using it for a couple of days,  I found that I had to add yet another property.

This time, instead of doing that hard way, I have decided to do something different. Instead of adding the new property I was thinking of, I added a simple integer that will act as a version number for the entity. I followed the same as above and waited another half hour to get it updated. And for the actual property that I wanted to add, I added the new property but deferred updating the property with a default value until that entity is being used. The lazy way. So I just need to update my queries with this new version number logic but don’t have to really update all my data at once.

I realized later it was an excellent move. As not all my entities really need that new property added. Whichever entity needs it, will get it when it is accessed for the first time. Your data migration now becomes highly scalable. Now all my models, I begin with a version number, so that I never have to worry so much about data migration when I decide to make changes to my models.

This is not without a downside. We have an additional property in the model and a little overhead of a version number comparison every time entity is accessed. If you are continuously adding properties that may not be required for all entities, then the storage space you save could easily outweigh this new additional property.

But, you decide whether the flexibility of scalable data migration it provides is worth the weight and hassle.