Choosing between PaaS and IaaS is critical. The wrong choice can not only slow down your team from the start, but can cause a spiral into long-term costs as you release more code, build more features, and become more and more embedded in your decision. If you take the time upfront to consider your project’s needs, however, you can make the right choice, saving your team both time and money.
At Ohana, a startup focused on increasing employee engagement, we were under pressure to release a functioning app quickly and on-budget. We carefully considered the benefits of both PaaS and IaaS. In the end, we built and deployed our app with a PaaS provider—Heroku.
Let’s look at why we chose PaaS, and cases when you might instead choose IaaS.
Making the Decision at Ohana
At Ohana, we had several constraints with our app. First, we didn’t have the ability, or desire, to host our own infrastructure on prem, so we knew we wanted to choose either PaaS or IaaS. But which one?
- We had a small dev team with limited experience, both in years and in technical stacks.
- As a typical startup, we had compressed timelines, and a need to create an MVP as quickly as possible.
- Also as a typical startup, we had extremely limited funding.
One of our more senior developers pushed strongly for IaaS. He was extremely technical and loved to be creative in his architectural decisions. He wanted to own as much of the code and architecture as possible. He loved diving into the nitty-gritty of protocols and databases and valued control over everything else.
A different developer felt the opposite and pushed for PaaS. He believed that as a startup, we should be focusing on our business logic—the ideas that made our startup unique. In our case, these were features that only our app offered that would increase employee engagement for our customers. This developer had no interest in configuring environments, managing middleware, or in building basic functionality such as security, user administration, and so on. He valued time and resources over control.
Breaking Down the Benefits
We had several meetings examining when teams should use PaaS, when they should use IaaS, and which one was right for us. Here are the benefits of each that we took into account as we made our decision:
Benefits of PaaS
We found that PaaS projects tend to value speed, reduced complexity, and business logic over technical control. PaaS typically offers teams:
- Faster time to market
- Reduced complexity
- The ability to stay focused on business logic—and therefore the experience of the app—and not the infrastructure
- Apps that are more easily scaled
- Reduced administration and security costs
- Developer-friendly experience (built-in dev-ops and other tools)
- Apps that are consolidated to a common architecture
- Improved quality of service
- Built-in analytics and reporting
- Not getting paged for operational or underlying security problems
Benefits of IaaS
On the other hand, we found that IaaS works well for very technical teams that value control and technical details over convenience. IaaS works well for teams with:
- A true need for fine-grained control over environments (control over efficiency)
- A legacy app that requires the current environment be exactly reproduced
- Requirements for a specific set of tools/environments
- Performance, network, or hardware needs not supported by PaaS
- A need for high-performance computing or big data analysis
Our Decision
In the end, we decided on PaaS. Although it was difficult for our more technical developer to give up control, our final decision came down to several PaaS benefits that outweighed his preference. PaaS gave us:
- Lower cost of deployment
- Fast-as-possible time to market
- Ability to spend our scarce resources on what made us unique
- Overall lowering of risk
While there was a bit of a learning curve (since we were new to the Heroku platform), our decision to go with PaaS worked out well. In just six weeks we deployed an impressive MVP that supported our initial customers’ needs and showcased our differentiators. We were able to focus on creating a product that our customers loved, and where the ancillary tech (such as user management, environments, database connectivity, and so on) just worked. We didn’t spend our spare time “reinventing the wheel.” Heroku also filled in our need for dev-ops, giving us easy builds, deploys, continuous deliveries, app management, scaling, and more.
Conclusion
Developers love to learn. Their job is to understand, build, and create. But often they get caught up in the building, underestimating the value of their time. They are biased towards creating custom solutions, even when those solutions might already exist. Sometimes this is the correct choice, but sometimes a PaaS can help increase efficiency. Understanding your team’s biases, moving past them, and choosing the correct technology is critical. It’s an upfront decision with long-term effects on your costs, performance, hiring decisions, and more.
At Ohana, PaaS was the right choice for our app, but it may not be for yours. Take the time to carefully consider your needs, and the benefits of both technologies.
Oldest comments (0)