6 ms·

Same. I've never worked in infrastructure teams because I simply don't care about this stuff, and I always find it funny how the infrastructure details tend to

by lpapez 3y ago

Same. I've never worked in infrastructure teams because I simply don't care about this stuff, and I always find it funny how the infrastructure details tend to leak out to us application developers. Come on, I just want to deploy my app somewhere. I don't want to know about yamls and kubernetes, I just want a button where I deploy my branch. It often feels like people working on infrastructure and platform development do it for it's own sake, forgetting that they were supposed to be enablers for other teams building on top of it.

root_axis 3y ago
You say you don't want to understand infrastructure and just want a button that magically deploys your app, yet in the same breath you complain that devops folks are "working on infrastructure and platform development for it's own sake". These are contradictory sentiments. "Leaking" infrastructure details to developers is actually less work for them because they are deferring the finer details of the app deployment to the developers who made it. Your request for a magic button that doesn't require you to understand anything about infrastructure is exactly why we have so much complexity.
- jackpeterfletch 3y ago
  I agree that you never escape the requirement to have knowledge of how your application is deployed. Things like autoscaling, security, performance etc, all intrinsically effect how you actually write your application. I think there's a broader point though, in that very often, infra teams will pursue solutions that solve problems in the perspective of their own lens and interests without good oversight from the broader organisation, for developer experience, and economies of scale. I've seen and worked in environments at both ends of that scale and the gap in dev-ex, and agility as a result can be absolutely staggering. So often its to avoid 'vendor lock-in', only for infra teams to become the 'vendor', its complex, so they grow by necessity to be expensive, but then still lack the resources to be able provide a clean experience that can be easily migrated off of, resulting in lock-in. As a dev, the cost isn't my concern, but whats frustrating is knowing that its possible to deploy a new service, with all the bells and whistles, in an hour, and being unable to.
- osigurdson 3y ago
  Those pesky details like cache line misses and inter node latencies should just go away. I am far too important to know about such realities. Why should I care about cores or processor architecture, I should just be able to write my code and something should figure out the details. If you agree with the above statement, please go into management.
- baq 3y ago
  The problem in complex, large infrastructures is I know exactly what I need to do and have no idea how to even get started. There are no obvious entry points, there are layers upon layers of abstractions to make developing IaC easy for those who maintain it but they reduce comprehensibility to almost zero. My most recent example: deploy a lambda function. Building the image: 1 day. Deploying it to prod: 2 weeks.
dig1 3y ago
I'm not in devops-land, but I pretty much hear the same from devops guys: "Instead of running pip/poetry/npm/yarn/whatever-is-popular-this-month, wait for it to download gigs of dependencies, setup nginx in a specific way, start 10 services for a web shop, use exact python or node version and pray to infra gods that everything holds the water, why can't we copy a single jar/binary, start it and forget about it" ;) I'm getting the impression that the whole industry shifted focus from solving actual problems in the most simple way to draining money and keeping things afloat as much as possible.
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.
jakupovic 3y ago
Wow, this is pretty hard to read and understand someone who has this mindset. Best developers understand the platform that their apps run on and the infrastructure needed for it. There is no artificial separation between platform and apps. You cannot run your beautiful app without infrastructure needed. This is coming from someone who has done both and still does. Many times over, in new teams especially, you must create the infrastructure and then apps. Guess what if you can't you don't move forward. I think you want to write some code and then throw it over a wall and make it someone else's responsibility. Not very useful ;(. How about testing is that for someone else to do? You must be new to this game.
osigurdson 3y ago
This type of prima donna attitude ultimately negatively impacts customer experience. If your code is really that amazing and such gospel can only come from your hands, consider hiring a real software engineer to do the grunt work of making it work robustly, securely and in a performant manner on the substrate to which it is deployed.
throwaway894345 3y ago
Honestly I’ve never worked anywhere that made deployment easier for application teams than with Kubernetes. The alternative to infrastructure details leaking everywhere has historically been a tedious coordination process with an Ops team whose incentive is to say “no” as often as possible. The deployment frequency drops precipitously and consequently the size of changes goes up significantly so when something inevitably breaks you have to sift through tons of changes to find the culprit and you have to coordinate even more to fix the release. And since this one ops team is supporting every team at the company, “coordination” hurts. I’m sure it doesn’t have to be that way—that there are some all-star ops teams who can make a more traditional VM-based infrastructure run as smooth as the median SRE team can build out a Kubernetes platform, but I’ve never seen it. It’s also worth noting that sometimes the details leak because app teams want them to leak—they want to build some feature that requires some particular infrastructure solution (e.g., we want our app to run some background task in response to requests, and we don’t want to do it in the VM lest the autoscaler—which is background-task-agnostic—kill it while the background task is running).
Bayart 3y ago
I don't agree that what we're doing stops at enabling other teams to build. That's part of the role but reducing it to that siloes infrastructure away from other domains and adds unnecessary friction. You shouldn't have to know about the yamls and the k8s, but you should know about infrastructure concerns and how they relate to you and your design choices, just as infra guys should be aware of what's going on on the front side. Having to work with close-minded counterparts who refuse to elaborate further than "make it work now, or else" is about the worse thing there is. Being willing to participate in good faith in back and forth discussions around those subjects is important and pays dividends.

