When to use Platform as a Service
Osaka Train Platform

When to use Platform as a Service

To date, Infrastructure as a Service (IaaS) is more popular than Platform as a Service (PaaS). Heroku (now a subsidiary of Salesforce) was launched in 2007. Microsoft launched Azure in 2008. These are the most popular PaaS platforms.

Amazon Web Services (AWS) launched Elastic Cloud Compute (EC2), Simple Storage Service (S3), and Relational Database Service (RDS) in 2006. Google Cloud Platform (GCP) launched in 2008. When Microsoft saw the success of AWS they quickly added their own IaaS offerings. In 2014, Microsoft even began allowing Azure VMs to run Linux, which was further highlighted by Microsoft's CEO pronouncing "We ?? Linux" which I interpret as “We ?? Money”. This brings us to our current state where the big three IaaS providers are AWS, GCP, and Azure.

If IaaS is more popular, when do we use PaaS? An advantage that both IaaS and PaaS have over owning servers is that you don’t have to maintain the hardware. Common advantages for PaaS are that you don’t have to maintain the operating system, the database, the number of nodes, or the network. Your PaaS provider takes responsibility for the security and performance of those layers for you. Basically, PaaS can allow you to launch without IT or operations specialists. PaaS providers have free options that allow you to do proof on concepts or hackathon projects.?

IaaS and PaaS share some disadvantages. If you want to make a capital expense rather than an operations expense, you have to buy your own hardware. If you are constrained by regulations preventing you from using public cloud offerings you have to build an on premises system.

Let’s review the two main PaaS providers to discuss their specific advantages and disadvantages.

Azure App Services

I worked for a company for a while where I helped various teams with their infrastructure needs. The company had a handful of products and multiple services. Some of the products were obtained via acquisition. Because the systems had very different origins, the technologies used varied greatly from team to team. Many teams were open source oriented but the team that handled the billing website for our software used Microsoft products. When I joined the company this team used the original (pre-git) version of Microsoft Team Foundation Server (TFS). They wrote code using ASP.NET. Production ran on Azure websites (mostly known today as Azure App Services).

Their use of Azure was a real “Aha Moment” for me about PaaS. Deployments to Production were automated. Azure can be configured to run tests prior to release. If the tests fail the deployment will be cancelled. One of the really impressive things was that they were running at scale and Azure would swap in the new code on instances via A/B testing. If performance didn’t meet specific expectations Azure would automatically back out the code and alert the developers.?

While it’s more likely to see Azure PaaS using Microsoft technologies, it also supports Java, Python, and Node.JS on Windows. On Linux it supports Ruby, PHP, and Node.JS.

While most reviews and documentation seem to agree that it’s better to use Azure PaaS for web applications instead of IaaS, there are a few reasons you might want to use IaaS instead:

  • Versions - There may be an older version of the database or operating system that has features you need. IaaS will allow you to stay at these older versions by controlling them yourself.
  • Load-balancing and Content Distribution - While Azure App Services has a great history of scaling to meet demands, there are some options beyond its capability (like operating an outpost server in Alibaba for users in China).
  • Education - If you want to truly understand a full stack you have to build it from scratch. Even IaaS obscures you from the hardware portion of the stack.

Heroku

When I built VoteSquared I used GCP IaaS. It was a Ruby on Rails (RoR) application running on CentOS with MongoDB. The instances were built using Chef. I specifically picked MongoDB because if it had gotten the volume I had hoped for, a traditional relational database would have performance issues. Unfortunately, I was never able to garner enough interest in using the site so it’s currently shut-down. I’ve even terminated the GCP instances but I am still paying for the domain.

For Employee Empowerment (EmpEmp), I decided to try out Heroku. Like VoteSquared, EmpEmp is built with Ruby on Rails. Heroku requires the use of Postgres. While I’m not fond of the MySQL licensing and stewardship (by Oracle) I had hoped to use it as I didn’t have experience with Postgres. Running Postgres locally is a little more complicated than MySQL. Other developers who have worked on EmpEmp also found Postgres challenging to get running locally.

I found that I was able to get a free (hobby) system running fairly easily. It wasn’t capable of being production quality, but it was good enough to perform user testing.

It was far simpler to set up a production system on Heroku than using IaaS. I was able to quickly configure the production environment to auto-deploy the master branch after Travis tests passed. When, yet again, I was proven naive about how many people would use the website, I was able to downgrade the production database (which was my biggest monthly cost).?

Beyond the database decision, I also stumbled over two other unexpected complexities. First, Heroku requires a Gemfile.lock to pin versions of required gem dependencies. Unfortunately, this means I regularly need to update Gemfile.lock to keep up with security vulnerabilities. Second, you need to specify three digits of the Ruby version in your Gemfile whereas with IaaS you can specify two digits.

Heroku is great for hobby developers, hackathons, and commercial proof-of-concepts as it allows you to quickly and cheaply release your work. Where Heroku fails to compete with IaaS is at scale. If your site becomes popular it will eventually be more expensive than IaaS. Heroku also doesn’t perform as well at scale as IaaS can in part because it’s in less regions. The performance problem is also due to it being a generic service that isn’t fine tuned to your use case.

Azure App Services vs Heroku

Based on the details above it might sound like Azure App Services is superior to Heroku. For ASP.NET, that’s absolutely true. Azure App services also has smooth integration with other Microsoft services like Active Directory.?

For open source, you’ll find Heroku has two advantages:

  • Ease of Use
  • Cost - Heroku is more affordable for projects using open source frameworks

Summary

If you’re building sites with ASP.NET you should absolutely use Azure App Services over IaaS. If you’re building an open source system in the public cloud that can start small, use Heroku.

For more advice and ideas message me on LinkedIn.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了