9 ms·

It's cool that this stack works for the author, but if anyone is just starting out on their own one-person journey to build a product, I don't think they should

by eric_b 6y ago

It's cool that this stack works for the author, but if anyone is just starting out on their own one-person journey to build a product, I don't think they should follow the stack in this article. There are too many dependencies and too much complexity here. Kubernetes is overkill for 95% of applications, especially single founder SaaS businesses. Clickhouse may make sense for an analytics product but caring and feeding it is non-trivial (see: ZooKeeper dependency and all the problems you get once you move to a distributed database). Most people would be better off with a single beefy machine running Linux, Postgres and whatever web app framework they know. The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles.

triangleman 6y ago
Indeed OP uses this sort of stack in his full time job and has learned about all the kinks over the years, while getting paid to do it! I'm working on a side project and it's literally a bunch of .py files in a folder. Libraries include fastapi and sqlite3. I cannot think of a reason to use container orchestration over a "single beefy machine" in almost any use case.
- mixmastamyk 6y ago
  Side project vs. business with paying customers and bus factor is a different equation.
- sgarland 6y ago
  Not having to recreate your Python env, not having to worry about dependencies (once they're pinned), the ability to run the app on a hosted service like Fargate instead of managing the server...
amzans 6y ago
I agree with you. I wouldn't blindly recommend my stack to everyone, one could argue it's probably even overkill for my SaaS project right now. At this scale I could get away with a couple of $20/mo instances, and call it a day. However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing features. If I wanted to start a new project, I can leverage the same stack and be up and running in minutes. Which means I can take advantage of my cumulative efforts for any future project. It's definitely not for everyone as you said, but it might be a good solution for many :)
- ignoramous 6y ago
  > However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing features. As someone who is mostly in the same boat as you, you have got a strong point in terms of favouring tricks you know best. The amount of code I have had to throwaway made me not want to invest in things that require lots of resources to run and maintain (in other words, things I'd not be comfortable with managing all by myself). I almost always default to managed and serverless products: This won't necessarily be a winning strategy for everyone to say the least as it brings its own complexity to the table. It is pragmatic; however (like you call out), to trade one set of complexities (one that I am comfortable with) for another.
  - amzans 6y ago
    Hey that's great! I think everyone should do what works for them. Using a tool "just because" it worked for others, seems to be what often drives many decisions in this industry. For example, would you go for the 2,200+ microservice architecture from Uber[1] just because they say it solved all their problems? They probably have their reasons, and they are unlikely to be the same as everyone else. I know my stack as a solo founder is unconventional, but it's what has worked best for me. And I'm happy with my choice. If serverless does the trick for you, then focus on that, and keep building the features that your customers actually care about. [1] https://eng.uber.com/microservice-architecture https://eng.uber.com/microservice-architecture
- segmondy 6y ago
  Your stack is great. If anything, I think many one-man SaaS will benefit from using k8s. That's the superpower of k8s, one person can go from 1node to 1000nodes if they need that scaling with minimal effort. Cobbling together shell scripts and tools for one or two servers is just as much work as using k8s, so long as you don't run your own and use a managed service. Best of luck, I think your list is pretty reasonable.
  - blandflakes 6y ago
CraftThatBlock 6y ago
SaaS business single founder here, moved from a mix of GCP's Cloud Run, Cloud SQL, and Compute Engine to DO's managed Postgres and Kubernetes, and it has had the follow effects: - Much cheaper, reducing bill from >100$/month to ~40$. Important for early stage startups - More performance, easier scaling. Found that my application was much better suited to run in K8S, but this is definitely specific to my use-case - Consolidation of resources. Except Postgres/Redis, everything is in my cluster, simplifying management and maintenance For my business, this was a great move, but as others have said, I wouldn't recommend it to everyone. K8S is a great and powerful tool, but also is very complex.
- tebbers 6y ago
  Did you experience the downtime issues with DigitalOcean managed Kubernetes that the author also experienced? I'm also considering DOKS so would be great to know!
  - CraftThatBlock 6y ago
    I had no issues so far, everything has been fairly smooth. Setup was very easy too (was my first cluster setup), and pricing is very good.
  - nrmitchi 6y ago
    Note: source for this information is from discussions with DO via support and the kubernetes slack. I am not affiliated with DO in any way. The downtime issues with DOKS are directly related to the resources allocated to the control plane, which is not set up in a HA capacity. The resources assigned are directly related to the size/number of nodes you use. API-heavy applications can very easy knock out the control plane, and in that situation is takes it a (relatively) long time to recover on it's own (I would typically see ~4hr before it became responsive again). Their support team is able to modify the master resources for a given cluster (to assist with recovery), but the turn-around time on that shouldn't be considered "production ready". At this point my advice for DOKS would be: - Are you using very basic, out-of-the-box Kubernetes to host "apps"? You will probably be fine, but be sure to have a back-up. - Are you planning to use Operators, or anything that heavily interacts with the kube-api? I would recommend not using it, or over-provisioning your cluster (which would very quickly offset the advantage of the "free" managed masters). I know that they are working on fixing some of these reliability issues and I have hopes that it will be more stable shortly. At this time I have a "stable" cluster which (unless their support lied to me) had master resources manually increased by their support team after the 3rd incident of it dying. I haven't had an issue since then.
throwaway894345 6y ago
> The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles. Is this true? At my last company we wasted a bunch of time every week dealing with the accumulation of ad-hoc changes in different environments creating different behavior. When we pivoted to a continuous deployment model (we also moved from EC2 to ECS/Fargate), all of this time went away as did all of the guess-work and fear of deploying to production (because production very rarely deviated from lower environments with respect to behavior, because all environments were reproducible). It also enabled us to stand up whole environments with the press of a button, which made it a lot easier for developers who were interating on infrastructure (we had a lot of async ECS/Lambda workloads). I'm sure if we were smarter or had the right kind of discipline we could have made pet EC2 instances work, but we benefited a lot from moving to cattle/containers. NOTE: I also suspect that cattle/EC2 is a lot harder than cattle/containers, but that may also just my inexperience with the former. I would really like to know how to do reproducible EC2 instances properly, but from the research I've done, it seems like one has to reinvent a good chunk of Kubernetes.
- xmodem 6y ago
  My take would be that once you need another environment than staging+prod, that's the time to move to at the very least move to containers, and probably think very hard about either a hosted Kubernetes or something like Fargate.
- noodle 6y ago
  I think it entirely depends on the path you're taking. For example, I'd disagree with the quoted section you made for a different reason. I'd almost always suggest early stage startups to use something like Heroku (if it works for them), which gives them the ability to pay a small premium in order to never have to spend too much time dealing w/ devops stuff. Pre product-market-fit, that's wasted time/effort unless specific devops needs are essential to getting there.
- treis 6y ago
  You definitely want "one click" deployments from the git go. Then it's just a small tiny step from that to your servers being cattle.
jturpin 6y ago
Setting up Kubernetes is a fixed cost in the beginning with clear payoffs. Things like microk8s, Rancher or GKE/EKS make it a lot easier to set up than it used to be. Deploying your app is then just a simple Helm chart, or another way of getting deployments out. If I was running any kind of business that was making more than zero dollars I would absolutely go with Kubernetes. I don't think it's as complicated as people think at any rate, and it lets you use premade Helm charts which can simplify the deployment of things like Clickhouse.
- ramraj07 6y ago
  No it's not, assuming your database sits outside k8s there's absolutely nothing that needs to be fit inside k8s, a simple machine running docker if needed is more than sufficient. K8s is such a huge mental overhead that if it's not already naturally in your head because you've had extensive experience (or apparently born geniuses) no one with limited tech budget should ever do this.
  - jturpin 6y ago
    All of these tools (Terraform, Kubernetes, Github Actions/Other CI) seem like overkill until a node dies and you need to recreate it, or configuration gets messed up and you don't remember how you deployed it in the first place. It sounds like the OP has had experience with these problems. If these aren't problems you have interest in solving, then Heroku or a similar platform would be the way to go. Running a business on a single node is not advisable. If your scale is that small, or uptime doesn't matter, then sure go with that. If you're running on multiple nodes, you're going to need a way to schedule containers to your cluster one way or another. Scheduling and orchestrating is where complexity get introduced - Kubernetes wrangles this complexity. You can run a lot on a $5 server. I would probably run 3 $10 servers for a small business at least, which feels like still within the realm of a cheap budget for business infrastructure costs. As far as Kubernetes complexity goes, I think this is a self-perpetuating idea on internet tech communities. I don't think it compares to the complexity of actually programming the web apps themselves. There's like 6 resource types you have to be familiar with to work with Kubernetes, and most of that will just be Deployments (where containers actually get scheduled and run, health checks, etc). The others are for configuration and routing.
treis 6y ago
>Most people would be better off with a single beefy machine running Linux, Postgres and whatever web app framework they know The problem is back ups. You've got to figure them out yourself. And there's a decent chance that you do it wrong leading to potentially catastrophic data loss. IMHO, managed DB + S3 equivalent and then doing your own server is the sweet spot. You don't have to worry about data loss and it's still pretty cheap and flexible.
- benbristow 6y ago
  If you're using something like DigitalOcean, you can enable full system backups for 20% of the cost of the 'droplet' (VPS) a month in one-click. Probably quite a safe bet.
  - treis 6y ago
    Seems like that is once a week and not recommended for databases for performance reasons.
kodah 6y ago
Personally, I run a Kubernetes cluster that all my projects go on by default. DigitalOcean hosts mine and my bill is pretty low. I set it up for this exact reason, so I could continue to use my knowledge of containers and container scheduling systems to get easy wins early on.
hasithsen 6y ago
I second this. If what you are familiar with is <stack-that-is-not-cool-by-popular-opinion> but know it would work, go with it. You don't have to struggle with a new tool if something similar is already in your toolbox, and you already have a lot of experience using it. Of course, do this unless you are building to learn (and maybe ship), rather than to just ship. And if the new tool proves to be a better one, you can upgrade then.
Axsuul 6y ago
That's not to say you shouldn't use Kubernetes as a solo founder eventually. Kubernetes does a lot of the devops heavy lifting for you making your job as a solo founder much easier.
BobbyJo 6y ago
Kubernetes honestly isn't that complicated. It's complexity really only scales with the complexity of the system you're running on it. If you're just bringing up a database and a backend on top of it, it's honestly very simple to get running on a single linux box using something like microk8s. And, as a benefit, you can move everything over to EKS or GKE in like a few hours max, if you ever need to scale.
- ownagefool 6y ago
  I think (one of) the big win(s) with k8s is testing in namespaces at a pace that doesn't really slow you down. If you think you'd want to do end2end against an environment entirely built by code, k8s is a really good building block. If you think a one man band and his ruby app can probably go pretty far with self-discipline, but if I'm choosing to do any sort of IaC I'd probably recommend looking at k8s as a) a faster solution, b) a more versatile solution and c) largely vendor agnostic solution. Point being, I'd probably recommend folks learn to use k8s before they invest time learning lambda, EC2, or ECS, but if you're a small team and you already have lambda, EC2, or ECS, and it's working for you, then it's hard to argue for change.
0df8dkdf 6y ago
> There are too many dependencies Agree. Blindly recommend this to anyone is not a good idea! It comes down to author's skill sets, and if the author is truly interested in tech, or just some guy want to implement an idea. Personally I am full stack and know how to make server scale without using Kubernetes. Since I've being using commonJS since it's inception, it is pretty easy to write web apps that scales using a light weight server layer like v8.
redisman 6y ago
I believe 100% that a one-man SaaS needs to leverage their existing knowledge even more than a team. So for me it would be a no-brainer nodejs, dynamo, etc. - the tech I use every day and know in and out. You should have a very good reason to stray from your core if you actually want a business and not just a fun coding challenge.
- danjac 6y ago
  This. You will want to focus on product design, customer acquisition, financing, investment etc etc. These alone are more than enough for a team, let alone one person. You don't want to be wasting your time and energy fixing server issues or obscure browser bugs at 3 am.
bdcravens 6y ago
If Docker is advantageous, then ECS is great alternative to Kubernetes. It gives you most of the benefits in a fully managed offering.
- nickthemagicman 6y ago
  Didn't they recently integrate with docker compose? It looked really cool but I haven't tinkered with it yet.
  - bdcravens 6y ago
    Yes. https://docs.docker.com/engine/context/ecs-integration/ https://docs.docker.com/engine/context/ecs-integration/
    - nickthemagicman 6y ago
      Have you messed with the docker compose integration? Did you like it?
