Comments by "Stephen D Green" (@stephendgreen1502) on "The Thing No One Tells You About Microservices" video.

Autonomy truly is a big ask. It requires expert developers. If they leave, it requires that they be replaced with developers able to acquire expertise quicker than the previous devs could develop it, so work can continue autonomously. For example, an event gets raised by a microservice. No one team knows all the handlers for this event. Each only knows whether their microservice will handle it. So nobody sees the sequence of things that happen, nobody sees the big picture. So the devs need to be capable of understanding where their events and handlers fit in but without even knowing what the big picture is that are fitting in to. If they never get their handler completed, the event might never be handled, but nobody knows this. If a team needs a new dev to replace an expert who leaves, the new dev will not know if an event raised is ever handled. How can they find out? Go through all the codebases of all the microservices in various languages? What if these are moving targets and nobody knows all the codebases and which versions are in production? It all gets very taxing. Too taxing for an average dev. Autonomy is a really big ask.
11
Unattainable for many domains. What if multiple ‘microservices’ need to share a common login system? If the login system is a microservice too then how do you avoid coupling and maintain autonomy? It might seem possible, but for most developers it is not possible to do it well enough. One microservice might need a tweak to the way logins work to provide security for a new feature. They therefore need the login microservice to be changed. But how does a team change it without affecting other microservices? It is probably not attainable. Not in the real world. Too likely that a change will undermine autonomy and loose coupling. If microservices had to be strictly developed to retain that title, hardly anyone would be able to use them, except if their business is mostly about streaming like Netflix.
3
@ContinuousDelivery Thank you. Much appreciated. I feel a corollary here might be that databases break the microservices architecture. If your domain is not for a huge scale global userbase and if NOSQL is not strongly preferred over RDBMS in your system, steering clear of microservices is probably going to be a good choice.
3
@Tomaszevics Then you need to know about the other microservices in order to change the login service. That means the teams are not autonomous.
1
@jasondbaker that might cover one kind of coupling, but not all developers are advanced enough to know about the other kinds of coupling it would not cover
1
@adambickford8720 then every team needs to learn that JWT standard, all equally well. Still not autonomous, since one might want to do it differently or might think a different standard is bring used. What happens if a team loses its experts in auth standards and has to fall back on junior devs who are not knowledgeable in it.
1
@TheEvertw remember you have no control over the login service. It is autonomous. So the respective team develops it almost in isolation. Autonomous microservice by autonomous teams. Nobody gets to dictate as some kind of cross-service architect. That would break the autonomy.
1
@TheEvertw Is it a contradiction that we are forbidden to share a database yet the microservices share a queuing system? Seems so to me. A bit contrived.
1
@TheEvertw you cannot do without the database coupling if you need strong data consistency, as is needed in many domains and scenarios
1
@TheEvertw Or rather, not for domains and scenarios requiring strong data consistency. My original point.
1
@TheEvertw It is my job to make such a decision so I have to kick the tyres hard, so to speak.
1
@TheEvertw I worked with microservices technology in an SaaS system, high profile in public sector, for over a year and experienced the problems for data consistency. Now I am faced with people wanting to develop a similar system for much fewer users and a high requirement for data consistency and database-centricity. I already advised strongly against microservices. Now this video and comment threads have reinforced and confirmed it. But there is still strong determination to move in microservices direction so I need to be sure I have strong and well supported arguments.
1
@TheEvertw define wisdom - in this context
1
@ContinuousDelivery Did Martin even consider ACID and databases? Or is it a distributed implementation of pure function thinking, devoid of state, persistence, time, ‘side effects’ like that.
1