5 ms·

MRSK is like something pulled straight from my dreams. Longtime Capistrano user, loves Docker for reproducible environments but still hasn’t mastered using it i

MRSK is like something pulled straight from my dreams. Longtime Capistrano user, loves Docker for reproducible environments but still hasn’t mastered using it in prod because I’m a dinosaur who just wants servers and a load balancer. 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.

lobstrosity420 3y ago
> 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.
- PragmaticPulp 3y ago
  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.
  - breakfastduck 3y ago
    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.
  - BackBlast 3y ago
    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.
- aigoochamna 3y ago
  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.
  - abdellah123 3y ago
    it is. Some features only work on their edge runtime !
Kiro 3y ago
> 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.
- aigoochamna 3y ago
  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.
  - sickcodebruh 3y ago
    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.
  - sureglymop 3y ago
    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.
- axelthegerman 3y ago
  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
  - bityard 3y ago
    Also, never underestimate the utility of being able to perform upgrades (either the app or the underlying infrastructure) with little to no downtime.
lordofmoria 3y ago
> 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
- mirekrusin 3y ago
  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.
- brightball 3y ago
  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.

lobstrosity420 3y ago

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

PragmaticPulp 3y ago
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.
- breakfastduck 3y ago
  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.
- BackBlast 3y ago
  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.
aigoochamna 3y ago
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.
- abdellah123 3y ago
  it is. Some features only work on their edge runtime !

Kiro 3y ago

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

aigoochamna 3y ago
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.
- sickcodebruh 3y ago
  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.
- sureglymop 3y ago
  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.
axelthegerman 3y ago
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
- bityard 3y ago
  Also, never underestimate the utility of being able to perform upgrades (either the app or the underlying infrastructure) with little to no downtime.

lordofmoria 3y ago

> 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

mirekrusin 3y ago
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.
brightball 3y ago
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.