4 ms·
"Not only were the various teams all competing for the same deployment resources, it meant that every time an "Incident" was declared, several teams' code had t
by kovac 6y ago
"Not only were the various teams all competing for the same deployment resources, it meant that every time an "Incident" was declared, several teams' code had to get rolled-back; and, no team could deploy while an incident was being managed."
So, how exactly did switching back to monolith solved the above problems? Seems to me like your actual problem is in QA and managing releases than application architecture whether it's towards or away from microservices. What I'm hearing is that you decided to fallback on relying on people to not push broken code out to production. Which is fine and all but what are you going to do if your team grows again? Rearchitect the system into microservices? A little heavy handed don't you think? In your particular case, I think, be it monolith or microservice architecture you need to work more on improving QA and streamlining releases. These, once automated, don't depend much on the number of developers. I've experienced this with a team of 3 as well as a team of about 15 (not 30 though). I don't think that the application architecture has anything to do with your problems one way or the other.
Having said that, if the late night calls stopped after this exercise, then that's fine because no one should have to go through that!
- jdlshore 6y ago> So, how exactly did switching back to monolith solved the above problems? It seems that you didn’t read the whole article, but instead rushed to express your superiority. Switching to a monolith helped because they are a single team maintaining multiple services. Combining the services reduces their overhead. The deployment problems haven’t recurred because their team is the only one deploying the monolith (or at least, that’s what’s implied.)
- kovac 6y agoI did read the article. Saying your now small team to be "careful" is not a real solution which I mentioned in my comment. What do you mean by expressing my superiority? Expressing my opinion backed by my own professional experience which happened to disagree with your own?
- bobthebuilders 6y agoIncorrect.
- kovac 6y agoEloquent. So... we should change application architectures as the team changes size?
- jdlshore 6y agoThat appears to be what the article is suggesting.
- PeterisP 6y agoTeam size and structure definitely is relevant, as many of the main arguments for or against specific architectures are about how it makes certain developer processes faster or safer or easier or more predictable; so yes, it seems reasonable that the most appropriate architecture would change as the team changes size - though it does not mean that we should change the architecture, as the benefit may not be worth the cost of change.
- kovac 6y agoChanging a system architecture twice like this, specially to go back to what it was before is a large cost to a company. In this line of thinking, they may have to move back to a microservice if they had a bigger team for the exact same application! This is fine by me, but rather than what other benefits they enjoyed by migrating the second time, a clear analysis of motivations behind moving to microservice and then back to monolith without compromising the benefits attained by doing the first migration would be a lot more enlightening. Because I don't imagine the first migration to microservices happened just because they had too big a team. I suppose this thread will naturally attract people who hate microservices in principle. Logic: Because of microservices, we had bugs (okay, what kind of bugs?). Therefore we moved back to a monolith again (why did they use a microservice architecture in the first place). Then the bugs disappeared (how?) and we got a whole bunch of other benefits as a bonus (any trade offs?). Cool, so the initial migration to microservices must have been done by complete idiots then. It seems that even to question that is too much here.