Lecture Slides:

Additional Readings:

Additional Resources:

• The death of service oriented architecture or rebirth on the wings of SaaS and Cloud Computing [pdf] [annotated pdf]
• Case Study: SOA @Twitter
• Decomposing Twitter: Adventures in Service Oriented Architecture, presentation at QConfNY by Jeremy Cloud [video]

Lectures 2,3,4,5 will have an hands-on approach towards the creation of microservices that can be used for the creation of the project in teams of three. To get in touch with Martin Stefanko directly if you need help with the project, you can create an account at https://quarkusio.zulipchat.com/login/ 

Timeline

* by 2.10.2023 teams of three formed. You can add your name/uco/team to the following document: 

* 25.9 (lect) introduction to Microservices and the Quarkus framework

* 2.10 (lect2), 9.10 (lect4), 16.10 (lect5) hands-on lectures for the creation of microservices with the Quarkus framework.

* By 1.10.2023 all teams should have decided the domain of the system to be implemented, the project can start.

* 11.12.2023 Final projects presented.

Main Project Requirements

1. Pick some domain of the system under development that you agree within your team. This can be anything related to work, study, but also any domain that you think could be interesting for you. Examples can be an eshop, some platform to sell used items, platform to manage emergencies, etc... Anything that you think could be worth scaling-up with microservices and that can be interesting for some team members.
If you do not come up with some domain, do not worry, we will assign you some project description. Give also a name to your platform :)

After you have decided, you can add your team and project domain to the teams document.

2. Create a repository on GitHub/GitLab, in which you will collect the source code and the documentation about the project and collaborate within your team. Add the info about the repository to the list of teams document.

3. Add to the repository a short description of the system, and the main requirements that you think are worth to be included for the project and how you would divide it into services (we will have more in the course, after the 4 technical lectures block).

4. Each student should take the responsibility of one/two microservices, there can be students that can take more responsibility on other implementation, like the monitoring part, testing, etc... you can also have students more into documentation/design if not confident with implementation, but at least everybody should get hands on some part of the system.

Technical Requirements

