7 ms·

I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplet

I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture that made cloud app deployments unnecessarily complicated with k8s and cool new tech (that'd get them high profile jobs.) I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?"

everforward 3y ago
> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" I work on the Ops side partially, and our platforms are defined by the highest level of complexity we need to support. That is to say that your basic web app can run on k8s, but that auto-scaling, messaged-based behemoth that 85% of the business flows through will not. So I can either support k8s, or I can support k8s _and_ old-school rsync deployments to VPS' The complexity of running a basic web app on k8s is entirely too high, but the cost of keeping an entirely separate deployment/monitoring/oncall/permissions stack for VPS' is worse. Better hope your monitoring vendor has an agent that can run in a VPS' on the OS you want, or you're back to running Nagios yourself. If at least 1 group is going to write an app that runs on k8s, you might as well run most of the company on k8s. Otherwise you're either going to manage 2 separate stacks, and/or try to write an abstraction layer that will probably itself resemble k8s.
allarm 3y ago
> why not just deploy it on a cheap vps? I’m that kind of a person and the usual response I get is - hey, that’s too complex!
littlestymaar 3y ago
> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It
- banku_brougham 3y ago
  - Upskill Synclayer
api 3y ago
The problem with devops replacing the old title “sysadmin” was that the dev part dragged in the worst thing about developer culture: the love of complexity and the tendency to build massive towers of it. Sysadmins usually avoided complexity because their attitude toward it was more sensible: it’s expensive, fragile, and tends to actually multiply failure modes. I also blame cloud marketing. This stuff is a gigantic money printer for cloud companies. It’s in their interest to encourage as much over engineering as possible, especially if it locks you into things like Kubernetes that are hard to run and thus usually used as services.
- hparadiz 3y ago
  If you guys don't see the value of being able to click on a button on a website to deploy, perfectly, everytime over some guy sshing into the box and running git pull I dunno what to tell you.
  - mmmm2 3y ago
    Emacs has a button for that :-).
  - banku_brougham 3y ago
    People arent missing the value, nobody is saying it wont perform as advertised -- the discussion is about the cost.
    - hparadiz 3y ago
      Setting up a testing & deploy via a CI script is basically free. AWS gives away CodeDeploy for free. Ansible is open source. I learned all this stuff working on open source stuff where platforms like GitHub give you free compute time.
      - deleted 3y ago
        [deleted]
  - rmbyrro 3y ago
tambourine_man 3y ago
I'm convinced it's the hiring that has shaped the scene. If you're hiring, you want to be able to add/replace people as easily as possible. If you're being hired, you want to charge as much as you can. And to satisfy those two demands, the current web stack is great. Almost like it's been built for it. It's got very little to do with the tech itself, a lot more to do with market dynamics. That's the problem it's trying to solve.
- fsloth 3y ago
  I can’t confirm but it does look like a significant portion of current software engineering zeitgeist is developed for compartmentalized careerism with a good splash of non-value adding complexity. If that keeps food on the table and the wheels of business spinning, fine, but I’ve seen this leading to situations where a simple thing expands to a role, and then department and … oh, hi, enterprise software, it’s you!
- Nextgrid 3y ago
  The root cause is the decade of zero interest rates which led to companies intentionally overcomplicating their stacks to justify neverending VC rounds. Early prospective employees took notice and adjusted their skills as a result. The dangerous part is that in the meantime we've got brand new and budding talent that actually took this charade seriously and effectively got high on their own supply, seeing this performance art as the actual normality even in a post-ZIRP world where tech/engineering is primarily there to drive business profits and not a VC mating ritual. The only winners are the cloud/infra/tooling providers who got an entire generation of "engineers" to do perpetuate their con without even realizing it.
  - rodgerd 3y ago
    > The root cause is the decade of zero interest rates which led to companies intentionally overcomplicating their stacks to justify neverending VC rounds. Extended hot take: the true customer of a company are the current and prospective holders of capital, whether VC, private investment, or public markets. Keeping them happy is the main goal of the exec. If your owners' portfolios include real estate, you push "back to the office". If it includes container startups, you deploy on k8s. Your "strategic partnerships" are determined by how much your owners care about propping up investment A investment B.