- nullsense 6y ago
  Especially in CDK you can spin up a service in fargate in 5 lines of code with ApplicationLoadBalacedFargateService
bitwize 6y ago
When people bring up "cattle, not pets" I tell the story of my uncle, who runs a small dairy farm in Wisconsin. He has about fifty head of cattle, gave each of them names, and takes care of them when they're sick. Point being that it takes very large scale for the principles people refer to when they say "cattle, not pets" to kick in -- even when you're actually raising cattle. But by the same token, automated reproducible configuration is a huge win whether you have 1 server or 10,000.
mixmastamyk 6y ago
> once you obtain product market fit This phrase assumes a unique product, while many have probably been done before.

by eric_b 6y ago

triangleman 6y ago

Indeed OP uses this sort of stack in his full time job and has learned about all the kinks over the years, while getting paid to do it! I'm working on a side project and it's literally a bunch of .py files in a folder. Libraries include fastapi and sqlite3. I cannot think of a reason to use container orchestration over a "single beefy machine" in almost any use case.

mixmastamyk 6y ago
Side project vs. business with paying customers and bus factor is a different equation.
sgarland 6y ago
Not having to recreate your Python env, not having to worry about dependencies (once they're pinned), the ability to run the app on a hosted service like Fargate instead of managing the server...

amzans 6y ago

I agree with you. I wouldn't blindly recommend my stack to everyone, one could argue it's probably even overkill for my SaaS project right now. At this scale I could get away with a couple of $20/mo instances, and call it a day. However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing features. If I wanted to start a new project, I can leverage the same stack and be up and running in minutes. Which means I can take advantage of my cumulative efforts for any future project. It's definitely not for everyone as you said, but it might be a good solution for many :)

ignoramous 6y ago
> However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing features. As someone who is mostly in the same boat as you, you have got a strong point in terms of favouring tricks you know best. The amount of code I have had to throwaway made me not want to invest in things that require lots of resources to run and maintain (in other words, things I'd not be comfortable with managing all by myself). I almost always default to managed and serverless products: This won't necessarily be a winning strategy for everyone to say the least as it brings its own complexity to the table. It is pragmatic; however (like you call out), to trade one set of complexities (one that I am comfortable with) for another.
- amzans 6y ago
  Hey that's great! I think everyone should do what works for them. Using a tool "just because" it worked for others, seems to be what often drives many decisions in this industry. For example, would you go for the 2,200+ microservice architecture from Uber[1] just because they say it solved all their problems? They probably have their reasons, and they are unlikely to be the same as everyone else. I know my stack as a solo founder is unconventional, but it's what has worked best for me. And I'm happy with my choice. If serverless does the trick for you, then focus on that, and keep building the features that your customers actually care about. [1] https://eng.uber.com/microservice-architecture https://eng.uber.com/microservice-architecture
segmondy 6y ago
Your stack is great. If anything, I think many one-man SaaS will benefit from using k8s. That's the superpower of k8s, one person can go from 1node to 1000nodes if they need that scaling with minimal effort. Cobbling together shell scripts and tools for one or two servers is just as much work as using k8s, so long as you don't run your own and use a managed service. Best of luck, I think your list is pretty reasonable.
- blandflakes 6y ago

CraftThatBlock 6y ago

SaaS business single founder here, moved from a mix of GCP's Cloud Run, Cloud SQL, and Compute Engine to DO's managed Postgres and Kubernetes, and it has had the follow effects: - Much cheaper, reducing bill from >100$/month to ~40$. Important for early stage startups - More performance, easier scaling. Found that my application was much better suited to run in K8S, but this is definitely specific to my use-case - Consolidation of resources. Except Postgres/Redis, everything is in my cluster, simplifying management and maintenance For my business, this was a great move, but as others have said, I wouldn't recommend it to everyone. K8S is a great and powerful tool, but also is very complex.

tebbers 6y ago
Did you experience the downtime issues with DigitalOcean managed Kubernetes that the author also experienced? I'm also considering DOKS so would be great to know!
- CraftThatBlock 6y ago
  I had no issues so far, everything has been fairly smooth. Setup was very easy too (was my first cluster setup), and pricing is very good.
- nrmitchi 6y ago
  Note: source for this information is from discussions with DO via support and the kubernetes slack. I am not affiliated with DO in any way. The downtime issues with DOKS are directly related to the resources allocated to the control plane, which is not set up in a HA capacity. The resources assigned are directly related to the size/number of nodes you use. API-heavy applications can very easy knock out the control plane, and in that situation is takes it a (relatively) long time to recover on it's own (I would typically see ~4hr before it became responsive again). Their support team is able to modify the master resources for a given cluster (to assist with recovery), but the turn-around time on that shouldn't be considered "production ready". At this point my advice for DOKS would be: - Are you using very basic, out-of-the-box Kubernetes to host "apps"? You will probably be fine, but be sure to have a back-up. - Are you planning to use Operators, or anything that heavily interacts with the kube-api? I would recommend not using it, or over-provisioning your cluster (which would very quickly offset the advantage of the "free" managed masters). I know that they are working on fixing some of these reliability issues and I have hopes that it will be more stable shortly. At this time I have a "stable" cluster which (unless their support lied to me) had master resources manually increased by their support team after the 3rd incident of it dying. I haven't had an issue since then.

throwaway894345 6y ago

> The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles. Is this true? At my last company we wasted a bunch of time every week dealing with the accumulation of ad-hoc changes in different environments creating different behavior. When we pivoted to a continuous deployment model (we also moved from EC2 to ECS/Fargate), all of this time went away as did all of the guess-work and fear of deploying to production (because production very rarely deviated from lower environments with respect to behavior, because all environments were reproducible). It also enabled us to stand up whole environments with the press of a button, which made it a lot easier for developers who were interating on infrastructure (we had a lot of async ECS/Lambda workloads). I'm sure if we were smarter or had the right kind of discipline we could have made pet EC2 instances work, but we benefited a lot from moving to cattle/containers. NOTE: I also suspect that cattle/EC2 is a lot harder than cattle/containers, but that may also just my inexperience with the former. I would really like to know how to do reproducible EC2 instances properly, but from the research I've done, it seems like one has to reinvent a good chunk of Kubernetes.

xmodem 6y ago
My take would be that once you need another environment than staging+prod, that's the time to move to at the very least move to containers, and probably think very hard about either a hosted Kubernetes or something like Fargate.
noodle 6y ago
I think it entirely depends on the path you're taking. For example, I'd disagree with the quoted section you made for a different reason. I'd almost always suggest early stage startups to use something like Heroku (if it works for them), which gives them the ability to pay a small premium in order to never have to spend too much time dealing w/ devops stuff. Pre product-market-fit, that's wasted time/effort unless specific devops needs are essential to getting there.
treis 6y ago
You definitely want "one click" deployments from the git go. Then it's just a small tiny step from that to your servers being cattle.

jturpin 6y ago

Setting up Kubernetes is a fixed cost in the beginning with clear payoffs. Things like microk8s, Rancher or GKE/EKS make it a lot easier to set up than it used to be. Deploying your app is then just a simple Helm chart, or another way of getting deployments out. If I was running any kind of business that was making more than zero dollars I would absolutely go with Kubernetes. I don't think it's as complicated as people think at any rate, and it lets you use premade Helm charts which can simplify the deployment of things like Clickhouse.

ramraj07 6y ago
No it's not, assuming your database sits outside k8s there's absolutely nothing that needs to be fit inside k8s, a simple machine running docker if needed is more than sufficient. K8s is such a huge mental overhead that if it's not already naturally in your head because you've had extensive experience (or apparently born geniuses) no one with limited tech budget should ever do this.
- jturpin 6y ago
  All of these tools (Terraform, Kubernetes, Github Actions/Other CI) seem like overkill until a node dies and you need to recreate it, or configuration gets messed up and you don't remember how you deployed it in the first place. It sounds like the OP has had experience with these problems. If these aren't problems you have interest in solving, then Heroku or a similar platform would be the way to go. Running a business on a single node is not advisable. If your scale is that small, or uptime doesn't matter, then sure go with that. If you're running on multiple nodes, you're going to need a way to schedule containers to your cluster one way or another. Scheduling and orchestrating is where complexity get introduced - Kubernetes wrangles this complexity. You can run a lot on a $5 server. I would probably run 3 $10 servers for a small business at least, which feels like still within the realm of a cheap budget for business infrastructure costs. As far as Kubernetes complexity goes, I think this is a self-perpetuating idea on internet tech communities. I don't think it compares to the complexity of actually programming the web apps themselves. There's like 6 resource types you have to be familiar with to work with Kubernetes, and most of that will just be Deployments (where containers actually get scheduled and run, health checks, etc). The others are for configuration and routing.

treis 6y ago

>Most people would be better off with a single beefy machine running Linux, Postgres and whatever web app framework they know The problem is back ups. You've got to figure them out yourself. And there's a decent chance that you do it wrong leading to potentially catastrophic data loss. IMHO, managed DB + S3 equivalent and then doing your own server is the sweet spot. You don't have to worry about data loss and it's still pretty cheap and flexible.

benbristow 6y ago
If you're using something like DigitalOcean, you can enable full system backups for 20% of the cost of the 'droplet' (VPS) a month in one-click. Probably quite a safe bet.
- treis 6y ago
  Seems like that is once a week and not recommended for databases for performance reasons.

kodah 6y ago

Personally, I run a Kubernetes cluster that all my projects go on by default. DigitalOcean hosts mine and my bill is pretty low. I set it up for this exact reason, so I could continue to use my knowledge of containers and container scheduling systems to get easy wins early on.

hasithsen 6y ago

I second this. If what you are familiar with is <stack-that-is-not-cool-by-popular-opinion> but know it would work, go with it. You don't have to struggle with a new tool if something similar is already in your toolbox, and you already have a lot of experience using it. Of course, do this unless you are building to learn (and maybe ship), rather than to just ship. And if the new tool proves to be a better one, you can upgrade then.

Axsuul 6y ago

That's not to say you shouldn't use Kubernetes as a solo founder eventually. Kubernetes does a lot of the devops heavy lifting for you making your job as a solo founder much easier.

BobbyJo 6y ago

Kubernetes honestly isn't that complicated. It's complexity really only scales with the complexity of the system you're running on it. If you're just bringing up a database and a backend on top of it, it's honestly very simple to get running on a single linux box using something like microk8s. And, as a benefit, you can move everything over to EKS or GKE in like a few hours max, if you ever need to scale.

ownagefool 6y ago
I think (one of) the big win(s) with k8s is testing in namespaces at a pace that doesn't really slow you down. If you think you'd want to do end2end against an environment entirely built by code, k8s is a really good building block. If you think a one man band and his ruby app can probably go pretty far with self-discipline, but if I'm choosing to do any sort of IaC I'd probably recommend looking at k8s as a) a faster solution, b) a more versatile solution and c) largely vendor agnostic solution. Point being, I'd probably recommend folks learn to use k8s before they invest time learning lambda, EC2, or ECS, but if you're a small team and you already have lambda, EC2, or ECS, and it's working for you, then it's hard to argue for change.

