I'm so sick of microservice architecture... in theory it was going to make scaling elastic and deployment easier. In reality it seems to slow productivity to a 🐌 pace.

Anyone have any brilliant suggestions on how to herd these cats in production?

What kind of architecture do you work with?

@Jifuna A lot of different frameworks, but primarily Java/Springboot, Node/Express, and some select golang and rails apps (from various teams and companies). That's part of the madness itself, I suppose.

Microservices are not perfect but still better than deploying all servers in one machine. Maybe the future will greet us with a more brilliant technology

I have a suggestion, *dont* use micro-service arch. Its only worth it if you're literal facebook or netflix. For most projects its gonna force you to maintain data integrity across multiple databases and copy models across multiple code bases. The real problem is that people try to split everything into services, even things that are supposed to be coupled. You really cant decauple your User from your Bills or HotelRooms or whatever. Thats not how its supposed to be. You can however decouple lets say a payment gate from your Rest. Or similar. Things that *dont* need to communicate often and only perform big whole times and are not being maintained during the same developement cycle. And those kinds of services are sparse. For most projects you only need 1 or 2, but that makes people feel like they are not using microservices at all -_- so they break everything apart and make one for almost every entity

@Hazarth this exactly! I advocate for one giant monolithic service if that's all we need... Otherwise it's just "we heard microservices are the hotness, so we're doing all the decoupling for web scale"

When is the time to move from monolith to micro-service? Facebook and Netflix may have that architecture now but when did they move (I remember a Netflix talk on how they did it)? How big were they when they did it? Did they need to or just planning for the future? Should startups plan for the future for their aspiration of becoming as big as Facebook or Netflix? Or should they stick with monolith and know that one day their architecture will need to change if they are successful?

At which point does it slow you down?

@netikras when making a multi-service change. If you change an object at both the sending and receiving end that means you have to deploy them simultaneously to test your change. When you change three services, a database schema, and the front end you're relying on unit tests in hopes they'll all work together at deployment time.

@stisch is jenkins also struggling at this point? Never had such issues... Autodeployment and testing pipeline, incl IT, usually covers every possible caveat, unless your jenkins scripts aren't at its best...
And for prod deployment -- blue-green does the job perfectly.

Where is your jenkins struggling?

You are right, in practice, microservice architecture does not work as perfectly as we would like, and I have seen many projects where it stops development productivity. The article https://alpacked.io/blog/... talks about some of the disadvantages of such an architecture