Framework-Defined Infrastructure | Hacker News Reader

Framework-Defined Infrastructure

vercel.com

47 pointstodsacerdoti17 comments

I don't feel comfortable about this at all. It seems like the absolute Railsification of the entire deployment pipeline, magic everywhere. And don't get me wrong, I mainly work with Rails, but the truth is, that the abstraction layers need to be understood, especially for deploying infrastructure, if everything is managed elsewhere, then how do I troubleshoot stuff? It is no longer in my control.

I think it was really convenient to have platforms like Heroku to deploy quick test environments, but sprinkling magic to everything just to indulge the increased complexity of javascript frameworks its just not sane.

There was this one time, I was interviewing for a devops position. They didn't have anyone like that despite growing to a fairly large organization, and ultimately, balked on my asking salary. The organization's notion of devops is Heroku, and their notion of scaling is sliding that bar to add more servers.

It can work, though it gets expensive fast.

Well yes, and I feel like if you're part of a small team, you do want to have much more control over the deployment strategy and implementation, you do want to have ironed-out documentation and perhaps you even want every member of the core team to be able to act in a heartbeat to re/deploy when needed.

On the other hand, of you do have the resources, then it is likely that you will have money to pay for the engineers and have an operating devops team.

So, yeah, while there is probably some place in the middle of these cases where this abstraction can work I think for the vast majority of software implementations this is merely a solution looking for a problem, and of course, as long as a collective we refuse to address the extreme added complexity brought into the field by the Javascript ecosystem we are never going to eventually find true solutions for any engineering problem.

No, this is strictly a regression. A perversion even.

Infrastructure is what you ultimately pay for. making that more complicated (contextual, my ass) so that people might give up faster and "just use vercel" is very clearly the driver here.

Usually, companies even have guidelines what developers can use and how, probably none of these fancy new cloud-for-your-framework-aaS things are allowed. And often not running into just another lock-in situation has business value.

A great framework allows you to ship your code into multiple different infrastructure situations (on prem servers, kubernetes, aws lambda, ...) and "just work" by abstracting over the individual infrastructure specifics.

Also IaC is not a buzzword, you may have infrastructure engineers that already agreed on a specific tool (CDK, terraform, pulumi, ...) and have built extensions to deal with internal specifics of the company and really want to leverage them across projects.

Having something like the _framework_ dictate all that is like completely going backwards. I can't think of any explanation other than trying to promote that lock-in towards younger developers that haven't felt these pains of lock-in before.

I think these are all good concerns. Where FdI runs counter to lock-in is applications do not "know" the target platform (as in they don't hard code any dependency on the platform). Respectively, the app is staying portable to every target that the app can deploy to.

Look, it’s the AMP guy. He’s CTO of Vercel now?

Edit: I can’t overstate how much this changes my perception of Vercel. I thought they genuinely cared about the open web, but I guess that was just good branding.

> I thought they genuinely cared about the open web

What made you think that? Honest question as I feel out of the loop.

They seemed to care about making it easy to make good websites, and they hired Rich Harris to work on Svelte. Overall I’ve gotten good vibes and values from them. But AMP was built on toxic values, and dishonesty. Hiring a CTO who was responsible for that undermines all their previous communication in my eyes.

Reading the post makes me want to believe this is possible but I cannot for the life of me, imagine it. I feel like for a product like this to exist, it has to 1) have a ton of resources into smoothing the experience between cloud provider APIs or/and 2) make some high level abstractions that are far from optimized (from a resource or $ perspective).

I'd love to see some examples or case studies showing the potential for something like this.

How is this novel compared to say, Chef Habitat?

Vercel might be able to pull this off... I would be curious to see how they figure their way around the design principle of "complexity has to live somewhere".

super interesting. How do you workout the idiosyncrasies between different providers? If you restrict yourself to IaaS that shouldn't be an issue, but functions vs lambda vs cloud-run vs etc all have significant differences.

The way we handle it is to provide a "runtime" within those environments to normalize behavior along the lines that the framework expects.

Sounds like Chef Habitat.

Author here: Happy to answer questions about the post!

Does framework-defined-infrastructure also work for stateful infrastructure? All of the examples in the blog entry are stateless (functions, edge workers, etc).

Yeah, good question. For stateful infrastructure the way we are exploring it is basically like: "Hey, it looks like you expect to talk to a database and we've never seen this before. Would you like us to make one?" …and then going forward the mapping is persisted.

OK, it's like a meta-docker-compose generator ?

Reply on news.ycombinator.com