Skip to main content

Why SaaS and Cloud Computing make IT fun again

If you had asked me five or even three years ago what I thought of IT, I would probably replied that I had enough of IT for the rest of my life. Computers were fun in 90's when I was a student, but after the year 2000, with the increasing industrialization and maturity of the IT industry, things were starting to become boring for me. IT was no longer that exciting mix of science and art. This was especially the case of the enterprise IT as low cost country outsourcing turned the software development and enterprise integration into a full blown industrial process with lack of creativity: Armies of anonymous software engineers implementing endless customizations of a questionable business value, all this driven by multi-month waterfall projects and roll outs. Well, I exaggerate here a bit, I agree. ;-)

It was the rise of Software as a Service (SaaS) which changed the rules of the game. By running a single multi-tenant instance of a service on top of a hardware and software stack of their own choice, SaaS vendors are able to completely avoid the costs of supporting a platform matrix - multiple hardware architectures, operating systems, database engines and middleware platforms. They save additional resources by actively supporting only one version of their software at a time. By preferring configuration over customization, the ability to let customers implement limited changes while still maintaining a single code base and a single physical instance of a service , the costs of implementation and maintenance - especially upgrades - are also significantly reduced. Overall, SaaS allows to focus much more resources towards productive use as opposed to unproductive technicalities which plague the traditional behind-the-firewall implementations and ISVs.

The above productivity gains together the centralization brought about by running a single instance of a SaaS app caused another indirect change though: Armies of software engineers are no longer needed or desired. When building a SaaS application, you need a small SWAT team of engineers of exceptional qualities rather then a large infantry of average coders. The reason is that you need to move very fast and be extremely flexible in order to react to changing circumstances. Sure, managing a team of exceptional individuals brings difficulties of its own kind: strong opinions, clashing egos, flame wars over programming languages and architectural approaches. One has to work hard to keep the team together as opposed to ending up with a bunch of eccentric individuals. But I still prefer dealing with these problems and work once again in an environment, where creativity and smarts of a small team can win over a much larger and well equipped competitor.

What do public clouds and Platform as a Service (PaaS) such as AWS bring on top of SaaS? I believe the key features are democratization, elasticity and raised level of abstraction. By democratization I mean the fact, that in the age cloud, everybody, even a small startup, can afford to run its service on a world-class infrastructure. Elasticity of public clouds brings the ability to grow and shrink capacity in matter of minutes - at GoodData we grow our platform month-on-month at double-digit rate since summer of 2008. Capacity planning in case we had to procure and provision physical hardware would become a nightmare. And last but not least, raising the level of abstraction, realized by utilizing higher-level platform services and management APIs, allows cloud-hosted SaaS vendors to focus yet more energy towards their core competencies, rather than developing and maintaining the low level platform stack.

Eventually, I am glad that I did not succeed departing the IT industry five years ago, because I would miss the paradigm shift which is changing the whole landscape of IT these days. I am glad to be a part of that seismic shift.

Popular posts from this blog

First Month of Active Touring

Putting my money where my mouth is, I took on the adventure of buying a plug-in hybrid. A few years back, I used to drive a car only for weekend getaways, so an SUV seemed to be a logical choice. At only fifteen thousand kilometers driven annually, the fuel economy was not a significant issue, the driving experience was the main thing.

During the past few years with family and small kids, the car usage became more spread out throughout the week. With that said, I noticed we maintain two very distinct driving patterns: many short trips around Prague during the week to get kids to school and sports and then longer trips, roughly 100 miles each direction, during the weekends. With short distances and many cold starts due to the city driving on the workdays, the already poor fuel economy of an SUV deteriorated further.

I realized when our car was up for renewal that it was almost as if we needed two different vehicles for two different use cases - an electric vehicle for city driving and …

Version 2.0 Syndrome - Why the Software Architecture Matters

"Guys you will never have a chance to build the version 2.0, you have to get it right from the get-go, or keep suffering from your mistakes for the lifetime of the product." - Jiri Karpeta, my boss at LCS International, used to say. It was back in 1995, and while LCS's bread and butter were Helios, an ERP for the SMB segment, we were busy building Noris - the future LCS's flagship ERP for larger enterprises. Of course, given the above philosophy, LCS was quite heavily invested in CASE tools to support our software design efforts. That's where I learned the first time that software modeling matters.

But back to the original statement above that you "never get a chance to build the version 2.0". It may sound too harsh, too fatalistic. Well, you may be right, there are always exceptions to the rule. While I don't have exact statistics at hand, my experience shows that the statement is more often correct than not. I have interviewed hundreds of software…

Agile on Overdrive

It may sound old-fashioned and laughable these days when techniques like UML are so unsexy, but I can still remember the days back at IBM T.J. Watson in the early 2000's when we were working on a prototype of a new VoiceXML browser to inform IBM's standardization efforts in the space. (The language was supposed to be VoiceXML 3.0, and we abbreviated the research project to "V-3" - pronounced "fau drai" in reference to the German V-2 rocket.) We took VoiceXML 2.0 as a foundation but added full DOM and DOM Events support together with XForms as the data model representation.

It was shortly after IBM's acquisition of Rational Software, so we took advantage of that deal and got our hands dirty with Rational Rose. While one of our colleagues kept pushing us to start coding and iterate towards the result in the agile fashion, given the incomplete specs and many open questions stemming from the combination of so many complex technologies in one piece, we prevai…