Here is the first post in the series, as I talked about in the prelude. Let’s get right to it.
Microservices is a style of architecture that has gained popularity in the last couple of years and used by successful big companies like Google, Amazon, NetFlix, Twitter, SoundCloud, Gilt and many others. With all the success that this architectural style has seen in the real world, it looks like it is set to become the default enterprise architectural style.
Ok, so let’s demystify this thing called microservices. (If at first you thought they meant small services, you are not wrong but that is just the beginning.)
So how do you define microservices ? Is there a formal agreed upon definition ?
Microservices evolved over time from practice rather than based on any one theory. So as such there is not one standardized definition for it. However, from the two books out on microservices, here is how each defines it.
Microservices are small, autonomous services that work together
Sam Newman, ‘Building Microservices’
A microservice is an independently deployable component of bounded scope that supports interoperability through message-based communication. Microservice architecture is a style of engineering highly automated, evolvable software systems made up of capability-aligned microservices.
‘MicroService Architecture: Aligning Principles, Practices and Culture’
So if you break it down to simpler terms, the main defining characteristics are:
- It is suitable for large distributed systems. Instead of having one big application serve your needs, you now have a bunch of much smaller services working together to serve the same needs.
- They are bounded in terms of both functionality and data (Bounded Context pattern – More on that in another post)
- The services publish well defined APIs. The APIs are typically technology agnostic.
- They are completely independent of each other, each running in their own process. They are independently deployable and replaceable without affecting any of the other services in the system.
- The services use a lightweight communication mechanism to talk to each other.
- The services are built around business needs of the domain rather than technological considerations.
- The technology used by the services can be mixed and matched resulting in a polyglot system.
- Decentralization of software, data and organizational structure. Think Amazon’s ‘You build it, you run it’ approach.
- The build and release processes are automated to a large extent.
- Microservices align with Agile methodology
The last point is of particular interest. If you look at the history of microservices and the companies that have successfully applied it, a common factor in addition to the architectural patterns, is how they have implemented it at the organizational level and the cultural practices that go with it. They have all use cloud infrastructure, heavily automated their processes, with an emphasis on speed of delivery while adapting to changes in requirements. They have also integrated teams that combines development and operations (DevOps).
If you look at the agile manifesto, it aligns neatly with the characteristics of a microservices architecture. SoundCloud is a case in point -They adopted agile practices and found that when they moved to microservices from a monolithic system, it aligned better with their agile methods. This is what the experts are saying with regards to it :
Microservices are the architectural phase of the agile progression
Matt Mclarty. Source
Many organizations have found that by embracing fine-grained, microservice architectures, they can deliver software faster and embrace newer technologies. Microservices give us significantly more freedom to react and make different decisions, allowing us to respond faster to the inevitable change that impacts all of us.
If we look at the characteristics of an agile software architecture, we tend to think of something that is built using a collection of small, loosely coupled components/services that collaborate together to satisfy an end-goal. This style of architecture provides agility in a number of ways. Small, loosely coupled components/services can be built, modified and tested in isolation, or even ripped out and replaced depending on how requirements change. This style of architecture also lends itself well to a very flexible and adaptable deployment model, since new components/services can be added and scaled if needed
Simon Brown. Source
So in conclusion, we can see that microservices are defined more by a common set of patterns, properties and organizational structures and cultures that support it, rather than a set of rigid rules. The flexibility to adapt it your needs to deliver quality products to scale and speed is the essence of the microservices style.
Further Reading : Microservices Resource Center
If you have the time, Martin Fowler has written an in depth article at their resource center and I suggest you head over there for a more detailed read.