+ For the implementation, try to keep with the technology stack presented during the lecture Quarkus and related frameworks shown during the lecture, Docker/Podman. Any deviation should be agreed with the lecturer:
+ (must) On your GitHub page of the project. give a i) description of the project, ii) a story/scenario of usage, iii) why you think a microservice architecture can be appropriate, iv) benefits of the using microservices in this project, v) drawbacks of microservices in this case. You can populate some of these points based on your experience during the course.
+ (must) Have the API design & contract available in the project documentation or integrated in the Quarkus project (e.g., using https://swagger.io - https://quarkus.io/guides/openapi-swaggerui)
+ (must) Have some blueprint for the design of your services (e.g., using domain driven design) which can be documented either with C4 models (https://c4model.com/) and/or UML models and/or other type of diagrams;
+ (must) Have some monitoring part for the services collecting metrics about usage (https://quarkus.io/guides/microprofile-metrics https://quarkus.io/guides/telemetry-micrometer-tutorial); (note: updated the link)
+ (must) Have at least one service that can show self-healing capabilities (https://quarkus.io/guides/microprofile-health);
+ (must) All services have some meaningful tests running (https://quarkus.io/guides/getting-started-testing);
+ (must) Have some simple database support for at least one service - https://quarkus.io/guides/hibernate-orm-panache
+ (must) Process monitoring data and visualization with Prometheus + Grafana (https://quarkus.io/guides/microprofile-metrics);
+ (must) Have a scenario that you can run that showcase some reactive properties of the system (those that you implemented): Responsiveness (quick response / always on), resiliency (self-healing service), elasticity (how the system can scale up/down when needed), message-driveness (asynchronous messages with loosely coupled / location-transparent services); (note: some of these might be difficult to show, so you can just focus on showing how your system can deal with failures or excessive number of requests)
+ (must) pick at least one of the following optional requirements and showcase the implementation / deployment at the final presentation:

• (optional) Use Jaeger for tracing (https://quarkus.io/guides/opentracing);
• (optional) Use of Kafka for asynchronous messaging (https://quarkus.io/guides/kafka)
• (optional) Use of authentication for some microservices with JWT (JSON Web Tokens);
• (optional) Configure and deploy the project with Docker/Podman;
• (optional) Configure and deploy the project on Kubernetes/Minikube or Openshift/CRC;
• (optional) show the usage of a native executable with GraalVM, discussing advantages/disadvantages (e.g., what are the performance improvement running the scenario you created);
• (optional) Not directly covered in this course: however, if you have previous experience or want to try, you can showcase polyglot microservices (implemented in different programming languages/frameworks) - this is something that any team with students that have no experience with Java can have;

Teams

Team1

• Vojtěch Sýkora
• Marek Seďa
• Dominik Seďa

Team2 (City bike & scooter reservation system / Wheelio)

• Gema Vidagany Viel
• Jiří Šimek
• David Rajnoha
  

Team3 (Platform for exchanging skills (languages, playing musicinstruments, etc.) with strangers / Brainshare)

• Dávid Šutor
• Matej Meško
• Jana Treláková

Team4

• Miroslav Rouča
• Martin Mojžiš
• Straka Jan

Team5 (Household Management (track utilities, chores, common expenses, …)

• Martin Klimeš
• Juraj Marcin
• Anna Vítová

Team6 (Car rental service(make a rental, payment process, fees)

• Stanislav Koshchienko
• Anna Ogorodova
• Madyar Turgenbaye
  

Team7 (Covid Testing System (registration for testing, creating certificates for covid tests)

• Lukáš Vavřík
• Jozef Mihale
• Martin Stojan
  

Team8 (Banking System)

• Dominik Rehák
• Peter Verčimák
• Filip Piták
  

Team9 (Library Management System)

• Jakub Krištof
  
• Dávid Laurovič
  
• Adam Kridl
  

Team10

• Vasilii Karmazin
• Ifeanyichukwu Egeolu
• Ughur Aghakishiyev
  

In this lecture, we will discuss about Microservices with Martin Štefanko (Red Hat): we will cover several aspects: what are microservices, how the principles are different from typical SOA principles, some examples of implementation. Martin will also showcase rapid prototyping of microservices with Quarkus (https://quarkus.io).

• Microservices in general
• Comparison to typical SOA principles
• Technologies that make microservices possible
• Live Example of Microservices creation
• Principles of microservices from the perspective of the business
  

Lecture slides

Video

The following is a video recording from two years ago, so content might be slightly different.

• Introduction to Quarkus (https://quarkus.io/guides/getting-started )
  
• HTTP / REST
• Docker/Podman
• Kubernetes/Openshift
  

Video

The following is a video recording from two years ago, so content might be slightly different.

This lecture we will continue with technical details of writing microservices, using Quarkus (https://quarkus.io). This lecture we will look in particular at Microprofile (https://microprofile.io)

• What is Microprofile?
  
• Communication between services
• CDI
• Microservices configuration
• Health and Metrics collection

Video

Please note this is a video from previous years, so some content might be different

This lecture we will continue with technical details of writing microservices, using Quarkus (https://quarkus.io). This lecture we will look in particular at:

• REST clients
• Fault Tolerance
• Authentication with JWT
  
• reactive services with Kafka

Video

Note: this is a video from a previous edition:

The aim of this lecture is to give an understanding about what a Service Oriented Architecture (SOA) - from the architectural point of view, and why we even need such an architecture. We will also look at the definition of SOA Maturity Model looking at when we can consider an organization as fully SOA compliant, crossing different levels of adoption with different organizational aspects (governance, application level, information level, etc...). We will do the same with Microservices: how it represents an evolution of SOA, which are crucial aspects of the evolution of the architecture.

Lecture Slides:

The following in the Open Group Service Integration Maturity Model (OSIMM) we discussed during the lecture

Other frameworks for Microservices Maturity Assessment

Reading Material:

• The main SOA Reference Architecture: The Open Group SOA Reference Architecture & Arsanjani, Ali, et al. "Design an SOA solution using a reference architecture." IBM DeveloperWorks (2007) - NOTE: same document as above, but might contain some different info, e.g. better diagram of the different layers

In this lecture,  we start a two series session about Domain Driven Design (DDD) for designing microservices. In this first part, we will look at the strategic phase, covering the whole idea of the approach, the definition of bounded contexts, and the creation of context maps. Next lecture, we will continue with the tactical level.

Lecture slides

Additional Materials

For a very quick summary about DDD and the Bounded Context (more extensive details in the main reference books about DDD: [1], [2]):

[1] Evans, Eric, and Eric J. Evans. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional, 2004. [URL]

[2] Vernon, Vaughn. Implementing domain-driven design. Addison-Wesley, 2013. [URL]

In this lecture, we see the tactical level of DDD and how it can be used for the design of microservices. We try to do a small exercise for the definition of microservices based on your domain (as said in the previous lecture, DDD for design of microservices makes sense if there is a large number of requirements and the domain is complex, for simple CRUD implementation of microservices, the whole DDD process has too much overhead).

Lecture slides

Additional material

We have looked at how to apply DDD for the analysis of the domain and identification of the microservices. It is an iterative process that allows to define bounded contexts and derive the microservices from the attribution of functionality to each boundary. The following is another example of the application of DDD for the creation of microservices.

In this lecture,  we deal with Service Oriented Architecture Modelling Language (SoaML), that is a way to represent services in SOA. We see the notation and how it can be useful to represent services. We will also look at the definition of service contract with REST APIs (OpenAPI).

Lecture Slides 

Further References for SoaML

• How to model services with SoaML: VP Tutorial
• SoaML Specifications 1.0.1: (SoaML specifications) [PDF]
  
• Elvesæter, Brian, Arne-Jørgen Berre, and Andrey Sadovykh. "Specifying Services using the Service Oriented Architecture Modeling Language (SoaML)-A Baseline for Specification of Cloud-based Services." CLOSER. 2011 [PDF].
  
• Berre, A. J. "Service-oriented Architecture Modeling Language (SoaML)—Specification for the UML Profile and Metamodel for Services (UPMS). OMG Document." (2009) [PDF]

In this lecture we look at common SOA patterns that have been applied over the years in the SOA domain. You have probably already heard about design patterns, analysis patterns and enterprise patterns (as well as anti-patterns). Patterns represent solutions to reoccuring problems and are usually applied also to make projects more understandable, as other projects' participants can immediately recognize one pattern. Each pattern has obviously benefits and also drawbacks. In this lecture, we look at SOA patterns.

Lecture slides

In this lecture, we look at Microservices patterns to get an overview of patterns both for the design and migration from monolithic systems. In particular, we look at the Strangler Fig pattern, the Saga pattern (both in the orchestration and choreography variants), and the CQRS pattern.
 

Lecture slides

Orchestration vs Choreography

Additional Material

Migrations from monolith to microservices

Suggested reads from the following document: "Principles for Microservice Design: Think IDEALS, Rather than SOLID" and "Migrating Monoliths to Microservices With Decomposition and Incremental Changes":

Master thesis about Migrations from Monoliths to Microservices that was defended in 2022:

SAGA PAttern

Article about comparison of frameworks supporting the Saga pattern: Štefanko, M., Chaloupka, O., Rossi, B.  (2019). The Saga pattern in a reactive microservices environment. In Proc. 14th Int. Conf. Softw. Technologies (ICSOFT 2019) (pp. 483-490).

Martin Stefanko's thesis, Master thesis that was defended in 2018:

The following is an example on how to implement the Saga Pattern in Quarkus:

CQRS + Event Sourcing

Example of CQRS with Quarkus:

We will have some closing lecture about how chaos engineering can be used for the scope of building more reliable microservices and what is different compared to traditional software testing. We will also have a short summary of the course.

Additional Material

Presentations by students

• Every team will have 10min to present, there is no predefined template / structure of the presentation, but would be nice to cover the goals of the system and present the implementation of some of the technical requirements that you consider more interesting for your project (https://is.muni.cz/auth/el/fi/podzim2023/PV217/index.qwarp?prejit=11832245) . Please also highlight the contribution of each student in the different parts of the project.

• A sample structure of the points to cover during the presentation (please see also the requirements above for more details)
  
  • Context of the project: why microservices as seen as necessary for this system;
  • Overview of the system's architecture (e.g., services implemented, their responsibilities, etc...);
    
  • Any particular focus of your project like usage of Apache Kafka, or some monitoring capabilities, usage of Grafana, etc...
  • How the deployment of the system has been done;
    
  • Demo of the application with some scenario that can show some interesting aspect of the implemented system;
    
  • Pro & Cons of microservices after having implemented the project;
    
  • How the work was distributed among team members;
    
• Please remember to upload your presentation into the homework folder "Presentations" and the final archive of your project (as zip, tar.gz) to the "Projects" folder;
  
  Final-Presentation
  Final-Project

Schedule:

• 12:00 Team1 ( Vojtěch Sýkora, Marek Seďa, Dominik Seďa)
• 12:10 Team2 (Gema Vidagany Viel, Jiří Šimek, David Rajnoha)
• 12:20 Team3 (Dávid Šutor, Matej Meško, Jana Treláková)
• 12:30 Team4 (Miroslav Rouča, Martin Mojžiš, Straka Jan)
• 12:40 Team5 (Martin Klimeš, Juraj Marcin, Anna Vítová)
• 12:50 Team6 (Stanislav Koshchienko, Anna Ogorodova, Madyar Turgenbaye)
• 13:00 Team7 (Lukáš Vavřík, Jozef Mihale, Martin Stojan)
• 13:10 Team8 (Dominik Rehák, Peter Verčimák, Filip Piták)
• 13:20 Team9 (Jakub Krištof, Dávid Laurovič, Adam Kridl)
• 13:30 Team10 (Vasilii Karmazin, Ifeanyichukwu Egeolu, Ughur Aghakishiyev)
  

Monday 18/12/2023 14:00 A320

Tuesday 16/1/2024 14:00 A319

Tuesday 23/1/2024 14:00 A320