5 ms·

Building Microservices the Lean Way, part 2

104 points by tmwatson100 12y ago

anton_gogolev 12y ago
Is it just me or this is a tech homeopathy article?
- jamiesoncj 12y ago
  What do you mean by that? Not sure I understand your point
  - anton_gogolev 12y ago
    The article is, to put it mildly, not very dense on the content. A lot of hand-waving and shallow thoughts.
    - jamiesoncj 12y ago
      Oh right. I didn't get it. I thought tech homeopathy was some new framework / library / approach I hadn't heard about. Maybe homeopathy.js or similar? On the plus side, your comment did make me re-watch this: https://www.youtube.com/watch?v=HMGIbOGu8q0 https://www.youtube.com/watch?v=HMGIbOGu8q0
- zerr 12y ago
  You're not alone :) Even for the recently posted free 3-chapters from NGINX micro services book - while skimming, I had this constant feel of "show me the code".
codewithcheese 12y ago
Hi Tom, I too have a django monolith. But, I hesitate to go down the microservices route, since I reuse alot of classes in what would become different services. Can you comment on how your class structure has changed, and how you have maximized (or not) code reuse?
- tmwatson100 12y ago
  What sort of classes do you mean? Views? Models? Other? For us it hasn't changed much. Our apps were pretty self-contained so that splitting them into separate services isn't very arduous. Stuff that is shared between apps is often related to 3rd party integrations, which could be moved into a separate (often asynchronous) worker/ service. In reality most of these design choices are done on a case by case basis, based on time/ cost/ maintenance.
  - codewithcheese 12y ago
    Yeah my main concern is for models. I can see it helps if you have distinct django apps already, in my case I have one main monolithic app. As an example I use elasticsearch, but I post process the results using models. ES is a service already do I really want to iolate some logic and build another service on top of that?
- FooBarWidget 12y ago
  We extracted common code in a library, which we reuse in each microservice.
latch 12y ago
FWIW, I've found that building a robust and deep "API Gateway" is the key to making SOA/Microservices work. Otherwise, you end up with duplication and latency. Routing and authentication are obvious candidates. It's also a good place to track stats and tag each request with a unique ID so you can trace it as it flows through your services. By "deep", I mean that it should be application-aware. Caching is a good example. For many applications, url + querystring results in too many permutations. If the cache is aware, it can often use more meaningful keys. Additionally, events in the underlying services can be used to cache purge, which can result in a wicked cache hit ratio. A more complex example has to do with duplication. Say you're building an ecomm platform. You have a service for search, and one for recommendations and one for the main catalog. They all need to return the same representation of a "product". Do you duplicate the logic? Do you tie them together and pay the latency and reliability price? No. Have them all just return IDS, and let the API Gateway hydrate the actual results. It's a form of API-aware server-side include and it works well.
- jamiesoncj 12y ago
  This is really interesting. Would you consider writing a more in-depth post on this? I'd love to read it.
  - latch 12y ago
    If you mean the SSI: http://openmymind.net/Practical-SOA-Hydration-Part-1/ http://openmymind.net/Practical-SOA-Hydration-Part-1/ http://openmymind.net/Practical-SOA-Hydration-Part-2/ http://openmymind.net/Practical-SOA-Hydration-Part-2/ I'm playing with it again on a new project, with a twist. Each item can be heavily personalized. Sticking with the ecomm example, the virgin product might look like { "id": "434p", "name": {"en": "..."}, } But we want to expand that, per user, with stuff like: "liked": true, "bought": "22-1-2015" We don't want to burden the clients with having to make multiple calls. I'm still working it out, but the services will continue to just return a list of product ids, and the API Gateway will now hydrate both the product and the personalized pieces. Something like: res = upstream(req) ids = extractIds(res.Body) products = getProducts(ids) personalized = getPersonalized(ids, currentUser) reply(merge(products, personalized)) Not critical, but worth pointing out that, for me, the API Gateway acts like a gigantic product cache with _every_ product in-memory. When a product changes, it gets an event and updates its cache. It isn't really a "cache", since there's never a miss. Trying to figure out if I can do the same with personalized data. (Even if you have tens millions of product, you can easily store it in memory).
hannes2000 12y ago
> Finally, how do we deal with our monolith? We decided to treat it as if it was a (very large) microservice. Judging from your team size (3 engineers on the team page), this is probably still a very normal-sized microservice :)
scient 12y ago
I have a hard time believing that doing SOA over HTTP is faster than doing the calls directly to the database. I saw a SOA proponent build out a service for "products", instead of accessing them directly from the database in the application itself, and the result is a service that is fast on surface, but when you make 6 calls to it, it still adds up and is by far the biggest performance bottleneck. I guess approaching your SOA as DB over HTTP and additional layers is to blame here :)
AndrewHampton 12y ago
So here's a question we've been talking about at my office. When developing a micro-service on your development machine, do you need to run the whole stack or just the service you're working on? For example, let's I am working on service A, which depends on services B and C. Do I need to run all 3 apps and their data stores locally? We currently will typically point A to the staging B and C. However, we have some long running jobs that A will initiate on B and B needs to post back to A when it's finished. This doesn't work when pointing to staging B.
- rgarcia 12y ago
  You should check out a tool we built to solve this problem at Clever: https://github.com/clever/aviator https://github.com/clever/aviator It lets us spin up a service + all dependent services locally with a single command.
  - danesparza 12y ago
    It's my understanding microservices shouldn't have many dependencies on one another. The link to you blog post that explains your rationale doesn't appear to work... do you mind explaining what need this fills?
