The Commoditization of Computing: IaaS vs. PaaS
At this point it’s not about whether we should move to the cloud, it’s about how fast can we get it done. Over the last several years, we’ve witnessed and taken part in something that can only be compared to the industrial revolution. It’s something I call the “commoditization of computing.” No longer are the days of asking, “How much is it going to cost to build that and try it out?” No longer are the days of answering, “Well, I need to buy four servers and add storage to the SAN, so probably about four to six weeks and about $50,000.” Now it’s the press of a button and I just spun up two web servers, a database and an app server. There are no more excuses to stop us from innovating. No more long meetings discussing whether it is worth trying something, only for the end result to be “OK forget it, not worth it.”
So, I think you can agree with me that those days are over. Now, the conversation turns to how we get there? Do we lift and shift everything we have? Sure, we can do that, but at what cost? Do we want to just free ourselves up from owning and managing hardware, or do we want to truly get the full benefit of the cloud? Which brings me to the key issue: What is the full benefit of the cloud? The way I see it, it is about paying for exactly what I use. We can spin up a server, right size it, and pay a cost for that server which is most likely cheaper that what we can purchase, power, license and manage ourselves. But is that truly the full benefit of the cloud? I say no. I say not even close. I believe the full benefit is the power of PaaS.
As leaders of organizations, our job is to first identify the incredible opportunity before us, second foster the environment to achieve, and lastly ensure we reach our goals
Ok, so what is the difference between IaaS and PaaS, and when should I use each? IaaS is “Infrastructure as a Service,” and PaaS is “Platform as a Service.” They both have their purpose, and both are important in the cloud ecosystem. Determining when to use each appropriately is the secret sauce. It’s the difference between 20-30 percent savings versus 60-70 percent savings over the standard co-lo/on-prem environment. Both options give us something much harder to obtain in our own data centers. We can get scale, DR, high availability, quick time to market and cost savings, but how do I get the 60-70 percent cost savings? Is that truly possible?
It is possible—you just might have to think a little differently. You also might have to make an investment of time to refactor your application. In fact, the size, scope and cost of the application will make the choice for you. For example, a large-scale, enterprise application can cost millions of dollars a year to run, so a 60-70 percent cost savings might be worth the time invested.
The next question to ask is how to move an application to a PaaS environment? Again, learning to think differently is super important. Forget what you know about standard patterns and practices, and take a leap of faith. Consider if you should use a standard SQL database, and if so, what should be stored in that database. What is the peak usage for your application? Does the application get hit harder during certain times of the day or are there cyclical spikes? These are important questions that need to be answered.
Once you move to PaaS, you’ll find that one of the greatest things about it is that you pay for what you use. For example, if I need a total of 60 minutes a day of CPU to run a particular task, then that is exactly what I should pay for. If I were to use IaaS for that task, I am paying 24x7 if I can’t control the frequency and timing of that task. With a PaaS service, I let the cloud provider worry about how often and how much. All I worry about is how many minutes of CPU or how many transactions I used. A very different way of thinking.
So, let’s talk more about databases. What should you use a database for, and what is its purpose? We’ve gotten away from the primary purpose for which a database was created. The primary purpose as I see it now is to search for data, not to use it as a repository. A database should let me search for something, and if built properly, instantly I should get my results. But do I need to store all the data in the database? My philosophy is to store what you need to search, keep your database lean and mean, and learn to scale out.
The incredible thing about PaaS is that a database can cost you anywhere from $20 a month to $6,000 a month. Personally, I would rather have 20 databases at $100 a month rather than one database at $6,000 a month. Store what you need to search, and put the all the rest of the data needed for display in a much cheaper storage medium.
The concept of scale out becomes easy when you learn to think differently. Thinking about scale early in the design process helps you avoid the common problem of having to “throw hardware” at a problem later. There are so many inexpensive PaaS storage solutions that the combinations are limitless. The combination of SQL and many cheaper NoSQL storage options leaves you with a multitude of alternatives. Learn to think differently!
I’ve kept this discussion pretty much cloud agnostic so far, and honestly the concepts can be applied to any of the major cloud providers–the two biggest being AWS (Amazon) and Microsoft Azure. I personally believe Microsoft is ahead of Amazon in the PaaS space. The number of Azure PaaS services is too high to count. The hardest part is keeping up and deciding when to use each. But that is a good problem to have!
As leaders of organizations, our job is to first identify the incredible opportunity before us, second foster the environment to achieve, and lastly ensure we reach our goals. It is very likely there will be resistance, and that is why it is critical to drive and embrace this change from the top of the organization. These are exciting times; it would be a shame if as leaders we missed this opportunity to achieve great things.