How to connect separate microservice applications?

Question

I am building huge application using microservices architecture. The application will consist of multiple backend microservices (deployed on multiple cloud instances), some of which I would like to connect using rest apis in order to pass data between them.

The application will also expose public api for third parties, but the above mentioned endpoints should be restricted ONLY to other microservices within the same application creating some kind of a private network.

So, my question is:

How to achieve that restricted api access to other microservices within the same application?

If there are better ways to connect microservices than using http transport layer, please mention them.

Please keep the answers server/language agnostic if possible.

Thanks.

Answer 1

you can use RabbitMQ publish your resquests to queue and then consume tasks

Answer 2

I know i'm super late for this question :)) but for anyone who came across this thread, Kafka is a great option for operations similar to this question.

based on Kafka's own introduction

Kafka is generally used for two broad classes of applications:

1. Building real-time streaming data pipelines that reliably get data between systems or applications
2. Building real-time streaming applications that transform or react to the streams of data

Side Note: Kafka is created by LinkedIn and is being used in many huge companies so it's kindda battle tested.

Answer 3

...the above mentioned endpoints should be restricted ONLY to other microservices within the same application...

What you are talking about in a broad sense is authorisation.

Authorisation is the granting or denying of "powers" or "abilities" within your application to authentic users.

Therefore the job of any authorisation mechanism is to validate the "claim" implicit in any inbound API request - that the user is allowed to do the thing encoded in the request.

As an example, imagine I turned up at your API with a PUT request for Widget 1234:

PUT /widgetservice/widget/1234 HTTP/1.1

This could be interpreted as me (Bob Smith, a known user) making a claim that I am allowed to make changes to a widget in your system with id 1234.

Whatever you do to validate this claim, I hope you can see this needs to be done at the application level, rather than at the API level. In fact, authorisation is an application-level concern, rather than an API-level concern (unlike authentication, which is very much an API level concern).

To demonstrate, in our example above, it's theoritically possible I'm allowed to create a new widget, but not to update an existing widget:

POST /widgetservice/widget/1234 HTTP/1.1

Or even I'm allowed to update only widget 1234 and requests to change other widgets should not be allowed

PUT /widgetservice/widget/5678 HTTP/1.1

How to achieve that restricted api access to other microservices within the same application?

So this becomes a question about how can you build authorisation into your application so that you can validate individual requests coming from known users (in your case your other services in your ecosystem are just another kind of known user).

Well, and apologies but I'm going to be prescriptive here, you could use a claims-based authorisation service, which stores valid claims based on user identity or membership of roles.

It depends largely on how you are handling authentication, and whether or not you are supporting roles as part of that process. You could store claims against individual users but this becomes arduous as the number of users increases. OAuth, despite being pretty heavy to implement, is a leading platform for this.

I am building huge application using microservices architecture

The only thing I will say here is read this first.

Answer 4

RestAPI is not only way to do it, one of the some ideas that i have seeming is about the usage of Service Registry link Eureka (Netflix), Zookeeper (Apache) and others.

Here is an example:

• https://github.com/tiarebalbi/qcon2015-sao-paolo-microservices-workshop

Answer 5

One way is to use HTTPS for internal MS communication. Lock down the access (using a trust store) to only your services. You can share a certificate among the services for backend communication. Preferably a wildcard certificate. Then it should work as long as your services can be adressed to the same domain. Like *.yourcompany.com.

Once you have it all in place, it should work fine. HTTPS sessions does imply some overhead, but that's primarily in the handshake process. Using keep-alive on your sessions, there shouldn't be much overhead with encrypted channels.

Of course, you can simply add some credentials to your http headers as well. That would be less secure.

Answer 6

The easiest way is to only enable access from the IP address that your microservices are running on.

Answer 7

Yeah easy. Each client of a micro service has an API key. Micro services only accept requests from clients with a valid API Key.

Also, its good to know that REST is simply a protocol that allows communication between bounded contexts.

It doesn't have to be over HTTP. The requirement is that it has a uniform interface (this is why HTTP is used with its PUT, POST, GET, DELETE... methods) and that it is stateless (all state being transferred through a URI).

So if all your micro services run on the same box, all you need to do is something like this:

class SomeClass implements RestfulMethods {

    public function get(params){ // return something}
    public function post(params){ // add something}
    public function put(params){ // update something}
    public function delete(params){ // delete something}
}

Micro services then communicated by interacting with the RestfulMethod implementations of other services.

But if your micorservices are on different machines, its probably best to use HTTP as the transport mechanism.