@conference {2020:bac:iccs, title = {Microservice Disaster Crash Recovery: A Weak Global Referential Integrity Management}, booktitle = {International Conference on Computational Science}, year = {2020}, month = {June}, address = {Amsterdam, The Netherlands}, abstract = {Microservices which use polyglot persistence (using multiple data storage techniques) cannot be recovered in a consistent state from backups taken independently. As a consequence, references across microservice boundaries may break after disaster recovery. In this paper, we give a weak global consistency definition for microservice architectures and present a recovery protocol which takes advantage of cached referenced data to reduce the amnesia interval for the recovered microservice, i.e., the time interval after the most recent backup, during which state changes may have been lost.}, keywords = {BAC theorem, Microservices}, author = {Maude Manouvrier and Cesare Pautasso and Marta Rukoz} } @inbook {2020:restalk:ms, title = {Modeling Microservice Conversations with RESTalk}, booktitle = {Microservices}, year = {2020}, pages = {129--146}, publisher = {Springer}, organization = {Springer}, abstract = {Microservices are characterized by their small size and low degree of coupling. As a consequence, building microservice architectures requires composing multiple microservices and determine how they interact to achieve a given client{\textquoteright}s goal. In this chapter we introduce the concept of RESTful conversation, whereby clients or API gateways perform multiple basic HTTP request/response interactions with one or more microservice APIs. To represent possible sequences of interactions, we introduce the RESTalk visual notation, as well as its textual DSL, and the corresponding metamodel, and show how it can be used to complement existing structural approaches to represent RESTful APIs, such as the OpenAPI Specification. To reveal the degree of coupling between clients and microservices, the language supports the concept of hyperlink flow, showing whether, within a conversation, the links embedded into responses provided by a microservice are used by the client/API gateway to form the subsequent requests.}, keywords = {API, conversation, Microservices, RESTalk}, doi = {10.1007/978-3-030-31646-4_6}, author = {Ana Ivanchikj and Cesare Pautasso} } @conference {2019:map:europlop, title = {Interface Evolution Patterns {\textemdash} Balancing Compatibility and Flexibility across Microservices Lifecycles}, booktitle = {24th European Conference on Pattern Languages of Programs (EuroPLoP 2019)}, year = {2019}, month = {July}, publisher = {ACM}, organization = {ACM}, address = {Irsee, Germany}, abstract = {Remote Application Programming Interfaces (APIs) are technology enablers for distributed system trends such as cloud-native application development. API providers find it hard to design their remote APIs so that they can be evolved easily; refactoring and extending an API while preserving backward compatibility is particularly challenging. If APIs are evolved poorly, clients are critically impacted; high costs to adapt and compensate for downtimes may result. For instance, if an API provider publishes a new incompatible API version, existing clients might break and not function properly until they are upgraded to support the new version. Hence, applying adequate strategies for evolving service APIs is one of the core problems in API governance, which in turn is a prerequisite for successfully integrating service providers with their clients in the long run. Although many patterns and pattern languages are concerned with API and service design and related integration technologies,patterns guiding the evolution of APIs are missing to date. Extending our pattern language on Microservice API Patterns (MAP), we introduce a set of patterns focusing on API evolution strategies in this paper: API Description, Version Identifier, Semantic Versioning, Eternal Lifetime Guarantee, Limited Lifetime Guarantee, Two in Production, Aggressive Obsolescence, and Experimental Preview.The patterns have been mined from public Web APIs and industry projects the authors have been involved in.}, keywords = {API, API Evolution, Microservices, patterns}, doi = {10.1145/3361149.3361164}, url = {https://dl.acm.org/citation.cfm?id=3361164}, author = {Daniel L{\"u}bke and Olaf Zimmermann and Cesare Pautasso and Uwe Zdun} } @article {2018:ieeecloud:bac, title = {Consistent Disaster Recovery for Microservices: the BAC Theorem}, journal = {IEEE Cloud Computing}, volume = {5}, year = {2018}, month = {January/February}, pages = {49-59}, abstract = {How do you back up a microservice? You dump its database. But how do you back up an entire application decomposed into microservices? In this article, we discuss the tradeoff between the availability and consistency of a microservice-based architecture when a backup of the entire application is being performed. We demonstrate that service designers have to select two out of three qualities: backup, availability, and/or consistency (BAC). Service designers must also consider how to deal with consequences such as broken links, orphan state, and missing state.}, keywords = {availability, BAC theorem, consistency, disaster recovery, Microservices}, doi = {10.1109/MCC.2018.011791714}, url = {http://ieeexplore.ieee.org/document/8327550/}, author = {Guy Pardon and Cesare Pautasso and Olaf Zimmermann} } @conference {2018:map:icsoc, title = {Guiding Architectural Decision Making on Quality Aspects of Microservice APIs}, booktitle = {16th International Conference on Service-Oriented Computing (ICSOC 2018)}, volume = {11236}, year = {2018}, month = {November}, pages = {73-89}, publisher = {Springer}, organization = {Springer}, address = {Hangzhou, Zhejiang, China}, abstract = {Microservice APIs represent the client perspective on microservice-based software architecture design and related practices. Major issues in API design concern the quality aspects of the API. However, it is not well understood today what the established practices related to those quality aspects are, how these practices are related, and what the major decision drivers are. This leads to great uncertainty in the design process. In this paper, we report on a qualitative, in-depth study of 31 widely used APIs plus 24 API specifications, standards, and technologies. In our study we identified six recurring architectural design decisions in two API design contexts with a total of 40 decision options and a total of 47 decision drivers. We modelled our findings in a formal, reusable architectural decision model. We measured the uncertainty in the resulting design space with and without use of our model, and found that a substantial uncertainty reduction can be potentially achieved by applying our model. }, keywords = {API, Microservices, quality}, doi = {10.1007/978-3-030-03596-9_5}, author = {Uwe Zdun and Mirko Stocker and Olaf Zimmermann and Cesare Pautasso and Daniel L{\"u}bke} } @conference {2018:map:europlop, title = {Interface Quality Patterns --- Crafting and Consuming Message-Based Remote APIs}, booktitle = {23rd European Conference on Pattern Languages of Programs (EuroPLoP)}, year = {2018}, month = {July}, publisher = {ACM}, organization = {ACM}, address = {Kloster Irsee, Germany}, abstract = {The design and evolution of Application Programming Interfaces (APIs) in microservices architectures is challenging. General design issues in integration and programming have been covered in great detail in many pattern languages since the beginnings of the patterns movement, and service-oriented infrastructure design patterns have also been published in the last decade. However, the interface representations (i.e., the content of message payloads) have received less attention. We presented five structural representation patterns in our previous work; in this paper we continue our coverage of the API design space and propose five interface quality patterns that deal with the observable aspects of quality-attribute-driven interface design for efficiency, security, and manageability: An API Key allows API providers to identify clients. Providers may offer rich data contracts in their responses, which not all consumers might need. A Wish List allows the client to request only the attributes in a response data set that it is interested in. If a client makes many API calls, the provider can employ a Rate Limit and bill clients according to a specified Rate Plan . A provider has to provide a high-quality service while at the same time having to use its available resources economically. The resulting compromise is expressed in a provider{\textquoteright}s Service Level Agreement. }, keywords = {interfaces, Microservices, patterns, quality}, author = {Mirko Stocker and Olaf Zimmermann and Daniel L{\"u}bke and Uwe Zdun and Cesare Pautasso} } @article {2017:sw:ms1, title = {Microservices in Practice (Part 1): Reality Check and Service Design}, journal = {IEEE Software}, volume = {34}, year = {2017}, month = {January-February}, pages = {91-98}, keywords = {Microservices}, doi = {10.1109/MS.2017.24}, url = {http://ieeexplore.ieee.org/document/7819415/}, author = {Cesare Pautasso and Olaf Zimmermann and Mike Amundsen and James Lewis and Nicolai Josuttis} } @article {2017:sw:ms2, title = {Microservices in Practice (Part 2): Service Integration and Sustainability}, journal = {IEEE Software}, volume = {34}, year = {2017}, month = {March-April}, pages = {97-104}, keywords = {Microservices}, doi = {10.1109/MS.2017.56}, url = {http://ieeexplore.ieee.org/document/7888407/}, author = {Cesare Pautasso and Olaf Zimmermann and Mike Amundsen and James Lewis and Nicolai Josuttis} }