How Cloud Computing Changes the Economics of Software Architecture

I’ve been thinking a lot about architecting software applications for the cloud lately – particularly for Windows Azure, as that’s the platform we have chosen to build CubeSocial’s SaaS solution on.

Lots has been written about the impact of PaaS and IaaS services like Amazon Web Services and Windows Azure on software architecture.  I’ve seen plenty of commentary arguing that architects need to change the way they design systems to consider the platform billing model and on-going costs.

But is that really a change? In my opinion, it’s no different to what we architects have always done – only in the past the cost considerations were different. It was about numbers of servers, software licences, software versions etc.

I believe the cloud computing model changes our approach in a much more fundamental way.

I see the shift that is happening right now as the modern equivalent of what happened when Windows went from 16-bit to 32-bit.

Freed from the memory limitations of 16-bit computing we all stopped optimizing our Windows code, as there were simply so many system resources available to play with… it was effectively limitless.

Cloud computing platforms bring the same philosophical shift to web applications.

Yes, I could spend time architecting for the billing model. I could spend money getting programmers to performance tune their code to reduce billing charges. But that doesn’t mean I should.

Let me ask you this: Why spend 50$ an hour on getting a programmer to tune their code, when instead I can pay Microsoft or Amazon another $50 a month and throw another web front end at the problem. Then, instead I can have my developers doing something much more useful to the business: adding new product features more quickly than the competition so that I can sell more and make more revenue.

And that is the true economics of cloud computing.


5 thoughts on “How Cloud Computing Changes the Economics of Software Architecture

  1. Hey Mark,

    Interesting post, I guess there are a few things I would throw in.

    Often the sorts of architecture issues which you need to design for cant be fixed by just throwing more resource at it. Or if you do they become exponential problems that get to consume a LOT of resource VERY quickly. For example bottlenecks and inappropriate use of the building blocks that make up the solution (eg. doing relational stuff with non relational stores).

    Putting it another way, there is still only so much memory you can keep throwing at a memory leak.

    From another angle, the scale that our solutions now need to operate could mean that the $50 you are talking about is multiplied by a very big number, and like datacentres today, your ability to compete in the market could come down to just how low you can keep your costs.

    For datacentres that is people and electricity, for our applications it could very well be storage and CPU cycles.

    Finally, I would rather a one off $50 payment, than the cumulative and recurring $50 cost. But agreed there is a balance there.

    Anyway, just a couple of thoughts!

    1. Strewth mate you were quick of the mark with that reply!
      I take your points about building blocks etc, and you still need to do the right thing – you’re correct.
      I would argue with your maths in the last para though. Fixing a performance issue (a bug effectively) let’s say takes 4 hours. But as we all know that’s not all the effort. You have to document, regression test, deploy, and manage the whole process. Let’s say 16 hours in total = $800. Or 16 months of an additional web server. Then multiply that by however many things (web pages, SQL queries or whatever) you are tuning. Let’s say their are 10 ‘things’ so 160 hours of effort total.
      Meanwhile I could have spent that 160 hours delivering a new feature, which wins me say 1 new customer per month at say $25 a month = $300/month additional revenue by the end of year 1, and I am net up $250/month.
      Do the maths with whatever bill rate you are using, but at the end of the day I think unless you are trying to build the next Twitter or Facebook our default approach for the cloud should be to focus on delivering new features quickly and not worry about spending coding cycles trying to minimise hosting costs.

      1. In my maths I was looking at that $50 be cumulative, what I meant is that this becomes a “technical debt” that grows with interest along with your site.

        But these are seriously complex equations, no doubt. Its also hard to talk in abstracts. I agree totally on the feature piece, also from the angle that performance and speed is a feature.

        Interesting chat mate.

  2. Working in the Azure business now, I have had the chance to work with a few hundred partners building apps on Azure. A few things I see people getting wrong – first to Mark’s point, I see people spending huge amounts of time trying to build a cost model for their app. Now this is a good thing to do at a first iteration but this thing is hard to predict – I mean that is one of the main reasons to go to the cloud in the first place. In most cases it makes more sense to build the app with a rough idea of costs and then just, well, run it and see what it costs. To Mark’s point, this is cheaper than trying to do a modelling project with consultants. Also I see partners trying to build a monolithic app in the cloud. with the cloud you have to be more iterative, more experimental and just faster. Its no good building your first app that takes you a year and then seeing if it works. You have to think in a more iterative way. The ultimate extreme is in the social games market where companies knowingly only write 20% of the features they have planned in the first release to see if it works and how people use it. This is part of being a cloud-thinker.

  3. Whats surprising is that with how new this is, there are already numerous major companies out there that are offering the private and public clouds aside from Mircrosoft Azure like Amazon, AppRiver,, etc. from what i can tell, this industry is so new it may only get more crowded and with new leaders. With that in mind it is difficult to design just for one provider.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s