361–370 of 446 posts
Earlier quoted context omitted.
Or it could be that you just became old and don't want to learn new things anymore ))
Such "new things" are just a big bunch of unnecessary complexity.
By definition the "old things" you use would also be "just a big bunch of unnecessary complexity" since they were once new.
Earlier quoted context omitted.
Apollo reminded me more of Nix than containers. The wrapper scripts are super Nix-y :)
That's what it was. VM with a barebones deployment system that had a ton of hooks in it. Really really smart idea that IMO helped Amazon in the 2010s immensely. While everyone else was figuring out k8s and whatnot, Amazon had a good system with CI in place for years. I wonder how it's fared over time. Amazon was never known for internal tooling in many other places. I hope Apollo is still running strong today.
Reading through the comments, the options used by others for deploying on VMs (Nix, Rsync etc) seem much harder to manage. Curious if there are simple-r deployment strategies, or tools/services for deploying on VMs.
Earlier quoted context omitted.
> What works for us is to do the simplest thing that works, then iterate. The older I get, the more often I'm reminded that this un-sexy approach is really the best way to go. When I was younger, I always thought the old guys pushing boring solutions just didn't want to learn new things. Now I'm starting to realize that after several decades of experience, they simply got burned enough times to learn a thing or two h…
Jonathan blow had a great take on this that really spoke to me. I can’t do it justice, but paraphrasing as best I can: Get the simple to understand, basic thing working and push the harder refactor / abstraction until later. Leave the fancy stuff for a future engineer who better understands the problem. That future engineer is you with more experience with the actual problem.
With the average tenure of a software developer at a company being about 2 years, that future engineer is for sure some other poor soul.
Earlier quoted context omitted.
What was the problem you were having with Ruby (on Rails) and Nix? It wasn't ergonomic for me, but I was able to get things to work.
I think one of the main issues was depending on a custom gem. And then something about sandboxing, and outdated things being cached (maybe this was just a rails thing though). Also setting up rails project was convoluted. It was just obvious that there wasn't much time devoted towards that use case of Nix. The rails support was more of just to handle packaging existing software as opposed to being good for a developm…
I've not used Nix so I legitimately don't know (but I am quite interested in it)
Not sure if this counts, but for more than a decade I was at a telecom vendor, working with radio base stations (3G, 4G and 5G). That (to me), is probably one of the most distributed systems on the planet - we worked across several million nodes around the globe. I've been out of the loop for a bit, but I know they now have vRAN, Cloud RAN, etc (basically certain soft-real time functions pulled out of base stations a…
Earlier quoted context omitted.
> That's the easy part! The hard part is managing databases. Ding ding ding ding ding. "But what about disk?" (so, relatedly, databases) is the hard part. Balancing performance (network disks suuuuuck) and flexibility ("just copy the disk image to another machine" is fine when it's a few GB—less useful when it's lots of GB and you might need to migrate it to another city and also you'd rather not have much downtime)…
Sometimes I think K8s is largely pushed for Amazon/Google/Microsoft to sell the disk that goes along with it.
If you can stick to using Java the JVM can hot-deploy code in real-time without any downtime. It leaks memory but if your systems are minimalist you don't need anything else than one JVM process per machine for everything!