Microservices is a new software architecture and delivery paradigm, where applications are composed of several small runtime services.

The current mainstream approach for software delivery is to build, integrate, and test entire applications as a monolith. This approach requires any software change, however small, to require a full test cycle of the entire application.

With Microservices a software module is delivered as an independent runtime service with a well defined API. The Microservices approach allow faster delivery of smaller incremental changes to an application.

There are several tradeoffs to consider with the Microservices architecture. On one hand, the Microservices approach builds on several best practices and patterns for software design, architecture, and DevOps style organization. On the other hand, Microservices requires expertise in distributed programming and can become an operational nightmare without proper tooling in place. There are several good posts that highlight the pros-and-cons of Microservices, and I have added in the references section.

In the remainder of this post, I will define five architectural constraints (principles that drive desired properties) for the Microservices architectural style. To be a Microservice, a service must be:

1. Elastic
2. Resilient
3. Composable
4. Minimal, and;
5. Complete

Microservice Constraint #1 – Elastic

A microservice must be able to scale, up or down, independently of other services in the same application.

This constraint implies that based on load, or other factors, you can fine tune your applications performance, availability, and resource usage.

This constraint can be realized in different ways, but a popular pattern is to architect the system so that you can run multiple stateless instances of each microservice, and there is a mechanism for Service naming, registration, and discovery along with routing and load-balancing of requests.

Microservice Constraint #2 – Resilient

A microservice must fail without impacting other services in the same application.

A failure of a single service instance should have minimal impact on the application. A failure of all instances of a microservice, should only impact a single application function and users should be able to continue using the rest of the application without impact.

Adrian Cockroft describes Microservices as loosely coupled service oriented architecture with bounded contexts [3]. To be resilient a service has to be loosely coupled with other services, and a bounded context limits a service’s failure domain.

Microservice  Constraint #3 – Composable

A microservice must offer an interface that is uniform and is designed to support service composition.

Microservice APIs should be designed with a common way of identifying, representing, and manipulating resources, describing the API schema and supported API operations. The ‘Uniform Interfaces constraint of the REST architectural style describes this in detail.

Service Composition is a SOA principle that has fairly obvious benefits, but few guidelines on how it can be achieved. A Microservice interface should be designed to support composition patterns like aggregation, linking, and higher-level functions such as caching, proxies and gateways.

I previously discussed REST constraints and elements in as two part blog post: REST is not about APIs

Microservice  Constraint #4 – Minimal

A microservice must only contain highly cohesive entities

In software, cohesion is a measure of whether things belong together. A module is said to have high cohesion if all objects and functions in it are focused on the same tasks. Higher cohesion leads to more maintainable software.

A Microservice should perform a single business function, which implies that all of its components are highly cohesive. This is also an Single Responsibility Principle (SRP) of object-oriented design [5]

Microservice Constraint #5 – Complete

A microservice must be functionally complete

Bjarne Stroustrup, the creator of C++, stated that a good interface must be, “minimal but complete” i.e. as small as possible, and no smaller.

Similarly, a Microservice must offer a complete function, with minimal dependencies (loose coupling) to other services in the application. This is important, as otherwise its becomes impossible to version and upgrade individual services.

This constraint is designed to oppose the minimal constraint. Put together a microservice must be “minimal but complete.”

Conclusions

Designing a Microservices application requires application of several principles, patterns, and best practices of modular design and service-oriented architectures. In this post, I’ve outlined five architectural constraints which can help guide and retain the key benefits of a Microservices-style architecture.

For example, Microservices Constraint# 1 – Elastic steers implementations towards separating the data tier from the application tier, and leads to stateless services.

At Nirmata we have built our solution, that makes it easy to deploy and operate microservices applications, using these very same principles. We believe that Microservices style applications, running in containers, will power the next generation of software innovation.

If you are using, or interested in using microservices, I would love to hear from you.

Jim Bugwadia

Founder and CEO
Nirmata

For more updates and news follow us at:    

 

If you are in the San Francisco Bay Area, come join our meetup group.

References

[1] Microservices, Martin Fowler and James Lewis,
http://martinfowler.com/articles/microservices.html
[2] Microservices Are Not a free lunch!, Benjamin Wootton,
http://contino.io/microservices-and-architectural-evolution/
[3] State of the Art in Microservices, Adrian Cockroft,
http://thenewstack.io/dockercon-europe-adrian-cockcroft-on-the-state-of-microservices/
[4] The Principles of Object-Oriented Design, Robert C. Martin,
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod