Yazılım Çorbası: Yazılım Mimarisi Microservices Architecture

Giriş
Mikroservis mimarisinin 3 tane önemli unsuru var. Açıklaması şöyle

A modern cloud-native application running on Microservice Architecture relies on the following critical components:

- Containerization (through platforms like Docker) - for effective management and deployment of services by breaking them into multiple processes.
- Orchestration (through platforms like Kubernetes) - for configuration, assignment and management of available system resources to services.
- Service Mesh (through platforms like Istio) - for inter-service communication through a mesh of service- proxies to connect, manage and secure microservices.

Service Mesh Nedir?
Açıklaması şöyle.

"Service mesh" is an umbrella term for products that seek to solve the problems that microservices' architectures create. These challenges include security, network traffic control, and application telemetry.

Esas amacı servisler arası iletişim. Açıklaması şöyle

A service mesh refers to a dedicated infrastructure layer for tackling service-to-service communication. It enables reliable delivery of requests through the complex topology of services constituting a modern, cloud native application.

Yani 3 tane alanda hizmet veriyorlar. Bunlar traffic management, security, and observability.

API Gateway vs Service Mesh

Açıklaması şöyle

A service mesh’s primary purpose is to manage internal service-to-service communication, while an API Gateway is primarily meant for external client-to-service communication.

API Gateway provides a single entry point for a client for a number of different underlying APIs (system interfaces/web services/Rest APIs, Lambdas, etc.). Performs traffic management, authorization and access control, monitoring, and API version management.

API Gateway operates at Layer 7. Just like layer 7 load balancers it knows about content. Thus induces an overhead in extra hop at API gateway.

Service Mesh (Popular example Istio) operates at layer 4. Provides inter service communication. Works like a sidecar to services. Handles service discovery, circuit breaking, timeouts, retries, encryption, tracebility, authentication and authorization among services.

İletşim (Communication)
Açıklaması şöyle

In a Service Mesh, proxies deployed alongside individual services enabling inter-service communication is widely known as the Sidecar Pattern. The sidecars (proxies) might be designed to handle any functionalities critical to inter-service communication like load balancing, circuit breaking, service discovery, etc.

Observability - Improved Transparency
Observability Nedir?

Açıklaması şöyle.

In software, observability (abbreviated as “o11y”) is the ability to ask new questions of the health of your running services without deploying new instrumentation. The term comes from control theory, which defines observability as the ability to understand the internal state of a system from its external outputs (source).

Telemetry consists of those “outputs”—it’s the data generated by your system that documents its state.

Şekilde Linkerd service mesh dashboard'unda service çağrıları görülebilir

Telemetry Ne Anlama Gelir?

Açıklaması şöyle.

The term comes from the Greek tele-, meaning “remote”, and -metry, meaning “measure.” You probably already generate telemetry from your programs, even if you’re not paying for monitoring or logging services. In fact, even the output from a print or console.log() statement is a form of telemetry!

Telemetry olarak

- Metrics

- Application Performance Monitoring (APM)

- Loglar

- Traces

- Structured Events

kullanılabilir

Telemetry Olarak Metrics Nedir?

Açıklaması şöyle.

One commonly used form of telemetry data in software is metrics. A metric consists of a single numeric value tracked over time. Traditional monitoring uses system-level metrics to track things like CPU, memory, and disk performance. This data is important for choosing among virtual machine instance types, with options for processor speed, RAM, and hard disk storage.

Telemetry Olarak Application Performance Monitoring (APM) Nedir?

Açıklaması şöyle. Metrics'in yetersiz kaldığı durumda, uygulamanın kendisi hakkında bilgi verir.

But it doesn’t tell you about user experience, or how to improve the performance of your code.

Modern monitoring services also provide application performance monitoring (APM) features, which track application-level metrics like average page load times, requests per second, and error rates. Each metric only tracks one variable, which makes it cheap to send and store. Values are pre-aggregated at write-time, however, so you need to deploy a code change if you want to track metrics for a new intersection of data, e.g. error rates for a specific user.

APM verisi genellikle "time-series" veritabanı üzerinde saklanır.

Telemetry Olarak Log

Açıklaması şöyle.

Logs are text strings written to the terminal or to a file (often referred to as a “flat” log file). Logs can be any arbitrary string, but programming languages and frameworks have libraries to generate logs from your running code with relevant data at different levels of specificity (e.g. INFO vs. DEBUG mode). There’s no standardization among programming communities about what should get included at each log level.

Log aggregation services allow you to send the content of your logs and store them for later retrieval. Querying flat logs (as opposed to structured logs) is slow because of the computational complexity of indexing and parsing strings, which makes these tools impractical for debugging and investigating your production code in near-realtime.

Telemetry Olarak Traces

Açıklaması şöyle.

A trace is a visualization of the events in your system showing the calling relationship between parent and child events as well as timing data for each event. The individual events that form a trace are called spans. Each span stores the start time, duration, and parent_id. Spans without a parent_id are rendered as root spans.

A distributed trace connects calling relationships among events in distributed services. For example, Service A calls Service B, which makes a database query and then hits a third-party API.

Telemetry Olarak Structured Events Nedir?

Açıklaması şöyle.

A structured event is a data format that allows you to store key-value pairs for an arbitrary number of fields or dimensions, often in JSON format. At a minimum, structured events usually have a timestamp and a name field. Instrumentation libraries can automatically add other relevant data like the request endpoint, the user-agent, or the database query.