- tekacs 12y ago
  One option is a framework[1] which tries to start dependent services locally. A stopgap solution is to use something like an Actor[2] model, which schedules actors on an ActorSystem and to clone the context/scheduler/system for each client ID. As long as your actors are fairly sane, this should be fairly lightweight. Then just shut down the actors for a given client (actorSystem.shutdown() under Akka), either after a time or by having a client send a Shutdown message (or both). [1]: http://wym.io/ http://wym.io/ [2]: http://akka.io/ http://akka.io/
  - mh- 12y ago
    just wanted to ask, in the footer on wym.io it mentions "wym-core is open source software".. but I wasn't able to find the source or a repo anywhere?
AndrewHampton 12y ago
So here's a question we've been talking about at my office. When developing a micro-service on your development machine, do you need to run the whole stack or just the service you're working on? For example, let's I am working on service A, which depends on services B and C. Do I need to run all 3 apps and their data stores locally? We currently will typically point A to the staging B and C. However, we have some long running jobs that A will initiate on B and B needs to post back to A when it's finished. This doesn't work when pointing to staging B.
gabrtv 12y ago
> The services are considered to be in a trusted network and are accessed by a private token passed in the ‘Authorization' header plus the user id of the requester in an ‘X-USER’ header. This reads like the user ID is exposed in a header without any sort of encryption.
- adaml_623 12y ago
  What does 'trusted network' mean to you? A lean quick service is not going to want to wait on encryption handshaking.
  - wtbob 12y ago
    On modern hardware, I believe AES and SHA-384 are very cheap. But yes, in a private network it's overhead.
akbar501 12y ago
Questions for Tom: 1.) How are you handling auth? Are you using a home grown solution or using OpenID Connect + OAuth 2.0? 2.) Is the JWT behind the firewall using a pre-shared key? 3.) What does the public token look like and how does the API Gateway perform auth? Does the token passed into the API Gateway contain only a user id? And does the API Gateway have to perform a database query to populate the full user object? side note: Thanks for writing the article.

104 points by tmwatson100 12y ago

anton_gogolev 12y ago

Is it just me or this is a tech homeopathy article?

jamiesoncj 12y ago
What do you mean by that? Not sure I understand your point
- anton_gogolev 12y ago
  The article is, to put it mildly, not very dense on the content. A lot of hand-waving and shallow thoughts.
  - jamiesoncj 12y ago
    Oh right. I didn't get it. I thought tech homeopathy was some new framework / library / approach I hadn't heard about. Maybe homeopathy.js or similar? On the plus side, your comment did make me re-watch this: https://www.youtube.com/watch?v=HMGIbOGu8q0 https://www.youtube.com/watch?v=HMGIbOGu8q0
zerr 12y ago
You're not alone :) Even for the recently posted free 3-chapters from NGINX micro services book - while skimming, I had this constant feel of "show me the code".

codewithcheese 12y ago

Hi Tom, I too have a django monolith. But, I hesitate to go down the microservices route, since I reuse alot of classes in what would become different services. Can you comment on how your class structure has changed, and how you have maximized (or not) code reuse?

tmwatson100 12y ago
What sort of classes do you mean? Views? Models? Other? For us it hasn't changed much. Our apps were pretty self-contained so that splitting them into separate services isn't very arduous. Stuff that is shared between apps is often related to 3rd party integrations, which could be moved into a separate (often asynchronous) worker/ service. In reality most of these design choices are done on a case by case basis, based on time/ cost/ maintenance.
- codewithcheese 12y ago
  Yeah my main concern is for models. I can see it helps if you have distinct django apps already, in my case I have one main monolithic app. As an example I use elasticsearch, but I post process the results using models. ES is a service already do I really want to iolate some logic and build another service on top of that?
FooBarWidget 12y ago
We extracted common code in a library, which we reuse in each microservice.

latch 12y ago

