Lecture 4

⏳ Duration: 1.5h

The Evolution of Architectural Approaches

The development of technology, particularly the shift from monolithic to microservices architecture, has had a profound impact on modern information systems.

Monolithic applications, which were the dominant approach in the past, consisted of a single, large unit of code. While this approach had its advantages, such as simplicity during the initial stages of system development, it also presented significant drawbacks, including challenges with scaling, limited flexibility, and complex maintenance.

As technology evolved, microservices emerged as a solution. This approach involves breaking an application into smaller, independent services, each responsible for a specific functionality. The shift to microservices enabled greater flexibility, easier system scaling, and faster deployment of new features. Additionally, each service can be developed, tested, and deployed independently, simplifying code management and reducing the risk of errors.

Thanks to microservices, organizations can better adapt to changing business needs, improve system availability (by isolating failures to individual services), and innovate more quickly. Furthermore, microservices promote the use of modern techniques like containerization and cloud solutions, which streamline infrastructure management and make better use of resources.

However, despite the many benefits, transitioning to microservices also comes with challenges, such as:

  • Complexity in managing communication between services
  • The need to monitor and maintain a larger number of components
  • Managing distributed transactions

These challenges require new tools and approaches to management, as well as the implementation of a DevOps culture.

With the development of microservices, new technologies such as serverless and containerization have emerged, serving as natural extensions of system flexibility. These technologies further enhance the efficiency of managing and scaling modern applications, becoming key components of the cloud ecosystem.

Serverless

Serverless is a model where developers don’t have to manage servers or infrastructure. Instead, cloud providers take care of all the infrastructure, allowing developers to focus solely on the application code. The key advantage of this approach is its scalability – applications automatically scale based on resource demand. Serverless systems allow functions to be dynamically started and stopped in response to specific events, leading to cost optimization (you only pay for the actual resource usage). This approach simplifies managing applications with variable or unpredictable traffic.

Serverless is also a great complement to microservices, enabling the deployment of independent functions in response to various events, which offers even greater flexibility. It can be used for applications such as real-time data processing, API handling, and task automation.

Containerization

Containerization (e.g., using Docker) is another step toward increasing flexibility. With containers, applications and their dependencies are packaged into isolated units that can be run across different environments in a consistent and predictable manner. Containers are lightweight, fast to deploy, and offer easy portability across platforms, which is crucial in microservice architectures.

Containerization is gaining significance, especially when combined with container management tools like Kubernetes, which automatically scales applications, monitors their status, ensures high availability, and manages their lifecycle. This approach perfectly supports both microservices and serverless, enabling easy deployment, scaling, and monitoring of applications.

Common Goal – Flexibility

Both serverless and containerization represent a further step towards flexibility, offering the ability to quickly adapt to changing conditions and demands. Together with microservices, they form a modern approach to application architecture that allows for the separation of responsibilities, easier scaling, dynamic resource allocation, and better utilization of cloud infrastructure.

The combination of these technologies allows businesses to rapidly deploy new features, respond to changing user needs, and minimize costs by optimizing resource usage – all of which are particularly important in today’s fast-evolving technological landscape.

The Impact of Technology on Information Systems

Networking communication, relational databases, cloud solutions, and Big Data have significantly transformed the way information systems are built and how work is carried out within them.

Similarly, information-sharing tools such as newspapers, radio, television, the internet, messaging apps, and social media have influenced human interactions and social structures. Each new technological medium shapes how people use computing and perceive its role in everyday life.

Microservices architecture

The concept of microservices is essential to understand when working on architectures. Although there are other ways to architecture software projects, microservices are famous for a good reason. They help teams be flexible and effective and help to keep software loose and structured.

The idea behind microservices is in the name: of software is represented as many small services that operate individually. When looking at the overall architecture, each of the microservices is inside a small black box with clearly defined inputs and outputs.

An often-chosen solution is to use Application Programming Interfaces ( API) to allow different microservices to communicate

Main Advantages of Microservices:

  • Efficiency – Each service performs a single, well-defined task (“do one thing, but do it well”).
  • Flexibility – They allow for easy modifications and scaling of the system.
  • Architecture Transparency – The system consists of small, independent modules.

Microservices can be compared to pure functions in functional programming – each service operates independently and has clearly defined inputs and outputs.

To enable communication between microservices, Application Programming Interfaces (APIs) are often used, allowing data exchange and integration between different services.

Example of an API in Microservices – Python & FastAPI Below is an example of a REST API microservice in Python using FastAPI, which returns user information:

from fastapi import FastAPI

app = FastAPI()

# Przykładowe dane użytkowników
users = {
    1: {"name": "Anna", "age": 28},
    2: {"name": "Piotr", "age": 35},
    3: {"name": "Kasia", "age": 22},
}

