3 ms·

In my experience you can get pretty far with just a handful of vms and some bash scripts. At least double digit million ARR. Less is more when it comes to devop

In my experience you can get pretty far with just a handful of vms and some bash scripts. At least double digit million ARR. Less is more when it comes to devops tooling imo.

cloudking 2y ago
+1 or just use App Engine, deploy your app and scale
- cglace 2y ago
  App engine deploys are soooo slow. I liked cloud run a lot more.
sanderjd 2y ago
Of course you can get away with that if your metric is revenue. (I think Blippi makes about that much with, I suspect, nary a VM in sight! The question is what you're doing with your infrastructure, not how much revenue you're making. Some things have higher return to "devops" and others have less.
lolinder 2y ago
> you can get pretty far with just a handful of vms and some bash scripts. At least double digit million ARR. Using ARR as the measurement for how far you can scale devops practices is weird to me. Double-digit million ARR might be a few hundred accounts if you're doing B2B, and double-digit million MAUs if you're doing an ad-funded social platform. Depending on how much software is involved your product could be built by a team of anywhere from 1-50 developers. If you're a one-developer B2B company handling 1-3 requests per second you wouldn't even need more than one VM except maybe as redundancy. But if you're the fifty-developer company that's building something beyond simple CRUD, there are a lot of perks that come with a full-fledged control plane that would almost certainly be worth the added cost and complexity.
- marcosdumay 2y ago
  > double-digit million MAUs I was about to make a similar point, but you made the math, and it's holding-up for the GP's side. You can push vms and direct to ssh synchronization up to double-digit million MAU (unless you are using stuff like persistent web-sockets). It won't be pretty, but you can get that far.
  - lolinder 2y ago
    I'm not concerned about handling the requests for the main user-facing application (as you say, you can get way further with a single box than many people think), I'm thinking about all of the additional complexity that comes with serving multiple millions of human users that wouldn't exist if you were just serving a few hundred web scrapers that happen to produce as much traffic as multiple millions of humans. What those sources of complexity are depends a lot on the product, but some examples include admin tooling for your CS department, automated content moderation systems, more thorough logging and monitoring, DDOS mitigation, feature flagging and A/B testing, compliance, etc. Not to mention the overhead of coordinating the work of 50 developers vs 1—deploying over SSH is well and good when you can reasonably expect a small handful of people to need to do it, but automatic deploys from main deployed from a secure build machine is a massive boon to the larger team. Any one of these things has an obvious answer—just add ${software} to your one VM or create one extra bare-metal build server or put your app behind Cloudflare—but when you have a few dozen of these sources of complexity then AWS's control plane offerings start to look very attractive. And once you have 50 developers on the payroll spending a few hundred a month on cloud to avoid hand-rolling solutions isn't exactly a hard sell.
- davedx 2y ago
  > there are a lot of perks that come with a full-fledged control plane that would almost certainly be worth the added cost and complexity. Such as? Logging is more complicated with multi container microservice deployments. Deploying is more complicated. Debugging and error tracing is more difficult. What are the perks?
  - 2y ago
kevin_nisbet 2y ago
I agree, this is an incredibly valid approach for some companies and startups. If you benefit by being frugal and are doing something that doesn't need incredible availability, a rack of servers in a colo doesn't cost much and you can take it pretty far without a huge amount of effort.

In my experience you can get pretty far with just a handful of vms and some bash scripts. At least double digit million ARR. Less is more when it comes to devops tooling imo.

cloudking 2y ago

+1 or just use App Engine, deploy your app and scale

cglace 2y ago
App engine deploys are soooo slow. I liked cloud run a lot more.

sanderjd 2y ago

Of course you can get away with that if your metric is revenue. (I think Blippi makes about that much with, I suspect, nary a VM in sight! The question is what you're doing with your infrastructure, not how much revenue you're making. Some things have higher return to "devops" and others have less.

lolinder 2y ago

> you can get pretty far with just a handful of vms and some bash scripts. At least double digit million ARR. Using ARR as the measurement for how far you can scale devops practices is weird to me. Double-digit million ARR might be a few hundred accounts if you're doing B2B, and double-digit million MAUs if you're doing an ad-funded social platform. Depending on how much software is involved your product could be built by a team of anywhere from 1-50 developers. If you're a one-developer B2B company handling 1-3 requests per second you wouldn't even need more than one VM except maybe as redundancy. But if you're the fifty-developer company that's building something beyond simple CRUD, there are a lot of perks that come with a full-fledged control plane that would almost certainly be worth the added cost and complexity.

marcosdumay 2y ago
> double-digit million MAUs I was about to make a similar point, but you made the math, and it's holding-up for the GP's side. You can push vms and direct to ssh synchronization up to double-digit million MAU (unless you are using stuff like persistent web-sockets). It won't be pretty, but you can get that far.
- lolinder 2y ago
  I'm not concerned about handling the requests for the main user-facing application (as you say, you can get way further with a single box than many people think), I'm thinking about all of the additional complexity that comes with serving multiple millions of human users that wouldn't exist if you were just serving a few hundred web scrapers that happen to produce as much traffic as multiple millions of humans. What those sources of complexity are depends a lot on the product, but some examples include admin tooling for your CS department, automated content moderation systems, more thorough logging and monitoring, DDOS mitigation, feature flagging and A/B testing, compliance, etc. Not to mention the overhead of coordinating the work of 50 developers vs 1—deploying over SSH is well and good when you can reasonably expect a small handful of people to need to do it, but automatic deploys from main deployed from a secure build machine is a massive boon to the larger team. Any one of these things has an obvious answer—just add ${software} to your one VM or create one extra bare-metal build server or put your app behind Cloudflare—but when you have a few dozen of these sources of complexity then AWS's control plane offerings start to look very attractive. And once you have 50 developers on the payroll spending a few hundred a month on cloud to avoid hand-rolling solutions isn't exactly a hard sell.
davedx 2y ago
> there are a lot of perks that come with a full-fledged control plane that would almost certainly be worth the added cost and complexity. Such as? Logging is more complicated with multi container microservice deployments. Deploying is more complicated. Debugging and error tracing is more difficult. What are the perks?
- 2y ago

kevin_nisbet 2y ago

I agree, this is an incredibly valid approach for some companies and startups. If you benefit by being frugal and are doing something that doesn't need incredible availability, a rack of servers in a colo doesn't cost much and you can take it pretty far without a huge amount of effort.