4 ms·

I'd love some additional examples of technical problems microservices solve that are unrelated to scaling the organization. I've mainly come across the occasio

I'd love some additional examples of technical problems microservices solve that are unrelated to scaling the organization. I've mainly come across the occasional one-off where a different language is significantly better suited to the problem at hand, so that has been broken out as its own service, and there's another one here in the comments about migrating a python application between versions (I could argue the semantics of microservice here, but I'll roll with it), but I have not come across many where a microservice was the "right" solution to a purely technical problem.

felixhuttmann 6y ago
Examples: 1) Long-living connections. One part of your application offers large file downloads, so that your users sometimes take significant amount of time to download, and the error rate shall be low. Think people doing `curl -L https://github.com/.../some-commit-hash.zip https://github.com/.../some-commit-hash.zip` in CI. I'd guess this is not served by github's ruby monolith. Or you use websockets. Redeployments typically stop all running tcp connections. Splitting this part off allows you to redeploy the main application frequently without disrupting websockets or downloads. 2) Reduce startup time. For some languages/ecosystems, startup time is significant and scales with the size of the codebase. For example, a typical java enterpise app like keycloak has half a million lines of code and takes about 1 minute only for startup. This is even more relevant when running things in AWS Lambda or google cloud run, and can also be relevant for integration tests. Having several deployables each handling a subset of the functionality may give you better cold start times than having one that contains all code. 3) Resiliency toward resource exhaustion. If two functionalities are served in the same process or VM, and one of them * has a memory leak * uses the connection pool to the database inefficiently and thereby clogs it up * has an endpoint that is overloaded by a misbehaving client then the other functionality is also affected, which can be avoided by putting them into separate processes/containers/VMs. Splitting services allows to reduce the effort spent on resource hygiene and rate limiting. 4) Binary size. It is often convenient to compile static info or asset-like things into the application, think geoinformation on timezones. This bloats the binary, splitting that part off into an independent deployable can give you a much smaller binary for the main application.
- eightysixfour 6y ago
  1) Sure, that may be an example of a good microservice, but I'm not sure that is a requirement to follow a broad microservices architecture. This can also be handled via proxies/load balancers and rolling deployments of monoliths. 2) Agreed, for individual services. Maybe/maybe not for the entire system. 3) I think this is generally true, but if you have a service that others are dependent on, you can still have these problems. Auth services for example (that was a fun day at work). 4) Sure, but now you have two binaries.
saberience 6y ago
Microservices are easier to understand and debug. This should speak for itself. If you ship a service which is well defined and only handles a reasonable amount of functionality, reasoning about its runtime behavior, memory, CPU usage, IO, etc, becomes much simpler. Microservices are easier to test, either through unit testing, load-testing, integration testing etc. If you push a new version of a microservice and you see it's using more memory than the previous iteration, it's usually trivial to work out which line of code caused the change. Microservices are mentally easier to grok for engineers working on them. I've worked on monoliths that required months for engineers to get up to speed on working with them because they did SO much stuff and if we had a memory issue with our monolith it could take weeks to diagnose the issue and we had to have our best engineers look at those problems because the service had grown so big and complex over many years.
- eightysixfour 6y ago
  > Microservices are easier to understand and debug. I think an individual microservice is easier to grok and debug, but I also think a system made of microservices is harder to understand and debug. Depending on scale this is a bit of a wash to me, YMMV.
yawnxyz 6y ago
I broke out all our code for displaying public content into a few different microservices so my sites could easily grab them, which allowed me to play with different frameworks and ways to display our content (blog posts and directory/references for biology). The new content microservices endpoints are also a public (though undocumented) API as an extra bonus. Basically it gave me the flexibility to work faster, and generating the code (e.g. the REST endpoint or the Svelte/Sapper front-end) is also a lot faster, and I get to host them on Vercel for free Oh and it also helps me to separate business logic code and other not-so-public data to somewhere else (Heroku instead of Vercel) and it just runs completely separately. That way I don't have to worry about accidentally sharing data As a solo designer/engineer this Vercel + microservices / tiny APIs + tiny frontends makes my life much easier

felixhuttmann 6y ago

Examples: 1) Long-living connections. One part of your application offers large file downloads, so that your users sometimes take significant amount of time to download, and the error rate shall be low. Think people doing `curl -L https://github.com/.../some-commit-hash.zip https://github.com/.../some-commit-hash.zip` in CI. I'd guess this is not served by github's ruby monolith. Or you use websockets. Redeployments typically stop all running tcp connections. Splitting this part off allows you to redeploy the main application frequently without disrupting websockets or downloads. 2) Reduce startup time. For some languages/ecosystems, startup time is significant and scales with the size of the codebase. For example, a typical java enterpise app like keycloak has half a million lines of code and takes about 1 minute only for startup. This is even more relevant when running things in AWS Lambda or google cloud run, and can also be relevant for integration tests. Having several deployables each handling a subset of the functionality may give you better cold start times than having one that contains all code. 3) Resiliency toward resource exhaustion. If two functionalities are served in the same process or VM, and one of them * has a memory leak * uses the connection pool to the database inefficiently and thereby clogs it up * has an endpoint that is overloaded by a misbehaving client then the other functionality is also affected, which can be avoided by putting them into separate processes/containers/VMs. Splitting services allows to reduce the effort spent on resource hygiene and rate limiting. 4) Binary size. It is often convenient to compile static info or asset-like things into the application, think geoinformation on timezones. This bloats the binary, splitting that part off into an independent deployable can give you a much smaller binary for the main application.

eightysixfour 6y ago
1) Sure, that may be an example of a good microservice, but I'm not sure that is a requirement to follow a broad microservices architecture. This can also be handled via proxies/load balancers and rolling deployments of monoliths. 2) Agreed, for individual services. Maybe/maybe not for the entire system. 3) I think this is generally true, but if you have a service that others are dependent on, you can still have these problems. Auth services for example (that was a fun day at work). 4) Sure, but now you have two binaries.

saberience 6y ago

Microservices are easier to understand and debug. This should speak for itself. If you ship a service which is well defined and only handles a reasonable amount of functionality, reasoning about its runtime behavior, memory, CPU usage, IO, etc, becomes much simpler. Microservices are easier to test, either through unit testing, load-testing, integration testing etc. If you push a new version of a microservice and you see it's using more memory than the previous iteration, it's usually trivial to work out which line of code caused the change. Microservices are mentally easier to grok for engineers working on them. I've worked on monoliths that required months for engineers to get up to speed on working with them because they did SO much stuff and if we had a memory issue with our monolith it could take weeks to diagnose the issue and we had to have our best engineers look at those problems because the service had grown so big and complex over many years.

eightysixfour 6y ago
> Microservices are easier to understand and debug. I think an individual microservice is easier to grok and debug, but I also think a system made of microservices is harder to understand and debug. Depending on scale this is a bit of a wash to me, YMMV.

yawnxyz 6y ago

I broke out all our code for displaying public content into a few different microservices so my sites could easily grab them, which allowed me to play with different frameworks and ways to display our content (blog posts and directory/references for biology). The new content microservices endpoints are also a public (though undocumented) API as an extra bonus. Basically it gave me the flexibility to work faster, and generating the code (e.g. the REST endpoint or the Svelte/Sapper front-end) is also a lot faster, and I get to host them on Vercel for free Oh and it also helps me to separate business logic code and other not-so-public data to somewhere else (Heroku instead of Vercel) and it just runs completely separately. That way I don't have to worry about accidentally sharing data As a solo designer/engineer this Vercel + microservices / tiny APIs + tiny frontends makes my life much easier