In a post titled You are not Google Oz Nova points out that many decisions about software architecture are made without really addressing the scale and context of the system under design related to the scale and context of the organization that developed the technology. One of the examples in the post is that of DyanmoDB which was originally designed to support write availability at scale so that Amazon did not lose any “put in basket” actions. In service of the write availability, DynamoDB loses many of the attributes of relational databases that are useful, consistency, referential integrity and easy joins, but few teams that adopt DynamoDB as part of their architecture really need what DynamoDB is optimized for.
In the service of thinking about technology choices, Oz introduces an acronym UNPHAT
- Understand the problem – then you can produce a solution within the problem space
- eNumerate the candidates – choose at least three so that you are not doing a simple binary choice
- Find a Paper to read about each candidate – get beyond the marketing and conference presentation
- Investigate the Historical context – what was it designed to optimize and what could it ignore
- What Advantages does the technology have and what are the disadvantages – nothing is ever all positives
- Think about how well the technology fits your problem space – does it work for your context and scale?
In the wake of this, how many problem spaces really need the complexity of Microservices?