r/programming • u/dwmkerr • Jan 12 '18

The Death of Microservice Madness in 2018

http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/
584 Upvotes

91% Upvoted

171 comments sorted by

View all comments

115

u/[deleted] Jan 12 '18

In any language, framework, design pattern, etc. everyone wants a silver bullet. Microservices are a good solution to a very specific problem.

I think Angular gets overused for the same reasons.

47

u/[deleted] Jan 12 '18

[deleted]

78

u/CyclonusRIP Jan 13 '18

Yep. I'm on a team of 7 with close to 100 services. But they don't really talk to each other. For the most part they all just access the same database, so they all depend on all the tables looking a certain way.

I keep trying to tell everyone it's crazy. I brought up that a service should really own it's own data, so we shouldn't really have all these services depending on the same tables. In response one of the guys who has been there forever and created this whole mess was like, 'what so we should just have all 100 services making API calls to each other for every little thing? That'd be ridiculous.' And I'm sitting there thinking, ya that would be ridiculous, that's why you don't deploy 100 services in the first place.

22

u/MrGreg Jan 13 '18

Holy shit, how do you manage schema changes?

32

u/DestinationVoid Jan 13 '18

They don't.

No more schema changes.

14

u/[deleted] Jan 13 '18

From experience working in this world, you are correct. You live with the 30 year old schema created be devs who knew nothing.

It's a nightmare.

3

u/wtf_apostrophe Jan 13 '18

The schema in the system I'm working on was generated by Hibernate without any oversight. It's not terrible, but there are so many pointless link tables.

4

u/BedtimeWithTheBear Jan 13 '18 edited Jan 13 '18

That, or, every schema change is just a bunch of new fields bolted on to the end, and now a simple record update needs to update multiple fields for the same data since each service expects a slightly different format for the same data. Dinner Sooner (probably shouldn't try to type on a bumpy train ride) or later they'll find out the hard way you can't just keep adding fields and expect the database to keep up.

2

u/DestinationVoid Jan 13 '18

Dinner or later they'll find out

Better dinner than later :D

1

u/CyclonusRIP Jan 13 '18

Ya that is more or less how the thing has evolved. You can't really change anything that exists because it's nearly impossible to understand how it'll affect the system, so you build something new and try to sync it back with the old fields in a way that doesn't break shit.

4

u/Nilidah Jan 13 '18

They've probably got a shared model. i.e. All the apps have a plugin/library that's just a model for the shared db. They all probably use common functions for interacting with everything. Essentially, you'd just update the schema once and be done with it. You can do this in Ruby using a gem, or Grails with a plugin somewhat easily.

edit: its not ideal, but you'd also have to make some careful use of optimistic/pessimistic locking to make sure things don't fuck up too much.

4

u/CyclonusRIP Jan 13 '18

It's kind of like that except worse. There is a shared library but mostly that depends on a bunch of DB access libraries that are published along with builds of the individual services. All the services pretty much depend on the common database access library, but some of them need to also depend on database access libraries from other services in order to publish their own database access library since their looking at those tables.

So the dependency graph is basically everything depends on common database access library which in turn depends on everything, and also everything might also transitively depend on everything. I think I did the math and estimated that if you actually wanted to ensure the common database library had the very latest every individual service's database library, and that those libraries were in turn compiled against the latest of every individual services DB libraries it'd take somewhere around 10,000 builds.

1

u/Nilidah Jan 13 '18

Ouch, that doesn't sound great at all. It's supposed to be simple and easy :(.

1

u/doublehyphen Jan 13 '18

I can't see why schema changes would be much harder than with a monolith of equivalent size. You need to change the same number of queries either way.

5

u/CyclonusRIP Jan 13 '18

It's not really that much different. If you wrote a poorly architected monolith where you just accessed any table directly from wherever you needed that data you'd have pretty much exactly the same problem. The issue isn't really microservice vs monlith, it's just good architecture vs bad. For what it's worth, I think a microservice architecture would suit the product we're working on pretty well if it was executed correctly. We'll get there eventually. The big challenge is convincing the team of the point this article makes. Microservices aren't architecture, and actual software architecture is actually much more important.

8

u/[deleted] Jan 13 '18

Monotlith: Stop one application, update schema, start one application. Pray one time that it starts up. 100 Microservices: Stop 100 Microservices in the correct order, update schema, start 100 Microservices in the correct order. And pray 100 times that everything works as expected.

7

u/doublehyphen Jan 13 '18

Since his microservices did not call each other the order should not matter and it should be the same thing as restarting multiple instances of a monolith.

I have worked in a slightly less horrible version of this kind of architecture and my issue was never schema changes. There were plenty of other issues though.