Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes?
I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it.
I wish more tools and platforms were like this.
Isn't this just labeling the knowledge that you don't have (and could probably read up on) as potentially unnecessary complexity?
I mean, every time I hear about embedded, I keep hearing about byte boundaries, RTOSes, compiler chains, musl, JTAG, and a million other things that make my mind numb. But I assume embedded engineers need to know all those things, because of the constraints unique to their field. Some of them could be just "a complex way for engineers to keep themselves spinning their wheels and not actually working on an application", but a lot of them provide value in the real world and solve some specific problem.
Cloud infrastructure management frameworks are the same.
I guess I was comparing it to how things were (or more precisely, how I perceived things) 20 years ago. You'd rack a server or two, install Linux, stick the application in /usr/local/bin, make sure Apache was set up, and you were off and running. Simple enough. It probably didn't scale to 2020-sized Internet user counts, though.
That sounds incredibly complex! :) Where would you find a place to rack a server? Are there minimum rates for such a place, or can you rack a single server for one month? Would you be able to rack it yourself? What if there was some problem with the PSU, and the server lost power when the data center was fine? What if the network card failed? What about if a hard drive in the server blew out?
Cloud infra in 2021 infrastructure has pretty turnkey answers to all of those (Kubernetes is not one for any of the ones I mentioned, except maybe for “what happens when any node goes down“). So yes, the complexity might be high, but so are the capabilities.
I mean, maybe you are running a mom-and-pop shop with a server rack in the basement for some reason, and have pretty daytime-specific hours. That's fine, and I still think you can do the server rack thing. Or at least that's the way I see it.
Perhaps one piece of meta-commentary here is that server hardware has not become substantially cheaper, faster, smaller, and easier to set up since 20 years ago. I can't really set up a server in my small bedroom that's capable of serving 10k concurrent users, and doesn't deafen me with its noise. Maybe if I did, all this cloud stuff might be less ubiquitous?
Because everyone else is doing it.
Things have gotten so complex that we need complex solutions, but w're afraid to make and own the solution ourselves because of cost, focus on core business or recruitment/knowledge concerns. So we need to find the next best open source solution to leverage the collaborative effort to reduce time and cost and have a large community to fall back on for support. And because everyone jumps on board of the same train all use cases must/will be accounted for (else the solution will fade into a niche), meaning the solutions becomes a problem in and of itself.
Repeating the cycle once again.
Running a cluster across your IOT fleet (1k+ devices; 5-10 apps each) gives a nice interface for pushing out tasks, choosing applications for a device, configuring supervisor-device relationships, etc. It turns out from scratch Docker containers on ARM are very portable.
I think you’re being dramatic — embedded is notorious for crazy builds of weird config flags to even get “hello world” to compile, and you’re waving your arms pretending that concepts from Erlang abstracted away from the language are too much.
Docker is just cgroups and namespaces, with a zip file of code. More or less literally.
Orchestration is the same mess it’s always been — back to at least the telephone days, when Erlang used the same concepts.
When you start having a lot of pieces to manage eg. cache, database, auth, multiple applications then Kubernetes comes into its own.
Because then you can scale, monitor, trace, debug, log, backup, audit, encrypt and visualise all of those pieces in exactly the same way.
And do it irrespective of which cloud you use or whether it's even in the cloud at all.
I’m not telling people what to do, if you like K8s or Docker or what have you knock yourself out, and I mean it. For example, people keep telling other people on HN not to use React and that’s a hill I’d die on - and could write a dissertation defending it. I’m just wondering what the dev experiences of others are so I may learn from them.
All the tools you mention are not integrated into your app neither change how you write code. In fact your application shouldn't even know what service mesh you are using.
I can write a back end application once and then have it run with istio/linkerd/traefik/whatever with zero code changes.
That doesn't happen in the Javascript world. The choice of framework directly affects your code.
https://azure.microsoft.com/en-us/services/app-service/conta...
Can't afford to test my luck until I've finished migrating all my accounts off my gmail.
Honestly, creating a second google account might itself increase the chances of getting banned. Nobody knows with Google, and that's the problem.
I created a new google account with no relation to my main one and added it as an owner to my GCP project, so hopefully in the event of either account being banned I can still access everything.
Luckily, there are lots of other Google services for that that you can plugin for that sort of stuff. Cloudrun is great if you are planning to use those things.
Kubernetes is what you use when you want to mix stateful and stateless stuff so you can avoid depending on those services. That makes sense if you need to support multiple clouds or on premise installations. But otherwise, it's a lot of extra complexity and devops even before you consider the overhead of managing the kubernetes cluster. There are lots of companies that talk themselves into needing this where the need is arguably a bit aspirational. I've been on more than one expensive project where we served absolutely no traffic at all with hundreds of dollars worth of kubernetes clusters idling for months on end that had no realistic hopes of ever getting more than a very modest amount of traffic even if everything worked out as they planned.
Edit: fixed name
Just to illustrate the point, dokku's docs[0] for logging say "Warning: The default docker-local scheduler will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server."
Alright, well, that's gonna be a whole lot more work than two click in Heroku to send all my logs to any logging provider of my choice.
I just enter my Honda Civic and drive to my office. Simple. I call it "Sedan".
(Honda Civic driver looking at an 18-wheeler in the highway and not understanding why somebody would use that)
In all seriousness though, Kubernetes solves a specific set of problems. Just because you personally don't have these problems, doesn't mean that Kubernetes is bad, or that people who use it, don't need it.