5 ms·

I work on an infrastructure team, and I always find it funny how app developers think it's possible to abstract everything away. All abstractions leak! your cod

by lantry 3y ago

I work on an infrastructure team, and I always find it funny how app developers think it's possible to abstract everything away. All abstractions leak! your code will reach a physical machine at some point in the process. We platform people do our best to abstract things for you, but we can't magically bypass the law of leaky abstractions (https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...)

Traubenfuchs 3y ago
In a good infrastructure setup, any average dev should be able to get a new hello world crud service deployed to a test environment with the db and aws service backing of his choice and have it reachable by other services within an hour, without ANY additional config. Take the subdomain name from the repo name and be done with it! If that is not possible, you have failed your job as masters of the infrastructure. At my company, for this I need to copy-paste some terraform in repo 1, write some scaling config in repo 2 and put in new, encrypted credentials and other configs in repo 3, then finally I can deploy my docker app from repo 4. I can all do it myself in two hours but it constitutes total failure on the infrastructure teams side.
- flumpcakes 3y ago
  While you're writing your 'hello world' app, the infrastructure you deploy to has to support every single permutation of everything every developer in the company writes, multi-tenanted, multi-environmental, multi-region, highly-available, backed-up, in-flight and at-rest encryption, permissioned appropriately, ISO27001 compliant, and that's not even getting to observability and metrics. Infrastructure people tend to have a much harder job, especially with ignorant developers who just want a one-button deploy. Too many developers only care about 1/3 of the SDLC.
- noitpmeder 3y ago
  The fact that you ended with "I can do it all myself in two hours" indicates to me you're horribly ignorant of all the complexity you want to hand wave away.
forinti 3y ago
I grew up in the 1980s, when you had to know your platform well to get nice software written. I find it annoying that there are a lot of young (and not-so-young) developers who don't take the time to properly understand where their apps are running in order to make the best of it and also not to write crappy and slow software. I see people climb mountains in Java when they had all they needed in the database or in the OS.
- throwaway894345 3y ago
  I also suspect people balk at infrastructure because it means learning a new and complicated thing to solve their problem, but the shape of the solution is the same whether they build it in their application as a library or whether they avail themselves of off-the-shelf infrastructure offerings (although there are some problems that can only be solved by infrastructure). Either way, you have to understand the solution at a high level, and I think much of the balking at infrastructure is really just balking at needing to understand the fundamental nature of their own problem.
stavros 3y ago
I'm an application developer, and I'm also an infra guy, because you can't get away from the fact that your code will run on a machine, and you need to know what happens. I don't have much respect for application developers who "don't want to know anything about infra", sadly.
- silverquiet 3y ago
  I found it refreshing when a developer said to me point blank, "I don't care where this runs". She didn't say that she didn't care that it runs, but she was being upfront that she had other concerns more relevant to her, so she left the operations work for my team, but crucially, she followed our advice/requests on how to build things to work with our infra. Not everyone can do everything; it's why there are specialties, but it means that collaboration is vital.
  - stavros 3y ago
    I don't care where my stuff runs either, but, when it breaks, I care that I have a good enough mental model of what's going on that I can debug it. Whenever I see web developers not knowing how an HTTP server works, a part of me dies a little.
    - silverquiet 3y ago
      I remember learning about keyboard matrix encoders because I got into building MAME arcade projects when it was still a fairly young idea and consumer products that integrate arcade controls with computers were not commonly available. When you learn about them, you'll understand why older and/or cheaper keyboards have artifacts known as blocking and ghosting. It's something that I at least found interesting, but I doubt most people can be bothered to care. And as far as how that keyboard encoder is creating the ones and zeroes and then sending them over the USB bus - that might as well be magic to me. I suppose we all live at the abstraction level that suits us. I'm of the opinion that a lot of the modern infrastructure we work with is over-abstracted. I'm not sure that most developers even know that an HTTP server exists thanks to the work of modern devops where you push a commit and it gets automatically deployed to some sort of container orchestration system. At some level it has to be this way; we stand on the work that was done before us; "the shoulders of giants" it's often said with more poetic flair. So I wonder if it's just me getting older and not understanding the new, or if we have genuinely gone astray in some ways. And those need to be mutually exclusive either.

