Hacker News Reader

Comment by avip | Hacker News Reader

First, that's a great stack and very well written/presented.

One comment - he dismisses serverless as being overengineering. I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.

One can see from the snapshot the servers are indeed severely overprovisioned and underutilized. Building an api with api-gateway + lambda is less work than running django in uwsgi behind self-managed nginx, and is guaranteed to be more cost-effective for unpredicted load.

Same logic applies to the db servers - why not hosted?

And last - the inf is a good reminder that prefixing your api routes with /v1, /v2 is always a good habit.

View on HN

Good point! For people who have tons of experience with serverless, serverless is probably a better choice than running servers for some use cases.

As a small business owner, there are two types of cost that I need to consider:

Time: the time I use to do A is the time I can't use to do B. Unfortunately I haven't used serverless so far in my professional career -- in this sense, I'm not full-stack enough :) It takes time for me to learn it, understand it, operate it, and experience various outage scenarios to gain the true learnings. It's more costly for me (probably not for others) to use serverless than the things that I already understand. I'd rather spend more time on other non-engineering things nowadays -- believe it or not, I spend 1/3 of my working hours replying emails :)

Money: the money I spend on A is the money I can't spend on B. I decided not to use api-gateway + lambda & hosted db servers, primarily because of $$$. I actually did the pricing calculation a few times last year. In addition, api-gateway + lambda also require some time for me to learn, which I should use to talk to users, marketing, building new product feature, thinking (yep, thinking also uses some time budget :)...

