Microservices, a different SOA approach

What are microservices?

Have you heard of Microservices yet? First time I heard the word I had strong associations with a new appliation for bacterial life in food processing. Maybe my background in biochemistry got the better of me.

Actually, the Microservices Architecture (MSA) is a new sprout on the ever-growing tree of Service-Oriented Architecture concepts. The definition sounds vaguely familiar: A particular method of designing (usually complex) enterprise software applications as suites of small, independent services, communicating with each other using language-agnostic API’s.

Yes, that reminds us of the definition of a service-oriented architecture. There are many similarities. Both service types are designed to be easily replaceable, fit into a continuous delivery development process, are language-agnostic (that is, many programming languages and backends can be used in conjunction) and each service represents an element of functionality.

There is one major difference. Where a SOA focusses on integrating a multitude of enterprise applications, a  MSA consists of one application, developed as a suite of small services. The communication makes use of lightweight API’s, for instance with REST, and there is hardly any centralized management.

There are many benefits to this type of architecture. A few are mentioned here:

Independence by decoupling

With correctly decoupled services, the change of one service has minimal impact on other parts of the application

Scalability

As opposed to a “monolithic” application, microservices can be scaled individually, adapting the resource usage independently to the needs for each individual service.

Agility by diversity

Because every service has a very distinct task, the opportunity arises to create that service in the language that is most suitable for that task.

Business capability-oriented instead of siloed.

What’s often seen in software development, is that the grouping of development activities and hence the creation of teams is based on the technology layer, for instance DBA’s, frontend-developers and integration specialists. The design becomes a copy of the organization structure. MSA has a a natural tendency to create services that represent business capabilities, wherein a multidisciplinary approach is key.

Old wine in a new bottle?

Well, yes, in some ways. strong decoupling of functions is a proven technique and a very old one too. (I think UNIX here). SOA is there for some time, and we mentioned the analogies with MSA. But why not pick the strengths of every architecture, while leaving the weaknesses behind? Cross-over ideas to other disciplines, evolution in ICT architecture. Maybe my association with biochemistry wasn’t that far-fetched at all.