9 ms·

> When looking at the cloud resources, we noticed many On-Demand EC2 instances with relatively low CPU utilization, which can be expected considering they don't

> When looking at the cloud resources, we noticed many On-Demand EC2 instances with relatively low CPU utilization, which can be expected considering they don't have customers yet. As a software consultant myself, I'd probably stop the conversation right there and ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers. Still want to be deployed in AWS? Toss the damn app on a single EC2 instance...

whatever1 3y ago
Exactly. Worry about scaling when scaling is in the horizon
- x86x87 3y ago
  No no no. We want to be like Google. Web Scale. Big big data. Huuge
RcouF1uZ4gsC 3y ago
A single EC2 instance with SQLite as the database can get you pretty far.
deleted 3y ago
[deleted]
waffletower 3y ago
And in that case, why ec2, why not a more affordable provider?
- mywittyname 3y ago
  There's a lot of expertise in AWS-land.
  - SparkyMcUnicorn 3y ago
    A DevOps junior should be able to start a VM just about anywhere, and without specialized experience. AWS/GCP/Azure knowledge definitely helps when deploying there, but it's also not really necessary to get something running.
  - ipaddr 3y ago
    There are a lot of salesforce consultants but still would advise to look at other solutions.
- grogenaut 3y ago
  Because I already have an AWS account that bills directly to my credit card along with some other stuff that I'm already paying for. Every time I go down the let me save money route I spend hours reading through CD website reviews for hosting providers without any real understanding of their quality to save a few dollars and end up burning tens of hours of time. Or I could just fire the fucking thing up on AWS and then turn it off if I decide not to work on the project further
- jmholla 3y ago
  Who would you recommend as a more affordable provider?
  - barbariangrunge 3y ago
    I use digital ocean for simple projects. It’s not bad
sigstoat 3y ago
i had a client who was burning… $10k? maybe $20k per month largely on nodes for EKS when they had no paying customers and ~zero load. (they had fully “production” sized clusters in all of their environments, and they had a slew of weird not-quite-prod environments.) they also had some rabbitmq-on-k8s system going that fell over during small tests because they couldn’t get k8s to actually scale it. (which then convinced them they needed k8s, and bigger nodes) sigh
- interroboink 3y ago
  The promise of cloud infrastructure is that it can scale to fit demand — start small, and grow as needed. But sometimes the truth is that it just lets people spend money more easily (: Back in the day, it would have required a whole procedure to buy that hardware, have it set up, etc. Now you can needlessly spend $10k per month with just a few clicks!
  - pnpnp 3y ago
    This is one reason I like serverless. It works for a bunch of cases when you can wrap your head around it, and cost can scale linearly with your growth. At some point, it might make sense to move off for cost reductions, but tools like GCP Cloudrun (deploy dockerized app servers that scale dramatically better than k8s) can be really nice for a small team.
0xEFF 3y ago
A single EC2 instance is an equally bad trade-off on the opposite side of the spectrum from over architected SQS, SNS, etc… The ideal trade off is a single Kubernetes cluster with as much in the cluster as makes sense for the team and stage of the project. As you say, toss the app on a single node to start, but the control plane is tremendously valuable from on the onset of most projects.
- intelthrow6 3y ago
  I don’t see the reasoning. A startup that outgrows an EC2 server will be making enough money to hire more people to scale the system properly than what was initially designed: trading away everything for development velocity. Kubernetes is not the right tool for this startup. Kubernetes is what large, old-school non-tech companies use to orchestrate resources, because it’s easier to find someone that “knows k8s” (no one knows k8s unless they’re consulting) than it is to find someone that can build properly distributed systems (in the eyes of whoever is in charge of hiring).
  - ljm 3y ago
    Is that right? K8S is basically another answer to Conway’s Law. Every startup I’ve worked at switched to it because then the infrastructure could map more closely to the code. Not unlike microservices at a higher level. The old-skool approach is depending on a team of SREs or sysadmins to provision hardware for you and basically handle the deployment, which K8S plus container images basically abstract away. Not to say that dedicating resources to platform development (k8s style) isn’t a time sink when you’re trying to build product and find a fit in the market.
    - intelthrow6 3y ago
      In my experience, giving code preferential treatment is how you end up with complexity lunacy; so I’ll add an addendum to Conway’s Law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure — and which mirrors the skills of its key creators.” K8s is designed to solve Google problems. Your startup will not have Google problems. Your startup will have Pinterest problems, or Gitlab problems, or Reddit problems — at which point you do not need K8s; you need someone who knows infra (which I expect devs to be working on distributed systems to understand). Using K8s in a startup context is a sign of conformist thinking, detached from any critical aspect.
taeric 3y ago
It is rather amusing how over engineered most seed projects have a tendency to be. I do think ddb and lambda hit a sweet spot for costs on ramping up. The rest, though, really struggle.
- mlhpdx 3y ago
  For me, setting up connections between SQS, SNS, DDB, Lambda, step functions, S3, Route53, API Gateway in CloudFormation is just a muscle memory. I’m much faster at it at this point that I am at standing up an EC2. I agree it can be hard to learn, but it certainly isn’t hard to do. Elsewhere in the comments, there’s a suggestion that this kind of thing isn’t appropriate for “hobby projects” and early stage but I disagree. Those are the times when you really want something you can step away from without doing a disservice to your customers (i.e. letting packages go out of date and get vulnerable) and cost you as little as possible in a steady state so you can focus on acquiring customers and not worrying about fuddling around with the guts.
  - fnordpiglet 3y ago
    Your muscles must be tuned to enormous amounts of IAM-fu ;-)
    - mlhpdx 3y ago
      Indeed. One of the hard things to figure out is the keeping the number of roles small while avoiding stars (IAM ain’t GitHub).
      - fnordpiglet 3y ago
        Yes. Stars should be removed frankly. The fact they admit new actions without any review or awareness alone is scary. However IAM isn’t really for humans. It is just really hard to reason about roles programmatically. Some of the new minimal rights discovery from cloud trail analysis leads to an interesting pattern I’ve not seen a lot of : in lower environments permissions are wide open, but a capture of the required roles happens pre-prod and is used and tested against in preprod then promoted to production. This seems like a really useful pattern, and it exposes where your integration tests are incomplete.
