> the code that developers write implicitly defines infrastructure. What your code actually needs in terms of infrastructure should be inferred as you build you

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