1. Demistifying Hypes in Cloud-Native Technologies Davide Taibi Professor. University of Oulu

2.

3. Software Systems Evolution Serverless Computing Function as a Service

4.

5. Microservice Migration Motivations - Improve Maintainability - Improve Scalability - Reduce Costs - Simplify Distributed Work - Improve System understandability

6. Main Issues Identified Technical Issues • Architectural Patterns are not clear • Decoupling from the monolithic system • Database migration and data splitting Effort-Related issues • Effort required for the DevOps infrastructure • Effort required for library conversion • Effort at least 20% higher Davide Taibi - Colloquium Series - SPLAB ZHAW

7. Stop using microservices! Move to serverless functions as soon as possible! O’Reilly SW Architecture Conference 2018

8. What is Serverless [3] What is Serverless? a cloud-native platform for short-running, stateless computation and event-driven applications which scales up and down instantly and automatically and charges for actual usage at a millisecond granularity [3] Baldini I. et al. (2017) Serverless Computing: Current Trends and Open Problems. In: Chaudhary S., Somani G., Buyya R. (eds) Research Advances in Cloud Computing. Springer, Singapore

9. From Microservices to Serverless Functions • Practitioners started migrate from microservices to FaaS • Mixed Approach (microservices + Functions) • New applications 100% serverless • vast majority of Finnish companies (interviewed)

10. Why practitioners are moving to serverless

11. Migration Motivations Companies Already moved to Microservices • OPS Effort for Microservices • Get rid of Kubernetes • No OPS Companies Migrating from Monolithic systems • New (hype) technology • Promising technology • No initial infrastructural costs (pay as you use) • Automatic scaling • Lack of skilled OPS personnel

12. Migration Issues • Developers are not used to the event-oriented programming • Very hard to test • Debug almost impossible • Unknown Patterns and antipatterns • Anomalies can generate unexpected costs!

13. Microservices or Serverless

14. Both! Serverless Microservices Composing Serverless functions to Microservices

15. How About Micro-Frontends?

16. 1

17. What is a Micro-frontend? Let’s connect the dots... 16

18. “ From Domain Driven Design (DDD) Micro-frontends are the technical representation of a business subdomain, they allow independent implementations with same or different technology choices, finally they avoid sharing logic with other subdomains and they are own by a single team 17

19. How About a Service Mesh?

20.

21. Our Demystification Process

22. Our Demystification Process Benefits and Issues of new Technologies Patterns and Anti-Patterns Follow-Up Case Studies Technology Assessment Frameworks

23. Demystifying New Hypes Microservices Serverless Micro- Frontends Cognitive and Continuum Cloud

24. Patterns and Anti-Patterns FOCUS: MICROSERVICES On the Definition of Microservice Bad Smells Davide Taibi and Valentina Lenarduzzi, Tampere University of Technology // To identify microservice-specific bad smells, researchers collected evidence of bad practices by interviewing developers experienced with microservice-based systems. They then classified the bad practices into 11 microservice bad smells frequently considered harmful by practitioners. // with possible solutions to overcome these smells. To produce this catalog, we surveyed and interviewed 72 ex- perienced developers over the course of two years, focusing on bad prac- tices they found during the develop- ment of microservice-based systems and on how they overcame them. We identified a catalog of 11 microservice- specific bad smells by applying an open and selective coding 5 proce- dure to derive the smell catalog from the practitioners’ answers. The goal of this work is to help practitioners avoid these bad prac- tices altogether or deal with them more efficiently when developing or migrating monoliths to microservice- based systems. As with code and architectural smells, which are patterns com- monly considered symptoms of bad design, 1,6 we define microservice- specific bad smells (called “micro- service smells” hereafter) as indicators of situations—such as un- desired patterns, antipatterns, or bad practices—that negatively affect software quality attributes such as understandability, testability, extensi- bility, reusability, and maintainability of the system under development. Background MICROSERVICES ARE CURRENTLY enjoying increasing popularity and diffusion in industrial environments, being adopted by several big players such as Amazon, LinkedIn, Netflix, and SoundCloud. Microservices are relatively small and autonomous ser- vices that work together, are mod- eled around a business capability, and have a single and clearly defined purpose. 1,2 Microservices enable independent deployment, allowing small teams to work on separated and focused services by using the most suitable technologies for their 56 I E E E S O F T WA R E | job that can be deployed and scaled independently. 1,2 Microservices are a newly developed architectural style. Several patterns and platforms such as nginx (www.nginx.org) and Kuber netes (kubernetes.io) exist on the market. During the migration process, practitioners often face com- mon problems, which are due mainly to their lack of knowledge regarding bad practices and patterns. 3,4 In this article, we provide a cata- log of bad smells that are specific to systems developed using a micro- service architectural style, together PUBLI S HED BY THE IEEE CO MPUTER S O CIE T Y Several generic architectural-smell detection tools and practices have been defined in the past years. 7–9 Moreover, several microservice- specific architectural patterns have been defined. 10 However, to the best of our knowledge, no peer-reviewed work and, in particular, no empirical studies have proposed bad practices, antipatterns, or smells specifically concerning microservices. However, some practitioners have started to discuss bad practices in microservices. In his ebook Micro- services AntiPatterns and Pitfalls, 0 74 0 -74 5 9 / 1 8 / $ 3 3 . 0 0 © 2 0 1 8 I E E E Authorized licensed use limited to: Gran Sasso Science Institute. Downloaded on July 05,2022 at 07:30:29 UTC from IEEE Xplore. Restrictions apply.

25. Technology Assessment Feramework • Microservice Framework Assessment

26. Conclusion • New Technologies are continuously introduced • Silver Bullets do not exist • Economical, and Technical motivations should be always considered • Think about the issues in your system before migrating

27. Thanks Davide Taibi Professor. University of Oulu davide.taibi@oulu.fi https://m3s-cloud.github.io