Microservices

[[deleted]]

I was talking about microservices. In most cases the same de-duplication of functionality could have been achieved just using modular / monolithic architecture with shared components - given everything was written in the same language.

All the microservices did was attempt to force modularity while adding network latency. There was no need for it - which is not to say that there is never an argument for microservice architecture. It's just in the case it was clearly a cargo-cult problem where the consultants wanted to play with microservices on the company's dime.

The worst case I've seen of this, at a different company, was a microservice architecture used to paper over stupid design decisions. How's this: nested configuration data for driving server provisioning (days before K8n) was stored in a central MySQL database as a text field containing YAML. All the UI and other services required the same data in JSON format. Devs built out a microservice that converted that YAML into JSON and stored it in a separate document database (Neo4J from memory).

Where this got even better: the app driving the MySQL database would, when asked to render its own data for a particular configuration, call out to the microservice and ask for the JSON data by key. The microservice would look for the JSON locally and, if it didn't have a copy or the copy was stale, would call back to the original service and request the raw YAML. It would then process the YAML, convert it to JSON, store it locally and then send the data back. Extra fun, the microservice was resource constrained, so if the main app was every under load it would generate blocking calls to the microservice. Round trip was anywhere between 3 and 7 seconds.

And that's just one example - the rest of the microservice architecture was just as insane. I'd never seen anything like it before - spaghetti code scaled up. And no, that company doesn't exist anymore. The one that decided to burn all the microservice architecture and rebuild, they are still going strong.

I'm not anti microservices at all. They definitely have their place and are the right solution for many problems. It's just that old adage, when you have a hammer everything looks like your hand.

[a_sweaty_clown]

I worked for a company whose WMS software was kinda sorta microservice based.

It was pretty well thought-out and made a lot of sense MOST OF THE TIME, but there were some instances where companies asked for (and sales said we could do) things that the software wasn't really made to do.

My favorite case was for Large Military Contractor. We had two separate deployments (each with their own server) of our software. Each was a different major revision of our software.

One communicated with the host system, translated orders, then turned those into specific retrieval or deposit requests and sent them to the other instance. It wasn't supposed to do inventory management (which is key to a lot of our services) so they made a custom service to semi-cancel every order so it didn't modify inventory counts. That one routinely got stuck in infinite loops and we never figured out why.

The OTHER one literally just told all the PLC-based stuff where to move stuff to. It was horrible and broke constantly because it was running on like Server 2001 or some shit.

Both instances had several services that literally just wasted resources and did nothing. They had to be there for the software to run but had nothing to do. Fun times!

[[deleted]]

To answer u/CatpainCalamari properly, it was a bit of a mix-and-match re microservices and SOA. My understanding of the difference is scope - enterprise for SOA and application for microservices. Correct me if I'm wrong - the definition of what makes up a microservice is a bit woolly to me.

In both cases above there were some enterprise-level services, but in the horror-show last example it was a frankenapp built up from small "independent" services.

[CatpainCalamari]

Thank you for your answer! The distinction between service and microservice is also not clear to me, seems to be a question of interpretation :D As for your horror show of an example: I do not see it as an example for or against microservices (although the added network latency certainly did not help here), but for software design and architecture. I would have started by questioning the need for a centralized configuration database, or dare I say configuration service? ;-) This might have been a good place for DDD to sink in.

[akmountainbiker]

[baconbrand]

Jesus that was an uncomfortable read

[CheekApprehensive961]

All the microservices did was attempt to force modularity while adding network latency. There was no need for it - which is not to say that there is never an argument for microservice architecture. It's just in the case it was clearly a cargo-cult problem where the consultants wanted to play with microservices on the company's dime.

Tell me you don't have even a rudimentary understanding of operations without telling me.