MRSK: Deploy web apps anywhere(mrsk.dev)
mrsk.dev
MRSK: Deploy web apps anywhere
https://mrsk.dev/
122 comments
> especially early on when my focus should be testing my product, not optimizing my cloud infrastructure for scale that might never be needed
Not to mention vendor lock in, something that really needs to be talked about more with this new wave of function this and edge that.
Not to mention vendor lock in, something that really needs to be talked about more with this new wave of function this and edge that.
Avoiding vendor lock-in always sounds nice in theoretical discussions, but in practice it needs to be weighed against the cost of additional development time.
In the past decade I’ve been on several teams that went out of their way to avoid vendor lock-in by refusing to use platform service offerings.
Every single time it was a complete waste of time. We could have saved a lot of time by embracing platform offerings and then trying to port to a different vendor only if necessary.
In the past decade I’ve been on several teams that went out of their way to avoid vendor lock-in by refusing to use platform service offerings.
Every single time it was a complete waste of time. We could have saved a lot of time by embracing platform offerings and then trying to port to a different vendor only if necessary.
Really depends on the use case. When you don't need the extra features of the AWS load balancer+API gateway over, say, a relatively straight forward nginx/caddy installation. The time to learn the AWS equivalents over off the shelf OSS is pretty similar. Why not just use the OSS all things considered?
There are significant downsides to a lot of the vendor offerings, they seem like a simpler solution but they are plenty complicated in their own right. Particularly since they are probably built to accommodate varied and complex cases that you don't really need. And rarely is this paired away under some special dialog for power users, often you are expected to just know everything up front.
There are significant downsides to a lot of the vendor offerings, they seem like a simpler solution but they are plenty complicated in their own right. Particularly since they are probably built to accommodate varied and complex cases that you don't really need. And rarely is this paired away under some special dialog for power users, often you are expected to just know everything up front.
You are absolutely correct here for most businesses.
Howvever, there are many companies working within heavily regulated sectors that unfortunately need to be able to evidence a rapid ability to switch platforms AND exactly where data is stored and processed.
As such using very specific offerings in cloud providers is unfortunately not always an option. Something that is portable, even at expense of complexity or available dev time, becomes a non negotiable.
Howvever, there are many companies working within heavily regulated sectors that unfortunately need to be able to evidence a rapid ability to switch platforms AND exactly where data is stored and processed.
As such using very specific offerings in cloud providers is unfortunately not always an option. Something that is portable, even at expense of complexity or available dev time, becomes a non negotiable.
Vendor lock in? Next can be self hosted, deployed on AWS/Amplify/Lambda, your own hardware, etc. I wouldn't say it's as locked in as some other solutions out there.
it is. Some features only work on their edge runtime !
> especially early on when my focus should be testing my product, not optimizing my could infrastructure for scale that might never be needed.
In that case, go with managed services like render, Heroku, or fly. MRSK, or any DIY deployment, is not going to save you the hours of tinkering you will inevitably do to get the non-server stuff up for even a low-usage production app: 1. One-click Deploys, basic CI/CD 2. Redis/memcache 3. Database / migrations / rollback / backup 4. Logging / metrics / down detection & basic high availability 5. Keeping up with basic upgrades
In that case, go with managed services like render, Heroku, or fly. MRSK, or any DIY deployment, is not going to save you the hours of tinkering you will inevitably do to get the non-server stuff up for even a low-usage production app: 1. One-click Deploys, basic CI/CD 2. Redis/memcache 3. Database / migrations / rollback / backup 4. Logging / metrics / down detection & basic high availability 5. Keeping up with basic upgrades
He's "dinosaur" probably meaning he knows how to work with linux - it'd likely take more time to learn clicking in some proprietary page than just doing it so that it works locally and remotely.
Honestly, I can appreciate MRSK a little more because I’m anticipating running some small stuff out of my house (behind Cloudflare) once I finally have fiber next month.
Soon as I have a couple of little home servers in place I think this will be a solid model for me.
Soon as I have a couple of little home servers in place I think this will be a solid model for me.
> and a load balancer
> not optimizing my cloud infrastructure for scale that might never be needed
I don't understand why you would want a load balancer with that mentality. Feels like most companies will never reach a scale where load balancing is necessary.
> not optimizing my cloud infrastructure for scale that might never be needed
I don't understand why you would want a load balancer with that mentality. Feels like most companies will never reach a scale where load balancing is necessary.
besides scalability there's also fault tolerance.
sure the DB might still be a single point of failure as is the load balancer, but some rogue web processes hogging your single server or a disk failure bringing it down
sure the DB might still be a single point of failure as is the load balancer, but some rogue web processes hogging your single server or a disk failure bringing it down
Also, never underestimate the utility of being able to perform upgrades (either the app or the underlying infrastructure) with little to no downtime.
Load balancers don't just do scale. They provide a separation of concerns, and for a "simple app" (i.e. the kind were talking about here), a vendor provided one (AWS elb for example) is very easy to set up.
Our LB does a bunch of heavy lifting for us. It handles SSL termination, static routing (we serve a bunch of content from S3), handles Auth for our internal "management" endpoints, and because we use containers it gives us health checks, auto restarts, and rolling deploys. I'm pretty sure we have about 30lines of terraform to support all of that.
Our LB does a bunch of heavy lifting for us. It handles SSL termination, static routing (we serve a bunch of content from S3), handles Auth for our internal "management" endpoints, and because we use containers it gives us health checks, auto restarts, and rolling deploys. I'm pretty sure we have about 30lines of terraform to support all of that.
Right... there are a lot of contradictions in their comment. You want to focus on your product, by managing your own server(s)? You don't want to over engineer early on but you're running a load balancer and n-servers? Why not a single server? Or, offload the management entirely to someone else and focus on your product.
It’s not contradictory if read with an understanding that one can be experienced and comfortable with the amount of server management required for a product at its current and likely future states. This makes the management piece less demanding than evaluating then learning an unfamiliar paradigm and the question marks that go along with that.
Maybe they mean reverse proxy? Often these come in the same product (see HAProxy). This can be used like Traefik to basically just proxy http requests to the right containers/applications based on host header or sni but it also has real load balancing capabilities too.
I am not a fan of the 37signals model. Basecamp is a terrible product. Last I used it with a partner, it still didn't support inline code highlighting. They're very opinionated about everything but I don't see their opinions driving good products. Kubernetes has been getting better with every release. I'd advise companies thinking of doing it better to implement their improvements to K8s directly so it can become a scalable, easy to use standard for everyone.
37signals is part of a contingent of reactionary developers and you can see this in HEY and now MRSK. It's reactionary without delivering real innovative value.
37signals is part of a contingent of reactionary developers and you can see this in HEY and now MRSK. It's reactionary without delivering real innovative value.
37signals is known for sustainable, human-being focused development among other things.
They solve problems by breaking them into first principles and composing them into shapes that fit them.
They've created RoR which at the time brought together with textmate millions of developers onto mac and "programming can be actually pleasant and cool" side. Their hero style page was copied everywhere on the internet which is visible to this day.
Many unicorns grew from RoR, many use it to this day.
They are open source advocates.
They create environment of certain kind of skepticism towards established tech while injecting novel approaches here and there.
You're saying something about inline code highlighting and jumping onto shitting over whole company and saying something about kubernetes.
It's hard to take it seriously even if you have a point there that some functionality is embarrassingly missing in one of their products.
They solve problems by breaking them into first principles and composing them into shapes that fit them.
They've created RoR which at the time brought together with textmate millions of developers onto mac and "programming can be actually pleasant and cool" side. Their hero style page was copied everywhere on the internet which is visible to this day.
Many unicorns grew from RoR, many use it to this day.
They are open source advocates.
They create environment of certain kind of skepticism towards established tech while injecting novel approaches here and there.
You're saying something about inline code highlighting and jumping onto shitting over whole company and saying something about kubernetes.
It's hard to take it seriously even if you have a point there that some functionality is embarrassingly missing in one of their products.
> human-being focused development
So human-being focused a third of their human-being employees quit after the CEO wrote a blog post! https://www.theverge.com/2021/4/30/22412714/basecamp-employe...
So human-being focused a third of their human-being employees quit after the CEO wrote a blog post! https://www.theverge.com/2021/4/30/22412714/basecamp-employe...
Yes, it's the prerogative of a company to not want its work environment to be polluted with discussions that have no relationship to the tasks at hand.
It is human-focused to not pussyfoot around such decisions but to instead bring clarity to the table and allow humans to make their choice.
More companies should be like that and, in fact, in Europe, still are.
It is human-focused to not pussyfoot around such decisions but to instead bring clarity to the table and allow humans to make their choice.
More companies should be like that and, in fact, in Europe, still are.
> no relationship to the tasks at hand.
> It is human-focused
Human-focused, as long as the human is white and male.
When you make a communications service, you probably want to involve a wide range of perspectives to make sure you build a good product that doesn't contribute harm. Specifically with Hey, they've walked back a bunch of features (props for being reactive, I guess) after they got a modicum of feedback from people that don't look like the two founders.
- https://twitter.com/dhh/status/1275991097261449216
"This is a great and important perspective we hadn’t considered" is a stunning example - You don't need to (and can't!) personally consider every perspective, but maybe if you involved more people in the product development process you get to catch these things before you release them. Human-focused.
- https://twitter.com/dhh/status/1275595820121776128
- https://twitter.com/dhh/status/1276173017060569089
> It is human-focused
Human-focused, as long as the human is white and male.
When you make a communications service, you probably want to involve a wide range of perspectives to make sure you build a good product that doesn't contribute harm. Specifically with Hey, they've walked back a bunch of features (props for being reactive, I guess) after they got a modicum of feedback from people that don't look like the two founders.
- https://twitter.com/dhh/status/1275991097261449216
"This is a great and important perspective we hadn’t considered" is a stunning example - You don't need to (and can't!) personally consider every perspective, but maybe if you involved more people in the product development process you get to catch these things before you release them. Human-focused.
- https://twitter.com/dhh/status/1275595820121776128
- https://twitter.com/dhh/status/1276173017060569089
Do you know how many people they did have working on this, or what people specifically were lacking to catch these? Do you have insight into what major problems they caught before release that they public never saw?
You seem to conflate “human focused” with “no disagreement s focused”.
Tweeting you ‘plan to leave’ is not the same as actually quitting.
I think his criticism is warranted when you think of 37signals without Ruby on Rails or the open source angle. Judging them just on their products.
I don't really see people refer to them as the cream of the crop. Basecamp's UX is opinionated but still complicated: I get lost on it even though it's a simple product. It seems to work well for a team more similar to 37signals'.
Hey.com I haven't seen take the world by storm, even though it does seem better than most e-mail software (and I do appreciate their technological solutions on it). I guess most people don't have that problem with e-mail that the Basecamp founders do.
That's a bit of a trend for them: they often claim people should do one thing and everything else is worse, even though that one thing really works for them and might not work for anyone else. Their agile methodology, their team size, their tech stack, etc. they often pose themselves as the "sane" ones doing it simple and easy, while everyone else is chasing the wrong thing.
So in that sense I can see why OP said they're reactionary. I would disagree, however, as they've been revolutionary on many fronts, but it's usually as part of a contrarian view that sometimes is more of a miss than a hit.
I don't really see people refer to them as the cream of the crop. Basecamp's UX is opinionated but still complicated: I get lost on it even though it's a simple product. It seems to work well for a team more similar to 37signals'.
Hey.com I haven't seen take the world by storm, even though it does seem better than most e-mail software (and I do appreciate their technological solutions on it). I guess most people don't have that problem with e-mail that the Basecamp founders do.
That's a bit of a trend for them: they often claim people should do one thing and everything else is worse, even though that one thing really works for them and might not work for anyone else. Their agile methodology, their team size, their tech stack, etc. they often pose themselves as the "sane" ones doing it simple and easy, while everyone else is chasing the wrong thing.
So in that sense I can see why OP said they're reactionary. I would disagree, however, as they've been revolutionary on many fronts, but it's usually as part of a contrarian view that sometimes is more of a miss than a hit.
Except they're fast and built with care, with graphic design given as much importance as technology itself (as in actual "interface problem solving", not "the same product as everyone else's, but with gradients and transparency"). Navigation's different but it's very good. The text editor is best-in-class. I don't prescribe to the notion that a professional worker should always have 64gb RAM so both Notion and Jira can be open at the same time, and I for myself appreciated that whatever page I was on was just a single page, an slightly interactive html page, and whenever I needed to go somewhere else I'd browse there clicking on hyperlinks, and get there fast. It might sound dated, but compared to, say, Asana and Monday or dear god Microsoft or Jira's "reinventions", it's really many years ahead.
(I have nothing to do with the company, just a happy client)
(I have nothing to do with the company, just a happy client)
One might or might not like 37 Signals and their products. Some of their ideas are fantastic, others not so much.
But claiming their text editor to be best in class when it is literal dogshit is brave.
But claiming their text editor to be best in class when it is literal dogshit is brave.
inline coding == BAD company, very opinionated everything. but you better to use: https://kubernetes.io/ because they are good people. /s
Some people like some products other people like others. There are tons of terrible products out there and many of them are also completely overengineered.
37signals and DHH did a lot right with Rails, so I'm looking forward to trying their approach on deployment.
IMO kubernetes is quite a lot of moving pieces that are absolutely not needed for most deployments, if you like it great! I'm sure many will love the opinions guiding MRSK (myself included).
I personally wouldn't touch K8s but I'm also not telling anyone not to try it.
37signals and DHH did a lot right with Rails, so I'm looking forward to trying their approach on deployment.
IMO kubernetes is quite a lot of moving pieces that are absolutely not needed for most deployments, if you like it great! I'm sure many will love the opinions guiding MRSK (myself included).
I personally wouldn't touch K8s but I'm also not telling anyone not to try it.
Basecamp is designed first to get people to use it who won't use anything else (non-technical clients, essentially.)
Syntax highlighting would be nice. They started their open source text editor before there were many good alternatives but didn't set themselves up to accept contributions. They lost the main two developers of it in the drama last year. Now that CKEditor 5 is out, they should probably switch to that...
Syntax highlighting would be nice. They started their open source text editor before there were many good alternatives but didn't set themselves up to accept contributions. They lost the main two developers of it in the drama last year. Now that CKEditor 5 is out, they should probably switch to that...
I'm first to crap on K8s but I do agree w/ you here...
Feels a bit surreal seeing a 'tool' that wraps Traefik + Docker Swarm be so self-aggrandizing.
Feels a bit surreal seeing a 'tool' that wraps Traefik + Docker Swarm be so self-aggrandizing.
> I'm first to crap on K8s
OK to each their own.
Do you object to YAML? Kubelet?
It seems like a pretty solid approach to me. Some have been misdirected by it because something that uses a sizable fraction of a CPU doesn't work for their use case, but that speaks more to the lack of an alternative to Docker Compose, which Kubernetes wasn't intended to be.
OK to each their own.
Do you object to YAML? Kubelet?
It seems like a pretty solid approach to me. Some have been misdirected by it because something that uses a sizable fraction of a CPU doesn't work for their use case, but that speaks more to the lack of an alternative to Docker Compose, which Kubernetes wasn't intended to be.
I was griping re: MRSK not so much K8s.
Kubernetes is 'fine' in the sense that a sledgehammer can, technically, open a door...
Kubernetes is 'fine' in the sense that a sledgehammer can, technically, open a door...
Upvoted this, because opinions about an opinionated product should be allowed.
Fully agree that 37Signals’ products are very opinionated and often missing crucial features. I can see that they fulfil some use-cases, but could be more mainstream.
Fully agree that 37Signals’ products are very opinionated and often missing crucial features. I can see that they fulfil some use-cases, but could be more mainstream.
I don’t have a problem with opinions on products, but urging people to “do x instead of y because standards” is such an intellectually lazy take, especially when the party being criticized has led development on some of the most influential open source projects in history.
I’d love to see OP do anything as remotely influential in the industry as DHH.
I’d love to see OP do anything as remotely influential in the industry as DHH.
> I’d love to see OP do anything as remotely influential in the industry as DHH.
I vastly prefer their appeal to standards over your appeal to authority.
I vastly prefer their appeal to standards over your appeal to authority.
[deleted]
What? Appeals to standards are appeals to authority.
Are you sure you can’t see the nuanced difference in this case?
There can be differences between appeals to authority, and there's also a difference between an appeal to standards and an appeal to (the common, shared hacker value of) standardization.
But no such differences are captured by calling one appeal to authority 'an appeal to authority' in contradistinction to another.
But no such differences are captured by calling one appeal to authority 'an appeal to authority' in contradistinction to another.
Personally, I find quite a big difference between the standard of the already widespread usage of K8S versus the cult of personality around DHH who is abrasively opinionated at times.
Their standard is rational thinking though first principle decomposition - if it still holds through their evaluation, it'll stay as standard, otherwise it's not a standard from their PoV.
> They're very opinionated about everything...
So is Apple, and it seems to work for them.
So is Apple, and it seems to work for them.
Apple's opinions seem to be agreeable...
And yet there are entire sub-threads all over this forum every week with people voicing a preference for Microsoft over Apple for development work. This was my point.
He mentioned partitioning bare-metal into VMs (which is a good idea, containers aren't a great security boundary) but it doesn't look like MRSK does that (yet?).
I can see using this to deploy on DO or Hetzner to save a few bucks vs Render or Amplify- but on bare metal you're giving up a pretty amazing ecosystem these days. Ie. if you want to run stateful things like databases, logging/monitoring, NFS, object storage, persistent disks, complex networking, etc it's going to be miles easier to manage that w/ k8s. Even for that bare-metal/vm-partitioning goal above, there is a k8s runtime (kata-containers) which will automatically run containers on lightweight vms and handle all the plumbing to and from K8s. Plus if your mid-size SaaS wants to sell to the whales you're going to need compliance and security best practices that are much easier to implement and enforce w/ k8s. Finally, there are also lighter weight distributions these days to make it less painful to run yourself.
That said, I do appreciate the 37signals philosophy of having such strong opinions they craft their own tools and I also applaud leaving the cloud for bare metal. Even if you need the burst capacity you can provision your base-load on bare-metal and burst to the cloud when needed.
I can see using this to deploy on DO or Hetzner to save a few bucks vs Render or Amplify- but on bare metal you're giving up a pretty amazing ecosystem these days. Ie. if you want to run stateful things like databases, logging/monitoring, NFS, object storage, persistent disks, complex networking, etc it's going to be miles easier to manage that w/ k8s. Even for that bare-metal/vm-partitioning goal above, there is a k8s runtime (kata-containers) which will automatically run containers on lightweight vms and handle all the plumbing to and from K8s. Plus if your mid-size SaaS wants to sell to the whales you're going to need compliance and security best practices that are much easier to implement and enforce w/ k8s. Finally, there are also lighter weight distributions these days to make it less painful to run yourself.
That said, I do appreciate the 37signals philosophy of having such strong opinions they craft their own tools and I also applaud leaving the cloud for bare metal. Even if you need the burst capacity you can provision your base-load on bare-metal and burst to the cloud when needed.
I had the impression k8s is still not recommended to run a DB or any kind of persistence. Are any large companies doing that in production?
Regarding logging, object storage, how does kubernetes help? You'll have to implement these regardless of the underlying container infra.
Regarding logging, object storage, how does kubernetes help? You'll have to implement these regardless of the underlying container infra.
Yes. Lots of companies run things like ElasticSearch and Cassandra in Kubernetes. And even sharded RDBMS's are doable now thanks to projects like Vitess, which famously underpinned YouTube. Basically if there's a mature k8s operator for the DB in question, it's pretty straight forward. The "use containers/k8s for stateless stuff only" approach is very dated.
As far as I understand Zalando does this. They have their own PostgreSQL operator https://github.com/zalando/postgres-operator.
Ondat does that, a bunch of people are using them. And Akamai acquired them, probably to scale their model
This looks to me like something that has 5% of the features of dokku. If you want a slimmed down dokku that seems great. But I'm wondering if I love dokku why I would choose this. What am I missing?
The switching to live containers and proxy integration seems like table stakes these days. Is traefik that much better than nginx in all cases?
And, dokku just works with almost any kind of web app (regardless of the language) i throw at it. It's amazing for just git cloning something, create a dokku app and new git remote and then just push and see if it works, which it does almost all the time. It's super fun to experiment with something new and just see what happens.
The switching to live containers and proxy integration seems like table stakes these days. Is traefik that much better than nginx in all cases?
And, dokku just works with almost any kind of web app (regardless of the language) i throw at it. It's amazing for just git cloning something, create a dokku app and new git remote and then just push and see if it works, which it does almost all the time. It's super fun to experiment with something new and just see what happens.
Dokku maintainer here.
For anyone wondering, Dokku supports Traefik in addition to Nginx, as well as Caddy and Haproxy.
For anyone wondering, Dokku supports Traefik in addition to Nginx, as well as Caddy and Haproxy.
used dokku too but faced a couple of issues over time including very slow deploys for some reason.
also fubdamentally dokku is single server whereas MRSK is multi-server. not that I need that but worth pointing out as a difference
also fubdamentally dokku is single server whereas MRSK is multi-server. not that I need that but worth pointing out as a difference
Dokku Maintainer here.
I'd love to hear more about the issues you've faced, even if you're not using Dokku anymore. It helps me improve the project for others.
Regarding multi-server support, we support Kubernetes and Nomad for job scheduling - and have for years - which I think should make us multi-server capable. Are you looking for something else?
I'd love to hear more about the issues you've faced, even if you're not using Dokku anymore. It helps me improve the project for others.
Regarding multi-server support, we support Kubernetes and Nomad for job scheduling - and have for years - which I think should make us multi-server capable. Are you looking for something else?
MRSK is a bit more focused on deployment and server management: it only needs SSH access to configure a server and deploy your application. Dokku still requires managing/installing servers manually.
Dokku Maintainer here.
Is the issue that you only need to `gem install mrsk` locally vs running our bootstrap script to install Dokku on a remote server? I'm not sure what the difference is maintenance-wise between Dokku and MRSK, as at the end of the day you still have a server you need to maintain/upgrade for both products.
Is the issue that you only need to `gem install mrsk` locally vs running our bootstrap script to install Dokku on a remote server? I'm not sure what the difference is maintenance-wise between Dokku and MRSK, as at the end of the day you still have a server you need to maintain/upgrade for both products.
So it’s trying to both tackle provisioning and deployment at the same time? Why not just use more powerful tools for each role - e.g., provision with Ansible and deploy with Dokku?
I'm not going to claim that Kubernetes on bare-metal is easy, but it's certainly doable. And it's worth doing, because of all the ecosystem work that's been built up on Kubernetes over the last several years, everything from observability, to workload scaling, to database management, to multi-datacenter service networking. Switching to something new (MRSK), means throwing that out. How is MRSK 10x better to make it worth losing the ecosystem?
Of course you need full-time admins to babysit your bare-metal Kubernetes clusters. But if you're running bare metal, you made the financial decision that (cost of full-time InfraOps Engineers + cost of bare-metal servers <<< cost of IaaS cloud). So you're already paying for full-time InfraOpEng. In this day and age, is it really reasonable not to expect them to know Kubernetes cluster management as well?
Of course you need full-time admins to babysit your bare-metal Kubernetes clusters. But if you're running bare metal, you made the financial decision that (cost of full-time InfraOps Engineers + cost of bare-metal servers <<< cost of IaaS cloud). So you're already paying for full-time InfraOpEng. In this day and age, is it really reasonable not to expect them to know Kubernetes cluster management as well?
Btw Traefik is an excellent proxy:
https://traefik.io/traefik
Far too few people know about it IMO
https://traefik.io/traefik
Far too few people know about it IMO
I’ve been trying out many reverse proxies for stateful, low-traffic websocket connections, but unfortunately they all eat so much ram. Even nginx, with tuning, use at least 10x ram/conn of a well tuned naked uWebSocket deployment with TLS.
Traefik was much more ram hungry than nginx, and iirc Caddy as well (at least 2 goroutines per conn). It’s probably fine (and worth it) for the vast majority of request-response web apps, but all of these extra layers have a cost. And that’s still nothing compared to the overhead of say k8s with all bells and whistles.
Anyway, as someone who’s been out of the loop on backend for many years, I am quite shocked at the level of resource waste, even among the projects with a strong reputation. You always hear the complaints about frontend bloat, but these days backend seem to have caught up.
Traefik was much more ram hungry than nginx, and iirc Caddy as well (at least 2 goroutines per conn). It’s probably fine (and worth it) for the vast majority of request-response web apps, but all of these extra layers have a cost. And that’s still nothing compared to the overhead of say k8s with all bells and whistles.
Anyway, as someone who’s been out of the loop on backend for many years, I am quite shocked at the level of resource waste, even among the projects with a strong reputation. You always hear the complaints about frontend bloat, but these days backend seem to have caught up.
Yeah I’m personally of the opinion that the performance loss for regular web services is worth it 99% of the time. RAM is cheap, human time is not.
That said I definitely believe your characterization of resource hunger between nginx and traefik.
You are the second person to mention using websockets for requests in as many days… How do you deal with scale out? Sticky cookie routing seems like almost a requirement if you don’t want to deploy a redis-alike.
Also just out of curiosity, do you use hyper-express[0]?
[0]: https://github.com/kartikk221/hyper-express
That said I definitely believe your characterization of resource hunger between nginx and traefik.
You are the second person to mention using websockets for requests in as many days… How do you deal with scale out? Sticky cookie routing seems like almost a requirement if you don’t want to deploy a redis-alike.
Also just out of curiosity, do you use hyper-express[0]?
[0]: https://github.com/kartikk221/hyper-express
Really? I believe it is one of the most known proxies besides Nginx and apache. Especially in docker environments.
Yes, really. I was interviewing last year and used it in one of the projects on my resume. Almost nobody knew what it was. In fact, exactly 1 out of 25-30 people I discussed the project with knew what Traefik was..
Sad days. I am fairly active in the self hosting scene. Traefik is a superstar there right after caddy.
> fairly active in the self hosting scene
Though that is probably why - Traefik is popular for self-hosting, while Caddy is more generally mainstream.
Though that is probably why - Traefik is popular for self-hosting, while Caddy is more generally mainstream.
Isn't it the opposite? Traefik is more common in the enterprise as an nginx replacement for k8s, while Caddy is easier to setup and great for self-hosting - I've never seen it used in enterprise environments.
You could be right - I’ve only heard of Traefik in self-hosting contexts.
I'm one of the many who hadn't heard of Traefic until MRSK mentioned it. The marketing seems very (overly?) targetted at cloud microservices and container-specific tech[1]. Is that just marketing, or is it really not a good fit for monoliths on bare-metal?
[1] https://github.com/traefik/traefik "Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components (Docker, Swarm mode, Kubernetes, Consul, Etcd, Rancher v2, Amazon ECS, ...) and configures itself automatically and dynamically. Pointing Traefik at your orchestrator should be the only configuration step you need."
[1] https://github.com/traefik/traefik "Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components (Docker, Swarm mode, Kubernetes, Consul, Etcd, Rancher v2, Amazon ECS, ...) and configures itself automatically and dynamically. Pointing Traefik at your orchestrator should be the only configuration step you need."
I wish I could upvote this more!
Traefik is absolutely amazing! And it seems like in the development community every wants to use nginx. But in my experience traefik is absolutely perfect for proxying with container deployed applications.
Traefik is absolutely amazing! And it seems like in the development community every wants to use nginx. But in my experience traefik is absolutely perfect for proxying with container deployed applications.
I want to learn Traefik but it yet again has another overly verbose config file. They could learn a lot from caddy. Is it better enough to deal with learning a new DSL?
I'd stick to Caddy. I deprecated my old traefik reverse proxy and tls config which took me days to get right earlier mostly due to my lack of understanding, but the config and DSL is a little tricky too. With Caddy its literally 4 lines of code. Sane defaults are really powerful. I don't have any comments on performance etc as these are hobby projects, I did like traefik's dashboard though.
I find traefik does really well in dynamic, more complex environments (like kubernetes).
It also really depends on what you want out of the proxy.
Probably makes sense to try caddy first for simpler use cases and graduate to traefik if you find some features you want to have (like l4 traffic that isn’t alpha:beta)
It also really depends on what you want out of the proxy.
Probably makes sense to try caddy first for simpler use cases and graduate to traefik if you find some features you want to have (like l4 traffic that isn’t alpha:beta)
Ugh. This still isn't quite what I want. I can't stand Docker. It's so damn heavy.
All I want is something like the following:
- Sandboxed applications
- With an agent to control which ones run on a machine
- A GUI to easily observe and manage deployments
- Infra-as-code using a sensible file format (anything but YAML)
I imagine this working best with VM-based runtimes like .NET and WASM. The ability to control resources consumption isn't there yet, but I don't see why you couldn't have a runtime that gives fine-grained controls over sandboxing and resource consumption.
This idea came about from observing discourse on replacing conventional hypervisors with WASM/WASI.
Forget Docker. Forget OCI. Forget Kubernetes/SWARM. We just need a simple system for orchestrating apps that are already VMs.
All I want is something like the following:
- Sandboxed applications
- With an agent to control which ones run on a machine
- A GUI to easily observe and manage deployments
- Infra-as-code using a sensible file format (anything but YAML)
I imagine this working best with VM-based runtimes like .NET and WASM. The ability to control resources consumption isn't there yet, but I don't see why you couldn't have a runtime that gives fine-grained controls over sandboxing and resource consumption.
This idea came about from observing discourse on replacing conventional hypervisors with WASM/WASI.
Forget Docker. Forget OCI. Forget Kubernetes/SWARM. We just need a simple system for orchestrating apps that are already VMs.
you hate Docker, OCI, and yaml?
kind of hipster?
kind of hipster?
Caprover comes close to this. You can pack your app into a zip file and upload it with a special file or choose pre-packaged apps.
I find Docker running a full Linux userspace a little bloated. Thankfully there are distroless base images(https://github.com/GoogleContainerTools/distroless). Haven't done service dev in a while, so I don't really have experience with this, but it looks promising.
Distroless is great for things that compile to static binaries, I use it for Rust apps. For anything that pulls in heavy dependencies, having a package manager is convenient (alpine, debian-slim).
It's 2023 and a dev deploying an app needs to know the physical IPs of a machine it's going to deploy on, really good design.
Its in the same repo, yes, but don't have to care about it, just as you may not care about Ci artifacts or editor config files, or gitignore files or whatever.
That info has to live somewhere, and in the same repo as the code doesn't sound that bad.
That info has to live somewhere, and in the same repo as the code doesn't sound that bad.
The value proposition of MRSK is to deploy servers on a few machines that you physically own.
Their focus is not on serverless-cloud-native-infinite-scaling.
Their focus is not on serverless-cloud-native-infinite-scaling.
While I realy love DHH and his blog, and noticed MRSK while he was writing about their cloud exit (very nice story, highly recomended) I have to wonder, why would I use this instead of Nomad?
It supports similar usecase but Nomad is more mature, activelly improved, supports non-docker environments and is cross-platform.
It supports similar usecase but Nomad is more mature, activelly improved, supports non-docker environments and is cross-platform.
Like most things system, this can be replaced with regular existing tools and a shell script. You will gain a lot more valuable knowledge and experience by learning how to use existing systems, rather than picking up yet another magic unicorn tool that promises you the moon but won't help you when it breaks.
Do you plan to be doing this job for the next 10 years? Then set aside the time to learn system tools and scripting. The time investment, however long it takes, will pay itself off many times over, guaranteed.
Do you plan to be doing this job for the next 10 years? Then set aside the time to learn system tools and scripting. The time investment, however long it takes, will pay itself off many times over, guaranteed.
Or, you could use existing tools and patterns so the next person picking up your project has even the slightest chance of being productive.
Yes you can glue things together with existing stuff. Let's not pretend that cgroups+namespaces+dnsmasq (or whatever) tech is actually a better solution. It might be "simple" via some metric, but it's yet another ad-hoc piece of engineering that has to be understood and maintained.
I've seen this at a former job, and it was an absolutely horrible idea.
Yes you can glue things together with existing stuff. Let's not pretend that cgroups+namespaces+dnsmasq (or whatever) tech is actually a better solution. It might be "simple" via some metric, but it's yet another ad-hoc piece of engineering that has to be understood and maintained.
I've seen this at a former job, and it was an absolutely horrible idea.
Sure. But if you're going to use a "real" system that can be adopted by others, you might as well use the most popular, well known, well funded, well supported tool out there. Using this "Capistrano alternative" won't be familiar for people that come after, and they'll spend just as much time learning it as learning a janky shell script, except the janky shell script is at least tailored to your use case.
I'd agree with that too.
I'd be open to something truly simple (Nomad perhaps?) over K8S in some scenarios, but if I'm going to take a gamble, it's going to have to be a lot simpler to provide enough benefit on taking a chance on a less popular piece of tech.
I'd be open to something truly simple (Nomad perhaps?) over K8S in some scenarios, but if I'm going to take a gamble, it's going to have to be a lot simpler to provide enough benefit on taking a chance on a less popular piece of tech.
It’s not immediately obvious to me how this differs from something like ansible which people have been using for years for basic deployment topologies. What am I missing?
edit: after looking a bit closer, I think it’s a bit misleading to call what this is doing “zero downtime”. as far as I can tell, your services are essentially going to be unresponsive until they start, which can be brutal for slow starting ones (and that’s assuming they start successfully)
edit: after looking a bit closer, I think it’s a bit misleading to call what this is doing “zero downtime”. as far as I can tell, your services are essentially going to be unresponsive until they start, which can be brutal for slow starting ones (and that’s assuming they start successfully)
Nice, this reminds me of something from a few years ago:
https://github.com/mikew/b3cmd-server
https://github.com/mikew/b3cmd
This used docker-compose + git.
https://github.com/mikew/b3cmd-server
https://github.com/mikew/b3cmd
This used docker-compose + git.
Can MRSK be used to manage deploying applications that are distributed as Docker images, such as Adguard Home?
I see there is support for ‘accessories’ such as Redis. What if I only want to deploy an image and skip building a Dockerfile and pushing it to a registry?
I see there is support for ‘accessories’ such as Redis. What if I only want to deploy an image and skip building a Dockerfile and pushing it to a registry?
Yup, use an accessory for that. I used it to setup a Minecraft server for our last company meetup.
I agree, there should be a way to have the primary app be an image that doesn’t get built/pushed.
I agree, there should be a way to have the primary app be an image that doesn’t get built/pushed.
Related discussion: "MRSK vs Fly.io" (162 comments): https://news.ycombinator.com/item?id=35263886
Also here is the MRSK introduction blog post: https://world.hey.com/dhh/introducing-mrsk-9330a267
Also here is the MRSK introduction blog post: https://world.hey.com/dhh/introducing-mrsk-9330a267
Slightly off-topic, but my ChatGPT instincts always tend to fire whenever I read copy that concludes with the formula, “Ultimately…” or “Overall…”.
I wonder how much (if any) of this landing page was GPT generated.
I wonder how much (if any) of this landing page was GPT generated.
The confusing part is, how to put a load balancer in front of those deployed servers ?
If your “host servers” are known (say 4 backends) you set up the balancer and point it to the 4 host IPs.
If you are dynamically allocating host servers and needing to register them with the LB you should probably consider K8s?
This is designed for a “more stable” world:
Have some hosts. Have an LB. Deploy containers to those hosts. Avoid superfluous k8s complexity that you don’t need.
If you are dynamically allocating host servers and needing to register them with the LB you should probably consider K8s?
This is designed for a “more stable” world:
Have some hosts. Have an LB. Deploy containers to those hosts. Avoid superfluous k8s complexity that you don’t need.
I don't think you need K8S for that. Any decent load balancer (LB) is going to have some concept of origin configuration that weights routing with various algorithms and health checks. You would just update the config in the LB when you bring a new origin online.
Load balancing isn't part of MRSK - all public clouds offer them, Digitalocean does as well. Or DIY with Haproxy, Nginx, Traefik, etc.
I’m also interested in this setup and have so far only had experience using HAProxy. Any alternatives HN can recommend?
(software)
Sorry one of the key part of deploying web applications is not part of the offering.
He sets up a load balancer in his demo video? Did you watch it?
looks nice and tries to solve a problem i had a while ago: how to deploy a small dockerized app to a cheap vm with declarative deploy (like k8s) but without k8s.
anyone know a similiar tool?
anyone know a similiar tool?
You can ship your local docker context to a remote host and build/run your containers there. All the docker commands you typically run locally you can run on the remote host.
https://www.docker.com/blog/how-to-deploy-on-remote-docker-h...
https://www.docker.com/blog/how-to-deploy-on-remote-docker-h...
thanks! I was a little bit confused at first because I've always taken docker compose as a tool mainly for spinning up dev environments. But I read mentioned article and it looks perfectly valid for single host deployments.
One thing which bothered me is how i manage container versions usually made with hashes but all you need is to either make sth like a compose template like file which would have a version placeholder or specify production compose configuration on top of the default one.
https://stackoverflow.com/a/71194294 https://docs.docker.com/compose/production/
https://stackoverflow.com/a/71194294 https://docs.docker.com/compose/production/
MRSK was designed to handle deployment of 37Signals products to bare metal servers and it does that well. However when it comes to deploying to cloud it falls short by a lot: start with dealing with cloud native load balancers (ELB, ALB, …) as services come and go, or persistent storage requirement for state full services and much more you’ll need to take care of yourself.
I think it’s important to remember that MRSK is a bare metal department tool and not really designed for the cloud, as per the creators’ statements. https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47...
I think it’s important to remember that MRSK is a bare metal department tool and not really designed for the cloud, as per the creators’ statements. https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47...
I use Qemu/KVM VMs and then deploy Apps with Docker Compose and Ansible (including Traefik).
Would this make my workflow obsolete or easier?
Would this make my workflow obsolete or easier?
Do not get wedded to that name…
Maersk will be in touch to gently ask that MRSK desist using their trademark.
Maersk will be in touch to gently ask that MRSK desist using their trademark.
IANAL, but my understanding is that trademark law is based on the idea of avoiding confusion in the marketplace. It's possible to have similarly named products in completely different industries without violating trademark law because they won't confuse potential buyers of the product.
THAT said, I'm not sure I personally would take the gamble!
THAT said, I'm not sure I personally would take the gamble!
A terminal had to change the name from Terminix to Tilix due to trademark issues, even though one is a terminal and the other is a pest killer.
https://github.com/gnunn1/tilix/issues/815
https://github.com/gnunn1/tilix/issues/815
Oh yeah, that's a good point. Given my understanding of trademarks, I'm not sure Terminix's claim would hold up in court, _but_ that's irrelevant because people don't generally want to go to court. I doubt 37signals would go to court to keep the MRSK name.
I wouldn't be so sure knowing the stubbornness of DHH...
I’m using it to deploy a dockerized nodejs app, it works great!
How does it compare to Coolify?
[deleted]
This should probably be seen in the context of this: https://twitter.com/dhh/status/1613508201953038337
I’m gearing up to deploy a Nextjs project in the next few months and while I appreciate the claims of Function this and Edge that, I feel infinitely more comfortable with a couple small server instances, especially early on when my focus should be testing my product, not optimizing my cloud infrastructure for scale that might never be needed. I’m excited to give MRSK a shot and feel grateful to live in a time when there are so many good choices.