Tek tek sistemler güvenilir bir sürece dönüşür.

Evet. 6 hizmet, sınırları belirlenmiş iş paketleri olarak planlanabilir. Mevcut durumu, ön koşulları ve önce ihtiyaç duyduğunuz sonucu birlikte netleştiririz. Alt sayfalarda ilgili kapsam ve teknik kararlar yer alır.

Uygulamadan önce hedefler, etkilenen sistemler, sizden beklenen katkı, sonuçlar ve kabul kriterleri üzerinde anlaşılır. Açık teknik sorular önce bir envanter çıkarma çalışmasında veya bir pilot uygulamada netleştirilebilir. Ek görevler, efor ve takvime etkileri açısından değerlendirilir.

Dokümantasyon, kullanıcı eğitimi ve sorumluluklar sözleşme kapsamında ele alınır. OTOKO® sürekli görevleri üstlenirse, bunun için hizmet saatleri ve eskalasyon yolları içeren bir işletim kapsamı üzerinde anlaşırız. Ekibiniz sonuçları kendisi veya mevcut iş ortaklarıyla birlikte de sürdürebilir.

Bir arayüz, başarılı bir veri aktarımından daha fazlasıdır. Gönderen ve alan taraf verilere aynı anlamı yüklemeli, hatalarla başa çıkabilmeli ve değişiklikleri kontrollü şekilde devreye alabilmelidir. Mimariyi planlar, bağlantıları hayata geçirir ve eksiksiz iş sürecini test ederiz. Eski uygulamalar ve dosya aktarımları da değerlendirme kapsamındadır. Teknik çözüm, güncellik, yük, güvenlik ve bakım kolaylığına ilişkin gereksinimlerinize göre şekillenir.

İş ortaklarının ve uygulamaların, davranışına güvenebilecekleri arayüzlere ihtiyacı vardır. API sözleşmelerini tasarlarız, gateway üzerinde erişim ve korumayı kurarız, sürümleri, dokümantasyonu ve onayları tüm yaşam döngüsü boyunca organize ederiz.

Adlandırma kuralları, hata biçimleri, sürümlendirme ve güvenlik gereksinimleriyle API ilkesi OpenAPI spesifikasyonu ve her API için sorumlularla arayüz kataloğu Kong, Apigee veya Azure API Management ile ağ geçidi kurulumu, OAuth 2.0 ve OpenID Connect üzerinden kimlik yönetiminize bağlanma Erişim yönetimi, anahtarlar ve kullanım raporlarıyla iş ortağı ve geliştirici portalı Onay süreci, eski sürümlerin kullanımdan kaldırılması ve değişiklik bildirimleriyle yaşam döngüsü

API ilkesi ve arayüz kataloğu Kimlik yönetimine bağlı, çalışmaya hazır API ağ geçidi Her API için belgelendirmeyle geliştirici portalı

Bağlı sistemlerin işlemleriyle başlarız: hangi verilere ihtiyaç duyarlar, hangi durumları değiştirebilirler ve hataları nasıl tespit ederler? REST, GraphQL veya gRPC, kullanım amacına göre seçilir. API tanımı, protokole uygun formatı kullanır; örneğin ilgili HTTP API'leri için OpenAPI. Yük verisinin (payload) yanı sıra sayfalama, zaman sınırları, hata yanıtları ve yeniden deneme davranışı da belirlenir. Örnekler ve test senaryoları, tüketen ekiplerin arayüzü üretime alınmadan önce entegre etmesine yardımcı olur.

Bir gateway erişimleri yönetebilir, istekleri sınırlayabilir ve teknik kuralları uygulayabilir. Belirli bir kullanıcının somut bir siparişi okuyup okuyamayacağına ise ayrıca ilgili serviste karar verilmelidir. Bu sınır boyunca token kontrolünü, servis kimliklerini, kiracı eşlemesini ve kayıt tutmayı biz planlarız. Yazma çağrıları için tekrarlanan isteklerin nasıl ele alınacağı netleştirilir. Eski sürümler, değişikliklerin iş ortağı bağlantılarını beklenmedik şekilde kesmemesi için şeffaf bir kullanımdan kaldırma sürecine tabi tutulur.

Sözleşme testleri taahhüt edilen yapıyı kontrol eder; entegrasyon ve yük testleri davranışı tamamlar. Reddedilen erişimleri, geçersiz girdileri ve zaman aşımlarını başarılı çağrılar kadar test ederiz. Devir şartnameyi, gateway yapılandırmasını ve sorumlulukları kapsar. Başlangıç için tipik tüketicilere, yük varsayımlarına ve bir API'nin mümkün kılması gereken iş süreçlerine ihtiyaç vardır.

Bağımsız geliştirme yardımcı olabilir, ancak çok sayıda dağıtık servis bunu zorlaştırabilir de. Anlamlı iş sınırlarını inceler ve iletişim, veri sorumluluğu, dağıtım ve işletim dahil olmak üzere uygun bir mimariyi hayata geçiririz.

İş birimiyle birlikte Event Storming ve Bounded Context'lerle domain ayrımı Helm, GitOps dağıtımı ve her ekip için ad alanlarıyla Kubernetes üzerinde platform REST, gRPC veya mesajlar üzerinden hizmet iletişimi; şifreleme ve yönlendirme için Service Mesh ile Dağıtık işlemler için Saga deseni ve Outbox ile her hizmet için ayrı veri tutma Kayıt tutma, yapılandırma, gizli bilgiler ve hata toleransı için işletim kuralları

Hizmet ayrımı ve arayüzlerle domain modeli Kod olarak dağıtım zinciriyle platform Her hizmet için kurallarla işletim kılavuzu

İş birimi ve geliştirme ekibiyle birlikte kavramları, kuralları ve değişiklikleri inceleriz. Düzenli olarak birlikte uyarlanması gereken işlevler dikkatsizce ayrılmamalıdır. Modüler bir monolit, dağıtık işletimi devreye almadan net sınırlar oluşturabilir. Mikroservisler bağımsız ekiplerin, yük profillerinin veya dağıtım döngülerinin gerekçelendirilebilir bir fayda sağladığı yerlerde bir seçenek haline gelir. Karar, yalnızca bir eğilime göre bir mimari seçmek yerine, işletim sonuçlarıyla birlikte belgelenir.

Birden fazla servise yayılan bir işlemde ortak bir veritabanı işlemi (transaction) kendiliğinden bulunmaz. Durum geçişlerini, geçici tutarsızlığı ve telafi edici işlemleri biz planlarız. Bir outbox yöntemi, veri değişikliğini ve yayınlanacak olayı tutarlı şekilde birbirine bağlamaya yardımcı olabilir. Yeniden denemeler iş düzeyinde idempotentlik, yani yeniden işlemede tanımlı bir sonuç gerektirir. Zaman sınırları ve bağımlılıklar, yavaş bir servisin tüm zinciri kilitlememesi için sınırlandırılır. İlgili ekiplerin bu kuralları anlayabilmesi ve test edebilmesi gerekir.