In practice, this assumes that all of the concerns presented there will necessarily become bottlenecks. And that is simply not true.
You can have modules with completely different deployment lifecycles, speed of development and performance characteristics as part of a single service and, for the most part, things will be totally fine.
This really reeks of premature optimization. A badly separated service is a gigantic hassle down the line.
In general, service boundaries become obvious to developers when they start seeing the friction. But the default answer should always be a no unless there is proof that friction is there. The overhead of maintaining multiple services, repos, CIs and so on is not trivial for s team of 10 people or less.
>The overhead of maintaining multiple services, repos, CIs and so on is not trivial for s team of 10 people or less.
This is why the big guys use mono repos. It makes it trivial to split off services from a code perspective. You still need to manage the ops but if it's code that could have run in another service the ops is mostly a copy/paste of an existing deployment.
As for knowing where the service boundry is, that's something that can evolve just as easily as is does in a monolith codebase. Sometimes your class structure is right and sometimes you need to retool it. It shouldn't be the end of the world to update an internal service.
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.
It really is trivial to automate the process of creating a new service with a corresponding repo and CI pipeline. And with tools like giter8 it's not that hard to standardise on service layout and components as well. You could easily do it in a few hours.
Likewise just using modules looks good on paper but in practice most languages make it too easy to reference code in other modules. And so very quickly you end up with spaghetti code. So regardless of whether you use modules or services you still need to do a lot of upfront work in setting and enforcing some design/architectural rules.
Agreed. We built cookiecutter templates at edX for the basic Django service and Ansible playbook. We built shared libraries for OAuth and other shared functionality.
That said, much of this did not come into place until we were on the third microservice. Starting with templates and libraries for the very first service would have definitely been premature optimization, and have resulted in wasted time and later rework.
It's just as easy to create spaghetti with microservices. Circular dependencies all over the place. Discipline is discipline no matter what you use. Microservices just make lack of discipline harder to fix.
In practice, this assumes that all of the concerns presented there will necessarily become bottlenecks. And that is simply not true.
You can have modules with completely different deployment lifecycles, speed of development and performance characteristics as part of a single service and, for the most part, things will be totally fine.
This really reeks of premature optimization. A badly separated service is a gigantic hassle down the line.
In general, service boundaries become obvious to developers when they start seeing the friction. But the default answer should always be a no unless there is proof that friction is there. The overhead of maintaining multiple services, repos, CIs and so on is not trivial for s team of 10 people or less.