@app.get("/users/{user_id}")
def get_user(user_id: int):
    """Zwraca dane użytkownika na podstawie ID."""
    return users.get(user_id, {"error": "User not found"})

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="127.0.0.1", port=8000)
  1. We start the FastAPI server.
  2. We can retrieve user data by sending a GET request to http://127.0.0.1:8000/users/1.
  3. The API will return the data in JSON format, for example:
{
    "name": "Anna",
    "age": 28
}

Communication through API

A central component in microservice architectures is the use of APIs. An API is a part that allows you to connect two microservices. APIs are much like websites. Like a website, the server sends You the code that represents the website. Your internet browser then interprets this code and shows you a web page.

Let’s take a business case with the ML model as a service.

Let’s assume you work for a company that sells apartments in Boston. We want to increase our sales and offer better quality services to our customers with a new mobile application which can be used even by 1 000 000 people simultaneously. We can realize this by serving a prediction of house value when the user requests for pricing over the web.

Serving a Model

  • Training a good ML model is ONLY the first part: You do need to make your model available to your end-users You do this by either providing access to the model on your server.
  • When serving ML Model You need: a model, an interpreter, input data.
  • Important Metrics:
  1. Latency,
  2. Cost,
  3. Throughput (number of requests served per unit time)

Sharing data between two or more systems has always been a fundamental requirement of software development – DevOps vs MLOps.

Building a system ready for a production environment is more complex than training the model itself: - Cleaning and loading appropriate and validated data - Calculating variables and serving them in the correct environment - Serving the model in the most cost-efficient way - Versioning, tracking, and sharing data, models, and other artifacts - Monitoring the infrastructure and the model - Deploying the model on scalable infrastructure - Automating the deployment and training process

When you call an API, the API will receive your request. The request triggers your code to be run on the server and generates a response sent back to you. If something goes wrong, you may not receive any reply or receive an error code as an HTTP status code.

  • Client-Server: Client (system A) requests to a URL hosted by system B, which returns a response. It’s identical to how a web browser works. A browser requests for a specific URL. The request is routed to a web server that returns an HTML (text) page.

  • Stateless: The client request should contain all the information necessary to respond.

You can call APIs with a lot of different tools. Sometimes, you can even use your web browser. Otherwise, tools such as CURL do the job on the command line. You can use tools such as Postman for calling APIs with the user interface.

All communication is covered in fixed rules and practices, which are called the HTTP protocol.

Example: API Serving an ML Model Below is an example of an API service that exposes an ML model for predicting real estate prices, using FastAPI and Scikit-Learn:

from fastapi import FastAPI
import pickle
import numpy as np

# Tworzymy API
app = FastAPI()

# Wczytujemy wcześniej wytrenowany model ML (np. regresję liniową)
with open("model.pkl", "rb") as f:
    model = pickle.load(f)

@app.get("/predict/")
def predict_price(area: float, bedrooms: int, age: int):
    """
    Real Estate Price Prediction Based on Features:
    - area ( m²),
    - bedrooms (#),
    - age .
    """
    features = np.array([[area, bedrooms, age]])
    price = model.predict(features)[0]
    return {"estimated_price": round(price, 2)}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="127.0.0.1", port=8000)

Request

  1. An Endpoint URL a domain, port, path, query string - http://mydomain:8000/getapi?&val1=43&val2=3
  2. The HTTP methods - GET, POST
  3. HTTP headers contain authentication information, cookies metadata - Content-Type: application/json, text … Accept: application/json, Authorization: Basic abase64string, Tokens etc
  4. Request body

The most common format for interaction between services is the JavaScript Object Notation format. it is a data type that very strongly resembles the dictionary format in Python - key-value object.

{
"RAD": 1,
"PTRATIO": 15.3, "INDUS": 2.31, "B": 396.9,
"ZN": 18,
"DIS": 4.09, "CRIM": 0.00632, "RM": 6.575, "AGE": 65.2, "CHAS": 0, "NOX": 0.538, "TAX": 296, "LSTAT": 4.98
}

Response

  1. The response payload is defined in the response header:
200 OK
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Mon, 18 Jul 2016 16:06:00 GMT Server: Apache
Path=/;

  1. Header example: “Content-Type” => “application/json; charset=utf-8”, “Server” => “Genie/Julia/1.8.5

  2. Body example:

{":input":{"RAD":1,"PTRATIO":15.3,"INDUS":2.31,.....}}, {":prediction":[29.919737211857683]}
  1. HTTP status code: • 200 OK is used for successful requests, • 40X Access Denied • 50X Internal server error

REST API

The Representational State Transfer (REST) API works just like other APIs, but it follows a certain set of style rules that make it reconizable as a REST API: - Client-server architecture - Statelessnes - Cacheability - Layered system - Uniform Interface

Publish/Subscribe

The “Publish/Subscribe” messaging system is crucial for data-driven applications. Pub/Sub messages are a pattern in which the sender (publisher) of a piece of data (message) does not directly target a specific receiver. Pub/Sub systems often have a broker, which is a central point where the messages are stored.

Apache Kafka

On the Kafka website, you will find the definition:

