Thursday, June 23, 2016

Microservices based Cloud Native Application - Part I

Preview:

In this post, I'm going to write about an application based on Microservices Architecture, which I presented in the Cloud Foundry Meetup. 

The entire series link could be found here:
Microservices based Cloud Native Application - Part I

Microservices based Cloud Native Application - Part II

Microservices based Cloud Native Application - Part III


Application Use Case:

The application is a miniature LinkedIn kind of application, which was built to demonstrate the key aspects of a Cloud Native application.


Application Features:


The app allows users to build their profile with experience details, their skills, certifications. 

The app allows the users to connect with other users and they can endorse skills and also recommend other users.

Application Architecture:





The application uses Microservices Architecture, which consists of loosely coupled, independently evolvable/deployable services.
It uses polyglot persistence. i.e, each service uses the right database which fits the use case. Flavors of Nosql and Sql is used in this application.

In addition to the microservices which implement functional features, the following Cloud Native application features are also implemented. 
  1. Loosely coupled bounded context
  2. Service Discovery 
  3. API Gateway
  4. Centralized Logging
  5. Fault Tolerance
These are explained in more detail in the following sections.

Microservices:

  1. Profile-Basic: This service would allow CRUD of a User Profile, like name, email etc. Since the data is well defined, we used a RDBMS (Mysql) for this.
  2. Profile-Skill: This service would allow the user to add new skills to his/her profile and allow other users to endorse skills. Due to the key/value nature of the data, we used a key/value store (Redis) for this
  3. Profile-Details: This service would allow CRUD of a Experience details/Certification Details of a user. Since the data is largely huge texts without restricted by a schema, we used a Document store (MongoDB) for this.
  4. Profile-Recommendation: This service would allow users to recommend other users. Since the data is largely huge texts without restricted by a schema, we used a Document store (MongoDB) for this. This is implemented as a separate service to demonstrate a key feature (Circuit Breaking). From a usecase perspective, creating a separate service would allow other services to look at the recommendations of a user to rate the profile (future usecase)
  5. Profile-Connection: This service would allow users to add other users to their network and also provides a listing of all the users present in their network. In order to maintain a networked graph of all the users, we used a Graph database (Neo4J) for this service
  6. Discovery-Server: This service would act a discovery service and would allow all other microservices to register to and discover each other. (including multiple instances of each service). This microservice is implemented by using the Netflix Eureka library.
  7. Edge-Server: This service would act like a API gateway, and can be used to provide authentication, routing and transformation of the requests. This service is implemented by using Netflix Zuul library
  8. Profile-web: This is an angular application, which consists of the actual client side implementation of the application.
Continued...See Part II