These expectations came together in a product I worked on recently. The application ran as separate workloads on Kubernetes, while customers received its entire ecosystem through one installation package.

I think of this as a product that feels monolithic to develop and install, but runs as a distributed system. With clear component boundaries, we can add useful runtime and operational capabilities to that cohesive experience. There is also a cost to carrying this responsibility.

Why did I need this approach?

The delivery model is on-premises. Unlike a centrally operated SaaS service where customers receive accounts, this product is installed in each customer’s own infrastructure. The application arrives with the environment it needs to run.

That environment includes a database, identity management, messaging, and monitoring. Each component supports the application. Selecting, connecting, and configuring these tools manually for every customer could turn delivery into a recurring integration project.

I wanted installation knowledge to become part of the product. The system prepared for one customer needed to be installable for another through the same recipe, using that customer’s settings. From the customer’s perspective, this should be one product installation.

The runtime requirements still made separate components useful. A user-facing service and a background worker may have different load profiles. Established open-source tools can handle identity or data storage. Delivering these parts together does not require them to run and grow in the same way.

One development experience, one delivery package

What I appreciate about developing a monolithic application is the ability to keep the whole product in mind. I open the project, see how its parts relate, and evaluate a feature in context. A distributed application can preserve that experience.

Here, “monolithic feel” describes development and installation. Code organization, the delivery package, and runtime topology are separate design decisions. A product developed together and delivered in one package can run as separate processes, and where needed on different nodes, in Kubernetes.

The customer’s entry point looks like this, using an illustrative command name:

product install

Once the package is available in the target environment, supported server prerequisites are met, and connection details are supplied, this command starts the installation flow. K3s prepares Kubernetes; Helm installs the platform services and application. Initial database definitions, application access settings, and component readiness checks belong to the same flow.

The customer does not have to run a separate installation procedure for every service. Environment-specific settings remain separate, while the package carries the knowledge of how the components fit together.

In this project, application image building also happens inside the target environment. BuildKit produces the image on the platform where it will run. Components requiring compilation use toolchains and base images appropriate for the supported processor architecture. The image is pushed to the local Zot registry and runs on the same platform. Runtime settings are applied during installation, while secrets are provided without baking them into the image.

For the customer, this path from source code to a running application becomes part of the product’s installation behavior.

Where should cohesion end and boundaries begin?

This is the decision that determines whether the approach works. If a unified product experience makes every component dependent on the internal details of the others, we lose much of the value of distributed execution.

The package defines the product boundary. Component responsibilities need their own boundaries.

It should be clear which data a component owns, which API or message contracts it exposes, and who is affected when it changes. Requiring components to understand one another’s internal tables, implementation details, or private configuration expands the impact of change.

The same distinction applies to updates. We can ship a product release containing components tested together. That does not mean every application change must reinstall the database, identity service, and entire platform. Compatible changes should be applicable to the relevant component. Changes to data schemas or service contracts need their own coordination.

A shared development environment is comfortable when responsibilities are clear. Otherwise, every change inside the package can become a whole-product concern.

The question of where we manage complexity, which I explored in my writing about cloud-native and monolithic systems, matters here too. We can offer cohesion to developers and customers while keeping component relationships explicit in the platform design.

What do we gain?

The first benefit is repeatable delivery. The order of installation and the required initialization settings travel with the product. Checking existing versions, configuration, and health is part of that experience. Installation and upgrades become defined product operations.

The second benefit is runtime visibility and targeted intervention. When logs, metrics, and health information are associated with components, we can focus investigation on the relevant part. With suitable boundaries, we can restart, update, or change the capacity of one component while limiting the effect on the rest of the product.

This separation also supports performance management. We can add consumers to a busy background workload or scale request-handling services according to their own load. Appropriate metrics and autoscaling policies can automate these changes. Instead of growing the whole product at the same rate, we can expand the part that needs capacity.

This is a capability we can build on the architecture. Application concurrency, data-layer capacity, and available cluster resources determine the result. In an on-premises environment, autoscaling still operates within the customer’s hardware capacity and configured limits.

Another benefit is broader access to the open-source ecosystem. We can integrate established tools for identity, messaging, or monitoring into the product. Components do not all need to use the same language. As an illustrative example, an API could use .NET and a background worker Python, while the customer installs both as parts of one product.

The Lego analogy is useful here. Service contracts, data ownership, and version compatibility are the connection points. When those are defined well, we can use the accumulated work of existing tools and focus our own effort on the product’s distinctive functionality.

A useful consequence: Developing in the same environment

Once we have an installable ecosystem for customers, we can install the same package for development. For me, easier local development is a natural benefit of this delivery model.

Tools such as Docker Compose and Aspire, familiar from the .NET ecosystem, can also bring services into a shared development experience. The property I want to preserve here is that the actual customer platform runs in development through its own installation recipe.

We use the same Kubernetes distribution, database, messaging, and identity services. The application communicates with the real components; I do not replace them with substitutes for development. A background task connects to the product’s messaging service, and a sign-in flow uses its identity service.

In this sense, I develop in a separate instance of the production environment. It is isolated from the customer’s live system and data and can run in a local virtual machine or on development servers. Hardware capacity, node count, and settings may differ, while the components and operating recipe remain consistent. Performance and high-availability assessments still require tests appropriate to the target capacity.

Developing inside the ecosystem the product will use lets us address some delivery uncertainties earlier.

Where do we pay for this convenience?

For the customer to install with one command, we must design everything behind that command. Component compatibility, startup order, access rules, and data relationships become part of product maintenance. Open-source updates and security fixes must be evaluated within that whole.

Installation is the beginning of the lifecycle. Backup and recovery, schema changes, application updates, and support need their own design. Responsibilities must also be clear between the product team and the customer. One installation command alone does not guarantee easy operations.

On-premises customers may remain on different versions. Network access, certificates, storage, and hardware capacity can vary. Defining supported environments and validating upgrade paths takes ongoing effort.

Working on offline installation made this delivery responsibility especially clear. Images and build dependencies must be prepared in advance, package integrity checked, and target prerequisites defined. Supporting restricted-network environments adds responsibilities to release preparation.

There is also a resource cost. Running a full platform alongside a small application requires memory, storage, and operational knowledge. If images are built in the target environment, build capacity and permissions must be included. The simpler development and installation experience is supported by an investment in platform engineering.

When would I choose it, and when would I avoid it?

I consider this approach for products that will be installed repeatedly in different customers’ infrastructure and developed over time. Components with different runtime needs, targeted intervention or scaling requirements, and useful open-source dependencies can justify turning the installation ecosystem into part of the product.

The team’s ability to maintain the platform is part of that decision. Writing the installation recipe once is not enough. It must evolve with versions, security updates, and customer environments.

If the customer already has a standardized Kubernetes platform, I reconsider including a cluster in the package. Adapting the application and its dependencies to that platform may be more appropriate. A centrally delivered SaaS product also changes the justification, because customer-by-customer installation is no longer the same requirement.

My deciding factors are how the product will be delivered and how it will operate over the years. When we can preserve one product experience while making useful use of component independence, this design has a strong purpose.

One area where I contribute in development and consulting is considering these decisions together: developers must be able to understand the product, customers must be able to install it, and operations teams must be able to manage it. Bringing those needs into one design makes the application a product we can keep delivering and supporting.

Yakın zamanda üzerinde çalıştığım bir üründe bu beklentiler aynı tasarımda buluştu. Uygulama Kubernetes üzerinde ayrı iş yükleriyle çalışıyor; müşteriye kendi ekosistemiyle birlikte tek bir kurulum paketi olarak gidiyordu.

Bu deneyimi anlatırken aklıma gelen ifade, monolitik tadında geliştirilen ve kurulan, dağıtık çalışan bir ürün oldu. Bu bütünlüğü korurken bileşenlerin sınırlarını da doğru çizebilirsek, geliştirme rahatlığının üzerine önemli çalışma ve işletim yetenekleri ekleyebiliyoruz. Bunun için üstlenmemiz gereken bir maliyet de var.

Neden böyle bir yapıya ihtiyaç duydum?

Bu çalışmanın teslim modeli on-premise. Merkezi olarak işlettiğimiz ve müşterilere hesap açtığımız bir SaaS hizmetinden farklı olarak, her müşterinin kendi altyapısına kurulacak bir ürün geliştiriyoruz. Uygulama, ihtiyaç duyduğu çalışma ortamıyla birlikte müşteriye gidiyor.

Bu ortamda veritabanı, kimlik yönetimi, mesajlaşma ve izleme gibi bileşenler var. Bunların her biri uygulamanın çalışmasında bir rol üstleniyor. Her müşteri kurulumunda bu araçları yeniden seçmek, elle bağlamak ve başlangıç ayarlarını ayrı ayrı yapmak, teslimatı tekrar eden bir entegrasyon işine dönüştürebilir.

Ben kurulum bilgisini ürünün içine almak istedim. Bir müşteride hazırladığımız sistemin, başka bir müşteride de o ortama ait ayarlarla aynı tarif üzerinden kurulabilmesi gerekiyordu. Müşterinin gördüğü deneyim tek bir ürün kurulumu olmalıydı.

Çalışma ihtiyaçları ise ayrı bileşenleri anlamlı kılıyordu. Kullanıcıya cevap veren bölümle arka planda işleyen görevler aynı yük profiline sahip olmayabilir. Kimlik yönetimi veya veri saklama için açık kaynak ekosistemindeki araçlardan yararlanabiliriz. Bu parçaları birlikte teslim etmek, hepsinin aynı şekilde çalışmasını ve büyümesini gerektirmiyor.

Geliştirirken bir bütün, teslim ederken tek paket

Monolitik uygulama geliştirmenin sevdiğim tarafı, ürünün zihnimde bir bütün olarak kalması. Projeyi açıyorum, parçaların birbiriyle ilişkisini görüyorum ve geliştirdiğim özelliği bu bütünün içinde değerlendirebiliyorum. Dağıtık çalışan bir sistemde de bu deneyimi korumak mümkün.

Burada “monolitik tadında” ifadesiyle geliştirme ve kurulum deneyimini tarif ediyorum. Kodun organizasyonu, teslimat paketi ve çalışma topolojisi farklı tasarım kararları. Birlikte geliştirdiğimiz ve tek paketle teslim ettiğimiz ürün, Kubernetes üzerinde ayrı süreçlerde ve gerektiğinde farklı node’larda çalışabilir.

Müşterinin gördüğü giriş noktası, temsili bir isimle şöyle:

urun install

Paket hedef ortama alındığında, desteklenen sunucu ön koşulları ve gerekli bağlantı bilgileri sağlandığında, bu komut bütün kurulum akışını başlatıyor. K3s ile Kubernetes hazırlanıyor; Helm üzerinden platform servisleri ve uygulama kuruluyor. Veritabanının başlangıç tanımları, uygulamanın erişim ayarları ve bileşenlerin hazır olma kontrolleri de aynı akışta ele alınıyor.

Böylece müşteri her servis için ayrı kurulum adımları yürütmüyor. Ortama ait ayarlar ayrı tutuluyor, bileşenlerin nasıl bir araya geleceğinin bilgisi paketle birlikte taşınıyor.

Bu çalışmada uygulamanın imaj üretimini de hedef ortamın içine aldım. BuildKit, uygulama imajını çalışacağı platformda üretiyor; derleme gerektiren parçalar desteklenen işlemci mimarisine uygun araç zinciri ve taban imajlarla hazırlanıyor. İmaj yerel registry olan Zot’a aktarılıp aynı platformda çalıştırılıyor. Ortama ait çalışma ayarları kurulumda uygulanırken gizli bilgiler imaja gömülmeden sağlanıyor.

Müşteri açısından kaynak koddan çalışan uygulamaya uzanan bu süreç, ürünün kurulum davranışının bir parçası oluyor.

Bütünlük nerede bitmeli, sınırlar nerede başlamalı?

Bu yaklaşımın başarısını belirleyen nokta bence burası. Tek ürün deneyimi oluştururken her parçayı birbirinin iç yapısına bağımlı hale getirirsek, dağıtık çalışmanın getirisini azaltırız.

Paketin sınırı ürünün sınırıdır. Bileşenlerin sorumluluk sınırları ise ayrıca tasarlanmalıdır.

Bir bileşenin hangi veriyi yönettiği, diğerlerine hangi API veya mesaj sözleşmesiyle ulaştığı ve değiştiğinde kimleri etkilediği anlaşılır olmalı. Her bileşenin başka bir bileşenin iç tablolarını, ayrıntılı uygulama davranışını veya özel yapılandırmasını bilmesi, değişikliklerin etki alanını büyütür.

Aynı ayrım güncelleme için de geçerli. Birlikte test edilmiş bileşenleri tek ürün sürümünde paketleyebiliriz. Bu, her uygulama değişikliğinde veritabanını, kimlik servisini ve bütün platformu yeniden kurmamız gerektiği anlamına gelmez. Uyumlu değişikliklerin yalnızca ilgili bileşene uygulanabilmesini tasarlamak gerekir. Veri şeması veya servis sözleşmesi değiştiğinde ise koordinasyon ihtiyacı ayrıca ele alınır.

Ortak geliştirme ortamı, açık sorumluluk sınırlarıyla birlikte rahatlık sağlar. Aksi durumda tek paket içindeki her değişiklik, bütün ürünün yeniden değerlendirilmesini gerektiren bir işe dönüşebilir.

Cloud-native ve monolit üzerine yazımda bahsettiğim karmaşıklığın nerede yönetildiği konusu burada da belirleyici. Bütünlüğü geliştiriciye ve müşteriye sunarken, parçalar arasındaki ilişkileri platform tasarımında görünür tutmak gerekiyor.

Karşılığında ne kazanıyoruz?

İlk kazanım, teslimatın tekrarlanabilir hale gelmesi. Yeni bir müşteri ortamına giderken hangi bileşenin önce kurulacağı ve hangi başlangıç ayarlarının uygulanacağı ürünle birlikte geliyor. Kurulumun mevcut sürüm, yapılandırma ve sağlık durumunu dikkate alması da bu deneyimin parçası. Böylece kurulum ve güncelleme, tanımlı ürün işlemleri olarak ele alınabiliyor.

İkinci kazanım, çalışma anındaki görünürlük ve müdahale esnekliği. Loglar, metrikler ve sağlık bilgileri bileşenlerle ilişkilendirildiğinde, incelemeyi ilgili noktaya yönlendirebiliyoruz. Sınırları doğru kurulmuş bir sistemde belirli bir bileşeni yeniden başlatmak, güncellemek veya kapasitesini değiştirmek mümkün oluyor. Müdahalenin etki alanını daraltarak ürünün diğer işlevlerini koruyabiliyoruz.

Bu ayrım performans yönetiminde de değerli. Yoğunlaşan bir arka plan işine daha fazla tüketici ayırabilir, istek karşılayan servisleri kendi yüklerine göre ölçekleyebiliriz. Uygun metrikler ve autoscaling politikaları tanımlandığında bu kapasite değişiklikleri otomatik yürütülebilir. Bütün ürünü aynı oranda büyütmek yerine, ihtiyaç duyulan parçayı büyütme imkânı elde ederiz.

Bu, mimarinin üzerine kurulabilen bir yetenektir. Uygulamanın paralel çalışmaya uygunluğu, veri katmanının kapasitesi ve kümenin kullanılabilir kaynakları sonucu belirler. On-premise ortamda otomatik ölçekleme de müşterinin mevcut donanım kapasitesi ve tanımlanan sınırlar içinde gerçekleşir.

