IT Systems Architecture - Microservices

In this section, we will be covering IT Trends. It is very important not to fall into a trap of Technical Hype, which may lead us to problems in the future. This section explains, how we, as IT Architects, should choose an architectural style based on technologies that are ready to implement in the organization.

In this lecture, we will get into concepts of Service-Oriented Architecture (SOA as an architectural style that supports service-orientation) from Architecture point of view, and SOA distinctive features

Service specification is one of the most crucial part of designing good services, which will be used by Consumers. The idea is to give Customer all necessary information, how he should use service, that means: how Customer should ask Service to execute its function, and how response from execution of that function should looks like

This lecture describes Mediation layer, which plays an important role in defining a loosely coupled Service-Oriented Architecture. The mediation layer between the service provider and the consumer can make a lot of things possible

Services can communicate with each other via multiple methods or protocols. We can specify two main methods of communication: Synchronous and Asynchronous. This lecture describe differences between those 2 types of communication methods

In this lecture we will deep dive into design patterns for system integration. The ideas was covered in book: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, which started to be a primary language of communication between architects and developers

This lecture describes, what is the Messaging System - as a technology that enables high-speed, asynchronous, program-to-program communication with reliable delivery

A Message Channel, is a Infrastructure for storing and asynchronously accessing messages. A channel behaves like a collection or array of messages, but one that is magically shared across multiple computers and can be used concurrently by multiple applications. This lecture describe Message Channels and how them can be used to integrate systems with each other

This lecture shows differences between services Registry and Service Repository in simple example

In Enterprise ecosystem it is common to choose Enterprise Architecture as a way to design IT solutions. This chapter describe benefits of using Enterprise Architecture

Enterprise Architecture has many benefits, but there are drawbacks of using this Architecture Style. In this chapter we will be pointing, what disadvantages are in use of Enterprise Architecture

In this lecture, we will be focusing on Microservices Architecture, which is a more concrete and modern interpretation of Services Oriented Architecture (SOA), used for creating distributed systems. The lecture explains, what is a microservice and what is a philosophy of creating small components with the use of the Microservice Architecture style.

What are the differences between Monolith, Microservice, Nanoservice, and how “big” should be microservice? What many lines of code should microservice have? These questions will be covered in this lecture.

To get the full benefit from using Microservices Architecture, there is a need to understand requirements. In this lecture, we will learn, what requirements are crucial to implementing in Microservices Architecture.

Pros / Benefits of using Microservices Architecture, both for individual service, like for whole components combined with each other it distributed microservices architecture.

In this lecture, we will be focusing on cons/disadvantages of using Microservices Architecture

In this lecture, we will be learning about one of the common migration design patterns from Monolith application to microservices - Strangler. This is an approach that I was able to implement during my work with Monolith application and microservices and it is one of the most commonly used strategies of Decomposition to microservices.

During this lecture, we will be also focusing on the proper way of routing a call (with the use of API Gateway or Load Balancer) and also provide an Integration glue to react to changes between Monolith and microservices, when they occur.

In this lecture, we will be learning how Migration from Monolith to microservices will look over time, and what is important during each phase of decomposition to microservices. We can see, how this process looks over time.

The connection between microservices can be divided into Synchronous, Asynchronous plus connections between microservices between each other can be divided into Blocking and non-blocking. This lecture provides a description of each connection method in detail with information, which methods of connections are recommended in Microservices Architecture.

Microservices Architecture is different than Enterprise Architecture, where the heart of a system is a big database with the use of RDBMS. Instead of the well-known ACID model, it is recommended to think about databases in distributed computing systems with the CAP theorem. CAP states that it is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees: Consistency, Availability, and Partition-Tolerance.

Each microservice can have its own persistence storage, using many database technologies. In this lecture, we will deep dive into the persistence stacks which can be used in Microservices Architecture.

NoSQL databases will be divided into 4 subcategories, which are: Key-Value, Document, Column-Family, and Graph databases.

We will also discuss the advantages of using NewSQL technologies, and how those persistence mechanisms can help to give full advantages in Microservices Architecture.

In this lecture we will be discussing a Cloud-Native is a term that can describe the patterns of organizations, architectures, and technologies that consistently, reliably and at scale fully take advantage of the possibilities of the cloud to support cloud-oriented business models.

In order to prepare a microservice to be a Cloud Native Application, we need to consider few important factors. Heroku developers described 12 factors, which are necessary to implement to lift and shift microservices into Cloud. This lecture describes each factor and focuses on its of them in order to architect good microservices components.

A circuit breaker is a design pattern that helps to decrease the number of requests to a service that is not responding. In this lecture, we will see, how this pattern is implemented in Microservices Architecture

One of the good practices related to automation in the deployment process is Blue/Green deployment. The fundamental idea is to have two easily switchable versions of microservice, in which only one version is marked as "active" and all requests go to that version, and the other one is "passive". In this lecture, we will be learning, how Blue/Green deployment looks in Microservices Architecture.

While microservices containers offer your applications potential increases in both functionality and productivity, they also have more moving parts to configure, coordinate, and, well, orchestrate. This lecture explains, how orchestration looks like in Microservices Architecture.

CQRS stands for Command Query Responsibility Segregation. It's a pattern that was described by Greg Young and Udi Dahan. It is a successor of a CQS model, which means Command Query Separation, which was introduced in 1986 by Bertrand Meyer and was focused on manipulating methods/functions inside code.

Write operation is more costly, because each create, update or delete changes application state. Write is consider as Command in the CQRS model.

In this lecture, we will be describing, how Query and Command can be separated by using CQRS pattern, and what can benefit after implementing this pattern into Microservices Architecture.

Transaction between microservices is not a trivial task. Monolithic systems often use one shared database. In the case of microservices, we do not have such a possibility, because we do not have a central, shared database and each microservice has its own independent data source.

In this lecture, we will discuss how to achieve transactions in Microservices Architecture by use of two-phase commit (which is not recommended), and Saga pattern, with an explanation of the usage of this pattern.