Or why should I target a bunch of different cloud APIs to make my tool consumable when I can target one?
Why target any cloud APIs at all if your product have a small amount of users? You don't need to scale up/down fast at if you're just at 3000 users. Throw it on a Linux box, write a systemd service and be done with it.
Most companies have small amount of users and don't have rapidly shrinking/growing user bases, meaning their infrastructure need is not rapidly shrinking/growing neither, in most cases.
Hence, Kubernetes being accidental complexity most people can do without, rather than necessary complexity.
I get why people say k8s is complex, but there really isn't another great option for running a containerized service based architecture, maybe nomad
But again, what specifically are you able to do in Kubernetes that you cannot do in Nomad? You mentioned it's not as "functional" but seems you're unable to actually specify what you mean by this.
> Nomad is built by a for profit company while k8s is purely OSS
Not sure how you can claim Kubernetes somehow is "more OSS" than Nomad? Both are under FOSS licenses (Nomad: MPL, Kubernetes: Apache) but both are mainly maintained by two big for-profit companies (Nomad: HashiCorp, Kubernetes: Google). They are both the same in this regard, both are the "same amount of OSS", whatever that means.
This is deeply untrue of Kube, it's maintained by lots of companies, and is in a totally separate organization than Google with distinctly different governance. Kube goes out of its way to ensure its not dominated by one organization and has stats on this. I haven't looked at the Nomad stats but I imagine its nowhere near that and still under the Hashicorp umbrella and pretty much only works with Hashicorp stuff.
> But again, what specifically are you able to do in Kubernetes that you cannot do in Nomad?
The big thing for me is API extensibility. The Kube CRD is one of the more powerful abstractions to hit infrastructure in awhile. The ability to create your own controllers and offer consistent APIs to an end user is imperfect but incredibly useful.
Other thoughts:
* Kube is supported by every major cloud provider.
* I'm not a fan of HCL, some people like it but I prefer Kube's approach of decoupling the templating from the core app.
What cloud APIs are involved in running Linux on a VPS? Backups for your VPS are often one click to set up, and the only vendor-specific service you need.
If k8s is ____, fly is ____.
I cant even compare fly to heroku, almost the same but different underneath.
I one day aspire to have the cajones of ilrwbwrkhv.
For the reference of other potential solo devs, if done right, Fly.io will still be cheaper than the Vultr 5 dollar micro instance (or equivalent) with an incomparably better DX.
You might be able to save a little, you might pay a lot more. Hedge your bet and use vultr.
My gut feeling is that if someone is going to struggle with optimizing for a relatively fixed target like Fly (the billing is extremely predictable compared to some other offerings out there, if not completely fixed), the chances are that they won't be cut out to do double time taking on what is effectively a Linux sysadmin role.[1]
[1] I may be completely wrong
Actual billing caps are very hard for cloud providers to implement with the HA distributed systems clouds use for billing, and would carry a significant performance cost. Alerts are the best you can do if you take the variable costs.
This means that I can't misconfigure my way to a three-figure-plus bill, which is hard to find in cloud providers.
(Even if we all acknowledge that it is one motivation for many tech fads).
Honestly, if this is on a resume the next question should be — tell me why you needed such a system…
Just as Magpies like their shiny trinkets, I like my shiny frameworks.
Like in sqlite or something like json files?