Bir diğer kazanım, açık kaynak ekosisteminden daha geniş yararlanabilmek. Kimlik yönetimi, mesajlaşma veya izleme için belirli bir işi iyi yapan araçları ortak ürün düzenine dahil edebiliyoruz. Her bileşenin aynı dilde yazılması da gerekmiyor. Temsili olarak bir API .NET ile, arka plan görevi Python ile geliştirilebilir; müşteri ikisini aynı ürünün parçaları olarak kurar.

Lego benzetmesi burada anlamlı. Parçaları bir arada tutan bağlantı noktaları; servis sözleşmeleri, veri sahipliği ve sürüm uyumudur. Bunları doğru tanımladığımızda, mevcut araçların birikiminden yararlanıp kendi emeğimizi ürünün özgün işlevlerine yönlendirebiliriz.

Bu tasarımın bir meyvesi: Aynı ortamda geliştirmek

Müşteriye kurulabilir bir ekosistem hazırladığınızda, aynı paketi geliştirme için de kurabiliyorsunuz. Benim için lokal geliştirme kolaylığı, bu teslim modelinin doğal kazanımlarından biri.

Docker Compose veya .NET ekosisteminden tanıdığımız Aspire gibi araçlarla da servisleri ortak bir geliştirme deneyiminde buluşturabiliyoruz. Burada korumak istediğim özellik, müşteriye teslim edilen platformun kendi kurulum tarifiyle geliştirme ortamında da çalışması.

Aynı Kubernetes dağıtımı, aynı veritabanı, aynı mesajlaşma ve kimlik servisleri kullanılıyor. Uygulama gerçek bileşenlerle iletişim kuruyor; geliştirme için onların yerine muadil araçlar koymuyorum. Arka plan görevini yazarken ürünün mesajlaşma servisine, giriş akışını geliştirirken ürünün kimlik servisine bağlanıyorum.

Bu anlamda üretim ortamının ayrı bir örneğinde geliştirme yapıyorum. Müşterinin canlı sisteminden ve verilerinden ayrı olan bu ortam, yerel bir sanal makinede veya geliştirme sunucularında kurulabilir. Donanım kapasitesi, node sayısı ve ortam ayarları değişse de kullanılan bileşenler ve çalışma tarifi korunur. Performans ve yüksek erişilebilirlik değerlendirmeleri için ise hedef kapasiteye uygun testler gerekir.

Ürünü çalışacağı ekosistemin içinde geliştirebilmek, teslimata hazırlanırken taşıdığımız belirsizliklerden bir bölümünü daha erken ele almamızı sağlıyor.

Bu rahatlığın bedelini nerede ödüyoruz?

Müşterinin tek komutla kurulum yapabilmesi için o komutun arkasındaki işleri bizim tasarlamamız gerekiyor. Bileşenlerin sürüm uyumu, başlangıç sırası, erişim kuralları ve veri ilişkileri ürünün bakım kapsamına giriyor. Açık kaynak araçların güncellemelerini ve güvenlik düzeltmelerini de bu bütün içinde değerlendirmeliyiz.

Kurulum, yaşam döngüsünün başlangıcı. Yedekleme ve geri yükleme, veri şeması geçişleri, uygulama güncellemeleri ve destek süreçleri ayrıca tasarlanmalı. Bunların sorumluluğunun ürün ekibi ile müşteri arasında nasıl paylaşılacağı da açık olmalı. Tek kurulum, tek başına kolay işletim garantisi vermiyor.

On-premise teslimatta farklı müşteriler farklı sürümlerde kalabilir. Ağ erişimi, sertifika düzeni, depolama ve donanım kapasitesi değişebilir. Desteklenen ortamların sınırını tanımlamak ve güncelleme yollarını doğrulamak için sürekli emek gerekiyor.

Çevrimdışı kurulum üzerinde çalışırken de bu teslim sorumluluğu belirginleşti. Gerekli imajları ve build bağımlılıklarını önceden hazırlamak, paket bütünlüğünü kontrol etmek ve hedef platformun ön koşullarını belirlemek gerekiyor. İnternet erişimi kısıtlı ortamlara teslim imkânı kazanırken, dağıtım paketinin hazırlanmasına daha fazla sorumluluk ekliyoruz.

Kaynak maliyeti de var. Küçük bir uygulamanın yanında bütün bir platform çalıştırmak; bellek, disk ve işletim bilgisi gerektiriyor. Hedef ortamda imaj üretmeyi seçiyorsak build işlemlerinin kapasitesini ve yetkilerini de hesaba katmalıyız. Geliştirme ve kurulumdaki sadeliğin karşılığında, platform mühendisliğine yatırım yapıyoruz.

Ne zaman tercih ederim, ne zaman etmem?

Bu yaklaşımı, farklı müşterilerin kendi altyapılarına tekrar tekrar kurulacak ve zaman içinde geliştirilecek ürünlerde değerlendiririm. Birden fazla çalışma ihtiyacı olan bileşenler, kısmi müdahale veya ayrı ölçekleme gereksinimi ve açık kaynak servislerden yararlanma isteği varsa, kurulum ekosistemini ürünleştirmek anlamlı hale gelir.

Ekibin bu platformu sürdürebilmesi de kararın parçası. Kurulum tarifini bir kez hazırlamak yeterli olmaz; sürümler, güvenlik güncellemeleri ve müşteri ortamlarıyla birlikte yaşatabilmek gerekir.

Müşterinin zaten standartlaştırılmış bir Kubernetes platformu varsa, kendi kümemi de pakete dahil etme kararını yeniden değerlendiririm. O durumda uygulama ve bağımlılıklarını mevcut platforma uyarlamak daha uygun olabilir. Merkezi bir SaaS teslim modelinde de müşteri başına kurulum ihtiyacı aynı olmadığı için bu paketleme yatırımının gerekçesi değişir.

Benim için tercih ölçütü, ürünün nasıl teslim edileceği ve yıllar içinde nasıl işletileceği. Tek ürün deneyimini korurken parçaların çalışma özgürlüğünü anlamlı biçimde kullanabiliyorsak, bu tasarım güçlü bir karşılık veriyor.

Geliştirme ve danışmanlık çalışmalarında değer ürettiğim alanlardan biri de bu kararları birlikte ele almak: geliştiricinin ürünü anlayabilmesi, müşterinin kurabilmesi ve operasyon ekibinin yönetebilmesi. Bu üçünü aynı tasarımda buluşturmak, uygulamayı sürdürülebilir biçimde teslim edilebilir bir ürüne dönüştürüyor.

I did not reach this point by discovering one clever prompt. The path included local-model experiments, oversized skill files, exhausted token allowances, and automation that could fail in dangerous ways. The central lesson was simple: running a model and operating a reliable AI system are very different problems.

Why local models remain attractive

Running a SaaS-backed agent on my own computer initially made me uncomfortable, and the concern has not disappeared. Data privacy, confidential company information, and knowing what is sent to which provider are serious questions with no universal answer.

An entirely local, offline model is therefore appealing. Yet much of the value delivered by a cloud AI product does not come from model weights alone. Search, web clients, document parsers, indexes, code execution, tool integrations, identity, and permission controls all affect the quality of the result.

Starting a local model often gives you an advanced chatbot. To reproduce a capable operator, you must also provide tools, APIs, retrieval, access policies, observability, and an execution environment. Taken far enough, this becomes a private AI platform that you must build and operate yourself.

That can be a valid choice. It resembles running your own mail server at home: possible, sometimes necessary, but accompanied by maintenance, security, hardware, and time costs. Unless you are a large organization, generate heavy usage, or earn revenue from the infrastructure, a managed service can remain cheaper. That was the outcome of my own experiments.

A model is not an operator by itself

An LLM produces likely output from the context it receives. It can say “I don’t know,” but that does not mean it will reliably identify every missing fact. In operational work, the tendency to fill an unspecified gap with a plausible assumption is a risk.

Consider a well-documented user-management API. If its endpoints, authentication, request bodies, and error responses are explicit, the documentation becomes part of the agent’s operating context. The agent can construct a user-creation request and, when it has network access and credentials, execute it.

Location matters. A cloud agent cannot automatically reach a service on a private local network. An agent running on the relevant machine or network may reach it when properly authorized. What the model knows is only one part of the system; where the agent runs and what it may access are equally important.

From API documentation to a skill

API documentation explains the technical call. A skill defines the policy for using it:

• Which documentation must be read first?
• Which environment is the default?
• Which actions must remain read-only?
• Which changes require human approval?
• How will the outcome be verified and reported?
• Should an error trigger a retry or stop the workflow?

A skill for a user-management application can instruct the agent to fetch the current API documentation, prepare the request, assess its impact, and report the result. A general-purpose model then becomes a limited operator for a specific application.

flowchart LR
    I["Request"] --> S["Relevant skill"]
    S --> D["Current documentation"]
    D --> P["Plan and command"]
    P --> R["Independent review"]
    R -->|Approved| E["Execution"]
    R -->|Revise| P
    E --> V["Verification and report"]

The skill should not memorize every command. It should define how to find the authoritative source, which boundaries apply, and when the agent must stop.

A second and third pair of eyes

Agents make mistakes in API calls just as they do in code. A development error may cost time; an incorrect production call can cause data loss or an outage.

I therefore put independent checks into the workflow. One agent interprets the request and prepares the action. A second agent, with separate context, reviews both the requirement and the proposed command. If it rejects the plan, nothing runs; its findings return to the first workflow for revision.

A second pass by the same model is helpful but not fully independent. For higher-risk work, review can be sent to another model or provider. What people describe as “build with Codex, review with Claude, verify with Gemini” becomes more useful when expressed as a repeatable policy rather than a personal habit.

This is still not a proof of correctness. Two models can share the same false assumption. Human approval, least privilege, backups, dry runs, and before-and-after verification remain necessary for irreversible operations.

Simulating the viewpoints of a team

Engineering titles such as junior, senior, lead, architect, and tester exist because a team needs different questions and responsibilities. I use a similar separation in agent workflows. The value does not come from pretending that each role is a real person; it comes from reviewing the same change through distinct, constrained contexts.

An architect may define boundaries, a developer implement the change, a reviewer examine risk and consistency, and a tester validate acceptance criteria. When this exists only in chat, the history quickly becomes fragile. When the workflow operates through an issue-management system, each role advances the issue, records evidence, and hands it to the next stage. The virtual team then works on a persistent record rather than an ephemeral conversation.

What a local AI platform actually contains

Open-source and self-hosted components are available for this kind of system, but the following layers show the distance between downloading a model and running an operational platform:

This is not a deployment recipe. Identity, secret storage, sandboxing, logs, evaluations, backups, and network policy still have to be designed. A GPU cluster makes experimentation possible, but renting compute and operating a reliable, isolated model service are different businesses.

Installing the tools is the most visible and often the easiest part. The real work is analyzing an organization’s processes, identifying decision and authority boundaries, delivering the right context at the right time, designing safety gates, and integrating the pieces with existing platforms. The same tool list can produce very different operating models in two organizations.

How I applied the approach

I gradually moved the Kubernetes clusters, Azure services, development work, technical documentation, social media processes, and blog operations that I manage into this model, provided they are authorized for AI use. Today I can send an instruction from my phone and have it executed through an authorized working environment even when I am away from my desk. It sounds a little like Jarvis from Iron Man, but the mechanism is not magic. It is standards, access, and documentation.

I follow roughly the same sequence for each kind of work:

1. Turn the task into a repeatable standard.
2. Document decision points and prohibited actions.
3. Prepare the authoritative documentation.
4. Make the skill retrieve only the relevant material.
5. Add review and approval gates according to risk.
6. Verify the outcome independently after execution.

Writing the documentation can take as long as writing code. The difference is that I now prepare the definition once for many recurring tasks. The agent can use that source for later development or operational work without requiring the process to be explained again.

Ambiguity must be treated as a design flaw. I do not want a personal photograph inserted into an article without permission, a private message sent to the wrong person, or a month-old backup restored over production. These constraints cannot be captured by saying “be careful.” They require target verification, explicit prohibitions, approval conditions, and a rollback plan.

The token wall

My first system worked, but it was not economical. The weekly allowance of the plan I used, which cost roughly €100, stopped being enough. Email, cluster and Azure operations, coding, issue tracking, and repeated review loops all consumed the same token budget. For a while, I had to buy additional capacity.

Optimization became the point where my own engineering contribution mattered most. Instead of sending all available context to every task, I designed a way to select only what was relevant.

One of my earliest skill files exceeded 100,000 words. In my current use case, I manage a similar scope with roughly 5,000 words of core instruction plus documentation loaded on demand. This is a personal example of what better context selection achieved, not a general promise of the same reduction for every workload. I did more than edit for brevity; I changed the context architecture.

• Common rules live in one place.
• Task-specific documents load only when needed.
• Agents receive the relevant issue and files, not the entire history.
• Output format and length are constrained.
• Tools return structured results instead of repeated prose.
• Simple tasks do not use the most expensive model or multiple reviews.

The same plan can now handle authorized reviews, development, issue management, cluster and platform operations, and much of my personal work. Lower token use is only one benefit. With less irrelevant context, results also became more consistent.

There is no universal optimization recipe here. The type of work, available tools, data sensitivity, cost of failure, and expected output must be analyzed together before the right combination of models, context, and controls can be selected. An efficient system comes less from copying a ready-made skill than from understanding how an organization actually works and designing for that environment.

Employer policy, data, and authority

Technical capability is not authorization. When work involves an employer, customer, or regulated data, company policy, contracts, data classification, regulation, and provider terms all matter.

Sending information from defense, healthcare, finance, or another controlled environment to a general SaaS service may be unacceptable. An internal model, private cloud, data masking, or a restricted set of approved tools may be required instead. The appropriate design depends on the industry, the data, and the threat model.

AI should therefore not be introduced secretly into a workplace process. Security, legal, management, and engineering stakeholders need an explicit operating model. An agent should never receive broader permissions than the human role it represents.

What I gained

The most valuable result is not that I can produce more work. It is that I recovered time. I can socialize more, go to the sea with my son almost every day, watch a film in the evening, and make our time together more meaningful.

In the past, part of my attention could remain trapped in a technical problem while I was with other people. Now I can record the problem and delegate research, alternatives, and the first implementation steps. I return when a real decision is required.

That does not reduce my responsibility. I delegated the operations, not the ownership.

Dependency and skill decay

AI-driven work creates dependency. A service outage can stop the process. More importantly, stepping away from the craft for too long can weaken your understanding and troubleshooting ability.

Junior engineers may never build the fundamentals; senior engineers may forget details they no longer practice. When operating an agent replaces understanding the system, engineering can gradually become little more than being a customer. I explored this risk further in Artificial Intelligence and the Human Mind: The Erosion of Thinking, Decay of Code, and Loss of Control.

I therefore still do some work manually, read generated commands, explain architectural decisions, and make sure I can intervene without AI when the system fails. Automation should not purchase speed by giving up competence.

Decisions stay with me

AI is no longer just a chatbot in my workflow, but it is not an unrestricted virtual employee either. It is an operational layer grounded in documentation, constrained by skills, and reviewed by other agents or models when the risk justifies it.