When we talk about wide events, we mean structured events with lots of fields. You can add whatever fields you want, and because they’re key-value pairs, it’s easy to query for them later on.

Events can be built into traces by pointing each event to its parent event with the parent_id field.

Telemetry Verisinin Özellikleri

Telemetry verisinin

- Context

- Dimensionality

- Cardinality

gibi özellikleri de önemli

Telemetry Context Nedir?

Açıklaması şöyle.

Context refers to the collection of additional dimensions, fields, or tags on a piece of data that tells you more about the internal state of your system. Context can include metadata, system-level metrics, and domain-specific information about the running program.

Telemetry Dimensionality Nedir? - Verinin Kaç Farklı Sütunu Var Gibi Düşünülebilir

Açıklaması şöyle.

The dimensionality of data refers to how many fields or attributes a piece of data has attached to it. Examples of low-dimensionality data include metrics and flat logs. High-dimensionality data includes anything that can support many fields or attributes, including JSON blobs, structs, and objects.

Telemetry Cardinality Nedir? - Her Sütun Kaç Farklı Değer Alabilir Gibi Düşünülebilir

Açıklaması şöyle.

The term cardinality refers to how many possible values a dimension can have. Some examples of low-cardinality data include booleans (true/false) and days of the week. High-cardinality examples are first name, social security number, UUID, or build ID.

Cardinality becomes especially relevant when you start considering multiple dimensions at the same time. For a REST API, for example, endpoints can number from dozens or hundreds (not including unique IDs). If you want to look at the behavior of each endpoint across the over 43 million user agents in the world, you get what’s called a cardinality explosion. Imagine trying to track the intersection of endpoint × user agent with application-level metrics—that’s billions of lines of code. Thus when you have questions that require high-cardinality data to answer, you need telemetry and tools that support it.

Sadece Telemetry Yeterli mi?

Açıklaması şöyle. Cevap hayır. Yardımcı araçlar da gerekir.

In order to have good observability into your software services, you need both good instrumentation generating high-context telemetry data, and you need sophisticated ways of interacting with that data that enable asking novel questions—questions you couldn’t have thought of when you wrote the code. Put more simply, software observability requires good data and good tooling.

Service mesh Observability yeteneğine yardımcı olur. Açıklaması şöyle

It isn’t easy to follow the complex flow of traffic behavior within an unclear and dense cloud-native environment. Messages take a winding path through the topology, moving between the infrastructure layers and transitioning from pod to pod on a unique track. This is where service mesh brings transparency to the way application modernization services are delivered. You can thus track their behavior effectively.

Bazı Service Mesh Ürünleri

Bazı çözümler şöyle

The leading solutions today are:

- Istio: A full open-source solution founded by IBM, Google and Lyft.
- App Mesh: Exclusive to AWS.
- Linkerd: Initially developed by Twitter for internal use, in 2017 it was made open-source and donated to the CNCF.
- Consul Connect: Open-source with a premium paid service.
- SMI (Microsoft Service Mesh Interface): Announced at KubeCon in 2019, it is backed by heavy players such as Linkerd, HashiCorp, Colo.io, and VMWare.

Nasıl Çalışır

Açıklaması şöyle

Service Mesh katmanını sağlamanın 3 farklı yolu mevcut.
- Mikroservis uygulamasına non functional kod yazarak veya dependency olarak kütüphaneler ekleyerek (Hystrix, Ribbon, Feign client gibi)
- Node agentlar aracılığıyla nodelar üzerinde denetimler sağlayarak
- Ya da Sidecar Proxy’ler aracılığı ile.

Sidecar Proxy Nedir?

Açıklaması şöyle. Yani pod üzerinde iki tane container oluyor. İkinci contaier sidecar proxy container

What is a sidecar pattern?
The sidecar pattern is a single-node(pod) pattern that has two containers. The first is the application container. It contains the core business logic for the application. In addition to the application container, there is a sidecar container. The role of the sidecar is to augment the application container.

Açıklaması şöyle

Sidecar Proxy’ler adından da anlaşılacağı üzere aslında birer proxy. Servislerin yanına konumlanırlar. Servisler hedef servislere erişimlerini o servise ait sidecar proxy üzerinden sağlarlar. Sidecar’ları sadece servis intercommunication’ı değil; load balancing, service discovery, authorization, authentication gibi konuları da çözen bir kutu olarak düşünebiliriz. Örneğin balancing üzerinden konuşursak, 3er instance çalışan listeleme ve stok servislerinden 2 stok servisi bottleneck içerisinde ise sidecarlar gelen istekleri daha stabil olan 3. containera yönlendirme aksiyonunu gerçekleştirebilirler. Sidecarlarınız Kubernates gibi bir orchestration frameworkünde yönetiliyorsa OSI 4. katmanda load balancing işlemleri gerçekleştirilir. Bu da bir yazılımcının bunu kodlamasından daha hızlı sonuçlar ortaya çıkaracaktır. Ayrıca servis sayısının artması durumunda servisler arası iletişimin daha güvenilir olmasını sağlayacaktır.

Yani sidecar proxy

- service intercommunication : Hiç bir servis birbirini direkt çağırmaz.

- load balancing

- service discovery

- authorization

- authentication

gibi işlevleri yerine getirir

Şeklen şöyle