by lantry 3y ago

Traubenfuchs 3y ago

In a good infrastructure setup, any average dev should be able to get a new hello world crud service deployed to a test environment with the db and aws service backing of his choice and have it reachable by other services within an hour, without ANY additional config. Take the subdomain name from the repo name and be done with it! If that is not possible, you have failed your job as masters of the infrastructure. At my company, for this I need to copy-paste some terraform in repo 1, write some scaling config in repo 2 and put in new, encrypted credentials and other configs in repo 3, then finally I can deploy my docker app from repo 4. I can all do it myself in two hours but it constitutes total failure on the infrastructure teams side.

flumpcakes 3y ago
While you're writing your 'hello world' app, the infrastructure you deploy to has to support every single permutation of everything every developer in the company writes, multi-tenanted, multi-environmental, multi-region, highly-available, backed-up, in-flight and at-rest encryption, permissioned appropriately, ISO27001 compliant, and that's not even getting to observability and metrics. Infrastructure people tend to have a much harder job, especially with ignorant developers who just want a one-button deploy. Too many developers only care about 1/3 of the SDLC.
noitpmeder 3y ago
The fact that you ended with "I can do it all myself in two hours" indicates to me you're horribly ignorant of all the complexity you want to hand wave away.

forinti 3y ago

I grew up in the 1980s, when you had to know your platform well to get nice software written. I find it annoying that there are a lot of young (and not-so-young) developers who don't take the time to properly understand where their apps are running in order to make the best of it and also not to write crappy and slow software. I see people climb mountains in Java when they had all they needed in the database or in the OS.

throwaway894345 3y ago
I also suspect people balk at infrastructure because it means learning a new and complicated thing to solve their problem, but the shape of the solution is the same whether they build it in their application as a library or whether they avail themselves of off-the-shelf infrastructure offerings (although there are some problems that can only be solved by infrastructure). Either way, you have to understand the solution at a high level, and I think much of the balking at infrastructure is really just balking at needing to understand the fundamental nature of their own problem.

stavros 3y ago

I'm an application developer, and I'm also an infra guy, because you can't get away from the fact that your code will run on a machine, and you need to know what happens. I don't have much respect for application developers who "don't want to know anything about infra", sadly.

silverquiet 3y ago
I found it refreshing when a developer said to me point blank, "I don't care where this runs". She didn't say that she didn't care that it runs, but she was being upfront that she had other concerns more relevant to her, so she left the operations work for my team, but crucially, she followed our advice/requests on how to build things to work with our infra. Not everyone can do everything; it's why there are specialties, but it means that collaboration is vital.
- stavros 3y ago
  I don't care where my stuff runs either, but, when it breaks, I care that I have a good enough mental model of what's going on that I can debug it. Whenever I see web developers not knowing how an HTTP server works, a part of me dies a little.
  - silverquiet 3y ago
    I remember learning about keyboard matrix encoders because I got into building MAME arcade projects when it was still a fairly young idea and consumer products that integrate arcade controls with computers were not commonly available. When you learn about them, you'll understand why older and/or cheaper keyboards have artifacts known as blocking and ghosting. It's something that I at least found interesting, but I doubt most people can be bothered to care. And as far as how that keyboard encoder is creating the ones and zeroes and then sending them over the USB bus - that might as well be magic to me. I suppose we all live at the abstraction level that suits us. I'm of the opinion that a lot of the modern infrastructure we work with is over-abstracted. I'm not sure that most developers even know that an HTTP server exists thanks to the work of modern devops where you push a commit and it gets automatically deployed to some sort of container orchestration system. At some level it has to be this way; we stand on the work that was done before us; "the shoulders of giants" it's often said with more poetic flair. So I wonder if it's just me getting older and not understanding the new, or if we have genuinely gone astray in some ways. And those need to be mutually exclusive either.