One way to see it is that the database is a microservice that manages data for all the other microservices and its API is (for example) SQL. After that it should be clear why any of the other microservices should not have the privilege to include the tools to define the data.
Unfortunately Rails or Django or any other framework's migrations are so much more convenient compared to maintaining a schema manually. Any database centric migration tool would have to update the models for all the projects using it. That's not easy AFAIK.
I'm working at a project in which different teams are writing services in Elixir (Phoenix) and C# (no idea what's in there.) We're using different databases and an HTTP API, so the databases and their schemas are hidden inside every (not so micro) service. We didn't share the database because it would have been a nightmare to mirror changes in both codebases.
> One way to see it is that the database is a microservice that manages data for all the other microservices and its API is (for example) SQL.
That's a good point, especially since, in the common (or at least initial) situation, that's how it's approached.
However, I'm wary of taking the concept to an extreme [1] in that many modern RDBMSes are very much not "micro". Besides the storage optimizations that the article mentions, modern RDBMSses are capable embedding programmatic business logic (e.g. stored procedures, triggers), but there seems to be a categorical avoidance of using these features by most devs, even if it means moving huge quantities of data to a different microservice (presumably across a network) to perform the processing.
> Unfortunately Rails or Django or any other framework's migrations are so much more convenient compared to maintaining a schema manually.
The article addresses this by recommending code generation, which is, essentially, the converse of SQL-generation. Is either one more manual than the other?
Perhaps the generated SQL seems less manual, because the database, in that situation, isn't a first-class citizen, as it were. A dropped table is, essentially, invisible to the developer. That is, I believe, the author's point, though.. the appearance of convenience is at the expense of actively ignoring pitfalls.
> Any database centric migration tool would have to update the models for all the projects using it. That's not easy AFAIK.
I'm not sure I follow.. Are you describing one database with multiple "client" applications? If so, it's not clear how an app-centric model would be any easier, with multiple apps all wanting to perform duplicate migrations (or.. duplicated/conflicting rollbacks?).
[1] Granted, this could be a critique of the "microservice" model in general
Client applications should not migrate the database. That's up to the database, with any tool for for the purpose. I'm ignorant in this matter.
Then there is code generation to keep the models up to date. The generation tool should know all the ORMs or whatever used by the clients and modify their models. Saying that this is not mainstream is an understatement. I know some reverse engineering gems for Rails but nothing like that.
> The generation tool should know all the ORMs or whatever used by the clients and modify their models. Saying that this is not mainstream is an understatement.
I'm not sure that there would ever need to be any code-generation tool that knows more than one ORM and is, presumably, bundled with that ORM.
Now, if you're saying that they don't actually exist, currently, for anything other than jOOQ (which is being promoted in the article), I don't doubt that.
However, given something like ActiveRecord's schema discovery functionality, maybe that's good enough when combined with slightly more manual intervention. Other ORMs may be better or worse, of course.
Unfortunately Rails or Django or any other framework's migrations are so much more convenient compared to maintaining a schema manually. Any database centric migration tool would have to update the models for all the projects using it. That's not easy AFAIK.
I'm working at a project in which different teams are writing services in Elixir (Phoenix) and C# (no idea what's in there.) We're using different databases and an HTTP API, so the databases and their schemas are hidden inside every (not so micro) service. We didn't share the database because it would have been a nightmare to mirror changes in both codebases.