unclebucknasty 3y ago
>I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale... I'd argue it's just as much the dogmatic nature of all things software-related, together with the attendant shiny new object syndrome. See SPAs, NoSQL, micro-services, etc. There's generally a use case for all of these, but they tend to be too easily extrapolated into, "if you're not using these, you're not doing it right."
znpy 3y ago
> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" Was a devops engineer at my previous job. We already had k8s clusters setup, pre-made CI templates and pre-tailored helm charts (along with monitoring and much more). All those things you (a developer) could mostly clone, slightly customize and ship both to a development k8s cluster and to a prod k8s cluster (with all the safety nets already in place). Creating (and maintaining) a single vm for a pet project is way more work than using the pre-made and pre-customized and curated toolkit. This was at a 100+ developers organisation. If you think you could easily get off with a single vm then you've never seen devops done right, i'm fairly sure. EDIT: I probably fell for the bait, but the post i'm replying to really made me remember why we went on a killing spree in order to eradicate everything that was not k8s at my previous job and removing as much developer access to prod as possible. Some idiot developers think they know better, usually end up re-inventing a square wheel that breaks as soon as it's not running on their laptop anymore.
- zer00eyz 3y ago
  You're not wrong. K8s, containers in general, aren't solving the problem. Developers write apps, engineers write software. One is installable, it respects the system it lives on, It can be tuned to use the hardware it has or share. The other, the other is a bucket of shit in a bag. The bag protects you and everyone else from it contaminating everything it touches. Containers dont solve the problem they just enable it.
  - worik 3y ago
    > Developers write apps, engineers write software. That is a classic distinction without a difference! Engineers have been to engineering school. If you have not been to engineering school, you are not an engineer!
    - zer00eyz 3y ago
      It's not a dead language, Im sorry the valley stole your title but that ship has sailed.
maccard 3y ago
I think that the $5 tier is a little tight for a web app as opposed to a crud app, but 2x $40 tiers is enough for a decent amount of traffic, with one as a failover. The problem is that containers are excellent, and IMO there's a gap in the market between "I want to run one container" and "I want a fully managed k8s cluster"
- alibarber 3y ago
  For my personal projects (that right now seem to revolve around April 1st jokes for people in my industry) - I've found a good middle ground to be K3s on a single Hetzner VM that I scale up and down if I think more/less people are going to be looking at it (i.e. between the 5 - 10 dollar/month price range) I set this up with Terraform and some bash scripts. Infra as code is just too convenient to pass up on for something that I might not come back to for months at a time (and then ask - how did I set that up?), and containers too mean that I can play with some shiny fun technology one time, leave it in a box, and then come back to a clean-slate for the next thing that I want to play with without having to pay for a new VM etc.
  - maccard 3y ago
    The other great thing about containers is that you can have entire isolated stacks for your projects, and you can stand the entire thing up with `docker compose up -d` in a matter of seconds. Gone are the days of accidentally connecting to the wrong database with WAMP.
- mnahkies 3y ago
  For my personal stuff that doesn't get any traffic I cobbled together some scripts to manage containers / SSL here https://github.com/mnahkies/shoe-string-server https://github.com/mnahkies/shoe-string-server I don't think I ever got around to making it self healing if a container dies, but it does support gitops style deployments through a cronjob / conf repo similar to argocd It's been running happily on a <$10 / month aws lightsail instance for a few years now, though tbh I'd still reach for k8s for anything serious
- auspex 3y ago
colechristensen 3y ago
> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" I’ve lost startup jobs for basically this. As in “let’s focus on our mvp instead of adopting k8s and discussing “the definition of done” for literally six hours a week”. That one ran out of money and folded, sadly. They had tons of potential and a few bad hires. But also on the other side, my time is expensive, engineering time is expensive, downtime is catastrophic for a new business. Some people want to spend 4 5 or 6 figures to save twenty dollars a month. Imagine my time is worth $500 an hour, if the effort to make something cheaper doesn’t pay for itself in a year then it’s probably a waste of resources.
marginalia_nu 3y ago
Yeah my search engine, back when it was hosted on a PC in my living room off domestic broadband would shrug off HN[1][2] without the fans even spinning faster than usual. And like, internet search should be more resource heavy than the sort of websites that regularly do keel over to HN. Every query is like up to 50 MB in disk reads. [1] https://news.ycombinator.com/item?id=28550764 https://news.ycombinator.com/item?id=28550764 [2] https://news.ycombinator.com/item?id=35611923 https://news.ycombinator.com/item?id=35611923
- Nextgrid 3y ago
  The shift to cloud-based workloads (with oversubscribed CPUs and mandatory networked storage) means that a lot of people lost track of just how fast physical hardware (even mid-range consumer-grade) has become.
  - paulmd 3y ago
    That’s also a deliberate thing - cloud providers have consciously avoided increasing the per-unit performance of a vcpu, you still get the same Sandy Bridge performance in 2024 as you did in 2012. They actually go all the way to the extent of having AMD design them smaller, higher-density “cloud” cores that don’t clock as high, to avoid ever increasing that vcpu unit.
ProblemExplorer 3y ago
> unnecessarily complicated with k8s Kubernetes is/was a way to fight off walled gardens from cloud providers. The other path would have been to learn the bespoke implementation of each cloud provider depending on what that employer ended up using. Kubernetes was at the right place, at the right time just as AWS was trying to force feed people their own proprietary solution, as Azure was trying to wall off people into their own walled garden, as GCP was being Google just not giving a damn about any other usecase than what works great at a massive search company. With Kubernetes, developers can learn one API to deploy their applications and hopefully it works on AWS, Azure, GCP, DO, OVH or a laptop at home. So that way, developers can learn one thing and transfer their knowledge at an employer that hosts on AWS, and then another that hosts on Azure and so on. This is in contrast to the experience of a Python developer who's mastered FastAPI/Flask/SQLAlchemy and feels absolutely lost in a Django project or an Angular developer who stares a Next.js project wondering what the heck is happening and how it all works. Neither a Next.js or an Angular developer would start off with an AWS Amplify solution if they could help it.
- oceanplexian 3y ago
  > With Kubernetes, developers can learn one API to deploy their applications and hopefully it works on AWS, Azure, GCP, DO, OVH or a laptop at home. That's one of the lies developers tell themselves, because at some point you're going to need to manage Accounts, VPCs and ELBs, Certificates, Security Groups, IAM policies, and everything else. All of those underlying primitives that are required and have massive differences in behavior that are expressed differently in GCP, Azure, and AWS. On top of that Kubernetes is itself a walled garden. You will inevitably end up cargo culting the entire ecosystem of plugins, like Cilium and Helm and so on. All of this IaC is meaningless outside of Kubernetes. Soon enough, you have 10,000 lines of YAML configuring highly proprietary infrastructure with multiple variants for each cloud. At some point you will have to rewrite controllers to add functionality or correct bugs the upstream maintainers don't want to prioritize, and so on. Your "knowledge" of the stack ends up being the ability to orchestrate 15 levels of templated YAML. Eventually your company ends up hiring people who only know how to copy/paste YAML, and lose institutional knowledge of how underlying systems work. You didn't break out of the walled garden, you created an elaborate prison. And Amazon and GCP and Azure love you, because you're their #1 customer. The more complex you make it to deploy a CRUD app the more they profit.
