We are nearing the end game now! It’s time for the penultimate blog in the series, it’s been a great ride and I am honoured to have shared this with all my readers.
So without further ado, let’s get started!
Logging and Monitoring
In software engineering, a lot of things can go wrong and let me assure you, things will go wrong!
The real question is what will happen when things go wrong?
Logging and monitoring is the cornerstone of maintainable systems. A good system has always good logging and monitoring engines.
In addition, monitoring will allow us to view the current status of the system and notice problematic trends such as high memory consumption or above-average exceptions.
One of the most important architecture pattern here is a Central Logging Service.
Let us say that in a system with three services, each service creates its own logging service engine.
Now we clearly see the problem here!
Every service has its own log format, its own log data and its own log location. While individually this may be correct, now the developers will have to pull the logs from multiple sources to learn about the system.
With central logging, we change this approach and create a central logging service which will use a central repository preferably a database to improve querying.
To implement a central logging service, we must have an exposed api and watch folders with logs present in a single format.
The second important type of logging architecture model is Correlation ID.
When our system has many services, we will have a lot of business flows that include more than one service.
One of the challenges in such a flow is to be able to understand which log record belongs to which flow.
For example, say user one asks for a recommendation.
The recommendation service calls the stock service for data and then an error occurs in the stock service.
Both services implement logging.
So we have good documentation of what exactly happened in this case.
We have a log for the StockQuotes in case it fails. So far there is no issue. But what happens when a user in parallel initiates a request?
When we try to get the logs now, we have two sets of logs, one which contains an error and the other which is free from any error.
The way to identify our set of logs now is through correlation ID.
Correlation Id is an identifier that is assigned to a flow at the beginning of it and is passed from service to service. It is included in every log record and enables us to track the flow from start to end.
External Considerations
In previous topics we learnt about professional considerations, scalability, redundancy, etc. As an architect however we have to think about some external considerations as well.
These considerations have nothing to do with best practices, architecture or software. They don’t affect technology stack and architecture patterns. Yet these become extremely important in the larger scope of things that a software architect has to consider.
Deadlines
Deadlines are a major factor in deciding how a project and its architecture are carried forward.
As a software architect, we must be aware of the impact of deadlines on a project’s schedule.
Developers’ Skillset
Selecting unknown technologies can result in unnecessary delays and low quality code.
Thus it is important to know our team’s capabilities and the best suited technologies accordingly for them.
IT Support
In a business flow there are numerous things that need constant support for maintenance such as queue engines, business flow managers, NoSQL databases and more.
At times developers take on this business need and get good at the maintenance aspect of these flows. But this is wrong! Developers should only develop! That is why we need a proper IT support team.
Cost
No discussion is complete in any business flow without deciding on cost.
Quite often we see amazing tools that are freely available for commercial use, such as the Apache Foundation tools.
However, this can make us forget there are still products out there that cost a lot of money and discussion must be considered when designing our architecture.
The rule of thumb is that always use an existing tool instead of developing it.
So that is it for part 8! In the final part 9 we end this amazing journey with the final task that every Software Architect must take, crafting the holy bible of Software architecture, The Software Architecture Document!
I am so happy to finally end this year-long endeavour and I am excited to take the CodeWolf blog in a new amazing direction now!
So what happens next? Who knows, stick around to find more!
Discover more in the next blog!!
I keep on coding something cool, visit ankush.tech to see what I am doing!
If you wish to read about my work, here is a book that I published recently – “Knowing Software Architects “
Get Started with CSS today: “CSS Bullets, a comprehensive guide to all the CSS you need!“
Interested in React? Learn react from scratch with my book, “REACT Bullets“.
Not subscribed to the newsletter? Subscribe now!!!
Thanks for sticking around!
Leave a Reply