4 ms·
I was one of two developers who built a large micro-service system from scratch. It was the correct way to do it given the requirements and limitations. The dev
by bszupnick 7y ago
I was one of two developers who built a large micro-service system from scratch. It was the correct way to do it given the requirements and limitations. The dev-ops overhead was HUGE. Handling multiple repositories, versions, version-dependencies, documenting/coordinating changing APIs between the micro-services.
Even something as simple as having 12 different repositories meant 12 different Bitbucket pipeline yaml files and there was no way for repos to share pipelines. So one change meant 12 changes.
It was good experience, and HAD to be done in that type of architecture, but keeping it all organized was a challenge.
- spand 7y agoCan you elaborate why it had to be done that way ?
- yonl 7y agoOne of the major overhead for me was writing tests. I used to get so frustrated because there are so many, so many things to mock / stub. Do you have any suggestions for testing (Mostly service API testing) ?
- coverj 7y agoI'm only probably a month ahead of you but with my research and initial testing I've liked https://stoplight.io/open-source/prism/ https://stoplight.io/open-source/prism/ so far. There are a lot of other options out there too if you are willing to make a swagger/open api spec
- asplake 7y ago12 repositories between 2 developers? Why?
- klohto 7y agoMonorepo is the answer
- PopeDotNinja 7y agoSeeding the N databases for each microservice is quite the pain, too.
- 2T1Qka0rEiPr 7y agoI'd also be interested to hear why it was the right choice still? But, you hit on a good point with all of the bootstrapping which needs to be repeated. And then with each subsequent change you make to your pipelines (e.g. testing frameworks) either becomes inconsistent or you have to apple the same changes in N places instead of 1.