Successful delegation did not mean allowing AI to make more decisions. It meant implementing my decisions with less repetition, better records, and lower operational effort. Building this kind of system begins before model selection: the processes must be analyzed and organization-specific authority and control mechanisms must be designed. The technology components may be available, but turning them into a dependable operating model is the real design work.

The final review remains mine, because even when AI acts on my behalf, the model will not be the one accountable for the outcome.

Bu noktaya tek bir iyi prompt yazarak gelmedim. Yerel model denemeleri, büyüyen skill dosyaları, tükenen token limitleri ve hataya açık otomasyonlar üzerinden ilerledim. Sonunda öğrendiğim şey şuydu: Bir modeli çalıştırmakla, güvenilir bir operasyon sistemi kurmak aynı şey değil.

Yerel model fikri neden hâlâ cazip?

Yerel bilgisayarımda SaaS tabanlı bir agent çalıştırmak ilk zamanlarda beni ciddi biçimde tedirgin ediyordu. Veri gizliliği, şirket bilgilerinin dışarı çıkması ve hangi içeriğin hangi sağlayıcıya gönderildiği hâlâ önemsediğim konular. Bunların kolay veya herkes için geçerli tek bir cevabı yok.

Modeli tamamen yerelde ve çevrimdışı çalıştırma fikri bu nedenle çok çekici. Fakat bulut servislerinden aldığımız katma değer yalnızca model ağırlıklarından gelmiyor. Arama motoru, web istemcisi, doküman ayrıştırıcıları, indeksleme, kod çalıştırma ortamı, araç bağlantıları, kimlik ve izin yönetimi gibi katmanlar modelin iş kalitesini doğrudan etkiliyor.

Yerelde yalnızca bir model ayağa kaldırdığınızda çoğu zaman gelişmiş bir sohbet botu elde ediyorsunuz. Aynı kalite ve hareket alanı için modele araçlar, API’ler, arama, erişim politikaları, gözlemlenebilirlik ve bir yürütme ortamı sağlamanız gerekiyor. Bunu yeterince ileri götürdüğünüzde kendiniz için küçük bir AI platformu kurmaya başlıyorsunuz.

Bu tercih yanlış değil. Kendi e-posta sunucunuzu evde çalıştırmaya benziyor: Yapabilirsiniz, belirli koşullarda yapmanız da gerekebilir; fakat bakım, güvenlik, donanım ve zaman maliyetini de üstlenirsiniz. Büyük bir kurum değilseniz, yoğun kullanım üretmiyorsanız veya bu altyapıdan doğrudan gelir elde etmiyorsanız hazır hizmet çoğu zaman daha ekonomik kalıyor. Benim denemelerimde de sonuç bu oldu.

Model tek başına operatör değildir

LLM, kendisine verilen bağlama göre olası çıktıyı üretir. “Bilmiyorum” diyebilir; fakat bu, her bilgi boşluğunu güvenilir biçimde tespit ettiği anlamına gelmez. Eksik talimatın bıraktığı alanı makul görünen bir tahminle doldurması özellikle operasyon işlerinde tehlikelidir.

Bir kullanıcı yönetimi API’sinin iyi hazırlanmış dokümantasyonunu modele verdiğimizi düşünelim. Endpoint, kimlik doğrulama, istek gövdesi ve hata cevapları açıkça yazılmışsa doküman aynı zamanda çalışma bağlamının bir parçası olur. Agent, kullanıcı oluşturmak için gerekli çağrıyı hazırlayabilir ve çalıştığı ortamdan API’ye erişebiliyorsa isteği uygulayabilir.

Burada kritik ayrım erişimdir. Bulutta çalışan bir agent, yerel ağınızdaki servise kendiliğinden ulaşamaz. Yerel makinede veya ilgili ağ içinde çalışan bir agent, uygun kimlik bilgileri ve izinler sağlandığında bunu yapabilir. Modelin ne bildiği kadar, agent’ın nerede çalıştığı ve neye yetkili olduğu da sonucu belirler.

API dokümanından skill’e

API dokümanı çağrının teknik biçimini açıklar. Skill ise bu API’yi kullanırken uyulacak operasyon politikasını tanımlar:

• Önce hangi doküman okunacak?
• Hangi ortam varsayılan kabul edilecek?
• Hangi işlemler yalnızca okunabilir olacak?
• Hangi değişiklik kullanıcı onayı gerektirecek?
• Sonuç nasıl doğrulanacak ve raporlanacak?
• Hata durumunda yeniden deneme mi, durma mı tercih edilecek?

Kullanıcı yönetimi uygulaması için hazırlanan bir skill, agent’a önce güncel API dokümanını bulmasını, uygun isteği üretmesini, değişikliğin etkisini kontrol etmesini ve sonucu bildirmesini söyleyebilir. Böylece genel amaçlı bir sohbet modeli, sınırları belirli bir uygulamayı işletebilen basit bir operatöre dönüşür.

Benim kullandığım temel akış şu:

flowchart LR
    I["İhtiyaç"] --> S["İlgili skill"]
    S --> D["Güncel dokümantasyon"]
    D --> P["Plan ve komut"]
    P --> R["Bağımsız kontrol"]
    R -->|Onay| E["Uygulama"]
    R -->|Revizyon| P
    E --> V["Doğrulama ve rapor"]

Skill komut ezberletmez; doğru kaynağı nasıl bulacağını, hangi sınırlar içinde hareket edeceğini ve ne zaman duracağını tarif eder.

İkinci ve üçüncü göz

Agent kod yazarken hata yapabildiği gibi API çağrısında da hata yapabilir. Geliştirme ortamındaki küçük bir hata zaman kaybettirir; production ortamındaki yanlış çağrı ise doğrudan veri ve hizmet kaybına dönüşebilir.

Bu yüzden skill içinde bağımsız kontrol adımları tanımlıyorum. İlk agent ihtiyacı yorumlayıp komutu hazırlar. Ayrı bağlamdaki ikinci agent, hem ihtiyacı hem de önerilen işlemi inceler. Onay vermezse işlem uygulanmaz; bulgular ilk akışa dönerek planın revize edilmesini sağlar.

Aynı modelin ikinci kez bakması yararlı olsa da ortak model hatasına karşı tam bağımsızlık sağlamaz. Risk yükseldiğinde farklı bir model veya sağlayıcı üzerinden çapraz kontrol uygulanabilir. Codex ile hazırlanmış bir değişikliği Claude ya da Gemini ile gözden geçirmek gibi görünen yöntem, sürecin içine yazıldığında kişisel bir alışkanlık olmaktan çıkar ve tekrarlanabilir kontrol mekanizmasına dönüşür.

Bu yine de matematiksel bir doğruluk garantisi değildir. İki model aynı yanlış varsayıma dayanabilir. Bu nedenle geri döndürülemez işlemlerde insan onayı, en az yetki, yedekleme, dry-run, işlem öncesi ve sonrası doğrulama gibi klasik kontroller devam etmelidir.

Bir takımı simüle etmek

Junior, senior, lead, architect ve tester gibi roller ekiplerde boşuna ortaya çıkmadı. Her biri probleme farklı bir açıdan bakar ve farklı sorumluluk taşır. Benzer ayrımı agent iş akışına verdiğimde tek bir uzun prompt yerine rolü ve bağlamı sınırlandırılmış çalışmalar elde ediyorum.

Örneğin architect çözüm sınırlarını belirleyebilir, developer değişikliği uygulayabilir, reviewer risk ve tutarlılığı inceleyebilir, tester ise kabul ölçütlerini doğrulayabilir. Bu rollerin her biri ayrı bir insan olduğu için değil, aynı işin farklı sorularla incelenmesini sağladığı için değerlidir.

İş yalnızca sohbet bağlamında tutulduğunda geçmiş hızla kaybolur. Süreci issue yönetim sistemine taşıdığımda ise roller issue’yu ilerletir, yorum bırakır, çıktıları kaydeder ve işi sonraki role devreder. Böylece sanal ekip, yaşayan bir iş kaydı üzerinde çalışır.

Yerel bir AI platformunun gerçek bileşenleri

Bu yapıyı kurarken kullanılabilecek açık kaynak veya self-hosted bileşenler mevcut. Fakat aşağıdaki tablo, “bir model indirdim” ile “operasyon yapabilen bir platform kurdum” arasındaki mesafeyi de gösteriyor:

Liste bir kurulum reçetesi değil. Kimlik yönetimi, secret saklama, sandbox, loglama, değerlendirme, yedekleme ve ağ politikaları gibi üretim sorumlulukları ayrıca çözülmek zorunda. GPU’lu bir cluster’ınız varsa bunları deneyebilirsiniz; eski kripto madencilerinin donanımı burada yeniden anlam kazanabilir. Yine de donanım kiralamak başka, güvenilir ve izole bir model hizmeti işletmek başka iştir.

Araçları kurmak bu sistemin en görünür, fakat çoğu zaman en kolay kısmıdır. Asıl çalışma; kurumun süreçlerini analiz etmek, karar ve yetki sınırlarını çıkarmak, doğru bağlamı doğru anda sağlamak, güvenlik kapılarını tasarlamak ve bütün parçaları mevcut platformlarla güvenilir biçimde birleştirmektir. Aynı araç listesi iki farklı kurumda tamamen farklı bir operasyon modeline dönüşebilir.

Ben bu yapıyı nasıl uyguladım?

Kendi yönettiğim ve AI kullanımı için yetkilendirilmiş kapsamdaki Kubernetes cluster’larını, Azure servislerini, geliştirme işlerini, teknik dokümantasyonu, sosyal medya süreçlerini ve bu blogun yönetimini aşama aşama AI’a taşıdım. Bugün bilgisayar başında olmasam bile telefonumdan verdiğim talep yetkilendirilmiş çalışma ortamım üzerinden yürütülebiliyor. Biraz Iron Man’deki Jarvis benzetmesini çağrıştırıyor; fakat arkasında sihir değil, standart, erişim ve dokümantasyon var.

Her iş için aynı sırayı izliyorum:

1. İşi tekrarlanabilir bir standarda dönüştürüyorum.
2. Karar noktalarını ve yasak alanları yazıyorum.
3. Gerekli dokümantasyonu hazırlıyorum.
4. Skill’in doğru dokümanı seçmesini sağlıyorum.
5. Risk seviyesine göre review ve onay kapıları ekliyorum.
6. İşlem sonrasında sonucu bağımsız olarak doğrulatıyorum.

Doküman hazırlamak bazen kod yazmak kadar zaman alıyor. Fark şu: Eskiden hem kodu hem dokümanı üretirken artık bazı işlerde yalnızca iyi tanımı ve dokümanı bir kez hazırlıyorum. Tekrarlanan kodlama veya operasyon adımlarını agent aynı kaynağa dayanarak yürütebiliyor.

Dokümanda tahmine açık boşluk bırakmamak çok önemli. Bir fotoğrafımın izinsiz biçimde makaleye eklenmesini, özel mesajın yanlış kişiye gönderilmesini veya production veritabanına eski bir yedeğin dönülmesini istemem. Bu sınırlar yalnızca “dikkatli ol” cümlesiyle değil; hedef doğrulama, açık yasaklar, onay koşulları ve geri alma planıyla tanımlanmalı.

Token duvarı ve optimizasyon

İlk kurduğum sistem çalışıyordu; fakat ekonomik değildi. Kullandığım yaklaşık 100 avroluk paketin haftalık limiti yetmemeye başladı. E-posta yönetimi, cluster ve Azure operasyonları, kod geliştirme, issue takibi ve çoklu review akışları aynı bütçeden token tüketiyordu. Uzun süre ek paket almak zorunda kaldım.

Asıl katma değerim bu noktadan sonra ortaya çıktı: Her göreve bütün bağlamı göndermek yerine yalnızca gerekli bağlamı seçmek.

İlk skill dosyalarımdan biri 100 bin kelimeyi aşmıştı. Bugün kendi kullanım senaryomda benzer kapsamı yaklaşık 5 bin kelimelik çekirdek talimat ve ihtiyaç anında okunan dokümanlarla yönetiyorum. Bu oran her işte aynı sonucu verecek genel bir tasarruf vaadi değil; doğru bağlam seçiminin etkisini gösteren kişisel bir örnek. Yaptığım şey yalnızca metni kısaltmak değil, bağlam mimarisini değiştirmekti.

• Ortak kuralları tek yerde tutuyorum.
• Göreve özel dokümanı ihtiyaç anında yüklüyorum.
• Agent’a bütün geçmişi değil ilgili issue ve dosyaları veriyorum.
• Çıktı biçimini ve uzunluğunu sınırlıyorum.
• Tekrarlanan açıklamalar yerine araçlardan yapılandırılmış sonuç alıyorum.
• Basit işlerde pahalı model ve çoklu review kullanmıyorum.

Bugün izin verilen kapsam içindeki teknik review, kod geliştirme, issue yönetimi, cluster ve platform operasyonlarıyla kişisel işlerimin büyük bölümü aynı paket içinde rahatça yürüyebiliyor. Kazanç yalnızca daha az token değil; modelin gereksiz bağlam içinde kaybolmaması sayesinde daha tutarlı sonuç.

Burada herkese uygulanabilecek tek bir optimizasyon reçetesi yok. İş türü, kullanılan araçlar, veri hassasiyeti, hata maliyeti ve beklenen çıktı birlikte analiz edilmeden bir kurum için doğru model, bağlam ve kontrol düzeni belirlenemez. Verimli bir yapı, hazır bir skill’i kopyalamaktan çok o işletmenin gerçek çalışma biçimini doğru okuyup ona özel bir sistem tasarlamayı gerektirir.

İşveren, veri ve yetki sınırı

İş yerinizle ilgili süreçleri AI ile yürütüyorsanız teknik olarak yapabiliyor olmanız yeterli değildir. İşverenin politikası, müşteri sözleşmeleri, veri sınıflandırması, düzenleyici şartlar ve kullanılan sağlayıcının koşulları birlikte değerlendirilmelidir.

Savunma sanayii, sağlık, finans veya başka bir regüle alanda genel amaçlı SaaS hizmetine veri göndermek kabul edilemez olabilir. Böyle bir durumda kurum içi model, özel bulut, veri maskeleme veya yalnızca onaylanmış araçların kullanılması gerekebilir. Doğru çözüm sektöre, veriye ve tehdit modeline göre değişir.

Bu yüzden işe gizlice AI eklemek yerine güvenlik, hukuk, yönetim ve teknik ekiplerle açık bir model üzerinde anlaşmak gerekir. Agent’a verilen yetki de insan kullanıcının yetkisinden daha geniş olmamalıdır.

Bana ne kazandırdı?

En görünür sonuç daha fazla iş üretmek değil, zamanımı geri kazanmak oldu. Sosyalleşmeye daha fazla vakit ayırabiliyorum. Oğlumla neredeyse her gün denize gidebiliyor, akşamları rahatça film izleyebiliyor ve baba-oğul zamanını daha verimli yaşayabiliyorum.

Eskiden bir etkinliğin ortasında zihnim hâlâ “bu teknik problemi nasıl çözerim?” sorusuyla meşgul olabiliyordu. Şimdi problemi kayıt altına alıp araştırma, alternatif üretme ve ilk uygulama adımlarını sisteme bırakabiliyorum. Ben yeniden karar noktasında sürece katılıyorum.

Bu, daha az sorumluluk anlamına gelmiyor. Operasyonları devrettim; sahipliği değil.

Bağımlılık ve yetkinlik kaybı

