It's just been a convenient way to divide up the work? When FE & BE don't work together and aren't aware of each other it's just another mess. And then people invented Backend For Frontend to deal with it or GraphQL. We're just adding more layers and abstractions and complexities on top.
It's valuable to have someone to be dedicated to infrastructure. It's even more valuable for everyone to be aware of the whole ecosystem. No 1 lives in a silo.
In an ideal world, it would be great for everyone to be aware, but people have limited time and the systems naturally grow large enough that you would have to spend all of your time just keeping up with the changes.
This is where we have architects, microservices and layers of complexity and abstraction.
> and the systems naturally grow large enough that you would have to spend all of your time just keeping up with the changes.
I've seen more cases where it doesn't actually need to be that large - just like you don't need infinite scaling or 1000 microservices and microfrontends. Instead of accepting that it has to grow - think about how it can work together more efficiently. In a lot of situations there's been more downtime due to redundancy, DR and other setups than having a simple instance.
Everyone architects their own part and a build tool / process for each of it... when does it end?
I see these "systems" that mention more as a mess and most people spend 80% of their time to workaround it or just procrastinate at how fragile it is.
The truth is that infrastructure is not that complex when you have someone giving you building blocks and setting up guardrails. Having someone give you the pipelines and setting the boundaries is great. Choosing the pieces to get the product over the line is not that hard in a world where cloud is the norm.
Possible at FAANG[1] but gets a lot harder as companies get smaller and/or the devs teams are not setup to do that.
[1] I assume the SREs are not the only ones doing the Infra code
We know that we are constantly pulled in many directions in our industry, and often we take shortcuts to get the work out the door. Infra is not a place you typically want to take shortcuts. Burdening devs with the infra | ops responsibilities is a sure way to security incidents and inflated costs.
It does provide a good market for consultants|contractors to come in and clean up afterwards.
If we look at this job separation in a different analogy, why do we typically separate FE & BE development? b/c people can only be expected to be proficient in so much of the stack? And you typically want someone around who is proficient for each part of the stack?