ljm 3y ago
I’ve been exploring this lately because, honestly, the cloud is total overkill for small startups and hobby projects. Kubernetes has its value even for small scale workloads like that, but it’s still a few steps more than, say, running a Capistrano script to push your code to a small Linux box with a database on a second one. You’ll get really far on minimal resources these days, especially with cheaper ARM boxes that offer far more bang for your buck. Paying 1k+ a month to AWS/GCP/Azure is total insanity when you’re not even averaging a single active user a day.
- CharlesW 3y ago
  > …the cloud is total overkill for small startups and hobby projects. It absolutely can be, sure. But solutions like Vercel, Cloudflare Workers, Supabase, etc. can be excellent and inexpensive for those use cases.
  - meinheld111 3y ago
    And surely a vivid tech stack does more to make you look good in front of vc‘s than an overkill architecture does make you look incompetent
    - djbusby 3y ago
      IME the investor cares more about Traction that Technology.
      - mejutoco 3y ago
        IDK, I remember seeing a tweet from Paul Graham saying that any new startup should use Typescript (I guess instead of js) so there might be some rules of thumb that some investors follow.
  - mvdtnz 3y ago
    Vercel is a lot of things but I don't think I've ever seen it referred to as "inexpensive".
renewiltord 3y ago
Yeah that's a good starting point. Maybe just docker on those when you have two apps so they don't step on each other.
boredumb 3y ago
This is 100% the line of questioning to pursue.
politician 3y ago
I recently spoke with some folks who declined to invest because our solution was too simple: specifically, the fact that we don't use Kubernetes was a negative signal. That's baffling to me, but that perspective is out there too.
ecshafer 3y ago
With so many developers I feel that there is a complete lack of familiarity with what it takes to just run a website. So many came up in the land of cloud and k8s and etc. There are use cases for these more advanced production environments. But if more developers just learned how to make a website on linux, with a db, a webserver, and an application. They would know that a lot of more complex things just aren't needed... especially when you don't even have customers.
- bamfly 3y ago
  Truly, a very small number of real servers, just enough for blue/green deployments and so you can stay up if any one server goes offline, meets any plausible needs for a really, really high percentage of businesses & products. A ton of early-stage ones can get away with skipping most of that and just run on one or two servers, period, for quite a while. If you're outsourcing operations to AWS or whomever, a couple largish instances and a couple supporting services can get you pretty much that same thing, for a bit more money and a bit less control over performance-consistency. All that HA/scaling/clustering/cloud stuff is expensive, not just in monetary terms, but in performance terms. If you don't actually need it, a high percentage of your compute & (especially) your network traffic may be going to that, rather than actually serving the product. It also adds a hell of a lot of complexity, which comes at a significant time-cost for development, unless you want your defect rate to shoot up. > But if more developers just learned how to make a website on linux, with a db, a webserver, and an application. And hell, nothing's stopping you from writing 12-factor apps and deploying containers, and scripting your server set-up and config, even if you don't go straight for heavy, "scalable" architecture. Even if your server's a beige Linux box in a closet. Enough benefits that the effort's probably a wash at worst (hey, documentation you can execute is the best documentation!) even if you never need to switch architectures, and then you'll have a relatively easy time of it, if you do end up needing to.
  - mistrial9 3y ago
    > just run on one or two servers, period, for quite a while famously, StackOverflow
