Üretim ve lojistik için bulut altyapısı

Saha yerinde kalmak zorunda, geri kalanı buluta çıkabiliyor. Bu sektörde hybrid bir tercih değil, çoğu zaman tek seçenek.

Üretim ve lojistik tarafında altyapı konuşmaları neredeyse her zaman aynı yerde başlıyor: sahadaki sistemler yerinden oynatılamıyor. Üretim hattını ya da depo operasyonunu süren yazılımlar, bağlantının kesilmesine tahammülü olmayan sistemler. Buna karşılık ERP, raporlama ve entegrasyon katmanı buluta çıkabiliyor. Ortaya çıkan mimari hybrid oluyor.

İçindekiler

Altyapıyı zorlayan ne

Birincisi bağlantı kopması senaryosu. Saha ile bulut arasındaki hat koptuğunda üretimin ya da sevkiyatın durmaması gerekiyor. Bu, sahadaki sistemlerin bir süre kendi başına çalışabilmesi ve bağlantı gelince senkronlanması anlamına geliyor. Mimariyi belirleyen asıl kısıt bu.

İkincisi mevcut donanım yatırımı. Bu sektörde sahada üç beş yıllık, amortismanı bitmemiş donanım bulunuyor. Onu çöpe atmak kimsenin işine gelmiyor; hybrid mimarinin en yaygın gerekçelerinden biri bu.

Üçüncüsü ERP entegrasyonu. ERP genelde her şeyin merkezinde duruyor ve kendisine bağlı çok sayıda sistemle sürekli konuşuyor. Bu yüzden ERP'yi taşımak, ona bağlı bileşenleri de birlikte düşünmeyi gerektiriyor; tek başına taşınan bir ERP ortamlar arası gecikmeye en duyarlı bileşen haline geliyor.

Dördüncüsü vardiya düzeni. Üretim yirmi dört saat sürüyorsa bakım penceresi bulmak kolay olmuyor. Planlı bakımların ne zaman yapılacağı sözleşme aşamasında konuşulması gereken bir konu; olağan penceremiz 00.00 ile 06.00 arası ama vardiya düzenine göre ayrıca planlanabiliyor.

Ne kalır, ne çıkar

Bölme kararı uygulama sınırlarına göre veriliyor: birbiriyle çok konuşan parçalar aynı tarafta kalıyor. Pratikte sahada kalanlar genelde üretim ve depo yürütme sistemleri, hat üzerindeki kontrol yazılımları ve bunların yerel veri tabanları oluyor.

Buluta çıkanlar ise raporlama ve iş zekâsı, entegrasyon katmanı, test ve geliştirme ortamları, yedekleme hedefleri. Bunlar kesintiye daha toleranslı ve veri bağı daha zayıf olduğu için ilk taşınacak grup da bunlar oluyor.

İki ortam arasında şifreli bir site-to-site bağlantı kuruluyor ve iki taraftaki ağ adresleme birbiriyle çakışmayacak şekilde planlanıyor. Bu planlama işin en sıkıcı ama en belirleyici kısmı; adres çakışması sonradan çıktığında çözümü genelde bir tarafı yeniden adreslemek oluyor, o da kesinti demek. Topolojiyi hybrid cloud bağlantı sayfasında diyagramla anlattık.

Kapsamımızda ne var

Kurulumdan önce mevcut ortamın envanterini çıkarıyoruz: hangi sistem hangi sistemle konuşuyor, hangi veri nerede duruyor, hangi bağımlılık gizli. Bu adım atlandığında hybrid mimari kâğıt üzerinde çalışıp gerçekte tökezliyor, çünkü kimsenin haberi olmayan bir bağımlılık iki ortam arasına düşüyor. Kurulum ve bağlantı tarafı hybrid cloud entegrasyon kapsamında.

Sonrasında iki ortamı tek bir kaynak havuzu gibi yönetilebilir hale getiriyoruz; kapasite planlaması ikisini birden görerek yapılıyor. Bunun ayrıntısı kaynak yönetimi sayfasında. Temel kavram için hybrid cloud nedir sayfasına bakabilirsiniz.

Maliyet tarafında hybrid'in otomatik olarak ucuz olmadığını baştan söylüyoruz. İki ortamı birden işletmek, tek ortamı işletmekten daha karmaşık. Hesabın nasıl yapıldığını ve hangi kalemlerin unutulduğunu maliyet hesabı yazımızda rakamlarla açtık.

Bakım penceresi ve vardiya

Yirmi dört saat çalışan bir tesiste bakım penceresi bulmak, altyapı tarafındaki en sıradan işi bile planlama konusu haline getiriyor. Güvenlik yamaları ve sürüm yükseltmeleri ertelenebilir işler değil; ertelendiklerinde biriken risk bir noktada tek seferde ödeniyor.

Planlı bakımları en az üç gün önceden yazılı olarak bildiriyoruz. Olağan bakım penceremiz 00.00 ile 06.00 arası ama vardiya düzenine göre ayrıca planlanabiliyor; hangi hattın hangi saatte durabildiğini siz biliyorsunuz. Önceden duyurulan pencereler çalışma süresi hesabının dışında tutuluyor.

Acil müdahale gerektiren güvenlik yamalarında bu süre kısalabiliyor; böyle durumlarda mümkün olan en erken bildirim yapılıyor ve işlem kayıt altına alınıyor. Kesintisiz yükseltmenin Kubernetes tarafında nasıl yürütüldüğünü sürüm yükseltme yazımızda adım adım anlattık.

Nereden başlanır

En iyi başlangıç noktası kesintiye en toleranslı ve veri bağı en zayıf iş yükü oluyor: test ve geliştirme ortamları ya da gece çalışan toplu işler. Bunlar taşındığında iki şey birden öğreniliyor, bağlantının gerçek başarımı ve iki ortamı birlikte işletmenin ekibe getirdiği yük.

İkinci adım bağlantı kopması senaryosunu denemek. Hattı bilerek kesip sahadaki sistemlerin ne kadar süre kendi başına çalışabildiğini ölçmek, bu mimaride yapılabilecek en değerli test. Sonuç beklediğinizden kısa çıkarsa mimari değişmesi gereken şey, geçiş tarihi değil.

Geçişin nasıl planlandığını geçiş süreci sayfasında, hangi katmandan kimin sorumlu olduğunu sorumluluk paylaşımı sayfasında bulabilirsiniz. Diğer sektörler için çözümler sayfasına bakın.

Bu sektörde en sık atlanan hazırlık, sahadaki sistemlerin gerçek envanterinin çıkarılması. Yıllar içinde eklenmiş, kimsenin belgelemediği bağlantılar hemen her tesiste bulunuyor ve hybrid mimariyi tökezleten şey genelde bunlar oluyor. Envanter çalışması keşif aşamasının parçası; sürprizlerin geçiş gecesi değil başında çıkması için.

Uzmanla görüşün