bkazez a year ago

I recently migrated a small Rails project (16,000 monthly users) from Heroku to Helm/Kubernetes, after having tried Fly.io and everything else. It was easy, and I like the peace of mind of zero-downtime deploys and non-beta infrastructure. Cost is comparable to Heroku.

My writeup, in case it helps others: https://www.vmii.org/blog/2023/03/12/kubernetes/

  • selcuka a year ago

    I was going to ask "why", but you already explained it in your writeup:

    > The prevailing wisdom is that Kubernetes is overkill for a small Rails/Elasticsearch app, but overkill is my life philosophy.

    • loveparade a year ago

      I'll never understand these arguments against Kubernetes and its complexity that are so prevalent on HN. Yup, k8s has a learning curve, just like any new technology. You'll need to spend a couple days understanding it. But once you've grasped the abstractions it's actually quite easy to setup, operate, and manage, even for small side projects. I'd pick it any day over "third party magic" that is a black box and I have no control over.

      It feels like many developers these days are so spoiled by magic services that they are unwilling to even spend a few days going deep into something. Everything has to work in minutes. Next, what inevitably happens is that services shut down, pricing changes, or something stops working, and they have no way to debug it or move off it. And then we get customer support complaints and posts on HN about it. These developers look for the next shiny 3rd party service that solves the problem immediately and repeat the cycle, without ever learning anything that helps in the long term.

      • theonething a year ago

        > I'll never understand these arguments against Kubernetes and its complexity

        Because my project doesn't need the benefits that K8s offers. Why choose the more complex solution when I don't need it? And judging from experience and what others have shared, most projects will not need it.

        > no way to debug it or move off it

        If a managed service is down, the host company debugs it. That's the whole point of a managed service, so I don't have to do devops.

        Why would there be no way to move off of it? PaaS is so easy to onboard and deploy, you can move to other services easily.

        > It feels like many developers these days are so spoiled by magic services that they are unwilling to even spend a few days going deep into something

        Why don't you go all the way and build your own physical servers instead of using these magic cloud machines? That way you can go deep into it, and if they have problems, you can debug yourself.

        If you enjoy building and maintaining your own K8s clusters and you feel it benefits you, great for you. But don't be so condescending to people who don't feel the same and choose the simpler infra solution because they'd rather go deep into building their application rather than spending time with K8s. Calling them spoiled for that is just obnoxious.

        • YetAnotherNick a year ago

          > Because my project doesn't need the benefits that K8s offers.

          So what? It just takes a month long time investment to be used to kubernetes(many people already have some experience from working for employers), and after that it takes one or two days extra days to make some project as easy to deploy as heroku. So basically it is a fixed learning cost. Obviously if someone is looking to get something up as soon as possible and doesn't have kubernetes experience, it is better to not use it.

          But for me, the fixed learning cost clearly paid off. Kubernetes is lot better than alternatives if you want to assign fine grained securities, namespaces, complex scaling rules, using multiple clouds, multiple node types etc. Even if I don't need any of these now, I am not giving any extra time investment for new projects and it guarantees I don't need to do any migration to some other form of deployment if my project becomes big.

          • bryanrasmussen a year ago

            > It just takes a month long time investment to be used to kubernetes

            Ok so next time I'm laid off I will have some tech to choose learning. May I will spend that month.

            Even when I wasn't a parent I don't think my life was that open that I could say well it only takes a month, I guess I will learn that. Lots of things take a month to learn. people pick and choose.

            • rat9988 a year ago

              I'm pretty sure he meant a month of your job.

              • replygirl a year ago

                gp prolly has stuff to do at the job.

                • bryanrasmussen a year ago

                  exactly. but if it is a month of my job that means my employer needs to choose that I start learning it.

                • rat9988 a year ago

                  That's exactly what we all meant.

      • selcuka a year ago

        > Yup, k8s has a learning curve, just like any new technology.

        It's more than the learning curve, though. It also requires resources for itself (the control plane) so it's not really suitable for small projects unless you use a managed offering (which has the same downsides as you mentioned in your second paragraph).

        Also you make it sound like all Kubernetes alternatives are 3rd party, paid, hosted services, which is far from the truth.

        • speedgoose a year ago

          K3S is lightweight and a pleasure to work with. I had much better experience using it than managed Azure AKS that is hell.

        • 8n4vidtmkvmk a year ago

          Just go managed. Let someone maintain the control plane for you. The important bits are in the YAML, pretty sure I'm still portable.

          I can still run it locally for dev via Docker and I use Devspace to make it easy to bring up a dev env.

          • gurrone a year ago

            That is only partially true. So you spin up a GKE cluster, setup your deployment push it out via kubectl. OK your app is running but now you need access to it. The portable way is a Service Loadbalancer but it's just a TCP loadbalancer. So you go for the Ingress API. Then you want to do it a little bit more, you learn that the Ingress controller on GKE just configures you a L7LB at Google. Nice, that can do what I want. I want it to run dual-stack IPv4 and IPv6 (my prior example for those shortcomings in GKE was setting response-header but that was added lately after only 3yrs). Oh snap supported by the LB but not by the Ingress controller. Then you dig deeper and learn that development already shifted from the Ingress to the Gateway API. And now you're already knee deep into problems, because what you want to do is not really part of the Ingress or Gateway API and now you're at the mercy of the vendor you choose. Or you run a vendor neutral Ingress controller, like the classic nginx one. That later choice means you've to make yourself familiar with the oddities of that component as well. And then you also want something for DNS, Let's Encrypt and so on. Half a dozen controller installations later you finally have something. But now you've to maintain it because the managed service is only for k8s.

            But one should not forget that you also had to build up a lot of vendor specific know how in the past. Someone had to configure your F5 BigIP and your Juniper Router and the Cisco Switch and of course the Dell or HPe boxes you bought.

            I take more concerns with k8s immature ecosystem which is kind of reinventing classic unix stuff for distributed computing. And that just started and you've to lifecycle components with breaking changes every few weeks. And people took issues with updating Ubuntu LTS releases every two years. Now they have to update some component every week.

            • 3np a year ago

              This was refreshing. Now let's talk about logging and metrics!

            • 8n4vidtmkvmk a year ago

              I don't know about every week... I ignore my k8s setup for 6-12 months at a time. Once in DigitalOcean bugs me to upgrade k8s and that, I admit, has been a bit of a disaster in the past.

              I don't know. I had a pretty good thing going prior to k8s too, just some rsync and `ln -sfn` and it was easy, simple and very fast, but like you said, upgrading Ubuntu and PHP and other services becomes the problem there. Couldn't do that without downtime.

              Trade-offs.

            • arcbyte a year ago

              This has been my experience with kubernetes as well.

              Look I can and have done all these things, but it's just not worth my time to do them for my little apps. I'd rather be talking to customers and shipping features at this point in my career.

            • alyandon a year ago

              Currently dealing with almost exactly this using Citrix LBs and k8s. You can't even really tell what is happening with the Citrix ingress controller when things break. :-/

      • dig1 a year ago

        IMHO, this is a too simplistic view of things. Personally, I don't judge a tool by how easy to start with or how easy it is to understand but by how easy it is to fix something when things begin to fall apart. In this field, K8s is a magic box. You can understand Linux kernel in a couple of hours, yet you'll need years with it to start debugging nasty things.

      • rapind a year ago

        > It feels like many developers these days are so spoiled by magic services that they are unwilling to even spend a few days going deep into something.

        Quite the opposite. K8s are a big opaque ball of magical complexity to most of us devs for sure (as is heroku). However, for 100% of my use cases nothing should be more complex than the database.

        I’m not opposed to learning about it, but reducing complexity wherever reasonable has paid off for me.

      • debarshri a year ago

        I have a hypothesis around why people think it is complex. In my opinion it is not very complex, But the way of working, interfaces that developers deal with and formal process around k8s creates a perception that it is complex. It is also all the tools around k8s that makes it feel complex. You don't need istio, kyverno, OPA, all the other million tools from the cncf landscape to deploy your simple rails app. The industry had to paint that operating k8s hard so that they could sell tools around it. Currently version of k8s and all the stripped down versions are much easier to operate than before.

        It barely takes a weekend to learn and play around with managed k8s from cloud providers or with minified k8s tools like k3s, k0s etc.

        • nicoburns a year ago

          I think it's fair to say that it's considerably more complex than a single (or say 2-3) linux VMs. I can see that managed kubernetes would make things simpler. But managed kubernetes is also just as expensive as other managed solutions (more expensive for small projects).

      • turtlebits a year ago

        The problem is that the surface area for k8s is too large for one person to truly understand it. Sure, you can get up and running in a few days, but good luck when your cluster mysteriously stops working and ignores all kubectl commands.

        • dewey a year ago

          In the past 6 years of working with Kubernetes in production every day, I've never had that happen to me, so it doesn't sound like the error case I should optimize for.

      • musha68k a year ago

        I dig the independence sentiment and agree somewhat / in general on the "should know how it works underneath" part but Heroku is still the one platform I can recommend to most of my exclusively-dev friends.

        The systems evolution that led us to Kubernetes does have it merits of course: I just know I can trust the simple foundations of control loop meets immutability in order to maintain complex distributed systems, including expectations for self-healing and resilience. Though IMHO the "freedom" aspect you hinted on above is the more important one these days - yet usually cloud platform dependence unfortunately creeps in, in other ways still.

        Personally though I bet that for an easy 80% of "need to deploy software" cases, Kubernetes is indeed overkill - as long as it isn't "managed" / abstracted away at least to the level of a Heroku. And of course there are many other ways and platforms to benefit from "containers" and their promise (?) of independence these days.

        All power to anyone though if they have the money/time/energy to put work into that layer, in addition to whatever else they are trying to achieve. Disclaimer being that learning can definitely be its own merit (that's how I got started myself) but it's important to know when it's "just" that, when it's more and when it's simply overkill.

      • bshipp a year ago

        My issue is that I have 40 dockerized containers set up behind a reverse proxy and, although I want to play with k8s to learn, I've already dumped so much time and effort into docker-compose that I'm cautious about migrating to a new system. Is the architecture substantially different?

        • 8n4vidtmkvmk a year ago

          I went down that road a few years ago. Dockerized my app because I figured that was the first step. Then naturally docker-compose to bring the pieces together, right? No. Was upset that was not the next step to Kubernetifying an app. Use Kustomize instead. It's not that bad. Did take days or a few weekends but it requires very little maintenance now and its easy to spin up new apps.

        • margorczynski a year ago

          Well it's distributed. I would say single machine vs distributed system is a really big difference. A lot problems and complexity.

  • foldr a year ago

    >If you are still with me, this is about the point where things start to get incomprehensible. Just close your eyes and keep copying/pasting yaml.

    Excellent writeup. This line seems to track with what other people have told me about maintaining Kubernetes deployments. Almost no-one really understands the YAML (beyond the basics), so you end up with services defined via tens of thousands of lines of unmaintainable copy pasta YAML. This problem probably isn't going to surface so quickly (if ever) for a smaller project.

  • robertlagrant a year ago

    Thanks for this. Having tried similar with AWS, and having to specify security groups, static IPs, etc etc with many annotations in EKS, that Google Cloud version looks refreshingly simple.

  • alexellisuk a year ago

    The cost of Heroku was 50 USD / mo for 1GB of application RAM. I can't imagine that a GKE cluster, plus nodes, plus cloud SQL (and you refer to AWS S3 too?), plus bandwidth all adds up to less than 50 USD / mo.

    What's your cost breakdown like?

    And how are you finding it so far?

    • bkazez a year ago

      50 USD/mo was for 1 production Heroku app dyno (no db!), with no Redis or Sidekiq. On GKE we added Redis and Sidekiq, all duplicated for staging (on Spot VMs), for 58 USD/mo. (One single-zone cluster is free on GCP.)

    • vasco a year ago

      Around 8 years ago I migrated a full company from heroku to AWS and cut costs by 3/4. At that time I remember all the startups around us doing the same, with similar results.

  • number6 a year ago

    Thanks for your writeup I am thinking of moving our Django Apps to kubernetes

dzonga a year ago

something to note DHH is a beast. MSRK seems most of MSRK was written by him alone - https://github.com/mrsked/mrsk/commits/main?after=83dc82661b...

his output is crazy. that's why he gets the big bucks

  • rsanheim a year ago

    This is a great point, and something that I think of often as someone who has been building rails apps for almost 20 years.

    Once MSRK has gotten "good enough" for whatever Basecamp needs and DHH has moved on, how many other folks with the dedication and skills will help take over when maintenance and weird edge cases surface?

    So far the rails community has been strong enough where this _usually_ isn't an issue, but it definitely is a real concern. You can see the impact of this in some of the recent asset bundling solutions DHH spiked out and then mostly left to the community, where things like js-bundling and css-bundling are close but not completely solid for a bunch of use cases.

    • hokumguru a year ago

      I mean isn’t that most open source software? Company releases a tool but only maintains it for themselves, sometimes working with the community to update it.

  • matt_s a year ago

    Sticking with a technology for a long period of time pays the dividend of being able to crank out stuff like its a reflex. I get that DHH created Rails framework so he is intimately knowledgeable but this concept of sticking with and going deep on a tech stack will be much better for someone's career than hopping to whatever fad is trending.

  • TheFragenTaken a year ago

    I've always been fascinated with DHH. On top of his programming skills, and CTO of Basecamp, he drives the prototype class in the World Endurance Championship. Absolute beast.

  • tiffanyh a year ago

    I think what’s more shocking is they were still using Capistrano for the past ~17 years.

    https://world.hey.com/dhh/introducing-mrsk-9330a267

    • atonse a year ago

      I sorely missed Capistrano all these years I moved off rails. The closest the elixir ecosystem had to it (that I found) was edeliver.

      So why fix something that ain’t broken?

    • faizshah a year ago

      Interestingly there has been a resurgence of the Capistrano approach in the PHP community with ansistrano: https://github.com/ansistrano/deploy

      That’s Capistrano v2 implemented in Ansible. Honestly been tempted just to try it on a side project for fun.

      • malinens a year ago

        At my work we use Capistrano for PHP projects. It does not matter in which language project is written. You can still use ruby Capistrano and it works good enough

  • donio a year ago

    It's 2K lines of code and another 2K tests.

    • Alifatisk a year ago

      What does the loc tell you?

      • donio a year ago

        That you can go and read through the code in about 5 minutes and see that the only thing special about it is the name of the author.

        I don't get why HN is going crazy about this. Please tell me if I am missing something obvious.

        • lloydatkinson a year ago

          Because it flies directly in the face of the "cloud everything" or "kubernetes cultism" that seem prevalent. It's a change, basically.

          • ignoramous a year ago

            > "cloud everything" or "kubernetes cultism" that seem prevalent.

            Not here? To me, general sentiment on news.yc has been anti cloud / k8s for at least 5 years, if not more.

        • chillfox a year ago

          I am guessing that a lot of people who entered the industry since big cloud was a thing never learnt the basics of how to deploy on servers, so these 2000 lines of code are absolutely magic to them.

          Personally I use a ~200 line shell script + docker to deploy self hosted apps on a cheap office computer that lives under my desk.

chrisweekly a year ago

"vs." (versus) is misleading; TLDR Fly.io likes and claims alignment with MRSK, which is 37signals/DHH's new mechanism for managing dockerized apps with a strong "get off the cloud, run it locally" story.

  • stingraycharles a year ago

    Yeah they’re completely and totally different things. Fly.io is actually hosting servers / services, while MRSK is basically a bunch of scripts to deploy things using Docker containers.

    It’s like comparing AWS with Chef. Maybe there’s some overlap in philosophy, but that’s about it. Maybe fly.io is just using it as a way to do a bit of marketing.

    • paxys a year ago

      A head to head comparison makes some amount of sense. Fly.io is a platform-as-a-service provider, and natively handles stuff like like building/storing images and orchestrating your services across their DC.

      MRSK is a direct competitor to Fly's own orchestrator, and is meant for use when hosting on your own hardware or on a VM rented from an infrastructure provider. So it's still a "use either A or B" situation.

      I guess a better title would be – Hosting on the Fly.io platform vs. on your own servers/VMs with MRSK.

  • sergiotapia a year ago

    Seems like Fly is trying to borrow some thunder here haha

  • PKop a year ago

    That's them being respectful, but make no mistake the point of the blog post is "vs"

    • d4rti a year ago

      This is a competitive post par excellence, for politeness, accuracy and still doing a great job of demonstrating fly.io's key competitive points vs MRSK.

      I'd love it if all 'vs' and competitive marketing was this good.

  • dcre a year ago

    Second half is a comparison!

kungfufrog a year ago

Couldn't something like this be a few hundred lines of Ansible? Not trying to be intentionally negative but I don't really get the use case as I feel this is a pretty well established process by existing tools for server automation and provisioning.

  • nickjj a year ago

    Pretty much.

    I've been using Ansible with Docker Compose since 2015. I can set up a full server with all of the bells and whistles in about 20 lines of inventory configuration. Behind the scenes there's a bunch of portable and generic roles that work for baseline "server level" components. I've done this now for dozens of companies, it's a tried and true model with an easy way to customize things if needed.

    Ansible sets up the server, Docker Compose runs the apps (stand alone `docker compose` commands, not the Ansible module) and git is used to deploy everything.

    • jillesvangurp a year ago

      It's my go to solution as well. If I can't get a reasonable docker capable host out of the box (which you'd get in AWS and gcloud), use ansible to create one. I had to do this in Telekom cloud last year and dusted off some ansible stuff I had from previous projects and got it done. I sometimes combine it with using packer for building vm images. That avoids repeated overhead of having to run ansible, which can be a bit slow.

      For application deployment, I use simple scripts that restart docker compose via shh that we can run from Github actions. Ansible is overkill for that.

    • pxtail a year ago

      Can you elaborate a bit more on why are you preferring standalone commands instead of going all-ansible? I was considering switch to ansible module for myself but I'm hesitating, I feel like this could produce quite complex, intricate setup since docker compose itself has many specific stuff like .env files, .env.local files, docker-compose.yml environment specific override files, environment variables and many more so I have mixed feelings when thoughts about intertwining it with ansible arrives.

      • nickjj a year ago

        > Can you elaborate a bit more on why are you preferring standalone commands instead of going all-ansible?

        I very strongly believe:

        - Ansible is a great tool for setting up a server to get it to the point where you can run / deploy applications

        - Docker Compose is a great tool for running your app

        - Git is a pretty good tool for initiating deployments

        In my opinion these are 3 distinct things. Trying to make Ansible do everything gets messy, you also lose feedback. For example if you git push, a post receive hook will stream the response back to your terminal but Ansible will only show output when a task is complete.

        Using the raw Docker Compose commands also keeps things more consistent between dev, CI and prod. You run basically the same thing in all environments.

    • asar a year ago

      Is there a repo you could share for such a setup? Currently looking at similar options for self hosting web apps on cloud providers.

      • nickjj a year ago

        Not for all of the Ansible bits but for the Docker Compose apps I do have up to date repos for Flask, Rails, Django, Node and Phoenix[0].

        All of those example apps are deployable to production (and can be used in development) once your server has Docker installed.

        [0]: https://github.com/nickjj?tab=repositories&q=docker-*-exampl...

        • cheshire_cat a year ago

          Do your examples support zero downtime deployment and zero downtime rollback? If so, could you please point to the relevant sections? I couldn't figure it out from the READMEs.

          • nickjj a year ago

            > Do your examples support zero downtime deployment and zero downtime rollback?

            Those examples are for running your app, not deploying it.

            Zero downtime is also a loaded term.

            MRSK isn't zero downtime in a way that's commonly described as zero downtime. MRSK uses Traefik's built in functionality to queue requests so if your back-end is down it won't respond with a 502. Instead the user will see a busy mouse cursor until your back-end is up.

            A user will be able to automatically "resume" their request after your app reloaded which is nice, it saves them from having to see a 502 and manually reload the browser but if you have a Rails app that takes 27 seconds to boot up then the user will be waiting for 27 seconds with no feedback. You could make a case the UX there is worse than a user explicitly seeing a custom 502 page that mentions to reload in a bit.

            That's much different than a true zero downtime rolling update that something like Kubernetes will give you, or if you rolled your own solution to do it without Kubernetes. I don't know if MRSK will handle that, given the direction it's going it's quite possible DHH will implement that behavior in which case that would be very useful.

            Rollback is also tricky once you start introducing database migrations. I personally always roll forward.

    • htamas a year ago

      How do you use Git to deploy things? Sorry if it's a dumb question, I'm unfamiliar with Ansible.

      • nickjj a year ago

        A git post receive hook. You can set up a bare git repo which lets you push code to it. Then when you push to it, the post receive hook runs which can be any script you want. In this case you can run the commands to restart your containers or whatever else you need to do.

    • CoolCold a year ago

      side question - do you plan to revive podcasting, Running In Production in particular or is it RIP? It has some eye-opening episodes for me

  • nine_k a year ago

    Ansible is Python, and MRSK is Ruby. Each appeals to their own ecosystem; switching between the two is a noticeable cognitive load.

    Also, it could be implemented using Ansible, but it has been implemented in MRSK. A serious difference if you plan to count on someone to keep it updated and supported.

    • gtirloni a year ago

      Switching between Python and Ruby is a noticeable cognitive load. However, you barely touch Python while using Ansible.

      • jillesvangurp a year ago

        It's all yaml files. The amount of python you touch is basically zero indeed. Same with msrk as far as I can see.

  • e12e a year ago

    Probably. But not the interesting bit (the tenth of Docker swarm they've layered on top of plain Docker - for better or worse).

    I actually had a quick look at the code - and at this point it doesn't strike me as a tempting building block.

    There's no developer overview i could find (birds eye guide to the MRSK code structure and concepts). There doesn't appear to be much in the way of tests?

    Specially - i was wondering how hard it would be to replace traefic with caddy or haproxy, do letsencrypt via MRSK-managed parts of the deployment or drop in varnish.

    As best I can tell - there's no clean or sensible way to do any of those things.

    Despite that, as a simple Docker glue stick it seems quite useful.

    I must say i was disappointed with one thing in the demo - hosting the app on the internet in plaintext covering it with a TLS figleaf via cloudflare. That's terrible guidance in a demo/tutorial.

  • datadeft a year ago

    NIH.

    I have mixed feelings towards NIH people. One bunch is the RIIR crew (ripgrep, ruff, etc.) that produces high quality re-writes with amazing performance and safety, the other bunch is who re-writing tools without any added value.

    I am not sure which category MRSK fall into, there has not been enough details from them to justify this particular re-write.

    • burntsushi a year ago

      Author of ripgrep here. I never saw it as a "rewrite": https://old.reddit.com/r/rust/comments/11updi0/introducing_r...

      You might think of it as NIH, but I didn't at the time that I wrote it. Because I saw a gap in the ecosystem that wasn't being filled. grep didn't offer the UX of a tool like ag, and ag didn't degrade gracefully to behave like a grep. (And also wasn't as fast on single file search.) That gap is what motivated me to turn ripgrep from what it was (a test bed for Rust's regex crate) into what it is now.

      There's a reason why you basically never see me criticizing people about "NIH." Because it's actually quite difficult to accurately cast that criticism. Saying things are NIH is like saying things are broken. It's terribly overused.

      • datadeft a year ago

        I agree with you. I am not sure what classifies as re-write. For my grep use cases rg is a prefect replacement only it is faster. From this point of view some might say it is a re-write.

  • KingOfCoders a year ago

    Can I build this shelf software by myself? As always the answer is yes.

  • altairprime a year ago

    If you’ve got a tool that will apply a Dockerfile using ansible, I’d love to know more. It’s a good idea and it deserves to exist!

  • intelVISA a year ago

    Yeah not sure I see the value prop here it's just run of the mill Docker glue?

ofrzeta a year ago

Wow, the MRSK homepage is truly Web 1.0: https://mrsk.dev/

  • paxys a year ago

    I don't care about the lack of design frills on a webpage (in most cases it is preferable), but having to make sense of a wall of text stretching from edge to edge of a 4K screen is where I draw the line. Adding one line of CSS to set more readable column widths should be the bare minimum.

    • jrockway a year ago

      Why should the designer pick how wide you want the text? You are the one who knows what you like, and you can resize the browser window.

      • handsclean a year ago

        This is actually why I serve soup on a plate. Only my guests know what bowls they like, and they can pour the soup into a bowl of their choice.

      • quest88 a year ago

        Why should the designer design. Brilliant.

      • Lio a year ago

        > Why should the designer pick how wide you want the text? You are the one who knows what you like, and you can resize the browser window.

        Along with all the other answers here, given that this is a Rails adjacent I would say Convention Over Configuration.

        I like a basic text oriented page myself but sensible defaults would be useful. If the user wants to override the CSS in their browser they can do.

      • tasuki a year ago

        Do you resize the browser window differently for each website you visit?

        I want my text no wider than 80 characters, but I like the images to be potentially much wider than that. What is your solution?

        • foldr a year ago

          For all websites to be designed with your preferences in mind?

      • e12e a year ago

        Because the designer of today needs to wear the hat of yesteryear's typesetter (among many other hats)?

  • steve1977 a year ago

    I haven’t seen a website load so fast in a while.

rozenmd a year ago

I wish there was something like MRSK for deploying generic Dockerfiles onto VMs from scratch, without the mess of Kubernetes or needing to use Rails.

Like, provision Hetzner -> pass the IP address to the tool + a Dockerfile -> your image Just Works on the server and restarts if it crashes.

  • jahsome a year ago

    I may be ignorant but doesn't that scenario you described encapsulate how MRSK functions?

    From the MRSK readme[1]:

        Connect to the servers over SSH (using root by default, authenticated by your ssh key)
        Install Docker on any server that might be missing it (using apt-get)
        Log into the registry both locally and remotely
        Build the image using the standard Dockerfile in the root of the application.
        Push the image to the registry.
        Pull the image from the registry onto the servers.
        Ensure Traefik is running and accepting traffic on port 80.
        Ensure your app responds with 200 OK to GET /up.
        Start a new container with the version of the app that matches the current git version hash.
        Stop the old container running the previous version of the app.
        Prune unused images and stopped containers to ensure servers don't fill up.
    
    ---

    1. https://github.com/mrsked/mrsk#readme

  • fbdab103 a year ago

    Dokku[0] does exactly that. Feels a very similar space to mrsk, but has been around for several years now.

    [0] https://dokku.com/

  • mr_ndrsn a year ago

    mrsk doesn't require rails. It makes no assumptions about what you're running, we deploy a golang service with it.

    mrsk does require a ruby install on your machine, tho.

    • KingOfCoders a year ago

      I would be very interested in that, do you have a writeup?

      • mr_ndrsn a year ago

        I don't think there's a writeup out there, but mrsk just uses docker under the hood. So, if you have a CMD in your Dockerfile, it will use that.

        If you have an image that can run multiple things, like a rails app that can run the app process for web traffic by default, but it can also run job workers with the right command, you can provide the cmd in the mrsk config. You can see this in the jobs role in the example: https://github.com/mrsked/mrsk#using-different-roles-for-ser....

  • nwienert a year ago

    Docker Swarm is very underrated, more for multiple apps but you can of course just have one.

  • stavros a year ago

    I wrote something to do just that:

    https://gitlab.com/stavros/harbormaster

    SSH into the server, run the Docker container, give it a config file with the images you want to run, and it handles everything else automatically.

  • e12e a year ago

    > Like, provision Hetzner -> pass the IP address to the tool + a Dockerfile -> your image Just Works on the server and restarts if it crashes.

    This is MRSK. It's just that rails now comes with a dockerfile. And your service need a health check.

  • jordemort a year ago

    I think this is what MRSK is? There's no Kubernetes. It even installs Docker for you.

  • andrewmutz a year ago

    I don't think you need to use rails to use MRSK

emmelaich a year ago

I'm curious about the name. Is it from Maersk the Danish shipping company?

  • mr_ndrsn a year ago

    Well, he is Danish, and this does help you ship software...

    • tgv a year ago

      Shipping containers, to be precise.

  • vitro a year ago

    In Czech there is a verb "mrskat" - to flog - and one flog/flap can be said as one "mrsk". Made me giggle.

  • stavros a year ago

    Looks like it, from the image.

1ba9115454 a year ago

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.

  • Thaxll a year 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 you can some see trivial shortcoming that has been solved for years by other solutions.

    • FridgeSeal a year ago

      > When you look at the issues: https://github.com/mrsked/mrsk/issues/44

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

      • mr_ndrsn a year ago

        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.

        • datadeft a year ago

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

          • mr_ndrsn a year ago

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

          • the-lazy-guy a year ago

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

            • datadeft a year ago

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

              Disclaimer I love Ruby and Rails to death.

    • davedx a year ago

      Kubernetes is terrible, I hate it with a passion, and welcome any alternatives that reduce the complexity (as it the stated vision of MRSK)

      • growse a year ago

        Which bit, the APIs or the implementation?

    • firemelt a year ago

      As an engineer reading this makes me feel ashamed

    • axelthegerman a year ago

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

    • throwaway110535 a year ago

      Same could’ve been said for Rails…

      • mbreese a year 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.

  • maxmcd a year 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)

    • mr_ndrsn a year 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/

      • ctvo a year ago

        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.

        • mr_ndrsn a year ago

          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.

          • ctvo a year ago

            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.

    • mdasen a year 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 a year 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?

      • davedx a year ago

        He said it in the YouTube video he made. They explicitly estimate they're going to save 7M/year moving Hey to MRSK

  • gurrone a year 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.

  • akvadrako a year 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.

  • datadeft a year ago

    After they argued that k8s is better than AWS.

    ¯\_(ツ)_/¯

    • pc86 a year ago

      Just because something is hard to use and slow doesn't mean it's worse than AWS.

    • lobstrosity420 a year ago

      How would you say that both statements can’t be true at the same time?

      • datadeft a year 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 a year 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 a year ago

            Yeah this is exactly how I see it. Thinking in terms of VMs is not going make you understand serverless.

        • krab a year 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.

pictur a year ago

Marketing is truly an art. Although there are thousands of projects on this subject, the man can share wonderfully as if he has discovered something new. I appreciate.

  • chuankl a year ago

    I am new to these kinds of lightweight low-complexity deployment systems. Can you point me to a few other good projects? Thanks!

subarctic a year ago

Interesting to see fly comparing themselves to an open source project. I guess they legitimately think it's cool and want to see mrsk catch on? I'm not sure what the marketing angle is here (and "competitor vs us" is such a common thing that it's hard not to think of the marketing angles here)

nathants a year ago

(movie trailer voice)

in a world where backend is a single binary and frontend is a single html file…

who needs containers or complicated devops?

  • intelVISA a year ago

    Imagine how many jobs that'd obsolete... you'd probably automate more devs than ML ever could!

ofrzeta a year ago

I'd really like something like platform.sh as open source. I'd be willing to contribute as well :)

  • hankmh a year ago

    Have you checked out Dokku [0] or others like it?

    If so, what do you perceive as the gaps between Dokku and Platform.sh? I ask as an employee of a PaaS (not Platform.sh). So I'm curious for discovery and learning.

    [0] https://dokku.com/

    • ofrzeta a year ago

      I tried it once and concluded it wasn't good enough but I don't remember the specific gaps. Now that I browse the docs it actually looks quite powerful, so I guess I will have to take another look.

      Other contenders are CapRover and Coolify that I just recently got to know here.

      I guess it would make more sense to contribute to one of these projects than start a new project.

      What PaaS are you working at?

      • hankmh a year ago

        I work at Aptible. We've been around for about 10 years, have about 300 customers, all companies that prioritize reliability, scalability, and security. Many are late stage startups/recently minted unicorns....but nobody has really heard of us.

        If you want I can hook you up with an extended trial, beyond what's offered on the website. I'd love your feedback. We aren't open source, though we have considered it. Maybe your feedback can help push us over the edge. My email is henry AT aptible.com.

        Same offer goes to anyone here. Feedback would be really valuable to me personally.

    • mgz a year ago

      Dokku is great, I switched to it from Capistrano and never looked back.

riffic a year ago

fly.io's been a little under my radar but are they the new DigitalOcean or something?

  • WaxProlix a year ago

    Depends on what you use DigitalOcean for. Fly historically provided a network of edge serving and some compute, and has recently taken in a monster pile of Heroku free tier (and partial free tier) refugees, whose needs don't really align with their original core business. I've not been following much, but it seems like they're in a transitory period.

    For what it's worth, "lots of new interested customers" is nowhere near the top of the list of Bad Problems To Have In Business, I think, so they're probably fine medium term. Just the growing pains and possibly unwanted pivoting -- and monetizing the freebies -- might be an issue for a bit.

  • the_gastropod a year ago

    I’d categorize fly as more akin to Heroku or Render than DigitalOcean.