4 ms·

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 sil

by mej10 11y ago

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.

mvc 11y ago
Do you work on more than one in a given week? How do you test a feature which requires co-ordination between several of your services?
joesmo 11y ago
Here's an example of equivalent operations: Monolith: * make db call Microservices: * send request * receive request * 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.
- jeffasinger 11y ago
  I don't really buy this. 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.
- mej10 11y ago
  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.

by mej10 11y ago

mvc 11y ago

Do you work on more than one in a given week? How do you test a feature which requires co-ordination between several of your services?

joesmo 11y ago

Here's an example of equivalent operations: Monolith: * make db call Microservices: * send request * receive request * 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.

jeffasinger 11y ago
I don't really buy this. 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.
mej10 11y ago
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.