The Death of Microservice Madness in 2018 • Hacker News Board

Re: The Death of Microservice Madness in 2018

#21

Post by sk5t » Sun, Jan 21, 2018, 10:35 PM UTC

dvt wrote: post #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 mak…

> A microservice should generally not have side effects

I gotta ask, how is this realistic? A salient feature of most of the software I've worked on is that it has useful side effects.

Re: The Death of Microservice Madness in 2018

#22

Post by TekMol » Sun, Jan 21, 2018, 10:36 PM UTC

saryant wrote: post #17

TekMol wrote: 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. Evolvin…

How does an additional layer make changes to the DB easier? If a column is dropped what will your layer do when a request for data from that column comes in? What if the request joins it with other columns from other tables?

Re: The Death of Microservice Madness in 2018

#23

Post by krapp » Sun, Jan 21, 2018, 10:36 PM UTC

acd wrote: post #19

axelfontaine wrote: post #6

Earlier quoted context omitted.

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.

It wouldn't work - it's trivial to add meaningless query parameters or anchors that would change the hash but still lead to the same content. And stripping that wouldn't work because some sites use them to route to content.

What might work is hashing the text and outbound link content submitted pages of, and building something like a similarity index of text, metadata and a graph of links, but that would probably still be fragile, and definitely be too much effort for a site with as little traffic as this.

Re: The Death of Microservice Madness in 2018

#24

Post by TekMol » Sun, Jan 21, 2018, 10:38 PM UTC

fnbr wrote: post #10

TekMol wrote: 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's what I did for a recent side project. It worked really well, although coordinating the different services was a bit of a pain. We ended up using a cronjob to run everything repeatedly, which was inefficient but worked. If we had the time we would have used a proper RPC framework or some sort of queue.

What do you mean by 'run everything repeatedly'?

Re: The Death of Microservice Madness in 2018

#25

Post by toast0 » Sun, Jan 21, 2018, 10:39 PM UTC

TekMol wrote: 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…

Everything that accesses one table should be in one place. If you're sharing the database because you don't have enough use of the tables to justify splitting it up, that's fine. Do yourself a favor and create different MySQL users that can only access the tables needed.

If you're sharing the database because sometimes you want to access a table from the frontend and sometimes you want to access that same table from your backend layer, you're probably setting yourself up for pain later.

Re: The Death of Microservice Madness in 2018

#26

Post by TekMol » Sun, Jan 21, 2018, 10:39 PM UTC

buttscicles wrote: post #20

TekMol wrote: 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.

I would say it is less complexity then adding another API on top of the database.

Re: The Death of Microservice Madness in 2018

#27

Post by cookiecaper » Sun, Jan 21, 2018, 10:39 PM UTC

TekMol wrote: 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…

At the very least, each service should "own" its area of concern, which means only one application should ever write to the underlying structures, and those structures should support that application alone. What happens if you have an app that needs a certain setting on the database, but you can't restart to make it effective because 9 other apps are using the same DB?

It's hard enough to coordinate this kind of maintenance when there is only one OLTP-style user of the database. If you get a lot of interdependent units, where app A needs to read table B and app C needs to write to table D, it's nigh impossible to do it without global downtime.

"Microservices" require a large amount of control and discipline to implement properly. In almost all cases, a straight-up monolith ends up being much saner. "Microservices" are often seen as a license to run hog wild and disregard everything outside of one's immediate area of concern / team. This is convenient at the time because of Conway's Law, but it is terrible for long-term maintenance, overall consistency, and employee sanity.

Re: The Death of Microservice Madness in 2018

#28

Post by z3t4 » Sun, Jan 21, 2018, 10:39 PM UTC

If you can separate something out into it's own completely independent and reusable module, you should always do so. Also if something can scale by adding concurrency, that is often a good strategy. For example in conferences where every participant is supposed to talk, you can divide them into groups, so many people can talk at the same time but in small groups.

Re: The Death of Microservice Madness in 2018

#29

Post by dvt » Sun, Jan 21, 2018, 10:39 PM UTC

sk5t wrote: post #21

dvt wrote: post #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 mak…

> A microservice should generally not have side effects I gotta ask, how is this realistic? A salient feature of most of the software I've worked on is that it has useful side effects.

A microservice, imo, should just be a simple black box that takes in some input and returns some output (sometimes asynchronously). No side-effects necessary. No fiddling with database flags or global state, and definitely no hitting other microservices. See @CryoLogic's post for a good example. This means that you simply can't build some things using microservices -- like logging in a user -- and you'd be right.

Re: The Death of Microservice Madness in 2018

#30

Post by Floegipoky » Sun, Jan 21, 2018, 10:40 PM UTC

TekMol wrote: 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…

By most definitions of microservices I've heard there's a 1:many relationship between microservices:datastores. Multiple microservices can't talk to the same database. For example:

> While monolithic applications prefer a single logical database for persistant data, enterprises often prefer a single database across a range of applications... Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems https://martinfowler.com/articles/microservices.html

Not to say that pattern can't be successfully implemented, just that it wouldn't be considered microservices. It sounds like you're describing a three-tier architecture: https://en.wikipedia.org/wiki/Multitier_architecture#Three-t...