AI ile yürütülen işlerde güçlü bir bağımlılık oluşuyor. Servise erişemediğinizde süreç durabilir. Daha önemlisi, uzun süre elinizi işin içinden çekerseniz kullandığınız teknolojiyi anlama ve sorun çözme kasınız zayıflayabilir.

Junior geliştirici temel becerileri hiç kazanamayabilir; senior geliştirici ise kullanmadığı ayrıntıları zamanla unutabilir. Agent’ı yönetmek, sistemi anlamanın yerini aldığında mühendislik rolü kolayca yalnızca müşteri olmaya dönüşür. Bu riski Yapay Zekâ ve İnsan Zihni: Düşünmenin Erozyonu, Kodun Çürümesi ve Kontrolün Kaybı yazısında daha ayrıntılı ele almıştım.

Bu nedenle zaman zaman işi elle yapmak, üretilen komutu okuyabilmek, mimari kararı açıklayabilmek ve sistem arızalandığında AI olmadan müdahale edebilmek gerekiyor. Otomasyon, bilgi kaybı pahasına kazanılan hız olmamalı.

Sonuç: Kararlar bende, uygulama AI’da

Geldiğim noktada AI benim için bir sohbet botu veya sınırsız yetkili sanal çalışan değil. Dokümanla beslenen, skill’lerle sınırlandırılan, gerektiğinde başka agent ve modeller tarafından kontrol edilen bir operasyon katmanı.

Başarılı delegasyon, AI’ın daha fazla karar vermesi değil; benim verdiğim kararları daha az tekrar, daha tutarlı kayıt ve daha düşük operasyon yüküyle uygulaması oldu. Böyle bir sistemin kurulması model seçiminden önce süreçlerin analiz edilmesini, kuruma özel yetki ve kontrol mekanizmalarının tasarlanmasını gerektiriyor. Teknoloji parçaları hazır olsa bile onları güvenilir bir çalışma modeline dönüştüren kısım bu tasarım emeği.

Son review hâlâ bende. Çünkü AI benim adıma işlem yapsa da yanlışlığın hesabını verecek olan model değil, benim.

We often say that microservices should be independent. Yet an order may require a payment, a payment belongs to a customer, and shipping depends on inventory. Absolute independence is neither realistic nor useful. The goal is to understand dependency boundaries and control their effects.

What is a dependency?

A component depends on another component when it needs that component’s availability, behavior, or data to perform its responsibility.

An order service may depend on:

• a payment service to collect money,
• an inventory service to check availability,
• a customer service to obtain a delivery address,
• a message broker to publish events,
• or a particular database schema to process data.

A dependency is not limited to one service making an HTTP request to another. Shared databases, common libraries, API and event contracts, deployment procedures, and recurring coordination between teams can all create dependencies.

A dependency is not the same as a necessity

Business needs and technical design decisions should be separated. Requiring payment before confirming an order may be a business necessity. Making the order service call the payment service synchronously is a technical design decision.

The distinction becomes clearer when the same example is classified:

We may not be able to remove a business or regulatory requirement. However, implementing it with a particular protocol, shared transaction, or shared database is usually an architectural choice. We can change that choice, reduce its impact, and design for failure.

When does a relationship become a dependency?

If the answer to any of the following questions is yes, there is a dependency worth managing:

• Does my component stop working when the other component is unavailable?
• Does a change in the other component require a change in my code?
• Must the two components be released at the same time?
• Does my service need to know the other service’s internal data model?
• Do both services write to the same database tables?
• Does one service’s performance problem directly affect the other?
• Does one team repeatedly have to wait for another team to deliver a feature?

These questions show that dependencies exist beyond source code. Runtime, data, contract, deployment, and organizational dependencies create different kinds of risk.

Runtime dependency

Service A waits for an immediate response from service B before completing an operation. If no fallback, cache, or deferred path has been defined, A cannot complete that flow while B is unavailable. As the call chain grows, latency and the probability of failure grow with it.

Data dependency

One service needs data managed by another. That need is normal, but direct access to the same tables turns every schema change into a shared release problem.

Contract dependency

Services communicate through APIs, events, or message formats. An uncontrolled contract change can break consumers. Asynchronous communication does not remove this dependency; it changes its form.

Deployment dependency

If releasing one service requires several other services to be updated at the same time, the services may be physically separate but are not independently deployable.

Organizational dependency

When one team repeatedly waits for another team’s implementation or approval, a technical relationship has become an organizational bottleneck.

Shared libraries and infrastructure are not automatically harmful. They become a significant dependency when a shared change forces many services to upgrade together or prevents teams from working independently.

Where should the microservice boundary be drawn?

Microservice architecture is not an attempt to remove every relationship between services. Its purpose is to let each service make decisions within its business area without knowing the internal design of other services or inheriting every temporary failure they experience.

A healthy microservice should:

• own a defined business capability,
• manage its own data,
• avoid direct access to another service’s database,
• expose explicit and backward-compatible contracts,
• be independently deployable where practical,
• tolerate temporary failures within defined limits,
• and avoid knowledge of other services’ implementation details.

The acceptable dependency boundary can be evaluated through a service’s ability to change, deploy, and fail independently. If a small change requires many services to be updated together, the system is tightly coupled even if it is distributed across separate processes.

How synchronous and asynchronous communication change dependency

With synchronous communication, the caller waits for the other service. This model is direct and easy to understand, and it can be appropriate for short operations that require an immediate answer. However, latency and failures propagate through the call chain.

With asynchronous communication, a service publishes an event that other services process later. The services no longer need to be available at the same moment, but message ordering, retries, idempotency, observability, and eventual consistency must now be managed.

Asynchronous communication does not eliminate dependency. When the message is reliably accepted and persisted, the order service no longer depends on the payment service being available at that exact moment, but it still depends on the event contract and messaging infrastructure. The dependency is loosened in time; the responsibility remains.

Useful dependency and harmful coupling

Delegating payment processing to a service that owns that business capability can be a useful dependency. Requiring the order service to understand the payment service’s internal tables, classes, or release schedule is harmful coupling.

Well-designed dependencies separate responsibilities, allow teams to specialize in business domains, and let components scale according to their own workload. Uncontrolled dependencies turn small changes into large coordination efforts, make test environments difficult to create, and tie system performance to the slowest component.

The result can be a distributed monolith: a system made of separate services that still have to be developed, tested, and released together. It combines the coupling of a monolith with the network and operational costs of a distributed system.

How should dependencies be managed?

Define boundaries around business capabilities

Design services around business responsibilities rather than technical layers. Generic services used by everyone can gradually become central bottlenecks.

Give every data set an owner

The authoritative owner of the data and its write rules should be explicit. Other services may access it through defined APIs or events and keep controlled local copies when necessary, but they should not take ownership of the source’s write rules.

Evolve contracts compatibly

API and event schemas are contracts between services. Contract tests and deliberate versioning help prevent a provider change from unexpectedly breaking its consumers.

Question long synchronous call chains

When a single user request calls many services in sequence, both latency and failure probability increase. If the user does not need the complete result immediately, part of the work may be handled asynchronously.

Treat failure as a normal design condition

Timeouts, bounded retries, circuit breakers, idempotency, queues, and appropriate fallback responses can contain the impact of a dependency. Unbounded retries deserve particular care because they can send even more traffic to a service that is already struggling.

Prevent cyclic dependencies

If service A depends on B and B also depends on A, revisit the service boundaries or ownership of the workflow. A cycle can be evidence that a separate business capability has not yet been recognized.

Make dependencies visible

Service maps, distributed traces, metrics, and correlated logs should reveal which services depend on one another. A relationship that is missing from the documentation does not disappear in production.

Before introducing a new dependency

The following questions form a useful review checklist before adding a service call, shared library, or event contract:

1. Is this relationship a genuine business requirement or a consequence of the current design?
2. Does the user need the result immediately?
3. What happens when the called service is unavailable?
4. Can the operation continue with cached or slightly stale data?
5. Can the work be completed later?
6. Who owns the contract, and how will it evolve?
7. Can the services still be deployed independently?
8. Does the design require direct access to another service’s database?
9. Is the dependency becoming bidirectional or cyclic?
10. Can we observe the effects of failures, delays, and changes in production?

Conclusion

The goal of microservices is not zero dependency; that would be unrealistic for a system whose parts collaborate. The goal is to make dependencies explicit, bounded, mostly one-way, resilient, and open to change.

One question provides a useful starting point:

Does a change, delay, or failure in one service unnecessarily affect the code, release schedule, or runtime behavior of other services?

If the answer is repeatedly yes, the relationship is more than a natural business dependency: it is tight technical coupling. Good architecture does not hide dependencies or pretend to remove them. It makes them visible, draws deliberate boundaries around them, and prevents their effects from spreading through the system without control.

Mikroservis mimarisinde “servisler birbirinden bağımsız olmalıdır” cümlesini sıkça kullanıyoruz. Fakat siparişin ödemeye, ödemenin müşteriye, sevkiyatın stoğa ihtiyaç duyduğu bir sistemde mutlak bağımsızlık mümkün değildir. Bu nedenle hedef sıfır bağımlılık değil, bağımlılığın sınırlarını bilmek ve etkisini yönetmektir.

Bağımlılık nedir?

Bir bileşen görevini yerine getirebilmek için başka bir bileşenin varlığına, davranışına veya ürettiği veriye ihtiyaç duyuyorsa aralarında bağımlılık vardır.

Örneğin bir sipariş servisi:

• ödeme servisinden tahsilat yapıyorsa,
• stok servisinden ürün miktarını sorguluyorsa,
• kullanıcı servisinden teslimat adresini alıyorsa,
• bir mesaj kuyruğuna veri gönderiyorsa,
• belirli bir veritabanı şemasına göre işlem yapıyorsa

bu bileşenlere farklı biçimlerde bağımlıdır.

Bağımlılık yalnızca bir servisin diğerine HTTP isteği göndermesi değildir. Paylaşılan veritabanları, ortak kütüphaneler, API ve olay sözleşmeleri, dağıtım süreçleri ve ekipler arasındaki sürekli koordinasyon ihtiyacı da bağımlılık oluşturabilir.

Bağımlılık ile zorunluluk aynı şey değildir

İş ihtiyacı ile teknik tasarımı birbirinden ayırmak gerekir. Bir siparişin tamamlanabilmesi için ödeme alınması bir iş zorunluluğu olabilir. Sipariş servisinin ödeme servisine senkron HTTP isteği göndermesi ise bir teknik tasarım kararıdır.

Aradaki farkı aynı örnek üzerinden açalım:

İş veya mevzuat kaynaklı zorunluluğu ortadan kaldıramayabiliriz. Ancak bu zorunluluğun belirli bir protokolle, aynı işlem zincirinde veya ortak bir veritabanıyla uygulanması çoğu zaman mimari tercihtir. Bu tercihin etkisini azaltabilir, yönünü değiştirebilir ve hata durumlarına karşı dayanıklı hâle getirebiliriz.

Bir ilişki nerede bağımlılığa dönüşür?

Aşağıdaki sorulardan birine “evet” cevabı veriliyorsa dikkate alınması gereken bir bağımlılık vardır:

• Diğer bileşen çalışmadığında benim bileşenim de çalışamaz mı?
• Diğer bileşendeki değişiklik benim kodumu değiştirmemi gerektiriyor mu?
• İki bileşeni aynı anda yayımlamak zorunda mıyım?
• Diğer servisin iç veri modelini bilmek zorunda mıyım?
• İki servis aynı veritabanı tablolarını kullanıyor mu?
• Bir servisin performans sorunu diğerini doğrudan etkiliyor mu?
• Bir özelliği geliştirmek için sürekli başka bir ekibi bekliyor muyum?

Bu sorular bağımlılığın yalnızca kod düzeyinde olmadığını gösterir. Çalışma zamanı, veri, sözleşme, dağıtım ve organizasyon bağımlılıkları birbirinden farklı sonuçlar üretir.

Çalışma zamanı bağımlılığı

A servisi bir işlemi tamamlamak için B servisinden anlık cevap bekler. Alternatif bir akış, önbellek veya işlemi erteleme seçeneği tanımlanmamışsa B çalışmadığında A da bu akışı tamamlayamaz. Çağrı zinciri uzadıkça toplam gecikme ve hata olasılığı artar.

Veri bağımlılığı

Bir servis başka bir servisin yönettiği veriye ihtiyaç duyar. Bu ihtiyaç normaldir; ancak iki servisin aynı tablolara doğrudan erişmesi, veri modelindeki her değişikliği ortak bir dağıtım problemine dönüştürür.

Sözleşme bağımlılığı

Servisler API, olay veya mesaj formatları üzerinden anlaşır. Bu sözleşmenin kontrolsüz değiştirilmesi tüketicileri bozabilir. Asenkron iletişim de bu bağımlılığı ortadan kaldırmaz; yalnızca sözleşmenin biçimini değiştirir.

Dağıtım bağımlılığı

Bir servisin yeni sürümünü yayımlamak için diğer servislerin de aynı anda güncellenmesi gerekiyorsa servisler fiziksel olarak ayrılmış olsa bile bağımsız değildir.

Organizasyonel bağımlılık

Bir ekip işini tamamlamak için sürekli başka bir ekibin geliştirme yapmasını veya onay vermesini bekliyorsa teknik ilişki organizasyonel darboğaza dönüşmüştür.

Ortak kütüphaneler ve altyapı bileşenleri tek başına zararlı değildir. Ancak ortak bileşendeki değişiklik birçok servisi aynı anda güncellemeye zorluyor veya ekiplerin bağımsız hareket etmesini engelliyorsa artık ayrıca yönetilmesi gereken bir bağımlılıktır.

Mikroservislerde sınır nerede çizilir?

Mikroservis mimarisinin amacı servisler arasındaki bütün ilişkileri yok etmek değildir. Amaç, her servisin kendi iş alanında karar verebilmesi; başka servislerin iç yapısını bilmemesi ve onların geçici sorunlarından mümkün olduğunca az etkilenmesidir.

Sağlıklı bir mikroservis:

• belirli bir iş yeteneğinin sahibi olmalı,
• kendi verisini yönetmeli,
• başka bir servisin veritabanına doğrudan erişmemeli,
• açık ve geriye uyumlu sözleşmeler sunmalı,
• mümkün olduğunda bağımsız yayımlanabilmeli,
• geçici hataları belirli ölçüde tolere edebilmeli,
• diğer servislerin uygulama ayrıntılarını bilmemelidir.

Bağımlılığın kabul edilebilir sınırını, servisin bağımsız değişebilme, yayımlanabilme ve hata verebilme kabiliyeti üzerinden değerlendirebiliriz. Küçük bir değişiklik birçok servisin aynı anda güncellenmesini gerektiriyorsa sistem dağıtık olmasına rağmen sıkı bağlıdır.

Senkron ve asenkron iletişim bağımlılığı nasıl değiştirir?

Senkron iletişimde çağrıyı yapan servis karşı tarafın cevabını bekler. Yöntem basit ve anlaşılırdır; kullanıcıya anlık cevap verilmesi gereken kısa işlemler için uygun olabilir. Buna karşılık gecikme ve hata doğrudan çağrı zincirine yayılır.

Asenkron iletişimde servis bir olay yayımlar ve diğer servisler bunu daha sonra işler. Böylece servislerin aynı anda çalışması gerekmeyebilir. Bunun karşılığında mesaj sıralaması, tekrar işleme, idempotency, izlenebilirlik ve gecikmeli tutarlılık yönetilmelidir.

