Think twice before using Laravel Vapor for your SaaS business

When Vapor was released in Summer 2019 many developers considered it as the all-in-one solution for one of their main issue with developing great software: Hosting it in a scalable and cheap way.

Laravel’s latest commercial product promises to solve this issue in a Laravel-agnostic way: Hosting the project on AWS Lambda and leverage the auto-scaling features of Amazon’s cloud services. But there are issues and limitations with this way of hosting your (profitable) side-business. While I think Laravel Vapor can be an easy and sufficient way hosting your proof of concept project, I discourage using Laravel Vapor for your (active and profitable) business for three reasons.

Vendor Lock-In

First of all Laravel Vapor only works with Amazon’s AWS. While this may not sound like a pitfall at first glance I shortly want to outline why this may be counterproductive in some situations.

The obvious meaning of a vendor lock-in is the fact that you are not able to switch hosting providers as you want, because you committed yourself and your business to a proprietary environment. Running on AWS is fine at the moment but you don’t know what will happen in the next years: Amazon could change their pricing model, deprecate API functionality that is used by Vapor to deploy your project or even discontinue some products of their AWS ecosystem.

From a perspective of a business owner that may want to sell the own business at some time a vendor lock-in could drastically decrease the attractivity of your SaaS project for potential buyers. When you build your project to sell it one day you need to keep your hosting options open, otherwise you’ll choose the technology stack for your future acquirer and this may result in a lower offer.

When running on a standard web-server stack you can design your infrastructure high-available, scalable and reliable. If anything goes wrong at some time you can switch server providers within an hour and you are back online.

Performance

AWS Lambda is fast. Very fast. But you should remember that the whole serverless architectural concept wasn’t initially designed for running whole web applications on top of it.

When serverless became popular, it was primarly (designed to be) used as platform for Functions as a Service (FaaS). A function in this context was meant to execute specific workloads which could be scaled nearly indefinitely. For example: You built a small Python or PHP application that receives a string and builds a QR code from it. The generation of the image would take some reasonable amount of computing power so it’s clever to move the load into a serverless framework in order to just get the results from the function instead of caring about the scalability of the microservice.

Technically a Laravel project is also a function that can be executed on a serverless framework. If not, Vapor would not work at all. But in fact it works and most of the time it even works pretty good and fast. But there were SaaS projects out there in the past that made the experience that using a tailored technical infrastructure can speed things up by multiple times.

When working on Vapor there were even specific changes made to the Laravel Framework just to adjust it to be executable on Amazon’s AWS Lambda.

Centralization

Historically the internet was used to be decentral. With huge cloud providers like Amazon, Google or Microsoft this has changed. A huge amount of percents of all available websites in the world wide web are hosted on those big cloud providers. AWS Lambda is part of this ecosystem.

Today’s classical way of deploying new SaaS projects in the wild seems to be picking one of those big cloud providers, get Cloudflare in front of it and remove any thoughts about the infrastructure from your head afterwards.

In the past we experienced some major outages of Cloudflare and even Amazon AWS and there will always be outages. But the bigger the cloud provider is, the higher is the impact on the digital ecosystem. You don’t want your good-running SaaS to be part of those outages. Take control about your hosting and your application infrastructure; it’s the foundation you build your success on. Don’t just let some piece of third party software handle such crucial parts of your daily income.

Wouldn’t it be nice if your application is still reachable when the next outage occurs?

Conclusion

Vapor works fine. No doubt. But nevertheless I hope that I may have triggered some thinking process if you are currently hosting your SaaS business using it. After all it’s a platform built and made by a highly talented developer. But not by an infrastructural architect nor a cloud specialist. People rely on the service your business provides and you rely on your business as source of income. Don’t neglect the infrastructual part of your SaaS application by shifting the responsibility to some third party application that proclaims to make your life easier. At the end it may make your life even harder.