|
I don't really see what this article nails. So, if I understand the argument correctly. Microservices were used to increase development speed. While old pieces were left behind (legacy) new systems have come up to modernize (these are still microservices)? His team, now responsible for many, legacy unloved old microservices, are being merged back into a monolith. The real question is, is remerging all the code back into 1 application the right solution for their problems they had with stability. I think mental models are important, and having a huge blob of unrelated roles, makes sense to the current development team. But won't, just like the old situation, to the new developers. Perhaps it's just the clickbait article, but a better title would have been. "Homogenizing our wild-west legacy microservices". For me personally microservices was a god send, working on getting stuff done, instead of dealing with ancient code that doesn't reflect the current business anymore. I still buy in the thought of, if you can't develop a great monolith, you sure won't be great at building microservices.
modular-monolith is the cool thing currently. Create a Monolith, without the shortcuts that create problems in the long run. Public interfaces are your most valuable pieces in the system. Worship them, code-review them, fight about them. Currently I could care less about the implementation itself. Does it solve our problems, is it fast enough, is it tested great, ship it. What language you used, architecture. database, I don't care. Just make sure it's a joy to use from the outside. If more developers would spend longer on thinking about the problems and less with throwing large amount of code that makes them feel smart. Making a microservice doesn't fix that problem. Think that what is missing is the stability that microservice are able to give in its most optimal form. Each service being the main source, the second it leaves the system it is stale reference data. Is stability important? use the old reference data, how fresh does your data really needs to be. |