Asenkron iletişim bağımlılığı yok etmez. Mesajın güvenilir biçimde kabul edilip kalıcılaştırıldığı bir yapıda sipariş servisi, ödeme servisinin o anda erişilebilir olmasına bağımlı değildir; fakat olay sözleşmesine ve mesajlaşma altyapısına bağımlıdır. Yani bağımlılık zaman bakımından gevşer, sorumluluk ortadan kalkmaz.

Faydalı bağımlılık ile zararlı bağlılık

Sipariş servisinin ödeme işlemini bu alanda uzmanlaşmış bir ödeme servisine bırakması doğal ve faydalı olabilir. Zararlı olan, sipariş servisinin ödeme servisinin iç tablolarını, sınıflarını veya dağıtım takvimini bilmek zorunda kalmasıdır.

Doğru kurulan bağımlılıklar sorumlulukların ayrılmasını, ekiplerin iş alanlarında uzmanlaşmasını ve bileşenlerin kendi yüklerine göre ölçeklenmesini sağlar. Kontrolsüz bağımlılıklar ise küçük değişiklikleri büyük koordinasyonlara dönüştürür, test ortamlarını zorlaştırır ve sistem performansını en yavaş bileşene bağlar.

Sonuçta mikroservislerden oluşan fakat birlikte geliştirilip birlikte yayımlanmak zorunda olan bir dağıtık monolit ortaya çıkar. Böyle bir sistem, monolitin sıkı bağlılık problemleriyle dağıtık sistemlerin ağ ve operasyon maliyetlerini aynı anda taşır.

Bağımlılıklar nasıl yönetilebilir?

Servis sınırlarını iş yeteneklerine göre belirleyin

Servisleri yalnızca teknik katmanlara göre bölmek yerine iş sorumluluklarına göre tasarlayın. Herkesin kullandığı genel amaçlı servisler zamanla merkezi darboğazlara dönüşebilir.

Her verinin bir sahibi olsun

Bir verinin otoritatif sahibi ve yazma kurallarından sorumlu servis açıkça belirlenmelidir. Diğer servisler bu veriye tanımlı API’ler veya olaylar üzerinden erişebilir, gerektiğinde kontrollü yerel kopyalarını tutabilir; ancak asıl kaynağın yazma kurallarını sahiplenmemelidir.

Sözleşmeleri geriye uyumlu geliştirin

API ve olay şemaları servisler arasındaki sözleşmelerdir. Sözleşme testleri ve bilinçli sürümleme, bir sağlayıcıdaki değişikliğin tüketicileri beklenmedik biçimde bozmasını engeller.

Uzun senkron çağrı zincirlerini sorgulayın

Tek bir kullanıcı isteğinin tamamlanması için çok sayıda servisin sırayla çağrılması hem gecikmeyi hem hata olasılığını artırır. Kullanıcının sonucu gerçekten aynı anda görmesi gerekmiyorsa işin bir bölümü asenkron yürütülebilir.

Hataları tasarımın doğal parçası kabul edin

Timeout, sınırlı retry, circuit breaker, idempotency, kuyruklama ve uygun durumlarda alternatif cevap üretme gibi yöntemler bağımlılığın etkisini sınırlar. Özellikle kontrolsüz retry, zaten zorlanan bir servise daha fazla yük göndererek sorunu büyütebilir.

Döngüsel bağımlılıkları engelleyin

A servisi B’ye, B de A’ya bağımlıysa sorumluluk sınırları veya iş akışının sahipliği yeniden değerlendirilmelidir. Döngü bazen yeni bir iş alanının henüz açıkça tanımlanmadığını gösterir.

Bağımlılıkları görünür kılın

Servis haritaları, dağıtık izleme, metrikler ve ilişkilendirilmiş loglar hangi servisin hangisine bağımlı olduğunu göstermelidir. Dokümantasyonda görünmeyen bir ilişki, üretimde ortadan kaybolmaz.

Yeni bir bağımlılık oluşturmadan önce

Bir servis çağrısı, ortak kütüphane veya olay sözleşmesi eklemeden önce şu sorular yararlı bir kontrol listesi oluşturur:

1. Bu ilişki gerçek bir iş zorunluluğu mu, yoksa mevcut tasarımın sonucu mu?
2. Kullanıcı işlemin sonucunu anında almak zorunda mı?
3. Çağrılan servis çalışmadığında ne olacak?
4. Eski veya önbelleğe alınmış veriyle devam edilebilir mi?
5. İşlem daha sonra tamamlanabilir mi?
6. Sözleşmenin sahibi kim ve nasıl değiştirilecek?
7. Servisler birbirinden bağımsız yayımlanabilecek mi?
8. Bu ilişki başka bir servisin veritabanına erişmeyi gerektiriyor mu?
9. Bağımlılık iki yönlü veya döngüsel hâle geliyor mu?
10. Hata, gecikme ve değişiklik etkisini üretimde görebilecek miyiz?

Sonuç

Mikroservislerde hedef sıfır bağımlılık değildir; birlikte çalışan bir sistem için bu gerçekçi değildir. Hedef, bağımlılıkları açık, sınırlı, mümkün olduğunca tek yönlü ve değiştirilebilir hâle getirmektir.

Bir ilişkinin sağlıklı olup olmadığını anlamak için şu soruyla başlayabiliriz:

Bir serviste yapılan değişiklik, gecikme veya hata diğer servislerin kodunu, dağıtım zamanını ya da çalışma durumunu gereksiz yere etkiliyor mu?

Cevap sürekli olarak “evet” ise ortada yalnızca doğal bir iş ilişkisi değil, sıkı bir teknik bağlılık vardır. İyi bir mimari bağımlılıkları gizlemez veya tamamen yok etmeye çalışmaz; onları görünür kılar, sınırlarını bilinçli biçimde çizer ve etkilerinin sistem boyunca kontrolsüz yayılmasını engeller.

What Is a Flow?

Imagine that we are building a project whose purpose is to move data from System A to System B:

flowchart LR
    A["System A"] --> B["System B"]

At this stage, we are dealing mainly with a data integration or data pipeline problem. Tools such as Logstash, Azure Data Factory, and Apache NiFi can read data from different sources and move it to target systems. Nothing here requires us to build a custom flow engine.

In real projects, however, data is rarely moved without any intermediate work. Its format may need to be transformed, required fields must be validated, and invalid records have to be separated:

flowchart LR
    A["Read data"] --> T["Transform"]
    T --> V["Validate"]
    V --> D{"Valid?"}
    D -->|Yes| B["Send to target"]
    D -->|No| E["Separate invalid records"]

We are no longer describing only where the data comes from and where it goes. We are also defining the steps it passes through and the conditions that control its route. A flow is a structure that describes the steps of a process, the transitions between those steps, and the paths to follow for different outcomes.

When Do We Need a Flow?

Not every sequence of operations needs a separate flow infrastructure. If the steps are few, stable, and changed only by developers, the process can remain in ordinary application code:

Read → Validate → Transform → Save

This is still a flow, but its definition is embedded in the codebase. Adding a step or changing the order requires a code change, testing, and another deployment. In this article, I will refer to this as a static flow.

A flow begins to emerge as a separate concern when the number of steps grows, conditional paths appear, failed work must be retried, or operators need to see the current stage of a process. The number of steps alone is not the deciding factor. A three-step process that waits two days for human approval may need stronger flow management than a short operation containing twenty consecutive method calls.

The need becomes clearer when we want to manage process state and failure paths independently of a single application call. Common signs include the following:

• The process lasts longer than a single HTTP request or application process
• It waits for an external event, timer, or human decision
• It must continue from the failed step instead of starting again
• Operators need to see the current step of each instance
• The same process follows different paths for different customers or conditions

None of these signs alone requires a custom engine. They help us distinguish between a flow that can stay in code, one that fits an existing execution tool, and one whose behavior has become a product concern.

What Is a Flow Engine?

A flow engine is the execution layer that decides which step of a defined flow should run and when. It reads the flow definition and determines the starting step, the next transition, and the completion condition. Depending on the requirements, it may also manage retries, timeouts, waits, parallel work, and execution state.

flowchart LR
    D["Flow definition"] --> E["Flow engine"]
    E --> A["Step A"]
    A --> B["Step B"]
    B --> C["Step C"]

When we need to run many flows, recover after failure, or track long-running processes, collecting these responsibilities in an execution layer can be easier to reason about than distributing them throughout the application code.

What Do Ready-Made Flow Tools Do?

Once a flow need appears, several options become available: code-based solutions, existing engines, managed services, and custom development. Mature tools already exist for different kinds of problems, but they do not all solve the same type of flow.

NiFi combines routing, transformation, queuing, back pressure, and data provenance for dataflows. I covered this model in more detail in Data Flow Automation with Apache NiFi.

Airflow represents work as tasks and dependencies in a DAG. Features such as schedules and backfills make it particularly useful for data pipelines. Step Functions uses state machines to run AWS services, Lambda functions, and external work within ordered and conditional application workflows.

These tools do more than connect boxes. They provide capabilities such as scheduling, retry handling, state tracking, execution history, and operational views, all of which are expensive to build and maintain. The question from Should I Write Everything Myself? On Using External Tools Properly also applies here: does this infrastructure problem belong to our product, or has another team already spent years solving it?

Where Do Ready-Made Tools Start to Struggle?

Let us extend the example. The flow no longer transforms data and sends it directly to a destination:

flowchart LR
    A["Receive data"] --> C["Customer-specific operation"]
    C --> P["Persist"]
    P --> N["Send notification"]
    N --> H["Wait for human approval"]
    H --> B["Continue to next step"]

As nodes begin to contain product-specific behavior, the distance between our product model and the tool’s native model grows. NiFi, for example, includes processors that can run scripts, and compiled custom extensions can also be developed. However, placing core business rules in many scripts or tool-specific extensions can make testing, dependency management, CI/CD, and versioning harder than they are in a normal application codebase.

Airflow tasks can also execute custom code. Its main model, however, is closer to running workflows defined by developers than to serving as a general-purpose low-code product where end users add and remove nodes at runtime. If each new feature requires another adapter, plugin, or workaround, the tool may begin shaping the product model instead of reducing the problem.

There is also a reason why many flow tools use their own queue and state structures instead of, or alongside, Kafka and RabbitMQ. A message broker transports messages. A flow engine must additionally know which step is expected, which step has completed, how many retries have occurred, when a timeout expires, which flow version is running, and what the execution history contains. A broker does not provide all of this information by itself.

When Does a Custom Flow Engine Become Relevant?

Now imagine that users can add or remove nodes through configuration or a visual designer:

Add node → Change connection → Define rule → Publish flow

The flow is no longer a fixed pipeline written in advance by a developer. It becomes product data interpreted at runtime. A combination of the following requirements can provide a strong reason to evaluate a custom engine:

• Users create their own flows
• Nodes perform product-specific operations
• Flow definitions can change at runtime
• Tenants have different nodes, permissions, and limits
• Flow definitions require independent versioning
• Running executions must complete on the version with which they started
• The existing tool’s model must be bypassed for every new capability

A custom user experience does not necessarily require a custom runtime. We can build our own designer and flow definition while using Step Functions or another engine behind it. A custom engine becomes a real option when both the flow language and its execution behavior become core product capabilities.

That is the requirement examined in this article: running a dynamic flow in which nodes can be added or removed and connections can be changed through configuration.

Core Concepts of a Dynamic Flow

Before discussing execution models, we need to separate a few concepts:

A simplified definition may look like this:

{
  "flowId": "customer-registration",
  "version": 3,
  "startAt": "validate",
  "nodes": {
    "validate": {
      "type": "function",
      "next": "persist"
    },
    "persist": {
      "type": "function",
      "next": "notify"
    },
    "notify": {
      "type": "function",
      "end": true
    }
  }
}

A published flow definition should be treated as immutable. When a user changes it, the platform creates a new version instead of editing the existing one. Running instances can then continue with the version on which they started, while new instances use the latest version.

Flow v1 → Instance A, Instance B
Flow v2 → Instance C
Flow v3 → New instances

What Guarantees Should Flow Execution Provide?

Before choosing a message bus or database, we need to describe the engine’s behavior:

• Can the same step run more than once?
• What happens when a message is lost or redelivered?
• Is ordering required across the whole system or only within one flow instance?
• What happens if an external call succeeds but the process stops before state is saved?
• Is the context carried in the message, or does the message contain only a reference?
• What happens if a retried step produces the same side effect again?

Choosing a broker does not answer these questions automatically. Kafka, for example, maintains record order within a partition, not across an entire topic. Using flowInstanceId as the partition key can place related events in the same partition, but parallel consumer work, retries, and external-service latency can still change the order in which operations complete.

With RabbitMQ, a single queue and a single consumer can provide strong ordering, but this limits throughput. Once multiple consumers, redelivery, and requeue behavior enter the system, delivery order and completion order can diverge.

Ordering and delivery guarantees therefore tend to be designed together with mechanisms such as:

• Sequence numbers scoped to a flow instance
• Expected-step validation
• Idempotency keys
• Optimistic concurrency
• Duplicate-event detection
• Outbox and inbox patterns

Approach 1: Central Orchestrator

In the first model, a central orchestrator makes all transition decisions:

sequenceDiagram
    participant O as Orchestrator
    participant A as Step A Worker
    participant B as Step B Worker
    participant S as Execution Store

    O->>A: Run Step A
    A-->>O: Step A completed
    O->>S: Update state
    O->>B: Run Step B
    B-->>O: Step B completed
    O->>S: Complete flow

The orchestrator reads the flow definition, identifies the current step, sends work to the relevant worker, receives the result, updates state, and schedules the next step. Retry, timeout, notification, and authorization rules can be applied here as shared policies.

The main benefit is that the full flow remains visible through one execution model. Versioning, waits, parallel joins, and operational views can be handled in a controlled way. The trade-off is that every transition passes through the same logical component, so the orchestrator’s performance and availability become important.

A central orchestrator does not have to be a single process or pod. If execution state is stored in a shared durable store, the orchestrator can remain stateless and run as several replicas on Kubernetes. If one replica stops, another can continue scheduling. Centralization here means that transition decisions share one authority, not that only one physical instance exists.

Approach 2: Choreography-Based Distributed Flow

In the second model, a central component does not control every transition. A step publishes an event when it finishes, and the next step runs by listening for that event:

flowchart LR
    S["FlowStarted"] --> A["Step A"]
    A --> EA["StepACompleted"]
    EA --> B["Step B"]
    B --> EB["StepBCompleted"]
    EB --> C["Step C"]
    C --> F["FlowCompleted"]

Operational functions such as audit, metrics, and notifications can listen to the same events independently:

flowchart LR
    E["StepCompleted"] --> N["Next step"]
    E --> A["Audit function"]
    E --> M["Metric function"]
    E --> T["Notification function"]

This model allows steps to scale independently and new listeners to be added without changing the main flow. If one worker stops, other flows on the platform can continue running. The affected flow instance, however, cannot progress until the message is redelivered or the worker becomes available again.

As the central execution load decreases, coordination responsibilities become distributed. Selecting the next step, updating context, detecting duplicate events, handling retries, joining parallel branches, and respecting the flow version all become more difficult. Correlation, tracing, and replay are no longer optional operational features; they become part of the execution model. I explored the operational side of this problem in Why Is Debugging Not Enough in Event-Driven Architecture?.

