Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption

524 views

Published on

5th of April 2017. My presentation done at the 14th International Conference on Software Architecture (ICSA), Gothenburg, Sweden.

Microservices are a new trend rising fast from the enterprise world. Even though the design principles around microservices have been identified, it is difficult to have a clear view of existing research solutions for architecting microservices.
A systematic mapping study methodology has been used to identify, classify, and evaluate the current state of the art on architecting microservices from the following three perspectives: publication trends, focus of research, and potential for industrial adoption. More specifically, we systematically define a classification framework for categorizing the research on architecting microservices and we rigorously apply it to the 71 selected studies. We synthesize the obtained data and produce a clear overview of the state of the art. This gives a solid basis to plan for future research and applications of architecting microservices.

Accompanying paper: http://www.ivanomalavolta.com/files/papers/ICSA_2017.pdf

Published in: Technology
  • Be the first to comment

Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption

  1. 1. Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption *paolo.difrancesco@gssi.it ‡{p.lago, i.malavolta}@vu.nl Paolo Di Francesco*, Patricia Lago‡, Ivano Malavolta‡
  2. 2. 2Di Francesco, Lago, Malavolta Paolo Di Francesco Roadmap • Microservice Architectures (MSAs) • Study Design • Results • Conclusions Roadmap
  3. 3. 3Di Francesco, Lago, Malavolta Paolo Di Francesco Microservice architectures MSA is an architectural style inspired by service-oriented computing • Small services • Running in own process • Lightweight communication Introduction
  4. 4. 4Di Francesco, Lago, Malavolta Paolo Di Francesco Microservice architectures • Products not Projects • Cross-functional teams • Infrastructure automation • Intelligence in the endpoints • Decentralized governance of • Language • Data Introduction Delivery Pipelines Teams Capabilities
  5. 5. 5Di Francesco, Lago, Malavolta Paolo Di Francesco Problem Difficult to have a clear view of existing research solutions for architecting microservices Introduction 978-1-5090-2246-5/16/$31.00 ©2016 IEEE Leveraging microservices architecture by usingDocker technology David JaramilloCloud Engineering and Services IBM Boca Raton, FL, USA djaramil@us.ibm.com Duy V Nguyen Cloud Engineering and Services IBM Boca Raton, FL, USA dnguyenv@us.ibm.com Robert Smart Emerging Technologies IBM Hursley, United Kingdomsmartrob@uk.ibm.com Abstract— Microservices architecture is not a hype and for awhile, started getting attention from organizations who want to shorten time to market of a software product by improving productivity effect through maximizing the automation in all life circle of the product. However, microservices architecture approach also introduces a lot of new complexity and requires application developers a certain level of maturity in order to confidently apply the architectural style. Docker has been a disruptive technology which changes the way applications are being developed and distributed. With a lot of advantages, Docker is a very good fit to implementing microservices architecture. In this paper we will discuss about how Docker can effectively help in leveraging mircoservices architecture with a real working model as a case study. Keywords—micoservices; docker; devops; automation I. INTRODUCTIONA common way to build software applications until now is the monolithic approach where one deployment unit has several responsibilities and in some cases it does mostly everything. Monolithic approach is still good for small scale teams and projects, but when scalability, flexibility and other requirements like fast development, short time to market, wider team collaboration, and so on become more and more critical to achieve business competitiveness, monolithic starts becoming a big barrier. It’s much harder to make changes to the application in responding to radical change requirements from users or business model frequently, as the code base becomes bigger, more complicated with more people making changes to it. The tightly coupled model of monolithic approach natually requires incremental amount of effort to coordinate to make any must- have updates which consequently slows down the release cycle of the application as well as contributes further to its fragility Microservices architectural approach was introduced as a solution to solve the monolithic problem. Even though it’s in theory supposed to address most of the problems occured in mononithic approach, but Microservices also has a long downsides list which emphasizes the requirement to have a certain level of maturity in automation and agility for the developers to be able to make use of it’s advantages. Containerization technologies where Docker is leading is really accelerating the application of microservices architecture in a lot of use cases. II. MICROSERVICES ARCHITECTUREMicroservices are small autonomous services that work together to fulfill a business requirement. This section will discuss about some basic concepts and characteristics in micoservice architecture. A. Small and focussed Even though “small” is not a very good measure to describe microservices but we can use it as an attempt to emphasize one of the most important characteristics of microservices that is each service is fine-grained, high cohesion to focus on fulfilling a granular responsibility. In the enterprise context, microservices should be designed with business oriented driver in mind. That means the resulting services should not mimic organization, technological or communication boundaries. In stead, they should be modelled around specific business domain. From development perspective, each service should be treated as an independant application with its own source code repository and delivery pipeline. B. Loosly coupled Loose coupling is an essential characteristic of microservices. Each microservice needs to be deployed as
  6. 6. 6Di Francesco, Lago, Malavolta Paolo Di Francesco Solution SYSTEMATIC MAPPING STUDY • Unbiased • Objective • Systematic • Answer a set of research questions by analysing all relevant research contributions Introduction
  7. 7. 7Di Francesco, Lago, Malavolta Paolo Di Francesco Systematic mapping study • RQ1: What are the publication trends of research studies about architecting microservices? • RQ2: What is the focus of research on architecting microservices? • RQ3: What is the potential for industrial adoption of existing research on architecting microservices? Systematic Mapping Study
  8. 8. 8Di Francesco, Lago, Malavolta Paolo Di Francesco Systematic mapping study Systematic Mapping Study 342 297 (architect* OR design* OR system OR structur*) AND (microservi* OR micro-servi* OR "micro servi"*)
  9. 9. 9Di Francesco, Lago, Malavolta Paolo Di Francesco Systematic mapping study RQ1: What are the publication trends of research studies? • Scientific interest, venues, and contribution types RQ2: What is the focus of research? • Understanding of current research gaps • Classification framework RQ3: What is the potential for industrial adoption of existing research? • Are we ready to be transferred to industry? Systematic Mapping Study
  10. 10. 10Di Francesco, Lago, Malavolta Paolo Di Francesco RQ1 – Publication trends Finding: Publication venues are scattered across specific topics or application domains Publication Trends
  11. 11. 11Di Francesco, Lago, Malavolta Paolo Di Francesco RQ1 – Publication trends Gap: Industry-oriented studies are not yet in the focus of researchers Publication Trends 3 3 8 8 14 48 0 10 20 30 40 50 60 Evaluation research Philosophical paper Experience paper Opinion paper Validation research Solution proposal I - Research Strategy
  12. 12. 12Di Francesco, Lago, Malavolta Paolo Di Francesco Systematic mapping study RQ1: What are the publication trends of research studies? • Scientific interest, venues, and contribution types RQ2: What is the focus of research? • Understanding of current research gaps • Classification framework RQ3: What is the potential for industrial adoption of existing research? • Are we ready to be transferred to industry? Systematic Mapping Study
  13. 13. 13Di Francesco, Lago, Malavolta Paolo Di Francesco RQ2 – Research Focus 1. Research Scope • Information to put a research study into context • Target problems, research perspective, software lifecycle 2. Support for architecting • Architecting activities, quality attributes, architectural patterns, infrastructure services Research Focus
  14. 14. 14Di Francesco, Lago, Malavolta Paolo Di Francesco RQ2 – Research Focus (Scope) • Finding: Tradeoff between flexibility and complexity • Gap: System level qualities not yet fully investigated Research Focus 4 4 4 5 5 7 7 11 13 15 16 19 19 0 5 10 15 20 Time to market Security Realtime communication Low testability Low portability Runtime uncertainty Low auditability Modernization Data management Service composition Resources management Low flexibility Complexity II - Target Problems
  15. 15. 15Di Francesco, Lago, Malavolta Paolo Di Francesco RQ2 – Research Focus (Scope) • Key enablers: Containerization and Virtualization • Researchers are investigating how to leverage system quality • Finding: Focus on legacy migration Research Focus 10 6 6 11 16 21 21 0 5 10 15 20 25 Other Mobile oriented IoT Domain-specific Migration System quality Cloud IV - Research Perspective
  16. 16. 16Di Francesco, Lago, Malavolta Paolo Di Francesco RQ2 – Research Focus (Scope) • Cross-cutting domains of application • Finding: Focus on cloud and mobile Research Focus 10 6 6 11 16 21 21 0 5 10 15 20 25 Other Mobile oriented IoT Domain-specific Migration System quality Cloud IV - Research Perspective
  17. 17. 17Di Francesco, Lago, Malavolta Paolo Di Francesco RQ2 – Research Focus (Scope) • Gap: Maintenance and testing are not primary targets • Finding: Most studies cover design, but one addresses requirements Research Focus 1 10 12 22 24 65 0 10 20 30 40 50 60 70 Requirements Testing Maintenance Operation Implementation Design VI - SW Lifecycle Scope
  18. 18. 18Di Francesco, Lago, Malavolta Paolo Di Francesco RQ2 – Research Focus (Support for Architecting) • Little focus on architectural reuse, maintenance and evolution, impact analysis and recovery • Low interest in extrovert architecting activities Research Focus 0 4 2 5 6 6 10 15 18 23 29 56 0 10 20 30 40 50 60 Getting Input Providing Information A. Impact Analysis A. Recovery A. Synthesis A. Reuse A. Understanding A. Mainten. and Evo A. Evaluation A. Description A. Implementation A. Analysis VII - Architecting Activities
  19. 19. 19Di Francesco, Lago, Malavolta Paolo Di Francesco RQ2 – Research Focus (Support for Architecting) Gap: Not equal attention to every quality attributes Research Focus 12 13 14 14 14 17 28 40 0 10 20 30 40 50 Portability Usability Compatibility Reliability Functional suitability Security Maintainability Performance efficiency VIII - Quality Attributes
  20. 20. 20Di Francesco, Lago, Malavolta Paolo Di Francesco RQ2 – Research Focus (Support for Architecting) Set of infrastructure services supporting non-functional tasks Finding: This focus will help devising new patterns and styles for further leveraging cloud-based architectural models Research Focus 1 4 6 6 10 13 26 26 0 5 10 15 20 25 30 Data storage Service Proxies Security Messaging Service brokering Service Orchestration System level management Monitoring XI - Infrastructure Services
  21. 21. 21Di Francesco, Lago, Malavolta Paolo Di Francesco Systematic mapping study RQ1: What are the publication trends of research studies? • Scientific interest, venues, and contribution types RQ2: What is the focus of research? • Understanding of current research gaps • Classification framework RQ3: What is the potential for industrial adoption of existing research? • Are we ready to be transferred to industry? Systematic Mapping Study
  22. 22. 22Di Francesco, Lago, Malavolta Paolo Di Francesco RQ3 – Potential for Industrial Adoption Technology Readiness Level Technology is either formulated, validated or demonstrated • At most in lab TRL ≤ 4 • In relevant environment 5 ≤ TRL ≤ 6 • In operational environments TRL ≥ 7 Potential for Industrial Adoption
  23. 23. 23Di Francesco, Lago, Malavolta Paolo Di Francesco RQ3 – Potential for Industrial Adoption Industry Involvement Potential for Industrial Adoption
  24. 24. 24Di Francesco, Lago, Malavolta Paolo Di Francesco Conclusions http://cs.gssi.infn.it/ICSA2017ReplicationPackage Conclusions

×