Software architect | Microsoft MVP | Author of Ode To Software Architecture book | Founder of Evolutionary Architecture by Example Repository
I don't know if this is only my observation or if someone else feels the same. One of the biggest problems with infrastructure is that it is too often isolated from the development teams. Companies often extract a separate team responsible for the infrastructure at some point. As this team grows, it is then split into multiple others. These teams handle topics like identity access management, orchestrators, API gateways, or build pipelines. This, in turn, leads developers to worry less and less about infrastructure. It is not uncommon for software architects to treat infrastructure-related topics as a second category. There are DevOps; we can put it on their shoulders. This is an anti-pattern. There are so many things that can go wrong: - Database, storage, and cache - API gateway and load balancers - IAM - Orchestrators, message brokers - Security of infrastructural components And many more. At some point, I decided to start collecting topics related to architecture that are most important from the software architect's perspective. The result? I will give a talk about it at the Devoxx conference in June :) Feel free to check the details here: https://lnkd.in/dmXia-Qp Who do I see there? :) #softwarearchitecture #devops #softwaredevelopment
Shammy Narayanan
2mo
You are spot on, Maciej. Most often, Solutions are viewed primarily as Coding and Testing (CUT), but they are much more than that, and Infrastructure (IAM, Observability, Storage tiers, Compute types, Promotional pipelines, Audit trails, Data logs, etc.) are all too closely knitted. I hope common sense prevails!!
HW/SW Co-design, RISC-V, full-stack AI from bare silicon to computational consciousness.
2moMaciej Jedrzejewski> Companies often extract a separate team responsible for the infrastructure at some point. Let me explain it. It's "divide and conquer". Very similar pattern to the popular disaggregation (of memory, compute and IO), that helps keeping costs manageable and optimize resource sharing. Another side of such control is that some system architects, who are good at "soft skills", prevent this way in-house competition for them, because, as you have noticed, noone has a clear mental model of the system. Un-involvement of developers into the infrastructure is just a behavioral sign of it.