Where Should Execution State Be Stored?

Carrying the entire flow context only inside Kafka or RabbitMQ messages may look attractive, but it creates problems around large payloads, sensitive data, queries, and historical access. The message can carry identity and transition information while the main state remains in a durable store:

{
  "flowInstanceId": "flow-123",
  "stepId": "validate",
  "executionId": "exec-456",
  "sequence": 4
}

The execution store can keep information such as:

FlowInstance
- id
- definitionId
- definitionVersion
- currentStep
- status
- contextReference
- sequence
- createdAt
- updatedAt

A relational database can provide transactions and queryability, Redis can provide fast temporary state and locking, Kafka can serve as a replayable event log, and RabbitMQ can deliver tasks. Large payloads can remain in object storage while the flow context carries references. A real system does not have to force one of these tools to perform every role.

A Hybrid Implementation Option

Central orchestration and distributed step execution can also be used together. In this model, a central component interprets the flow definition and version, while independent workers or services perform the actual work:

flowchart TB
    D["Flow definition"] --> O["Stateless orchestrator"]
    O --> B["Message bus"]
    B --> F1["Step worker A"]
    B --> F2["Step worker B"]
    B --> F3["Step worker C"]
    O <--> S["Execution store"]
    F1 --> E["Flow events"]
    F2 --> E
    F3 --> E
    E --> A["Audit / metric / notification"]

Flow decisions are centralized while work execution remains distributed. The orchestrator can scale as a stateless component, workers can grow independently according to their load profiles, and operational tasks can consume flow events. In return, the coordination cost of the central model and the messaging and observability costs of the distributed model must be managed in the same system.

This model is not free either. Once we build a custom engine, the team becomes responsible for retries, timeouts, idempotency, versioning, migrations, security, tenant isolation, and operational tooling. The long-term cost of these responsibilities must be considered alongside the cost of forcing an existing tool beyond its natural model.

Conclusion

Keeping a flow in code, executing it with an existing tool, or turning it into a custom engine are different responses to the same problem at different levels of scale and variability. The relevant factors are not limited to the number of nodes. They also include how dynamic the process is, how state is preserved, who changes the flow, and how important execution behavior is to the product itself.

With a custom model, every node does not have to use the same technology. As long as it follows a shared execution contract, a node can be a FaaS function, a service running in a container, an external SaaS integration, or a traditional application. The engine then depends on the node’s input, output, identity, and execution result rather than its programming language or deployment model. In cloud-native environments, this makes it possible to combine work with different sizes and load profiles in the same flow.

Each option carries a different cost. A ready-made tool may constrain the product model, while a custom engine leaves state, ordering, retries, idempotency, versioning, and operations with the product team. The purpose is therefore not to prescribe one correct approach, but to make visible the point at which changing requirements begin to call for a different execution model.

Further Reading

• Apache NiFi — Overview
• Apache Airflow — DAG concepts
• What is AWS Step Functions?
• Apache Kafka — Design: ordering and partitioning

Flow Nedir?

Bir proje geliştirdiğimizi ve amacımızın A sistemindeki veriyi B sistemine taşımak olduğunu düşünelim:

flowchart LR
    A["Sistem A"] --> B["Sistem B"]

Bu haliyle karşımızda daha çok bir veri entegrasyonu veya data pipeline problemi vardır. Logstash, Azure Data Factory ve Apache NiFi gibi araçlar farklı kaynaklardan veri okuyup hedef sistemlere taşıyabilir. Henüz özel bir flow engine geliştirmemizi gerektiren bir durum yoktur.

Gerçek projelerde veri çoğunlukla doğrudan taşınmaz. Önce formatı dönüştürülür, zorunlu alanları doğrulanır ve hatalı kayıtlar ayrılır:

flowchart LR
    A["Veriyi oku"] --> T["Dönüştür"]
    T --> V["Doğrula"]
    V --> D{"Geçerli mi?"}
    D -->|Evet| B["Hedefe gönder"]
    D -->|Hayır| E["Hatalı kayıtları ayır"]

Artık yalnızca verinin nereden nereye gittiğini değil, hangi adımlardan ve hangi koşullardan geçeceğini de tarif ediyoruz. Flow, bir işin adımlarını, bu adımlar arasındaki geçişleri ve farklı sonuçlarda izlenecek yolları tanımlayan yapıdır.

Flow’a Ne Zaman İhtiyaç Duyulur?

Her sıralı işlem ayrı bir flow altyapısı gerektirmez. Adımlar az, sabit ve yalnızca geliştiriciler tarafından değiştiriliyorsa süreç normal uygulama kodu içinde yönetilebilir:

Oku → Doğrula → Dönüştür → Kaydet

Bu da bir flow’dur; ancak tanımı kod tabanının içindedir. Adım eklemek veya sırasını değiştirmek için kodu güncellemek, test etmek ve yeniden yayımlamak gerekir. Bu yazıda bunu statik flow olarak adlandıracağım.

Adımlar arttığında, koşullu yollar oluştuğunda, hata alan bir işin yeniden denenmesi veya sürecin hangi aşamada olduğunun izlenmesi gerektiğinde flow ayrı bir kavram haline gelmeye başlar. Buradaki ölçüt yalnızca adım sayısı değildir. Üç adımdan oluşan fakat iki gün insan onayı bekleyen bir süreç, yirmi metodun arka arkaya çağrıldığı kısa bir işlemden daha güçlü bir flow yönetimine ihtiyaç duyabilir.

Flow’a asıl ihtiyaç, sürecin ilerleme durumunu ve hata yollarını uygulama çağrısından bağımsız olarak yönetmek istediğimizde ortaya çıkar. Aşağıdaki belirtiler bu ihtiyacı görünür hale getirir:

• Süreç tek bir HTTP isteğinin veya uygulama prosesinin yaşam süresini aşıyorsa
• Bir dış olay, zamanlayıcı veya insan kararı bekleniyorsa
• Hata sonrasında sürecin baştan değil kaldığı adımdan devam etmesi gerekiyorsa
• Operasyon ekibinin her instance’ın hangi adımda olduğunu görmesi isteniyorsa
• Aynı sürecin farklı müşteriler veya koşullar için farklı yollar izlemesi gerekiyorsa

Bu ihtiyaçların hiçbiri tek başına özel bir engine geliştirmeyi zorunlu kılmaz. Önce flow’un kod içinde kalıp kalamayacağına, ardından hazır bir yürütme aracının süreci karşılayıp karşılamadığına bakılır.

Flow Engine Nedir?

Flow engine, tanımlanan akışın hangi adımının ne zaman çalışacağını yöneten yürütme katmanıdır. Flow tanımını okur; başlangıç adımını, sıradaki geçişi ve tamamlanma koşulunu belirler. İhtiyaca göre retry, timeout, bekleme, paralel çalışma ve execution state gibi davranışları da yönetir.

flowchart LR
    D["Flow tanımı"] --> E["Flow engine"]
    E --> A["Step A"]
    A --> B["Step B"]
    B --> C["Step C"]

Birden fazla flow çalıştırmak, hatadan sonra kaldığı yerden devam etmek veya uzun süre bekleyen süreçleri takip etmek istiyorsak bu sorumlulukları uygulama kodu boyunca dağıtmak yerine bir yürütme katmanında toplamak anlamlı hale gelir.

Hazır Flow Araçları Ne Yapar?

Flow ihtiyacı ortaya çıktığında önümüzde kod tabanlı çözümler, hazır engine’ler ve özel geliştirme gibi farklı seçenekler bulunur. Farklı problem türleri için yıllardır kullanılan olgun araçlar vardır; ancak hepsi aynı tür akışı çözmez.

NiFi; routing, transformation, kuyruklama, back-pressure ve data provenance gibi veri akışı ihtiyaçlarını birlikte sunar. Bu yönünü Apache NiFi ile Veri Akışı Otomasyonu yazısında daha ayrıntılı incelemiştim.

Airflow’da işler bir DAG içindeki task ve bağımlılıklar olarak tanımlanır. Schedule ve backfill gibi yetenekleri nedeniyle özellikle veri pipeline’larında güçlüdür. Step Functions ise state machine yaklaşımıyla AWS servislerini, Lambda fonksiyonlarını ve harici işleri belirli bir sıra ve karar yapısı içinde çalıştırır.

Bu araçlar yalnızca kutuları birbirine bağlamaz. Scheduling, retry, state takibi, execution history ve operasyon ekranı gibi geliştirmesi ve işletmesi pahalı yetenekleri de sağlar. Bu nedenle daha önce Harici Araçlardan Doğru Şekilde Faydalanma yazısında ele aldığım soru burada da geçerlidir: Bu problem gerçekten bizim ürünümüze mi ait, yoksa yıllardır başka ekiplerin çözdüğü bir altyapı problemi mi?

Hazır Araçlar Nerede Zorlanmaya Başlar?

Örneğimizi biraz daha büyütelim. Flow artık yalnızca veriyi dönüştürüp hedef sisteme göndermiyor:

flowchart LR
    A["Veriyi al"] --> C["Müşteriye özel işlem"]
    C --> P["Kaydet"]
    P --> N["Bildirim gönder"]
    N --> H["İnsan onayı bekle"]
    H --> B["Sonraki adıma geç"]

Node’ların içine ürüne özgü davranışlar girmeye başladığında hazır aracın doğal çalışma modeliyle aramızdaki mesafe artar. Örneğin NiFi içinde script çalıştıran processor’lar vardır. Gerektiğinde derlenmiş özel extension’lar da geliştirilebilir. Ancak temel iş kurallarını çok sayıda script veya araca özel extension içine yerleştirmek; test, bağımlılık yönetimi, CI/CD ve versiyonlama süreçlerini normal bir uygulama kod tabanına göre zorlaştırabilir.

Airflow task’ları içinde de özel kod çalıştırabiliriz. Fakat Airflow’un ana çalışma modeli, son kullanıcıların runtime sırasında node ekleyip çıkardığı genel amaçlı bir low-code ürün olmaktan çok, geliştiriciler tarafından tanımlanan workflow’ların yürütülmesine yakındır. Hazır bir aracı kullanmak için sürekli adapter, plugin ve workaround geliştiriyorsak araç artık problemi azaltmak yerine ürün modelimizi şekillendiriyor olabilir.

Birçok flow aracının Kafka veya RabbitMQ yerine ya da bunların yanında kendi queue ve state yapılarını kullanmasının da bir nedeni vardır. Bir message broker mesajı taşır; fakat bir flow engine ayrıca hangi adımın beklendiğini, hangisinin tamamlandığını, retry sayısını, timeout’u, flow versiyonunu ve execution geçmişini bilmek zorundadır. Broker bu bilgilerin tamamını tek başına sağlamaz.

Özel Flow Engine Ne Zaman Gündeme Gelir?

Kullanıcıların bir konfigürasyon veya görsel tasarım ekranı üzerinden node ekleyip çıkarabildiğini düşünelim:

Node ekle → Bağlantıyı değiştir → Kural tanımla → Flow'u yayımla

Bu noktada flow, geliştiricinin önceden kodladığı sabit bir pipeline olmaktan çıkar ve ürünün çalışma anında yorumladığı bir veriye dönüşür. Aşağıdaki ihtiyaçların birkaçının birlikte bulunması özel bir flow engine için güçlü bir gerekçe oluşturur:

• Kullanıcılar kendi flow’larını oluşturuyorsa
• Node’lar ürüne özgü işler gerçekleştiriyorsa
• Akış tanımı runtime sırasında değişebiliyorsa
• Tenant’a göre farklı node, yetki ve limitler bulunuyorsa
• Flow tanımı bağımsız olarak versiyonlanacaksa
• Devam eden execution’ların başladıkları versiyonla tamamlanması gerekiyorsa
• Hazır aracın modeli her yeni özellikte aşılmaya çalışılıyorsa

Özel bir kullanıcı deneyimine ihtiyaç duymak, mutlaka özel bir runtime geliştirmeyi gerektirmez. Kendi flow tanımımızı ve designer’ımızı oluşturup arka tarafta Step Functions veya başka bir engine kullanabiliriz. Ancak hem flow dili hem de yürütme davranışı ürünün temel yeteneğine dönüşmüşse custom engine gerçek bir seçenek haline gelir.

Bu yazıdaki ihtiyacımız da budur: Node’ların eklenebildiği, çıkarılabildiği ve bağlantıların konfigürasyon üzerinden değiştirilebildiği dinamik bir flow çalıştırmak.

Dinamik Flow’un Temel Kavramları

Execution modelini seçmeden önce birkaç kavramı ayırmamız gerekir:

Basitleştirilmiş bir tanım şöyle olabilir:

{
  "flowId": "customer-registration",
  "version": 3,
  "startAt": "validate",
  "nodes": {
    "validate": {
      "type": "function",
      "next": "persist"
    },
    "persist": {
      "type": "function",
      "next": "notify"
    },
    "notify": {
      "type": "function",
      "end": true
    }
  }
}

Yayımlanmış flow tanımı değişmez kabul edilmelidir. Kullanıcı değişiklik yaptığında mevcut tanımı güncellemek yerine yeni bir versiyon üretilir. Böylece çalışan instance’lar başladıkları sürümle devam ederken yeni instance’lar son sürümü kullanabilir.

Flow v1 → Instance A, Instance B
Flow v2 → Instance C
Flow v3 → Yeni instance'lar

Flow Execution Hangi Garantileri Vermeli?

Message bus veya veritabanı seçmeden önce engine’in davranışını tanımlamalıyız:

• Aynı step birden fazla kez çalışabilir mi?
• Mesaj kaybolduğunda veya yeniden teslim edildiğinde ne olacak?
• Sıralama bütün sistemde mi, yalnızca aynı flow instance içinde mi gerekli?
• Başarılı bir dış çağrıdan sonra state kaydedilemeden proses kapanırsa ne yapılacak?
• Context mesajla mı taşınacak, yoksa yalnızca bir referans mı gönderilecek?
• Retry edilen bir step yan etkiyi ikinci kez üretirse sonuç ne olacak?

Bir broker seçmek bu soruların kendiliğinden cevaplanmasını sağlamaz. Örneğin Kafka kayıt sırasını topic genelinde değil partition içinde korur. Aynı flowInstanceId değerini partition key olarak kullanmak ilgili event’lerin aynı partition’a gitmesini sağlayabilir; fakat paralel consumer işlemleri, retry veya dış servis gecikmeleri sonuçların aynı sırada tamamlanacağını garanti etmez.

RabbitMQ’da tek queue ve tek consumer güçlü bir sıra oluşturabilir, ancak throughput’u sınırlar. Birden fazla consumer, redelivery ve requeue devreye girdiğinde teslim sırası ile işlemlerin tamamlanma sırası birbirinden ayrılabilir.

Bu nedenle ordering ve teslimat garantileri genellikle şu mekanizmalarla birlikte tasarlanır:

• Flow instance bazlı sequence number
• Beklenen step kontrolü
• Idempotency key
• Optimistic concurrency
• Duplicate event kontrolü
• Outbox ve inbox pattern’leri

Yaklaşım 1: Merkezi Orchestrator

İlk yaklaşımda bütün geçiş kararlarını merkezi bir orchestrator verir:

sequenceDiagram
    participant O as Orchestrator
    participant A as Step A Worker
    participant B as Step B Worker
    participant S as Execution Store

    O->>A: Step A'yı çalıştır
    A-->>O: Step A tamamlandı
    O->>S: State'i güncelle
    O->>B: Step B'yi çalıştır
    B-->>O: Step B tamamlandı
    O->>S: Flow'u tamamla

