Such a terrible idea, let's build something that everyone else has a solution for, we're on our own with our custom solutions that no one else know or use.
We'll see how many years it will take them to come back to Kubernetes or equivalent.
And the argument k8s is too complicated so build our own looks really bad from an engineering perspective.
> They're the same service, because they're running the same image
If something purports to “run my containers” and “be an alternative to K8s”, I’d kind of expect it to run whatever it’s told. Whether running identical containers on the same host is a good thing or not really depends on your architectures choices and trade offs. Blindly being like “you can’t have this because reasons” makes this whole tool a giant non-starter IMO.
And use IP addresses like it was 1999 again. Your IP addresses belong to exactly one location, the DNS server's config. Using a non-type safe configuration language is also meh. I am not sure why most people are unaware of Dhall...
> And the argument k8s is too complicated so build our own looks really bad from an engineering perspective.
On the other hand, React is too complicated if you just need a bit of JavaScript on your mostly HTML/CSS page... So now you can use Hotwire if you like.
I don't see what's so bad about that (same things as MRSK and k8s)
I believe 37Signals is replacing their Capistrano-based deploy for Basecamp with MSRK. It seems they're keeping their k8s deploy setup for Hey. (Just what I'm inferring from the first two paragraphs here: https://world.hey.com/dhh/introducing-mrsk-9330a267)
Yes, we're actively de-k8s/de-clouding all workloads, including Hey, with mrsk as the pattern. We've started with simple apps and moved up our complexity tree, updating mrsk as we go. My co-worker, Farah Schüller, wrote up a good summary of things so far: https://dev.37signals.com/bringing-our-apps-back-home/
The third paragraph ends: "With MRSK, we can deploy a new version of HEY in as little as 20 seconds."
They didn't say that they're replacing their k8s setup for Hey explicitly, but they go on to say the reason they wrote MRSK is that they like the advantages of containers while getting lower complexity and being able to use their bare metal hardware. It seems like they want to go in that direction.
... and mrsk is imperative compared to the declarative approach of swarm and k8s.
Especially if you go all in on gcp and use gke + config-connector + fluxcd or argocd and all the other controller, it takes time to know and understand how successful your latest change was. In the end k8s + controller is a huge asynchronous reconciliation loop. It might succeed to apply your changes at some point in time, but you've no idea when it starts and when it ends. That often sucks and takes a lot of time. And even more time if you've to figure out which change failed and why and if it's the final state already. Some older dudes with grey hair might remember cfengine and its eventual consistency approach.
Deploys with k8s are faster than most of the competition. When your process is optimized you can expect to go from code change to updated UI in about 5 seconds.
Thaxll|2 years ago
We'll see how many years it will take them to come back to Kubernetes or equivalent.
And the argument k8s is too complicated so build our own looks really bad from an engineering perspective.
When you look at the issues: https://github.com/mrsked/mrsk/issues/44 you can some see trivial shortcoming that has been solved for years by other solutions.
FridgeSeal|2 years ago
Wow. That’s uh, that’s certainly a decision.
> They're the same service, because they're running the same image
If something purports to “run my containers” and “be an alternative to K8s”, I’d kind of expect it to run whatever it’s told. Whether running identical containers on the same host is a good thing or not really depends on your architectures choices and trade offs. Blindly being like “you can’t have this because reasons” makes this whole tool a giant non-starter IMO.
datadeft|2 years ago
davedx|2 years ago
firemelt|2 years ago
axelthegerman|2 years ago
On the other hand, React is too complicated if you just need a bit of JavaScript on your mostly HTML/CSS page... So now you can use Hotwire if you like.
I don't see what's so bad about that (same things as MRSK and k8s)
throwaway110535|2 years ago
maxmcd|2 years ago
mr_ndrsn|2 years ago
mdasen|2 years ago
They didn't say that they're replacing their k8s setup for Hey explicitly, but they go on to say the reason they wrote MRSK is that they like the advantages of containers while getting lower complexity and being able to use their bare metal hardware. It seems like they want to go in that direction.
gurrone|2 years ago
akvadrako|2 years ago
datadeft|2 years ago
¯\_(ツ)_/¯
pc86|2 years ago
lobstrosity420|2 years ago