Thank you Praneeth :)
TBH, we are moving now in another direction. We will reduce the number of services and make them appropriate size. Plan is to have super-clean pipeline for each of them without too much "magic".
Maybe you should also take that into consideration.
Maybe you shouldn't try to resolve a problem that shouldn't be there in a first place.
Choose your "weapon of choice" wisely :)
I think this is a cool solution. But I have a question is how you deal with it now, do separate pipelines work better, how you set them up for monorepo?
This is a geeky solution :) Since I left the company, I can only tell you what I suggested to the Team - think very thoroughly what should be in one logical service and then put that in one repository.
Create CI/CD on top of it for each deployment unit (physical service), if you have more than one at all; make it simple, fast, have great unit tests.
If currently several services just handle some parts of the same domain, make 1 service out of them with modules (dev.to/nikolicbojan/your-clean-arc...)
In general - I went with monorepo due to the fact there was a small team handling a lot of services. Thing is that there was no need for so many services in the first place. I didn't tackle the entire problem, I swapped it for a smaller problem to enable Team to work faster, but that was not a complete solution.
TBH, I am thinking about deleting this article or at least putting a big warning sign on the start that this was an experiment that proved not to be a great solution :)
Hello and thanks for the share.
Can you elaborate a bit more about the fact that it's not a great solution.
Today, we have a micro service architecture tiddly bound and we are doing PR in 30 min (build / quality / iac / deployment). It's a way too long and building / testing only what has been touched in the context of the PR seems to be the only way to go...
Hi Cedric, sorry for late response - vacation :)
Building just the things that changed is the way to go, but I no longer think it is good to have one repository and one complex build script that is aware of too many things.
If you have properly separated services, put them in the separate repositories and create CI and CD for each. Treat them as truly separate.
In the meantime, I found a YT channel that has majority of answers I learnt the hard way explained in a small 10 minutes videos - youtube.com/channel/UC3RKA4vunFAfr...
Hi Cedric, I was not referring to a particular video as Derek talks a lot about interesting subjects like Architecture, Loosely coupled monolith, CQRS...
I do not know how many services do you have, how they are communicating, etc. and therefore I think these short lessons from Code Opinion could give you some interesting ideas.
Maybe you can reduce number of services (if you have too many and struggle) by making them more coarse grained? Maybe you have somewhere sync communication between them, that should be avoided, for sure. Maybe... to many unknowns :)
Hope you will find there some good explanations. BR!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is gold mine of an article (i went through the process of password reset, just to leave this comment)
Thank you Praneeth :)
TBH, we are moving now in another direction. We will reduce the number of services and make them appropriate size. Plan is to have super-clean pipeline for each of them without too much "magic".
Maybe you should also take that into consideration.
Maybe you shouldn't try to resolve a problem that shouldn't be there in a first place.
Choose your "weapon of choice" wisely :)
I think this is a cool solution. But I have a question is how you deal with it now, do separate pipelines work better, how you set them up for monorepo?
This is a geeky solution :) Since I left the company, I can only tell you what I suggested to the Team - think very thoroughly what should be in one logical service and then put that in one repository.
Create CI/CD on top of it for each deployment unit (physical service), if you have more than one at all; make it simple, fast, have great unit tests.
If currently several services just handle some parts of the same domain, make 1 service out of them with modules (dev.to/nikolicbojan/your-clean-arc...)
In general - I went with monorepo due to the fact there was a small team handling a lot of services. Thing is that there was no need for so many services in the first place. I didn't tackle the entire problem, I swapped it for a smaller problem to enable Team to work faster, but that was not a complete solution.
TBH, I am thinking about deleting this article or at least putting a big warning sign on the start that this was an experiment that proved not to be a great solution :)
Hello and thanks for the share.
Can you elaborate a bit more about the fact that it's not a great solution.
Today, we have a micro service architecture tiddly bound and we are doing PR in 30 min (build / quality / iac / deployment). It's a way too long and building / testing only what has been touched in the context of the PR seems to be the only way to go...
Hi Cedric, sorry for late response - vacation :)
Building just the things that changed is the way to go, but I no longer think it is good to have one repository and one complex build script that is aware of too many things.
If you have properly separated services, put them in the separate repositories and create CI and CD for each. Treat them as truly separate.
In the meantime, I found a YT channel that has majority of answers I learnt the hard way explained in a small 10 minutes videos - youtube.com/channel/UC3RKA4vunFAfr...
Are you referring to a specific video in the channel ?
Thanks for your answer !!
Hi Cedric, I was not referring to a particular video as Derek talks a lot about interesting subjects like Architecture, Loosely coupled monolith, CQRS...
I do not know how many services do you have, how they are communicating, etc. and therefore I think these short lessons from Code Opinion could give you some interesting ideas.
Maybe you can reduce number of services (if you have too many and struggle) by making them more coarse grained? Maybe you have somewhere sync communication between them, that should be avoided, for sure. Maybe... to many unknowns :)
Hope you will find there some good explanations. BR!