by lpapez 3y ago

root_axis 3y ago

You say you don't want to understand infrastructure and just want a button that magically deploys your app, yet in the same breath you complain that devops folks are "working on infrastructure and platform development for it's own sake". These are contradictory sentiments. "Leaking" infrastructure details to developers is actually less work for them because they are deferring the finer details of the app deployment to the developers who made it. Your request for a magic button that doesn't require you to understand anything about infrastructure is exactly why we have so much complexity.

jackpeterfletch 3y ago
I agree that you never escape the requirement to have knowledge of how your application is deployed. Things like autoscaling, security, performance etc, all intrinsically effect how you actually write your application. I think there's a broader point though, in that very often, infra teams will pursue solutions that solve problems in the perspective of their own lens and interests without good oversight from the broader organisation, for developer experience, and economies of scale. I've seen and worked in environments at both ends of that scale and the gap in dev-ex, and agility as a result can be absolutely staggering. So often its to avoid 'vendor lock-in', only for infra teams to become the 'vendor', its complex, so they grow by necessity to be expensive, but then still lack the resources to be able provide a clean experience that can be easily migrated off of, resulting in lock-in. As a dev, the cost isn't my concern, but whats frustrating is knowing that its possible to deploy a new service, with all the bells and whistles, in an hour, and being unable to.
osigurdson 3y ago
Those pesky details like cache line misses and inter node latencies should just go away. I am far too important to know about such realities. Why should I care about cores or processor architecture, I should just be able to write my code and something should figure out the details. If you agree with the above statement, please go into management.
baq 3y ago
The problem in complex, large infrastructures is I know exactly what I need to do and have no idea how to even get started. There are no obvious entry points, there are layers upon layers of abstractions to make developing IaC easy for those who maintain it but they reduce comprehensibility to almost zero. My most recent example: deploy a lambda function. Building the image: 1 day. Deploying it to prod: 2 weeks.

dig1 3y ago

I'm not in devops-land, but I pretty much hear the same from devops guys: "Instead of running pip/poetry/npm/yarn/whatever-is-popular-this-month, wait for it to download gigs of dependencies, setup nginx in a specific way, start 10 services for a web shop, use exact python or node version and pray to infra gods that everything holds the water, why can't we copy a single jar/binary, start it and forget about it" ;) I'm getting the impression that the whole industry shifted focus from solving actual problems in the most simple way to draining money and keeping things afloat as much as possible.

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.

jakupovic 3y ago

Wow, this is pretty hard to read and understand someone who has this mindset. Best developers understand the platform that their apps run on and the infrastructure needed for it. There is no artificial separation between platform and apps. You cannot run your beautiful app without infrastructure needed. This is coming from someone who has done both and still does. Many times over, in new teams especially, you must create the infrastructure and then apps. Guess what if you can't you don't move forward. I think you want to write some code and then throw it over a wall and make it someone else's responsibility. Not very useful ;(. How about testing is that for someone else to do? You must be new to this game.

osigurdson 3y ago

This type of prima donna attitude ultimately negatively impacts customer experience. If your code is really that amazing and such gospel can only come from your hands, consider hiring a real software engineer to do the grunt work of making it work robustly, securely and in a performant manner on the substrate to which it is deployed.

throwaway894345 3y ago

Honestly I’ve never worked anywhere that made deployment easier for application teams than with Kubernetes. The alternative to infrastructure details leaking everywhere has historically been a tedious coordination process with an Ops team whose incentive is to say “no” as often as possible. The deployment frequency drops precipitously and consequently the size of changes goes up significantly so when something inevitably breaks you have to sift through tons of changes to find the culprit and you have to coordinate even more to fix the release. And since this one ops team is supporting every team at the company, “coordination” hurts. I’m sure it doesn’t have to be that way—that there are some all-star ops teams who can make a more traditional VM-based infrastructure run as smooth as the median SRE team can build out a Kubernetes platform, but I’ve never seen it. It’s also worth noting that sometimes the details leak because app teams want them to leak—they want to build some feature that requires some particular infrastructure solution (e.g., we want our app to run some background task in response to requests, and we don’t want to do it in the VM lest the autoscaler—which is background-task-agnostic—kill it while the background task is running).

Bayart 3y ago

I don't agree that what we're doing stops at enabling other teams to build. That's part of the role but reducing it to that siloes infrastructure away from other domains and adds unnecessary friction. You shouldn't have to know about the yamls and the k8s, but you should know about infrastructure concerns and how they relate to you and your design choices, just as infra guys should be aware of what's going on on the front side. Having to work with close-minded counterparts who refuse to elaborate further than "make it work now, or else" is about the worse thing there is. Being willing to participate in good faith in back and forth discussions around those subjects is important and pays dividends.