Live data from Hacker News

Infrastructure From Code

shuttle.rs

21–30 of 44 posts

Re: Infrastructure From Code

#21

> dependencies like databases being provisioned through static analysis in real-time. I'm probably extremely biased (I'm a sysadmin), but this feels like a terrifying way to make your infrastructure entirely implicit and remove anybody's ability to coherently reason about the stuff underneath your application.

> but this feels like a terrifying way to make your infrastructure entirely implicit

This exact problem is my main beef with an unfortunately common and popular style of functional programming : stuff so condensed, so abstracted and so focused on describing the problem all the while hiding the actual execution / implementation / solution layers it's quasi-impossible to reason about and understand what actually happens when the program runs.

Re: Infrastructure From Code

#22
I love this idea, i've been thinking about this for a few years under the pseudonym 'compile to cloud'. Would be really cool if I could write some code that uses a dictionary & threads which automatically get transposed to a dynamodb instance connected to a bunch of lambda nodes. I'll keep an eye on this project.

Re: Infrastructure From Code

#24

> dependencies like databases being provisioned through static analysis in real-time. I'm probably extremely biased (I'm a sysadmin), but this feels like a terrifying way to make your infrastructure entirely implicit and remove anybody's ability to coherently reason about the stuff underneath your application.

Scarier to imagine a bug in the static analysis code :)

Re: Infrastructure From Code

#25

> the code that developers write implicitly defines infrastructure. What your code actually needs in terms of infrastructure should be inferred as you build your application, instead of you having to think upfront about what infrastructure piece is needed and how to wire it up. Your code runs somewhere. On something. In something. At a physical place, with physical cords running around to physical boxes of stuff. The…

I believe the direction they are going is that you have it implicitely define a default infrastructure, and then if you want to customize it you can. This seems reasonable to me. For prototyping or MVP, just go with the defaults. As your product gains maturity you can hire domain experts to fine tune the infrastructure, while keeping it as separate from the business logic as possible

Re: Infrastructure From Code

#26
post #18

> Serverless (think AWS Lambda) was a new cloud computing execution model This is older than author realizes. Google App Engine was doing this in 2008, 6 years before Lambda.

GAE was far worse from a UX perspective. As an outsider from Google, the handcuffs imposed by AppEngine we're severely restrictive compared to Lambda-like services.

Do you mean DevX?

Re: Infrastructure From Code

#27

Is spinning up a cloud-managed database really infrastructure as code? Seems more like SaaS from code. To me, infrastructure from code would at bare minimum mean spinning up a Kubernetes cluster capable of deploying database and similar containers so that you're not paying a premium to have some blackbox cloud service supposedly managing your services.

Infrastructure has multiple layers. Why does your bare minimum infrastructure start with Kubernetes and not with the OS underneath? Why does it start with the OS and not the firmware configuration? Why does it start with the firmware and not the hardware configuration you order from the vendor?

Re: Infrastructure From Code

#28

> dependencies like databases being provisioned through static analysis in real-time. I'm probably extremely biased (I'm a sysadmin), but this feels like a terrifying way to make your infrastructure entirely implicit and remove anybody's ability to coherently reason about the stuff underneath your application.

Hey! I'm one of the maintainers of the project so I thought I would address some of the comments here :)

> this feels like a terrifying way to make your infrastructure entirely implicit and remove anybody's ability to coherently reason about the stuff underneath your application.

There's two parts to this. The first is understanding what is happening under the hood since we're automatically provisioning so much for you (subdomain, LBs, DBs, etc.). Right now this is a little opaque, but a dashboard is in the roadmap to give users visibility on what's happening 'under the hood' - showing your provisioned infrastructure as well as how it's all wired up.

The second point is about potentially destructive actions - here we're going to be following a 'terraformesque' philosophy where infrastructure diffs are presented to the user and need to be accepted explicitly when deploying (or via a `--auto-approve` flag).

Re: Infrastructure From Code

#29

This is a pedantic side comment, but I believe the very first sentence of this article is incorrect! AFAIK, Facemash was hosted on Zuckerberg's personal computer in his dorm room; ditto for the first version of Facebook shortly thereafter. After that, it was moved to a rented server. source: I didn't attend Harvard, but I worked for their IT department beginning in 2005. Several of my coworkers had been directly invo…

> ditto for the first version of Facebook shortly thereafter.

Thanks for this! I found a different source[0] but I'll make the update shortly!

[0] https://qr.ae/pvAGDH

Re: Infrastructure From Code

#30
Not a single mention here of ansible, Terraform, puppet, chef or any other ways that this is actually done at scale.

You can’t readily build infrastructure from Code in a way that allows for solid uptime, redundancy, resiliency, or performance.

It sounds like a system like this would be fine for testing and possibly QA but definitely not for production.

Post reply on HN