4 ms·

Labor cost to maintain is far more than the service cost for a small startup, most of the time you can get by on the free tiers for quite some time. Founders ne

by hkchad 5y ago

Labor cost to maintain is far more than the service cost for a small startup, most of the time you can get by on the free tiers for quite some time. Founders need to focus time/energy on what adds value, not updating services.

cersa8 5y ago
This idea that you need a ton of money to maintain self hosted servers is not true. You may have to update to a new OS or software major version at some point in time, but in the meantime things can pretty much auto-security-update for the distribution provided version until you gain traction with your startup.
- deleted 5y ago
  [deleted]
quesera 5y ago
> Labor cost to maintain is far more than the service cost for a small startup This is the common wisdom which is correct in many cases, but not all. If you have a decent systems/infrastructure person in your startup, the incremental cost of running a lot of these kinds of services is effectively zero. If you are bootstrapped, this can be financially significant. Most startups do not need a decent infra person on day one, and no one would recommend hiring one for this purpose. But if someone on the team has the skills, it can make a ton of sense to leverage them. I think it's good to help people obtain these skills which add value to (or at least save money for) their project, and correspondingly enable more people to start up in the first place.
- raffraffraff 5y ago
  Very real example coming up. I was one of 3 engineers with a "day one" start-up just over 2 years ago. I was dedicated to infrastructure, and have experience with hardware > OS > config management > orchestration > CICD > monitoring. I've deployed hashicorp stack and Kubernetes. I've managed in-house services like gitlab, database clusters, metrics/logs solutions, Jenkins etc. I've also managed firewalls and I'm rusty on switches etc but I've done that too. At the start-up we ran nothing ourselves, except the gitlab runners. (Well, except for the first month where a bunch of laptops are used to prototype the app). I spent my first year writing terraform and helping design the product for low-cost scalability. So much of what we did for that whole year was in the free tier that our runway money could cover team building. 1 year in, I could deploy our entire stack from scratch into a new region in under an hour. VPC, subnets, security rules, IAM, queues, workers, Kubernetes cluster with autoscaling nodes, databases, DNS, CDN, monitoring, metrics, email (AWS SES)... That type of fast deployability to a new region shouldn't be a late consideration after you've spent a year tinkering with in-house stuff. In fact, getting to another round of funding requires that you have that stuff ironed out. Can you support FedRAMP requirements? Yes, because that was a day one consideration. How about GDPR? Ditto. Do you have separate dev, test and prod environments which are identical apart from scale/cost? Yep! Right now I'm working with a company that built everything in-house, from the perspective of "one single data center". It's a disaster. If you're not thinking at scale from the start, your probably not doing basic stuff like proper naming conventions, non-clashing CIDR. They're using all the right tools, but badly. Their terraform is a mess because it was obviously introduced it gradually on top of existing "snowflake" infrastructure. Their next data center was pretty much copy-paste followed by a thousand changes. And their code coverage is low - lots of stuff still manually created. (This is a known company with a decent product and lots of customers!). All of the people hired to try to make it scalable after the fact are saying things like "...it would be easier to just throw it all out and start over". The problem with doing things badly because you think you can improve it later is that suddenly you've got customers on this thing, and you can't start over.

by hkchad 5y ago

cersa8 5y ago

This idea that you need a ton of money to maintain self hosted servers is not true. You may have to update to a new OS or software major version at some point in time, but in the meantime things can pretty much auto-security-update for the distribution provided version until you gain traction with your startup.

deleted 5y ago
[deleted]

quesera 5y ago

> Labor cost to maintain is far more than the service cost for a small startup This is the common wisdom which is correct in many cases, but not all. If you have a decent systems/infrastructure person in your startup, the incremental cost of running a lot of these kinds of services is effectively zero. If you are bootstrapped, this can be financially significant. Most startups do not need a decent infra person on day one, and no one would recommend hiring one for this purpose. But if someone on the team has the skills, it can make a ton of sense to leverage them. I think it's good to help people obtain these skills which add value to (or at least save money for) their project, and correspondingly enable more people to start up in the first place.

raffraffraff 5y ago
Very real example coming up. I was one of 3 engineers with a "day one" start-up just over 2 years ago. I was dedicated to infrastructure, and have experience with hardware > OS > config management > orchestration > CICD > monitoring. I've deployed hashicorp stack and Kubernetes. I've managed in-house services like gitlab, database clusters, metrics/logs solutions, Jenkins etc. I've also managed firewalls and I'm rusty on switches etc but I've done that too. At the start-up we ran nothing ourselves, except the gitlab runners. (Well, except for the first month where a bunch of laptops are used to prototype the app). I spent my first year writing terraform and helping design the product for low-cost scalability. So much of what we did for that whole year was in the free tier that our runway money could cover team building. 1 year in, I could deploy our entire stack from scratch into a new region in under an hour. VPC, subnets, security rules, IAM, queues, workers, Kubernetes cluster with autoscaling nodes, databases, DNS, CDN, monitoring, metrics, email (AWS SES)... That type of fast deployability to a new region shouldn't be a late consideration after you've spent a year tinkering with in-house stuff. In fact, getting to another round of funding requires that you have that stuff ironed out. Can you support FedRAMP requirements? Yes, because that was a day one consideration. How about GDPR? Ditto. Do you have separate dev, test and prod environments which are identical apart from scale/cost? Yep! Right now I'm working with a company that built everything in-house, from the perspective of "one single data center". It's a disaster. If you're not thinking at scale from the start, your probably not doing basic stuff like proper naming conventions, non-clashing CIDR. They're using all the right tools, but badly. Their terraform is a mess because it was obviously introduced it gradually on top of existing "snowflake" infrastructure. Their next data center was pretty much copy-paste followed by a thousand changes. And their code coverage is low - lots of stuff still manually created. (This is a known company with a decent product and lots of customers!). All of the people hired to try to make it scalable after the fact are saying things like "...it would be easier to just throw it all out and start over". The problem with doing things badly because you think you can improve it later is that suddenly you've got customers on this thing, and you can't start over.