Microservices are almost completely opposed to agile development. They require a strong architecture before implementation and are much harder to reconfigure regardless of versioning. The running system is also hard to manage.

Microservices are typically an organizational rather than technical feature.

If each team are given their own microservice to manage the way they choose, things can work smoothly.

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".

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...

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.

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.

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.

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.

I think the only reason it might be hostile to agile is if your interface keeps changing (api other things contact it with, or what it contacts others via)

But if those things are constantly in flux, it really isn't a good candidate for splitting into a microservice in the first place.

How is it easier to on-board new engineers? You mentioned but did not explain this point.

Easier to on-board in the sense of limiting what new engineers can see, only giving them smaller pieces of access.

Otherwise it's probably the opposite, takes a lot longer for new engineers to understand the full system. Perhaps even reduces the bus factor, since less people understand all the moving parts.

Exactly. I could not have explained it better than you.

That can be done with libraries.

We do use libraries as much as possible. However we avoid putting business logic into libraries.

How many engineers do you have and what's your growth in manpower like?

Our entire product, engineering, data science, design org is around 80-90. Engineering is about 50-65% of that.

But search/merchandising is a small fraction of the team. We have 2 dedicated backend engineers on the search team.

We are growing rapidly. We are aiming to double the size of the eng org in the next 8 months.

Cool, thanks for sharing. So is your micro-service architecture you described in your article for the 2 engineers or the 40? Asking because 40+ doubling to 80+ seems like a great fit for Micro-services, but 2 people, eh, not so much, IMO.