Why am I using serverless as a solopreneur
I build my business, goalskeeper.io, with serverless infrastructure. I plan to stay serverless for the long run and not just for POC.
Why using serverless
As a solopreneur, I need to take care of sales, marketing, product, customer support, etc. I have little time to do, so I focus on the main things.
In my case (and most CRUD applications), it's irrelevant whether I use Ruby On Rails or Node.js server SQL or NoSQL database. What is essential is the product itself as the users see and feel it. None of them will care about the tech stack that I'm using.
Benefis using serverless
The main benefit is it's not my server. There is an army of developers whose job is to ensure the service will always be up. There is no need to wake up at night to bring the server up again.
I get secure DB that auto-scale for me (until a specific limit, which I predict I'll be far from it), I get hosting with CDN and SSL certificate, the users' authentication done by the same infrastructure.
I can focus on the product itself, the one thing that will make my users come back.
Drawbacks using serverless
The main drawback is the cost of using the service. If you plan the next unicorn with millions of users, this might kill your business. On the overhand, if you plan dozens of users, you will hardly pay, if at all. I'll not provide free users in goalskeeper.io besides the free trial period.
You are also bound to the tech stack of the serverless provider, but most of the chance, it should not affect you.
Should you use serverless?
If you plan to have up to a few thousand users, serverless is the best option. You trade little cost and the tech stack of the serverless provider with the speed of development and better maintenance.
If you wonder, I'm using Firebase. I have the marketing domain and the app subdomain. I'm using hosting, real-time DB, cloud function, authentication, and analytics.
Nothing stops you from using the best of both worlds. Use Firebase services for your app operation and stream data to traditional databases and storage for analytics and reporting.
Could not possibly agree more. Users couldn't care less about your tech stack. Build something that blows their mind!
I think serverless is great. I use it as-well. Most obvious downsides I've noticed so far:
Hard to manage sometimes (ex. logging, deployment, etc) (I fixed all of these recently by using serverless.com for all my serverless bits)
High risk (These functions need limits or they can potentially run up a huge billing tab)
I build my first product on the Azure serverless stack, I'm still very happy on how everything is running. To combat vendor/ service lock-in, I set up my architecture in way I can easily and quickly migrate the endpoints. If you want check out my product => queris.io
With many serverless offerings, you can usually actually save on cost. The idea is that you only pay for the compute that you use. This is usually better than instead of paying for a VM (or VMs) to be running 24/7, which can get expensive. There are some common workloads, though, that can be more costly in serverless (such as long-running, compute-intensive, batch processing).
With all things though it's good to numerically prove which is better for cost.
100% agree. In theory, people using ec2 and ecs can have autoscaling set up. In practice, not all apps are auto-scalable (high startup times and/or sharp unsustained traffic peaks) in an easy manner so most companies don't do it. They just run excess capacity.
That is the marketing line. In reality, I’ve found it’s usually cheaper to run a VM provisioned to handle many times the peak load 24/7 than it is to use a “serverless” offering. Sometimes 10 or even 100x cheaper.
It’s a simpler dev experience, too.
I am also starting a project using a serverless architecture for many of the reasons @RonenSabag mentions. Has anyone been down this road and regretted it later on? If so, at what point was it?
Why realtime db instead of firestore?
The only reason is I already worked with the real-time DB in the past so when I started naturally I used real-time DB without any thoughts on whether use it or firestore.
it's working pretty well for me
Got it, thanks!
Firestore will make cold starts terrible. Anything that's designed for long-lived connections (or anything with a heavyweight client like firestore) shouldn't be used in serverless context. Stick with stuff like dynamodb, by far the best choice for serverless since they abstract the connection pooling away from you and have a simple http based interface. Dynamodb will spit back a response in <100ms every time, whereas with something like RDS, mongodb atlas, or firestore your cold-starting lambdas will be sitting there for 5+ seconds before returning a response. Dynamodb is really the best way to use serverless with minimal tradeoffs
I think you're talking about cloud functions, not firestore (db). I'm pretty sure firestore doesn't have a cold start problem.
I've been using cloud functions and have 1-2 second cold starts from time to time, but not too worried because once I get enough traffic, it should stay warm almost all the time. Also, in my use case 1-2 seconds isn't a problem.
Serverless is a great choice for prototyping and early products but make sure there are hard limits configured. There is ALWAYS a server and that server has constraints / costs you more during heavy loads (great problem to have).
There are tradeoffs. Serverless is an excellent solution for 1000 paying users of SAAS business. Of course, free users don't make sense, and the cloud functions might have warm-up issues. Conversely, other on-call engineers are responsible for keeping your servers up, and authentication is not your headache.
If your product is a CRUD application and you are not aiming for eight figures, ARR business, serverless is a legit option, especially for solo founders and not just for POC purpose
I have been really wondering about the future of Ruby on Jets. Rails gets me so, so far, so fast, and really lets me keep the velocity high for a long time if I make smart decisions. But I've heard now from some credible people that server less has some significant advantages over Rails/Heroku.
Giving me lots to think about!
In my case, I am using serverless because I prefer not to handle the maintenance of my servers running on Heroku / AWS or any other infrastructure. I'm a solo founder and not planning to scale the team into a big group, so this is my tradeoff as the alternative will be being on call as long as I work on my product.
With serverless, billing might be much higher. For now, I plan a few thousand users at most, so billing will not be so high.
The out-of-the-box dev experience is excellent with serverless, but if you need your custom solution, it might be very complex or even impossible, but in Rails, you can find the right GEM that will help you.
An example here might be authentication. With Rails, you might use Device GEM, and you need to configure it and come up with a way to save the password (or sort of hash from the password). With Firebase, I call to signup or sign methods of the SDK, and they are doing everything for me. But if you want, for example, a single sign-in across multiple subdomains, you have to implement it by yourself without all the good things that Device GEM brings you. I'm not even sure whether I can support SSO (single sign-on) with Firebase, and if it's possible, I'm pretty sure it's tricky.
if you already have a running product, I'm not sure it's worth the migration, but if you are starting a new project and the usage you are planning is not so significant, and the complexity is just CRUD application, serverless can be a great fit for you
Your technical decisions are very relevant to how much progress your customers see you making on your app, its loading time, its reliability, etc, etc, etc.
The technical choices indeed make an impact on the user experience. I claim that serverless can work well in my case and maybe in other cases. Also, when your servers are down affect the user experience
Yes... downtime concerns is a major reason I try to limit 3rd party services. If you're using Firebase, when they're down, you're down. I've seen similar happen with external services at more than one job.
when firebase run on google cloud, if they down google is down, I think a lot of services will go down in such case, not just my service
That's true. They've had downtime several times since my server has, though. I've seen it on IH, with login breaking. The outage is often region-dependent.
i feel like you're not really painting a full picture here. sure serverless architecture allows you to rapidly build functionality. it's efficient and cost-effective up front. but the drawbacks are pretty severe long term. debugging serverless architecture can be tedious and time consuming. serverless functions are event-based. not all my functionality is fired by events. there are limitations from the vendor on exactly how much flexibility you have with what you can do in your serverless functions. and the big one which turned me off of serverless functions ( in the case of firebase ) is the response latency, and warm up. i often recorded response times of over 9 seconds for functions. this is totally unacceptable, and i don't want to hear about writing scripts to keep my functions warm or minimum always-on server counts. its because of these cons (which to me were total show stoppers) i moved to google cloud run. my applications are exponentially more performant, easier to debug and maintain, secure, and iterate with zero to negligible increase to budget.
I was recently hit by ridiculous cold-start times from cloud functions so I migrated to App Engine and things have been much better since (<1s cold starts for the most part)
btw you can keep a minimum number of function instances alive to combat cold starts: https://cloud.google.com/functions/docs/configuring/min-instances
Issue with that is that it costs money to keep an instance constantly on.
meh, you can pretty easily put multiple endpoints under one cloud function to lower the cost: https://medium.com/@savinihemachandra/creating-rest-api-using-express-on-cloud-functions-for-firebase-53f33f22979c
Move a bunch of httpsCallables under a rest endpoint in 1 cloud function and set min instances on that. I think it's something like $3 a month to keep the instance alive to avoid cold starts
Every coin has two sides :-) yes, I'm doing a trade-off here. 10 seconds of cold strat should not affect the users' experience in my case.
Event-based is typical architecture, especially in a microservices environment, so I don't consider it a drawback. Debugging might be challenging, but I have already encountered hard bugs in servers in the past.
My point here is to suggest other solopreneurs who are also developers to check whether it might fit them. The benefits are great. Not being on call is appealing for me.
Worst case, I'll refactor the architecture :-)
I want to believe you here, but I can't.
Your other points are well taken and I am agreeing with you. I only felt that not all cons were covered.
FWIW that level of tradeoff is unnecessary. Just use Dynamodb and node/python and your lambdas will never go above 1sec cold start.
Maybe I'm wrong regarding the 10 seconds will tell. For now, I'm pretty sure it's not affecting the users.
You're right that I didn't write all drawbacks, but any other platforms such as Rails, Node.js, or others have their disadvantages.
I think that building software business on serverless can be a valid option for some companies, and this thought here