FWIW, I've found that building a robust and deep "API Gateway" is the key to making SOA/Microservices work. Otherwise, you end up with duplication and latency. Routing and authentication are obvious candidates. It's also a good place to track stats and tag each request with a unique ID so you can trace it as it flows through your services. By "deep", I mean that it should be application-aware. Caching is a good example. For many applications, url + querystring results in too many permutations. If the cache is aware, it can often use more meaningful keys. Additionally, events in the underlying services can be used to cache purge, which can result in a wicked cache hit ratio. A more complex example has to do with duplication. Say you're building an ecomm platform. You have a service for search, and one for recommendations and one for the main catalog. They all need to return the same representation of a "product". Do you duplicate the logic? Do you tie them together and pay the latency and reliability price? No. Have them all just return IDS, and let the API Gateway hydrate the actual results. It's a form of API-aware server-side include and it works well.

jamiesoncj 12y ago
This is really interesting. Would you consider writing a more in-depth post on this? I'd love to read it.
- latch 12y ago
  If you mean the SSI: http://openmymind.net/Practical-SOA-Hydration-Part-1/ http://openmymind.net/Practical-SOA-Hydration-Part-1/ http://openmymind.net/Practical-SOA-Hydration-Part-2/ http://openmymind.net/Practical-SOA-Hydration-Part-2/ I'm playing with it again on a new project, with a twist. Each item can be heavily personalized. Sticking with the ecomm example, the virgin product might look like { "id": "434p", "name": {"en": "..."}, } But we want to expand that, per user, with stuff like: "liked": true, "bought": "22-1-2015" We don't want to burden the clients with having to make multiple calls. I'm still working it out, but the services will continue to just return a list of product ids, and the API Gateway will now hydrate both the product and the personalized pieces. Something like: res = upstream(req) ids = extractIds(res.Body) products = getProducts(ids) personalized = getPersonalized(ids, currentUser) reply(merge(products, personalized)) Not critical, but worth pointing out that, for me, the API Gateway acts like a gigantic product cache with _every_ product in-memory. When a product changes, it gets an event and updates its cache. It isn't really a "cache", since there's never a miss. Trying to figure out if I can do the same with personalized data. (Even if you have tens millions of product, you can easily store it in memory).

hannes2000 12y ago

> Finally, how do we deal with our monolith? We decided to treat it as if it was a (very large) microservice. Judging from your team size (3 engineers on the team page), this is probably still a very normal-sized microservice :)

scient 12y ago

I have a hard time believing that doing SOA over HTTP is faster than doing the calls directly to the database. I saw a SOA proponent build out a service for "products", instead of accessing them directly from the database in the application itself, and the result is a service that is fast on surface, but when you make 6 calls to it, it still adds up and is by far the biggest performance bottleneck. I guess approaching your SOA as DB over HTTP and additional layers is to blame here :)

AndrewHampton 12y ago

So here's a question we've been talking about at my office. When developing a micro-service on your development machine, do you need to run the whole stack or just the service you're working on? For example, let's I am working on service A, which depends on services B and C. Do I need to run all 3 apps and their data stores locally? We currently will typically point A to the staging B and C. However, we have some long running jobs that A will initiate on B and B needs to post back to A when it's finished. This doesn't work when pointing to staging B.

rgarcia 12y ago
You should check out a tool we built to solve this problem at Clever: https://github.com/clever/aviator https://github.com/clever/aviator It lets us spin up a service + all dependent services locally with a single command.
- danesparza 12y ago
  It's my understanding microservices shouldn't have many dependencies on one another. The link to you blog post that explains your rationale doesn't appear to work... do you mind explaining what need this fills?
tekacs 12y ago
One option is a framework[1] which tries to start dependent services locally. A stopgap solution is to use something like an Actor[2] model, which schedules actors on an ActorSystem and to clone the context/scheduler/system for each client ID. As long as your actors are fairly sane, this should be fairly lightweight. Then just shut down the actors for a given client (actorSystem.shutdown() under Akka), either after a time or by having a client send a Shutdown message (or both). [1]: http://wym.io/ http://wym.io/ [2]: http://akka.io/ http://akka.io/
- mh- 12y ago
  just wanted to ask, in the footer on wym.io it mentions "wym-core is open source software".. but I wasn't able to find the source or a repo anywhere?

AndrewHampton 12y ago

gabrtv 12y ago

> The services are considered to be in a trusted network and are accessed by a private token passed in the ‘Authorization' header plus the user id of the requester in an ‘X-USER’ header. This reads like the user ID is exposed in a header without any sort of encryption.

adaml_623 12y ago
What does 'trusted network' mean to you? A lean quick service is not going to want to wait on encryption handshaking.
- wtbob 12y ago
  On modern hardware, I believe AES and SHA-384 are very cheap. But yes, in a private network it's overhead.

akbar501 12y ago

Questions for Tom: 1.) How are you handling auth? Are you using a home grown solution or using OpenID Connect + OAuth 2.0? 2.) Is the JWT behind the firewall using a pre-shared key? 3.) What does the public token look like and how does the API Gateway perform auth? Does the token passed into the API Gateway contain only a user id? And does the API Gateway have to perform a database query to populate the full user object? side note: Thanks for writing the article.