nemothekid 3y ago
>ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers I think this is one of those things that really depends on the use case. If they are performing expensive inference, I think having any queue is better than no queue. Going from a synchronous system to an asynchronous one is not easy and it's not something you would want anyone to be paged for once it starts to matter. Getting SQS/SNS up and running now could be a couple hours of work today and is practically free if your traffic is low. Similarly I have a number of side projects that run extremely cheaply just using ECS and Fargate. I don't even think about Kubernetes really, it's just a PaaS to me that I'm shipping ARM binaries to. As a result I don't think very hard about autoscaling, failover, load balancing or deployment. A github action just pushes master to ec2 and everything "just works".
dangus 3y ago
Why would you plan not to have customers? Don't you think the company is able to forecast demand for a new product launch? Disney: We'd like to launch a new streaming service. Consultant: Great! You have no customers right now so you can run it on a singleton EC2 instance until you outgrow that scale! Disney: ...We expect 20 million people to sign up in the first week
- Dylan16807 3y ago
  > Don't you think the company is able to forecast demand for a new product launch? I'm pretty sure "follow the forecast" is exactly what motivated that post. In other words, the infrastructure is overkill for the initial forecast of customers. They're not working for Disney.
  - dangus 3y ago
    It wasn't really that the infrastructure was overkill, it was that scalable choices weren't made in the first place. Remember, the comment I replied to said: > As a software consultant myself, I'd probably stop the conversation right there and ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers. Still want to be deployed in AWS? Toss the damn app on a single EC2 instance... But in the article, it's pointed out that SQS and SNS would have been better choices at lower costs for low usage: > When it comes to the application, if I had been involved from scratch, I would have recommended SQS and/or SNS for the message bus, which are free of charge at low utilization. Basically, this company is in a pickle because they didn't have architecture experts from the beginning, and the development team started writing an application without much thought to areas where SRE and DevOps teams often get involved: scaling and cost optimization. Which is another way to say that most startups seem to wait too long to hire DevOps/SRE teams because they are roles considered to be "cost centers:" work that is not directly contributing to the money-making business logic.
