Source-linked AI summary
Microservices: yesterday, today, and tomorrow
Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente, Manuel Mazzara, Fabrizio Montesi, Ruslan Mustafin, Larisa Safina
TL;DR
Monolithic architectures create resource-allocation, scalability, and technology-lock-in problems, motivating microservices. This survey presents microservices evolution, architecture, practical issues, and open challenges, concluding that independent services support gradual updates and short redeployments while requiring compatible interface contracts.
Problem
Monoliths force one-size-fits-all deployment configurations, limit scalability, and create technology lock-in across modules.
Method
The paper provides an evolutionary survey connecting microservices with object-oriented and service-oriented paradigms, illustrated through architectural examples and practical issues.
Results
Independent microservices enable isolated testing, gradual version transitions, module-specific reboots, and short redeployment downtimes.
Takeaways & Limitations
Microservices support independently delivered business capabilities and continuous integration and delivery through automated pipelines.
Takeaways & Limitations
Independent technology choices complicate service composition because contract specifications and compatibility checkers differ or may be absent.
Abstract
from arXiv · showhide
Microservices is an architectural style inspired by service-oriented computing that has recently started gaining popularity. Before presenting the current state-of-the-art in the field, this chapter reviews the history of software architecture, the reasons that led to the diffusion of objects and services first, and microservices later. Finally, open problems and future challenges are introduced. This survey primarily addresses newcomers to the discipline, while offering an academic viewpoint on the topic. In addition, we investigate some practical issues and point out some potential solutions.
1 Introduction
Monoliths package modules into a single executable that shares machine resources, limiting independent execution, targeted scaling, and technology choice. Microservices address these issues through cohesive, independently deployed processes that coordinate via messages.
- Monoliths: Monolith modules share machine resources and therefore cannot be executed independently.This constrains modularisation to a single executable artefact.
- Monoliths: Monoliths require one-size-fits-all deployment configurations despite modules having different resource and component requirements.The resulting configuration may be expensive or sub-optimal, and scaling can allocate resources to unaffected modules.
- Microservices: Microservices are cohesive, independent processes that interact via messages and can be deployed in isolation with dedicated persistence tools.Cohesion means each service implements functionalities strongly related to its modeled concern.
- Microservice composition: A Plotter microservice can orchestrate Calculator and Displayer services to compute and display a function graph.This composition separates basic functionality from higher-level coordination.
- Benefits: Independent microservices limit bug scope, support isolated testing, and allow new versions to run alongside old ones during gradual transitions.These practices foster continuous integration and ease maintenance.
- Benefits: Microservice changes avoid rebooting the whole system, support short redeployment downtimes, enable per-service scaling, and reduce technology lock-in.Developers can choose implementation technologies per service, while communication requires compatible media, protocols, and encodings.
2 Yesterday
Software architecture evolved through object-oriented and component-based approaches toward service-oriented computing and then microservices. Microservices simplify service-oriented ideas by focusing on small services, while requiring specialized languages and development tools.
- Software architecture: Software architecture became an established research and practical field after foundational work in the early 1990s.Earlier decades saw growing concern with large-scale software development, design, and architecture.
- Object-oriented design: Object orientation contributed design patterns to software architecture, including the widely popularized patterns associated with Gamma et al.Model-View-Controller is identified as an earlier architectural pattern for graphical user interfaces.
- Component-based development: Component-based software engineering improved control over software design, implementation, and evolution before the shift toward services and microservices.The passage presents service orientation and microservices as subsequent developments in separation of concerns.
- Service-oriented computing: Service-Oriented Computing offers message-accessible functionality, separates interfaces from implementations, and uses workflow languages to orchestrate services.Its benefits include dynamism, modular reuse, distributed development, and integration of heterogeneous or legacy systems.
- Microservices: Microservices are presented as a second iteration of SOA and SOC that removes unnecessary complexity to focus on simple services implementing single functionalities.The approach retains service composition while targeting smaller application-level units.
- Open tooling needs: Microservices still need dedicated languages, testing suites, API design tools, and other development support.Most current architectures continue to use object-oriented or functional languages rather than languages designed specifically for services.
3 Today
Microservices extend service-oriented ideas to application architecture by decomposing systems into independent services, emphasizing maintainability, flexibility, and evolution. Their benefits come with distributed-systems costs, including integration, performance, security, and testing challenges.
- Architecture: Microservices decompose applications into small, independent services that can be developed and deployed separately.The approach emphasizes loose coupling, high cohesion, and independent delivery of business capabilities.
- State of the field: Microservices remain an emerging architectural style without consensus on their definition, characteristics, or best practices.The literature includes foundational definitions, recipes, and discussions of architectural patterns.
- Quality attributes: Microservices improve maintainability and testability by enabling isolated service changes and component-level testing.Large-scale integration testing remains difficult because anomalies can emerge from interactions among services.
- Coordination: Orchestration coordinates services through a central conductor, whereas choreography uses decentralized events and publish/subscribe mechanisms.Orchestration can simplify complexity but introduces service coupling and uneven responsibility distribution.
- Quality attributes: Network communication degrades performance relative to in-memory calls because network latency is substantially higher.Distributed integration mechanisms also create reliability concerns, particularly when networks are assumed to be reliable.
- Quality attributes: Security requires additional protection for data exchanged through REST, XML, and JSON, adding encryption overhead.The text relates microservices security vulnerabilities to those of SOA.
4 Tomorrow
Future work on microservices must address the difficulty of programming dependable distributed systems. Distribution supplies autonomy and loose coupling, but also introduces new coordination and error-management problems.
- Future challenges: Microservices research is still in an early stage, leaving important directions for advancing the paradigm.The paper presents these directions as future challenges rather than settled practices.
- Future challenges: Pervasive distribution creates autonomous, loosely coupled components but makes programming harder than in monolithic systems.The paper identifies service changes with possible side effects as one example of the new issues requiring attention.
- Future challenges: Preventing programming errors and building dependable systems remain challenging in microservice architectures.The paper frames these difficulties as recurring pitfalls of microservice development.
Interfaces
Microservice autonomy permits technology-specific implementation choices, but heterogeneous technologies make service contracts difficult to specify and verify. Current practice relies heavily on informal documentation, motivating technology-agnostic interface tools.
- Interfaces: Autonomous microservices can use the most appropriate technology for each service.Different technologies may specify composition contracts through incompatible mechanisms, while some lack specification languages or compatibility checkers.
- Interfaces: Informal natural-language service documentation makes client development error-prone because of potential ambiguities.The paper identifies informal documentation as the current answer for describing how clients should use services.
- Interfaces: Development support tools are lacking for checking whether service implementations correctly implement their interfaces.This limitation is stated alongside the reliance on informal documentation.
- Interfaces: Technology-agnostic message specifications can define service interfaces independently of implementation technologies and support compilation or message well-typedness checks.Such specifications may compile into language-specific interfaces or check messages independently of the transport protocol.
Behavioural Specifications and Choreographies
Interface compatibility is not sufficient when services exchange messages in ordered sessions. Behavioural types and interfaces address this limitation, and the paper identifies them as a future basis for compatibility checking and automated testing.
- Behavioural specifications: Formally defined APIs cannot guarantee compatibility when services must exchange messages in a precise execution order.Incompatible session behavior can produce problems such as closed-stream sends and deadlocks.
- Behavioural specifications: Behavioural types describe service behavior and can check whether multiple services have compatible actions.Session types are presented as a prominent example applied in parallel and distributed computing.
- Future directions: Behavioural interfaces may support automatic testing frameworks that check service communication behavior.The paper presents behavioural interfaces as an active topic likely to influence microservices development.
Choreographies
Choreographies describe desired system-wide communications and can generate compliant service implementations, supporting correctness by construction. Their future use in microservices remains constrained by compiler correctness, deployment dynamics, and limited expression of nondeterminism.
- Choreographies specify global communication behaviour rather than defining each service's behaviour separately.
- Choreographic Programming compiles choreographies into compliant implementations, guaranteeing properties such as deadlock-freedom and absence of communication errors.
- Choreographies can formalise communications during design, narrowing the gap between requirements and distributed implementations.
- Open challenges include compiler correctness, process mobility, runtime replication or failure, and limited expression of nondeterministic behaviour.
Moving Fast with Solid Foundations
The paper presents established formal methods and logical models as foundations for developing correct microservice systems. These foundations offer promising directions, but their extension to practical microservice scenarios remains unclear and requires empirical investigation.
- Behavioural types, choreographies, and refinement types specify, verify, and synthesise communication behaviours, but substantial work remains.
- Connections between behavioural types, choreographies, and logical models support results including polymorphism, choreography extraction, and multiparty-session reasoning.
- Choreographies have achieved Turing completeness and support correct-by-construction procedural programming for divide-and-conquer distributed algorithms.
- Formal methods based on established techniques are a promising starting point for writing correct microservice systems.
- It remains unclear how formal disciplines can naturally capture practical microservice scenarios, motivating empirical investigation of microservice programming.
4.2 Trust and Security
Microservices introduce trust and security challenges that are amplified by network-exposed APIs. The section examines these issues as a key concern of distributed microservice systems.
- Microservices create trust and security challenges that also affect service-oriented and distributed computing more broadly.
- Unlike monoliths, microservices communicate through network-exposed APIs that are independent of machine architectures and programming languages.
- Network-exposed APIs expand the attack surface beyond the single-OS setting typical of monolithic architectures.
Network Complexity
Decomposing applications into many independently interacting microservices can create complex network activity. This complexity makes enforcing security across the overall application more difficult, especially when services implicitly trust one another.
- Real-world decomposition can produce hundreds of microservices, creating intrinsically complex network activity.
- The resulting network complexity significantly increases the difficulty of enforcing security across the microservices-based application.
- Trusting every microservice is a strong assumption because services interact heterogeneously and openly across the network.
- If an individual microservice is compromised, the attack can affect the entire application rather than only that service.
Heterogeneity
Microservices maximize heterogeneity through many autonomous entities, administrative security domains, and cross-domain API interactions. The research community has not yet adequately addressed the resulting security challenges, leaving secure and trustworthy systems an open problem.
- Microservices can involve many autonomous entities, administrative security domains, and interactions across domains through APIs.
- Secure and trustworthy microservices-based systems remain an open challenge despite preliminary contributions.
5 Conclusions
The chapter presents microservice architecture as an increasingly popular style and explains its development through an evolutionary account connected to established paradigms. It offers newcomers an incomplete, selective starting point whose narrative emphasizes some connections and literature over others.
- Microservice architecture has increasingly gained popularity in academia and industry, prompting major back-end refactoring efforts in some companies.
- The chapter uses an evolutionary presentation to explain microservices’ motivations and relate them to object-oriented and service-oriented architectures.
- The overview is necessarily incomplete and selectively emphasizes certain connections and literature while treating other sources more severely.