Live data from Hacker News

The Death of Microservice Madness in 2018

dwmkerr.com

11–20 of 469 posts

Re: The Death of Microservice Madness in 2018

#11
post #9

I have recently been thinking about doing microservices by simply having a shared MySql DB that all modules connect to. So for example one developer can create the backend and one developer can create the frontend. The codebases can be completely independent. One could use PHP+Laravel and the other one PHP+Symfony for example. Frontend and backend would live on their own servers. And simply having the IP, login and P…

That sounds like the integration database pattern and it's generally not considered service-oriented (of which microservices is a subset).

Re: The Death of Microservice Madness in 2018

#12
post #9

I have recently been thinking about doing microservices by simply having a shared MySql DB that all modules connect to. So for example one developer can create the backend and one developer can create the frontend. The codebases can be completely independent. One could use PHP+Laravel and the other one PHP+Symfony for example. Frontend and backend would live on their own servers. And simply having the IP, login and P…

(Written quickly on my phone)

Issue ends up being how to keep applications from ruining assumptions made in other services. There’s no single code base which you can walk through and see possible changes.

At that point this isn’t making things easier to understand or maintain so it’s not the best approach.

Re: The Death of Microservice Madness in 2018

#13
Agree with the author that Microservices are harder to operate in certain aspects. For example latency tracing with Microservices is harder when you have many services to check latency through, what service call caused the latency. Doing error tracing with Microservices is also harder because now you have to follow a web request through many different Microservices. Microservices in some cases may have worse performance than a monolith. With Microservices data no longer does in local memory or local cache, you have to traverse the network through an API calls to fetch data. Imagine that you have a monolith that can look up data in a hash table that is one memory/cache access versus a micro service network call. In the micro service you have to make a network call for a memory lookup. A memory access may take between 0.5ns-100ns versus a network call may take 10000ns. That Microservices may be between 20000 times to a 100 times slower accessing remote memory in another Microservice than accessing it locally in the same monoliths memory. Thus one could argue that in some cases performance are worse with Microservices than a monolith. You can still scale stateless monoliths buy putting a load balancer in front of the monolith. There is also increased overhead of running Microservices, instead of having one Java process/NodeJS process for a monolith you may have several hundred nodeJS processes Microservices running in Docker containers. Each NodeJS process takes memory for NodeJS itself. An important aspect of Microservices which are good is that they allow a part of the system to be restarted independently instead of restarting a whole monolith. https://radlab.cs.berkeley.edu/people/fox/static/pubs/pdf/j0.... Sometimes you may want to rewrite a component that is also much easier to rewrite with Micro services. Compare a Mainframe from the 60s-80s running a monotlith without unit testing / integration testing versus modern micro services with testing. Replacing parts or the whole main frame monolith will be very very scary.

Latency Numbers Every Programmer Should Know https://gist.github.com/jboner/2841832

However I would argue Microservices has been done before the idea is not new. Microservices is a realization of the same principle as that of UNIX/Linux. This is called the UNIX philosophy, Write one program that do one thing well. Make the output of one program the input of the other one.

Microservices are not a new idea, its the reimplementation of the UNIX philosophy for the web.

The UNIX philosophy https://en.wikipedia.org/wiki/Unix_philosophy

"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features"." compare with Microservice definition by wikipedia "The services are small - fine-grained to perform a single function."

Improving reliaility with recursive reboots, Microservices on Kubernetes are at least implementing micro reboots in case of component failure. https://radlab.cs.berkeley.edu/people/fox/static/pubs/pdf/j0...

Like most tech Micro services probably follow the Hype cycle https://en.wikipedia.org/wiki/Hype_cycle

Re: The Death of Microservice Madness in 2018

#14
post #9

I have recently been thinking about doing microservices by simply having a shared MySql DB that all modules connect to. So for example one developer can create the backend and one developer can create the frontend. The codebases can be completely independent. One could use PHP+Laravel and the other one PHP+Symfony for example. Frontend and backend would live on their own servers. And simply having the IP, login and P…

