TQ
dev.com
Blog about software development
06 Jun 2016 - by 'Maurits van der Schee'
Microservices are highly popular and require that every service manages it's own data. This does not necessarily mean that each service has it's own database server. It can also only manage it's data in one big central database system. As long as nobody else, but the service, interacts with that data it is still in line with the ideas of microservices.
Having one database server brings several advantages. For one, it does not require you to change your data structure if you come from a monolithic application. Second it also brings as an advantage that you can still have constraints to ensure consistency. As a third advantage I see that it also enables you to do simple backups and data analysis. You can let all these services have their own tables, their own scheme or even their own database, because unlike popular believe cross database queries are not that inefficient.
When you have multiple legacy systems that you need to combine into one piece of software it makes perfect sense to allow each of these systems to have their own database server. You may be using systems from different vendors, but by integrating into standard interfaces that may not be a problem at all. One approach is to use a API gateway and use REST APIs as interfaces. Another approach is to connect all services to a message bus or queuing system such as RabbitMQ or even Redis.
The problem is that when you have several systems that it is hard to ensure consistency. One pragmatic way to solve this is to make "check queries" that you run scheduled and will report database inconsistencies when they appear. This is less strict than a constraint, but still allows you to act on inconsistent data and track down it's source. The problem can easily be seen when a user changes some of its account details or permission for the user are increased or revoked. In those cases micros services may have trouble updating each other, synchronizing these globally important properties. Also different caching timeouts on the same values may lead to inconsistency, even when the shared data is replicated without problems. You may also encounter a problem called "referential integrity" also known as "dangling references", when references to records of other systems exist, but these records in the other system no longer exist.
If you are building a web application you can use the session storage as a shared state and let all services be completely stateless. This way it is very well possible to effectively build an application as you don't have to retrieve all related (shared) data on every request to the services. Let's say that you have one database and there are several tables related to user management. You can have a micro service that focuses on user management and another micro service that focuses on management of customer resources. Both may need access to data provided by the authentication and authorization service, adding effective user object and it's roles to the session data.
When building microservices you benefit from the fact that when software developers are working together one plus one does not equal two. This is because the collaboration requires a lot of ceremony. Suddenly coding standards are needed, git work-flow agreements, code reviews, architectural meetings, decisions about technology choice, post-mortem investigations, hand-overs, extensive functional and technical documentation, data dictionaries, risk assessment sessions, bug triage, planning sessions, retrospectives and I'm sure I still forgot many of the overhead activities that a software team has. All this overhead is not necessary when you hire a good full-stack developer, give that person a quiet room, possible one or more assistants and enjoy the 10x benefit. Microservices may help you to scale this approach.
It is quite an unpopular opinion when you want to cut an application into small pieces allowing everybody to write it's own part. Management is afraid of the dependency of individuals (often called the "bus" factor) and developers are afraid that they have to work on a small and thus boring part of the system. In reality you see in large teams also very high dependency on certain people, despite all the expensive effort to avoid that. And when good people leave you have an excellent chance for a next developer to refactor that module to improve the sense of ownership and encourage "gardening" along the way, thus keeping the code in good shape. The fear of boredom for programmers can be mitigated by replacing it with ownership and focus on quality. By letting the senior developers set-up the new services and letting the juniors take over the responsibility for existing services you can allow programmers to move towards new services after a few years (or faster, depending on the growth of your company).
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe