practicing techie

Based on the steady flow of recently published technology articles and blog posts, as well as upcoming tech conference program session titles, it seems evident that the buzz on microservices, doesn’t show signs of tailing off in the near future.

As a concept, microservices based architecture, or just microservices, is quite old by IT standards, and it first came into ThoughtWorks’ Technology Radar already in 2012. Last year when I visited QCon New York microservices architecture was one of the major themes with one track and lots of sessions dedicated to the topic. Microservices also played roles of varying importance also in other track sessions.

At QCon, microservices was often characterized as “SOA done right” or “SOA without the ESB” by speakers and attendees alike. Many of the microservices track sessions focused on various practical issues encountered when implementing microservices including:

• service isolation vs. sharing
• managing dependencies
• importance of durable logical data model and API design
• managing and validating interface changes
• polyglot service API clients etc.
• test automation
• service API documentation

These topics were covered by plenty of speakers from different angles. Michael Bryzek of Gilt gave a good discussion of these issues in his talk on Microservices and the art of taming the Dependency Hell Monster.

In the Microservice open space much of the discussion revolved around defining the boundaries of a microservice: to what extent should a microservice be an entity isolated from its environment? A microservice can form dependencies to its environment through a wide variety of aspects, including logical data model, data model implementation, logical and physical runtime platforms, data storage systems and other microservices. To what degree should a microservice be allowed to depend on its environment or other microservices? How to balance aspects of reuse and isolation?

Microservices based architecture is often contrasted with SOA, with SOA being scorned at and ridiculed as the old way of doing things. Nevertheless, many of the problems and solutions related to microservices based architectures remind me of SOA literature of past years, so I decided to dust off some of my Thomas Erl SOA books to brush up my memory. According to Erl, service-orientation is a design paradigm that adheres to the following principles:

Standardized service contract – “Services within the same service inventory are in compliance with the same contract design standards.”
The same design standards are applied to related services. In particular, this means the data models are coherent across related services and some common type definitions can be shared. Standardization also applies to other aspects such as policy and SLA.

Service loose coupling – “Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.”
Service consumers are necessarily dependent on the contract that a service provides. This principle states that the API surface area, through which consumers interact with a service, should be minimized and explicitly defined, so that consumers can withstand evolution of services. Services are also decoupled from their runtime environment.

Service abstraction – “Service contracts only contain essential information and information about services is limited to what is published in service contracts.”
A service should be considered as a black box that provides a work specified by its service contract for consumers and hides other meta data and implementation details. Service contract should expose only information essential for accessing the service.

Service reusability – “Services contain and express agnostic logic and can be positioned as reusable enterprise resources.”
Organizational project delivery processes should prefer to implement business logic as reusable services and to use existing services over re-implementing business logic

Service autonomy – “Services exercise a high level of control over their underlying runtime execution environment.”
Services that depend on shared virtual or physical resources (e.g. database, other information systems or services, physical hardware) necessarily lose some of their autonomy, which can lead to unpredictable runtime behaviour. High level of autonomy can be costly and tradeoffs often need to be made.

Service statelessness – “Services minimize resource consumption by deferring the management of state information when necessary.”
“State data management consumes system resources and can result in a significant resource burden … Therefore, the temporary delegation and deferral of state management can increase service scalability and support a wider range of reuse and recomposition over time.”

Service discoverability – “Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.”
Additional metadata is used to describe services to help humans looking to find existing services to reuse in their project delivery.

Service composability – “Services are effective composition participants, regardless of the size and complexity of the composition.”
Services should be designed and implemented in a manner that does not limit them composing them into new services, in different layers

Most of these principles are quite general, technology agnostic and also very much relevant in a microservices based architecture. One thing they share is that at their core both are architectural styles and not technologies. Still, microservices and SOA are perceived in quite a different manner. SOA started gaining momentum in the era of the enterprise architect, and arguably, the voice of the practitioners (i.e. developers) was lost as SOA got hijacked by software tool industry heavyweights. Nowadays SOA is often regarded as enterprisey and associated with heavy tooling and onerous processes.

Microservices architecture on the other hand is associated with promoting a much leaner approach overall. There’re also some interesting relations that microservices has with the structure of the development organization. Many leading internet companies are organizing their development work around agile, small (“2 pizza” sized), autonomous teams with well-defined end-to-end responsibilities, in order to scale their organization better. According to Conway’s law organizations “are constrained to produce designs which are copies of the communication structures of these organizations“. In that sense,  microservices architecture reflects organizational structures of the development teams as well as the current best practice technological means of achieving team autonomy.

I like the pragmatism and the strive for lean practices in contemporary software development in general, and in implementing microservices in particular. However, the baby often seems to get thrown out with the bathwater when our industry is too busy reinventing things. A sign of this is that microservices developers clearly are rediscovering many of the insights that SOA architects and developers learned and documented long ago.