Microservices Technical Whitepaper

Common grounding:

·     A State is a condition of an entity at an instant of time.

·     Based on an entity’s state, Stateful is the ability to change the output of the entity given the inputs and state

·     On the other hand, if the output changes irrespective of the entity’s state or inputs, we call it as Stateless  

Example:

·     Consider a mutually exclusive binary system which represents 0 or 1. If you are sitting in a closed room and asked to watch the binary system as it changes between 0 and 1 and the instruction is to turn off and on the light switch based on the binary system displaying 0 or 1, you would do so. This is stateful.

·     On the other hand, in the same room, if the instruction is to answer ‘Yes’ when someone asks a question “are you in the room?” irrespective of the binary system displaying 0 or 1. This is stateless.

An API & a service can be designed and developed as stateful or stateless based on the requirement or need.

 Monolithic architecture style versus Microservices architecture

·     A monolith application is always built as a single, autonomous unit

·     In a client-server model, the server-side application is a monolith that handles the HTTP requests, executes logic, and retrieves/updates the data in the underlying database. 

Pain points with monolithic architecture:

·     All change cycles usually end up being tied to one another

·     A modification made to a small section of an application might require building and deploying an entirely new version

·     If you need to scale specific functions of an application, you may have to scale the entire application instead of just the desired components

SOA and Microservice

Microservices can be viewed as a special form of SOA.SOA has a broader framework.

·     SOA architecture is dependent on many ESBs whereas microservices typically uses one faster messaging layer.

·     SOA typically uses RDBMS database as back-end where microservices use NoSQL or micro-SQL databases that can connect to other databases.

·     Microservices is effective in a dynamic agile environment which demands scalable, adaptable, faster and modular services that can be quickly accessed by cloud-based applications

Some properties of Microservices

·     Product centric versus project centric approach

·     Services are componentized

·     Services are organized around business capabilities

·     Decentralized governance and management

·     The architecture is fast evolving

Microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.

Technical Myths:

·     Preferred way of creating enterprise applications

·     Enables easy and rapid scalability,

·     Helps enable support for a range of platforms and devices—spanning web, mobile, Internet of Things, and wearables

·     Enables rendering services when you are not sure what kind of devices you’ll need to support in an increasingly cloudy and mobile future

·     Developers widely use HTTP/REST with JSON to communicate with other services relating to application needs. REST is comparatively less complex over other protocols

Implementing Microservices architecture pattern

Consider a banking application. Consider account balance, transfers of funds, withdrawal and deposit transactions.

Suppose you have a large application, as in the above sample, and are splitting up the code base and teams to scale. Instead of finding an entire section of an application to split off, you can look for something on the edge of the application graph.

In our example, the arrows pointing to Printer, account balance, transfer funds, withdrawal and deposit suggest they’re five things that can be easily removed from the main application and abstracted away.

Printing either the application is irrelevant; a Printer just wants printable data. Turning these — Print, other transactions—into external services avoids the monoliths problem alluded in a traditional SOA web services approach. It also makes sense as they are used multiple times, and there’s little that can be reinvented.

Using service objects, we can go from monoliths to services. Without removing code from your application, you effectively just begin to structure it as though it were completely external. To do that, you’ll first need to differentiate the actions that can be done and the data that is present as inputs and outputs of those actions. Consider the code below, with a notion of doing something useful and a status of that task.

# a class to model a core bank application and execute it

Class Bankapplication

     define initialize

         @status = ‘Queued’

     end

    define print

          …………

          …………

         @status = ‘Finished’

     end

     define accountbalance

          …………

          …………

         @status = ‘Finished’

     end

     define transferfunds

          …………

          …………

         @status = ‘Finished’

     end

     define deposit

          …………

          …………

         @status = ‘Finished’

     end

     define withdrawal

          …………

          …………

         @status = ‘Finished’

     end

   end

to implement a Microservice,

#Service to do the work

Class Service #account balance, print, transfer funds, deposit or withdrawal

define execute the service

   #account balance, print, transfer funds, deposit or withdrawal

   ………

   ……….

   ……….

   Status=finish

   Return status

 end

end

#bankapplication status

Class status

  define initialize

     status = ‘Queued’

   end

  define finish

    status = ‘Finished’

 end

end

We have defined 2 classes: One that model the data and the other that executes the service and operations

Note the ‘Service’ class has not state, you can call same actions again and again with changing only the data and expect to get consistent results.

Implementing the classes as library service, will transform the existing code into a scalable external service.

Some pros and cons with Microservices

Pros:

·     Evolving technology stack; honors innovation

·     Easy to scale up or down (that is elastic in nature) with external or internal services or gateways

·     Handles fault tolerance more effectively

·     The code is organized by business capabilities

·     Changes are confined to a fraction of the service/application rather than changing the whole application, there by isolating the change agent and compilation

·     Use different programming language to code

·     Typically requires a small team size to implement and maintain, there by easier and less expensive to maintain

Cons:

·     Skill in designing Microservices

·     May lead to redundant effort in a distributed environment

·     As services increases, maintenance effort will linearly increase, thereby making integration difficult

·     Testing needs a good approach and skills

·     Microservice need good infrastructure support to scale up and perform as per expectations

In Summary:

Microservices offer as a good design technique for developing a large-scale enterprise application. Partitioning a big application or service in to Microservices offers potential benefits in leveraging the existing API and reusing them.

When we consider the fast pace changing landscape of technology, with mobile first and cloud first and organization taking up the digital transformation especially SaaS, PaaS, IoT and AI, Microservices have a very bright future.