5 ms·

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 fo

by avip 7y ago

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.

zippergz 7y ago
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.
- avip 7y ago
  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".
  - jbverschoor 7y ago
    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.
fovc 7y ago
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.
- xemdetia 7y ago
  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.
  - fovc 7y ago
    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.
RX14 7y ago
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.
spookthesunset 7y ago
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!
- outworlder 7y ago
  > 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.
  - wink 7y ago
    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".
cuu508 7y ago
> 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-io-hosting-setup-summer-2019/ https://blog.healthchecks.io/2019/08/a-look-at-healthchecks-...
wenbin 7y ago
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 :)...
- h0h0h0h0111 7y ago
  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).
- Drdrdrq 7y ago
  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.
- hbcondo714 7y ago
  > 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?
pier25 7y ago
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.
- northstar702 7y ago
  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.)
jbverschoor 7y ago
The lb, 2 web and 3 api frontends? You'd also see that 7 of his 8 worker boxes are almost at 100%.
nwsm 7y ago
> 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.
- YawningAngel 7y ago
  You can go copy/paste something like https://circleci.com/blog/deploying-a-serverless-application/ https://circleci.com/blog/deploying-a-serverless-application... and get easy lambda deployments in about 10 minutes.
peterwwillis 7y ago
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.
lacampbell 7y ago
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.
- keyle 7y ago
  I agree, the key here is that it's best to ship with what you know, rather than what is simplest on paper.
- thekingofh 7y ago
  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.
  - fyfy18 7y ago
    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.
seriocomic 7y ago
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.
SPBS 7y ago
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.
chillfox 7y ago
I think the far better consideration is picking the tech stack that requires learning the least amount of new skills.

by avip 7y ago

zippergz 7y ago

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.

avip 7y ago
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".
- jbverschoor 7y ago
  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.

fovc 7y ago

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.

xemdetia 7y ago
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.
- fovc 7y ago
  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.

RX14 7y ago

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.

spookthesunset 7y ago

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!

outworlder 7y ago
> 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.
- wink 7y ago
  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".

cuu508 7y ago

> 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-io-hosting-setup-summer-2019/ https://blog.healthchecks.io/2019/08/a-look-at-healthchecks-...

wenbin 7y ago

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 :)...

h0h0h0h0111 7y ago
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).
Drdrdrq 7y ago
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.
hbcondo714 7y ago
> 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?

pier25 7y ago

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.

northstar702 7y ago
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.)

jbverschoor 7y ago

The lb, 2 web and 3 api frontends? You'd also see that 7 of his 8 worker boxes are almost at 100%.

nwsm 7y ago

> 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.

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

peterwwillis 7y ago

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.

lacampbell 7y ago

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.

keyle 7y ago
I agree, the key here is that it's best to ship with what you know, rather than what is simplest on paper.
thekingofh 7y ago
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.
- fyfy18 7y ago
  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.

seriocomic 7y ago

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.

SPBS 7y ago

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.

chillfox 7y ago

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