Hacker News Reader

Comment by sickcodebruh | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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

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.

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

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.

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

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.

Reply on news.ycombinator.com