top | item 20465461

(no title)

seperman | 6 years ago

Not sure if I agree with you regarding the agile part. If each team owns their "micro-service", then they can have their own "sprints".

discuss

order

gitgud|6 years ago

Yes in very large systems that's true. But in the other systems, there's huge overheads which restrict systems from changing.

- Multiple execution environments

- Complexity in communication between services

- Managing the versioning of each service and it's dependent services.

Although services are easily to scale and change independently, they are hard to reconfigure globally, which means the application as a whole is hard to change...

seperman|6 years ago

There are pros and cons to the micro-services architecture. To your point it is not a black or white solution. Our systems are fairly large and over-engineered.

Often switching to microservices means reducing the complexity of communication between teams at the expense of increasing the complexity of communication between services.

budabudimir|6 years ago

What is the difference between each team owning a microservice and owning a part of the monolith?

There is common release process, but with proper infra in place, that shouldn't be a problem.

sheeshkebab|6 years ago

It all comes down to coordination and regression, which are quite complex in monoliths.

Suppose you'd like to push code change to production for your monolith - how do you know that someone else's change 1) is ready to to production together with yours 2) does not affect your module. Typically these can't be answered easily - and so release process is converted to manual testing and scheduled (and often slow) releases.

seperman|6 years ago

I was just disagreeing with "Microservices are almost completely opposed to agile development". You can be agile in both monolith architecture and micro-services. I don't see why microservices can be opposed to agile.