0df8dkdf 6y ago

> There are too many dependencies Agree. Blindly recommend this to anyone is not a good idea! It comes down to author's skill sets, and if the author is truly interested in tech, or just some guy want to implement an idea. Personally I am full stack and know how to make server scale without using Kubernetes. Since I've being using commonJS since it's inception, it is pretty easy to write web apps that scales using a light weight server layer like v8.

redisman 6y ago

I believe 100% that a one-man SaaS needs to leverage their existing knowledge even more than a team. So for me it would be a no-brainer nodejs, dynamo, etc. - the tech I use every day and know in and out. You should have a very good reason to stray from your core if you actually want a business and not just a fun coding challenge.

danjac 6y ago
This. You will want to focus on product design, customer acquisition, financing, investment etc etc. These alone are more than enough for a team, let alone one person. You don't want to be wasting your time and energy fixing server issues or obscure browser bugs at 3 am.

bdcravens 6y ago

If Docker is advantageous, then ECS is great alternative to Kubernetes. It gives you most of the benefits in a fully managed offering.

nickthemagicman 6y ago
Didn't they recently integrate with docker compose? It looked really cool but I haven't tinkered with it yet.
- bdcravens 6y ago
  Yes. https://docs.docker.com/engine/context/ecs-integration/ https://docs.docker.com/engine/context/ecs-integration/
  - nickthemagicman 6y ago
    Have you messed with the docker compose integration? Did you like it?
nullsense 6y ago
Especially in CDK you can spin up a service in fargate in 5 lines of code with ApplicationLoadBalacedFargateService

bitwize 6y ago

When people bring up "cattle, not pets" I tell the story of my uncle, who runs a small dairy farm in Wisconsin. He has about fifty head of cattle, gave each of them names, and takes care of them when they're sick. Point being that it takes very large scale for the principles people refer to when they say "cattle, not pets" to kick in -- even when you're actually raising cattle. But by the same token, automated reproducible configuration is a huge win whether you have 1 server or 10,000.

mixmastamyk 6y ago

> once you obtain product market fit This phrase assumes a unique product, while many have probably been done before.