Microservices Architecture : Integrations & Communications

Systems can’t be built in isolation, each part of the system needs to communicate with the components and also integrate with other parties to provide & seek the services. Microservices are no different they need to be integrated & have to communicate with other services & systems, this happens at various levels as shown below…let us explore each of these to understand the details of implementations & challenges, it is going to be long post as we need to see the various options available for the challenges to be addressed during integration scenarios. I would advice a cup of coffee won’t be a bad idea while reading  🙂

msafig3

User Interface (UI) Integration

  •  Each microservice can have its own UI
  • Single Page Applications(SPA)
  • Single HTML Page
  • JavaScript (udpates page dynamically)
  • Logic in JavaScript
  • Useful for complex interactions & offline ability requirement

Single Page Application(SPA) Technologies

  • AngularJS (Runs in browser, given by Google under MIT open source license)
    • Provides bi-direction UI data-binding which tracks changes at
      • View Level (Renders in browser)
      • Attribute Level (Code Level)
  • Ember.js (Similar to AngularJS with it s own module Ember data it provides MDA(Model Driven Approach)  for accessing REST resources. Also available under MIT open source license)
  • Ext JS provides MVC features & UI compose like Rich Client Applications. GPL license v3.0 ( Free for non-commercial implementation, for any commercial implementation license needs to be obtained from Sencha)

Microservices & SPA’s

  • SPA per Microservice
    • Each microservice can have its very own SPA which calls microservice via JSON/REST interfaces
      • Tight coupling of SPA’s is difficult
      • Switching between SPA’s needs browser app reload (not a recommended integration)
    • SPA’s should have uniform Authentication & Authorization to avoid the need for multiple logins , OAuth2 & Shared Signed Cookie can help solve these kind of problems

msafig4

Uniformity with Asset Server

  • Each SPA is assembled with its own UI
  • SPA’s of microservices can use the resources(JS,CSS etc) from asset server to enable uniform UI
  • Proxy Server helps in masking the security rules of different URL’s (helps in giving uniform experience)
  • Separation of assets will result in new problem of dependency(All the changes to the assets will require changes in microservices as well)
    • Risk to independent deployments
    • Scenario best avoided
    • Reduces dependencies in frontend

“Asset Sever is more a problem than a solution”

msafig5

JavaScript in SPA can access the data

  • From the same domain as the code originates(called as origin policy)
  • JavaScript can’t read data from multiple domains
  • All microservices are accessible to the outside under the same domain due to proxy(this is no limitation)
    • Policy has to be deactivated when UI of a microservice is supposed to access the data of different microservices
      • Solution 1: CORS (Cross Origin Resource Sharing) solves the origin policy problem
      • Solution 2: Have all SPA & REST services under one domain (here asset server is the best option to enable the solution)

Single SPA with multiple microservices

msafig6

Binding of UI would be required as the functionality of the pages might come from different microservices which are composed of the module(JavaScript, CSS) of specific microservice that has all the UI formation (assuming that implementation is AngularJS based)

  • AngularJS supports multiple modules for different SPA units/parts hence facilitating the each MS to have its own UI control module

Drawbacks:

  • Dependency across SPA & microservices for build & deployments( requires lot of coordination) – Better to avoid this setup
  • UI based coupling of microservices results in shared deployment artifact – Better to avoid this setup

“One advantage of this approach is SPA brings together UI from different microservices & shows to the users without any intervention “

HTML Applications

Each microservice has one or more web pages(HTML, JavaScript, CSS etc) generated on the server (difference from SPA is that only a new HTML web page is loaded not an application/module by the server)

ROCA (Resource Oriented Client Architecture)

msafig7

  • Handles JavaScript & dynamic elements in HTML UI
  • Alternative for SPA’s
  • JavaScript plays limited role of optimizing the usability of pages(facilitates & add effects to the web pages)
  • Core assumption application should be functional without JavaScript
  • ROCA reduces dependencies (core philosophy that web should work on HTML over HTTP)
  • In various microservices coupling can be enabled by links (natural integrations unlike SPA’s)

Routing based integration

  • From outside the mircoservices should appear like a single web application(with one URL)
  • Also enables the assets to be shared without violating same origin policy of various assets in the system

msafig8

Function of the router is to redirect the requests from external/internal parties to appropriate microservices

  • We can leverage Zuul for achieving this functionality, also reverse proxies can also help(like webservers nginx, apache httpd that direct request to other servers)
  • Request can be modified & URL’s are altered which is very easy in Zuul to extend & implement

NOTE: When the rules in router become complex it can kill the purpose of isolated deployment strategy hampering independent development & deployment.

JavaScript for HTML Layouts

  • AJAX can be leveraged to load the content of a link from another microservice(s)
  • Link based approach can be used
  • Facebook BigPipe :
    • Optimizes load time
    • Composes web pages from pagelets
    • JavaScript is used to replace elements of webpage(DIV elements etc)

Frontend Server based integration of Microservices

msafig9

  • Frontend Server assembles the HTML webpage from HTML code snippets generated by microservices
  • Assets like JavaScript, CSS etc can be stored in frontend server
  • Edge Side Integrations(ESI) concept helps by providing simple language to collate HTML from various sources
  • ESI cache holds static & dynamic content of a page (this mix of static & dynamic contents is key for assembling pages)
    • Proxies & cache (Varnish & Squid implement ESI)
  • Server Side Integrations (SSI) can be another alternative, but SSI doesn’t have cache support) and only available in webservers
  • Each microservice can deliver HTML snippets which can be integrated on the server
    • Apache httpd supports SSI’s with mod_include
    • Nginx supports SSI’s with ngx_http_ssi_module
  • Portlets can be used as an alternative solution for the content assembly ( JSR 168, 286) in this case but it is very complex and the portlets are implemented differently in various servers (For microservices this solution is best not to be considered) Also most of the portlet implementations restrict us to java technology only…

Integration Scenario with Mobile & Rich clients

Mobile & Rich client applications present a different challenge in the current context microservices integration as they have separate client side installer which is required to access the services whereas web implementation is more universal and generic with central management of the UI assembly with HTML snippets shared by microservices. Also the entire mappings can be controlled by single coordinated client & server deployment.

  • Mobile, Rich or desktop clients requires separate installation for the client (which is predominantly monolith in nature) which has to offer/manage the interfacing with microservices
  • These client requirements might drive/dictate changes in the microservices development & deployments hence it is advised to bring some modularity into the context
  • We can’t have multiple client app deployments for the feature changes in microservices as the users will have direct impact or overhead requiring updates on the devices (this isolation development approach is considered in SPA’s for client & server development but the same is not recommended)
  • Both client & microservices can’t be isolated coordination is required to rollout and address the channel based needs at optimum levels

Organization Scenario

  • Mobile client development teams are different from the microservices teams (adding the client specific developers in each microservice team is not a great approach)
  • Mobile platform team needs to interact with all the microservices implementation teams which requires lot of communication which is not recommended by microservices approach

msafig10

One probable solution can be microservices team develops the features for web and the same will be available to mobile app when it is released but the catch here is that each microservice needs to support different features for web & mobile (to avoid the scenario we can have similar features across channels but in the domain context it might not be the case as the requirements/usecases might vary)