Towards an Understanding of Microservices

Abstract—Microservices architectures are a departure from traditional Service Oriented Architecture (SOA). Influenced by Domain Driven Design (DDD), microservices architectures aim to help business analysts and enterprise architects develop scalable applications that embody flexibility for new functionalities as businesses develop, such as scenarios in the Internet of Things (IoT) domain. This article compares microservices architecture with SOA and identifies key characteristics that will assist application designers to select the most appropriate approach. Keywords-Service Oriented Architecture (SOA), microservices, Domain Driven Design (DDD), Software Engineering I. INTRODUCTION Software engineering as a discipline is mature [1] and many approaches to developing software architectures have been proposed. Our focus is upon service-based approaches, in particular microservices. Service-Oriented Architecture (SOA) has been established for some time now and we have chosen to undertake a comparative study between SOA and microservices, to enable greater understanding of the relative characteristics of each approach. A. The context for services A clear methodology for structuring application logic first appeared with the advent of Jackson Structured Pro- gramming (JSP) [2]. JSP encouraged the maintenance of a library of subroutines, each of which would do one thing well (cohesion), for example printing a text string to the screen. In doing so, JSP promotes modularity and reuse of code blocks. Pervasive adoption of Object Orientation (OO) was the next paradigm shift [3]. OO focuses on creating code block abstractions (called objects) as a set of services that could be called by clients (other objects) [4]. This abstraction enables the object internals to be complex, often using services of other objects for business logic, data calculations and data transformation. Objects also encapsulate data and control access to data, for reading or for changing the encapsulated data [4]. An example of an object would be an IncomeTaxCalc object in an HR system. This object would provide a service for calculating income tax on an employee’s salary. It could encapsulate details of the personal taxation data provided by the government of the employee’s country of residence. It may not provide access to the encapsulated data as no other object in the system is likely to require access to this data. This object’s service comprises of business logic and data calculation. A client of this object may be the WageSlip object, to create the data necessary for an individual report of an employee’s contributions towards taxation. Another feature of OO that is pertinent to this discussion is messaging between the objects [4]. Objects publish well- specified interfaces and it is through these interfaces that services of objects are called by the clients. An interface to an object identifies the object, the block of code within the object that is to execute, parameters for the code, and any return type [4]. Abstraction can be described as the separation of interface of the object from the internal implementation of the object. By abstracting how an object is used from how an object works, dependency of the client upon the object is reduced [4]. Modularity is another inherent characteristic of object oriented systems. The aim of modularity is to decompose the application into highly modular objects, each of which encapsulates coherent functionalities that enable maximum reuse of the objects. Code reuse is ultimately the payback in OO. Good modularity and well-designed encapsulation results in highly reusable objects. As a consequence, object based development is generally considered to be system development at a low level of granularity [4]. Component- based system development was the next significant development. In an attempt to work at higher levels of granularity, a number of objects are packaged together as a component. The idea is that working with components (as opposed to objects) would increase productivity [4] as it would be working at relatively higher level of granularity, and therefore be easier to translate form and to business logic. WageSlip would be an example of a component that would encapsulate a number of objects such as IncomeTaxCalc, NationalInsuranceCalc and PensionCalc. Reuse of WageSlip would result in higher productivity payback. B. Service Oriented Architecture In Service Oriented Architecture (SOA), a service encapsulates a number of components into a single interface to provide a discrete business function. For example, a service to check a share pric

…(Full text truncated)…