How to decide whether to adopt a micro services approach

Question

TL;DR - What criteria should you use to decide whether to 'do micro services'?

I lead a team of developers and one of them insists that we adopt a micro services approach to architecture. I was hesitant at first, because I had been coding under a rock for several years and never knew that micro services was a thing.

I began to warm up to the idea but I still don't think that a micro services approach is warranted in our case. We won't ever be servicing millions of users and there's only 5 of us so it's not like we're going to have full teams dedicated to such fine-grained services.

We have a web based network management portal that we build and maintain. There are number of other applications that handle different things like VOIP call billing, Netflow collection, SNMP based usage collection etc. I wouldn't call these micro services as they're a bit more coarse than the fine-grained responsibilities that micro services appear to have.

Should all dev teams everywhere 'do' micro services? If not, how do you decide whether micro services are appropriate for your environment?

Answer 1

If not, how do you decide whether micro services are appropriate for your environment?

Simply via pain. It sounds unusual, but is from my perspective a valid indicator, that something is going wrong.

If you look at the reasons, why microservices are all the rage, there is a historical dimension to it which plays a big part.

Usually succesful projects go like this:

1. Start with a prototype

2. Flesh out prototype

3. Get business going

4. Enormous growth which results in

   a. A big number of features are cranked out

   b. Codebase growth beyond control

5. PAIN starts: scheduling of deployments become a nightmare, dependend subsystems could not be deployed separately

6. RELIEF Microservices FTW

Dividing the whole codebase in easy deployable components.

The question you are asking is a good indicator, that you are not experiencing pain on such a level, that it would be necessary to move to microservices.

Doing microservices is not without a price. Your system will definitively increase in terms of complexity.

• When you have a monolith, your world is plain simple: »Call a method, do stuff, get results after a precalculatable amount of time«

• When you are dealing with microservices, you jump right into the mud of distributed systems: »Call me maybe« Things which are certain in a monolith, become uncertain in a microservice world.

The reason, why the microservice approach was chosen by many big companies is simple: dealing with the problems of distributed systems was simpler than scaling their monolith.

Of course: from an architectural point of view, a bunch of separated units looks cleaner (on paper) than a hairball of a monolith.

I lead a team of developers and one of them insists that we adopt a micro services approach to architecture.

I would ask him what would change (better or worse) in your concrete scenario.

We won't ever be servicing millions of users and there's only 5 of us so it's not like we're going to have full teams dedicated to such fine-grained services.

I do not see a (direct) problem here. Splitting up your codebase into separate deployable parts has nothing to do with team size. The codebase as such would be nearly the same. If your team handles the codebase now, it should be possible to do it after the migration. What is necessary, besides splitting up the codebase, is: educating your team in terms of how to deal with problems of distributed systems. This is an investment to make.

We won't ever be servicing millions of users and there's only 5 of us so it's not like we're going to have full teams dedicated to such fine-grained services.

I wouldn't call these micro services as they're a bit more coarse than the fine-grained responsibilities that micro services appear to have.

Microservices have nothing to do with millions of users - though with problems of deploying a codebase facing a million of users. More: Despite the term »micro«, the "services" must not only be 100 Lines long or so - which is one, but not the only reason for calling it "micro".

I like the term »focussed service« much more. That's what it is: in terms of »separation of concerns« such a service deals with one topic.

---

tl;dr

If you do not have any problem running your current system, you shouldn't make a switch.

Answer 2

Should all dev teams everywhere 'do' micro services?

Despite the benefits of the Microservices architecture, the answer is of course, not everyone should.

If not, how do you decide whether micro services are appropriate for your environment?

That's hard to answer, because any architecture is the technical response to a political -strategical- question. The company business strategy matters here, so, the decision should not be a mere question to resolve among developers.

I suggest reading Martin Fowler's post about Microservices. Also reading the links. They worth the read.

Reading about Microservices' strengths, you might get the answer to your main question: What criteria should you use to decide whether to 'do micro services'?

Usually, the microservices as architecture fits well in complex systems.

Complexity is defined by different bounded contexts. Like business units that could operate and evolve independently from each other, but they achieve a common goal working altogether.

The complexity of the system is not caused by the unitary complexity of each "bounded context". It's caused by the need of having to get rid of all of them in the same solution.

A bounded context can be as simple as: user's management, registration, invoicing, reporting, event tracking, security (authentication and authorization), ...

That being said, it doesn't mean that small projects should not adopt this architecture. As usual, it depends on whether the gains outweigh the implicit costs. And overall, if it responds to a real need.

I would take in account -seriously- the trade-offs described in the article linked above:

• The extra baggage of managing this kind of systems, reducing the productivity
• The knowledge (in deep) of the domain (microservices)
• The development complexity
• The company capacity to manage:
  • Rapid Provisioning
  • Basic Monitoring
  • Rapid Application Deployment
  • Devops Culture

Finally, getting involved any stakeholder in the company is a must. Just to assure that everyone know the implications.