Orchestrator flow tanımını okur, mevcut step’i belirler, işi ilgili worker’a gönderir, sonucu alır ve state’i güncelledikten sonra sıradaki step’i planlar. Retry, timeout, bildirim ve yetki kontrolleri ortak politikalar olarak burada uygulanabilir.

Bu yaklaşımın güçlü tarafı, flow’un tamamını tek bir execution modeli üzerinden görebilmemizdir. Versiyonlama, bekleme, paralel kolların birleşmesi ve operasyon ekranları daha kontrollü tasarlanabilir. Buna karşılık bütün geçişler aynı mantıksal bileşenden geçtiği için orchestrator’ın performansı ve erişilebilirliği önem kazanır.

Merkezi orchestrator, tek bir proses veya tek bir pod olmak zorunda değildir. Execution state ortak ve kalıcı bir store’da tutulursa orchestrator stateless tasarlanıp Kubernetes üzerinde birden fazla replica ile çalıştırılabilir. Bir replica kapandığında diğerleri planlamaya devam edebilir. Buradaki merkezilik fiziksel olarak tek instance bulunması değil, geçiş kararlarının aynı otorite tarafından verilmesidir.

Yaklaşım 2: Choreography Tabanlı Dağıtık Akış

İkinci yaklaşımda merkezi bir bileşen her geçişi yönetmez. Bir step işini tamamladığında event yayımlar; sıradaki step bu event’i dinleyerek çalışır:

flowchart LR
    S["FlowStarted"] --> A["Step A"]
    A --> EA["StepACompleted"]
    EA --> B["Step B"]
    B --> EB["StepBCompleted"]
    EB --> C["Step C"]
    C --> F["FlowCompleted"]

Audit, metric ve notification gibi operasyonel fonksiyonlar da aynı event’leri bağımsız olarak dinleyebilir:

flowchart LR
    E["StepCompleted"] --> N["Next step"]
    E --> A["Audit function"]
    E --> M["Metric function"]
    E --> T["Notification function"]

Bu model step’lerin bağımsız ölçeklenmesine ve yeni dinleyicilerin ana flow değiştirilmeden eklenmesine izin verir. Bir worker’ın kapanması platformdaki diğer flow’ların çalışmasını durdurmaz. Ancak ilgili flow instance, mesaj yeniden teslim edilene veya worker yeniden erişilebilir olana kadar ilerleyemez.

Merkezi execution yükü azalırken koordinasyon sorumluluğu dağıtılır. Sıradaki step’in belirlenmesi, context’in güncellenmesi, duplicate event’ler, retry, paralel join ve flow versiyonu daha zor hale gelir. Akışın tamamını görebilmek için correlation, tracing ve replay artık yardımcı özellik değil temel ihtiyaçtır. Bu problemin operasyon tarafını Event-Driven Mimaride Debug Neden Yetmez? yazısında ele almıştım.

Execution State Nerede Tutulmalı?

Flow context’inin tamamını yalnızca Kafka veya RabbitMQ mesajlarında taşımak cazip görünür; fakat büyük payload, hassas veri, sorgulama ve geçmişe erişim gibi sorunlar ortaya çıkar. Mesaj çoğu zaman kimlik ve geçiş bilgisini taşırken asıl state kalıcı bir store’da tutulabilir:

{
  "flowInstanceId": "flow-123",
  "stepId": "validate",
  "executionId": "exec-456",
  "sequence": 4
}

Execution store ise aşağıdaki türde bilgileri saklar:

FlowInstance
- id
- definitionId
- definitionVersion
- currentStep
- status
- contextReference
- sequence
- createdAt
- updatedAt

İlişkisel veritabanı transaction ve sorgulanabilirlik, Redis hızlı geçici state ve lock, Kafka replay edilebilir event log, RabbitMQ ise task delivery için kullanılabilir. Büyük payload’lar object storage üzerinde tutulup flow context içinde yalnızca referansları taşınabilir. Gerçek bir sistemde bu araçlardan biri diğerlerinin bütün görevlerini üstlenmek zorunda değildir.

Hibrit Bir Uygulama Seçeneği

Merkezi orchestration ile dağıtık step execution birlikte de kullanılabilir. Bu modelde flow tanımı ve versiyonu merkezi bir bileşen tarafından yorumlanırken gerçek işler bağımsız worker veya servislere bırakılır:

flowchart TB
    D["Flow definition"] --> O["Stateless orchestrator"]
    O --> B["Message bus"]
    B --> F1["Step worker A"]
    B --> F2["Step worker B"]
    B --> F3["Step worker C"]
    O <--> S["Execution store"]
    F1 --> E["Flow events"]
    F2 --> E
    F3 --> E
    E --> A["Audit / metric / notification"]

Bu hibrit modelde flow kararları merkezi, işin yürütülmesi dağıtıktır. Orchestrator stateless ölçeklenebilir; worker’lar kendi yük profillerine göre bağımsız büyüyebilir; audit ve notification gibi operasyonel işler event’leri dinleyebilir. Bunun karşılığında merkezi modelin koordinasyon yükü ile dağıtık modelin mesajlaşma ve gözlemlenebilirlik maliyeti aynı sistemde birlikte yönetilir.

Yine de bu model bedelsiz değildir. Özel engine geliştirdiğimiz anda retry, timeout, idempotency, versiyonlama, migration, security, tenant izolasyonu ve operasyon ekranlarının sahibi de oluruz. Hazır aracı zorlamanın maliyeti ile bu sorumlulukların uzun vadeli maliyeti birlikte değerlendirilmelidir.

Sonuç

Flow’un kod içinde kalması, hazır bir araçla yürütülmesi veya özel bir engine’e dönüştürülmesi aynı problemin farklı ölçek ve değişkenlik seviyelerindeki karşılıklarıdır. Seçimi belirleyen yalnızca node sayısı değil; sürecin ne kadar dinamik olduğu, state’in nasıl korunacağı, flow’u kimin değiştireceği ve execution davranışının ürünün ne kadar önemli bir parçası olduğudur.

Özel bir model kullanıldığında node’ların tamamı aynı teknolojiyle geliştirilmek zorunda değildir. Ortak execution sözleşmesine uyduğu sürece bir node FaaS fonksiyonu, container içinde çalışan servis, harici bir SaaS entegrasyonu veya klasik bir uygulama olabilir. Böylece flow engine, node’un programlama diline veya dağıtım biçimine değil; girdisine, çıktısına, kimliğine ve çalışma sonucuna bağlı kalır. Bu esneklik özellikle cloud-native ortamlarda farklı boyut ve yük profiline sahip işleri aynı flow içinde bir araya getirmeyi mümkün kılar.

Bu seçeneklerin her biri farklı bir maliyet taşır. Hazır araç ürün modelini sınırlandırabilir; özel engine ise state, ordering, retry, idempotency, versiyonlama ve operasyon sorumluluklarını ekibe bırakır. Bu nedenle amaç tek bir doğru yaklaşım önermek değil, ihtiyaçların hangi noktada farklı bir execution modeline dönüştüğünü görünür hale getirmektir.

Daha Fazla Okuma

• Apache NiFi — Overview
• Apache Airflow — DAG kavramları
• AWS Step Functions nedir?
• Apache Kafka — Design: ordering ve partition yaklaşımı

The goal of this article is not to turn every command into a tutorial. It is to build a useful mental model: what Kubernetes runs, what Helm packages, what Kustomize customizes, and how GitOps changes the way the resulting configuration reaches a cluster.

Start with the Core Problem: What Does Kubernetes Do?

Kubernetes is an orchestration platform for running and managing containerized applications. We can describe how many copies of an application should run, how it should be reached, which configuration it should use, and how it should recover when a process fails.

We usually express this desired state through YAML manifests:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: orders-api
  template:
    metadata:
      labels:
        app: orders-api
    spec:
      containers:
        - name: orders-api
          image: registry.example.com/orders-api:1.4.0
          ports:
            - containerPort: 8080

This file tells Kubernetes to run two Pods from the orders-api:1.4.0 image and expose port 8080 inside the container.

Kubernetes runs the workload and continuously tries to preserve that declared state. It does not, by itself, decide how our team should package a group of manifests, remove duplication between environments, review a production change, or synchronize a Git repository with a cluster. Those responsibilities belong to other layers.

What Happens as the Number of Manifests Grows?

A real application rarely consists of one Deployment. Over time, it may also need:

• Services
• ConfigMaps
• Secret references
• Ingress or Gateway resources
• HorizontalPodAutoscalers
• ServiceAccounts and RBAC rules
• NetworkPolicies
• environment-specific replicas and resource limits

Development, test, and production then introduce small but important differences. Development may need one replica while production needs four. Domains, image tags, resource limits, and integrations can also vary.

Copying every YAML file into an environment directory works at first, but each copy becomes another configuration that can drift. Helm and Kustomize approach this management problem from different directions.

What Is Helm?

Helm is commonly described as a package manager for Kubernetes. It turns the Kubernetes resources needed by an application into a reusable and versioned package called a Chart.

A small Chart usually looks like this:

orders-api/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    └── ingress.yaml

• Chart.yaml contains package metadata such as its name and version.
• values.yaml defines configurable defaults.
• templates/ contains Kubernetes manifest templates that consume those values.

The replica count and container image, for example, can be placed in values.yaml:

replicaCount: 2

image:
  repository: registry.example.com/orders-api
  tag: "1.4.0"

The Deployment template refers to them:

spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: orders-api
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

The same Chart can now be installed with a different values file for each environment:

helm upgrade --install orders-api ./orders-api \
  --values values-prod.yaml

Helm is particularly useful when:

• the same application must be installed for several customers or clusters,
• the package needs an independent version and distribution lifecycle,
• users need to configure many supported options,
• an existing product such as PostgreSQL, Prometheus, or cert-manager is distributed as a Chart,
• Charts will be shared through a repository or OCI registry.

There is a cost to this flexibility. As conditions and parameters accumulate, a Chart can become harder to understand than the manifests it generates. Kubernetes YAML gradually turns into a program written in a template language. Making every field configurable is therefore not a sign of good Chart design.

What Is Kustomize?

Kustomize customizes Kubernetes YAML without requiring placeholders or a template language. Its typical model keeps shared resources in a base and applies environment-specific changes through overlays.

k8s/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

The base contains the common definition. A production overlay describes only what differs:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

images:
  - name: registry.example.com/orders-api
    newTag: 1.4.0

replicas:
  - name: orders-api
    count: 4

We can inspect the generated manifests with:

kubectl kustomize k8s/overlays/prod

And apply them with:

kubectl apply -k k8s/overlays/prod

Kustomize is a good fit when:

• environments have a small set of explicit differences,
• we want the source to remain recognizable as ordinary Kubernetes YAML,
• dev, test, and production derive from one shared base,
• patch-based customization is enough,
• using the Kustomize support built into kubectl is useful.

Kustomize is not a package manager. It does not provide a Chart repository, Chart dependencies, or the same release abstraction that Helm provides. Its primary job is composing and customizing resources.

Helm or Kustomize?

The question often assumes that one tool must replace the other. Their strongest use cases, however, are not identical.

A practical rule is:

• Use Helm when the output is a reusable, distributable application package.
• Use Kustomize when you own the manifests and mainly need a small number of environment variations.
• Combine them when a packaged application still needs controlled, site-specific adjustments.

The right choice depends less on tool popularity than on the kind of variability we need to manage.

What Is GitOps?

Helm and Kustomize produce or customize manifests. GitOps is an operating model for managing the desired state represented by those manifests.

In a GitOps workflow, a Git repository is the source of truth for the system’s intended configuration. Instead of connecting to production and running a command directly, a developer or platform engineer proposes a Git change. The change can be reviewed and approved before a controller applies it to the cluster.

flowchart LR
    D["Developer"] -->|Pull Request| G["Git repository"]
    G -->|Desired state| C["Argo CD or Flux"]
    C -->|Synchronization| K["Kubernetes cluster"]
    K -. "Live state" .-> C

Git is no longer just storage for YAML files. It becomes the versioned record of the desired operational state.

What Do Argo CD and Flux Do?

Argo CD and Flux are widely used controllers for implementing GitOps on Kubernetes. They observe a source, generate or read the desired manifests, compare them with the live cluster, and report the difference. Depending on policy, they can also correct that difference automatically.

If Git declares four replicas but someone manually changes the live Deployment to two, the controller detects the drift. With automated synchronization or self-healing enabled, it can restore the Git-defined state.

This continuous comparison and correction is a reconciliation loop. It is more important than the presence of a Git repository alone; storing manifests in Git but deploying them through untracked manual commands does not give us the same operating model.

GitOps can provide:

• Pull Request review for operational changes,
• an audit trail of who changed what and when,
• detection of manual configuration drift,
• reproducible environment definitions,
• rollback by restoring a known Git revision,
• reduced need to distribute cluster credentials to developer machines or CI jobs.

It does not make an unsafe configuration safe. A bad manifest merged into Git can still be delivered very efficiently. Secret management, tests, approvals, access control, rollout health, and recovery policies remain separate design concerns.

How Is GitOps Different from CI/CD?

In a traditional CI/CD pipeline, the pipeline builds the application, pushes a container image, and often deploys directly to Kubernetes. The pipeline therefore needs credentials that allow it to change the cluster.

A GitOps design can separate these responsibilities:

1. CI tests the source code.
2. CI builds the container image and pushes it to a registry.
3. The image tag in the deployment repository is updated.
4. Argo CD or Flux detects the new desired state.
5. The controller reconciles the cluster with that state.

CI still exists, but it no longer has to perform the deployment itself. It produces an artifact and records the requested version in Git; a controller operating near or inside the cluster pulls and applies the change. This is why GitOps is often described as a pull-based delivery model.

How Do These Layers Work Together?

We can position the tools in one flow:

flowchart LR
    H["Helm: packaging"] --> M["Kubernetes manifests"]
    Z["Kustomize: environment adaptation"] --> M
    M --> G["Git: desired state"]
    G --> A["Argo CD / Flux: reconciliation"]
    A --> K["Kubernetes: live state"]

A project might use that model as follows:

1. Application source code lives in its own Git repository.
2. CI tests the code and publishes orders-api:1.4.0.
3. The application is packaged as a Helm Chart.
4. Environment-specific values or Kustomize overlays live in a deployment repository.
5. A Pull Request updates the production image tag to 1.4.0.
6. Argo CD detects the change and synchronizes the cluster.
7. The team observes rollout health through Argo CD and its monitoring stack.

This is an example, not a mandatory repository layout. A small team may not benefit from separating application and deployment repositories. A larger or regulated organization may need that boundary for access control, approval, and auditability.

Does Every Project Need All of Them?

No. Adding tools is not the same as increasing maturity.

A small application may be well served by a few clear YAML files and kubectl apply. Kustomize becomes useful when environment differences appear. Helm becomes valuable when the application needs to be packaged and reused. GitOps starts to pay for itself as the number of applications, environments, teams, and audit requirements grows.

This table is not a universal prescription. Team experience, security requirements, operational load, and the ownership model can change the decision.

Common Mistakes

Several mistakes appear repeatedly across these tools:

