4 ms·

I'm curious, how would microservices architecture make the application faster? In my experience monoliths are faster (but they are indeed a pain to maintain) -

I'm curious, how would microservices architecture make the application faster? In my experience monoliths are faster (but they are indeed a pain to maintain) - instead of making the rpc request with all the overhead it implies, you can just pass objects in memory directly!

gt565k 11y ago
Microservices allow you to scale individual components of your system and reduce technical debt by isolating them. Say you have services X, Y, and Z. Service Z handles a lot of traffic and is becoming a bottleneck to the whole system. You spin up 2-3 more instances, throw a load balancer in front of them, and increase throughput, all without ever touching the rest of the system. Pretty seamless! In addition, monolithic systems tend to be a pain in the ass for release cycles. Microservices allow you to very easily bring components up and down and do zero down time deploys by using a load balancer. Using our previous example, consider doing a release 2.0 for service Y. You spin up an additional instance of service Y with version 2.0 and the old instance is running version 1.0. You take the old instance out of the load balancer and stick the new one in. With the flip of a switch, your end user ends up using version 2.0 of service Y, without ever having to bring the system down. Now obviously microservices aren't the right design decision for every application. But as your system grows and uses different components, it's usually best to separate them out as individual services so that you can scale horizontally using load balancers.
djur 11y ago
A well-optimized monolith is going to be faster, but a less monolithic codebase makes certain bad decisions much more painful. If you know you have to make an RPC call of some sort to access a given resource, you're going to be more careful in how you access it; if you don't, you're going to have unusably slow and brittle software much faster than you would in a monolith. So you end up being forced to optimize earlier, and the process of optimizing a single small component is generally simpler (you can profile just that process, for instance). That said, there's nothing keeping you from gaining many of the same benefits from a well-disciplined, modular monolith, and I think there's a pretty high risk of a fast-moving and over-stressed team (like a lot of startups) being put under more stress by the time and complexity costs of microservices, and thus making much worse decisions than they would on a monolith.
dcre 11y ago
When things are "a pain to maintain," code gets worse and worse over time. Performance then suffers because no one understands what's going on. In other words, I believe that in the long run, complexity is a far bigger performance risk than technical overhead like how long it takes to make a web request. It's much easier to optimize away those kinds of problems away than to make an awful codebase understandable. In practice, I see service architecture as a way of making people think harder about how different parts relate to each other.
StavrosK 11y ago
They don't. They just force less disciplined devs to incur less technical debt by making interfaces inviolable. Personally, it would take a lot for me to switch a part of my monolith to a microservice and lose the speed of having everything done in the same process and the guarantees that having a single relational database offers. Having to reconcile data that got off sync because it was in two different data stores is not fun for anyone, and, to me, it's not worth it just to force yourself to not call any private methods on the other service. I just expose a public ABI and say "to interact with this part of the application, you may only call these functions here".
- gt565k 11y ago
  You can use the same data store with different services. If you have a web application that handles most of the traffic on your site, and you have some management task/process that hogs resources in the same application, you're affecting your end users by running those processes on the same service. The idea of microservices is to separate components so one does not affect the other, and you can scale individual components easily.
  - StavrosK 11y ago
    Define "application". You can easily have the task be a part of the same codebase and run on a different process or even server. For example, my Django maintenance commands run on a different server, and so do tasks, but they're still part of the same monolithic codebase.

gt565k 11y ago

Microservices allow you to scale individual components of your system and reduce technical debt by isolating them. Say you have services X, Y, and Z. Service Z handles a lot of traffic and is becoming a bottleneck to the whole system. You spin up 2-3 more instances, throw a load balancer in front of them, and increase throughput, all without ever touching the rest of the system. Pretty seamless! In addition, monolithic systems tend to be a pain in the ass for release cycles. Microservices allow you to very easily bring components up and down and do zero down time deploys by using a load balancer. Using our previous example, consider doing a release 2.0 for service Y. You spin up an additional instance of service Y with version 2.0 and the old instance is running version 1.0. You take the old instance out of the load balancer and stick the new one in. With the flip of a switch, your end user ends up using version 2.0 of service Y, without ever having to bring the system down. Now obviously microservices aren't the right design decision for every application. But as your system grows and uses different components, it's usually best to separate them out as individual services so that you can scale horizontally using load balancers.

djur 11y ago

A well-optimized monolith is going to be faster, but a less monolithic codebase makes certain bad decisions much more painful. If you know you have to make an RPC call of some sort to access a given resource, you're going to be more careful in how you access it; if you don't, you're going to have unusably slow and brittle software much faster than you would in a monolith. So you end up being forced to optimize earlier, and the process of optimizing a single small component is generally simpler (you can profile just that process, for instance). That said, there's nothing keeping you from gaining many of the same benefits from a well-disciplined, modular monolith, and I think there's a pretty high risk of a fast-moving and over-stressed team (like a lot of startups) being put under more stress by the time and complexity costs of microservices, and thus making much worse decisions than they would on a monolith.

dcre 11y ago

When things are "a pain to maintain," code gets worse and worse over time. Performance then suffers because no one understands what's going on. In other words, I believe that in the long run, complexity is a far bigger performance risk than technical overhead like how long it takes to make a web request. It's much easier to optimize away those kinds of problems away than to make an awful codebase understandable. In practice, I see service architecture as a way of making people think harder about how different parts relate to each other.

StavrosK 11y ago

They don't. They just force less disciplined devs to incur less technical debt by making interfaces inviolable. Personally, it would take a lot for me to switch a part of my monolith to a microservice and lose the speed of having everything done in the same process and the guarantees that having a single relational database offers. Having to reconcile data that got off sync because it was in two different data stores is not fun for anyone, and, to me, it's not worth it just to force yourself to not call any private methods on the other service. I just expose a public ABI and say "to interact with this part of the application, you may only call these functions here".

gt565k 11y ago
You can use the same data store with different services. If you have a web application that handles most of the traffic on your site, and you have some management task/process that hogs resources in the same application, you're affecting your end users by running those processes on the same service. The idea of microservices is to separate components so one does not affect the other, and you can scale individual components easily.
- StavrosK 11y ago
  Define "application". You can easily have the task be a part of the same codebase and run on a different process or even server. For example, my Django maintenance commands run on a different server, and so do tasks, but they're still part of the same monolithic codebase.