Maybe, but the increased development costs are incredibly high as soon as you move from a monolith, so much so that the deployment costs, no matter how large, will be dwarfed. For example, in my current setup, having a "mini" services architecture (typical monolith split up into three parts + supporting services) is probably costing us about 25% of our time. In other words, if we had a monolith, we'd be able to spend 3 extra months a year developing or refactoring that are now wasted in the slow development process that is caused slowly by the boundaries between applications.
You sure it's not the mainstream tools supporting microservices that are the problem? The E language, Fabric secure middleware, and even embedded on OKL4 with Camkes were straight forward. Small teams supported stuff like that because tools do almost all the work. It's like a modular, monolithic app with some parameters to tune and fault isolation.
Just seems like development, deployment, and support tooling could knock out issues people describe easily.
How is having microservices vs monolith increasing your development time? We have a lot of microservices, and I feel like having each piece of functionality silo'd with proper service boundaries only speeds up development.
* process request (equivalent to monolith db call above)
* send response back
* receive response
* decode response
Every single one of these steps needs to be debugged or at least tested every single time. Debugging itself becomes extremely difficult because you have to stop in one program and continue in another. You need a system for mocking data between the apps to reliably reproduce problems and debug them. There are problems that are silent between the two applications. You need to figure out a system for transactions. Or worse, distributed transactions. You have to deal with possibly sending out ridiculously huge amounts of data from app to app over a slow, unreliable network. You have to deal with service discovery. I could go on and on.
Every single one of these things adds complexity. For a small team or uncomplicated infrastructure (or both) this slows down the project immensely. That 25% that I'm quoting is from my current job and it's not overinflated. If you have enough people to handle it and your app is incredibly complex, then I have no doubt that your claims of speeding up development are true. If you're not at that scale/complexity, the opposite is true.
We are a small team working on something of moderate complexity.
We don't do a lot of request/response and most of our services interoperate asynchronously. The overall system is eventually consistent and we keep close tabs on the latency for changes propagating through the system. Different pieces have different latency requirements.
We don't have any services that exist solely to wrap a database -- in fact, most services read directly from databases. Updating them, however, is done by a single service.
We use S3 and Kafka as coordination points for large amounts of data.
We use DNS for service discovery.
Most information flows unidirectionally through the system. This + async everywhere means no race conditions.
The format of messages between systems changes very, very rarely. This is largely in part due to how we have segmented functionality -- most of the time, services just need to inform another service that some change or event has happened -- then the service itself contains all of the logic for what that means.
In any modern language there's going to be pretty battle tested libraries out there to handle requests/response/decoding/encoding for you. This is stuff that is almost never need to be debugged.
If you have a small team and uncomplicated infrastructure, you're only hurting yourself by moving to microservices. However, if developer synchronization problems make core changes to your monolith difficult and block the work of a ton of people regularly, your monolith takes minutes to build or start up, and you're already having to shard the data your monolith deals with across many datastores, then there's no definitely no developer tax to switching to microservices.
