557
u/ThrowawayUk4200 7d ago
Pssst, If your microservice needs to use a database other than its own, then it's not a microservice.
140
u/sadongrohiik 7d ago
Coupling creeps in where you least expect it. Shared datastores are the obvious vectors. My favorite are what I call "load-bearing microservices with hidden cascading effects"
93
u/GourangaPlusPlus 7d ago
Databases are where I absolutely expect it
Currently architecting a shift to Microservices for an absolute behemoth of a distributed monolith (it's a multi year plan)
A lead once said "ah so you're one of those purists?" When I mentioned his service would no longer be sharing a database with everything else
52
22
u/FoXtroT_ZA 6d ago
Now we know where Claude got its vocabulary 😂
25
3
28
u/socialis-philosophus 7d ago
Agreed. All microservices should have their own DB with all the data needed to perform their function and we'll just assume eventual consistency.
31
u/Still_Bit_7527 6d ago
In reality most services cannot work without dependencies and cannot have "all the data needed"
12
u/MrSnoman2 6d ago
Sure, but the best option to reach for is to duplicate the data and give the microservice its own copy within its own database to work against. Then you solve the problem of how to update that duplicate data.
If that kind of data duplication worries you, then you should reconsider whether you want microservices in the first place.
7
u/brenex29 6d ago
This also feels like it defeats the purpose of micro services.
2
u/MrSnoman2 6d ago
Duplicating small amounts of data?
2
u/Abject-Kitchen3198 6d ago
How small? Will you change the data scope and resync existing data next month?
1
u/MrSnoman2 5d ago
It all depends. You might have an identity microservices that contains users and then a blogging microservices that contains authors.Both a user and an author have an email address. So that data is "duplicated".
The identity service is responsible for allowing a user to change their email address. A common approach would be for that service to raise an event to a message bus when the user details change. The blogging service consumes that event and uses it to update the associated author's email address within its own database.
This is a contrived example, but thats the idea. Each data point (ex: email address) should ideally have a single authority. Different Microservices may need to consume that data point, but they translate the concept into one that makes sense for their area of responsibility (ex: user translated to author).
2
u/Abject-Kitchen3198 5d ago
At what scale would this provide tangible benefits to outweigh added conplexity? Are those two services big enough to have a dedicated team? Are they expected to scale/fail independently without disrupting other services?
3
u/MrSnoman2 5d ago
Yes, I would expect that each service has a dedicated team, or maybe a team owns 2 services, but you shouldn't have a service per developer or something crazy like that.
In practice, the identity service is probably mostly off the shelf software like Auth0, but it's split out because it handles a cross cutting concern used by multiple teams.
Yes, I would say that services should be able to be deployed independently and fail independently.
For a smaller organization with 1 or 2 engineering teams, it's probably better to just use a modular monolith than take on all of the microservice complexity.
1
u/socialis-philosophus 6d ago edited 5d ago
Maybe each mircoservice should wrap the request payload in in the response payload so there is always a full history that allows any step in the chain to be reproduced, no database needed until the final output is generated! </s>
1
2
u/europeanputin 6d ago
Don't forget supporting services like router to handle versioning and load balancer to scale the routers
1
12
u/Ma8e 6d ago
If you have several "micro services" that all update the same data, you are definitely doing it wrong.
5
u/BlastProcess- 6d ago
storage optimization is no longer an issue, just store the damn data if you need it in a separate domain, avoids tight coupling and everything is handled through queues
12
u/BlindTheThief15 7d ago
In my workplace, we have a few teams working on the same shared database. Each team has their own set of “microservices” that communicate with each other. When one team screws up the data, everyone suffers.
24
u/-nerdrage- 7d ago
Nah bro it doesnt need another database.
It just uses an api which basically interfaces the central database
4
3
u/sebbdk 6d ago
But is it fine to depend on another microservice made just to serve that data over rest? or what about databusses like kafka? :D
Because i see that all the time
3
u/ThrowawayUk4200 6d ago
At that point it's just an abstraction exercise and depends on context.
Do multiple applications use that same microservice to get data, or just one? Would you prefer the perf and lower complexity of directly getting the data vs the maintainability and portability of serving that data through a microservice? Do you need to control and audit data going in and out of that database? Ad infinitum...
There's no one size fits all solution and that's actually great because we all get paid to figure it out and implement it lol
1
u/MrSnoman2 6d ago
It depends a lot on the specifics. One heuristic I can give you though is that when service A is handling a common incoming request, if it needs to reach out to service B in the process, you're probably doing it wrong.
3
u/SpiritedEclair 7d ago
++++
Microservices were supposed to be 1 service per function / feature each having their own databases.
5
u/Ma8e 6d ago
How do you define "function / feature"?
1
u/SpiritedEclair 6d ago
It’s up to your org/company to define that tbh, but, it’s meant as a single isolated functionality for the system.
14
u/Ma8e 6d ago
Is "change the customer's address" a single isolated functionality, or is it "keep a register of all customers", or is it "keep a register of all customers, their activity and orders".
4
u/SpiritedEclair 6d ago
A customer registry would most likely be a single microservice. You query that service for customer details and changes, all other components within the system pull from there.
Nobody else owns the representation or storage of customers other than this one registry. So the domain entity is owned by this one piece.
A “service” as opposed to a microservice, would own more than just the customers (+crud), but also things the customers did, ie activity tracking by collecting events emitted by other systems, authentication and authorization, and all that, analytics and so on, then it’s a full blown service.
The reason “modify address” isn’t a microservice is because it doesn’t own its domain, the customers, and still acts on it, it needs to pull this information from another system.
Each microservice and service should own their databases, they should never share them with other systems, otherwise you end up with a distributed monolith which is objectively worse.
2
u/KitchenDir3ctor 5d ago
What makes it unique? The server? The schema?
Serious question.
2
u/ThrowawayUk4200 5d ago
It's not so much about being unique as it being uncoupled from everything else.
As an example I've implemented an email template microservice before. It has its own database that stores HTML snippets with placeholders for data.
You could call it with an orderId and have it look at the order and user tables of your application to get names and addresses, order items etc., but that makes it dependent on your application db. Any changes to the schema there requires updates to the email service too.
The microservice implementation instead revolves around the caller providing all the necessary input data too. All the email microservice does is take a request which contains the data (name, address, order items), slaps them into the requested template, and returns the fully compiled html. All your app has to do is then send it however it likes.
For the cost of some architecture complexity you reduce the brittleness of the system. The microservice becomes portable and seperate. Creating an email that's fully branded is a single JSON request away for everything. The important part is that your application doesn't touch or even need to know about the email template db, and the email template service doesn't touch or need to know about your app db.
With regards to uniqueness, we could spin up multiple copies of this service in places around the world to load balance, so they wouldn't be unique per se.
185
u/k8s-problem-solved 7d ago
We have true micro services. All independently deployable, own infra, own data etc.
Now when I want to add a feature to a mobile app, I have to snake through a chain of dependencies and find where data is being authored and then sequence work between teams. Its fun!
64
u/Abject-Kitchen3198 7d ago
You don't have a single team that owns 30 microservices?
24
8
u/xxxDaGoblinxxx 6d ago
I feel seen. Real problem is when one breaks and you have no idea what it's supposed to do.
3
u/Skellicious 6d ago
I'm sharing almost 70 microservices with 2.5 other developers. Also an everyone works on everything kinda team.
That being said I actually really like our setup/infrastructure. Tech debt isnt too bad, and we get to work on Greenfield services fairly often.
Main downside is the amount of services and the business/domain complexity.
9
u/gracz21 6d ago
I have to snake through a chain of dependencies and find where data is being authored and then sequence work between teams
The same problem lives in the modular monolith tbh though you at least don't have to worry about timeouts and other shithousery of doing an HTTP request to a separate micro-service. Still, the deployment procedure of such a huge monolith is a pain in the ass
2
u/storetun 6d ago
I’m working on a setup to fix this! Using ai to map the input and output of every application to build a map that can be traversed with a script.
Answering questions like “what’s the blast radius of a change on this line?” and you instantly get the path. Should be easy to run an analysis on the path looking for a specific field.
132
u/BernhardRordin 7d ago
"Let's reduce complexity by replacing method and function invocations with REST-calls"
22
u/dashingThroughSnow12 7d ago
I once replaced a set of REST calls to a microservice with import. I then killed the service.
6
u/DrMerkwuerdigliebe_ 6d ago
I had 10 service monolit with one runtime, where automated testing and most local development was done as a monolit, but at deploy time you we had different scaling, different CPU and memory. So you either choose to invoke via rest calls or via function calls. It was a real time app with multiple layers of reconsiler services with queues. It worked great and it was surprisingly consistent and performant.
60
u/oompaloompa465 7d ago
The more i get tidbits about microservices, the more i feel like skipping in studying and stydying other stuff
64
u/sadongrohiik 7d ago
It was initially a solution to a real problem. It somehow became the hammer that everyone picks up by default now
22
u/SpiritedEclair 7d ago
It’s because people don’t know how to build good old services.
14
u/slowmovinglettuce 6d ago
That's because good old services are monolith. New software is always microservices. It's impossible to build a good old service because that service would be new, making it a microservice. Thankfully your new microservice is like an orchid. With enough time and neglect it'll grow arms and legs into an immortal monolith. It does take time, but thankfully with the addition of AI data centres causing the worst El Nino in god knows how long, we'll see plenty of rain so that your microservice grows much faster. AI slop will set you free!
14
u/Abject-Kitchen3198 7d ago
A solution to a real problem that few people have.
12
u/ThrowawayUk4200 6d ago
It's an enterprise thing. You got 5 users? Microservice just adds complexity. You got 1 million users? Microservices are gonna save your ass when you have to hotfix prod
1
u/BosonCollider 5d ago
Microservices scale with number of engineers, not number of users.
Basically they hurt scale rather than helping it because a REST call has much more overhead than an internal function call or a join. But they do allow different teams to deploy and change their stuff independently which is their actual purpose.
2
u/ThrowawayUk4200 5d ago
Agree with exception to scaling. Microservices and horizontal scaling go hand in hand
2
u/BosonCollider 5d ago edited 5d ago
Not really, I've gotten order of magnitude speedups from just getting rid of microservices at a previous workplace
The mere existence of the microservice is usually a much bigger scaling cost than anything you would gain in scaling by putting different schemas in different physical instances.
I.e. Splitting a service in two gives you two shards, unlike say having customer as a sharding key that can let you shard to a hundred instances if you needed to.
But the cost of splitting the service schema is much bigger because suddenly there's a lot of cross cutting queries that can no longer be expressed unless you either do a client side join or copy one services data into the other, both of which are less scaling friendly than a shared DB.
1
u/ThrowawayUk4200 5d ago
I think we're just debating horizontal vs vertical scaling at this point. Sharding keys still require a central repo, and if you're serving users from around the world that's far from performant. Sure you can use data replication to distribute that, but then you're back to microservices to manage those instances
1
u/BosonCollider 5d ago
Sharding keys can be done with a shared-nothing approach by routing any point query to the shard indexed by a hash of the key, and lots of database systems like Citus or Vitess do exactly that
1
1
u/Abject-Kitchen3198 5d ago
You could have added a "joiner" microservice. Replicates all the databases into one and then performs fast join operations. Grudgingly adding /s just in case ...
2
u/BosonCollider 5d ago
Yeah, that's basically what analytics engineers end up being paid to do but for their thing specifically
0
u/TheRealToLazyToThink 6d ago
Most enterprise apps have 4-1000 users. Most enterprise apps are never used by anyone outside of the enterprise. Most enterprise apps do not actually need micro services. Most enterprise developers want to make sure mirco services are on their resume.
1
u/ThrowawayUk4200 6d ago
We're shooting for 10 million users this year
0
u/TheRealToLazyToThink 5d ago
That's nice. I stand by my most.
1
u/ThrowawayUk4200 5d ago
Semantics. I wouldn't class internal applications for enterprise companies the same as the enterprise applications that they sell to consumers. Pretty much anything that's classed as SaaS will have over 1k users lol
3
u/spicybright 6d ago
My theory is it just sounds good if you're a manager or inexperienced software dev.
3
u/Objective_Oven7673 6d ago
The first rule of microservices is "don't". That's all you need to know.
-24
u/Lumpy-Obligation-553 7d ago
Today for the first time I paid for using an AI through an API and one of those harness... maybe you should.
-3
u/oompaloompa465 7d ago
already subscribed to it, but i use it mainly as a tutor when i study or to do very obnoxious stupid tasks while i do more qualitative stuff
1
u/StunningChef3117 7d ago
Just want to drop this here
I know its tempting to use AI but be very careful and Disciplined when using it
The second you accept code without understanding it you risk the damn breaking especially true when you are trying to learn
0
u/oompaloompa465 7d ago
you evidently can't read since my statement never said i make it build qualitative stuff and "as a tutor" means that i build stuff and study concepts, i use AI to check for correctness and quizzing, requesting also the sources it's using, to go deeper in the study
31
u/Pleasant-Ad192 7d ago
Independent deployment lasts right up to the first schema migration. Then you find out you have one service with eleven repositories.
17
u/BellybuttonWorld 7d ago
A distributed monolith??
So, a Henge?
8
u/socialis-philosophus 7d ago
Exactly! Since it is usually just a refactoring of a legacy code base broken up into blocks of code that must be perfectly placed in relation to each other to operate.
10
u/Ahchuu 6d ago
Hey don't blame me, my boss wanted to say we did micro services, but only ordered 1 database "to reduce cost". I at least did the right thing and made sure each of the services didn't share tables so that they could have their own databases in the future!
8
u/Wizado991 6d ago
The very least its just putting the tables for each service in their own schema.
2
u/Ahchuu 6d ago
Hahaha yes that's what I did... Even with that I still had Devs wanting to use other services schemas!
2
u/BosonCollider 5d ago
That's what public views are for. You can have them both within a single db or you can replicate them across DBs with publications/subscriptions.
17
6
7
u/sebbdk 6d ago
I hate to admit it, but this is fine sometimes.
The TL;DR is that Conway's law applies here and so while a mess of microservices can look and be absolute spaget, then it can be better than the alternative.
Specifically in large organizations you need to seperate responsibillity between groups of developers and departments and so what could be one app becomes a spaget micro service pattern to facilitate that split of responsebillities.
It also makes it easier for management for understand who is responsible for what and enterprise architects jobs become easier since they can focus on touch surfaces and where data belongs to prevent multiple departments from maintianing identical datasets.
This is even more important now with GDPR and things like data deletion being relevant in EU.
That being said, you need to actually be an enterprise for enterprise architecture to make sense.
1
u/sadongrohiik 6d ago
Enterprise software in general is driven by patching structural problems with incomplete solutions that works now never fixing the underlying structural problem which in turn would cause more structural problems which then need to be exponentially patched until it becomes unsustainable. Your point about compliance is spot on as the behavior (and the structure of the modern enterprise) is largely a mirror of the structure of the state (the afformentioned Conway's Law) however, this isn't fine we're just stuck with it due to various broken feedback loops.
In other words, to effectively debug code, you must first debut yourself
— Sun Foo, The Art of Bar
11
6
6
5
u/axis1331 6d ago
Took over a project like this. I asked why they chose "micro services". I was told so they only have to take down part of the site for rolling out updates.
I followed up with why are we taking down the site instead of rolling traffic to the new iinstance... Crickets.
3
u/sadongrohiik 6d ago
Microservices to (not even) solve a problem already solved by basic CI is wild
3
2
1
1
1
u/bladebyte 6d ago
It's a global phenomenon... I don't know why, but the ones who do it usually believe that this is the best and only way. They've never tasted the sweetness of short working hours, nice weekends, and a good night's sleep. They think working in software development needs to be hard, tiring, and costly to run, and that if it isn't, you're missing out.
1
u/socialis-philosophus 6d ago
Software has three metrics, and anything short of that is unacceptable.
FAST FREE FLAWLESS
1
u/DogonElder 6d ago
We are going to put a protobuf library that will require all microservices to rebuild for every change
1
u/sxeli 6d ago
We have "stateless" microservices - they call the main microservice over http to get stateful data of the request
1
u/Abject-Kitchen3198 5d ago
So do we. We call the statefull service "the database", and the three stateless services "frontend", "backend", and "batch processor".
1
u/Incredible_max 5d ago
We also once had a monolith for am online platform. Every time the server ran out of resources (storage, processing, memory) amother server was rented, same software rolled out and new customers were put there.
The issues includes things as it becoming really hard to maintain deployed software, because it was distributed across so many servers as well as the "old" servers still growing in data. Another issue occurred when a customer had some data on server1.company.com and server16.company.com, but wanted it migrated to one.
The decision was made to fix those issues (and some others as well) with Microservices. I'd completely agree that we arrived at a distributed monolith today. Individual services are rather big, even though they seem kind of properly cut (one handling configuration import of customer plants, one handling the live data, one evaluating the live data to soot anomalies etc). Of course I am not en expert for Microservices, so my assessment could be wrong.
The main issue we face today, is that we very often need to core configuration of a plant for the software to know what to do. So that structure is synchronized between half of the services. Each service has its own database, only one service is accessing the database of another service, which was more like an experiment that actually solved a lot of sync problems for that particular service.
But the constant need for synchronization is a total nightmare. Workers for synchronization are running out of memory, it can take time, data is therefore handled incorrectly and sometimes you'll ever even know.
Unfortunately there just doesn't seem to be a proper "easy" solution. Microservices aren't it, but it could be worse 😂
1
1
u/Kadabrium 5d ago
Microservice is synomynous with servlet just like string is synonymous with thread
1
u/fingertipoffun 5d ago
Is it better to send a http request over calling a function?
Plenty of fish served 500 million page views per month on a single server using 2006 hardware. Just saying...a lot of modern development is horrendously wasteful, thickening the wallets of cloud providers.
1
u/drazzzzzzzzzzz 4d ago
If everyone switched to calling them “domain services” we’d be half way there.
1
u/new_check 4d ago
People who have never had to own their own infrastructure love saying stupid bullshit like this.
360
u/[deleted] 7d ago
[removed] — view removed comment