Yesterday, I spoke about the value of making architectural decisions to aid agility. Agility requires high deployment frequency (deployments to production per day), and low lead time (time between commit to production deploy).
Today, I want to highlight some technical choices that we can make to streamline the maintainability of systems. To build agility into the architecture. To pick technology that will reduce friction later on.
Some NoSQL databases are useful in circumstances where the data needed to be housed is unstructured or semi-structured. Many NoSQL databases like key-value, and document databases don’t require formal schema changes because there is no schema to change. Speaking from experience, there’s a lot of agility to be gained when developers don’t have to worry about schema changes, constraints, column sizes, etc.
In Azure, this could mean choosing to use a lighter, simpler, cheaper database like Azure Table Storage over the most common choice of Azure SQL. Likewise, if there is a demand for it, Cosmos DB could fulfill a need.
With the advent of services like Event Grid, it’s ever more simple to create event-driven architectures. When components of an architecture react or are “triggered” based on an event, it’s easy to replace the component in the future. It’s also much easier to extend the architecture unobtrusively since there will be natural extensibility “hooks” for developers to leverage. It’s also less likely that the system will grow to be a “big ball of mud” or the infamous monolith in the future, although results may vary.
For example, if there is an event that is published when a new user registers, then it’s easy for developers to create components that listen for that event and send a welcome email. If at some point in the future, there was a need to also send a text-message, it would be a simple addition of a new component that also listens to the same event.
Here’s a comprehensive comparison of the various messaging services on Azure.