benreesman 3y ago
Maybe that still counts as an unpopular opinion in the large, but I’ve never seen it be an unpopular opinion by the standards of really effective teams or really productive hackers I had the privilege to be around at times, and it seems to me that your good idea is coming back in a big way recently. When I worked on teams that denominated egress in terrabits/s, TPS in millions or higher (sometime much higher), and daily warehouse ingest in petabytes it was just the default thing to spin up an instance and a hot standby (sometimes per region or something) if that’s all that was required, and containers and whatnot were used only in the context of bare-metal: you do usually want one level of indirection so containers are really useful if you’re racking metal from a small menu of SKUs. But as for why it ever became conventional wisdom to wrap a venv inside a container on a hypervisor, often with multiple images composed on a dizzying array of low-friction SKUs? I never got it and still don’t.
baridbelmedar 3y ago
> Unpopular opinion: I blame the new age devops culture that made cloud app deployments unnecessarily complicated with k8s and cool new tech (that'd get them high profile jobs.)... Ah yes, time for the annual debate on the complexities of Kubernetes versus the unparalleled genius of custom scripts that seem to work...sometimes. Because reinventing the wheel is always superior to something with a standardized API. And let's not forget the sheer elegance of a homegrown scripts that rivals the structured approach of Kubernetes. A true testament to intuitive design. Sure, Kubernetes might have a few minor benefits beyond 'scaling out'. But honestly, who needs the ability to manage complex applications with any semblance of ease?
- ProblemExplorer 3y ago
  > honestly, who needs the ability to manage complex applications with any semblance of ease? The argument being made here is majority of applications are rarely complex and hence dont require managing that complexity. A simple webservice fronted by a simple reverse proxy like Caddy running on a single "modern PC" can do wonders without any Kubernetes needing to get involved.
OhMeadhbh 3y ago
But there's a middle ground somewhere. The current DevOps culture comes from the FAANG guys who really are getting a bazillion requests per second. In the last decade I worked for Amazon, Avalara and Audible Magic. None of these could build an app around a Digital Ocean droplet. But I think you're pointing out there are PLENTY of useful webapps that can run on a minimal system. I'm just curious where the middle ground is. Cause I think we've all seen sites blow up after a reference on HN or SlashDot or whatever and by the time you get there the only thing you see is a stock error from the PHP engine saying "My MySQL Engine is Melting" or somesuch. It would be very cool if one could write an app using {NODE|Ruby|Python|Whatever} and have the infrastructure around it notice when things spike and do some magic under the hood to spin up new containers in geographically distributed data centers and scale up a simple persistence tier. That way you could move forward with a SIMPLE application instance and not freak out that you'll disappoint new users if there's a spike in demand. You know, sort of like what AWS Lambda was supposed to be. Hmm... I think I might have come up with a plan for my next startup. Thank you for speaking your truth. [Edit: To re-iterate, I think I'm saying it's just as wrong to think a small, simple app needs Amazon-level redundancy and immediate scalability as it is to say Amazon could run on a single machine. But... the "Slash-Dotted Website Goes Down" scenario is real and there should be SOMETHING the industry could do that's easier on people than to force them into a custom AWS ECS solution across multiple continents.]
- LtWorf 3y ago
  Yeah most people don't like getting an invoice for thousands of € because their website was under a DDOS.
  - OhMeadhbh 3y ago
    sure. but there's a middle ground there somewhere. it's not just service blackout after 5 requests per second or a $10k monthly aws bill. if your budget was $500, you could set off alarms or auto-shutoff after some threshold. and turn on syn cookies if you're worried about the kiddies. the point is... there's a middleground there somewhere and I think different people put the cost/availability tradeoff at different places.
LtWorf 3y ago
Hipster devops was overcomplicated long before kubernetes. In my 1st job we had autoscaling on AWS to handle peaks… except that our servers took about 30 minutes to do the upgrades, download gcc, compile all the needed python modules… We'd always reach the autoscaling limit because the new servers weren't doing anything at all. All of them would be downloading and compiling the same things. I was very junior, but I told my boss if we shouldn't maybe use base images that already contained everything, instead of a default blank ubuntu for the servers. The boss said no, because that wouldn't be agile. The whole thing of using yaml files to configure servers already existed, it worked terribly. It was basically meme development there. Including using mongodb for no reason at all, and using it badly so that every write was actually moving thousands of records around.
- KronisLV 3y ago
  > I was very junior, but I told my boss if we shouldn't maybe use base images that already contained everything, instead of a default blank ubuntu for the servers. Honestly, nowadays Docker and other OCI containers do this pretty well. Spinning up new instances and even provisioning nodes has become very easy, in addition to load balancing features those provide. 12 factor apps are also an amazingly concise way to develop and manage multiple services without going into YAML hell: https://12factor.net/ https://12factor.net/ The problem is that the management layers around containers are typically overcomplicated to the point of comedy. Kubernetes might make sense with something like K0s or K3s might make some sense but is still inherently a full time position to run on prem (with updates and observability) and will cause headaches. Hashicorp Nomad is better, but is meant for scales greater than those of most companies. Docker Swarm hits the spot (especially with something like Portainer), but nobody seems to actually care because it's not a trendy piece of tech. The day Docker Swarm dies is the day I go back to writing PHP in a shared hosting environment in protest.
  - LtWorf 3y ago
    It's not fast if you refuse to create a pre-made image and recompile everything instead. Docker won't make it any more fast.
MattPalmer1086 3y ago
Not so unpopular. I worked at a startup where they wasted huge amounts of money on a massively complex set up using kubernetes (and this was the early days of kubernetes). Despite this, or maybe because of it, our AWS bill was killing us. The irony was that the cloud was supposed to be the simplest bit. All the computation and cryptography occurred on the mobile clients, the cloud was really just to provide storage. The same team then rewrote the mobile clients to have a "beautiful" API that took 100s of times more resource than the original code. I guess they just loved complexity for the sake of it.
paulmd 3y ago
A ton of the problem is people turning everything into dynamic this or that. Wordpress culture, basically. Most pages can really just serve a jekyll/astro static-generated page and be fine. But if you shove a database and php in the middle, it’s gonna be multiple orders of magnitude slower.
throwaway17824 3y ago
Once when working in devops I asked my team lead why we didn't just move everything to Heroku, rather than reinventing a bad in-house version of their features. I was firmly told not to suggest it again unless I wanted to put all of us out of a job. That seemed ridiculous to me — we had a laundry list of ways we could help the business if we got basic platform stuff off of our plates. But I sure learned something about how incentives affect otherwise-good engineers.
deleted 3y ago
[deleted]
febed 3y ago
Since you seem to have multiple successful and scalable deployments under your belt, what is your goto tech stack?

everforward 3y ago

> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" I work on the Ops side partially, and our platforms are defined by the highest level of complexity we need to support. That is to say that your basic web app can run on k8s, but that auto-scaling, messaged-based behemoth that 85% of the business flows through will not. So I can either support k8s, or I can support k8s _and_ old-school rsync deployments to VPS' The complexity of running a basic web app on k8s is entirely too high, but the cost of keeping an entirely separate deployment/monitoring/oncall/permissions stack for VPS' is worse. Better hope your monitoring vendor has an agent that can run in a VPS' on the OS you want, or you're back to running Nagios yourself. If at least 1 group is going to write an app that runs on k8s, you might as well run most of the company on k8s. Otherwise you're either going to manage 2 separate stacks, and/or try to write an abstraction layer that will probably itself resemble k8s.

allarm 3y ago

> why not just deploy it on a cheap vps? I’m that kind of a person and the usual response I get is - hey, that’s too complex!

littlestymaar 3y ago

banku_brougham 3y ago
- Upskill Synclayer

api 3y ago

The problem with devops replacing the old title “sysadmin” was that the dev part dragged in the worst thing about developer culture: the love of complexity and the tendency to build massive towers of it. Sysadmins usually avoided complexity because their attitude toward it was more sensible: it’s expensive, fragile, and tends to actually multiply failure modes. I also blame cloud marketing. This stuff is a gigantic money printer for cloud companies. It’s in their interest to encourage as much over engineering as possible, especially if it locks you into things like Kubernetes that are hard to run and thus usually used as services.

hparadiz 3y ago
If you guys don't see the value of being able to click on a button on a website to deploy, perfectly, everytime over some guy sshing into the box and running git pull I dunno what to tell you.
- mmmm2 3y ago
  Emacs has a button for that :-).
- banku_brougham 3y ago
  People arent missing the value, nobody is saying it wont perform as advertised -- the discussion is about the cost.
  - hparadiz 3y ago
    Setting up a testing & deploy via a CI script is basically free. AWS gives away CodeDeploy for free. Ansible is open source. I learned all this stuff working on open source stuff where platforms like GitHub give you free compute time.
    - deleted 3y ago
      [deleted]
- rmbyrro 3y ago

tambourine_man 3y ago

I'm convinced it's the hiring that has shaped the scene. If you're hiring, you want to be able to add/replace people as easily as possible. If you're being hired, you want to charge as much as you can. And to satisfy those two demands, the current web stack is great. Almost like it's been built for it. It's got very little to do with the tech itself, a lot more to do with market dynamics. That's the problem it's trying to solve.

fsloth 3y ago
I can’t confirm but it does look like a significant portion of current software engineering zeitgeist is developed for compartmentalized careerism with a good splash of non-value adding complexity. If that keeps food on the table and the wheels of business spinning, fine, but I’ve seen this leading to situations where a simple thing expands to a role, and then department and … oh, hi, enterprise software, it’s you!
Nextgrid 3y ago
The root cause is the decade of zero interest rates which led to companies intentionally overcomplicating their stacks to justify neverending VC rounds. Early prospective employees took notice and adjusted their skills as a result. The dangerous part is that in the meantime we've got brand new and budding talent that actually took this charade seriously and effectively got high on their own supply, seeing this performance art as the actual normality even in a post-ZIRP world where tech/engineering is primarily there to drive business profits and not a VC mating ritual. The only winners are the cloud/infra/tooling providers who got an entire generation of "engineers" to do perpetuate their con without even realizing it.
- rodgerd 3y ago
  > The root cause is the decade of zero interest rates which led to companies intentionally overcomplicating their stacks to justify neverending VC rounds. Extended hot take: the true customer of a company are the current and prospective holders of capital, whether VC, private investment, or public markets. Keeping them happy is the main goal of the exec. If your owners' portfolios include real estate, you push "back to the office". If it includes container startups, you deploy on k8s. Your "strategic partnerships" are determined by how much your owners care about propping up investment A investment B.

unclebucknasty 3y ago

>I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale... I'd argue it's just as much the dogmatic nature of all things software-related, together with the attendant shiny new object syndrome. See SPAs, NoSQL, micro-services, etc. There's generally a use case for all of these, but they tend to be too easily extrapolated into, "if you're not using these, you're not doing it right."

znpy 3y ago

> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" Was a devops engineer at my previous job. We already had k8s clusters setup, pre-made CI templates and pre-tailored helm charts (along with monitoring and much more). All those things you (a developer) could mostly clone, slightly customize and ship both to a development k8s cluster and to a prod k8s cluster (with all the safety nets already in place). Creating (and maintaining) a single vm for a pet project is way more work than using the pre-made and pre-customized and curated toolkit. This was at a 100+ developers organisation. If you think you could easily get off with a single vm then you've never seen devops done right, i'm fairly sure. EDIT: I probably fell for the bait, but the post i'm replying to really made me remember why we went on a killing spree in order to eradicate everything that was not k8s at my previous job and removing as much developer access to prod as possible. Some idiot developers think they know better, usually end up re-inventing a square wheel that breaks as soon as it's not running on their laptop anymore.

zer00eyz 3y ago
You're not wrong. K8s, containers in general, aren't solving the problem. Developers write apps, engineers write software. One is installable, it respects the system it lives on, It can be tuned to use the hardware it has or share. The other, the other is a bucket of shit in a bag. The bag protects you and everyone else from it contaminating everything it touches. Containers dont solve the problem they just enable it.
- worik 3y ago
  > Developers write apps, engineers write software. That is a classic distinction without a difference! Engineers have been to engineering school. If you have not been to engineering school, you are not an engineer!
  - zer00eyz 3y ago
    It's not a dead language, Im sorry the valley stole your title but that ship has sailed.

maccard 3y ago

I think that the $5 tier is a little tight for a web app as opposed to a crud app, but 2x $40 tiers is enough for a decent amount of traffic, with one as a failover. The problem is that containers are excellent, and IMO there's a gap in the market between "I want to run one container" and "I want a fully managed k8s cluster"

alibarber 3y ago
For my personal projects (that right now seem to revolve around April 1st jokes for people in my industry) - I've found a good middle ground to be K3s on a single Hetzner VM that I scale up and down if I think more/less people are going to be looking at it (i.e. between the 5 - 10 dollar/month price range) I set this up with Terraform and some bash scripts. Infra as code is just too convenient to pass up on for something that I might not come back to for months at a time (and then ask - how did I set that up?), and containers too mean that I can play with some shiny fun technology one time, leave it in a box, and then come back to a clean-slate for the next thing that I want to play with without having to pay for a new VM etc.
- maccard 3y ago
  The other great thing about containers is that you can have entire isolated stacks for your projects, and you can stand the entire thing up with `docker compose up -d` in a matter of seconds. Gone are the days of accidentally connecting to the wrong database with WAMP.
mnahkies 3y ago
For my personal stuff that doesn't get any traffic I cobbled together some scripts to manage containers / SSL here https://github.com/mnahkies/shoe-string-server https://github.com/mnahkies/shoe-string-server I don't think I ever got around to making it self healing if a container dies, but it does support gitops style deployments through a cronjob / conf repo similar to argocd It's been running happily on a <$10 / month aws lightsail instance for a few years now, though tbh I'd still reach for k8s for anything serious
auspex 3y ago

colechristensen 3y ago

> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" I’ve lost startup jobs for basically this. As in “let’s focus on our mvp instead of adopting k8s and discussing “the definition of done” for literally six hours a week”. That one ran out of money and folded, sadly. They had tons of potential and a few bad hires. But also on the other side, my time is expensive, engineering time is expensive, downtime is catastrophic for a new business. Some people want to spend 4 5 or 6 figures to save twenty dollars a month. Imagine my time is worth $500 an hour, if the effort to make something cheaper doesn’t pay for itself in a year then it’s probably a waste of resources.

marginalia_nu 3y ago

Yeah my search engine, back when it was hosted on a PC in my living room off domestic broadband would shrug off HN[1][2] without the fans even spinning faster than usual. And like, internet search should be more resource heavy than the sort of websites that regularly do keel over to HN. Every query is like up to 50 MB in disk reads. [1] https://news.ycombinator.com/item?id=28550764 https://news.ycombinator.com/item?id=28550764 [2] https://news.ycombinator.com/item?id=35611923 https://news.ycombinator.com/item?id=35611923

Nextgrid 3y ago
The shift to cloud-based workloads (with oversubscribed CPUs and mandatory networked storage) means that a lot of people lost track of just how fast physical hardware (even mid-range consumer-grade) has become.
- paulmd 3y ago
  That’s also a deliberate thing - cloud providers have consciously avoided increasing the per-unit performance of a vcpu, you still get the same Sandy Bridge performance in 2024 as you did in 2012. They actually go all the way to the extent of having AMD design them smaller, higher-density “cloud” cores that don’t clock as high, to avoid ever increasing that vcpu unit.

ProblemExplorer 3y ago

> unnecessarily complicated with k8s Kubernetes is/was a way to fight off walled gardens from cloud providers. The other path would have been to learn the bespoke implementation of each cloud provider depending on what that employer ended up using. Kubernetes was at the right place, at the right time just as AWS was trying to force feed people their own proprietary solution, as Azure was trying to wall off people into their own walled garden, as GCP was being Google just not giving a damn about any other usecase than what works great at a massive search company. With Kubernetes, developers can learn one API to deploy their applications and hopefully it works on AWS, Azure, GCP, DO, OVH or a laptop at home. So that way, developers can learn one thing and transfer their knowledge at an employer that hosts on AWS, and then another that hosts on Azure and so on. This is in contrast to the experience of a Python developer who's mastered FastAPI/Flask/SQLAlchemy and feels absolutely lost in a Django project or an Angular developer who stares a Next.js project wondering what the heck is happening and how it all works. Neither a Next.js or an Angular developer would start off with an AWS Amplify solution if they could help it.

oceanplexian 3y ago
> With Kubernetes, developers can learn one API to deploy their applications and hopefully it works on AWS, Azure, GCP, DO, OVH or a laptop at home. That's one of the lies developers tell themselves, because at some point you're going to need to manage Accounts, VPCs and ELBs, Certificates, Security Groups, IAM policies, and everything else. All of those underlying primitives that are required and have massive differences in behavior that are expressed differently in GCP, Azure, and AWS. On top of that Kubernetes is itself a walled garden. You will inevitably end up cargo culting the entire ecosystem of plugins, like Cilium and Helm and so on. All of this IaC is meaningless outside of Kubernetes. Soon enough, you have 10,000 lines of YAML configuring highly proprietary infrastructure with multiple variants for each cloud. At some point you will have to rewrite controllers to add functionality or correct bugs the upstream maintainers don't want to prioritize, and so on. Your "knowledge" of the stack ends up being the ability to orchestrate 15 levels of templated YAML. Eventually your company ends up hiring people who only know how to copy/paste YAML, and lose institutional knowledge of how underlying systems work. You didn't break out of the walled garden, you created an elaborate prison. And Amazon and GCP and Azure love you, because you're their #1 customer. The more complex you make it to deploy a CRUD app the more they profit.

benreesman 3y ago

Maybe that still counts as an unpopular opinion in the large, but I’ve never seen it be an unpopular opinion by the standards of really effective teams or really productive hackers I had the privilege to be around at times, and it seems to me that your good idea is coming back in a big way recently. When I worked on teams that denominated egress in terrabits/s, TPS in millions or higher (sometime much higher), and daily warehouse ingest in petabytes it was just the default thing to spin up an instance and a hot standby (sometimes per region or something) if that’s all that was required, and containers and whatnot were used only in the context of bare-metal: you do usually want one level of indirection so containers are really useful if you’re racking metal from a small menu of SKUs. But as for why it ever became conventional wisdom to wrap a venv inside a container on a hypervisor, often with multiple images composed on a dizzying array of low-friction SKUs? I never got it and still don’t.

baridbelmedar 3y ago

> Unpopular opinion: I blame the new age devops culture that made cloud app deployments unnecessarily complicated with k8s and cool new tech (that'd get them high profile jobs.)... Ah yes, time for the annual debate on the complexities of Kubernetes versus the unparalleled genius of custom scripts that seem to work...sometimes. Because reinventing the wheel is always superior to something with a standardized API. And let's not forget the sheer elegance of a homegrown scripts that rivals the structured approach of Kubernetes. A true testament to intuitive design. Sure, Kubernetes might have a few minor benefits beyond 'scaling out'. But honestly, who needs the ability to manage complex applications with any semblance of ease?

ProblemExplorer 3y ago
> honestly, who needs the ability to manage complex applications with any semblance of ease? The argument being made here is majority of applications are rarely complex and hence dont require managing that complexity. A simple webservice fronted by a simple reverse proxy like Caddy running on a single "modern PC" can do wonders without any Kubernetes needing to get involved.

OhMeadhbh 3y ago

But there's a middle ground somewhere. The current DevOps culture comes from the FAANG guys who really are getting a bazillion requests per second. In the last decade I worked for Amazon, Avalara and Audible Magic. None of these could build an app around a Digital Ocean droplet. But I think you're pointing out there are PLENTY of useful webapps that can run on a minimal system. I'm just curious where the middle ground is. Cause I think we've all seen sites blow up after a reference on HN or SlashDot or whatever and by the time you get there the only thing you see is a stock error from the PHP engine saying "My MySQL Engine is Melting" or somesuch. It would be very cool if one could write an app using {NODE|Ruby|Python|Whatever} and have the infrastructure around it notice when things spike and do some magic under the hood to spin up new containers in geographically distributed data centers and scale up a simple persistence tier. That way you could move forward with a SIMPLE application instance and not freak out that you'll disappoint new users if there's a spike in demand. You know, sort of like what AWS Lambda was supposed to be. Hmm... I think I might have come up with a plan for my next startup. Thank you for speaking your truth. [Edit: To re-iterate, I think I'm saying it's just as wrong to think a small, simple app needs Amazon-level redundancy and immediate scalability as it is to say Amazon could run on a single machine. But... the "Slash-Dotted Website Goes Down" scenario is real and there should be SOMETHING the industry could do that's easier on people than to force them into a custom AWS ECS solution across multiple continents.]

LtWorf 3y ago
Yeah most people don't like getting an invoice for thousands of € because their website was under a DDOS.
- OhMeadhbh 3y ago
  sure. but there's a middle ground there somewhere. it's not just service blackout after 5 requests per second or a $10k monthly aws bill. if your budget was $500, you could set off alarms or auto-shutoff after some threshold. and turn on syn cookies if you're worried about the kiddies. the point is... there's a middleground there somewhere and I think different people put the cost/availability tradeoff at different places.

LtWorf 3y ago

Hipster devops was overcomplicated long before kubernetes. In my 1st job we had autoscaling on AWS to handle peaks… except that our servers took about 30 minutes to do the upgrades, download gcc, compile all the needed python modules… We'd always reach the autoscaling limit because the new servers weren't doing anything at all. All of them would be downloading and compiling the same things. I was very junior, but I told my boss if we shouldn't maybe use base images that already contained everything, instead of a default blank ubuntu for the servers. The boss said no, because that wouldn't be agile. The whole thing of using yaml files to configure servers already existed, it worked terribly. It was basically meme development there. Including using mongodb for no reason at all, and using it badly so that every write was actually moving thousands of records around.

KronisLV 3y ago
> I was very junior, but I told my boss if we shouldn't maybe use base images that already contained everything, instead of a default blank ubuntu for the servers. Honestly, nowadays Docker and other OCI containers do this pretty well. Spinning up new instances and even provisioning nodes has become very easy, in addition to load balancing features those provide. 12 factor apps are also an amazingly concise way to develop and manage multiple services without going into YAML hell: https://12factor.net/ https://12factor.net/ The problem is that the management layers around containers are typically overcomplicated to the point of comedy. Kubernetes might make sense with something like K0s or K3s might make some sense but is still inherently a full time position to run on prem (with updates and observability) and will cause headaches. Hashicorp Nomad is better, but is meant for scales greater than those of most companies. Docker Swarm hits the spot (especially with something like Portainer), but nobody seems to actually care because it's not a trendy piece of tech. The day Docker Swarm dies is the day I go back to writing PHP in a shared hosting environment in protest.
- LtWorf 3y ago
  It's not fast if you refuse to create a pre-made image and recompile everything instead. Docker won't make it any more fast.

MattPalmer1086 3y ago

Not so unpopular. I worked at a startup where they wasted huge amounts of money on a massively complex set up using kubernetes (and this was the early days of kubernetes). Despite this, or maybe because of it, our AWS bill was killing us. The irony was that the cloud was supposed to be the simplest bit. All the computation and cryptography occurred on the mobile clients, the cloud was really just to provide storage. The same team then rewrote the mobile clients to have a "beautiful" API that took 100s of times more resource than the original code. I guess they just loved complexity for the sake of it.

paulmd 3y ago

A ton of the problem is people turning everything into dynamic this or that. Wordpress culture, basically. Most pages can really just serve a jekyll/astro static-generated page and be fine. But if you shove a database and php in the middle, it’s gonna be multiple orders of magnitude slower.

throwaway17824 3y ago

Once when working in devops I asked my team lead why we didn't just move everything to Heroku, rather than reinventing a bad in-house version of their features. I was firmly told not to suggest it again unless I wanted to put all of us out of a job. That seemed ridiculous to me — we had a laundry list of ways we could help the business if we got basic platform stuff off of our plates. But I sure learned something about how incentives affect otherwise-good engineers.

deleted 3y ago

[deleted]

febed 3y ago

Since you seem to have multiple successful and scalable deployments under your belt, what is your goto tech stack?