MicroService Architecture

Here is a microservice architecture deployment diagram. All Services are docker containers which are registered to Consul Server via Registrator. Client (External – Mobile, UI) makes a call to Bouncer which is our API Proxy. Bouncer has all permissions configured on API URLs. It makes a call to Auth Server which authenticates the request and if successful it passes the Service URL to HAProxy. HAProxy then has rules configured which redirect the URL to exact service.

Service always follow a naming convention so when service is registered in consul then consul-template refreshes the HAProxy configuration in the background.

microservice-architecture-1

Bouncer – API Proxy gateway…all calls come to bouncer to make sure that only authenticated requests are passed to actual services

Auth Server – Single point of authentication and authorization. All applications create permissions and save in Auth Server

External ELB – All public APIs talk to External ELB which in turn are passed to HA Proxy cluster

Internal ELB – All internal APIs are routed through Internal ELBs. There will be URLs which will only be exposed to Internal Services

HA Proxy (Cluster) – The Load balancer cum service router

Consul Server (Cluster) – Centralized Service Registry

Registrator – SideCar application running with each service which updates Consul Cluster about service health

Consul Template – Background application which updates HAProxy whenever there is a change in service configurations

ECS Cluster – AWS ECS where all docker containers are registered. Takes care of dynamically launching new docker containers based on parameters. Autoscaling is handled automatically

There you have major parts in deployment..Please share your comments..Happy Coding !!

A friend posted this question on my FB account

 

Question 1.

I am depicting from diagram that all microservice API will proxy through API gateway. Is it true for internal cluster communication also? If yes, then wouldn’t it be too much load on gateway server for too many micro-services in infrastructure? Or will it be as lightweight as load balancer? Can I assume this gateway as a simple reverse proxy server which is just passing through the request/response then why not use Apache or Nginx?

Answer : 1st….internal cluster communication may or may not happen through Bouncer..depending on what your security requirements are.if you want all API calls to be authenticated then yes it will go through Bouncer…Point to note is.Bouncer is very lightweight Node.JS application so it will have extremely high throughput and because its behind HA Proxy you can always add new nodes…

API Proxy is a reverse proxy but with some logic…Most of the time when you want to expose an API which interacts with multiple microservices you will have to aggregate data..that logic will reside in API Proxy..Its a common pattern in large scale architecture

Question 2.
As per your description, Auth server is also responsible for authorisation here? Then how are you making sure of isolation of microservice, if it’s authorisation logic is shared to auth server the how are you making sure of data integrity which is a security measure which protects against the disclosure of information to parties other than the intended recipient.

Answer:

Auth Server is like “Google auth server”…All resource permissions reside in AuthServer..Authorization server has permissions for each application…These permissions can either be added via API by app or by an Admin UI…so each app can have different permissions…A single user will be given different permissions for different apps so isolation is guaranteed. e.g. I May have “user-create” permission in UserService but I may not have “account-create” permission in AccountService

Who creates permissions, who gives them to users.. and when depends on your design.

 

MicroService Architecture

Web Application Scalability – Service Layer

So In our last post I promised that we will talk about how to make monolithic code into distributed SOA architecture.

Well its not easy. Once you have decided that you want to re-architect the single chunk of software in distributed manner you have to decide about different parts of the system which can be deployed on different machines and still everything will work fine.

There are many problems while doing so

a. How will you host these services (S in SOA)

b. How will you communicate and how serialization/deserialization will happen?

c. How do you make sure that you are able to implement the same workflow which you had in single monolithic component assuming you were doing things sequentially.

 

To answer the first question there are many options available but I will list down some which I have personal experience with

 

a. Design your services as RESTful and deploy them in you preferred container like weblogic

Pros

– Location transparency. You refer to the services using URI..

– Interacting with RESTful service is pretty easy in any language

Cons

– Serious overhead of HTTP protocol

– Serious maintenance issues with container management not to mention huge performance hit

b. Design your services as Java processes and interact with them using a service bus like JMS (ActiveMQ, Fiorano etc.)

c. Design your services as Thrift based and interact with them by passing pre-generated client code

Pros

– Serialization/Deserialization take care by thrift. You just interact with POJOs everywhere

– Lightweight highly scalable proven architecture (Facebook?). Forget about converting from Json to POJO and vice-versa

Cons

– Every time service or schema is changed you need to redistribute client code.

– Schema definition in thrift file has some limitations of its own

d. Design your services as separate Java Processes and have a networking library like ZeroMQ take care of communication

Pros

– ZeroMQ is battle tested and used in many mission critical projects. Takes care of networking needs

Cons

– Low level programming is needed compared to other approaches

– Many scenarios will have to be handled even with this approach so code size will swell up

For long time I had been dealign with Hub and Spoke Model by using a ServiceBus like MSMQ, ActiveMQ

ServiceBus is a popular approach especially in financial institutions who invest in enterprise grade product like TIBCO MQ.

Problem with service bus approach is that you have to write code specific to Messaging Bus. So another layer is added which increases complexity

So for some time I had been tracking if there is a way to remove this layer. Given my experience in Industry there are some areas I believe a company should not invest until absolutely necessary and one such area is networking.

Having said that one day while learning Scala I came across a project called Akka. Akka is a framework which addresses many problems with simple concept of Actors.

Networking and Concurrency provide easy way to program local or distributed services. What you get is complete location transparency as you communicate with remote actors in same way as you communicate with local actors.

There is no hub and spoke model so no new software has to be installed/maintained or written specific code to make things work.

It’s P2P…networking complexities are hidden deep inside and you never have to deal with thread. WOW !! Sounds too good to be true..It is.

Completely asynchronous with a programming paradigm that is easy to understand and concept of actors is already proven in telecom industry.

In the next post we will talk about some sample code for how location transparency can be achieved.

 

 

Web Application Scalability – Service Layer

Web Application Scalability – Part 1

Foundation

I have been thinking about writing about software architecture for a while. There is lot of confusion among programmers about how to design software at scale. Teams fight about a programming language/framework/library/tools and what not. So I intend to share my experience in this field and I will keep writing new articles and improvise existing ones.

Software architecture is a field that is highly based on

  • your experience
  • how many choices you made independently
  • if you made any mistakes did you learn from them
  • Are you up-to-date with latest
  • Knowing about pros and cons of each choice you are making

This will be a 3 part series.

Each part will deal with one layer in the Web Application. We will look at aspect of scalability, problems faced today, relevant technologies in today’s date and how to utilize them.

A traditional Web Application is made of three layers.

  1. Presentation
  2. Application
  3. Persistence

For more than a decade this architecture has been very popular in both Open Source community (Java, Ruby on Rails, PHP) and proprietary technologies (Asp.Net)

To achieve this architecture excellent frameworks are available across different technology and its easier to find talent.

From a typical web framework there are two main areas where developers seek help:

How to make web development easier?

Scale on demand – to be able to handle large traffic.

So if this is a popular architecture then what’s the problem?All web frameworks that I have worked with or that I know of primarily solve first problem.

But they fail miserably while answering second question. Developer is left on his own whenever scalability comes into picture. Fortunately large social networking websites have shown us the way forward and given us many tools which if utilized effectively can deliver this second aspect called scalability.

 

We will talk about second point in this series. When we talk about handling traffic here we are assuming that hardware available to us is Commodity hardware.

My approach will be practical by using as less jargons as possible so that a programmer with couple years of experience can easily understand the how he can make design and framework choices to achieve this nasty goal called scalability.

 

Web Application Scalability – Part 1