I used a bit of serverless Javascript (Firebase functions) in a previous startup, and it actually worked really nicely for small self-contained tasks - saving files to S3, triggering customer emails, triggering notifications or webhooks in other services (and ofc in Firebase, actually doing things with the database, but it's not a fit for everything).

Just wanted to add another reason not to use serverless, or at least AWS. For small projects I would rather experience downtime than big invoice. I had a project running on AWS, but it turns out you can't limit the budget, the best you can do is make alerts when costs exceed some limits. I have now moved the project to old-skool server and sleep much better since.

> We need to track the API usage

Thank you for this excellent write-up. Monetizing APIs is always a great topic; did you consider or will you consider using a 3rd party API management service such as RapidAPI or Apigee to keep track and charge for API usage?

Yes. I used rapidapi initially (v1) and built my own api gateway to replace it (v2) earlier this year.

The api was launched in Dec 2017 right here on HN: https://news.ycombinator.com/item?id=15825900

I think your next project should be open source your api gateway so others can monetize their apis too

I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.

I was all gung-ho about serverless for a while. I wanted to release a demo for my product and thought I'd cut through all the hassles of managing my own server.

I found it bewildering. It was a whole new skillset with new benefits, but also new considerations and headaches. When push came to shove and the clock to release my demo started ticking down, I just went back to a linux server.

I use the same linux distro at home and on the server, and there are about 3 technologies I need installed. On retrospect I think I made the right decision, but happy to have my mind changed.

I agree, the key here is that it's best to ship with what you know, rather than what is simplest on paper.

I've yet to find someone explain a serverless API based setup that isn't more complicated than good old fashioned LAMP or equivalent. Serverless seems to always come out more expensive as well.

I've been exploring serverless for a project at work, and this is my conclusion too. It's great that we don't need to manage any servers and can easily deploy tasks with one command - but we already have infrastructure to do all that for that for our existing apps.

For someone starting out you don't need to worry about learning Linux and how to configure Apache to serve SSL certificates in the right way, but that is important to know, unless you are happy to always rely on (and pay for) someone else to do that.

To me serverless is similar to Heroku, it's great for starting out but as you start to grow it's going to quickly become a lot cheaper to maintain you own systems. Except with serverless it's not so easy to self-host because you end up relying on all the tooling the vendor provides.

Depends on what you're familiar with. If he already knows Ansible inside and out, why risk getting stuck with some undebuggable AWS failures?

As a solo entrepreneur I can say time risk is a crucial thing to be mindful of. I'll take 10h +/-1h vs 5h +/- 15h any day.

Not to mention that he might not stick with AWS if he runs the numbers- he might hop ship to a different cloud provider if he gets a better deal. I don't think it's appropriate for such a fledgling enterprise to lock in to AWS-isms so they can keep the change provider cost as low as possible.

Also, people seem to be dismissing the value of a rock-solid local end-to-end dev stack which with the latest iteration of technology I feel has become very complicated and expensive. The OP can run the same Ansible for his dev stack as well as his prod and his dev stack doesn't turn into an AWS bill. Most of the AWS managed tech & services is only reliably testable on AWS at a functional/integration level, which is a cost that a company this small shouldn't have to absorb.

Not sure I agree with the anti-lock in sentiment. It's a nice to have, but if what you know well is AWS or GCP or whatever, definitely lock yourself in.

> Building an api with api-gateway + lambda (...) is guaranteed to be more cost-effective for unpredicted load.

Depends on the use case. I run a cron monitoring service on a similar nginx/uwsgi/django/postgres stack [1]. My service needs to handle lots of really small and simple HTTP requests, and almost every request needs to do a (small and quick) database write. I did napkin math – at the current usage levels, Lambda per-request fees alone would use up significant chunk of my current hosting budget.

[1] https://blog.healthchecks.io/2019/08/a-look-at-healthchecks-...

Someone who has been doing this for years before serverless existed can set up and manage this infrastructure trivially, using almost no time compared to developing the application and the business. It also provides you with security: you know the pitfalls and the problems with hosting these, serverless is another new technology which can go wrong.

Yes, and no. If you already have a lot of experience building apps that run on servers, there's a learning curve to switching to serverless. Is it huge? Not really. But there are certainly pitfalls and best practices to learn about. The costs can be harder to predict, especially when starting out. And the tooling is different (and much less mature). So now you have a bunch of stuff to learn about or consider, or you can just go do the same thing you already know how to do with minimal friction. It's possible that the cost savings of not overprovisioning servers is worth it, but I don't think it's that straightforward of an answer, and if your server costs aren't massive, you might be better of spending your time building a great product than learning a new way to build.

I think, and I'm replying to both above comments, that there's a non-trivial cost reduction + DevOps reduction potential here.

Of course, the overarching rule is always "if it works, don't touch it".

How? His boxes are running at 100%. He might be able save some money by switching to hosted db and maybe run his webservers serverless (and creating some keep-alive triggers).

Nontrivial cost reduction would be switching to a different host instead of aws.

As team of one, you have to be very judicious with your time. You often have to have a philosophy of "if it ain't broke, don't fix it". Yeah they could burn a week or two switching over to lambda and whatnot but is it going to have a higher ROI than all the other things they could be working on?

As me how I know. When I was a solo dev doing my own thing, I'd spend way too much time working on things that really wouldn't affect the business but were "good engineering things" to do. If I spent more time working on things that would grow the business instead of wasting weeks writing fancy deployment scripts, maybe I'd still be doing my own thing now!

> As team of one, you have to be very judicious with your time. You often have to have a philosophy of "if it ain't broke, don't fix it". Yeah they could burn a week or two switching over to lambda and whatnot but is it going to have a higher ROI than all the other things they could be working on?

Timeframe has to be considered. If it only takes a week, I'd strongly suggest biting the bullet. A week's budget can be quickly spent troubleshooting issues, scaling servers up and down, installing software updates, hardening systems and whatnot.

It will most likely be much cheaper to run too. Which, in a single-man operation, may be worthwhile.

Think of it the other way round - if your workload is not realtime, but "within minutes/hours", as in processing feeds here - scaling the worker nodes with an ansible scripts needs to be done on maybe a weekly (if not monthly or less) basis and you get 4/3 instead of 3/3 - for a few minutes of work. This just does not seem to be the workload for autoscaling and adding complexity. I've ran a similar setup at a past job - we planned for whatever but in the end it was one person clicking a few buttons to provision a new instance once in a while.

Also some workloads are really bad for lambda, because you can (total napkin math) run 4 cores at 100% load for 24h a day to do your processing, all at the cost of "1 instance".

If serverless were easier, more people would be using it. But it's not simple or straightforward. You have to learn new systems and conventions, it has a bunch of weird considerations depending on the use case, and most people just use it when they don't want to figure out what instance to run some periodic, one-off job on.

It's a niche, just like all solutions that aren't a single Unix process on a single Unix box. Even CGI scripts are a niche. You pick the niche that you know.

I don't know if overprovisioning servers to counter traffic spikes is over engineering, the mental model is pretty simple. May not be as cost effective or infinitely scalable, but it's simpler to wrap your head around.

I take (very minor) issue with your first line and the point "well written" (I do agree with well presented).

Since the author is reading/commenting here, and there was a large amount of space in the original article outlining tools/services he uses, can I humbly suggest they use a tool like "Grammarly" or similar to help with the word-choice(s)?

Some distracting use of plurals for terms - e.g. "traffics", "stuffs", etc - may have been avoided and other spelling and grammar aspects could have helped make this easier to read. That all being said - the 'essence' of the article is to be commended.

Completely agree. Cloud functions are in many cases a better option than maintaining a server, specially for those background tasks that fire occasionally.

The only issue I've found about using serverless is the database. In most cases (Firebase, Fauna, Cosmos, DynamoDB) you have to couple your stack to the DBaaS provider which is not a great idea. AWS recently announced Amazon Aurora PostgreSQL Serverless but while it allows you to use regular Postgres tools/queries you are again tied to AWS.

One hopes that GraphQL abstractions will enable the decoupling. So if you opt for a database that offers GraphQL natively, it might address the issue. You do have to learn the GraphQL ecosystem (new tools/language etc.)

> lambda is less work than running django in uwsgi behind self-managed nginx

If you discount building an AWS-specific deployment process that includes "pip install" from an AWS linux machine image, zipping the project, and putting it in S3.

You can go copy/paste something like https://circleci.com/blog/deploying-a-serverless-application... and get easy lambda deployments in about 10 minutes.

I think the far better consideration is picking the tech stack that requires learning the least amount of new skills.

The lb, 2 web and 3 api frontends?

You'd also see that 7 of his 8 worker boxes are almost at 100%.

Reply on news.ycombinator.com