5 ms·

I'm surprised 37signals built MSRK as an alternative to Kubernetes. They stated 2 reasons. Deployments to K8s are slow. K8s is hard to setup on bare metal.

datadeft 4y ago
After they argued that k8s is better than AWS. ¯\_(ツ)_/¯
- pc86 4y ago
  Just because something is hard to use and slow doesn't mean it's worse than AWS.
- lobstrosity420 4y ago
  How would you say that both statements can’t be true at the same time?
  - datadeft 4y ago
    Sure they can. 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.
    - tstrimple 4y ago
      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.
      - datadeft 4y ago
        Yeah this is exactly how I see it. Thinking in terms of VMs is not going make you understand serverless.
    - krab 4y ago
      Well, if you do it once every two months and you save two engineers' salaries, I'll be the first one to do it. And I hate YAML and repetitive work.
maxmcd 4y ago
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 https://world.hey.com/dhh/introducing-mrsk-9330a267)
- mdasen 4y ago
  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.
  - FridgeSeal 4y ago
    Azure, AWS (and I therefore assume GCP) now have K8s products where can BYO own compute, and they’ll manage everything else. Best of both worlds, no?
    - ofchnofc 4y ago
      [dead]
  - davedx 4y ago
    He said it in the YouTube video he made. They explicitly estimate they're going to save 7M/year moving Hey to MRSK
    - ofchnofc 4y ago
      [dead]
- mr_ndrsn 4y ago
  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/ https://dev.37signals.com/bringing-our-apps-back-home/
Thaxll 4y ago
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. When you look at the issues: https://github.com/mrsked/mrsk/issues/44 https://github.com/mrsked/mrsk/issues/44 you can some see trivial shortcoming that has been solved for years by other solutions.
- throwaway110535 4y ago
  Same could’ve been said for Rails…
  - mbreese 4y ago
    Honestly, the same could have been said about K8s when it was started too. There’s nothing wrong with multiple projects in a space. It’s a big market with different niches.
- firemelt 4y ago
  As an engineer reading this makes me feel ashamed
- datadeft 4y ago
  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...
  - nine_k 4y ago
    Dhall lacks a killer app that would use it. (Write one!)
    - datadeft 4y ago
      k8s is a pretty good one. I would not touch k8s without Dhall: https://github.com/dhall-lang/dhall-kubernetes https://github.com/dhall-lang/dhall-kubernetes
akvadrako 4y ago
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.
gurrone 4y ago
... 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.

datadeft 4y ago

After they argued that k8s is better than AWS. ¯\_(ツ)_/¯

pc86 4y ago
Just because something is hard to use and slow doesn't mean it's worse than AWS.
lobstrosity420 4y ago
How would you say that both statements can’t be true at the same time?
- datadeft 4y ago
  Sure they can. 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.
  - tstrimple 4y ago
    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.
    - datadeft 4y ago
      Yeah this is exactly how I see it. Thinking in terms of VMs is not going make you understand serverless.
  - krab 4y ago
    Well, if you do it once every two months and you save two engineers' salaries, I'll be the first one to do it. And I hate YAML and repetitive work.

maxmcd 4y ago

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 https://world.hey.com/dhh/introducing-mrsk-9330a267)

mdasen 4y ago
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.
- FridgeSeal 4y ago
  Azure, AWS (and I therefore assume GCP) now have K8s products where can BYO own compute, and they’ll manage everything else. Best of both worlds, no?
  - ofchnofc 4y ago
    [dead]
- davedx 4y ago
  He said it in the YouTube video he made. They explicitly estimate they're going to save 7M/year moving Hey to MRSK
  - ofchnofc 4y ago
    [dead]
mr_ndrsn 4y ago
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/ https://dev.37signals.com/bringing-our-apps-back-home/

Thaxll 4y ago

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. When you look at the issues: https://github.com/mrsked/mrsk/issues/44 https://github.com/mrsked/mrsk/issues/44 you can some see trivial shortcoming that has been solved for years by other solutions.

throwaway110535 4y ago
Same could’ve been said for Rails…
- mbreese 4y ago
  Honestly, the same could have been said about K8s when it was started too. There’s nothing wrong with multiple projects in a space. It’s a big market with different niches.
firemelt 4y ago
As an engineer reading this makes me feel ashamed
datadeft 4y ago
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...
- nine_k 4y ago
  Dhall lacks a killer app that would use it. (Write one!)
  - datadeft 4y ago
    k8s is a pretty good one. I would not touch k8s without Dhall: https://github.com/dhall-lang/dhall-kubernetes https://github.com/dhall-lang/dhall-kubernetes

akvadrako 4y ago

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.

gurrone 4y ago

... 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.