I've been a long-time fan of Mikrotik. I even ran an ISP on it a fair while ago. I have a couple of archived GitHub projects if they are useful to anyone:
- Router OS Diff - Can diff two configs and give you the commands needed to bring the existing config up to date with the desired config. It's certainly not perfect, but a starting point of anyone needs something like this. [1]
- Netbox Routeros – A netbox plugin for updating the config of RouterOS devices directly from the Netbox interface. [2]
It has been many years since I touched these, but perhaps they will be of interest to someone.
Aside from that, I have had excellent experience with Mikroik. Everywhere from in-datacenter to it running in an off-grid hut on a mountainside. I've even heard reports of people finding rain streaming through a CRS and it just happily ticking along.
And yes, adding a Redis cluster is fine, it is just another moving part to manage. But given that the alternative is made out of unobtainium, I guess that is just the way of it :-)
> One, it would be cool to be able to embed it, similar to sqlite, directly into applications.
I've found myself wanting this on several occasions too. I.e. wanting all my rust backend processes (k8s pods) to have some minimal shared state, without having to spin up a Redis cluster. I've talked to Claude about it a couple of times, and it descends into something like, "you gotta use Raft or CRDTs, and pick 2 out of 3 from CAP". Which honestly seems pretty fair, and indicates to me that I'm dreaming for something magical.
Nonetheless, it is nice to hear someone else asking for this. If this is indeed feasible (even if simple/limited), then I'd be interested to try it.
> which you can only obtain by having a strong CS base and coding manually for years.
I hope this isn’t the case. It is the route I took, but it also doesn’t seem to be a likely route going forward. Strong CS grounding is feasible for sure, but I have a hard time believing that a meaningful number of people will be spending the requisite years coding manually.
I’m not sure. We’ve always had to pick the level of abstraction we start teaching at. Voltages, transistors, registers, assembly, C, etc. This feels like it could just be a progression of that.
I've been wondering if there would be a benefit to inverting how we teach subjects now. Previously we would teach from the bottom, and build up. Semi-colon goes here, curly brace goes there, and then build up to architecture, systems, etc.
But this doesn't seem to make sense when someone comes to a topic with an LLM in-hand. They need to know high-level techniques, architecture, best practice, etc. As they pursue the topic they start to get down into the details, although probably never learn to do it fully independently.
I quite like this view because it paints a somewhat optimistic way forward from where we are now.
I see a lot of conversation here about provider feature parity, but my hope is that sovereignty doesn't have to be strictly about the region or company you choose. For me, the strongest form of sovereignty can come at a lower level. That is, running on an open-source stack you can pick up and run somewhere else should you need to. If your data and workloads live on standard Kubernetes with Postgres, object storage and the usual Prometheus/Grafana/Loki, then no single provider (EU or otherwise) actually has you over a barrel. As the article points out, the "AWS Europe is a separate subsidiary" argument does nothing if the software still ships from the USA.
Shameless plug: We started our company[0] on this basis, i.e. managed Kubernetes on bare metal in EU DCs. We run everything on open source tooling, provide DevOps engineering time to our customers' engineering teams, take on the migration risk ourselves, and offer response-time SLAs. So yes I'm biased, but I did this because I do actually really believe in this approach.
So I'd flip it around. Perhaps building a sovereign hyperscaler is the wrong approach. I'd say we need workloads that aren't welded to any one provider in the first place. And open source tools have come a very long way since EC2 first came online.
FWIW - I also really like Wispr Flow, but I moved to running the 'Whisper Large' model locally using Handy (https://github.com/cjpais/Handy), which has been essentially as good, while also having lower latency.
Honestly, I still had to practically stand on the clutch with mine!
I'd teach someone to drive it and say, "now push down on the clutch". They they would heave and struggle, then eventually succeed and look victorious. I'd say, "well done, it is now half way down! But that's all you need for now!"
EDIT: To fully explain: It has a two-stage clutch. You half-press it and it disconnects the wheels from the engine. If you fully depress it all the way to the floor, it additionally disconnects the power-take-off shaft (PTO) from the engine. The PTO shaft is a spindle on the back of the tractor which drives things like your flail mower, wood chipper, etc.
EDIT 2: Edit 1 was for the general audience, not the parent commenter ;-)
Up until a year ago I was regularly using a Massy Fergusson 135 [0] (Perkins Diesel version), made sometime in the 1970s. It was wonderful! So amazing to drive and use. Clunky and heavy, but you really really felt like you were using a machine. In low gears, if you put you foot down on the accelerator the engine would roar, and your speed would barely change!
And there was no fancy technology in it at all. If I was in the forest and had forgotten the key, I'd just reach behind the dashboard and hot-wire it. The air filter was basically a shisha-pipe that bubbled the incoming air through wire wool and engine oil.
Its fuel gauge didn't work either. You just had to take a look in the tank, or quickly react as soon as the revs started dropping. I ran it dry a few times and had to sit there with a spanner in one hand and YouTube into the other, while trying to bleed all the fuel lines. But they were all on the outside of the vehicle, which made it comparatively easy I imagine.
I've never actually driven a modern tractor, so don't know how it compares. I imagine the clutch is easier on the knees these days!
Anyway, this just felt like the place to share this.
This is something we've[0] done a number of times for customers coming from various cloud providers. In our case we move customers onto a multi-server (sometimes multi-AZ) deployment in Hetzner, using Kubernetes to distribute workloads across servers and provide HA. Kubernetes is likely a lot for a single node deployment such as the OP, but it makes a lot more sense as soon as multiple nodes are involved.
For backups we use both Velero and application-level backup for critical workloads (i.e. Postgres WAL backups for PITR). We also ensure all state is on at least two nodes for HA.
We also find bare metal to be a lot more performant in general. Compared to AWS we typically see service response times halve. It is not that virtualisation inherently has that much overhead, rather it is everything else. Eg, bare metal offers:
- Reduced disk latency (NVMe vs network block storage)
- Reduced network latency (we run dedicated fibre, so inter-az is about 1/10th the latency)
- Less cache contention, etc [1]
Anyway, if you want to chat about this sometime just ping me an email: adam@ company domain.
We can run a Forgejo instance for you with Firecracker VM runners on bare metal. We can also support it and provide an SLA. We're running it internally and it is very solid. We're running the runners on bare metal, with a whole lot of large CI/CD jobs (mostly Rust compilation).
The down side is that the starting price is kinda high, so the math probably only works out if you also have a number of other workloads to run on the same cluster. Or if you need to run a really huge Forgejo server!
I suspect my comment history will provide the best details and overview of what we do. We'll be offering the Firecracker runner back to the Forgejo community very soon in any case.
We've migrated to Forgejo over the last couple of weeks. We position ourselves[0] as an alternative to the big cloud providers, so it seemed very silly that a critical piece of our own infrastructure could be taken out by a GitHub or Azure outage.
It has been a pretty smooth process. Although we have done a couple of pieces of custom development:
1) We've created a Firecracker-based runner, which will run CI jobs in Firecracker VMs. This brings the Foregjo Actions running experience much more closely into line with GitHub's environment (VM, rather than container). We hope to contribute this back shortly, but also drop me a message if this is of interest.
2) We're working up a proposal[1] to add environments and variable groups to Forgejo Actions. This is something we expect to need for some upcoming compliance requirements.
I really like Forgejo as a project, and I've found the community to be very welcoming. I'm really hoping to see it grow and flourish :D
Hello! I think this is a fair question, and improving the communication on the website is something that is steadily climbing up our priority list.
We're not really that kind of product company; we're more of a services company. What we do is deploy Kubernetes clusters onto bare metal servers. That's the core technical offering. However, everything beyond that is somewhat per-client. Some clients need a lot of compute. Some clients need a custom object storage cluster. Some clients need a lot of high-speed internal networking. Which is why we prefer to have a call to figure out specifically what your needs are. But I can also see how this isn't necessarily satisfying if you're used to just grabbing the API docs and having a look around.
What we will do is take your company's software stack and migrate it off AWS/Azure/Google and deploy it onto our new infrastructure. We will then become (or work with) your DevOps team to supporting you. This can be anything from containerising workloads to diagnosing performance issues to deploying a new multi-region Postgres cluster. Whatever you need done on your hardware that we feel we can reasonably support. We are the ones on-call should NATS fall over at 4am.
Your team also has full access to the Kubernetes cluster to deploy to as you wish.
I think the pricing page is the most concrete thing on our website, and it is entirely accurate. If you were to phone us and say, "I want that exact hardware," we would do it for you. But the real value we also offer is in the DevOps support we provide, actually doing the migration up-front (at our own cost), and being there working with your team every week.
https://lithus.eu - We run your infrastructure so you don't have to. Managed Kubernetes on bare metal in Germany. ~50% cheaper than AWS.