Distributed Streaming Platform

What is a “distributed streaming platform”?

First, I want to remind you what a “stream” is. Streams are simply limitless data, data that never ends. They keep coming in, and you can process them in real-time.

And what does “distributed” mean? Distributed means that Kafka runs in a cluster, and each node in the group is called a Broker. These brokers are just servers that perform copies of Apache Kafka.

So, Kafka is a set of machines working together to handle and process limitless data in real-time.

Brokers make it reliable, scalable, and fault-tolerant. But why is there a misconception that Kafka is just another “queue-based messaging system”?

To answer this, we first need to explain how a queue-based messaging system works.

Queue-Based Messaging System

Message passing is simply the act of sending a message from one place to another. It has three main “actors”: - Producer: Creates and sends messages to one or more queues. - Queue: A data structure that buffers messages, receiving them from producers and delivering them to consumers in a FIFO (First-In-First-Out) manner. Once a message is received, it is permanently removed from the queue; there is no chance of retrieving it. - Consumer: Subscribes to one or more queues and receives their messages after they are published.

And that’s it; this is how message passing works. As you can see, there is nothing about streams, real-time processing, or clusters in this.

Apache Kafka Architecture

For more information about Kafka, you can visit this link.

Now that we understand the basics of message passing, let’s dive into the world of Apache Kafka. In Kafka, there are two key concepts: Producers and Consumers, who work similarly to classic queue-based systems, producing and consuming messages.


As seen, Kafka resembles a classic messaging system; however, unlike traditional queues, Kafka uses Topics instead of the concept of a queue.

Topics and Partitions

A Topic is the fundamental data transmission channel in Kafka. It can be compared to a folder where messages are stored.

Each topic has one or more partitions. This division impacts scalability and load balancing. When creating a topic, the number of partitions is defined.

Key Features of Topics and Partitions:

  • Topic is a logical unit where producers send messages, and consumers read them.
  • Partition is a physical subdivision of a topic. It can be compared to files in a folder.
  • Offset – Each message in a partition gets a unique identifier (offset), which allows consumers to track which messages have already been processed.
  • Kafka stores messages on disk, allowing them to be read again (unlike traditional queues, where a message is deleted after being processed).
  • Consumers read messages sequentially, from the oldest to the newest.
  • In case of failure, a consumer can resume processing from the last saved offset.

Kafka Brokers and Cluster

Kafka operates in a distributed manner – this means it can consist of multiple brokers, which work together as a single cluster.


Key Information about Brokers - A Broker is a single server in a Kafka cluster, responsible for storing the partitions of topics. - Each broker in the cluster has a unique identifier. - To increase availability and reliability, Kafka uses data replication. - The replication factor defines how many copies of a partition should be stored on different brokers. - If a topic has three partitions and a replication factor of three, it means each partition will be replicated across three different brokers.

The number of partitions should be chosen in a way that each broker handles at least one partition.

Producers

In Kafka, producers are applications or services that create and send messages to topics. This works similarly to queue systems, except Kafka writes messages to partitions.

How does Kafka assign messages to partitions?

  • Messages are distributed round-robin to available partitions.
  • We can specify a message key, and Kafka will calculate its hash to determine which partition the message will go to.
  • The message key determines the partition assignment – once the topic is created, the number of partitions cannot be changed without disrupting this mechanism.

Example of message assignment to partitions: - Message 01 goes to partition 0 of topic Topic_1. - Message 02 goes to partition 1 of the same topic. - The next message may go back to partition 0 if round-robin assignment is applied.

from kafka import KafkaProducer

# Tworzymy producenta Kafka
producer = KafkaProducer(bootstrap_servers="localhost:9092")

# Wysyłamy wiadomość do tematu "real_estate"
topic = "real_estate"
message = b"new flat "

producer.send(topic, message)
producer.flush()

print(f"Message in topic: '{topic}'")

Consumers

Consumers in Kafka read and process messages from topics. Each consumer can belong to a consumer group, which allows parallel message processing. - If multiple consumers belong to the same group, Kafka balances the load between them. - If one consumer fails, Kafka will automatically reassign its partitions to another active consumer.

from kafka import KafkaConsumer

# Tworzymy konsumenta, który nasłuchuje temat "real_estate"
consumer = KafkaConsumer("real_estate", bootstrap_servers="localhost:9092")

print("Wait for new message...")

for message in consumer:
    print(f"new message: {message.value.decode()}")

Another important concept in Kafka is Consumer Groups. This is crucial when we need to scale the reading of messages. It becomes costly when a single consumer must read from many partitions, so we need to balance the load between our consumers, and this is where consumer groups come in.

Data from a single topic will be load-balanced between consumers, ensuring that our consumers can handle and process the data efficiently. The ideal scenario is to have the same number of consumers in the group as there are partitions in the topic, so each consumer only reads from one partition. When adding consumers to a group, be cautious — if the number of consumers exceeds the number of partitions, some consumers will not read from any topic and will remain idle.