Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Microservices & Its Cousins - a quick summary of key "service" concepts

1 Introduction

Everything comes in cycles; back in 2005 we [1] discussed, defined and developed SOA (Service Orientated Architecture) based solutions and today, when asked what the best in class software blueprint is, we refer to “Microservice(s)”.

Behind both terms sits the same and simple concept – to develop and design independent, “utility based” services that can drive and provide flexibility, security and agility.

As we are moving from 2nd to the 3rd Platform (2nd mainly refers to client server based computing and 3rd is the web native landscape, where users have access to apps and data from everywhere at any time with any device) more and more organisation move into a “Digital” landscape where applications, data and automation is king.

To achieve full digital maturity the organisation’s IT landscape has to conform to a clear set of design patterns – for instance ease of use, self-service, agility and flexibility and to accelerate the Digital journey, many organisations are now adopting a microservice(s) approach, benefiting from the value microservices can provide.

However, it can be tricky to navigate yourself around these terms and to provide some guidance on microservices, this document was created with the main intention to provide some detail on microservices as well as other “services” common in today’s “IT vocabulary”.

2 Key Concepts 

Service Architecture, SOA, Event Driven Architecture, microservices, SDDC (software defined data centre) and many other architectural buzzwords abound in technology at the moment. In the absence of standard definitions the common view is that Services are a business or technology capability, or physical products or an architecture approach. In fact a Service has many abstraction levels (Service as a word is being used in a number of different context) :

  • Service (Oriented) Architecture – a design pattern mostly related to an Enterprise Architecture related approach which is aligning business, information, information system and technical infrastructure
  • Business Services – a design approach for business operating models combining business processes and business events, and which have defined value contracts
  • Application Services – a design approach to deliver application function supporting Business Services, implemented through a variety of technology solutions and standards (this is where microservices are mostly related to)
  • Web Services – a special Application Service implemented using Web Services standards for mass access, specifically to receive and return XML documents as example within a defined contract; pervasive standards make the difference
  • Information Services – a design approach to deliver information to Application Services, implemented through a variety of technology solutions and standards
  • Infrastructure Services – specialised or shared infrastructure services which support Application, Web and Information services

The main intention of a Service based approach is to develop / create fine grained capabilities that can be easily used in different context settings.

Imagine an address lookup service (as a web service) to can provide street name based on a given postcode. Service based means that this address lookup service can be called from a mortgage quoting service or from a hotel room booking service (both also as an online service). Neither mortgage quoting nor the hotel room booking service have to know or understand how address lookup service obtains the street name.

All both care about is the format of the input needed and in what format the output will be provided. The other view is also true – the address lookup service does not need to know who (what service) has requested a postcode lookup. All it requires is the postcode in a particular format.

here are only a number of clear pre-For a Service based approach to work :

  • Agreed interfaces
    • Input and output format
    • Ways to invoke / request
  • Agreed service contracts
  • Service levels (duration of reply)
  • Service concurrency (how many requests per time unit)

3 Service Characteristics 
Regardless on the abstraction level as outlined above, a Service should follow these key characteristics:

  • loosely coupled and highly cohesive – independentagile and easily maintainableisolating change
  • defining discrete value – measurable and manageable as a business and IT asset; something we can have a value contract with
  • based on pervasive standards – highly accessible to humans and/or machines
  • non-functional definition and management – delivering quality of service
  • transparent to business analysis – propensity to support “top decile” operating models and processes
  • re-use – the mindset and execution to share servicesbalanced against the need for highly differentiated services
  • virtual and independent – separation of business, application and infrastructure services to reduce fixed asset costs and increase IT responsiveness to demand

It is “all about” aspects such as modularity, encapsulation, loose coupling, separation of concerns, reuse, compostable and single implementation. See Service Oriented Architecture Principles later in this document.

4 Microservices 
Microservice (architectural style) relates to a design pattern that is referring to a number of independent application services delivering one single business capability in an independent, loosely connected and self-contained fashion.

Following the SOA style (see below) Microservices are more autonomous, highly independent and much “smaller” / finer grained than their SOA based counterparts.

Microservices Architecture can be viewed as a “marriage” between Component Oriented Architecture and Service Oriented Architecture. Software as a suite is composed of many small business components with a very specific business domain responsibility. Their interface to the outside world is through an API[2] of clearly defined services.

An area where microservices departs radically from SOA is in the ownership model for the services: with microservices, only a single team or person will develop and change the code for a given service – Netflix is one organisation that is using this approach [7]. The reason Microservices has taken off is wholly down to their being a realisation of many aspects of Eric Evan’s Domain Driven Design [8] – in that they can be created and maintained by small, independent teams.   

Loosely coupled services can be updated independently of each other; a group of small services that have to be updated together are not microservices because they’re not loosely coupled. This also applies to sharing a database across services, where updating a particular service means changing the entire schema (or where a change to a shared schema results in a change to >1 microservice – an antipattern.

5 Microservices Best Practice 
A ‘Good’ microservice has / are / have

  • fine-grained capabilities that are stateless[3] and are “stupid”
  • well defined interfaces which ‘hide’ how the service is executed (i.e. I care about the interface, not how the service is executed under the covers).
  • a ‘very loosely-coupled’ approach (can change one service without impacting another),
  • “disposable”, & “no ESB[4] - “dumb pipes and smart services”
  • Autonomous, explicitly versioned & highly independent
  • stupid – ie “do one thing, and do it well”
  • cost and value fully defined.

6 Summary
Microservices are not the same as Service Orientated Architecture - Microservices is an approach that builds on the key SOA related characteristics and it is the basis for many current and future software development projects. As outlined by Martin Fowler [9] :"...an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."

References:
[1] See Capgemini’s SOA (Service Orientated Architecture) point of view papers as well as whitepapers [5,6] were we outlined the notion of “everything as a service” in 2005.
[2] API = Application Programme Interface
[3] This is becoming less the case in certain architectures. There was a talk at Strange Loop conference in 2015 around stateful microservices.  Statelessness does therefore not determine whether something is a “microservice”. It is however something to be avoided unless absolutely necessary.
[4] ESB = Enterprise Service Bus
[5] From Big to Small, Capgemini 2005, http://www.nlondon.bcs.org/pres/am2jan05.pdf
[6] Service-Oriented Enterprise: How To Make Your Business Fast, Flexible and Responsive, Capgemini 2005, http://www.cio.co.uk/cmsdata/whitepapers/3651/soe_flexibleresponsive.pdf
[7] Spotify, ,  https://vimeo.com/85490944
[8] Eric Evans, 2003, Domain-driven Design: Tackling Complexity in the Heart of Software
[9] Martin Fowler, http://martinfowler.com/articles/microservices.html

Special Thanks to Andrew Harmel-Law for the feedback and insight he provided.   
 

About the author

Gunnar Menzel, VP Enterprise Architect
Gunnar Menzel, VP Enterprise Architect

Leave a comment

Your email address will not be published. Required fields are marked *.