4 ms·

It would be nice to have some of those basic ideas that led to your thorough explaination of the pit falls of microservice development. What you write in this p

by emj 6y ago

It would be nice to have some of those basic ideas that led to your thorough explaination of the pit falls of microservice development. What you write in this post is too general, sure if you have to release your microservices as one mega monolith, then it feels like an easy choice. When your application is not suited for microservices there are still things that can be easier: updating dependencies because of security is usually easier if the whole code base needs it. So it all depends on the application, what kind of development work does it need in a ten year frame, etc. I really do not recommend big monoliths, but the most important this is that it should be easy to start development, that is usually easier with microservices. I feel your pain the automation really only starts to matter when you are above 40 services in my view.

lmilcin 6y ago
I am not talking about pitfalls of microservices, I am talking about pitfalls of people trying to do microservices. Microservices is not a single idea, but a point in a progression of maturity of various aspects of the application and the team developing it. Think about this, you don't get to be F1 driver just because you decide to. You need to spend a considerable amount of time preparing to be an F1 driver. If your manager (ie. yourself) decides to sit in F1 driver seat but disregards advice to first get years of experience before doing so, this is only going to end in a disaster. And it will not be "a pitfall" of F1 car. Obviously the problem are managers who misplace their focus. "Microservices" is a shiny object everyone wants to brag about but nobody wants to do the ground work necessary. So I see teams that don't even have repeatable build/deployment procedure want to do microservices. Why not have repeatable builds and deployments first? This is already going to improve the situation a lot and be basis for further development which may culminate, at some point, with microservices-style environment.

by emj 6y ago

lmilcin 6y ago

I am not talking about pitfalls of microservices, I am talking about pitfalls of people trying to do microservices. Microservices is not a single idea, but a point in a progression of maturity of various aspects of the application and the team developing it. Think about this, you don't get to be F1 driver just because you decide to. You need to spend a considerable amount of time preparing to be an F1 driver. If your manager (ie. yourself) decides to sit in F1 driver seat but disregards advice to first get years of experience before doing so, this is only going to end in a disaster. And it will not be "a pitfall" of F1 car. Obviously the problem are managers who misplace their focus. "Microservices" is a shiny object everyone wants to brag about but nobody wants to do the ground work necessary. So I see teams that don't even have repeatable build/deployment procedure want to do microservices. Why not have repeatable builds and deployments first? This is already going to improve the situation a lot and be basis for further development which may culminate, at some point, with microservices-style environment.