• copying all YAML files for every environment,
• turning every Helm field into a parameter,
• using Kustomize overlays that replace so much of the base that the base has little meaning,
• adopting GitOps while keeping routine manual cluster changes,
• deploying mutable tags such as latest,
• storing unencrypted secret values in Git,
• applying generated manifests without rendering and validating them first,
• losing the traceable link between a Git change and the running image,
• enabling automatic synchronization before defining health checks and recovery behavior.

Regardless of the tools, the generated configuration should remain understandable, each change should be traceable, and a running version should be reproducible.

Conclusion

Kubernetes, Helm, Kustomize, and GitOps are not competing answers to one question. They operate at different layers of the delivery process.

Kubernetes runs the application. Helm packages its resources. Kustomize adapts manifests to an environment. Git records the intended state. Argo CD or Flux continuously reconciles that state with the cluster.

We do not need to introduce every layer on day one. We first need to identify where the current complexity lives: packaging, environment variation, review and audit, or the gap between Git and the live cluster. The useful tool is the one that reduces that specific complexity without creating a larger operational burden elsewhere.

Further Reading

• Kubernetes — Declarative Management with Kustomize
• Helm — Introduction to Helm
• Argo CD — Declarative GitOps CD for Kubernetes
• Argo CD — Automation from CI Pipelines
• Rendering and Managing Helm Charts Locally
• Versioning and Release Management on Kubernetes

Bu yazının amacı bütün komutları ezberletmek değil, büyük resmi kurmaktır: Kubernetes neyi çalıştırır, Helm neyi paketler, Kustomize neyi özelleştirir ve GitOps bu süreci nasıl yönetir?

Önce temel problem: Kubernetes ne yapar?

Kubernetes, container olarak paketlenmiş uygulamaları çalıştıran ve yöneten bir orkestrasyon platformudur. Bir uygulamanın kaç kopya çalışacağını, hangi porttan erişileceğini, hangi konfigürasyonu kullanacağını ve hata durumunda nasıl yeniden başlatılacağını tanımlayabiliriz.

Bu istekleri Kubernetes’e genellikle YAML manifestleriyle bildiririz.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: orders-api
  template:
    metadata:
      labels:
        app: orders-api
    spec:
      containers:
        - name: orders-api
          image: registry.example.com/orders-api:1.4.0
          ports:
            - containerPort: 8080

Bu dosya Kubernetes’e kabaca şunu söyler: orders-api:1.4.0 imajından iki pod çalıştır ve container’ın 8080 portunu kullan.

Kubernetes burada uygulamayı çalıştırır ve tanımlanan durumu korumaya çalışır. Fakat manifestleri farklı ortamlar için nasıl yöneteceğimiz, tekrarları nasıl azaltacağımız veya değişiklikleri kümeye kimin uygulayacağı Kubernetes’in tek başına çözdüğü sorunlar değildir.

Manifest sayısı arttığında ne olur?

Gerçek bir uygulama çoğunlukla yalnızca bir Deployment dosyasından oluşmaz. Zamanla aşağıdaki kaynaklar eklenir:

• Service
• ConfigMap
• Secret referansları
• Ingress veya Gateway
• HorizontalPodAutoscaler
• ServiceAccount ve RBAC kuralları
• NetworkPolicy
• ortam bazlı kaynak limitleri ve replica sayıları

Bir de geliştirme, test ve production ortamları varsa aynı dosyaların küçük farklarla kopyalandığı bir yapı oluşabilir. Örneğin geliştirme ortamında tek replica yeterliyken production ortamında dört replica gerekebilir. Kullanılan domain, image tag’i ve kaynak limitleri de değişebilir.

Helm ve Kustomize bu yönetim probleminin farklı taraflarına yaklaşır.

Helm nedir?

Helm, Kubernetes için paket yöneticisi olarak tanımlanır. Bir uygulamaya ait Kubernetes kaynaklarını yeniden kullanılabilir ve versiyonlanabilir bir paket hâline getirir. Bu pakete Chart denir.

Bir Helm Chart genel olarak şu yapıya sahiptir:

orders-api/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    └── ingress.yaml

• Chart.yaml, paketin adı ve versiyonu gibi bilgileri tutar.
• values.yaml, değiştirilebilir varsayılan değerleri içerir.
• templates/, bu değerleri kullanan Kubernetes manifest şablonlarını barındırır.

Örneğin replica sayısı values.yaml içinde tanımlanabilir:

replicaCount: 2

image:
  repository: registry.example.com/orders-api
  tag: "1.4.0"

Deployment şablonu ise bu değerleri kullanır:

spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: orders-api
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Bu sayede aynı Chart farklı değer dosyalarıyla farklı ortamlara kurulabilir.

helm upgrade --install orders-api ./orders-api \
  --values values-prod.yaml

Helm özellikle şu durumlarda güçlüdür:

• Aynı uygulama farklı müşterilere veya kümelere kurulacaksa
• Paket versiyonlamak ve dağıtmak gerekiyorsa
• Çok sayıda ayarın kullanıcı tarafından değiştirilebilmesi isteniyorsa
• PostgreSQL, Prometheus veya cert-manager gibi hazır çözümler kurulacaksa
• Uygulama bir OCI registry üzerinden Chart olarak paylaşılacaksa

Ancak şablon sayısı ve koşullar arttıkça Chart’ın okunması zorlaşabilir. Kubernetes YAML dosyaları zamanla bir şablon programlama diline dönüşebilir. Bu nedenle her değişkeni parametre hâline getirmek iyi bir tasarım değildir.

Kustomize nedir?

Kustomize, mevcut Kubernetes YAML dosyalarını şablon diline dönüştürmeden özelleştirmeyi sağlar. Temel yaklaşımı, ortak kaynakları bir base altında tutmak ve ortama özel değişiklikleri overlay olarak uygulamaktır.

k8s/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

Base, bütün ortamların ortak tanımını içerir. Production overlay’i ise yalnızca farkı belirtir:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

images:
  - name: registry.example.com/orders-api
    newTag: 1.4.0

replicas:
  - name: orders-api
    count: 4

Ortaya çıkacak manifesti görmek için:

kubectl kustomize k8s/overlays/prod

Uygulamak için:

kubectl apply -k k8s/overlays/prod

Kustomize özellikle şu durumlarda uygundur:

• Ortamlar arasında az ve belirgin farklar varsa
• Kubernetes manifestlerinin sade YAML olarak kalması isteniyorsa
• Ortak bir base üzerinden dev, test ve prod varyasyonları üretilecekse
• Yeni bir şablon dili kullanmadan patch tabanlı değişiklik yapılacaksa
• kubectl ile yerleşik gelen bir çözüm tercih ediliyorsa

Kustomize bir paket yöneticisi değildir. Chart bağımlılıkları, Chart repository’si veya release geçmişi gibi Helm özelliklerini sağlamaz. Onun temel işi mevcut manifestleri düzenlemek ve birleştirmektir.

Helm mi, Kustomize mı?

Bu soru çoğu zaman iki araçtan yalnızca biri seçilmek zorundaymış gibi sorulur. Oysa araçların güçlü olduğu alanlar farklıdır.

Basit bir karar kuralı şöyle kurulabilir:

• Yeniden kullanılabilir ve dağıtılabilir bir uygulama paketi üretiyorsak Helm güçlü bir adaydır.
• Kendi uygulamamızın birkaç ortamdaki küçük farklarını yönetiyorsak Kustomize daha sade kalabilir.
• İhtiyaç varsa Helm ile üretilen kaynakların üzerine Kustomize değişiklikleri de uygulanabilir.

Önemli olan aracı alışkanlıkla değil, değişkenliğin türüne göre seçmektir.

GitOps nedir?

Helm ve Kustomize manifest üretme veya özelleştirme araçlarıdır. GitOps ise sistemin nasıl yönetileceğine ilişkin bir çalışma modelidir.

GitOps yaklaşımında Git deposu, sistemin olması gereken durumunu tutar. Bir geliştirici veya operasyon ekibi doğrudan production kümesine bağlanıp komut çalıştırmak yerine Git üzerinde değişiklik yapar. Değişiklik incelenir, onaylanır ve bir GitOps controller tarafından kümeye uygulanır.

Basitleştirilmiş akış şöyledir:

flowchart LR
    D["Geliştirici"] -->|Pull Request| G["Git deposu"]
    G -->|İstenen durum| C["Argo CD veya Flux"]
    C -->|Senkronizasyon| K["Kubernetes kümesi"]
    K -. "Mevcut durum" .-> C

Burada Git yalnızca dosyaların saklandığı yer değildir; istenen durumun kayıt altına alındığı kaynak hâline gelir.

Argo CD ve Flux ne yapar?

Argo CD ve Flux, GitOps yaklaşımını Kubernetes üzerinde uygulayan yaygın araçlardır. Git deposundaki manifestleri izler, bunları kümedeki mevcut durumla karşılaştırır ve aradaki farkı görünür hâle getirir. Yapılandırmaya bağlı olarak farkları otomatik olarak da giderebilirler.

Örneğin Git’te replica sayısı dört olarak tanımlanmışken kümede elle ikiye düşürülürse controller bu sapmayı tespit eder. Otomatik senkronizasyon açıksa sistemi tekrar Git’teki duruma getirebilir.

Bu çalışma şekline reconciliation, yani uzlaştırma döngüsü denir.

GitOps’un sağlayabileceği başlıca avantajlar şunlardır:

• Değişikliklerin Pull Request üzerinden incelenmesi
• Kimin, neyi, ne zaman değiştirdiğinin izlenebilmesi
• Kümedeki manuel ve kayıt dışı değişikliklerin tespit edilmesi
• Önceki Git revizyonuna dönerek geri alma sürecinin sadeleşmesi
• Ortamların aynı yöntemle tekrar üretilebilmesi
• Deploy yetkisinin geliştirici makineleri veya klasik CI sistemleri yerine sınırlı bir controller’da tutulması

GitOps bütün operasyon problemlerini kendiliğinden çözmez. Hatalı manifest Git’e alındığında hata da kontrollü biçimde dağıtılabilir. Secret yönetimi, testler, onay mekanizmaları, erişim kontrolü ve geri dönüş stratejisi ayrıca tasarlanmalıdır.

CI/CD ile GitOps arasındaki fark nedir?

Klasik bir CI/CD akışında pipeline uygulamayı derler, container imajını üretir ve çoğu zaman doğrudan kümeye deploy eder. Bunun için pipeline’ın Kubernetes erişim bilgilerine sahip olması gerekir.

GitOps modelinde sorumluluk ayrılabilir:

1. CI kodu test eder.
2. CI container imajını üretip registry’ye gönderir.
3. Dağıtım deposundaki image tag’i güncellenir.
4. Argo CD veya Flux değişikliği görür.
5. GitOps controller yeni durumu kümeye uygular.

Yani CI hâlâ vardır; fakat Kubernetes’e doğrudan deploy etmek zorunda değildir. CI bir artifact üretir, CD tarafında ise kümenin içindeki controller Git’ten değişikliği çeker. Bu nedenle GitOps çoğunlukla pull tabanlı deployment modeli olarak anılır.

Bu kavramlar birlikte nasıl çalışır?

Araçları tek cümleyle konumlandırırsak:

flowchart LR
    H["Helm: paketleme"] --> M["Kubernetes manifestleri"]
    Z["Kustomize: ortam uyarlaması"] --> M
    M --> G["Git: istenen durum"]
    G --> A["Argo CD / Flux: uzlaştırma"]
    A --> K["Kubernetes: çalışma durumu"]

Örnek bir projede süreç şu şekilde kurulabilir:

1. Uygulama kaynak kodu kendi Git deposunda tutulur.
2. CI testlerden sonra orders-api:1.4.0 imajını üretir.
3. Uygulamanın kurulumu bir Helm Chart olarak paketlenir.
4. Ortama özel values dosyaları veya Kustomize overlay’leri dağıtım deposunda saklanır.
5. Production image tag’i Pull Request ile 1.4.0 olarak güncellenir.
6. Argo CD değişikliği algılar ve Kubernetes kümesiyle senkronize eder.
7. Dağıtım sağlığı Argo CD ve gözlemlenebilirlik araçları üzerinden takip edilir.

Bu yalnızca örnek bir modeldir. Küçük bir ekip için ayrı kod ve deployment depoları gereksiz olabilir. Büyük veya regüle bir yapıda ise yetki ayrımı, onay süreçleri ve denetlenebilirlik nedeniyle ayrı depolar anlamlı olabilir.

Her projede hepsine ihtiyaç var mı?

Hayır. Araç sayısının artması her zaman olgunluk göstergesi değildir.

Küçük bir uygulama için birkaç sade YAML dosyası ve kubectl apply yeterli olabilir. Ortam farkları oluştuğunda Kustomize eklenebilir. Uygulama tekrar kullanılabilir bir paket hâline geldiğinde Helm tercih edilebilir. Dağıtım sayısı, ekip büyüklüğü ve denetim ihtiyacı arttığında Argo CD veya Flux ile GitOps yaklaşımına geçilebilir.

Kabaca şöyle düşünebiliriz:

Buradaki tablo kesin bir reçete değildir. Ekip deneyimi, güvenlik beklentileri, uygulama sayısı ve operasyon yükü kararı değiştirebilir.

Sık yapılan hatalar

Bu araçlar kullanılırken bazı hatalar tekrar eder:

• Ortam başına bütün YAML dosyalarını kopyalamak
• Helm içindeki her satırı parametre hâline getirmek
• Kustomize overlay’lerinde base yapısını tamamen değiştirecek kadar patch üretmek
• GitOps kullanırken kümeye elle müdahale etmeyi normal operasyon şekli olarak sürdürmek
• latest gibi değişken image tag’leri kullanmak
• Secret değerlerini şifrelemeden Git’e koymak
• Render edilen manifesti deployment öncesinde doğrulamamak
• Git’teki değişiklik ile çalışan container imajı arasında izlenebilir bağ kurmamak
• Otomatik senkronizasyonu geri dönüş ve sağlık kontrolü tasarlamadan açmak

Araçlardan bağımsız temel ilke şudur: üretilecek manifest anlaşılabilir, değişiklik izlenebilir ve çalışan sürüm yeniden üretilebilir olmalıdır.

Sonuç

Kubernetes, Helm, Kustomize ve GitOps aynı problemin rakip çözümleri değildir. Bir dağıtım sürecinin farklı katmanlarında görev alırlar.

Kubernetes uygulamayı çalıştırır. Helm uygulamayı paketler. Kustomize manifestleri belirli bir ortama uyarlar. Git istenen durumu kayıt altına alır. Argo CD veya Flux ise bu durumun Kubernetes kümesinde korunmasını sağlar.

İyi bir başlangıç için bütün araçları aynı anda sisteme eklemek gerekmez. Önce mevcut problemin hangi katmanda olduğunu belirlemek gerekir: paketleme mi, ortam farklılığı mı, değişikliklerin denetlenmesi mi, yoksa kümeyle Git arasındaki tutarlılık mı?

Doğru araç, en popüler olan değil; sistemdeki gerçek karmaşıklığı azaltan araçtır.

Daha Fazla Okuma

• Kubernetes — Kustomize ile bildirimsel nesne yönetimi
• Helm — Introduction to Helm
• Argo CD — Declarative GitOps CD for Kubernetes
• Argo CD — CI pipeline otomasyonu
• Helm Chart’ları Localde Render Etme ve Yönetme
• Kubernetes Üzerinde Versioning ve Releasing Yönetimi