Microservices architecture

Micro services architecture is the "in thing" these days. It is generating sufficient chatter. Twitter is doing it, so is tumblr and number of different online services organizations.

It is right now at a stage where it is more a buzz word then a concrete concept. Technical folks are figuring out how micro services architecture would work for their particular domain or product.

In general what benefits do people derive from micro services?

1. Modifiability
2. Ease in rapidly deploying code to production (Multiple times a day)
3. Reduced testing effort
4. Faster feedback.
5. More freedom to experiment.

Rather than providing a formal specification of the architectural style, let us jot down some constraints that are applied to architecture conforming to this style.

Size

1. Services are very small. To quantify very small, it is typically code that fits within a single screen.
2. Small enough to rewrite rather than refactor.

When we talk about the size, we are talking about the business logic embedded in the micro service.

Rest of the working code which supports the business use case should be consumed as a part of a framework. For example, if the service requires to perform some database operations, then we are going to depend on a framework that facilitates the communication.

The key here is to understand that the frameworks are generic. As a philosophy I prefer opensource,

Single Responsibility Principles

1. Each micro service does just one thing and does that very well.
2. The micro services are loosely coupled
3. Represent behaviour and not feature

The process of establishing and realizing an architecture is inherently bound to the process of decomposing a problem domain into small manageable units.Single responsibility principle is a sound one regardless of what  architectural style we are dealing with.

Fred George makes a point in his talk where he advices that a micro service should not even be aware of any other micro service.He talks about a rapids - rivers - ponds concept which is pretty interesting way of decoupling the services. Have a look at the talk here

Often, developers take an approach, where they endeavour to capture an entire feature in a micro service. That might very well be a mistake. The right approach is to model behaviour and not feature within a micro service.

A feature can have any size, and therefore may be limited to a single micro service or scattered across multiple services.

Deployment

1. Automated provisioning.
2. Containerless.

Supporting micro services architecture without a robust continuous delivery pipeline is not possible.

Micro services should be as lightweight as possible. It should be possible to manage life cycle of each micro service independently. To do away with any excess baggage, it is advisable to not deploy the services in heavy application servers.

Versioning

Micro services at the very base is all about Litheness+Loose coupling . Each of the micro service should have its own life cycle independent of the other.

In practice, we might have a service being upgraded and modified much faster then it's consumer.

API Versioning could help us achieve the velocity of changes we need, within this architectural paradigm.

Well behaved services

Well behaved services adhere to published contracts when participating in conversations -

1. Obeying business rules under all circumstances
2. Consistent error reporting
3. Do not consume excessive resources and obey all non functional requirements.

For ensuring good behaviour, it is important to monitor the services behaviour. The number of services in the deployment are expected to be higher when compared to other architectural styles. Naturally, robust automation is required which allow introspection of services. 

Following are the recommended practices

1. Watchdog processes for in-app monitoring
2. Publishing current status and health information on a well known URL
3. Publishing the health status of all the dependencies