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 Death of Microservice Madness in 2018
11–20 of 469 posts
Re: The Death of Microservice Madness in 2018
#12I 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…
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
#13Latency 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
#14I 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 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
#15It'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
#16I 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…
This is already a smell. Usually, microservices don't need to access global state.
Re: The Death of Microservice Madness in 2018
#17I 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…
"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
#18I 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 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
#19I 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
#20I 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…
This might be fine, and maybe it could even be a good choice in your situation, but I would probably avoid the added complexity.