Stop Doing Cloud(grski.pl)
grski.pl
Stop Doing Cloud
https://grski.pl/self-host
123 comments
100% spot on. You can tell this is written by an IC engineer and not a manager/director who would be well aware of the resource costs of doing all of the manual install/configuration work outlined in the article.
Having been in both positions, my experience is that a whole lot of the idea that cloud is "cheaper" comes from people without awareness on how much of a commodity the skill set to set up and manage non-cloud setups is. You can reduce this all to predictable monthly bills scalable up and down by small fractions of headcount with ease most places.
At the very small scale when trying to start something, do what you're comfortable with, because whatever you're not is likely to cost you time.
Above that, it's down to what your margins are like, and how large a part the hosting is, but it's rare for cloud to be the cheaper option. Certainly not at list prices - while you're small enough to pay list prices you're being screwed over massively.
At the very small scale when trying to start something, do what you're comfortable with, because whatever you're not is likely to cost you time.
Above that, it's down to what your margins are like, and how large a part the hosting is, but it's rare for cloud to be the cheaper option. Certainly not at list prices - while you're small enough to pay list prices you're being screwed over massively.
> how much of a commodity the skill set to set up and manage non-cloud setups is.
So many little teams actually managing non-cloud setups
"Commodity" ? Not here
Yes, commodity. That doesn't mean anyone bothered to hire for that skill at your employers, but you can go out and hire this skill by the hour from any number of providers.
The same problem of teams lacking ops skills exists in companies doing cloud stuff too - often because they've bought the fiction that cloud doesn't need devops.
The same problem of teams lacking ops skills exists in companies doing cloud stuff too - often because they've bought the fiction that cloud doesn't need devops.
Not necessarily. Professional managers can overvalue managed service because they perceive scarcity of skilled resources. Cloud and managed services has an overall negative effect on engineers ability to develop talent thereby exacerbating the scarcity issue. It’s actually harmful for managers as well… over time we’ll need less of them too (since they outsourced part of the job of managing).
Or even an IC that is new to setting up infra and so they relish it. Do it a couple of times and you start appreciating managed solutions
After spending a lot of my time doing both, I can offer some perspective on that. It's not that I disagree, and many people feel the same as you, but very often it results from underestimating the time, experience and knowledge needed to create a secure and efficient cloud environment. Also, RDS makes many things easier for you (but also less flexible), but some things can't be automated and still require manual intervention like major version upgrades.
Same. I love RDS. It's amazingly convenient and I use it when I can justify it. It's also really expensive and I can - and have - easily build postgres setups w/replication across multiple data centers in several countries and still come out cheaper (including time spent) than anything remotely similar capacity in RDS. It's not hard, but it's more work than me, and so I'm happy to let AWS do it when I work somewhere where we can afford it.
Cloud has a role many places, but not in setups that are cost sensitive at scale.
Cloud has a role many places, but not in setups that are cost sensitive at scale.
"The cloud isn't cheaper than running your own infra, but it's sure as hell cheaper than running your own infra + paying someone to help you run it."
Two different things: 1. infrastructure (computers) and 2. running the infrastructure (running the computers)
Obviously, purchasing computers is more expensive that not purchasing them, i.e., using someone else's computers. The later is known, in marketing terms, as "cloud computing".
The remaining question is whether (a) paying for running own computers is less or more expensive than (b) paying for running someone else's computers, i.e., cloud computing. Or whether the costs are the same.
For some, the fundamental problem posed by "cloud computing" is not the cost. It is the fact that "the cloud" is someone else's computers. Handling data that does not belong to them. In some cases having customers share the same computers with each other.
Two different things: 1. infrastructure (computers) and 2. running the infrastructure (running the computers)
Obviously, purchasing computers is more expensive that not purchasing them, i.e., using someone else's computers. The later is known, in marketing terms, as "cloud computing".
The remaining question is whether (a) paying for running own computers is less or more expensive than (b) paying for running someone else's computers, i.e., cloud computing. Or whether the costs are the same.
For some, the fundamental problem posed by "cloud computing" is not the cost. It is the fact that "the cloud" is someone else's computers. Handling data that does not belong to them. In some cases having customers share the same computers with each other.
>Yes it is cheaper to run all this stuff yourself on a VPS but you still "pay" for those things with your time.
There's also liability. If you pay someone for services rendered, you can throw liability on them. If you run stuff yourself, you're liable.
Data breach at <cloud> for your services? Hang them out to dry. Data breach on your own server? You're fucked.
There's also liability. If you pay someone for services rendered, you can throw liability on them. If you run stuff yourself, you're liable.
Data breach at <cloud> for your services? Hang them out to dry. Data breach on your own server? You're fucked.
Unless you're huge, you'll find most providers will limit their liability to the cost of the service, which is usually a rounding error of your risk.
If you think you're covered in any meaningful way with a standard contract, you most likely didn't read their terms.
If liability is a concern, you need insurance.
If you think you're covered in any meaningful way with a standard contract, you most likely didn't read their terms.
If liability is a concern, you need insurance.
I'll believe it when I see it. There are major security breaches every year, and I have never heard any company get fined or taking any responsibility. If LastPass and Okta can get away with leaking passwords, then google (or any other cloud provider) can get away with absolutely anything.
This article doesn't offer any compelling argument IMO. When you are a startup you have to focus on getting to PMF, it doesn't matter that you spend more for managed services. In fact your time is much better spend building your service and iterating faster than dealing with server updates, backups, high availability, etc, etc.
I dunno ... been there done the startup thing.
Had we not gone with k8s and just gone with a vm -- even without docker compose -- but just a monolith we'd have been 1000% further along than when I left.
Even doing everything cloud native means learning how to package your stuff for that provider and go through their docs, learn their idosyncracies, etc.
BUT!!!!
Let's say you hire a kid whose been tinkering with servers in their room since they were teens and know their way around a Linux distro and can package python and run a proxy etc etc
There's a lot of compelling reason to simplify the tech stack and cloud/k8s/etc makes sense only when the scale requires it.
---
That being said -- Hetzner is not the panacea its pricing might suggest. We run our self hosted gitlab on it and we've had 2-3 incidents in the last month that required them to either power cycle a machine or fix some networking thing etc etc. I kinda expected more. But it's hella cheap: where else will you find so much hardware for 200 a month.
Had we not gone with k8s and just gone with a vm -- even without docker compose -- but just a monolith we'd have been 1000% further along than when I left.
Even doing everything cloud native means learning how to package your stuff for that provider and go through their docs, learn their idosyncracies, etc.
BUT!!!!
Let's say you hire a kid whose been tinkering with servers in their room since they were teens and know their way around a Linux distro and can package python and run a proxy etc etc
There's a lot of compelling reason to simplify the tech stack and cloud/k8s/etc makes sense only when the scale requires it.
---
That being said -- Hetzner is not the panacea its pricing might suggest. We run our self hosted gitlab on it and we've had 2-3 incidents in the last month that required them to either power cycle a machine or fix some networking thing etc etc. I kinda expected more. But it's hella cheap: where else will you find so much hardware for 200 a month.
Why did a startup need to manage K8s? Why does using the cloud preclude a monolith?
My app is a stateless monolith hosted with Fargate and RDS. I don't have to think about K8s, or look at it, or know how it works.
The pricing is relatively garbage, but it doesn't matter: now I don't have to think about devops as a concept.
I don't get how people are screwing up this cloud thing: it's as simple as you make it. Being pennywise and pound foolish trying to engineer complex solutions on the "cheaper" parts of cloud providers makes absolutely zero sense to me.
9 times out of 10 you hear X startup paying stupidly expensive bills it's because they tried to build out something that the cloud provider would have provided with a 50% markup but with an architecture you can't screw up.
My app is a stateless monolith hosted with Fargate and RDS. I don't have to think about K8s, or look at it, or know how it works.
The pricing is relatively garbage, but it doesn't matter: now I don't have to think about devops as a concept.
I don't get how people are screwing up this cloud thing: it's as simple as you make it. Being pennywise and pound foolish trying to engineer complex solutions on the "cheaper" parts of cloud providers makes absolutely zero sense to me.
9 times out of 10 you hear X startup paying stupidly expensive bills it's because they tried to build out something that the cloud provider would have provided with a 50% markup but with an architecture you can't screw up.
> Why did a startup need to manage K8s? Why does using the cloud preclude a monolith?
Because we were dumb and thought k8s meant we had to go microservices.
> if the app can fit on a single VM …
Well of course. If and when it out grows the vm hopefully you’ve found product market fit and are bootstrapped and making money and have hired proper platform and dev teams to do it right and the single VM PoC is redone.
Or so that is what we are sold. In reality things happen piece-meal and more chaotically.
Because we were dumb and thought k8s meant we had to go microservices.
> if the app can fit on a single VM …
Well of course. If and when it out grows the vm hopefully you’ve found product market fit and are bootstrapped and making money and have hired proper platform and dev teams to do it right and the single VM PoC is redone.
Or so that is what we are sold. In reality things happen piece-meal and more chaotically.
Yeah, we've got the GCP equivalent with a monolith running on Cloud Run, Cloud SQL, Cloud Load Balancer, and a few misc services that are pennies per month (Tasks, Scheduler, Secrets Manager, Cloud Build, etc). Scales elastically, all kinds of niceties around security, backups, observability, zero downtime deployments, preview environments, etc. that required basically no work from us to build. Handles a lot of traffic for cost that's in the range of hundreds per month. Devs spend basically no time on any of that after the initial setup and can focus entirely on development. I could build all of that out on some VMs or hardware (I've done all that stuff in the past, racking servers, managing Xen, DRBD, database clusters, etc) and probably save a little bit of money, but nowhere near enough to justify all the extra time and distraction. If we outgrow Cloud Run, it's an easy path to GKE or if we grow to where the cost is worth staffing out, it could all run on VMs or hardware without significant changes. In the meantime, I'm not worrying about NICs failing, OS packages needing to be patched, and so on.
Yeah. That’s why I love building on GCP: things just work so nicely together and there’s far fewer foot guns than AWS
[deleted]
If your entire application fits in one VM forever - fair enough.
If you're running a whole fleet of VMs and need to manage them the pain of doing that is quickly going to exceed the "pain" of using k8s. Do you need something like k8s ingress? Do you need the ability to move workloads if a machine goes down? certs? external-dns? Are you going to deploying tooling that's available off the shelf for k8s? (lessay Prometheus/Grafana?). VMs have overhead and likely waste a lot of resources.
I've seen this "monolith" and I've seen containerized/k8s. For anything that needs to scale and needs similar abstractions you get out of k8s you definitely should not try to reproduce this using VMs.
If you're running a whole fleet of VMs and need to manage them the pain of doing that is quickly going to exceed the "pain" of using k8s. Do you need something like k8s ingress? Do you need the ability to move workloads if a machine goes down? certs? external-dns? Are you going to deploying tooling that's available off the shelf for k8s? (lessay Prometheus/Grafana?). VMs have overhead and likely waste a lot of resources.
I've seen this "monolith" and I've seen containerized/k8s. For anything that needs to scale and needs similar abstractions you get out of k8s you definitely should not try to reproduce this using VMs.
> If your entire application fits in one VM forever - fair enough.
A lot of applications can fit on a single machine. Single machines have gotten so big: 256+ cores, terrabytes of ram, huge amounts of fast storage, 100+Gbps NICs.
Yeah, you should have 2-4 for continuity, but that doesn't need orchestration.
You really don't need to start thinking about horizontal scaling unless you're getting close to filling a single big machine. Especially since the longer it takes for you to scale to big machines, the bigger the machines will be when you get there.
If your application is very latency sensitive, then maybe you need to run machines in more places, and maybe you want something to orchestrate that...
A lot of applications can fit on a single machine. Single machines have gotten so big: 256+ cores, terrabytes of ram, huge amounts of fast storage, 100+Gbps NICs.
Yeah, you should have 2-4 for continuity, but that doesn't need orchestration.
You really don't need to start thinking about horizontal scaling unless you're getting close to filling a single big machine. Especially since the longer it takes for you to scale to big machines, the bigger the machines will be when you get there.
If your application is very latency sensitive, then maybe you need to run machines in more places, and maybe you want something to orchestrate that...
I agree one physical box can do a lot. As you say though, if you want HA/DR now you're already expanding beyond a single box. You're likely talking multiple boxes in multiple locations. Now you have to think about how your data is potentially replicated across. You have to think about monitoring. You have think about how you upgrade your software and maintain your services. You have OS/package upgrades. Where do you test? Do you have a staging environment? How do you monitor all this stuff? Does your business only have this one app or does it grow to offer more apps? Internal services?
I'm sure plenty of things fit this model. But many do not. There's going to be a point where you're taking more pain if you chose the wrong model.
I'm sure plenty of things fit this model. But many do not. There's going to be a point where you're taking more pain if you chose the wrong model.
Why do you need a fleet of VMs?
Go can serve about 500M users per month on Xeon E3 v2 CPUs.
Why, except for HA do you need more?
Do you know how much 5000 (and more in reality) concurrent requests are, and I'm just talking HTTP1.1 requests?
And with HTTP/2 and 48 cores 96 threads and even 24c/48t commodity hardware that's multiples of 5k concurrent rps.
Of course if you insist on using low performance php, node, ruby, elixir that's your own fault.
"Scale" my ass. Just another FUD buzzword to sell expensive proprietary services.
Go can serve about 500M users per month on Xeon E3 v2 CPUs.
Why, except for HA do you need more?
Do you know how much 5000 (and more in reality) concurrent requests are, and I'm just talking HTTP1.1 requests?
And with HTTP/2 and 48 cores 96 threads and even 24c/48t commodity hardware that's multiples of 5k concurrent rps.
Of course if you insist on using low performance php, node, ruby, elixir that's your own fault.
"Scale" my ass. Just another FUD buzzword to sell expensive proprietary services.
I'm not who you're responding to, but...
> Go can serve about 500M users per month on Xeon E3 v2 CPUs. > Why, except for HA do you need more?
Because not everything is a simple CRUD website. The last place I worked had a website that appeared to only be moderately more complex than such a site, and had well under 500M users per month. But parts of the application involved complicated processing of many dozens of TBs per day of newly collected data to optimize the content being served (some stream processing, some batch). We had multiple clusters of 1,000+ machines coming and going for an hour or two at a time (often overlapping).
> Go can serve about 500M users per month on Xeon E3 v2 CPUs. > Why, except for HA do you need more?
Because not everything is a simple CRUD website. The last place I worked had a website that appeared to only be moderately more complex than such a site, and had well under 500M users per month. But parts of the application involved complicated processing of many dozens of TBs per day of newly collected data to optimize the content being served (some stream processing, some batch). We had multiple clusters of 1,000+ machines coming and going for an hour or two at a time (often overlapping).
The problem isn't the 5000 request/s on your Go code. What do these requests do? Is there a database? Is it replicated? How large does it need to be? How complex are the transactions/queries? What happens when your one server goes down? What happens when the Data Center hosting your server(s) goes down? Do you have a large dev team? How do they develop? How do they test? How large is your application? What happens when your company builds new applications? How do you do updates/upgrades of your software and the dependencies? Do you have a staging environment?
Most of my experience is with high performance software. C++/C and yeah lots of Go. My observations aren't related to performance. There's more to scale and providing a reliable service than performance. I am totally onboard with the idea that people often go horizontally when they don't need to performance-wise because they choose slow tools. This is not what I'm talking about here.
That said, there's probably a class of problems that are fine with just one VM. So if that's what you have, go for it (which is what I said in my original comment).
Most of my experience is with high performance software. C++/C and yeah lots of Go. My observations aren't related to performance. There's more to scale and providing a reliable service than performance. I am totally onboard with the idea that people often go horizontally when they don't need to performance-wise because they choose slow tools. This is not what I'm talking about here.
That said, there's probably a class of problems that are fine with just one VM. So if that's what you have, go for it (which is what I said in my original comment).
Part of it seem to be in the format of the "stop doing math" meme[1], so I am not sure how much of it is serious.
[1] https://web.archive.org/web/20200418170753/https://twitter.c...
[1] https://web.archive.org/web/20200418170753/https://twitter.c...
That makes sense with yesterday's low interest rate and high VC investment, sure, and for startups that are VC funded so have cash to burn.
But we're entering leaner times. Many younger people haven't been through this before. Others may not remember. Investors are going to demand more responsible spending, and better balance books, sooner.
If you can start on a shoestring and hold on until you need to scale, you have an advantage in this market that you didn't have 5 years ago.
That and a lot of the cloud stuff comes with an inherent complexity. Architecting for cloud hosted K8 and various cloud services comes not only with a $$ cost but a software architecture complexity & labour overhead.
A single server can do a lot these days. Many many businesses think they need to scale out of the box a lot more than they do.
But we're entering leaner times. Many younger people haven't been through this before. Others may not remember. Investors are going to demand more responsible spending, and better balance books, sooner.
If you can start on a shoestring and hold on until you need to scale, you have an advantage in this market that you didn't have 5 years ago.
That and a lot of the cloud stuff comes with an inherent complexity. Architecting for cloud hosted K8 and various cloud services comes not only with a $$ cost but a software architecture complexity & labour overhead.
A single server can do a lot these days. Many many businesses think they need to scale out of the box a lot more than they do.
I’m sorry, are you advocating to do k8s on-premise as opposed to cloud? Or are you straw-manning “cloud architecture” by assuming that k8s is somehow some cloud requirement vs a single box you paid for yourself in a colo?
You can spin up a single server in the cloud as simply (or more so) than in a colo. Then you can add a load balancer and auto scaling in a few hrs (or less depending on experience) if you reach the point where you need to scale.
You can spin up a single server in the cloud as simply (or more so) than in a colo. Then you can add a load balancer and auto scaling in a few hrs (or less depending on experience) if you reach the point where you need to scale.
Whether it matters depends on how much your hosting costs make up of your burn rate. I agree it's a distraction for some startups, but I've also done startups where using AWS would've meant the company wasn't viable at all.
I think you are missing the point of the article. What I took from it is that majority of cases do not need the complexity that cloud brings including tons of unnecessary tools that are part of a cloud deployment.
Yes u need to get to Pmf first but you can do that without a kubernetes architecture or deploying a highly available app in 5 different zones.
Yes u need to get to Pmf first but you can do that without a kubernetes architecture or deploying a highly available app in 5 different zones.
Also a lot of startups right now need 1 - N GPUs on demand. I do not think the author has ever worked on a growing product.
Right now GCP and lambda cloud have almost no GPUs available. I would have done better on prem.
Do they? Why?
Startups are about hype. Current hype is AI. Google’s CPU based AI training system, whose name I’m blanking on now, doesn’t out perform GPU on smaller loads. Can’t say, “This pen is worth paying $10k unless you include ‘with AI’”.
Right, I get the "AI -> GPU" connection, I'm asking: literally what does a startup do with an on-demand GPU? What is the workload?
Sadly, even if you do something absolutely non-"AI" related, you need to add "AI" somewhere, it's a kind of SEO for VC. Yesterday it was blockchain, tomorrow it will be something else.
Did blockchain startups ever provide any real value to end-users? Like, at all? Speaking from my technical but not SWE perspective, the only things I'm familiar with using the blockchain are cryptocurrency (obviously) and NFTs, which as far as I'm concerned are a scam.
AI does seem different in that regard, I think it is providing tremendous value to people. Just probably not in the random places where people are throwing it in where it doesn't actually fit.
AI does seem different in that regard, I think it is providing tremendous value to people. Just probably not in the random places where people are throwing it in where it doesn't actually fit.
I agree with you but we're not talking about providing any value for end users but about venture investments and raising capital. You don't need to actually provide any value, you just need to convince someone with money to spend it, promising more money in the end. This money may never actually materialize (see Uber) but you can still receive a lot of money year by year, based on someone else's expectations.
I kind of agree with the premise, which is essentially "don't overcomplicate things at the beginning" but the article seems to keep conflating requirements. Does your company have a 10-person devops team or are you a solo enterpreneur? Are you servicing 2 requests per second or do you need a 80-core, 128GB RAM box for hosting your service?
The reason many start with cloud is that most businesses quickly grow, or at least hope to quickly grow, to the point where they'll need it. Standardized cloud tooling helps onboard new developers more quickly. It drastically speeds up audits like SOC2 or ISO. Much easier scale-up/scale-down. etc etc
You also pretty quickly get to the point where your cloud costs are negligible compared to the rest of your business expenses. If you're employing 20 people and paying ~$200k/mo in salaries, is reducing your cloud bill of $2000 to $200 going to materially impact your business, especially given the opportunity cost of not doing other revenue-generating work?
The reason many start with cloud is that most businesses quickly grow, or at least hope to quickly grow, to the point where they'll need it. Standardized cloud tooling helps onboard new developers more quickly. It drastically speeds up audits like SOC2 or ISO. Much easier scale-up/scale-down. etc etc
You also pretty quickly get to the point where your cloud costs are negligible compared to the rest of your business expenses. If you're employing 20 people and paying ~$200k/mo in salaries, is reducing your cloud bill of $2000 to $200 going to materially impact your business, especially given the opportunity cost of not doing other revenue-generating work?
"The reason many start with cloud is that most businesses quickly grow, or at least hope to quickly grow, to the point where they'll need it"
And most don't. That's the point of the article.
And most don't. That's the point of the article.
Most don't, but you can get a t3.micro RDS database and EC2 instance for less than $20/month, to service those two requests per second you're getting. I would assume most startup founders in the US can afford this. If they can but consider it too unlikely they'll recoup these costs, you're getting into "hobby project" territory rather than business.
This is true if you don’t follow best practices. That RDS instance should be in a private VPV. You should have a NAT bridge to your public VPC. That bridge is $35 a month. Then you need a public thing: be it EC2 or API Gateway or ALB with rules. That can more your total to $50/month. But it’s more secure than a Digital Ocean or Hetzner setup.
I think you’ve confused a couple of things. Your db should be in a private subnet as opposed to a VPC, and it’s never advised to have public access directly to your db. You also don’t need NAT for RDS instances as they shouldn’t be initiating outbound connections to the internet. If you do want to connect to your db from outside of AWS for ad hoc connections then you should be setting up a bastion host in the public subnet and you don’t need anything other than security group rules to configure communication between them - same goes for a web server (routing between public/private subnets are configured out of the box).
Well yes, if you start adding "best practices" that only apply to larger companies with threat models that are completely nonapplicable to your 0-revenue, 2-request/sec startup, you are going to have to pay more money.
Adding the requirement of separate private/public VPCs linked by a NAT gateway when we're comparing to a single physical machine with everything running in a single host running Docker is nonsense.
Adding the requirement of separate private/public VPCs linked by a NAT gateway when we're comparing to a single physical machine with everything running in a single host running Docker is nonsense.
This. A single dedicated bare metal server sacrifices too much availability, in return for capacity that you probably don't need yet. Better to use a fraction of a few different servers.
This reads like promotional literature for using Cloud services. Why do all this crap when you can just use AWS or GCP? Heck, as a bonus, you can blame them when it breaks instead of getting fired!
So if you use AWS and screw up a deployment in production, you can blame AWS and get away with it ? Even if it was your fault ?
First of all, should be (2023).
Second, he starts with sudo. Where's that command line coming from? Who installed the OS? Who maintains it? What about availability zones and fast failover?
You can do self hosting if you want, but it's not as easy or as cheap as he's making it out to be.
Cloud is still better for early stage startups, that's why everyone's using it.
Second, he starts with sudo. Where's that command line coming from? Who installed the OS? Who maintains it? What about availability zones and fast failover?
You can do self hosting if you want, but it's not as easy or as cheap as he's making it out to be.
Cloud is still better for early stage startups, that's why everyone's using it.
>What about availability zones and fast failover
You're making OP's main point. He's arguing that (to use his numbers) 90-95% of startups don't actually need to worry about that. Hell, I would argue that a lot of services at established companies don't actually need to worry about it (and the ones that do, need to worry about it a lot). Tons of stuff inside of $megacorps is running on crummy "non-scalable" architectures because somebody sat down and did the "engineering" part of "software engineering" and went "y'know, I think all we're really ever need is..."
>Cloud is still better for early stage startups
My preference is cloud these days (especially if I'm just quick and dirty clicking buttons in console rather than CDK-ing things together). However, there are still lots of cases where sinning up a $10 droplet and running `docker compose` completely satisfies "the architecture" part of the business.
You're making OP's main point. He's arguing that (to use his numbers) 90-95% of startups don't actually need to worry about that. Hell, I would argue that a lot of services at established companies don't actually need to worry about it (and the ones that do, need to worry about it a lot). Tons of stuff inside of $megacorps is running on crummy "non-scalable" architectures because somebody sat down and did the "engineering" part of "software engineering" and went "y'know, I think all we're really ever need is..."
>Cloud is still better for early stage startups
My preference is cloud these days (especially if I'm just quick and dirty clicking buttons in console rather than CDK-ing things together). However, there are still lots of cases where sinning up a $10 droplet and running `docker compose` completely satisfies "the architecture" part of the business.
I'm not sure how bad it is if you're the one product that's down for 12 hours out of your competitive field. Maybe you're right and it's small.
But even if you neglect these issues you still need to manage your own machines, which is more time consuming than spinning up a new VM with preinstalled OS in EC2.
But even if you neglect these issues you still need to manage your own machines, which is more time consuming than spinning up a new VM with preinstalled OS in EC2.
Downtime for your own staff is a quantifiable cost you can expect them to put up with. It's outside customers whose trust will be hard to restore.
> Hell, I would argue that a lot of services at established companies don't actually need to worry about it (and the ones that do, need to worry about it a lot). Tons of stuff inside of $megacorps is running on crummy "non-scalable" architectures because somebody sat down and did the "engineering" part of "software engineering" and went "y'know, I think all we're really ever need is..."
Yeah, those system architectures are the ones that end up in all the other rants, the ones about how companies never prioritize fixing technical debt and legacy code :)
Yeah, those system architectures are the ones that end up in all the other rants, the ones about how companies never prioritize fixing technical debt and legacy code :)
[deleted]
> Second, he starts with sudo. Where's that command line coming from? Who installed the OS? Who maintains it? What about availability zones and fast failover?
I've noticed most of these anti-cloud articles omit this exact point consistently. So we'll replace "the cloud" with docker compose! Because apparently docker compose just spins up resources ex nihilo.
There's also often the contrived assumption that "the cloud" means a bunch of huge bills because you automatically launch every service available and run them constantly. Also you run the largest instances because reasons.
I've noticed most of these anti-cloud articles omit this exact point consistently. So we'll replace "the cloud" with docker compose! Because apparently docker compose just spins up resources ex nihilo.
There's also often the contrived assumption that "the cloud" means a bunch of huge bills because you automatically launch every service available and run them constantly. Also you run the largest instances because reasons.
When people provision resources in the cloud in the same way they provision resources on-premises, they tend to massively over-provision.
[deleted]
You are missing the point. You may not need multiple availability zones when you are starting out and majority of cases never reach that point anyway. We are over optimizing too much because of "cloud" and dumbing us down further.
Stop building restaurants with foundations and secure access.
Here’s a plan for building a food cart for serving your first 1000 customers.
Yes, this might be a viable option for some use cases. In fact in Thailand and other SEA countries many restaurants never graduate past the food cart by choice.
But there are environments and some business plans that require a certain level of maturity, security posture from the get go.
At the same time I can deploy an application on AWS using IaC (AWS CDk) methods in minutes and use mostly serverless services without paying $200/mo.
Here’s a plan for building a food cart for serving your first 1000 customers.
Yes, this might be a viable option for some use cases. In fact in Thailand and other SEA countries many restaurants never graduate past the food cart by choice.
But there are environments and some business plans that require a certain level of maturity, security posture from the get go.
At the same time I can deploy an application on AWS using IaC (AWS CDk) methods in minutes and use mostly serverless services without paying $200/mo.
If you click on his LinkedIn and see his experience I think you can see why he thinks cloud isn't worth it in favor of running everything on a single server and saying things like don't worry about back ups. Being relatively new to the industry and never spending more then a year at a company you will never suffer the consequences of architecting something poorly.
Cloud or not, I think depends on your unique circumstances. Just becasue you can apt install everything once doesn't necessarily mean you should.
Cloud or not, I think depends on your unique circumstances. Just becasue you can apt install everything once doesn't necessarily mean you should.
Article is totally spot on! However, people have been so brainwashed by cloud marketing that they don’t even know what dedicated hardware means anymore. Even the comments here are talking about VPS. Almost everybody has accepted underperforming and unpredictable infra for double the cost of dedicated. OP is spot on, I do exactly the same.
How do you handle downtime due to project/package/os upgrades?
Still using docker so you can upgrade most of it on every deployment. As far as the host, modern Linux distros handle security updates automatically and unattended. I do recommend having a backup replica server in standby. If you need to upgrade the kernel on the host you just change the DNS to point to your backup, wait for some time for connections to finish on your primary then restart the primary, ensure it is stable, change DNS back. It’s standard A/B deployment. Nothing special about it.
Technically no different than what you’d do in the cloud - have multiple of each resource so you can update them one by one while the others keep serving traffic.
Additionally, not every update needs to be applied, you need to understand your threat model and only apply updates when they actually patch something that would affect you - this cuts down on the actual number of updates that you need.
Additionally, not every update needs to be applied, you need to understand your threat model and only apply updates when they actually patch something that would affect you - this cuts down on the actual number of updates that you need.
If you can't simply upgrade while your program is running, you would fire up a redundant server containing the latest version and take the one you are upgrading offline.
Don't upgrade unnecessarily. Then you won't get backdoored by xz releases.
Same security industry convinces you to upgrade every 15 seconds and then sells you solutions for when those upgrades fuck you over.
Same security industry convinces you to upgrade every 15 seconds and then sells you solutions for when those upgrades fuck you over.
Or don't upgrade unecessarily and still have backdoors :P
kexec
Cloud is the a better proposition than EJBs and look how long it took that to die off.
The bright shiny object / resume building in software decisions is in some ways fascinating
The bright shiny object / resume building in software decisions is in some ways fascinating
If anything, cloud is shinier resume building than handrolling.
Handrolling: "wrote a few systemd services"
Cloud: put the EC2 in the VPC with an ENI and attached the EBS to connect to the RDS
Handrolling: "wrote a few systemd services"
Cloud: put the EC2 in the VPC with an ENI and attached the EBS to connect to the RDS
Extremes choices are usually bad. Do nothing on Cloud, Do everything on Cloud... An ideal middleground is to do what you can with a VPS and offload things like Database (Supabase etc), emails to Cloud Providers. You can skip the VPS and go bare metal too if that's your expertise, but it's not for everyone. So, Stop doing (all managed) Cloud. Added bonus is you can shop for each category too and you aren't tied to one Cloud provider
Happy to onboard a startup like this and have them spend thousands of $ on me just on consulting on how to migrate to AWS/GCP/Azure without downtime.
Which they might have now that they have a running business...
A nicer problem to have.
I don't disagree with the article's main sentiment. You don't always need AWS. I advocate quite a bit for self-hosting when it makes sense.
But if you're going to manage your own servers, you need to do it right. This article is a perfect example of what I've seen in the past with not doing it right. It's inconsistent, it doesn't take backup seriously, and it doesn't take availability seriously.
Postgres is installed from their repo. Caddy is installed via & managed via ansible (instead of using something like caddy-docker-proxy). Actual backends are managed via docker compose. Backups are via a hacky script instead of something maintained & that another developer will be able to find docs on like borgmatic. Nothing is thought about for making sure the database state is consistent during backups (eg barman). Monitoring is an afterthought. Firewalling isn't even mentioned.
This setup is one hardware failure away from spending days or weeks trying to recover.
But if you're going to manage your own servers, you need to do it right. This article is a perfect example of what I've seen in the past with not doing it right. It's inconsistent, it doesn't take backup seriously, and it doesn't take availability seriously.
Postgres is installed from their repo. Caddy is installed via & managed via ansible (instead of using something like caddy-docker-proxy). Actual backends are managed via docker compose. Backups are via a hacky script instead of something maintained & that another developer will be able to find docs on like borgmatic. Nothing is thought about for making sure the database state is consistent during backups (eg barman). Monitoring is an afterthought. Firewalling isn't even mentioned.
This setup is one hardware failure away from spending days or weeks trying to recover.
The best part about the cloud for me is that it scales down to ZERO. We used to get large on-prem servers that could handle the worst case, only for them to sit idle 90% of the time. Now we just spin up the 5-10 EC2s we need a couple days a week when we receive new data.
I keep hearing the same, but truthfully I have never seen someone scale to zero. Usually it's only a single component of the architecture that does (if any).
But;
A) You have to engineer your system to scale to zero, engineering time isn't free
B) The overhead cost of service (5x for Linux compute, 11x for Windows compute, 7x for managed DB -- based on my last reads) can easily swallow any savings, especially if you're not scaled to zero almost all the time.
It only takes about 8hrs of being "non-zero" and it would have been cheaper just to have a whole machine for a day somewhere that wasn't a hyperscaler cloud provider.
But;
A) You have to engineer your system to scale to zero, engineering time isn't free
B) The overhead cost of service (5x for Linux compute, 11x for Windows compute, 7x for managed DB -- based on my last reads) can easily swallow any savings, especially if you're not scaled to zero almost all the time.
It only takes about 8hrs of being "non-zero" and it would have been cheaper just to have a whole machine for a day somewhere that wasn't a hyperscaler cloud provider.
Yeah 8 hours would be quite a bit for a day. I'll tell you our use case. We receive a large dump of data 2 times a week, and we spin up 5 machines to process the data files. We have one machine that uses a GPU, one that needs like 128GB of RAM, and a few smaller ones. They're up for maybe 3 hours each.
> To be honest most of you will be fine running a single dedicated bare-metal server
Someone that says this has never even reflected about availability requirements.
Someone that says this has never even reflected about availability requirements.
I could write a novel in response to this.
Top comment reflects on how "getting to market fast" is the most important thing, much more important than costs.
I agree.
Second comment reflects on reliability. Reliability is only a concern when you actually have a product that people want to use.
Cold hard truth:
If you are trying to get to market as fast as possible, most of the cloud abstractions are going to slow you down in most situations. It can be worth it, but your MVP should be as fast to develop as possible and there's nothing faster than writing code and running it.
Second, the reliability of a single machine is much more than you think. Until recently AWS didn't even cover their own reliability of a single instance, if they needed to boot you off a node and shut down your EC2 instance: you might get a bit of notice.
Ironically, you don't even need five-nines in most cases, and if you do, cloud only gives you a toolbox to get there, it's not going to get you there without serious human investment.
You will get 2-3 nines of availability with a bog standard PHP+MYSQL on a single machine.
You know how I know? Because we all did this 15 years ago and truthfully: servers and operating systems are significantly more robust now than they were then, so it's only gotten better for those who do things "wrong".
Top comment reflects on how "getting to market fast" is the most important thing, much more important than costs.
I agree.
Second comment reflects on reliability. Reliability is only a concern when you actually have a product that people want to use.
Cold hard truth:
If you are trying to get to market as fast as possible, most of the cloud abstractions are going to slow you down in most situations. It can be worth it, but your MVP should be as fast to develop as possible and there's nothing faster than writing code and running it.
Second, the reliability of a single machine is much more than you think. Until recently AWS didn't even cover their own reliability of a single instance, if they needed to boot you off a node and shut down your EC2 instance: you might get a bit of notice.
Ironically, you don't even need five-nines in most cases, and if you do, cloud only gives you a toolbox to get there, it's not going to get you there without serious human investment.
You will get 2-3 nines of availability with a bog standard PHP+MYSQL on a single machine.
You know how I know? Because we all did this 15 years ago and truthfully: servers and operating systems are significantly more robust now than they were then, so it's only gotten better for those who do things "wrong".
You will have down times no matter what. I've been surprised quite a free times about how well (in term of availability) a simple one with just a few nodes can perform.
Cloud is a scam in multiple dimensions: - It's overpriced most of the time (I'm looking at you aws) - It wastes you're brain cycle about their stupid proprietary stuff instead of focusing on real problems - Makes you dependent on their bullshit - There's probably more to add to the list.
Overall, I'm a strong believer of "Refrain from doing cloud) :)
Cloud is a scam in multiple dimensions: - It's overpriced most of the time (I'm looking at you aws) - It wastes you're brain cycle about their stupid proprietary stuff instead of focusing on real problems - Makes you dependent on their bullshit - There's probably more to add to the list.
Overall, I'm a strong believer of "Refrain from doing cloud) :)
It's 100% uptime as long as you never have to reboot!
And even if you have to reboot, how long does it take? A minute?
How much does that minute downtime cost?
It can cost a lot and for that case you have HA.
Not rocket science tbh
> And even if you have to reboot, how long does it take? A minute? How much does that minute downtime cost? It can cost a lot and for that case you have HA.
HA shouldn't mean "we deploy a few times a day which drops our uptime to three minutes so we have to spend a lot". One redundant server and a load balancer is hardly HA and increases costs by tens of dollars a month.
And frankly, a minute of downtime is the optimistic case. It all goes to hell when you have a failed software deploy that needs to be rolled back. Or when the application server has a bug that causes crashes and needs to restart every few hours.
A single-server setup is only useful for companies where the technology matters far less than the service being provided. If you can tolerate an uptime of only 2-3 nines, great, but that's absolutely not reasonable for companies where the technology is the service. It's not rocket science that paying customers are going to be pissed if your site is unreliable.
HA shouldn't mean "we deploy a few times a day which drops our uptime to three minutes so we have to spend a lot". One redundant server and a load balancer is hardly HA and increases costs by tens of dollars a month.
And frankly, a minute of downtime is the optimistic case. It all goes to hell when you have a failed software deploy that needs to be rolled back. Or when the application server has a bug that causes crashes and needs to restart every few hours.
A single-server setup is only useful for companies where the technology matters far less than the service being provided. If you can tolerate an uptime of only 2-3 nines, great, but that's absolutely not reasonable for companies where the technology is the service. It's not rocket science that paying customers are going to be pissed if your site is unreliable.
I couldn't agree more. I use a similar setup and serving over 500K monthly users on this single machine. The only thing I would change is that in my experience docker-compose isn't stable enough and it's hard to run predictable workloads without resetting the machine from time to time.
I opted of K3S which give me two benefits. 1. Predictable stable containers running and also restarting all the deployment automatically and 2. If I do need to migrate to bigger cluster / AWS cloud, I got everything ready in my K8S yml files.
I opted of K3S which give me two benefits. 1. Predictable stable containers running and also restarting all the deployment automatically and 2. If I do need to migrate to bigger cluster / AWS cloud, I got everything ready in my K8S yml files.
That’s fine so long as you don’t need a nearly 100% up time, require disaster recovery along with other checkboxes for high availability. Things which might not be required for your industry but to broad stroke all startups is naive of the author.
Both of the following can be true:
- A lot of companies and startups can get by with a few modest sized VPSs for their applications
- Cloud providers and other infrastructure managed services can provide a lot value that justifies paying for them.
Edit: also why the obsession with dedicated hardware and so anti vCPU? For the vast majority of people this is an implementation detail that doesn't matter at all. A lot of that dedicated server is sitting idle.
- A lot of companies and startups can get by with a few modest sized VPSs for their applications
- Cloud providers and other infrastructure managed services can provide a lot value that justifies paying for them.
Edit: also why the obsession with dedicated hardware and so anti vCPU? For the vast majority of people this is an implementation detail that doesn't matter at all. A lot of that dedicated server is sitting idle.
> why the obsession with dedicated hardware and so anti vCPU?
Because it is the reason an application that appears fast and snappy on your mid-range laptop slows down to a crawl when deployed. It’s the difference between a database query taking minutes (and blocking everything else) vs seconds.
vCPUs and the lack of persistent direct-attach storage is the reason I personally don’t use the cloud for anything I build.
Because it is the reason an application that appears fast and snappy on your mid-range laptop slows down to a crawl when deployed. It’s the difference between a database query taking minutes (and blocking everything else) vs seconds.
vCPUs and the lack of persistent direct-attach storage is the reason I personally don’t use the cloud for anything I build.
I do run a pretty similar setup for some projects, and in general I tend to agree with the author, especially when bootstrapping cloud services can cost quite some bucks for mediocre performance.
There is, however, one big disadvantage one should be aware of, and that is downtime. There will be downtime when you
* push a new version of your project
* install package updates for docker, postgres, ...
* install a new kernel and need to reboot
* need to upgrade the base OS because you can't stay on Ubuntu 16.04 for the next 10 years (this one can take hours)
Of course there are projects which can live with that. If your target audience is 9-5 office workers, some downtime at night might be acceptable. At least if you don't have customers in other timezones.
IMHO, the sweet spot would be to have two identical servers with automatic failover, but I did not find a good solution for that yet. Would be very interested if someone here has a solution for that and is willing to share.
There is, however, one big disadvantage one should be aware of, and that is downtime. There will be downtime when you
* push a new version of your project
* install package updates for docker, postgres, ...
* install a new kernel and need to reboot
* need to upgrade the base OS because you can't stay on Ubuntu 16.04 for the next 10 years (this one can take hours)
Of course there are projects which can live with that. If your target audience is 9-5 office workers, some downtime at night might be acceptable. At least if you don't have customers in other timezones.
IMHO, the sweet spot would be to have two identical servers with automatic failover, but I did not find a good solution for that yet. Would be very interested if someone here has a solution for that and is willing to share.
AFAIK all the well-known proxies/load balancer support automatic failure in one way or another - Caddy, Nginx, Traefik, HAProxy.
I prefer Caddy myself, for it's simplicity. On load balancing, it can detect when an upstream server isn't working, and remove it from the list of upstream until it's working again. Sometimes you want control of this, for example for OS updates - Caddy has an admin API you can use to remove a server from upstreams and wait until all connections are drained, then you can perform the updates and add the server back again. Then do the same for other upstream servers.
(I haven't actually used the Caddy admin API in production yet, but plan to soon).
I prefer Caddy myself, for it's simplicity. On load balancing, it can detect when an upstream server isn't working, and remove it from the list of upstream until it's working again. Sometimes you want control of this, for example for OS updates - Caddy has an admin API you can use to remove a server from upstreams and wait until all connections are drained, then you can perform the updates and add the server back again. Then do the same for other upstream servers.
(I haven't actually used the Caddy admin API in production yet, but plan to soon).
I agree with most of the article's sentiment. Cloud provider costs can pile up quickly.
But the most undersold value of the cloud, and where I see so far unbeatable value, is automation (single, unified API) and the ecosystem of tools it allows to flourish from it.
Yes, Ansible could replace some Terraform, CloudFormation or ARM/Bicep but it doesn't manage out of the box a component's lifecycle. That is, knowing how and when should a resource be created, storing that last applied state somewhere and, when there's a new change, knowing if a resource should be recreated or just updated.
But when there's a demand there's (eventually) tools.
But the most undersold value of the cloud, and where I see so far unbeatable value, is automation (single, unified API) and the ecosystem of tools it allows to flourish from it.
Yes, Ansible could replace some Terraform, CloudFormation or ARM/Bicep but it doesn't manage out of the box a component's lifecycle. That is, knowing how and when should a resource be created, storing that last applied state somewhere and, when there's a new change, knowing if a resource should be recreated or just updated.
But when there's a demand there's (eventually) tools.
I've been running my startup for more than 3 years in cloud credits, and now we have 2 more years in another provider ($250k). We've been careful not to use a vendor lock in for a "expensive" service.
I’m not unsympathetic to the thoughts behind this headline but I find the article not compelling.
I think that with modern tools running your own / or rented metal (collocated) is doable and could make sense, but the could solves so many things that you don’t need to be responsible for, you really have to have a clear (businesses)case why you should not start in the cloud or migrate away.
I’m rooting for 37signals, but I’m not sure their move away from the cloud (which I root for in particular) will be really that effective in the end, but I hope it will.
I think that with modern tools running your own / or rented metal (collocated) is doable and could make sense, but the could solves so many things that you don’t need to be responsible for, you really have to have a clear (businesses)case why you should not start in the cloud or migrate away.
I’m rooting for 37signals, but I’m not sure their move away from the cloud (which I root for in particular) will be really that effective in the end, but I hope it will.
I ain't reading all that.
I am happy for you though.
Or sorry that happened.
I kid, but the cloud may be expensive, but I too have used the cloud serving hundreds of thousands of users and have nowhere near the huge costs (around $100-130 a month), making well over $100K MRR.
Sometimes it depends on your business model and if you value your time.
Running a bunch of dev scripts on a VPS for me just wastes my time when I can just heroku push, point click and done, back enjoying my vacation.
I am happy for you though.
Or sorry that happened.
I kid, but the cloud may be expensive, but I too have used the cloud serving hundreds of thousands of users and have nowhere near the huge costs (around $100-130 a month), making well over $100K MRR.
Sometimes it depends on your business model and if you value your time.
Running a bunch of dev scripts on a VPS for me just wastes my time when I can just heroku push, point click and done, back enjoying my vacation.
Exactly. My AWS bill is $800-959/mo and 90% of that is split between storage and egress (a few tb each). I could get a colo and buy my own storage servers or move that stuff to Hetzner or R2 and maybe make my money back in a year or two, but I could also just not think about it and make slightly less money. The cost of me not having to worry about hardware or disks filling up or additional complexity is acceptable for me.
All this "not worth it", "fast to market", "raging madness to consider it". And all this is most understandeable individually.
But is it really a necessity that all those services are globally scaleable and have five nines?
What is the endgame, architecturally? How healthy is that the internet, all served bandwith increasingly is hosted by a few vendors?
But is it really a necessity that all those services are globally scaleable and have five nines?
What is the endgame, architecturally? How healthy is that the internet, all served bandwith increasingly is hosted by a few vendors?
[deleted]
[deleted]
> In the article I assume you have a server running somewhere. Preferable a dedicated one.
Isn't Hetzner Robot still technically "cloud"? You would have to hire rack space in a data center and put your computer in there if you want to really self-host.
Isn't Hetzner Robot still technically "cloud"? You would have to hire rack space in a data center and put your computer in there if you want to really self-host.
In such discussions “cloud” is generally used to refer to “modern” price-gouging providers selling underpowered VMs at exorbitant prices. The provider you’re talking about is more like a conventional “hosting provider”.
I think before one knee-jerk reacts to the article, they should evaluate how their response benefits the targeted audience, small and emerging startups where (1) someone in the team is actually capable to set up the described infrastructure, and (2) there's little prospect to reach 100K monthly users (at least in the short term and to be conservative).
That's a lot of startups.
From reading comments in this thread it seems that many are completely oblivious to the complexity that the cloud can bring to an architecture. It's as though it doesn't cost any time. AWS documentation for everything that you opted in? Downloaded at night in your brain? What about Kubernetes? Just a pill away?
When I hear someone say that they're choosing the cloud for their new project because "managing" their own infra is too much, as someone who is familiar with what the author is pointing at, I wonder "what exactly is there to manage?" Are we talking about the few Python or PHP scripts that speak to Postgres and Redis? Scaling up and down? What are we talking about?
Getting to PMF first as a criteria to not consider the simpler alternatives suggested here is also a premature optimization. The author of this post is boasting a bit by saying that he can show you how to do this in less than 15 minutes and for less than 200$/m. I think it'd still be worth it if it took an entire day to set up. What kind of product are you building that can't spare a day to address your infrastructure?
If the cloud is so seamless and your project becomes so successful that it actually ends up needing all its toys, then you have nothing to worry about. When the time comes, you'll simply turn those magic keys and enter paradise.
That's a lot of startups.
From reading comments in this thread it seems that many are completely oblivious to the complexity that the cloud can bring to an architecture. It's as though it doesn't cost any time. AWS documentation for everything that you opted in? Downloaded at night in your brain? What about Kubernetes? Just a pill away?
When I hear someone say that they're choosing the cloud for their new project because "managing" their own infra is too much, as someone who is familiar with what the author is pointing at, I wonder "what exactly is there to manage?" Are we talking about the few Python or PHP scripts that speak to Postgres and Redis? Scaling up and down? What are we talking about?
Getting to PMF first as a criteria to not consider the simpler alternatives suggested here is also a premature optimization. The author of this post is boasting a bit by saying that he can show you how to do this in less than 15 minutes and for less than 200$/m. I think it'd still be worth it if it took an entire day to set up. What kind of product are you building that can't spare a day to address your infrastructure?
If the cloud is so seamless and your project becomes so successful that it actually ends up needing all its toys, then you have nothing to worry about. When the time comes, you'll simply turn those magic keys and enter paradise.
Yeah, agreed cloud is bad. I have one question though.
Who is going to keep updating bloody ubuntu or any other linux distro along with all the packages that may break?
Who is going to enable automatic database backups or do backups with 1 click?
I've done these things countless times and they are still time consuming and involve guesswork every single time.
And you don't have that problem on public cloud VMs?
In AWS, AMIs are kept up to date and all you have to do is roll your instances inside an ASG (which is a 1 button thing) to have them updated with zero downtime.
RDS takes backups, out of the box with zero configuration, and further customization is very easy.
RDS takes backups, out of the box with zero configuration, and further customization is very easy.
Not really if you are using FaaS (lambdas)
I spend quite a bit on cloud, and despite that I would not spend my time setting up my servers/firewalls /auth .. Just not worth the time.
That's just raging idiocy, not a worthy article.
$200/mo is the cost of like 1-4 developer hours/mo depending on where you are.
Just the thought of hosting my own DB makes me feel like fainting. No thanks.
Choice of using cloud vs bare metal is similar to wasting time learning assembly vs higher level language. Similar affordances.
Try again. More like comparing Excel with VB macros (cloud) to a programming language. Artificial proprietary restrictions and inexplicable intricacies.
The thing is this type of argument often ignores opportunity costs of resources. There are a lot of other things that you can learn.
very refreshing to read. theres just so much complexity behind myriad of decisions just to build simple apps/websites and this is not a coincidence.
by draining cognitive resources you are able to manipulate people into making poor quality decisions. ex) mainstream news, aisle of grocery items, FANG-led development mythos and over-engineering
the last one is especially susceptible to manipulation.
"but we have to scale", "i read HN article from an ivy league founder", "someone with lot of followers on twitter said so"
and boom you are no longer in control of your mind or aware of losing control.
marketing is just like herding cattles, DDOS their cognitive resources so they can't think for themselves and gaslight each other, make them use your npm/pip package with a subscription/metering from day 1, get em while they are young.
by draining cognitive resources you are able to manipulate people into making poor quality decisions. ex) mainstream news, aisle of grocery items, FANG-led development mythos and over-engineering
the last one is especially susceptible to manipulation.
"but we have to scale", "i read HN article from an ivy league founder", "someone with lot of followers on twitter said so"
and boom you are no longer in control of your mind or aware of losing control.
marketing is just like herding cattles, DDOS their cognitive resources so they can't think for themselves and gaslight each other, make them use your npm/pip package with a subscription/metering from day 1, get em while they are young.
I agree maybe there's a bit of over adoption of architectures built for FANG companies, but arguing everyone is using the cloud due to "DDOSing of their cognitive resources" is a terrible take.
i think you should read the article again because thats exactly what i mean. people saying you are wrong without really offering rebuttal.
Honestly, of you're doing docker, might as well go full retard with k8s.
The most simple setup is a some git repo software (forgejo, gitea, goes, etc...) with hooks and client side deploy script. Can't get more simple. You have systemd watching. You don't need docker at all.
Even 100Mbit/s is enough when you have nothing to show for.
The most simple setup is a some git repo software (forgejo, gitea, goes, etc...) with hooks and client side deploy script. Can't get more simple. You have systemd watching. You don't need docker at all.
Even 100Mbit/s is enough when you have nothing to show for.
Right now I run a SaaS platform entirely in the cloud. I am fully aware I am paying more for a managed Postgres cluster versus spinning one up myself and I'm paying more for a managed docker service than I would if I just spun up some EC2's myself or went for a VPS.
But right now I'm also working on the project entirely solo so I have to be careful about what I commit my time to. Sure I could save some $$$ by managing my own infra but the time it would take to spin that up and maintain it will cut into the time I have to build new features for my app. I could hire a contractor to help me maintain that infra but then it goes from being the cheapest option to the most expensive option because I'm paying someone to help with it.
The cloud isn't cheaper than running your own infra, but it's sure as hell cheaper than running your own infra + paying someone to help you run it. Down the road when (hopefully) my company has more scale and we have dedicated folks for infrastructure, then I can start looking into lowering costs on the cloud side because those infra folks are gonna be working for me regardless of where I run the app, but for now when it's between doing it myself and hiring someone to help me, the value prop of a managed service is undeniable.