Thinking of Software Architecture Granularity
in my way…
For architectural design, the granularity of software is a perspective to think about. We have several options to select for our component sizes. It is not only limited to microservices vs monolith, right? We could use nano services, FaaS (serverless!?), or even further blockchains. But the first thing first, we should say
.. of your needs and situations.
After this self-relief sentence, I must confess that you should think about your software from many perspectives. Most of the time, granularity is just a little thing to worry about and pre-selected (prejudged?) in our environments. And even as we liberated our minds, could we freely think about all ‘pre-defined sizes’ by our communities? Okay, I know this is so much for now. Let's step back and jump into thinking of granularity.
When I try to design something new, I just try to define all processes and their dependencies (nothing technical). While defining, some of them become tuples and some of them become isolated from each other. With this progress, I draw some abstract boundaries in my mind and evaluate their validity. Brainstorm sessions and coffee talks are very welcome and helpful for deciding/rethinking some blurry points. Boundaries slowly become well-defined and I start naming those things (x layer, y platform, z services, etc.). Or you could simply think of I am simplifying my domain by using DDD.
I could separate responsibilities, handle dependencies, and think about communication interfaces with each other. These could be anything HTTP, MQTT, SMTP, etc. (and some letters contain T or P). At this point, my design problems are leveraged into boundary problems which is becomes simpler and sharper.
So far, probably so many questions should occur in your mind. I hope. But even though these steps are unclear and very abstract (and not applicable to every design), I think it has to be said by me and thought by you. My granularity questions generally start beyond these design processes.
Now on, it is time to think about the inside of the boundaries. How could we bundle our processes or separate them from each other? I need to detect business couplings and runtime behaviors. And yeah, we finally arrive at granularity ideas. (Sorry for the long journey)
And before giving some clues, let me clarify that I’m not trying to standardize your architectural thinking or giving some answers that fit any designs (not a silver bullet). On the contrary, I’ll give much more questions than answers. I think becoming a better software architect not only depends on the right answers you gave but mostly depends on your ‘right’ questions. So it’s time to ask more questions :-)
Centralized Management for Decentralized Process/Data
Could I decentralize my process or data?
Could I distribute my processes? Does it give any advantage?
Could I centralize my management more?
How could my process or data be smaller?
Is it meaningful?
I think these questions would always be in your mind while designing. When we think about granularity, we could separate our concerns about runtime behaviors and management needs. We should aim to centralize management while decentralizing our processes for increasing runtime performance as much as we need. Don’t forget that every decision from this perspective is a trade-off about runtime vs management. Defining the management and performance needs and limits is the key to better architecture.
And I know, these concerns are mostly suppressed by our business needs/tight schedules, etc. But in the end, thinking about edges could be an innovative point for us. Serverless, blockchain, and IoT are some outcomes of this perspective. How about think of beyond these granularities? I wonder what could it be next….
