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...
IP addresses are easy to use in the configurations that inspired mrsk. Small apps that are fairly static. There are two main problems that mrsk is trying to solve.
1. Moving our stuff out of the cloud without going back to static hosts.
2. Giving new rails devs a tool where they can deploy their application easily, in a modern fashion.
Both of these are not so large or complex that you must use hostnames in configs instead of IP addresses. I will note, that most of our internal configs, do in fact, use hostnames rather than IP's. But judging a tool because an example used an IP address seems shortsighted.
There are plenty of things in mrsk to discuss without fixating on that.
>> 1. Moving our stuff out of the cloud without going back to static hosts.
I move companies between clouds and on-prem to cloud, cloud to on-prem (even though a bit bigger one than 37singnals) and I could use tools like Ansible and Terraform. In my experience when a smaller company starts to writes tools that solve the imaginary problems of the CTO they are not focusing on solving customer problems and this usually ends badly.
>> 2. Giving new rails devs a tool where they can deploy their application easily, in a modern fashion
Could you share the comparison chart of tools that you considered? What thought process led you to believe that this is an unsolved problem and requires a new tool? Genuinely interested.
>> But judging a tool because an example used an IP address seems shortsighted.
How should I judge it by than? Reading the code? Figuring out how to hold it right myself?
> I move companies between clouds and on-prem to cloud, cloud to on-prem (even though a bit bigger one than 37singnals) and I could use tools like Ansible and Terraform.
Where did anyone say we don't use other tools? Chef + Terraform are wonderful and still in use for us.
> Could you share the comparison chart of tools that you considered? What thought process led you to believe that this is an unsolved problem and requires a new tool? Genuinely interested.
Your phrasing here and in your previous quoted reply leads me to believe you're not genuinely interested. Our environment is not your environment, our experiences are not your experiences. No, I can't share a chart of other tools that were considered, but off the top of my head, Capistrano, various CI integrations, Github Actions, etc.
We're a rails shop. We're going to look at tools in that area. We're not going to go dig into dagger or garden.io or something that causes us to have to conform our dev/deploy environment to a mental model that adds more friction for our developers.
> How should I judge it by than? Reading the code? Figuring out how to hold it right myself?
It's not that complicated of code, only about 2k, total, IIRC? I mean, you could read it. I'm baffled that you're choosing to compare a structural design flaw like the iPhone antennae issue to the fact that a configuration example in a new tool used an IP address. Go off, king.
> In my experience when a smaller company starts to writes tools that solve the imaginary problems of the CTO they are not focusing on solving customer problems and this usually ends badly.
Like writing their own web framework in obscure programming language?
> Like writing their own web framework in obscure programming language?
Which caused the biggest spike in CO2 production for recorded human history while making operation teams rage-quit their job over undefined method [] for nil messages?
> 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/
Can you expand on the limitations of AWS ECS? It seems like... you built a worse version of it.
Toss https://aws.amazon.com/ecs/anywhere on your own hardware and let someone else wake up at odd hours to worry about the container images making it on to the host.
I mean, mrsk has a different feature set than ECS, sure. But we don't want to pay AWS for ECS anywhere. We're trying to get off big tech where we can. I'm sure you've heard David talk about that.
This tool covers our use cases so far, and is easy to reason about. Ergonomically, it's very similar to Capistrano, which we're all familiar with.
Makes sense if you're dropping all AWS dependencies. For us, ECS Anywhere with its logging to CloudWatch and automatic IAM credentials management allowed us to still use the rest of the AWS ecosystem on cheaper and more specialized hardware.
It wasn't too bad to setup GitHub actions -> AWS ECR -> AWS CodeDeploy -> AWS ECS -> On-prem hosts via ECS Anywhere and that's worked well.
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.
I was just watching the video DHH put online about this new project and it was quite good seeing copy pasting IP addresses to YAML files still excites some people or think that this is somehow on par with a serverless offering to any cloud company.
It feels like so many people who complain about the cloud expense and complexity are only ever using VM based solutions and ignore all of the capabilities you get out of the box using managed or "serverless" services. When you treat the cloud like just another data center but someone else manages it for you you're likely not going to have an optimal cloud based solution and of course it's going to be more expensive.
If you're building a simple app, using Functions as a Service along with serverless document based storage solutions will enable you to have a very cost effective cloud deployment which includes so many things out of the box like the ability to scale globally without having to change your application architecture. For my small hobby projects, this amounts to a few dollars a month per application as the only cost which isn't purely consumption based is disk space for the database. I built an application for a small company (around 10k MAU) which costs them around $40 / month using these tools. Yeah, they could be on a small VPS somewhere with the same performance characteristics for the current user load. But then I would have had to build in all of the things I get from managed solutions myself. I haven't had to think about patching my server OS in years.
They stated 2 reasons.
Deployments to K8s are slow.
K8s is hard to setup on bare metal.