I mean it makes sense in a way and I'm not saying it is a bad thing, just a pattern I've noticed.
E: hehe there it is, they’re already here
Seeing some of the replies to tweets that appear here I’ve lost faith in the HN audience’s ability to observe and discuss
Pattern, not problem :)
You can ask the cloud to deploy a container to Kubernetes. You can rent a VM with Hetzner. You can rent rack space in a data center. You can build your own data center. You can build your own server hardware.
Depending on the scale you operate, you'll draw the line somewhere where it makes sense to you (which may change over time).
Dev teams will still operate best when they can deploy containers to Kubernetes and without having to design their own server hardware. You now need to build abstractions in house. Maybe you can sell these to other people? Congratulations you are now a cloud provider.
As others have pointed out it is relatively easy to deploy small k3s clusters on Hetzner Cloud.
I can confirm that. I've been running a few servers with them and my experience is that the older ones had a failure every 2-3 years. Usually it was a disk, sometimes the power supply. Once 2 of 3 disks failed but I managed to rebuild the array (it was the HDD era so it took several hours), no data needed to be restored from backup.
But since 2018 I had no failures at all. And I'm happy to see their ecosystem grow.
Jeez really? We have like, binaries deployed to machines over here.
Realistically I wish someone would just write an orchestrator that runs Go processes and nginx and glues it all together.
Not quite what you're asking for but you can get close, on bare metal, with:
- ssh to set up a systemd service, scp to deploy your binary, then ssh again to restart your service
- dokku (containers are optional) with its cli
For the first option, once you've set up nginx on the server you can easily automate the addition of a new systemd service for a new app with a simple shell script. That done, it is a matter of less than a minute to add a new app and even quicker to update and restart an existing one.
For the second option, it is installed with a single bash command and supports Heroku build packs which means for many systems there's virtually (or exactly) no config needed. Just run the cli from within your app folder. If you do want containers they are automatically found and deployed too.
I've done most deployment methods from the simplest (above) through to complete Terraform builds, and once they are automated all that matters is that the method you choose supports your needs. Go for the simplest option that does that.
"Marketing" as you said, made this concept of "container", but I think using the words "process" and "namespaces" is still ok.
I'm not saying "marketing" as to say it was coined by non technical people, but rather that it's a way to "sell" the feature. Like you go see your manager and say "I'm going to containerize the application" vs saying "I'm going to add some isolation settings to the process"
It may not be fatal to your business; it's not going to be a top 3 reason you succeed or fail! But it does make a difference.
To stay in your metaphor, moving faster is not a guarantee to arrive at your target earlier. As long as everything works fine, using k8s is great. When you have to dig deep to solve a problem, a stack with less layers might be a huge advantage.
The machines were there fully paid. But w aws I’d be up in 10 minutes w a lot less arguing . I’m convinced this might be part of AWS edge in big players
Then you get into serverless and suddenly they can’t log into production anymore, and they have to instrument their code, and work within finite resources - all that stuff they ignored in college about manipulating datasets larger then core memory are suddenly relevant.
When we did our transition to serverless we found that the people who complained the loudest about their traditional servers being mysteriously corrupted were actually the same that had obtained admin rights “so they could work faster” and were going into the servers and blowing away configuration files, altering permissions, and making other changes. Once there was no more ssh and no more root privileges our outages dropped two thirds. Today it’s mostly third party outages impacting us and people deploying untested code to production.
What we did find is our operational expenditure over three years tripled. So basically capital expenditure.
I’m not sure how they warped that into self congratulatory success.
The people complaining now complain that it turns out the promise of total automation was a lie. None of it is very robust and all of it is painful.
From a maintenance perspective, it's brilliant. Over time, cruft accumulates on my VPSes however disciplined I intend to be when I spin one up. Now, I no longer have to remember all of the ugly hacks I had to implement to get a particular new app I wanted to try out working, I just deploy and it's done.
Because compared to a staff of 50 doing anything the costs of an ec2 instance for a week are irrelevant?
Because finance already has AWS in system as a vendor?
Because pricing is public?
Because costs hit your budget not ITs so you have more authority?
Orgs can easily spend 5x what it would cost internally on AWS because of friction avoiding factors like this.
Setup one that doesn't eat your wallet is what makes it hard.
Let's also be realistic here: CloudFront is a good solution if you need a file to be served over CDN with low latency in multiple regions. Raw s3 or just a web server is much cheaper if you don't need low latency over multiple regions.
US offerings being way more overpriced than EU alternatives also boils down to the much larger capital/war-chest US tech companies have at their disposal to spend on Ops to conquer a market, a fact reflect in those prices but also in things like dev salaries, office equipment, etc.
EU offerings are better priced because most EU companies, who aren't bankrolled by some mega VC fund, cannot afford to pay US levels of pricing.
Using Cloud services that are obviously more expensive than self-hosted options reduces both numbers- less time to launch stuff, but less money. The point is that in early-stage startups, the costs are so low that paying an order of magnitude more for Operations may not move the second number by very much at all, since most of the money is paying for developers.
How many companies actually shift their infra vendor?
Granted, thinking about this up front is ideal, but it’s better to start an mvp and build from there than to be paralized by perfection at the outset and not build anything at all.
If I'm targeting AWS, Azure, etc. Then I'm going to leverage their services in a lot of cases. Wether it's AWS Dynamo DB, or hosted PostgreSQL, there are places you will save in either resources or personnel.
A set of Dokku servers behind a load balancer can go a long way. Kubernetes further still. Taking the issue of DB management, static assets or backups goes a long way to freeing up time to make solutions without buying into lockin too much.
Startup: use <aws|azure|gcp> because it's quick to get started. It's easy to scale it up 100X in 5 minutes for when you make it big. And it provides a long list of easy to use services that are overpriced per use, but which free you to focus on your business rather than complex DevOps.
Then once you scale to the point that you're comparing your salaries and your ops cost, you find smaller services to handle the expensive part of your business. Ones that do exactly what you need, not much else, and charge accordingly. Maybe they're self-operated, or maybe they're other companies with a narrow focus.
Then you write a blog post about how everyone is crazy to use <cloud> since it's so expensive, and you don't know why you ever thought they were a good idea.