People looked at me like they saw water burning but that would have made the dependency on the US a lot easier to sever. Just move the VM's.
To me it's like anything else in engineering, are the costs, risks, and benefits fully understood, and worth the tradeoff in the particular context.
I worked for a startup doing internet of things, the consumer would buy a device and get lifetime service baked in. And that company was a step further, just renting space in a colo was incredibly cost efficient, which supported the sales model and competitive landscape of that product. But it was also very costly to attention, one of the most valuable resources. But it can also get costly in non-intuitive ways, an example that comes to mind is we started to get interviews where a generation of candidates no longer had experience with metal, it was a foreign world to them.
With more experience, I find it's really the costs that get severely underestimated, both for and against the suggestion.
At some point, you have people (on here and elsewhere) questioning what all these people in an organization do. PART of the answer is that they're doing internal work that could have been outsourced in various ways.
In fact, I had no idea our static website at a scale-up in 2019 was costing us 90€/month; it came up when we were told to cut costs. Developers don’t always have a say in these things.
Heck, I then went and got a series of certifications in GCP. Even then, I’m not sure I’d understand the full complexity and pricing options of GCP. Smaller clouds and simple VPS solutions really are the overlooked option.
Unfortunately this is neither the case for very large, or very small companies.
Very large companies may have some experience, but it is usually legacy. Or buried under processes and politics.
Small companies will not have the experience to make the analysis
The machine is a beast and I can serve a lot of users with it. In fact, and quite funnily, I already serve much more users with it than a lot of my older clients do with their software running on expensive k8s setup because „scale“ :-)
And last, but not least, I had a lot of fun building it. Its just nice to hear that thing humming away in the corner.
Honestly even if you have a single server, running k8s (or maybe Docker Compose for really simple cases) on it is still the simplest way to manage it (assuming you have more than 1 service, anyway). One configuration file format, one CLI tool, zero special paths to memorize, no filesystem permissions to configure, pretty good security out of the box, access to a whole bunch of helm charts and operators (for example, cert-manager, external-dns, prometheus, alert-manager, some logging operator for centralized logging with a decent UI and search, and a postgres operator for backups / replication / failover), etc.
It’s also worth noting that Kubernetes is conceptually quite simple—once you realize that it’s just a database of resources that are being watched by controllers, things start to click into place and it feels much simpler.
In some sense Kubernetes is a bit like democracy or capitalism—it’s the worst in its class except for everything else that has been tried. :)
Same situation with Kubernetes. Google could have built something else and they still would have succeeded at doing what they did.
In my opinion, everything you wrote are opinions. Installing and managing rke on bare metal was more difficult than doing the same with nomad for me.
Or another example, installing clickhouse using apt was easier and worked better than doing it with docker.
In the end we can do what we can do because we learnt the tool and the problem. And the tool is sufficient.
Argument about the quality of the tool is too difficult unless we know all discussed tools in-depth
Maybe Google could have built something better than Kubernetes, but my point was that this doesn't do me any good. I can't _use_ the hypothetical better-than-Kubernetes product because it's hypothetical. So in the world of things that actually exist, Kubernetes is best in class despite the many valid criticisms of it.
> In my opinion, everything you wrote are opinions
Yes, my comment was my opinion.
> Installing and managing rke on bare metal was more difficult than doing the same with nomad for me.
Maybe Nomad is better. I haven't used it. I'm skeptical that it has the ecosystem breadth that Kubernetes has, but I'm happy to be wrong.
> Or another example, installing clickhouse using apt was easier and worked better than doing it with docker.
That's not really a useful comparison because (1) a system typically involves a lot more than just a singular database and (2) running a system involves a lot more than getting the software onto the machine. If you want to make a meaningful comparison, you need something like Ansible or Cloud Init to invoke apt and to wire everything together and at that point Kubernetes is _likely_ already easier. Especially when you consider logs, metrics, certificates, DNS, etc.
We can go with your idea, sure: a few months in, an Account Manager from the cloud provider shows up and says your bill could be reduced by 50% if you just adopt some changes, using their custom, super optimized tools (“minor changes” will be the mantra).
And now you have your own company looking back to you on how can they get those savings, people who don’t understand what a VM is and cannot differentiate salesforce from an elastic container, as everything is “cloud”, but heard “50% off”.
Further, it needs people in decision making roles who understand and value the strategic differences between having an infrastructure concept that is trapped in one provider's proprietary software tooling ecosystem (aws, azure, etc), vs things built on open standards that are portable.
And the reality is eventually you'll get a clueless one, and everything will revert to the mean.
And the mean is heavily influenced by marketing propaganda.
Most CTOs (and increasingly M2s and M3s) I've met are what I call "box architects". You know the ones who love drawing boxes, moving one box inside another box, drawing a line between 2 boxes or changing a unidirectional arrow into a bidirectional one, then declaring the hard part is done and now we need any random engineer to implement that or "Is there an AWS service that does that? I just don't see the value in us doing it in house".
A "super optimized tools" is just a box that you swap for another box and the "minor changes" will be just a couple of arrows than need to change or another box to swap for another box. You get them to feel good about doing architect stuff plus the 10x reduction in the bill. They can always replace that box with another box later after all.
If a car salesman told me I could save 50% of my fuel bill from driving their special car a certain way I'd laugh at them.
People who know the tech, no
Non-technical middle management types, yes. It produces revenue when done aggressively enough, google "solarwinds sales people" for many anecdotal examples of extreme persistence. Not that I agree with it.
I have a very hard time believing this, especially with fuel economy and emission regulations
It is true that fuel economy regulations make it much less practical to deliver gas guzzlers out of pure laziness. (As you may know, the Corolla GR is by far the most expensive of these options, because it's designed to achieve horsepower over mileage.)
2016 - lets use EC2, its just VM, we can move off
2018 - I see you are hosting your own PostgreSQL in EC2, you can use our managed solution
2020 - you are already using 18 our services (note, at this point you might still be using non-vendor products, like VMs, managed DB, and so on), why not use our IAM instead of rolling out your own auth.
2024 - you are now deeply locked, lets add more lock-in, why don't you use this tool to optimize your costs (welcome DynamoDB)
At this point, no one would ever question next tool from salesman. Because engineers see that company doesnt have strategy to move to another cloud, why should they reject this new tool?
also consider the people who are involved, a lot of times after 2 years you have totally new people in your team, they won't have context and constraints you had in the past when deciding to buy "just VM", they see it as "we already use AWS"
I would do a calculation based on their public price plan and come up with a 5-10x price compared to the bare metal OVH solution that perfectly fit our use case. I would then ask the sales team where I made a mistake in my calculation and hear nothing back.
A few months later, they would come back with the same pitch and the whole process would repeat...
The cloud makes it simple. They offer you managed service X. They hire experts for service x and you pay a part of the cost on top of your infra cost. No searching. No vetting. You just use the service.
I see the why this might be attractive. It isn't to me. But the pencil pushers like it.
To some management types it looks like a good deal to not deal with that and just let Amazon/Microsoft/Google/etc. deal with finding people to support the service and just pay a bit extra to the infra cost. Then you can only hire cloud infra admins. I don't think it works that way but that is what I have observed.
Your engineers who all have to possess AWS or similar certs before you hire them, work for free?
A move off VPS to managed services doesn't reduce your headcount or labour costs.
I think there is a very narrow space where you need the resources that this provides and it's not yet more cost effective to have your own team of admins. At a certain headcount a the number admins don't matter that much anymore.
If you're using managed services that are so complex you need certified people then you're doing it wrong
Another advantage of AWS is permission management, automatic RDS snapshots, cloudwatch comes out of the box...
You can do everything with VMs, but in practise it's probably much harder.
It's the new "Nobody ever got fired for buying IBM".
I don’t blame people for being skeptical
Beyond that, I just don't understand your point of view at all. Do people unironically think there is some super special dark magic being done in the bowels of Amazon, as opposed to just...code that runs on (virtual and physical) machines? The open source community yielded Linux but it's just sooo impossible for it to yield an object storage service? What a strangely shackled view of the world.
Well... yes?
What do you think the AWS S3 and DDB is running on? Fairy dust?
That's a different argument to the one I replied to, and the reply to "they have expensive infra people" is "you have to have expensive product-trained people to use them anyway".
The suggestion was to replace DBB and S3 with some VMs. Presumably those VMs would be managed by the engineers part of the parent commenter’s organization. They do not have access to as many engineers as AWS, nor do they pay them as well.
Not arguing about cost effectiveness here. Just pointing out how silly it is to suggest that you can replace DDB/S3 with some VMs ran by a midsize organization
I don't blame people for being skeptical
I can appreciate the desire to close gaps on expertise deficiency and make a vendor responsible, but the whole schtick of 'outsource everything and focus on your business for advantage' always rang to me as just an excuse to give our money to vendors.
Its almost as if the whole case for vertical integration is just taken as a wash
The original promise of the cloud is "you pay us less than you pay your sysadmins", which is not entirely unreasonable, especially at early stages.
Of course running on bare metal from Europe's own Hetzner is even more cost-efficient, if you already have a lot of sysadmin chops.
Unlike most VPSes