4 ms·

My experience with this requirement was that each of our "microservices" ended up consuming between 0.5 to 1 GB of RAM just to start up and connect to a databas

by jrs95 10y ago

My experience with this requirement was that each of our "microservices" ended up consuming between 0.5 to 1 GB of RAM just to start up and connect to a database and a message bus. And these were simple CRUD services. Developers with older laptops couldn't even run all of the dependencies for what they were working on, and even those with better hardware were pushing the limits of their machines just a few months after adopting this architectural strategy.

user5994461 10y ago
"laptop" => Don't expect to run distributed systems on old laptop.
- jrs95 10y ago
  I don't really think 3-4 micro services ought to be something one can't run locally relatively easily. Even with a brand new MBP I couldn't effectively develop full stack using just a handful of services without running out of memory. Though I suppose this is less about locking yourself into a single framework for your services, and more about not shipping insane amounts of bloat with each of your services.
  - user5994461 10y ago
    The "micro-service" name is a fallacy, there is no reason for services to be "micro" in size. The language runtimes and dependencies already add a lot of boilerplate, even for the simplest of services. You will also need databases and data sources in the same box. Laptop have little memory. MacBook are no exceptions.
  - majewsky 10y ago
    > I don't really think 3-4 micro services ought to be something one can't run locally relatively easily. To put things in perspective: There are in fact dozens of microservices running on every laptop out there. They're called "system processes" or "daemons".
virmundi 10y ago
To expand a bit upon user5994461's statement, you're probably doing it wrong if you're working like this regardless of laptop. If a micro service depends on a micro service, you might be doing it wrong. Let's say there is a valid reason for that, is there anything we can do to simplify the situation to run on a laptop? Say you boot up the recipes service that needs your auth service. In this scenario mock the auth service either directly in code (you should be able to do this if you use DI for the actual service repo) or by static responses for your work scenario into a proxy/stub server like SimpleHTTPServer from Python [1]. When you're recipe service calls out, it's hitting the localhost:8002 for the python service which returns the same general application/json-v1-auth data. You can even go a bit further and make the Python code adaptive based on input. You might benefit from splitting the system apart with events too. For example, duplicate some of the authentication or authorization data across the micro services. Let's say your recipe service needs to know who can read a given recipe. Use JWT or some other tokening feature to say who the current caller is (in a secured way). In the recipe's service, keep track of that user's authorizations locally. JWT tells you they are authenticated, the local DB can tell you their authorization. Now you don't need the auth service since you can probably create valid tokens. When the user's authorization changes, an even tells the recipe service. While there is a small period of time in which the person might be able to access something they shouldn't, in a functioning distributed system this isn't too bad. If you can't handle such failures, you might now want a micro service architecture. 1 - https://docs.python.org/2/library/simplehttpserver.html https://docs.python.org/2/library/simplehttpserver.html
- debaserab2 10y ago
  How do you deal with cache invalidation? That seems like a potential major security risk. Caching other microservice's data in general just sounds like a bad idea.
  - virmundi 10y ago
    In the examples above, the primary source of truth is the auth service. However, the rights get distributed (duplicated) to the various services. As I pointed out towards the end, there is a period of time where the auth service might say that a user lacks a group, but that the recipe service says the user has the group. During this window of time, the system will allow the user to access a feature that requires the group they are in fact no longer a part of. The same is true if you put groups in a JWT. Caching is caching. You always have to weigh the benefits against the cons. In general this is a problem with distributed systems. CAP and all that. What do you do if your network is partitioned such that the recipes service can service requests while the auth service can't notify the recipe service of changes? You can bring the whole system down. You can continue to allow operations based on the cached rights. You could limit operations if you haven't gotten a heart beat from the auth service in while. Back to the example, say group changes occur rarely. Say over that, network partitions (including message system failures) occur rarely too. Chances of both happing is P(partition, msg_failure). Probably small chance. If you can live with that, you're life might be better. If you have hard requirements to always get the auth, you might need to couple. Even then you're not really guaranteed that the latest data from the auth service is the latest data concurrently. Finally, even if you have coupling, you can still design the system to use profiles to pick the service. When you're running locally, don' go to the real auth system, just go to SimpleHTTPServer. Don't attempt to run the auth service locally. SimpleHTTPServer will probably use fewer resources than your micro service using some complex library.
