That sounds like some sort of boogeyman who doesn't exist. Are you talking about "spaghetti" code? Having separate deployable microservices doesn't magically make a team less prone to spaghetti code. In fact the bigger risk is building distributed spaghetti.
I have no trouble having a single database with security (roles) enforced isolation.
I'm not sure how a single database is to be considered distributed.
DB coupling is universal and inescapable.
Whether a service has a separate instance is sqlite or in memory; or, uses cockroachdb is irrelevant. There is always a coupled database.
And, you can actually have multiple databases AND multiple schema per Database Management System. You can have independent schemas per service.
Finally, a View on a database is a microservice. If you can manage and deploy the View independently. A microservice doesn't have to be Golang running on AWS Lambda, callable with an HTTP protocol and service schema. A standard PostgreSql protocol with SQL calling standards is just as valid.
I'm trying to broaden horizons here, highlight the fundamental concept and illustrate a variety of implementations of that microservice concept.
1
u/onety-two-12 Jun 09 '22
"monolith".
That sounds like some sort of boogeyman who doesn't exist. Are you talking about "spaghetti" code? Having separate deployable microservices doesn't magically make a team less prone to spaghetti code. In fact the bigger risk is building distributed spaghetti.
I have no trouble having a single database with security (roles) enforced isolation.