Isn’t Cloud Computing Just Hardware-As-A-Service?

Cloud Computing is the new web2.0, in terms of hype and buzz all around. I hate to invent yet another Buzzword. But isn’t Cloud Computing just a Hardware-As-A-Service (HaaS)?

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?

Shifting Away From Tables, To Entity Models

RDBMS (Relational data management systems), simply put, most Database systems allow us to create data models of businesses in terms of rows and columns in a table. Tables can be ‘related’ to indicate dependencies of data between tables. RDBMS was one of the best things that ever happened to software abstractions. Every business domain has been modeled to be a set of tables and relations between them.

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.

Menu Engineering : How To Fix Price For Your Product

Pricing a software product or service is one of the toughest tasks for any business. Particularly so in the web-centric world, where everything is expected to be free. 

In this NBC TV show, Guest Gregg Rapp  explains some interesting strategies that may help you design your pricing models based on how customer perceive price and the whole psychology behind it. The discussion (a restaurant menu) is not directly related to Software applications, but worth considering the essence of each strategy in pricing anything for that matter.

Visit msnbc.com for breaking news, world news, and news about the economy

On a related note, this podcast by 37signals  on the same topic discusses how to price software applications.

Giving something away for free is fine as a step one as long as it leads to a step two where you charge for your product. Pick a price that seems fair to you and that you'd be willing to pay. If you're not willing to pay for your own product, don't expect anyone else to either. Also, your price tiers need to make sense relative to each other.

- Making people pay

How To Choose A Database For Your Next Application ?

Well, it depends.

Want to know what options are available and how to choose one for your own application, read this wonderful article by James Hamilton. Though this article does not include all possible options (particularly those on the cloud), but its a nice introduction to classify databases based on what you need.

Relational databases have become so ubiquitous that the term “database” is often treated as synonymous with relational databases like Oracle, SQL Server, MySQL, or DB2. However, the term preceded the invention and implementation of the relational model and non-relational data stores remain important today.

Relational databases are incredibly rich and able to support a very broad class of applications but with incredible breadth comes significant complexity. Many applications don’t need the rich programming model of relational systems and some applications are better serviced by lighter-weight, easier-to-administer, and easier-to-scale solutions. Both relational and non-relational structured storage systems are important and no single solution is appropriate for all applications.

Source: One Size Does Not Fit All by James Hamilton (b:Perspectives)

Good to know. But before you start researching for a perfect Database for your App ..

Keep this great suggestion from 37signals in mind. I am big fan of “Getting Real”. The team behind “Getting Real” @ 37Signals suggest that you don’t worry too much about Scalability aspects early in the design of your application, as you will have lots of time later on to figure out.

In the beginning, make building a solid core product your priority instead of obsessing over scalability and server farms.Create a great app and then worry about what to do once it's wildly successful. Otherwise you may waste energy, time, and money fixating on something that never even happens.

Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scale. Without the first problem you won't have the second.

Source: Getting Real – Scale Later