Let's Just Integrate-MicroServices

What are Microservcies?

Past decade is about SOA architectures, SOAP protocol which provided a standard way of platform neutral communication between applications in an enterprise environment. SOA services are usually deployed as application packages on application servers running on VMs, but SOA business & architectures initiatives evolved to support reusability, composability, portability, service discovery etc.

Cloud computing, container based docker support, Restful Architecture & Tooling & success stories like Netflix, are suggesting to design application features as small autonomous deployable containers that can be created, destroyed, scaled independently. This approach of dividing monoliths into small services, or creating platforms backed by 1000s of small services working together, improved & released iteratively with CI/CD can be defined as Microservices.

Enterprises are getting several benefits by adopting microservices & cloud computing like cost, time to market, automation but there is a significant design challenges & management complexity that has to be embraced along with it. Also check out 2-minute read on D-Zone:
https://dzone.com/articles/what-are-microservices-actually

Guiding Principles in Microservices Architecture

It will be nice to have some high level overarching principles that you can rely on while designing small autonomous microservices. Sam Newman explained quite well in conferences and it is worthwhile to make some notes out of it.

I. Modelled around Business Domain

It helps to design microservice for each feature / capability of a platform / or application. Instead of designing services in horizontal layers like system, process, UI; it is better to design across vertical business layer.

II. Culture of Automation
As there is large number of deployable units, automation is way to manage containers at scale. It is quite important that to enable small teams that provision their infrastructure, manage & operate their service. Org should adopt CI/CD tools to automate deployments & releases as much as possible.

III. Hide Implementation Details

In microservice architecture, service design will also define the bounded context and API layer will manage the exposed data rather than multiple services hitting the same objects / or tables.

III. Decentralize All the Things

It is about service teams making their own smart decisions, and sharing best practices without centralized governance, and keeping messaging & middleware as dumb pipes business context creeping into gateway services.

IV. Deploy Independently

This directly relates to deployable dependencies and whether the service is running on VM / or as a container image. In SOA ecosystem, developer can develop independently but have to wait for scheduled deployment & releases, and a progressive approach is developed to reduce dependencies while evolving towards microservice architectures.

V. Consumer First

It is about getting feedback as you develop your APIs, and in the SOAP driven webservices, there is a WSDL document which is a spec driven way of telling about how to use your service. Similarly there are API documentation tools like Swagger & registries that provides a way of calling & discovering the service to your consumers.

VI. Isolate Failure

As you design many microservices, you have to think about how not to fail the application when a service fails to accept request or brought down. Pattern like circuit breaker, appropriate timeouts helps increase the resiliency of your application.

VII. Highly Observable

It is about understanding your deployed system, monitoring it as it runs & providing a faster & easier way to troubleshoot issues. It is suggested to have a log aggregation system which collects logs from all your services & provides some kind of query framework against the aggregated logs. Another design approach is to create a correlationID that traverses along the path of transaction & can provide a runtime view of the service model.