I ran across a post on microservices recently and was intrigued. I always like the idea of loosely coupled, independent items in software. However the idea of microservices causes issues with databases. Here’s the section in the piece by Netflix: Create a separate data store for each microservice.
I tend to think of microservices is very small, tightly bound components of software. If that’s the case, how can I separate each item in a database? Do I want dozens of databases?
I got in an argument with a developer a few months ago about this. The developer was sure that having separate databases (or stores) for each component wasn’t an issue. For things like banking and similar transfers, I’m not sure a microservice can be separated safely and still ensure integrity.
This is a tough concept for architecture, and I need to read more and understand how this could work in practice. I suspect that in places where things could be separate, you could easily use schemas in a database to separate out microservices from each other. If each service includes its own connection information, then using schemas would work and still allow for scale out to other databases if needed.
This is an area that certainly fits larger scale applications like Netflix and Spotify, but for many of us, our applications seem to be more tightly tied together.
Or are they?
Microservices are much like Service-Oriented Architecture (SOA), which I think fits many applications. I’m not sure how similar the concepts are, but this is certainly an area I’d like to learn more about.
Voice of the DBA 
I think it’s just a different way of thinking. In the Linux/Java world the thought is that everything is loosely coupled, but by default we’ll give you everything you need installed unless you tell us otherwise. Example…hortonworks hadoop. On your first node you’ll get postgres installed by default for configuration management. That means you have another postgres database lying around that you have to back up and patch. But you can always pass the installer a param to use another instance on another host in a different schema. Drupal works this way too. They even give acronyms to these self-contained “packages” like LAMP (for linux, apache, mysql, and php on a single host). This is even more prevalent with “container technology” like Docker which allow you to package every app you need to run some bigger app in one convenient package that you can start up without worrying about installing all of the dependencies.
The loose coupling at the data tier means that each microservice can have its own data store because there is really no need for sharing because it is simple persistence…no reports or queries or applications that integrate at the data tier. Obviously the data tier of a banking application could never work this way…but the services could.
This seems to be more of a foreign concept in “microsoft shops”. Generally there you install something like IIS on one machine, SQL Server on another, etc. Rarely do things come packaged together. Once you start to use aptitude or yum on Linux and you see the power of this technique you start to think in terms of packaging your apps more using the microservices techniques. At least I have.
LikeLike
You might be right, Dave. Certainly the idea of separation in the same machine isn’t something we consider well in Windows/MS stack.
I do like the idea of microservices and I’d think with a little thought, they are useful in many places.
LikeLike
Pingback: Why Test Table MetaData Tests with tSQLt | Voice of the DBA