justrealist 3y ago
SQS and SNS are a perfectly good primitives for building a robust distributed system that costs $0 when not in use, by triggering compute via Lambda or Batch. Your comment is really pretty ignorant of how these tools interact. Using serverless primitives is the opposite of leaving nodes running for no reason.
HatchedLake721 3y ago
What SQS has to do with EC2? One is a queuing service, the other one is a VM. So instead of using SQS that has $0 cost when there are no customers, you suggest I install, configure and run RabbitMQ on an EC2, to save $0 when there are no customers? Or save $1 when I have 100 customers? SQS is dirt cheap. The point of SQS or any other usage-based AWS _developer_ service compared to DIY is that you can be up and running in minutes at a minuscule cost. I agree with you about over-engineering and building a distributed "microservices" architecture when you have no customers. But I'll pick SQS any time of the day when I need queueing functionality to increase my developer velocity so I can focus on building value rather than wasting my life installing, configuring and running anything on EC2.
- djbusby 3y ago
  The question is: what are queueing for zero customers?
  - sokoloff 3y ago
    You might as well ask “why use a database when you have no customers?”
  - HatchedLake721 3y ago
    If I'm building a marketing automation app that allows customers to do a newsletter blast, I'll put those 1000 email recipients into a queue and run through it at a required pace with a retry interval if anything fails. What do you suggest I do before I get my first customer? - Blast 1000 emails in one go and pray upstream accepts it? - Push these to a database and keep checking it with a CRON? - Run RabbitMQ on an EC2 and push 1000 messages there? - Implement SQS in "15 minutes" at $0 cost?
- Nextgrid 3y ago
  The AMQP protocol alone and its various, good client libraries (compared to terrible AWS SDK which is a very thin abstraction over just sending/parsing raw JSON off the wire) is by itself enough to justify RabbitMQ. > when I need queueing functionality to increase my developer velocity so I can focus on building value rather than wasting my life installing, configuring and running anything on EC2. SQS still requires configuration, which means you either need to use the (terrible) AWS console UI or spin up a whole Terraform/CloudFormation/CDK/etc stack, not to mention that merely connecting to it requires correctly setting up AWS IAM (so you don't use a key that gives access to your entire AWS account). Vim'ing the RabbitMQ config file in contrast doesn't seem so bad, and even just using a static hardcoded password means the worst an attacker can do is take down your queue instead of taking over your entire cloud infra.
alien_ 3y ago
The OP here, thanks for your comment. To be honest I wasn't hired to challenge their entire setup, only to make it more cost effective. So I chose the most straightforward way I could think of that would allow us to come up with a cost effective setup that will be scalable, fault tolerant and simple to maintain later on. It all probably started with such a single instance running Docker compose, but then over time it evolved into this setup. The ideal setup I mentioned would have been also cost effective, scalable and resilient.

whatever1 3y ago

Exactly. Worry about scaling when scaling is in the horizon

x86x87 3y ago
No no no. We want to be like Google. Web Scale. Big big data. Huuge

RcouF1uZ4gsC 3y ago

A single EC2 instance with SQLite as the database can get you pretty far.

deleted 3y ago

[deleted]

waffletower 3y ago

And in that case, why ec2, why not a more affordable provider?

mywittyname 3y ago
There's a lot of expertise in AWS-land.
- SparkyMcUnicorn 3y ago
  A DevOps junior should be able to start a VM just about anywhere, and without specialized experience. AWS/GCP/Azure knowledge definitely helps when deploying there, but it's also not really necessary to get something running.
- ipaddr 3y ago
  There are a lot of salesforce consultants but still would advise to look at other solutions.
grogenaut 3y ago
Because I already have an AWS account that bills directly to my credit card along with some other stuff that I'm already paying for. Every time I go down the let me save money route I spend hours reading through CD website reviews for hosting providers without any real understanding of their quality to save a few dollars and end up burning tens of hours of time. Or I could just fire the fucking thing up on AWS and then turn it off if I decide not to work on the project further
jmholla 3y ago
Who would you recommend as a more affordable provider?
- barbariangrunge 3y ago
  I use digital ocean for simple projects. It’s not bad

sigstoat 3y ago

i had a client who was burning… $10k? maybe $20k per month largely on nodes for EKS when they had no paying customers and ~zero load. (they had fully “production” sized clusters in all of their environments, and they had a slew of weird not-quite-prod environments.) they also had some rabbitmq-on-k8s system going that fell over during small tests because they couldn’t get k8s to actually scale it. (which then convinced them they needed k8s, and bigger nodes) sigh

interroboink 3y ago
The promise of cloud infrastructure is that it can scale to fit demand — start small, and grow as needed. But sometimes the truth is that it just lets people spend money more easily (: Back in the day, it would have required a whole procedure to buy that hardware, have it set up, etc. Now you can needlessly spend $10k per month with just a few clicks!
- pnpnp 3y ago
  This is one reason I like serverless. It works for a bunch of cases when you can wrap your head around it, and cost can scale linearly with your growth. At some point, it might make sense to move off for cost reductions, but tools like GCP Cloudrun (deploy dockerized app servers that scale dramatically better than k8s) can be really nice for a small team.

0xEFF 3y ago

A single EC2 instance is an equally bad trade-off on the opposite side of the spectrum from over architected SQS, SNS, etc… The ideal trade off is a single Kubernetes cluster with as much in the cluster as makes sense for the team and stage of the project. As you say, toss the app on a single node to start, but the control plane is tremendously valuable from on the onset of most projects.

intelthrow6 3y ago
I don’t see the reasoning. A startup that outgrows an EC2 server will be making enough money to hire more people to scale the system properly than what was initially designed: trading away everything for development velocity. Kubernetes is not the right tool for this startup. Kubernetes is what large, old-school non-tech companies use to orchestrate resources, because it’s easier to find someone that “knows k8s” (no one knows k8s unless they’re consulting) than it is to find someone that can build properly distributed systems (in the eyes of whoever is in charge of hiring).
- ljm 3y ago
  Is that right? K8S is basically another answer to Conway’s Law. Every startup I’ve worked at switched to it because then the infrastructure could map more closely to the code. Not unlike microservices at a higher level. The old-skool approach is depending on a team of SREs or sysadmins to provision hardware for you and basically handle the deployment, which K8S plus container images basically abstract away. Not to say that dedicating resources to platform development (k8s style) isn’t a time sink when you’re trying to build product and find a fit in the market.
  - intelthrow6 3y ago
    In my experience, giving code preferential treatment is how you end up with complexity lunacy; so I’ll add an addendum to Conway’s Law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure — and which mirrors the skills of its key creators.” K8s is designed to solve Google problems. Your startup will not have Google problems. Your startup will have Pinterest problems, or Gitlab problems, or Reddit problems — at which point you do not need K8s; you need someone who knows infra (which I expect devs to be working on distributed systems to understand). Using K8s in a startup context is a sign of conformist thinking, detached from any critical aspect.

taeric 3y ago

It is rather amusing how over engineered most seed projects have a tendency to be. I do think ddb and lambda hit a sweet spot for costs on ramping up. The rest, though, really struggle.

mlhpdx 3y ago
For me, setting up connections between SQS, SNS, DDB, Lambda, step functions, S3, Route53, API Gateway in CloudFormation is just a muscle memory. I’m much faster at it at this point that I am at standing up an EC2. I agree it can be hard to learn, but it certainly isn’t hard to do. Elsewhere in the comments, there’s a suggestion that this kind of thing isn’t appropriate for “hobby projects” and early stage but I disagree. Those are the times when you really want something you can step away from without doing a disservice to your customers (i.e. letting packages go out of date and get vulnerable) and cost you as little as possible in a steady state so you can focus on acquiring customers and not worrying about fuddling around with the guts.
- fnordpiglet 3y ago
  Your muscles must be tuned to enormous amounts of IAM-fu ;-)
  - mlhpdx 3y ago
    Indeed. One of the hard things to figure out is the keeping the number of roles small while avoiding stars (IAM ain’t GitHub).
    - fnordpiglet 3y ago
      Yes. Stars should be removed frankly. The fact they admit new actions without any review or awareness alone is scary. However IAM isn’t really for humans. It is just really hard to reason about roles programmatically. Some of the new minimal rights discovery from cloud trail analysis leads to an interesting pattern I’ve not seen a lot of : in lower environments permissions are wide open, but a capture of the required roles happens pre-prod and is used and tested against in preprod then promoted to production. This seems like a really useful pattern, and it exposes where your integration tests are incomplete.

ljm 3y ago

I’ve been exploring this lately because, honestly, the cloud is total overkill for small startups and hobby projects. Kubernetes has its value even for small scale workloads like that, but it’s still a few steps more than, say, running a Capistrano script to push your code to a small Linux box with a database on a second one. You’ll get really far on minimal resources these days, especially with cheaper ARM boxes that offer far more bang for your buck. Paying 1k+ a month to AWS/GCP/Azure is total insanity when you’re not even averaging a single active user a day.

CharlesW 3y ago
> …the cloud is total overkill for small startups and hobby projects. It absolutely can be, sure. But solutions like Vercel, Cloudflare Workers, Supabase, etc. can be excellent and inexpensive for those use cases.
- meinheld111 3y ago
  And surely a vivid tech stack does more to make you look good in front of vc‘s than an overkill architecture does make you look incompetent
  - djbusby 3y ago
    IME the investor cares more about Traction that Technology.
    - mejutoco 3y ago
      IDK, I remember seeing a tweet from Paul Graham saying that any new startup should use Typescript (I guess instead of js) so there might be some rules of thumb that some investors follow.
- mvdtnz 3y ago
  Vercel is a lot of things but I don't think I've ever seen it referred to as "inexpensive".

renewiltord 3y ago

Yeah that's a good starting point. Maybe just docker on those when you have two apps so they don't step on each other.

boredumb 3y ago

This is 100% the line of questioning to pursue.

politician 3y ago

I recently spoke with some folks who declined to invest because our solution was too simple: specifically, the fact that we don't use Kubernetes was a negative signal. That's baffling to me, but that perspective is out there too.

ecshafer 3y ago

With so many developers I feel that there is a complete lack of familiarity with what it takes to just run a website. So many came up in the land of cloud and k8s and etc. There are use cases for these more advanced production environments. But if more developers just learned how to make a website on linux, with a db, a webserver, and an application. They would know that a lot of more complex things just aren't needed... especially when you don't even have customers.

bamfly 3y ago
Truly, a very small number of real servers, just enough for blue/green deployments and so you can stay up if any one server goes offline, meets any plausible needs for a really, really high percentage of businesses & products. A ton of early-stage ones can get away with skipping most of that and just run on one or two servers, period, for quite a while. If you're outsourcing operations to AWS or whomever, a couple largish instances and a couple supporting services can get you pretty much that same thing, for a bit more money and a bit less control over performance-consistency. All that HA/scaling/clustering/cloud stuff is expensive, not just in monetary terms, but in performance terms. If you don't actually need it, a high percentage of your compute & (especially) your network traffic may be going to that, rather than actually serving the product. It also adds a hell of a lot of complexity, which comes at a significant time-cost for development, unless you want your defect rate to shoot up. > But if more developers just learned how to make a website on linux, with a db, a webserver, and an application. And hell, nothing's stopping you from writing 12-factor apps and deploying containers, and scripting your server set-up and config, even if you don't go straight for heavy, "scalable" architecture. Even if your server's a beige Linux box in a closet. Enough benefits that the effort's probably a wash at worst (hey, documentation you can execute is the best documentation!) even if you never need to switch architectures, and then you'll have a relatively easy time of it, if you do end up needing to.
- mistrial9 3y ago
  > just run on one or two servers, period, for quite a while famously, StackOverflow

nemothekid 3y ago

>ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers I think this is one of those things that really depends on the use case. If they are performing expensive inference, I think having any queue is better than no queue. Going from a synchronous system to an asynchronous one is not easy and it's not something you would want anyone to be paged for once it starts to matter. Getting SQS/SNS up and running now could be a couple hours of work today and is practically free if your traffic is low. Similarly I have a number of side projects that run extremely cheaply just using ECS and Fargate. I don't even think about Kubernetes really, it's just a PaaS to me that I'm shipping ARM binaries to. As a result I don't think very hard about autoscaling, failover, load balancing or deployment. A github action just pushes master to ec2 and everything "just works".

dangus 3y ago

Why would you plan not to have customers? Don't you think the company is able to forecast demand for a new product launch? Disney: We'd like to launch a new streaming service. Consultant: Great! You have no customers right now so you can run it on a singleton EC2 instance until you outgrow that scale! Disney: ...We expect 20 million people to sign up in the first week

Dylan16807 3y ago
> Don't you think the company is able to forecast demand for a new product launch? I'm pretty sure "follow the forecast" is exactly what motivated that post. In other words, the infrastructure is overkill for the initial forecast of customers. They're not working for Disney.
- dangus 3y ago
  It wasn't really that the infrastructure was overkill, it was that scalable choices weren't made in the first place. Remember, the comment I replied to said: > As a software consultant myself, I'd probably stop the conversation right there and ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers. Still want to be deployed in AWS? Toss the damn app on a single EC2 instance... But in the article, it's pointed out that SQS and SNS would have been better choices at lower costs for low usage: > When it comes to the application, if I had been involved from scratch, I would have recommended SQS and/or SNS for the message bus, which are free of charge at low utilization. Basically, this company is in a pickle because they didn't have architecture experts from the beginning, and the development team started writing an application without much thought to areas where SRE and DevOps teams often get involved: scaling and cost optimization. Which is another way to say that most startups seem to wait too long to hire DevOps/SRE teams because they are roles considered to be "cost centers:" work that is not directly contributing to the money-making business logic.

justrealist 3y ago

SQS and SNS are a perfectly good primitives for building a robust distributed system that costs $0 when not in use, by triggering compute via Lambda or Batch. Your comment is really pretty ignorant of how these tools interact. Using serverless primitives is the opposite of leaving nodes running for no reason.

HatchedLake721 3y ago

What SQS has to do with EC2? One is a queuing service, the other one is a VM. So instead of using SQS that has $0 cost when there are no customers, you suggest I install, configure and run RabbitMQ on an EC2, to save $0 when there are no customers? Or save $1 when I have 100 customers? SQS is dirt cheap. The point of SQS or any other usage-based AWS _developer_ service compared to DIY is that you can be up and running in minutes at a minuscule cost. I agree with you about over-engineering and building a distributed "microservices" architecture when you have no customers. But I'll pick SQS any time of the day when I need queueing functionality to increase my developer velocity so I can focus on building value rather than wasting my life installing, configuring and running anything on EC2.

djbusby 3y ago
The question is: what are queueing for zero customers?
- sokoloff 3y ago
  You might as well ask “why use a database when you have no customers?”
- HatchedLake721 3y ago
  If I'm building a marketing automation app that allows customers to do a newsletter blast, I'll put those 1000 email recipients into a queue and run through it at a required pace with a retry interval if anything fails. What do you suggest I do before I get my first customer? - Blast 1000 emails in one go and pray upstream accepts it? - Push these to a database and keep checking it with a CRON? - Run RabbitMQ on an EC2 and push 1000 messages there? - Implement SQS in "15 minutes" at $0 cost?
Nextgrid 3y ago
The AMQP protocol alone and its various, good client libraries (compared to terrible AWS SDK which is a very thin abstraction over just sending/parsing raw JSON off the wire) is by itself enough to justify RabbitMQ. > when I need queueing functionality to increase my developer velocity so I can focus on building value rather than wasting my life installing, configuring and running anything on EC2. SQS still requires configuration, which means you either need to use the (terrible) AWS console UI or spin up a whole Terraform/CloudFormation/CDK/etc stack, not to mention that merely connecting to it requires correctly setting up AWS IAM (so you don't use a key that gives access to your entire AWS account). Vim'ing the RabbitMQ config file in contrast doesn't seem so bad, and even just using a static hardcoded password means the worst an attacker can do is take down your queue instead of taking over your entire cloud infra.

alien_ 3y ago

The OP here, thanks for your comment. To be honest I wasn't hired to challenge their entire setup, only to make it more cost effective. So I chose the most straightforward way I could think of that would allow us to come up with a cost effective setup that will be scalable, fault tolerant and simple to maintain later on. It all probably started with such a single instance running Docker compose, but then over time it evolved into this setup. The ideal setup I mentioned would have been also cost effective, scalable and resilient.