That is the whole purpose of doing microservices. Every team can operate independently. Choose their tools, processes, etc. As long as they respect their API Contracts.
I think it's a misinterpretation of microservices to say that the purpose is that the teams can choose their tools and processes.
Microservices merely ensure that the complexity of using different tools per microservice does not lead to an increase of maintenance burden.
Nonetheless, you still have a maintenance burden if every microservice is built upon different tools and processes, since you cannot address patterns of problems easily that occur within combinations of patterns and processes. The cardinality just increases with every tool and process added into the mix.
This burden of maintenance automatically takes its toll on productivity. Teams will not be able to create, maintain or iterate on code that produces business value (as opposed to managing the platform of microservices itself)
I think there is value in a well defined set of processes and tools because there will eventually be platform concerns that become increasingly difficult otherwise.
I do not have insight in how most companies with successful microservice architectures achieved their success, but I would bet my life that a majority of those companies do not let their engineering teams use tools and processes arbitrarily, unless it serves to REALLY produce value that would be unachievable by the tools and processes used up until that point (for example, because performance is usually sufficient, but a specific service suddenly needs to outperform everything that came so far, so you use C, Go or Rust instead of Python)
I am biased into thinking this because I suspect that most of these companies did either start with monolithic architecture (i.e. supporting multiple languages was impossible or just not feasible enough) or they started with a microservice approach focusing on producing value as quickly as possible after an initial ramp up time. Supporting many different tools and processes from the get go would make the ramp up time longer than necessary.
TL;DR Microservice platform maintenance suffers if tools and processes are chosen freely for each microservice, without any push towards unification.
Oof I need to sleep. Don't mind me, just trying to sort myself out.
> I think it's a misinterpretation of microservices to say that the purpose is that the teams can choose their tools and processes.
The crucial feature of microservices is to enable large number of people to work on delivering the same service, but not being constrained by the traditional modes of software release, where the entire monolith could only be updated at a fixed cadence and where the whole thing had to pass through a rigorous suite of tests etc.
One freedom that this gives a team is to choose a different language for their service... on this point there is large consensus. But one need not stop there; you could technically run your service on another cloud with a completely different deployment architecture. All that is asked for this insane freedom is that your service honor the SLA's that you provide. SLA's define the interface, everything else is left to the team.
That being said, shared tooling does provide some nice benefits where learning is shared across teams allowing new ones to bootstrap quickly. However, that is something the team should be allowed to choose.
I understand this point of view is contrary to popular opinion. The justification of microservices is to allow a team of let's say 10 developers to scale to 100. What you do is create 12 teams of 8. Each team owns their microservice with well defined APIs, and are allowed some flexibility on languages, tools, process, etc. Of course, it is a good idea to leverage common tools and such, but not obligatory.
Commonly we see a team of 20 maintaining 40 microservices, which becomes very difficult to manage and provides little gains. IMHO, this si the wrong approach. Microservices are tiny from the point of view of Netflix, or Amazon.
cuddlecake|6 years ago
Microservices merely ensure that the complexity of using different tools per microservice does not lead to an increase of maintenance burden.
Nonetheless, you still have a maintenance burden if every microservice is built upon different tools and processes, since you cannot address patterns of problems easily that occur within combinations of patterns and processes. The cardinality just increases with every tool and process added into the mix.
This burden of maintenance automatically takes its toll on productivity. Teams will not be able to create, maintain or iterate on code that produces business value (as opposed to managing the platform of microservices itself)
I think there is value in a well defined set of processes and tools because there will eventually be platform concerns that become increasingly difficult otherwise.
I do not have insight in how most companies with successful microservice architectures achieved their success, but I would bet my life that a majority of those companies do not let their engineering teams use tools and processes arbitrarily, unless it serves to REALLY produce value that would be unachievable by the tools and processes used up until that point (for example, because performance is usually sufficient, but a specific service suddenly needs to outperform everything that came so far, so you use C, Go or Rust instead of Python)
I am biased into thinking this because I suspect that most of these companies did either start with monolithic architecture (i.e. supporting multiple languages was impossible or just not feasible enough) or they started with a microservice approach focusing on producing value as quickly as possible after an initial ramp up time. Supporting many different tools and processes from the get go would make the ramp up time longer than necessary.
TL;DR Microservice platform maintenance suffers if tools and processes are chosen freely for each microservice, without any push towards unification.
Oof I need to sleep. Don't mind me, just trying to sort myself out.
pm90|6 years ago
The crucial feature of microservices is to enable large number of people to work on delivering the same service, but not being constrained by the traditional modes of software release, where the entire monolith could only be updated at a fixed cadence and where the whole thing had to pass through a rigorous suite of tests etc.
One freedom that this gives a team is to choose a different language for their service... on this point there is large consensus. But one need not stop there; you could technically run your service on another cloud with a completely different deployment architecture. All that is asked for this insane freedom is that your service honor the SLA's that you provide. SLA's define the interface, everything else is left to the team.
That being said, shared tooling does provide some nice benefits where learning is shared across teams allowing new ones to bootstrap quickly. However, that is something the team should be allowed to choose.
huherto|6 years ago
Commonly we see a team of 20 maintaining 40 microservices, which becomes very difficult to manage and provides little gains. IMHO, this si the wrong approach. Microservices are tiny from the point of view of Netflix, or Amazon.