In the recent times, microservice architecture, or simply microservices, has become quite popular. To put it into simple terms, microservices is a characteristic method of developing software systems and applications as a suite of independently deployable, small, modular services in which each service runs a distinct process and communicates through a well-defined, lightweight mechanism to serve a business purpose.
Origin of microservices
Microservices has a profound historical background. The term ‘microservices’ was used for the first time in mid-2011 at a workshop of software architects. After James Lewis laid out his ideas about microservices in 2012, several IT companies started considering the idea of microservices, and by 2014, large enterprises had started serious discussions about investing in it.
In 2014, James Lewis and Martin Fowler collaborated to provide a few real-world examples and presented microservices to the world. The major tenet of a microservice is its ability to take the place of services in a system that function independently from each other, the configuration around business capabilities and using smart endpoints and dumb pipes.
In the original object orientation model from the 1970s, an object is like a little computer that you send messages to and program it to perform tasks. The actor model is established on similar concepts, where the actor is the computer to which you send messages through its mailbox. Both of them are antecedents to the core aspects of microservices.
The idea came from the need of isolation between services. When you run every service in its own process within the same server, it is assured that a contract is followed. If all microservices are run inside the same process, all services will be eliminated if the process is resumed. When each service in run in its own process, it is ensured that only one service is eliminated in case the process is reinstated but if the server is restarted, it will eliminate all the services.
SOA vs Microservices
While many confuse microservices to be another name for Service-Oriented Architecture (SOA), they don’t know that traditional SOA is a broader framework and can mean a wide variety of things. Although they both rely on services as the main component, they vary greatly in terms of service characteristics.
The characteristic SOA model has, for example, more dependent ESBs, with microservices that use faster messaging mechanisms. SOA also emphasizes on imperative programming, whereas microservices architecture focuses on a responsive-actor programming style.
Additionally, SOA models generally possess an outsized relational database, while microservices usually utilize NoSQL or micro-SQL databases. However, the real variation lies in the architecture methods used to arrive at an integrated set of services in the first place. Also, while SOA places more importance on business functionality reuse, microservices emphasize on the concept of “bounded context”.
Benefits of SOA and microservices over monolithic architecture
Before we discuss the benefits of SOA and microservices over monolithic architecture, it is important to understand what monolithic architecture is. Monolithic architectures work on a single application layer that brings together all the functionalities required by the architecture. It is the simplest form of architecture because it doesn’t involve as many actors as other architectural styles.
The monolithic model works perfectly for small and mid-sized architectures and keeps the complications quite low: the problems usually appear when the architecture needs to scale up feature-wise since the modules are extensively dependent upon each other. SOAs usually incorporate functions into small/mid-sized applications and try to keep the complexity of each app / functionality very low and make them communicate over a set APIs (being them HTTP APIs, asynchronous messaging and so on).
In contrast, microservice capabilities are expressed formally with business-oriented APIs. They compress a root business ability, which are prized assets to the business. The execution of the service, which might require integrations with systems of record, is completely concealed. Dependencies between services and their consumer are diminished by applying the principle of loose coupling. By standardizing on contracts expressed through business-oriented APIs, consumers are not affected by changes in the implementation of the service. This allows service owners to change the implementation and modify the systems of record or service compositions which may lie behind the interface and replace them without any downstream impact.
When positioned properly, a microservices-based architecture or an SOA can bring substantial value to the business. That value can be expressed in both technical debt being avoided and a considerable increase in efficiency.
