Communication between APIs and API gateway

[Erol Merdanović]

Hi all

I have multiple APIs (my applications, hosted in same datacenter) that talk with each other. Should I put a API gateway in the middle of them?

PROS: I have one entry point (I don't have to remember each other APIs address). Plus I can easier handle load balancing (add extra APIs) and versioning (handle this with gateway).

CONS: There is an extra step which causes extra time. Single point of failure.

How do you solve this? Do APIs connect directly and use Zookeeper or something similar to track APIs status? What are the best practices?

[MattM]

Hi Erol,

What you're describing (multiple "APIs" talking to each other) sounds like it maps most closely to a Microservice Architecture.  The current conventional wisdom is that you would not use an API Gateway to intermediate the interactions between your APIs, and as you point out would most likely use a Service Discovery mechanism like Zookeeper (or Consul, Netflix Eureka, CoreOS etcd, etc).  However, there are definitely companies using APIs in an ESB-like manner as you describe.

There is consensus in the Microservices world that API Gateways are very effective when you have external applications (e.g. mobile, web, other app that is not part of the Microservices "fabric") accessing your APIs.  See the following illustrations...

Sam Newman's book "Building Microservices" - https://www.safaribooksonline.com/library/view/building-microservices/9781491950340/ch04.html
Chris Richardson's microservices.io site - http://microservices.io/patterns/apigateway.html

Please ping me if you'd like to discuss more.

Thanks, m@

[Erol Merdanović]

Dear Matt, 

first of all, thank you for your reply.

Yes, I'm trying to follow the microservices pattern. At the moment, services talk to each other via HTTP APIs or messaging. As you mentioned, API gateway should be used only for external access.

For direct HTTP communication there are no problems, but for messaging I followed http://www.slideshare.net/chris.e.richardson/building-and-deploying-microservices-with-event-sourcing-cqrs-and-docker-hacksummit-2014 to create a custom solution based on RabbitMQ. 

I followed the principle that only one service is the owner of the entity (lets say entity Company). When company is updated (via UI), event is published to RabbitMQ. Every other service listens to changes and updates it own database (it syncs data). Entity supports multiple versions so there are no problems with upgrading services and backward comparability.

Message is in format

{

  "timestamp": 1442340700000,

  "entity": "company", // <- entity name is unique for all microservices

  "version": 1, // <- to support backward compatibility

  "action": "create", // <- create/update/delete. I should probably also support events like company_bankrupted, company_sold etc..

  "fields":

  {

      "id": "91dd87da-bb52-496a-b371-4dda8515168a", // <- UUID for primary keys

      "name": "My company"

  }

}

Have you used any similar solutions? Some suggest different servicebuses to solve syncing (communication) between services. What do you think? I checked around for some opensource projects, but I wasn't able to find anything useful. So I'm not really sure if this is the right way.

Would love to hear your feedback.

[MattM]

I think that defining microservice boundaries is more of an art than a science.  The conventional wisdom is to define "bounded contexts", and that is deliberately a loose term.  In the example you cite, "company" as an entity may be tied to a number of microservices, but have different elements depending on the context of those services.  If you draw your service boundaries based on singular data entities, you are going to create a lot of chattiness between the microservices.  Since one of the goals of taking a microservices approach is to make each service as independent as possible, the "entity-defined" approach is not ideal.  It's better to look at the "jobs to be done" (Clayton Christensen term) to define what APIs are needed by your ultimate clients, and then define the service boundaries around those jobs.  Here's a good example of this jobs-to-be-done approach in action...

https://blog.yourkarma.com/building-microservices-at-karma

Note that they have split their services into three relatively broad categories: Order service, Fulfillment service, Tracking service.  This is an outside-in approach, as opposed to the inside-out approach of starting with data entities.  And note that they are open to taking an iterative approach.  If they find inefficiencies in this model, they are willing to look at ways to decompose the services further.

Hope this helps!

Thanks, m@

[Erol Merdanović]

Hi Matt. Thank you for feedback.

Maybe I didn't make myself clear enough. We have different services (billing - uses company, data upload logic - uses company, analysis - uses company). Every service is independent and has it's own database and copy of company data. So one service is not loading company data from another service (no chattiness). It only gets an event from "mother service" that controls company. Same approach as you just described.

Decomposing is hard and sometimes it produces a lot of code duplication. That is why I'm looking for some solutions that have been tested and work great in the production. So to be able to keep all the services in sync.

[mca]

<snip>

Decomposing is hard and sometimes it produces a lot of code duplication.

</snip>

keep in mind that clone and fork is more stable and sustainable than runtime sharing.

don't worry about duplicated code, worry instead about duplicated models (data-model, object-model, resource-model). changes to these will REQUIRE changes on both ends (provider and consumer).  and (for the web esp.) there can be more consumers than providers.

finally, when you share (only) representation formats (HAL, Cj, Siren, MASON, UBER) there is a much smaller chance that changes in the provider will *break* consumers. 

cheers.

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[MattM]

+1