rco8786 10y ago
That sounds orthogonal to what I was saying. I'm not advocating for bloated services. If you don't need module X, don't include it.
eikenberry 10y ago
If every microservice uses 500M+ of RAM you most probably are using the wrong technology to implement your microservices.
- jrs95 10y ago
  Yeah, that was more the issue. Implementing them with just one technology would have been fine had more thought gone into that decision.

by jrs95 10y ago

user5994461 10y ago

"laptop" => Don't expect to run distributed systems on old laptop.

jrs95 10y ago
I don't really think 3-4 micro services ought to be something one can't run locally relatively easily. Even with a brand new MBP I couldn't effectively develop full stack using just a handful of services without running out of memory. Though I suppose this is less about locking yourself into a single framework for your services, and more about not shipping insane amounts of bloat with each of your services.
- user5994461 10y ago
  The "micro-service" name is a fallacy, there is no reason for services to be "micro" in size. The language runtimes and dependencies already add a lot of boilerplate, even for the simplest of services. You will also need databases and data sources in the same box. Laptop have little memory. MacBook are no exceptions.
- majewsky 10y ago
  > I don't really think 3-4 micro services ought to be something one can't run locally relatively easily. To put things in perspective: There are in fact dozens of microservices running on every laptop out there. They're called "system processes" or "daemons".

virmundi 10y ago

To expand a bit upon user5994461's statement, you're probably doing it wrong if you're working like this regardless of laptop. If a micro service depends on a micro service, you might be doing it wrong. Let's say there is a valid reason for that, is there anything we can do to simplify the situation to run on a laptop? Say you boot up the recipes service that needs your auth service. In this scenario mock the auth service either directly in code (you should be able to do this if you use DI for the actual service repo) or by static responses for your work scenario into a proxy/stub server like SimpleHTTPServer from Python [1]. When you're recipe service calls out, it's hitting the localhost:8002 for the python service which returns the same general application/json-v1-auth data. You can even go a bit further and make the Python code adaptive based on input. You might benefit from splitting the system apart with events too. For example, duplicate some of the authentication or authorization data across the micro services. Let's say your recipe service needs to know who can read a given recipe. Use JWT or some other tokening feature to say who the current caller is (in a secured way). In the recipe's service, keep track of that user's authorizations locally. JWT tells you they are authenticated, the local DB can tell you their authorization. Now you don't need the auth service since you can probably create valid tokens. When the user's authorization changes, an even tells the recipe service. While there is a small period of time in which the person might be able to access something they shouldn't, in a functioning distributed system this isn't too bad. If you can't handle such failures, you might now want a micro service architecture. 1 - https://docs.python.org/2/library/simplehttpserver.html https://docs.python.org/2/library/simplehttpserver.html

debaserab2 10y ago
How do you deal with cache invalidation? That seems like a potential major security risk. Caching other microservice's data in general just sounds like a bad idea.
- virmundi 10y ago
  In the examples above, the primary source of truth is the auth service. However, the rights get distributed (duplicated) to the various services. As I pointed out towards the end, there is a period of time where the auth service might say that a user lacks a group, but that the recipe service says the user has the group. During this window of time, the system will allow the user to access a feature that requires the group they are in fact no longer a part of. The same is true if you put groups in a JWT. Caching is caching. You always have to weigh the benefits against the cons. In general this is a problem with distributed systems. CAP and all that. What do you do if your network is partitioned such that the recipes service can service requests while the auth service can't notify the recipe service of changes? You can bring the whole system down. You can continue to allow operations based on the cached rights. You could limit operations if you haven't gotten a heart beat from the auth service in while. Back to the example, say group changes occur rarely. Say over that, network partitions (including message system failures) occur rarely too. Chances of both happing is P(partition, msg_failure). Probably small chance. If you can live with that, you're life might be better. If you have hard requirements to always get the auth, you might need to couple. Even then you're not really guaranteed that the latest data from the auth service is the latest data concurrently. Finally, even if you have coupling, you can still design the system to use profiles to pick the service. When you're running locally, don' go to the real auth system, just go to SimpleHTTPServer. Don't attempt to run the auth service locally. SimpleHTTPServer will probably use fewer resources than your micro service using some complex library.

rco8786 10y ago

That sounds orthogonal to what I was saying. I'm not advocating for bloated services. If you don't need module X, don't include it.

eikenberry 10y ago

If every microservice uses 500M+ of RAM you most probably are using the wrong technology to implement your microservices.

jrs95 10y ago
Yeah, that was more the issue. Implementing them with just one technology would have been fine had more thought gone into that decision.