I think that sounds like a bad idea. I could see pain arising from the shared usage of the database -- e.g., during migrations or heavy usage. I'm not really sure what the benefit is, either: each team will likely want to be the owner of their own database anyway.

If you're talking about the separate microservices using the same tables in the database, that's probably an even worse idea. Either your services are way too tightly coupled, or shouldn't have been split into separate services in the first place.

Re: The Death of Microservice Madness in 2018

#15
Biggest issue with microservices: "Microservices can be monoliths in disguise" -- I'd omit the can and say 99% of the time are.

It's not a microservice if you have API dependencies. It's (probably) not a microservice if you access a global data store. A microservice should generally not have side effects. Microservices are supposed to be great not just because of the ease of deployment, but it's also supposed to make debugging easier. If you can't debug one (and only one) microservice at a time, then it's not really a microservice.

A lot of engineers think that just having a bunch of API endpoints written by different teams is a "microservice architecture" -- but they could't be more wrong.

Re: The Death of Microservice Madness in 2018

#16
post #9

I have recently been thinking about doing microservices by simply having a shared MySql DB that all modules connect to. So for example one developer can create the backend and one developer can create the frontend. The codebases can be completely independent. One could use PHP+Laravel and the other one PHP+Symfony for example. Frontend and backend would live on their own servers. And simply having the IP, login and P…

> shared MySql DB

This is already a smell. Usually, microservices don't need to access global state.

Re: The Death of Microservice Madness in 2018

#17
post #9

I have recently been thinking about doing microservices by simply having a shared MySql DB that all modules connect to. So for example one developer can create the backend and one developer can create the frontend. The codebases can be completely independent. One could use PHP+Laravel and the other one PHP+Symfony for example. Frontend and backend would live on their own servers. And simply having the IP, login and P…

I've been down that road. Eventually it turns into a nightmare because evolving your DB means making simultaneous changes to multiple applications.

"We think we can drop this column, someone figure out which of our eight apps using this DB might be using it still"

I much prefer putting a single service layer in front of the DB that speaks thrift or protobuf and letting all clients interface with that instead. Evolving thrift services is fairly straightforward and allows you to make changes without needing every app the keep up.

Re: The Death of Microservice Madness in 2018

#18
post #9

I have recently been thinking about doing microservices by simply having a shared MySql DB that all modules connect to. So for example one developer can create the backend and one developer can create the frontend. The codebases can be completely independent. One could use PHP+Laravel and the other one PHP+Symfony for example. Frontend and backend would live on their own servers. And simply having the IP, login and P…

The problem is the codebases are still not "completely independent".

If the backend dev needs to change a field in the database, or add a new one, then can might affect the front end dev.

Also - simple things like validation rules - i.e. what can the front end dev allow users to store into the DB vs what can the back end dev use/need.

Re: The Death of Microservice Madness in 2018

#19

I posted this a few days ago... I wonder why HN didn't keep the original post. https://news.ycombinator.com/item?id=16159589

This is the 9th time it's been posted: https://hn.algolia.com/?query=The%20Death%20of%20Microservic...

An improvement to the Hacker news website would be to compute and compare hashes of weblinks so that the same link is not reposted multiple times. Later posters of links could then be redirected to the first post of a link.

Re: The Death of Microservice Madness in 2018

#20
post #9

I have recently been thinking about doing microservices by simply having a shared MySql DB that all modules connect to. So for example one developer can create the backend and one developer can create the frontend. The codebases can be completely independent. One could use PHP+Laravel and the other one PHP+Symfony for example. Frontend and backend would live on their own servers. And simply having the IP, login and P…

If multiple services are coupled to the same database schema then any changes to the schema must be coordinated between all services, so you've got something of a distributed monolith instead of a set of independent microservices.

This might be fine, and maybe it could even be a good choice in your situation, but I would probably avoid the added complexity.

Post reply on HN