Indeed, I think I came to the incorrect conclusion! Just signed up for a subscription after getting through quite a lot of API funds!
3,685 karma · joined May 3, 2010
https://lithus.eu - We run your infrastructure so you don't have to. Managed Kubernetes on bare metal in Germany. ~50% cheaper than AWS.
So yes with Claude Code you can grab the Max plan and not worry too much about usage. With Aider you'll be paying per API call, but it will cost quite a bit less than the similar work if using Claude Code in API-mode.
I concluded that – for me – Claude Code _may_ give me better results, but Aider will likely be cheaper than Claude Code in either API-mode or subscription-mode. Also I like that I really can fill up the aider context window if I want to, and I'm in control of that.
In this case, the disks being in a ISO27001 data centre with processes in place to ensure erasure during de-provisioning (which Hetzner is, and has), may well also meet this criteria.
Even so, two of the major hurdles we see companies facing are:
1. Skills/Training/Hiring – Converting a staff of engineers familiar with AWS/Azure/etc to a new provider isn't necessarily straightforward.
2. Migration & disruption – Untangling one's integration with AWS/Azure/etc, finding and testing replacement services, planning the migration, executing on the migration. All this can cause disruption and delays in actually working on what's important.
What we do is provide multi-AZ bare-metal Kubernetes deployments onto EU providers (we default to Hetzner, but are flexible, and can do on-prem). As part of this we: a) include monthly DevOps engineering time dedicated to each client, and b) handle the migration planning and execution.
We're really trying to help companies (particularly SMEs & startups) make the jump. We try to mitigate the skills issue by providing actual engineers integrated with your team. We try to minimise the disruption by handling the migration in parallel to ongoing development cycles/sprints.
If anyone wants to know more you can reach me at adam@ domain. I hope this was interesting and not too much of a pitch.
[1]: https://lithus.eu
I'm really very surprised by some of the observations being made here, just because they are very contrary to my experience. Thoughts in no particular order:
- Hamburg's road systems took some inspiration from those of LA. To me Hamburg seemed exceptionally road/car heavy. Munich in comparison seems much more sane and European.
- The startup scene is great. I'm a member of the Werk1 co-working space there, and it is a huge and friendly community.
- Munich drivers are really great with cyclists. I eBike everywhere, and never have a had any problems with a car endangering me. They are exceptionally good at giving way to anyone in the cycle lines (bike, eBike, or scooter)
- For me it is a really very clean city.
- The English Garden (bigger the Manhattan’s Central Park) is a place of absolute magic in the summer. Floating down the river through a forest in the middle of the city?! Amazing.
- People are indeed super friendly when you talk to them. They don't do much needless smiling, but they are warm and friendly. (I'm white and look fairly presentable, and I cannot rule out that being a factor)
- You drive to the Alps in 1h ish. True, you cannot see them from them from the city. But it not much time you can be at the top of a ski resort.
- I think the comparison to Austin TX is very fair. Bavaria is conservative, Munich is not.
- The U-Bahn is pretty reliable, the S-Bahn less so. I cycle or e-scooter everywhere, so don't really notice (and even when it rains it really isn't that bad, said as a Londoner).
- I think there is more of a culture of having a stable job at large companies, perhaps in Germany in general (vs the UK). And I can see Munich feeling like 'a place people come to work' if you hang out in those groups. But I think there is is more available than just that.
The thing that really gets me is that one of the reasons it is hard to hire non-cloud engineers is the pressure applied by the cloud companies. Either because they hire those engineers, or because they do their upmost to ensure everyone reaches for AWS Lambda instead of systemd (which, in many cases, would do the job just fine).
Anyway, I could bellyache about this for hours (and, of course, the cloud does have its place), suffice to say I agree.
[1]: https://lithus.eu
If scaling really is on the horizon, then yes, doing k8s immediately will save you some time in the long run. If that is the case though, you could always reach for a managed K8S service first (EKS/GKE), then deploy to dedicated later. Just avoid any entanglements with other proprietary cloud services, because that will be time consuming to untangle later.
[1] lithus.eu
/pitch
Speaking off-the-cuff (so don't hold me to this):
If you need multi-node for (fairly good but not amazing) reliability, then the easiest first step would be a cloud instance, rather than bare-metal server. Given live migration, they are effectively multi-node.
If you need multi-node for performance, then get a single dedicated bare-metal server. They can pack a huge punch while being cost effective. And you'll likely get 100% uptime in a good year.
If you need multi-node for reliability & performance, then kubernetes.
Our experience has been excellent, but we also design for the platform. Redundant dedicated networking, multi-AZ, networking failover, RAID, k8s, Mayastor, etc.
The worst issues we see are occasional scheduled outages of an upstream router. This will take out an AZ for external traffic for about 20 mins, but the internal dedicated network will ensure internal services all stay up and quorate.
It’s not cheap, but it’s still cheaper than AWS.
I think their dedicated offering is probably more stable as it has been around longer, and it is also much much simpler. They need to provide networking, power, and finance the hardware. All of which is very much solved problems.
(We’re https://lithus.eu, if anyone is interested. You can contact me at adam@…. I’m on holiday this week, but back next week)
This is a symptom of societal unfairness. In this case there are different ways to react, but this is one of them. Tennis isn’t oppressing anyone, so no one is getting emotional about the pro tennis players knowing all the tips.
But the story since the 70s has been that you can have anything you want if you just work hard enough and are skilled enough (particularly in North America and the UK). Which means that if you don’t have something you want, then it is no one’s fault but your own.
Except in realty there are a whole host of external factors that influence once’s ability are accrue nice things.
It’s hard to reconcile these two things in our minds. We don’t have any narrative except the current one. So either we accept that we’re simply not good enough, or we accept things are broken with no solution. The former is often the most emotionally tolerable.
So when people see people with more than them, they don’t think, “good for them, we all choose how much we want to work for and I’m happy at my level”. Instead there is a collision of irreconcilable thoughts, and what comes out is, “they’ll never know what true love is”.
I didn’t realise this! The UUID spec mandates some values for specific digits, so I assume this would not be strictly valid UUIDs?
I fairly strongly disagree with this. Database identifiers have to serve a lot of purposes, and natural key almost certainly isn’t ideal. Off the top my head, IDs can be used for:
- Joins, lookups, indexes. Here data type can matter regarding performance and resource use.
- Idempotency. Allowing a client to generate IDs can be a big help here (ie UUIDs)
- Sharing. You may want to share a URL to something that requires the key, but not expose domain data (a URL to a user’s profile image shouldn’t expose their national ID).
There is not one solution that handles all of these well. But using natural keys is one of the least good options.
Also, we all know that stakeholders will absolutely swear that there will never be two people with the same national ID. Oh, except unless someone died, then we may reuse their ID. Oh, and sometimes this remote territory has duplicate IDs with the mainland. Oh, and for people born during that revolution 50 years ago, we just kinda had to make stuff up for them.
So ideally I’d put a unique index on the national ID column. But realistically, it would be no unique constraint and instead form validation + a warning on anytime someone opened a screen for a user with a non-unique ID.
Then maybe a BIGINT for database ID, and a UUID4/7 for exposing to the world.
EDIT: Actually, the article is proposing a new principle. And so perhaps this could indeed be a viable one. And my comment above would describe situations where it is valid to break the principle. But I also suspect that this is so rarely a good idea that it shouldn’t be the default choice.
Which is bizarre. But to me it is (apparently) the small of new electronics, plus perhaps the ‘hot dusty things’ smell. It also comes with the memory of playing Pod (a racing game), by Ubisoft (I think). Good teenage memories!
I’ve always felt that streams should be implementable via stored procedures, and that it would be a fun project. I’ve just never quite had the driving force to do it.
In the case of a queue, you put an item in the queue, and then something removes it later. There is a single flow of items. They are put in. They are taken out.
In the case of a stream, you put an item in the queue, then it can be removed multiple times by any other process that cares to do so. This may be called 'fan out'.
This is an important distinction and really effects how one designs software that uses these systems. Queues work just fine for, say, background jobs. A user signs up, and you put a task in the 'send_registration_email' queue.[1]
However, what if some _other_ system then cares about user sign ups? Well, you have to add another queue, and the user sign-up code needs to be aware of it. For example, a 'add_user_to_crm' queue.
The result here is that choosing a queue early on leads to a tight-coupling of services down the road.
The alternative is to choose streams. In this case, instead of saying what _should_ happen, you say what _did_ happen (past tense). Here you replace 'send_registration_email' and 'add_user_to_crm' with a single stream called 'used_registered'. Each service that cares about this fact is then free to subscribe to that steam and get its own copy of the events (it does so via a 'consumer group', or something of a similar name).
This results in a more loosely coupled system, where you potentially also have access to an event history should you need it (if you configure your broker to keep the events around).
--
This is where Postgresql and SQS tend to fall down. I've yet to hear of an implementation of streams in Postgresql[2]. And SQS is inherently a queue.
I therefore normally reach for Redis Steams, but mostly because it is what I am familiar with.
Note: This line of thinking leads into Domain Driven Design, CQRS, and Event Sourcing. Each of which is interesting and certainly has useful things to offer, although I would advise against simply consuming any of them wholesale.
[1] Although this is my go-to example, I'm actually unconvinced that email sending should be done via a queue. Email is just a sequence of queues anyway.
[2] If you know of one please tell me!
Maybe it’s late here, or maybe I’m just cynical - but what does that sentence even mean anyway?! It’s an app, it’s visual, why does this even need stating? How was this even a notable result from any kind of research?
/grump
He also pioneered the use of seat belts while at Ford. Which does make the morality-math a little more unusual.
We move companies onto bare metal, effectively giving them their own private cloud. This about halves their costs, doesn’t impact their engineering team as we handle the migration, and then we also include ongoing monthly engineering time to support their infra team. Overall it is a win-win for everyone (well, except AWS)
However, in the off grid-setting I did discover some nuance. Sometimes you could really do with some power around sunset or sunrise. In the winter, being able to more reliably run my air-source heat pump at sun-up would have been very handy. Or likewise, some extra power to run the AC (which is the same device) in the early evening in the summer would have also been handy.
There were plenty of cold mornings when I was keeping an eye on the solar grafana dashboard, waiting for that hockey-stick moment when the sun swung into the right place!
I did consider the possibility of setting up an additional east or wast facing array to capture sun at the extremes of the day. Unfortunately that would have required its own MPTT charge controller, and would have just been more complexity in general.
We handle the issues the the sibling comment mentions. We do the migration to bare-metal, and then also provide DevOps engineering time as part of the package. We generally cost around 50% less than the cloud providers, core-for-core.
[0]: lithus.eu
But we specialise in this so that our clients don't have to. As much as I do actually love Kubernetes, the fact that the _easiest_ way to self-host Sentry is via Kubernetes is not a good sign. And choosing to spin up a Kubernetes cluster just to run Sentry would feel a lot like the lady who swallowed a fly[0].
[0]: https://en.wikipedia.org/wiki/There_Was_an_Old_Lady_Who_Swal...
As others have said, we've [0] found the only practical way to deploy this for our clients is Kuberentes + Helm chart, and that's on bare-metal servers (mostly Hetzner). It runs well if you can throw hardware and engineering time at it, which thankfully we can. But given the option we would love a simpler solution.
[0]: https://lithus.eu