Infrastructure From Code

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.

source: I didn't attend Harvard, but I worked for their IT department beginning in 2005. Several of my coworkers had been directly involved in the disciplinary action against Zuckerberg and were very familiar with the details. That said, it is entirely possible I am misremembering. But other accounts seem to agree, e.g. https://www.quora.com/How-did-Mark-Zuckerberg-initially-host...

Infrastructure from code seems convenient for side-projects, but absolutely awful for something big where your infrastructure is now implicit in your code??

I know of only two tools that work effectively: Terraform & Pulumi. Terraform's config language has major flaws and Hashicorp is not interested in fixing them. For example, one cannot use a single Terraform config to create a database instance and a database inside it, or a VM and a server inside it, etc. So every application requires multi-stage configs which are full of footguns. Pulumi supports proper languages like Python & Golang and does not have this problem.

I would like to see a Rust version of Pulumi that uses static typing to eliminate run-time errors in infrastructure config. Maybe Shuttle will become that? It looks like they're integrating the web server with the infrastructure code. I think they should go in the opposite direction and make everything modular (usable separately) and composable. I want to write `deploy.rs` and run `cargo deploy`.

> To reap the benefits of serverless, you have to build your application as a multitude of stateless request or event handlers, often requiring a bottoms-up redesign of your system. For some use-cases the serverless paradigm works, but in many cases breaking things into discrete, decoupled functions may not be optimal or even feasible. The next question is, can we have our cake and eat it too? Can we maintain the paradigm of stateful processes and abstract away the underlying infrastructure and orchestration?

There's a key distinction here that Shuttle seems to pave over. In microservices design, ideally each microservice entirely owns its own datastores; to interact with the datastore, outside actors must interact with the service and not directly with the datastore (enforced either by convention or firewalls). In serverless land, the use of single-purpose functions intentionally has many different architectural components (even if they are only the different functions themselves) interact with the underlying datastore. Therefore it is important for the underlying datastore to be distinct and managed separately.

Additionally, this passage has a rather important non-sequitur: if the problem with serverless is that it "[requires] a bottoms-up redesign of your system", then how exactly is Shuttle solving this problem when it puts the database into the magic box of things developers no longer need to worry about, rather than enabling developers to work with existing databases (because the entire paradigm is about starting from brown-field and not green-field)?

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.

Your code runs somewhere. On something. In something. At a physical place, with physical cords running around to physical boxes of stuff. There is a finite amount of space at this physical place, meaning there are actual real-world limits that your code operates within. There is no unlimited scaling. There is no unlimited bandwidth, unlimited memory, unlimited CPU, unlimited connections. Your code operates within limits. On a server. In a datacenter. Often these limits are comically smaller than you might assume.

Because of this unfortunate air-quotes Real World air-quotes that your code is forced to grapple with, if you want your code to not crash, you will have to actually consider the implications of where, on what, and how it is running. Now, I know you may not care about the running of your application. You might give zero shits about anything outside of your IDE. But the business paying your six-figure paycheck to write this code, does care. The user who uses your code, does cares. So on behalf of these groups, I implore you in the strongest terms, to please start giving a crap about the infrastructure, operating system, container orchestrator, monitoring, etc.

Now. Am I saying you need to become an AWS expert? A Linux kernel expert? A Kubernetes expert? A tape robot, network switch, SAN, lights-off-management, power-distribution-unit expert?

Heck. No.

There is a middle ground. A place where you don't need to be an expert on everything your code depends on. But you can know something about it. Just enough to have a remote idea that your application will actually support more than 10 users, and work somewhere outside your laptop. For example:

- How much CPU and memory does your application need per request, or per user? You should find out. And you should make sure that whatever "thing" is running your code has enough CPU and memory to serve the maximum number of requests, or number of users, you want using your code. (You don't know what maximum number of requests/users your application is supposed to support? You should find that out too.) You might also want to find out what happens when these limits are exceeded, and whether your application can "scale up" in that event. And then - what happens when your application can't scale up.

- What maximum number of database connections do you want to be able to make? If the answer is "unlimited", that's... not an answer. If the answer is "2000", well, then you better check that the database can actually handle that many connections, because often it can't. And you better also check how many connections your application will actually use per # requests/users/number of instances of your app running.

- Do you know when your application stops working? And when it does, who is going to fix it? How will they do it, and how quickly? These things are directly related to that whole annoying "people depending on your application to keep running" thing I mentioned before. It's not a question of "if" your app stops running, but "when". So you should figure out how to monitor your application, so that you 1) know when it's "down" (can a user use all its functionality as expected?), 2) know approximately how to "make it work again", and 3) write up instructions for whomever has to "make it work again". You might do well to brainstorm about what things outside of your app might cause the app to stop working (disks, cpu, memory, network).

There is no way to infer all these things from just code. You need performance testing, and you need to know what scale this is supposed to run at, and you need to architect a whole system to be able to meet those requirements. After all of that, if you hard-coded limits into your application, in theory some automated thingamabob could detect those and build some infrastructure whatsits to match. But within an already-existing architectural framework that matches your application and its expected uses.

But we aren't there yet. We still live in a world where, if your app is going to run reliably, you do have to know about more than just code. Sorry.

And these things are not mysteries known only to SpaceX scientists and certain occult members meeting in a lead-lined bunker underneath a kebab shop in Davos, Switzerland. You can learn most of this in a fairly short amount of time. I know you weren't taught it in school, and your company has never trained you on it, and probably pays somebody else to slowly pull this information out of you and wrap your code in a lot of other code to make it run reliably. But it doesn't have to be this way. You can be the kind of self-motivated professional that takes an active interest in the real-world outcomes of 1/3 of your life. You can make better applications, and provide better experiences, just by doing some due diligence. And if you need a hand figuring these things out, there's lots of people online that are happy to answer your questions.

This is older than author realizes. Google App Engine was doing this in 2008, 6 years before Lambda.