T8 – : Yesterday, Today, and 5/30/2017 Tomorrow

MICROSERVICES: YESTERDAY, OUTLINE TODAY AND TOMORROW  Introduction to Monolith architecture and the problems it imposed on Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente, Manual Mazzara, Fabrizio Montesi, Ruslan Mustafin, Larisa Safina  Evolution of microservice architecture to cope up with the problems of monolith architecture

 Evolution of distributed architectures By  Monolith -> Object Oriented -> Component based (SOA) -> Microservices Megha G M  Characteristics of microservices & its impacts on software development Sowmya V  Interesting future directions of microservices Keerthanaa G S 1 2 30-05-2017 30-05-2017

INTRODUCTION – MONOLITH NEW TECHNOLOGY – MICROSERVICES

 Problems associated with large-scale software development were first experienced in 1960s  Last decade has seen a shift towards concept of service-orientation and led  Microservice – a cohesive, independent to natural evolution of microservices interacting via messages

 Monolith architecture  Microservice architecture – a distributed application  A software application whose modules cannot be executed independently where all its modules are microservices  Very difficult to use in distributed systems without specific frameworks  Guideline to design and implement distributed  Network Objects, RMI or CORBA might help but to a very little extent applications  Issues  Partition the components of a distributed application into  Difficult to maintain and evolve independent entities  Dependency hell – Adding or updating results in inconsistent system  Programming of simple services to implement a single  Small changes require rebooting the whole application functionality  Limited  Design and develop a highly maintainable & scalable  Technology in for developers 3 software 4 30-05-2017 30-05-2017

MICROSERVICE ARCHITECTURE AS A MICROSERVICES EXAMPLE SOLUTION TO MONOLITH

 Example: A functionality that plots the graph of a function  Implement limited and specific set of  Two microservices: Calculator and Displayer functionalities  Another microservice (orchestrator): Plotter

 Fosters  Takes the function given by a user

 Changing the module doesn’t require rebooting  Interacts with the Calculator to compute the graph of the function the whole application  Plotter then requests the Displayer to show the result back to the user

 Microservices extend containerisation To illustrate how the microservice approach scales, New microservices can be built on top of this whenever required  Scaling Add mathematical elementary & special functions using Calculator as  No lock-in to specific technology orchestrator

5 6 30-05-2017 30-05-2017

1 T8 – Microservices: Yesterday, Today, and 5/30/2017 Tomorrow

EVOLUTION OF MICROSERVICES (1/5) EVOLUTION OF MICROSERVICES (2/5) YESTERDAY YESTERDAY

 1980’s – integration of design & development made it hard to find a clear  Benefits of SOC distinction between them  Dynamism

 1990’s – Object-oriented software – “patterns”  Modularity & reuse

 Example : Model View Controller(MVC)  Distributed development

 Service-Oriented Computing (SOC) – Component-based software engineering  Integration of heterogeneous and legacy system (CBSE)  Second generation of services  Services offers functionalities to other components, accessible via message passing  The first “generation” of service-oriented architectures (SOA) was difficult to adopt due its vague requirements like discoverability and service contracts

 Microservices – the second iteration of the concept of SOA and SOC.

7 8 30-05-2017 30-05-2017

EVOLUTION OF MICROSERVICES (3/5) EVOLUTION OF MICROSERVICES (4/5) TODAY TODAY

 Microservices, a new trend in  Team

 Composition of small services,  1968 - Melvin Conway – design is a copy of the organization's communication patterns  Introduced in 2011  Organize cross-functional teams around services  Fine grained SOA (Netflix)  CTO Werner Vogels – “you build, you run it” principle  Characteristics  Total automation – Continuous integration, independent deployment, beneficial in  Size – Service maintainability and extendability rapidly changing business environments  Bounded context – Related functionalities are combined into services  Choreography over orchestration

 Independency – Services are operationally independent  Orchestration – requires a conductor

 Modularity – System provides Isolation of different functionalities  Choreography – decentralized

 Flexibility – System supports growing business needs  Impact on quality and management  Evolution – System stays maintainable with changes 9  Availability, Reliability, Maintainability, Performance, Security, Testability 10 30-05-2017 30-05-2017

EVOLUTION OF MICROSERVICES (5/5) AUTHOR’S CONCLUSION TOMORROW

 New issues posed by microservices  Dependability – building dependable systems with microservices  Microservices architecture gained popularity recently both in academia and in the industrial world  Interfaces – need to specify formal message specifications between services  Behavioural Specifications – To check that the services have compatible actions  Still in its infancy and still there is a lack of agreement on what  Choreographies – a possible future, still unclear in so many aspects microservices actually are

 Moving Fast with Solid Foundations – start from scratch or reuse existing results?  Few authors presented a revolutionary perspective to  Trust and Security microservices, the author here has given an evolutionary  Greater Surface Attack Area perspective  Network Complexity  No comprehensive collection of documentation in this field  Trust

 Heterogeneity

11 12 30-05-2017 30-05-2017

2 T8 – Microservices: Yesterday, Today, and 5/30/2017 Tomorrow

CRITIQUE: STRENGTHS CRITIQUE: WEAKNESSES

 Modularity – easy for bug-fixing  Challenges in Microservice architecture  Continuous integration  Developing distributed systems can be complex  Short re-deployment downtimes  Multiple and transaction management can be painful  Containerization  Unavailability of an individual service can hinder the performance of the system  Scaling  Integration testing is cumbersome as the system size grows  No technology lock-in  In-memory calls perform better compared to network message passing  Brings measurable cost savings in both time and speed to market  Deploying microservices can be complex. They may need coordination among multiple  Agility services

 Efficiency  Migration towards microservices involves major back-end refactoring for most companies

 Resiliency  Revenue 13 14 30-05-2017 30-05-2017

CRITIQUE: WEAKNESSES CRITIQUE: EVALUATION

 About the paper

 Security challenges  Survey paper submitted by Cornell University in June 2016  Authentication is necessary in 3rd party services  Cited more than 30 times

 The architecture is exposed to attacks  Explains the practical difficulties faced by developers in a Monolith architecture & introduces microservices and explains how it resolves the issues  Involves complex network activity  Provides an evolutionary perspective to this technology  Attack on one microservice can bring down the application  Provides a clear distinction between different technologies that led to  No common security infrastructure for heterogeneous systems microservices from the scratch

 Paper acknowledges some of the challenges of microservices but there are not a lot of solutions to these pitfalls

 The architectural details and cost details of the microservices are outside the scope of this paper 15 16 30-05-2017 30-05-2017

FUTURE WORKS GAPS  Tools are needed

 For formally specifying message types for data exchange  Constraints and limitations which are not discussed by the author  To provide guaranteed compatibility of services  Microservices architecture is not suitable for everybody  More research contributions are necessary in the domain of the actor model and software agents  For many organizations, a well-functioning microservice architecture may be difficult to reach  It is unclear how choreographies can be combined with flexible deployment models where nodes may be replicated or fail at runtime  Microservices don't necessarily mesh well with DevOps environments  Security against attacks

 Microservices have a promising future with respect to IoT

17 18 30-05-2017 30-05-2017

3 T8 – Microservices: Yesterday, Today, and 5/30/2017 Tomorrow

THANK YOU! QUESTIONS?

19 20 30-05-2017 30-05-2017

4