I don't think the argument that monolith should be the default is super compelling. If you are already answering "yes" to some of these questions you are likely to start benefiting in the short term from microservices - in particular for issues like "multiple teams own parts of the project and release at different cadences".
While the article mentions separate CI/repos/etc, that's not actually necessary or even super relevant to microservices. To my knowledge there is no real link between microservices and isolation of build/ deployment systems.
To me, the big issue with people adopting microservices is not understanding that it doesn't just mean SOA. If you just start splitting your service into multiple processes you gain some benefits, but you're going to incur huge overhead for releases - you probably have tons of shared code/ leaky interfaces. I think this causes most of the pain people have with microservices - and I think that a big part of people making this mistake is building a monolith (when they've answered "yes" to some of the proposed questions in the article) and then trying to split it later, often rushed, because that approach isn't going well.
Personally, my current side project is implemented using microservices. I rewrote one of them this weekend, and that service gets by far the most attention. I also use multiple languages, which is important and allows me to move really quickly (I fall back to Python for library support sometimes so that I can move faster). There's only a single shared library that virtually never updates (it's a fairly low level representation of a graph), and so I therefor virtually never have to worry about redeploying the world.
It's not perfect - I have to figure out how to deal with some of the downsides at some point, but I believe microservice-first was the right call. Oh and it uses a single repository, currently.
> you probably have tons of shared code/ leaky interfaces
Let's say that you have two microservices that work on the same business entity which is important to your application - eg, an invoice in an invoicing application. Not having shared code means that that you need to write from scratch all the code that deals with that entity for both services. If you later need to add some new attributes which are relevant to both services, you'll also need to independently update the code in both services, including the testing, and to do double the debugging.
If the services are really "micro", this will happen even more times for the same entity.
How can you do this without doing a lot more coding than if you had shared code?
Well, I think one answer is to add another service in front of that shared business entity that exposes an interface to match the domain of the consumers. Now the shared codebase should be a stable client.
But yeah, of course there's shared code between your codebases - things like JSON libraries, etc, are always going to be shared. The issue is more about what you're sharing - if it's a very stable, small library, it's probably fine. If it's something really core that's going to change a lot, or that two services may diverge in agreement upon, duplication may be worthwhile.
But this is really not any more useful than a monolith. You're applying a complicated criterion for something that should be simplifying my life, and now it's just making things harder in every services.
While the article mentions separate CI/repos/etc, that's not actually necessary or even super relevant to microservices. To my knowledge there is no real link between microservices and isolation of build/ deployment systems.
To me, the big issue with people adopting microservices is not understanding that it doesn't just mean SOA. If you just start splitting your service into multiple processes you gain some benefits, but you're going to incur huge overhead for releases - you probably have tons of shared code/ leaky interfaces. I think this causes most of the pain people have with microservices - and I think that a big part of people making this mistake is building a monolith (when they've answered "yes" to some of the proposed questions in the article) and then trying to split it later, often rushed, because that approach isn't going well.
Personally, my current side project is implemented using microservices. I rewrote one of them this weekend, and that service gets by far the most attention. I also use multiple languages, which is important and allows me to move really quickly (I fall back to Python for library support sometimes so that I can move faster). There's only a single shared library that virtually never updates (it's a fairly low level representation of a graph), and so I therefor virtually never have to worry about redeploying the world.
It's not perfect - I have to figure out how to deal with some of the downsides at some point, but I believe microservice-first was the right call. Oh and it uses a single repository, currently.