Getting Started with Microservices

Getting Started with Microservices

#002

Hello Friends,

How are we doing, today. Welcome back in this Microservice series. This series are intended for practitioners who are interested in cloud application migration or develop applications from scratch in cloud. We will provide information from both architectural and implementation perspective as we progress in this series. A practitioner going through the blogs will get all information about Microservices from beginner to expert level. Basic understanding of any Computer language and application development / design experience, experience on cloud platforms would help but not mandatory.

Hope, you have already visited first introductory blog where I have tried to put few scenarios from my own experience and tried to explain importance of Microservices. In this article, I shall try to address Microservice concept in more detail way and will provide more different characteristics and Principles of Microservice architectural style. So, let’s begin,

 What is Microservice?

If we want to define Microservice in Computer paradigm, probably we can say in very layman language

Small autonomous computer services having individual software development life-cycle that work well together.

Following terminologies are closely coupled with Microservice concept.

  • Independent processes – Should behave like an independent entity. All Microservice applications should bundle their dependencies and execution libraries and run independently. This may sound strange at the beginning. But this approach has many benefits which will be eventually explained as we progress. Basically, Microservices are separate applications on their own and running independently on separate servers.
  • Boundaries inversed – In N-tire Architectural style of Software development, we have seen different type of boundaries/layers e.g. Presentation layer, Business layer , Database layer. In other hand, Microservice echo system has inversed boundaries, that means, each microservice has its own presentation layer, business logic layer, data access layer and even its own data store/ data sink.In some reference architecture the user interface part is kept outside of microservice echo system. When each offering in user interface is clicked the request gets redirected to a microservice serving the request. We will discuss more on different patterns in future blogs.
  • Communication – Microservices adapt lightweight protocols like REST , AMQP. In specific cases Thrift , ZeroMQ , Avro are used. Also, it is best practice to follow stateless implementation while following Microservice style. For synchronous communication REST is being used and messaging protocol for asynchronous communication.
  • Autonomy – Microservices are self-contained, independently deployable and take full ownership of one business capability. A chain of related microservices create a bounded context.
  • Honey bee analogy – Each cell in honeycomb is independent. By adding new cells honeycomb grows organically to a big solid structure. Microservices support organic growth by adding new services to the echo-system without affecting existing services.

Characteristics of Microservice

Let’s now talk about different characteristics of Microservices. Following characteristics are backbone of Microservice implementation style.

Decentralize data and logic – Each service aligned to a specific capability with data and logic. At no point, two services share same responsibility or one service has more than one responsibility. When Monolith applications consolidate all data and logic in one boundary, Microservice decentralize data and logic.

Loose coupling – Microservices are independent. They interact with each other with stateless protocol. Specifically, messaging based endpoints provide higher degree of decoupling. Service to service communication happens over a well-defined interface. Correct communication pattern is the primary driver of creating loose coupling Microservices.

Abstraction – In microservice echo system, abstraction is not only in terms of service realization but also in terms of dependencies, execution environment. A single microservice encapsulates all its dependencies, libraries, runtimes a.k.a. Container.

Reusable – Microservices are course-grained reusable business services.

Stateless – Well designed microservices are stateless and no conversational state is maintained by services. If there is a requirement to maintain state then special arrangement needs to be done.

Discoverable –  In microservice echo system, microservices self-advertises their existence and make themselves available for discovery. A service-registry maintains the map between service names and its binding information.

ComposabilityService Composability is achieved by service orchestration or service choreography for multiple Microservices. This is also called service chaining. Multiple microservices may interact with each other to serve user requests.

Polyglot structureEach service can be developed by different technology. For example, one service can be developed in Java and another in Scala.

LightweightSince each service performs single business capability, it is much more lightweight than Monolithic heavy application executable.

Principles of Microservice

The following principles can be adapted for designing Microservices. Here are some best practices

Modelled around business domain – We should consider Service boundaries aligning to business domains.  A single Microservice or a chain of Microservices implement a bounded context.

Hide Implementation Details –If a service manipulates another service then data cohesion is broken. So, databases should be hidden from direct reach of another service. Microservice must not have any direct access to database of another service, if data is required from other service then the same can be obtained by API call exposed by the respective service.

Decentralize– In traditional systems a middleware enterprise bus is used to handle routing between services and this giant bus is difficult to maintain. In Microservice echo system choreographed system should be used where each actor in the business process understands only its responsibility and not the entire system. This can be implemented by business events.

Deploy independently – There should be provision to deploy each service independently. Deployment of some service should not affect other services.

Isolate Failure – Microservices are not reliable by default. Cascading failures can take the system down. Special care should be taken against cascading failures and timeouts for prevention.

Observable – Every service in the echo-system should log requests, response time, error codes. ELK stack can be implemented to achieve this. It comprises of log stash, elastic search, kibana. Hystrix / turbine dashboard can render a dashboard for downstream monitoring.

So, that’s it friends, we have just started our Microservice journey, you can consider this article as Foundation of Microservice concept. In my next blog, I shall be discussing how Microservices can be compared with other Architectural style of software development like SOA, Cloud Principles etc. Also, advantage & disadvantages of Microservices architectural style.

Happy reading!! And do not forget to let us know in below comment section about your feedback or if you want more clarification. CTT team will address all your technical questions as soon as possible.

You may like our previous Microservice Blog 🙂

Author: Debajyoti Mukherjee

Debajyoti Mukherjee has more than 11 years if IT experience in application design , application development. He has worked in large MNCs and has worked for eminent clients. He is proficient in custom development , cloud platform , microservice based application migration.

One Reply to “Getting Started with Microservices”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.