-
Maybe I’m just getting old and cranky but it seems like everything takes vastly more work, time, and ceremony than it used to back in the dark ages of pets-not-cattle and mutable infrastructure, with no real improvement in reliability or cost. (I know the customary response is that we’re solving harder problems at greater scale, and of course some folks are, but a lot of us are working on problems and at scales not that different than ones we were working on ten years ago.)
-
At the scale I operate at, this is definitely true. I used to run jobs on local university clusters, but eventually moved to Cloud stuff out of necessity. It was the thing everyone was doing, and in the face of declining support for local clusters, it was the best way to quickly spin up a cluster-like computing environment. But recently, I was given access to an old-fashioned university cluster again, with traditional job-submission tools, and it’s been great. I can submit a job that runs across 64 CPUs with almost no configuration. I don’t manage any infrastructure! There are no containers! I love it.
-
I think containers have been pretty badly pitched in some cases because people end up seeing containers as VMs, when in fact they’re more like virtual filesystems for a program + some isolation. Like containers can be extremely lightweight
If you are able to set up the container infrastructure properly you end up being able to isolate a lot of tricky components and share this configuration. This actually isn’t much of an issue with newer programs (I don’t understand people who put Go programs into containers…).
But, if you have software that depends on things like the host system’s font stack (PDF rendering, for example), or something that needs to be running with an old set of libraries (but you don’t want to pollute the host system with this stuff) containers work extremely well. For certain purposes, the isolation lets you provide (basically) single binaries to get things working and destroy the “works on my machine”-style issues in a lot of scenarios.
A bit ironically, containers are great for old software and a lot less useful for newer software.
EDIT: also, RE mutable infrastructure… even when you get to a relatively small setup (like 8 or so servers), it’s extremely easy to start having issues where your configuration is desynced from the reality in mutable infrastructure land. Trying to recover a server’s state after a reboot, only to realise that you did a one-time fix when you first deployed your software 2 years ago and it got lost in the reboot is really rough.
kubernetes is complated for sure, but if you really get into the headspace of something like salt stack it can feel nicer. There’s a big learning curve but after you get it, it can even be faster even for a single server.
-
Well you’ve still got to choose tech appropriate for your problem, that problem will never go away :)
-
-
I wanted some comments on my blog recently without using disqus and preferably without needing a server at all as the blog is already static. I ended up putting together a prototype that uses AWS lambda to handle comment submissions and generate a static json index file which can be read by some javascript.
Runs for free and works well enough for low traffic sites: https://github.com/joealcorn/chatter
-
At some point, I wanted to do something similar. The only sore point is it was unclear for me if you can prevent lambdas from running in parallel. Otherwise, you have a small race condition when you regenerate the JSON index file. It’s solvable by using Dynamo as a distributed lock. Or by not doing anything: as long as you have comments flowing (which is likely if you have a race condition), the index will become correct at some point.
Thanks for sharing the code!
-
I got around the issue of needing locks (wanted to be completely server-less and essentially free to run) by having the index generation regenerate the entire index rather than update the existing one, but there is another race condition with my solution.
The way it works at the moment is:
- Have a lambda function write new comments to a bucket with a flake id as the filename (so they’ll be roughly time ordered)
- Have a second lambda function to generate the index file that will execute when certain events are fired on the bucket (file created, deleted, updated)
The race condition I hit is because of S3’s eventual consistency - when the generation function runs the newly created comment might not show up in the file list. My solution would be to kick off the generation function on a delay, but this has not been implemented.
And of course, if you’ve many many comments the index generation will slow down, but this works fine for my use case.
Zappa makes all of this really easy to manage, I wouldn’t want to use lambda without this tooling.
-
-
I’ve yet to use k8s entirely because it seems like complexity that I do not need right now, but this point seems like a good one to me. Of course every system is still unique, so I’m not sure how far that goes.