Microservice Architectures

Definition of Microservice Architectures

The term “microservice” (MS) came about around 2012. Applications are developed as a suite of small MSs, each running in its own process.

Microservice architectures are built around business capabilities and make each MS independently deployable/upgradeable.

They may be written in different programming languages (“polyglot”) and use different data storage technologies (“polyglot persistence”).

They are communicating with a remote protocol like REST. Also common is messaging via a message bus.

Development teams for each MS are small. They are cross-functional, including the full range of skills required for the development: user-experience, database, and project management. In many organizations, the team’s responsibility does not end at a handover to operations, but it owns a product over its full lifetime (“you built it, you run it”).

Container technology is a major enabler for microservice architecture adoption. However, the former is a virtualization technology and the latter an architectural style/paradigm.

Applications must be designed so that they can tolerate the failure of a single microservice. This is much more difficult to achieve compared to a monolithic/traditional/single process design. While modern microservice runtimes like Kubernetes can help, developers still need to understand principles of distributed computing (e.g. stateless protocol design).

Monolithic solution versus microservice-based solution

Technology Evaluation

A microservice architecture is the state-of-the art approach to design server-side enterprise software. It is embraced by Software AG.

“Microservice” and “Service Oriented Architecture” (SOA) are both architecture paradigms, but not the same. MS is building on the SOA paradigm in the sense that every MS is exposing its functionality in form of (business) services, for which SOA standards like loose coupling or proper service governance should apply.

Relevance for IoT and Integration

The MS paradigm is fundamental for integration as well, as solutions which are composed of MSs have specific integration requirements in terms of used protocols, remote access, security, etc. Light-weight, technology-agnostic, web-based protocols and formats (HTTP, REST, JSON) are preferred.

In early discussions of MSs, using an Enterprise Service Bus (ESB) was said to be violating the “dumb pipes, smart endpoints” paradigm of MS and has been described as an antipattern. However, the core purpose of ESBs is to support a number of integration patterns, in particular asynchronous patterns. Asynchronous integration capabilities remain required and useful for MS architectures as well, as widely acknowledged today. Therefore, using an ESB is not an antipattern for MS architectures.

However, it is true that developers often tend to code business logic into the ESB and mingle it with logic that deals with technical integration (like attribute mapping). This causes many problems in the long run. So, keeping the “pipes dumb” (i.e., refrain from doing that) is indeed a best practice, but that is neither limited to MS architectures nor does it speak against using ESBs in them.

Market - Current Adoption

Market adoption is on the rise and Microservices are expected to remain the leading architecture paradigm, not the least because Microservices can be easily deployed to the Cloud. Even if a successor is found, it is expected to be building on it rather than contradicting it, so Microservies are a safe bet.

The lack of skilled human resources slow down Microservice adoption. However, in an era of overall IT skill shortage, it is hard to say whether this situation is specifically bad for Microservices, or rather an overall problem.

Given how fundamental the change to Microservices is, it is important not to forget that MSs are not everywhere yet, and that adoption by corporations all over the world will be a matter of decades.

How to adopt

In the vast majority of cases, adopting the MS paradigm for new applications is recommended. However, breaking up existing monolithic solutions into MSs is typically costly and often amounts to a complete re-implementation. In these cases, a careful service enablement of the monolith may be a sensible option.