Micro Service Musings: Moving Architecture Forward
As I've begun to see project transition from single solution monoliths to smaller components such as micro services and service oriented architecture, one of the things I've noticed is that I've been worrying less and less about what the code may look like, and seeing the the bigger issue becomes how does the service integrate with the rest of the environment.
Code quality will always be the pillar of software development, but what I mean is that much of the complexities of writing code has been moved away from within the service, and now is being described between how our subsystems related and interact with each other. Systems look a lot more streamlined and cleaner because they only contain code relevant to a particular portion of the project. As services become distributed across the environment, then we start to incorporate more advanced platform architecture such as event-sourcing, sagas, orchestrators that allow each of our systems to talk to each other and perform business actions that use to be done at the code level.
We as developers need to recognize that our job is bigger than just writing good code, it's about writing good systems. What we code in a single system may have huge external implications, such as the dependencies it creates, the processes it may be linked to, and how maintainable it will be in the future.
While this is by no means any new revelation in the industry, software architecture design principles have been here longer than I've been around, what I think is worth noting is that we are starting to delegate that responsibility down from experienced architect leaders down to more sophomore roles. These sophomore developers are being exposed to a lot more "architecture" decisions, while their seniors are working on the big vision of the larger team. This is important to understand because as we give more architecture responsibility to devs earlier in their career, we also have to give mentorship and guidance for them to be able to make those educated decisions, because they don't have that experience before.
Code quality will always be the pillar of software development, but what I mean is that much of the complexities of writing code has been moved away from within the service, and now is being described between how our subsystems related and interact with each other. Systems look a lot more streamlined and cleaner because they only contain code relevant to a particular portion of the project. As services become distributed across the environment, then we start to incorporate more advanced platform architecture such as event-sourcing, sagas, orchestrators that allow each of our systems to talk to each other and perform business actions that use to be done at the code level.
We as developers need to recognize that our job is bigger than just writing good code, it's about writing good systems. What we code in a single system may have huge external implications, such as the dependencies it creates, the processes it may be linked to, and how maintainable it will be in the future.
While this is by no means any new revelation in the industry, software architecture design principles have been here longer than I've been around, what I think is worth noting is that we are starting to delegate that responsibility down from experienced architect leaders down to more sophomore roles. These sophomore developers are being exposed to a lot more "architecture" decisions, while their seniors are working on the big vision of the larger team. This is important to understand because as we give more architecture responsibility to devs earlier in their career, we also have to give mentorship and guidance for them to be able to make those educated decisions, because they don't have that experience before.
:D
ReplyDelete