Monday, 5 August 2013

Micro Service Architecture

Micro service architecture is a paradigm that aims to build systems by decomposing business features into lightweight services. It is like applying SOLID principles at architectural level.

micro service architecture
Micro Services
Micro service architecture enhances classic SOA architecture by emphasising on one single responsibility. Conceptually micro services aren’t particularly difficult to delivery, but in practice some questions can raise.

Features of micro services

By definition a micro service is very small and has a small footprint. It takes a few minutes to complete a CI build including unit and integration tests. Micro services can be short lived (disposed once business doesn’t need it ) in a long-living software eco system. Micro services are likely not to like heavy frameworks, applications servers which could be a negative in some cases.
Another nice thing of these services is that they can be language agnostic, so a heterogeneous development team can build services with different languages provided service communication is abstracted into some forms. Moreover micro services can have multiple versions in production systems (that may bring additional work to DevOps).

Service communication

There isn’t a silver bullet for this one. It probably depends on role of these services, it’s high likely there are different communication paths amongst the services, say public network services could use HTTP, REST and JSON for data exchange, while internal services can leverage more efficient protocols, like Protobuf and may interact via message bus.

Service delivery

Micro services are relatively easier to develop and deliver to production systems given the development focus is on a one feature set. Moreover it is possible to have multi instance multi versioned services in production systems. These services can have multiple instances to handle high volume traffic, while multi instance deployment may require some design changes, for example instances can be made data agnostic, or each instance can handle specific traffic.(e.g. customer/location segmented etc.)
Having multiple instances and versions is not cost free, first of all it requires exposing versioned service interaction points, moreover deployment and provisioning will have some overhead,  however it is totally achievable to reduce overhead of DevOps works with change and configuration management systems. Infrastructures can be virtualized and service configuration be managed with tools like Chef and Puppet.