Recent Tutorials and Articles
    Making Microservices Architecture a Success
    Published on: 25th September 2016
    Posted By: Amit Kumar

    This tutorial will talk about basics of Microservices and other concerns that need to be addressed to make Microservices a success.

    Abstract


    Monolithic applications don't particularly do well for most of today's systems demanding agility, flexibility, maintainability, high availablity and scalability. Monolithic applications become hard to be maintainable with time. Additionally, it makes functionally different components of a system tightly coupled to each other.

    Many architecture styles have been introduced to tackle these challenges. Some of those are N-tier, SOA, Event Bus, MicroServices etc. While all of these architecture styles are being used in place of monolithic applications, Microservices, in-particular, has been picking up pace lately. 

    There are many organizations investing into Microservices architecture to build agile, highly available and scalable applications. Netflix is one of the organizations that have successfully adopted Microservices architecture. 

     

    Introduction to Microservices Architecture


    Microservices architecture, as name suggests, talks about splitting your application into small distributed services each of which offers a specific small business/technical functionality. These services are then deployed independently on different containers (Docker, Vagrant etc.) or physical/virtual machines depending on your IT infrastructure setup.

    However, as per Microservices architecture, these distributed services (micro-services) should be stateless in nature so that these can easily be replicated and scaled up/down.

    Here are some of the benefits of adopting Microservices architecture -

    1. Modular Systems - Microservices architecture makes the systems modular by dividing these into small services (micro-services).
    2. Agile Systems - It also helps achieve agility as smaller services can independently be updated/modified. This allows us to do quick releases containing new functionality / bug fixes and, ultimately, improved user experience and trust.
    3. Targeted Scaling - Scaling monolithic application is not efficient. E.g. a blog application contains services for fetching and saving blogs. While blog saving service will have low load, blog fetching service will have huge load comparatively. In order to scale monolithic application, we would need to replicate whole application on more machines. While this will help us cope up with work load, it is not an efficient approach since we also replicated blog saving service. With Microservices, we could separate it into two different services and then scale either of these without touching other one.   
    4. High Availability - Since micro-services are stateless in nature, these can be replicated at run time in case of machine failures.
    5. Polyglot Systems - Microservices architecture also allows us to leverage various technologies / programming languages as all the services are separately developed, deployed and maintained. This makes our system more resource effective and high performant as we can use right tool for right job.

     

    Microservices Concerns for Success


    After discussing benefits of using Microservices architecture, it is also important to note that some important concerns need to be addressed in applications to get best of Microservices architecture. While there are many organisations that have adopted Microservices architecture successfully, there are others who have failed at it.

    Below diagram illustrates a typical Microservices architecture by highlighting some of concerns that we need to pay attention to -

    Microservices Big Picture

     

    1. Containerisation - Micro-services should ideally be deployed in lightweight containers that can be added/removed dynamically. For example, you could deploy your distributed services in Docker/Vagrant containers with Docker Swarm/Kubernetes automating deployment, scaling and management of these.
    2. Service Discovery - While we can segregate our application into small distributed services, these can't work in isolation and often need to call other services. Since our services are agile and containerised, their address (host, port, other metadata) keep on changing. To avoid any problems in inter-service communication, a Service Registry is used. All the services register with this at the time of starting up. With this, whenever a Service needs to call another one, it first goes to Service registry to fetch target service details. Hence, this ensures seam-less communication between services.  There are many frameworks available for Service discovery such as Eureka, Consul, ZooKeeper etc.
    3. Service Load Balancing - While we can look up Service address details from Service registry, we also need to have load balancing to ensure that we are utilizing all the service instances. This is where load balancing comes into picture. This can be done at either server side or client side using tools such as Ribbon, Zuul, Nginx etc.
    4. Service Tracing - After we are all done with seamless inter-service communication, we face the challenge of debugging functional and technical issues. This debugging is often troublesome as a request is usually served by multiple distributed services. However, we can make our requests traceable by employing a service tracing/monitoring system such as ZipKin, Sleuth, Prometheus etc.
    5. Service Circuit Breaker - Circuit breakers are useful in controling the interactions between distributed services by adding latency tolerance and fault tolerance logic. It also helps in stopping cascading failures across them, and providing fallback options, all of which improve your system’s overall resiliency. Hystrix is one such tool providing circuit breaker functionality.
    6. Service Templates - Since we can end up a lot of distributed services, making these consistent is often challenging. Service templates help us in this respect by providing a base project that teams should build on. This also helps in streamlining the technologies, frameworks and tools acorss various teams. For example, Maven archetypes can be used as Service templates that each of the teams can use to create projects.

     

     

    Thank you for reading through the tutorial. In case of any feedback/questions/concerns, you can communicate same to us through your comments and we shall get back to you as soon as possible.

    Posted By: Amit Kumar
    Published on: 25th September 2016

    Comment Form is loading comments...