Seems like a pretty commonly accepted pattern:
https://docs.aws.amazon.com/prescriptive-guidance/latest/mod...
> You need to carefully assess the application architecture before adopting this pattern, and make sure that you avoid hot tables (single tables that are shared among multiple microservices).
Using the same database table with multiple services (micro or not) is an absolute disaster.
Are other services also restricted in the same way?
If microservices share a database, it's not clear who migrates the schema and coordinating it is nearly impossible because another piece of code in another service may be reading the old schema and break.
Sharing the database means you have a distributed monolith - you lose all independent deployability. It is the worst of both worlds.
The exception may be if you share a database instance, but each service has its own schema and only has authorization to read and write to its own schema.
That doesn't make the single database a service - it would make it shared infrastructure, however. This may bring its own maintainenance challenges but it doesn't violate any principles.
The only bullet on the list which isn't related to "it currently works this way and you can't change it" is the one that says
> You want to maintain and operate only one database.
Which is frankly a terrible bullet point because the next question is "Why would someone want to do that?"
The whole list is basically just "if you have constraints that make a better design impossible then I guess you can do this"
Because for example you have BI reporting queries that need to join across schemas, and it's the most cost effective way to do that. I've seen that kind of thing both through ETL and going through normal service APIs, and both are way more expensive (in developer time and compute resources) than e.g. doing a normal db query against the slave.
A shared database will also make me effective use of resources than if you try to manually assign them to split databases.
If you need cross service transactions, it's easier to have the db do that than to implement 2pc.
The real question is why split it? If you can fit on one machine, there's not much reason not to. Like the previous poster said, you can use separate schemas or table permissions with service accounts to keep logical separation.
The other (more serious) problem is that if multiple services can edit the same data independently, eventually they will, and it will cause data loss or degradation that will be catastrophic. And, although you CAN isolate things with permissions, the chances of this reliably getting done without a lot of time put into DBA (a role which simply doesn’t exist at startups), is very low in my experience.
Yes, and that API has types, e.g. protocol buffers. And also, sometimes you just want to change the API, and you want to make that as easy as possible.
using an IDL means that consumers of your API need to depend on an IDL definition at the source level, which introduces coupling that is not always useful
for example, talking to the stripe API doesn't require you to import a stripe.proto
Maybe I've been doing this wrong all my life then.
Imagine I want to fetch user data by id from Galactus, the user data service. I know what shape of data I want from it, and Galactus knows what shape of data it provides. Should both my service and Galactus have full, individual copies of this data structure? Alternatively, if Galactus has a published schema that I refer to, isn't that a shared data structure?
By extracting the user data shape to a common repository (library, header, schema, whatever), not only we deduplicate code, but we also centralize documentation. Maybe the `address` field is cached and frequently outdated, and someone from Galactus noted this down along with where to find the golden source.
Once you factor in other sources of redundancies (username regex, recommended logging, business-specific snippets), that naturally becomes a common library.
I get that it sacrifices some service independence, but is this piece of independence always so worth it, that common libraries are "officially doing it wrong"?
> Imagine I want to fetch user data by id from Galactus, the user data service. I know what shape of data I want from it, and Galactus knows what shape of data it provides. Should both my service and Galactus have full, individual copies of this data structure?
No. Galactus should have the full shape of the "user object" but should never put that on the wire or expose it. The wire API should expose sensible things like "what is the billing and shipping address(es) of this user id". Galactus is responsible for maintaining the mapping between the "user object" and whatever the relevant return format is for those data.
Edit: This allows you to run API migrations and data migrations independently. Which is crucial for any service that will last longer than 1 year.
When you start out, it will feel very repetitive because your client object structure matches your API structure matches your server object structure. You might even think "DRY!" and want to combine these, but IMO, resist the temptation. You will eventually have a case where these need to evolve independently. For the Galactus case, imagine that for compliance (or whatever) reason, you need to start soft-deleting users, and you do that via the simple case of an `IsDeleted` flag on the User table. You'll need that flag on the User object on the Galactus side, but you don't want to add this to the API and expose it to clients.
> Edit: This allows you to run API migrations and data migrations independently. Which is crucial for any service that will last longer than 1 year.
Totally agreed here too.
I've felt nervous for years about going all-in with Django Rest Framework, and you've articulated exactly why.
But there's also something going over the wire, as a response from Galactus' API, and consumed by one of more other services.
His question was, shouldn't the knowledge of the structure of that be in some type of shared code?
But the key here is that their own library still goes through their API, not directly to their database. So that if you don't want to use their library you don't have to.
The failing pattern we've seen at my company is a client library, a server library, and a shared "model" library.
The issue that has happened time and time again is the model library ends up including classes and dependencies that either the server or client needs. This in turn leads to a frustrating experience of dependency wrangling when someone decides to throw in lombok, or kafka, or JavaFx into the model library for that 1 sweat `Pair` class the server is using internally. Or worse, they depend on a different model library because they need that one sweat enum. (Which in turn depends on other model classes, or server classes, or whatever).
If you do a client library, it should depend on practically nothing. The transport library (http client), authentication, and the data marshalling library. Nothing more. It should also be viewed as an example of how to work with your API and not the only way to work with the API. (Don't reinvent graphql... please!)
in fact the galactus team should actively _not_ publish a library for their API
doing so introduces a source-level coupling between consumers and producer, which the API was (presumably) created specifically to avoid
it takes an enormous amount of discipline to ensure that this kind of software is treated as "a reference implementation" rather than the canonical path
if an internal service API is too difficult to use without an API library, then this is a pretty good signal that something is wrong and needs to be fixed, imo
Yes!
Maintaining that structure should be painful. Why? Because it's an exposed public API and there are ramifications to updating it that need to be thought out.
Further, it can be super easy to polite that structure with information only relevant to the server or client.
Using something like JSON schema, openapi, or grpc/protobufs can make generating that second structure easy, but sharing it is something that has caused my org tremendous headaches.
How can you get any work done like this?
Are you all working at massive corps that develop at a glacial pace?
Sounds like you all spend your time shuffling papers rather than doing anything meaningful.
To implement microservices, one takes what is a service in a normal application, a handful of code files in a normal application. Maybe some model files, a service, validators and a repo file. A slice of an application.
One creates a new project file, build files, etc. Maybe a new repo, maybe not. You then wrap that simple service in a bunch of boilerplate plumbing code so it can actually work on its own.
So, basically, a ton of extra code, right off the bat. Each time.
Then to do it right according to this thread, you duplicate the definition files between your services, multiple times, add JSON schema files that you didn't have to maintain before, and, someone else has mentioned, create an extra library on top of all this so your colleagues can implement it as if it were just a normal method call.
Even more code!
And that's your microservice. A lot of extra work. Busy work as far as I can see, no benefits. Just to do exactly what it used to do.
But, worse still, it has huge drawbacks, including:
1. Very slow "method" calls. Normal method calls are obviously orders of magnitude faster than whatever you're doing. L1 Cache is always going to be massively faster.
2. Poor debugging
3. Complicated devops requirement
4. Hidden complexity in the interaction between services that is impossible to see
That's what this thread is about when the original poster says "you're doing services wrong".
So, no, I'm not the first person to mention them. You just need to read the context of the discussion.
The article even states Microservices are not suitable for startups - the conversation in this thread has been able service oriented architectures which is a much broader topic.
I don't know where you're getting implementation details leaking when it's just API definitions being shared - they don't leak implementation details unless they're badly designed, which would affect them either way.
OOP languages have interfaces.
You can do this already without adding any sort of microservice, schemas, duplicate definition files, externally maintained libraries, etc..
It's a basic feature of most languages.
It is NOT an exclusive benefit of a microservice pattern. Stop claiming that, it's one of the most frustrating claims/lies microservice advocates make.
The actual benefit is that you're forcing developer to use interfaces. At a massive cost.
There are much cheaper alternatives. You enforce a Dependeny Injection pattern on your services. Code reviews. Linting tools.
So no, this is not basic stuff.
And worse still, if your team can't properly use interfaces in your languages, how do you expect them to suddenly learn to use them properly in your services?
Firstly, the space and time scales. If your two-pizza team has twenty services, and they communicate like this, and interfaces change a few times a week, then there will be quite a lot of pointless paperwork. If your two-pizza team has one service, used by other teams, and the interfaces change once a month, then this might be an appropriate amount of speed bump.
Secondly, tooling. If your APIs are all done by hand, then making an update is a modest amount of boilerplate. If you are generating everything from schemas, and you have your build down tight, then it can be a matter of changing the schema file, pushing, waiting for that to propagate, then adding the necessary data to the message you changed.
People get work done by knowing what they're doing, which I'm not sure you are able to tell.
There is plenty of literature that explains quite thoroughly the process of software architecture. Basically all major software architecture styles from the past four decades reflect the need to encapsulate and insulate implementation details, including the need to specify a domain model and how it should be specific and exclusive to each project.
Somehow, you are oblivious to basic principles but still feel entitled to insult others based on domain knowledge you clearly lack.
services map to teams, not units of functionality
imo minimum org size to use microservices is something like 50 engineers
> a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things.
When designing an API consumed by many people, changing that contract is often the wrong thing to do. You'll have unintended breaks with your consumers. So, adding an extra layer of annoyance is something that tells a dev that wants to change one of these models "Hey, what you are doing might impact more than just the place you are changing. Maybe you should rethink this".
That is, it's a bit painful.
Good software is using pain and annoyance to discourage devs from hurting themselves. When making a bad change isn't painful, it happens frequently.
Have you ever wondered why we write tests? Tests encourage pain. They make future changes annoying (because you might need to update the test, a pain). Yet most people see writing tests as a virtue, not a vice. That's because the pain of the failed test prevents unintended consequences of code changes.
That's what having 2 models does.
[1] https://blog.codinghorror.com/falling-into-the-pit-of-succes...
That's just implicit sharing, or versioning with extra steps...
I think many people prefer the compile-time error surfacing.
There’s definitely trade offs to sharing types though, especially if the API and clients are in different languages. If your team is small enough and has enough context on API changes it’s probably easier to maintain different types. But if it’s large or spanning multiple teams it might be better to rely on tooling to share or generate types. It’s always about trade offs.
There’s definitely trade offs to sharing types, especially if the API and clients are in different languages. If your team is small enough and has enough context on API changes it’s probably easier to maintain different types. But if it’s large or spanning multiple teams it might be better to rely on tooling to share or generate types. It’s always about trade offs.
Reference: https://www.youtube.com/watch?v=y8OnoxKotPQ
Yes. I recommend you read "Domain-driven design" by Eric Evans, specially the part explaining the concept of a bounded context.
> Alternatively, if Galactus has a published schema that I refer to, isn't that a shared data structure?
No, that's the interface.
> not only we deduplicate code
You don't. You just needlessly add a constraint for no reason at all, and in the process make your life a mess.
Let me reply in the spirit of your comment:
No, you are officially wrong. [0]
[0] Says me.
I agree w/ your other take re: the database but don't understand this one. Sharing data structures between client and server, particularly request/response structures, is hugely useful, certainly not an antipattern.
And similarly the idea that if you share a common lib across service boundaries then that's "wrong" falls apart at even the most cursory glance.
Service A and B both depend on Service C. So there's a shared client library/SDK that Service A and B use. As just a trivial example.
but one of the major reasons to break up logic into separate services is to eliminate source-level coupling
a consumer should not need to import service X's SDK in order to use service X, if that is the case then it introduces all kinds of bad situations like "well if i change my service X's behavior in some backwards-incompatible way, it's fine, as long as i update the SDK appropriately" -- wrong
etc. etc.
I know those aren’t the data structures you probably meant, but those are data structures that are commonly shared.
That’s different than a model though, which I think is really what OP is talking about.
There’s no problem in sharing a library but it is a model which works best with a monolith or a monorepo (and obviously one language). You definitely DO NOT want multiple versions of your library kicking around.
Quite correct. Each service should have it's own duplicated copy of `someUtilityFunction()`.
Then instead of applying 100 fixes to it you can have 100 different behaviours for some pice of business logic.
/s
edit: Libraries don't solve this, to be clear. Let's say you have 100 services that reference `someUtilityFunction()` in SharedLib==1.0. Oops, there's a bug! OK, let's publish SharedLib==1.1. Great... now you still need to go and update, test, and deploy 100 different services, because they're not going to pick up the corrected business logic otherwise. And of course, you might have the case where someone got lazy and didn't upgrade and they're still using SharedLib==0.0.1-alpha, and there's a bunch of breaking library changes that happened between that version and 1.0 that were never implemented...
Yeah, but that relies on a lot of "ifs" when a bugfix is done.
If the services don't have tests before deployment, you'll have problems.
If a rarely-updated service doesn't get the fix, you have problems.
If someone got lazy and didn't upgrade (how is that even possible? they don't have to do anything to get the new thing other than rebuild, redeploy) you'll have problems.
OTOH, there's no "ifs" about getting a bugfix when they're all using the same copy of `someFunction()`.
When they're all using the same copy of `someFunction()`, the bugfix will go in with the next build of their service, without them even knowing.
After all, you don't have each team keep their own copy of the kernel, do you?
So you can make a new function. Maybe one calls the other. They do nearly the same thing but not quite. Some dependencies move to the new one, some don't.
Or you version the library. Shortly after, people want mixes of behaviour from different libraries, and someone else wants two dependencies that each want different versions of the library.
I don't have a good recommendation here but silently changing the behaviour of libraries is not necessarily a better play than not doing that.
I assumed it was done here. Why wouldn't it have been? There's no evidence of that.
> Shared data structures? Common library? Services have an API
I assumed that was what they meant: common data structures being whatever the various APIs emitted and received. You don't need more than that if you're two people shipping a full product. People aren't buying your internal architecture, and it sounded as though they built it so the code could be separated out in future if necessary.
if you do have an API boundary then it's important to understand that interactions against that boundary are resolved at runtime -- in contrast to data structures which are resolved at compile time
if you break something out to a service that's only accessible over a network boundary then there's not much sense in requiring access to go thru some SDK library, right?
> Each service has to be maintained and deployed and increases the boilerplate needed for shared data structures, complicated communication protocols and infrastructure. By the time we released our app, the common library used by most services has been updated over a hundred times. And every service has to follow suit eventually.
Shared data structures? Common library? Services have an API. If you are sharing data structures and a common "core" library across services, yes, you are officially doing it wrong. From the architecture diagram it also looks like there's only one MongoDB instance, which, if you have multiple services talking to the same database[0], is also a major sign that you're doing it wrong.
IMO the author came to the correct conclusion, that monoliths are better for a new project, but for the wrong reasons. Or maybe the right reasons which aren't clearly explained, which is that at the beginning you don't have a good enough grasp of the domain to properly separate into independent services.
[0] yes, there are exceptions where you can have multiple services use the same physical database to reduce maintenance overhead, but enforce separate ownership through different logical databases or even table-level permissions, but I'm assuming that wasn't done here.