The Death of Microservice Madness in 2018
dwmkerr.com
The Death of Microservice Madness in 2018
1–10 of 469 posts
Re: The Death of Microservice Madness in 2018
#2I took his guide at the end and apparently we are supposed to do micro services, which is good, because we do as an engineering org of 800+ people.
Re: The Death of Microservice Madness in 2018
#3Highly appreciated if someone could summarize this. Thx
Re: The Death of Microservice Madness in 2018
#4I posted this a few days ago... I wonder why HN didn't keep the original post.
Re: The Death of Microservice Madness in 2018
#5https://en.wikipedia.org/wiki/Law_of_conservation_of_complex...
Broadly speaking, microservices make small, limited changes/update less complex, and large, sweeping changes/updates more complex.
This is why generalizations like "larger, established organizations [which make mostly relative small changes] should lean more to microservices than smaller, younger organizations [which make mostly relatively large changes]" hold true.
Re: The Death of Microservice Madness in 2018
#6I 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...
Re: The Death of Microservice Madness in 2018
#7I took his guide at the end and apparently we are supposed to do micro services, which is good, because we do as an engineering org of 800+ people.
And sadly some of us are doing them for no apparent reason with fewer than 10 people
Re: The Death of Microservice Madness in 2018
#8Best use I've found for microservices is highly isolated and well-defined stateless functions which make a significant (read compute intense) change to some data and drop it somewhere else e.g. image compression.
Now you can use this microservice anywhere and just change a few params in how you call it and you have avatars, thumbnails, etc.
Re: The Death of Microservice Madness in 2018
#9I 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 PW of the shared DB set in their project.
What do you guys think about such an approach?
Re: The Death of Microservice Madness in 2018
#10I 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.