Video: MICROSERVICES ARCHITECTURE | SERVICE REGISTRY | PART - 6 (Kasım 2024)
Kurumsal yazılım manzarası buzzy teknolojilerle doludur. Blockchain, düşük kod geliştirme ya da çalışma şeklimizi değiştiren diğer yeni trendler olabilir. Daha önce hiç duymadığınız yeni bir sözcük kelimesi "mikro hizmetler" dir.
Bu tasarım yüzünden. Mikro servisler, geleneksel bir "monolith" fikrinden ziyade iç içe geçmiş modüler bileşenlere dayanan bir yazılım geliştirmenin farklı bir yoludur - sürekli büyüyen bir kod dağından oluşan bir uygulama. Mikro hizmet tabanlı uygulamalar, karmaşık bir veri merkezi uygulamasında veya ölçeklenebilir bulut altyapısında barındırılan bir web veya mobil uygulamada olsun, kullanıcı arabirimi (UI) tarafından hiç farklı görünmüyor.
İşletmelerin mikro hizmetleri önemsemelerinin sebebi, sahne arkasında mimarinin gelişiminize ve BT ekiplerinize daha hızlı çalışıp yenilik yapması, altyapıyı yönetmesi ve bir uygulamaya yeni özellikler ve işlevler eklemenin maliyetini ve karmaşıklığını azaltmasıdır. IDC'de Uygulama Geliştirme Yazılım Araştırmaları Program Direktörü Al Hilwa, hem kültürel hem de teknik zorlukları göz önünde bulundurarak bir uygulayıcıya mikro hizmetleri nasıl uygulayacağını açıkladı.
Hilwa, "Yeni sistemler inşa ederken, muhtemelen kilit nokta, tek bir mikro hizmetin küçük bir ekip tarafından yapılması gerektiğini kabul etmektir" dedi. “İkincisi, programlama dillerinde ve geliştirici iş akışlarında çeşitlilik toleransı genellikle genel bir mikro hizmet kültürünün bağımsız niteliği ile ifade edilir. Bir yöneticinin ana aşaması, her bina yayınlanmış bir uyumlu modüle sahip küçük bir ekip kullanarak artan bir şekilde yazılım oluşturmaktır. Arayüzün avantajı, bağımsız modüllerin yayınlanan API'ler düzenli bir şekilde yönetildiği sürece bağımsız olarak çok daha hızlı bir şekilde geliştirilebilmesidir. ”
Gerçekten Mikro Hizmetler Nedir?
Hilwa, "Yeni Yazılım Sistemleri İnşa Etmek İçin Yeni Bir Mimari Yaklaşım Olarak Mikro Hizmetlerin Ortaya Çıkması" başlıklı 2015 IDC raporunu yazdı. Raporda, mikro hizmetleri, API tanımlı birlikte çalışabilirlik gereksinimlerini (bir bütün olarak uygulamaya geri bağlanmış anlamını sağlamak için), uygulama bileşenlerinin bağımsız olarak tasarlandığı ve geliştirildiği, ayrıntılı bir yazılım mimarisi olarak tanımlamaktadır. Ancak, mikro hizmetler bir boşlukta mevcut değildir. Yeni bir mimari, güçlü organizasyonel destek ve BT kültüründe bir değişim gerektiriyor.
Mikroservisler ayrıca belirli bir teknoloji ile tanımlanmamıştır, ancak konteynerlerin gelişmesi ve sürekli teslimat (CD) ve sürekli entegrasyon gibi geliştirme yaklaşımları yoluyla otomasyonun artması ile uzun süredir devam eden hizmet odaklı mimari (SOA) konseptinin evrimi olarak tanımlanmaktadır. (Cl).
Hilwa, "Günümüzde mikro hizmetleri kullanan kuruluşlar tipik olarak daha hızlı bir hizmet gelişimi hızı arzusuyla motive edilmektedir" dedi. “Dolayısıyla, bu tür çoğu durumda, mikro servisler büyük ölçüde CI / CD otomasyonunu kullanıyor. Ancak, gerçek dağıtım hızı, hizmetler arasında farklı olabilir. Anahtarın iç kültürü yakından incelemek ve “Teknoloji yığınında daha fazla ademi merkeziyetçilik ve çeşitliliğe tolerans göstermeye istekli olduğunuzdan emin olun.”
"İç kültür" ile Hilwa, büyük ölçüde yazılım geliştirme, BT operasyonları ve kalite güvencesini (KG) tek bir işbirliğine dayalı iş akışında birleştiren bir felsefe olan DevOps'a atıfta bulunuyor. DevOps yazılımının başlatılması HashiCorp ve kurucuları uzun süredir mikro hizmetlerin savunucusu olmuştur. Geçtiğimiz günlerde 24 milyon dolarlık B Serisi fon teminini alan şirket, açık kaynaklı kullanıcıları ve kurumsal müşterileri arasında Cisco, DigitalOcean, Mozilla ve Stripe gibi şirketleri sayıyor.
Mikro hizmetler, HashiCorp'un DevOps altyapısının geliştirilmesine ve uygulama iş akışlarına, popüler açık kaynaklı araçları ve büyüyen kurumsal ürün paketinde nasıl yaklaştığının temelini oluşturur. Amazon ve eBay: CTO ve HashiCorp'un kurucu ortağı Armon Dadgar, monolitler ve mikro hizmetler arasındaki farkı basit bir analoji kullanarak yıktı: Amazon ve eBay.
Dadgar, "Amazon ve eBay'i tekli uygulamalar olarak düşünün. Son kullanıcı bakış açısından, benzer görünüyorlar, ancak sahnelerin ardında şirketler, uygulamalarını nasıl inşa ettikleri ve tasarladıkları konusunda karşıt yaklaşımlar kullandılar" dedi. "Amazon, en başından beri bir mikro hizmet paketi oldu; tek bir uygulama gibi davranıyor. Ancak, aramayı, ürün kataloğunu, alışveriş sepetini, faturaları, sipariş akışlarını ayırıp bu işlevleri bölerseniz, iki uygulama farklı çalışıyor makineleri."
Amazon benzetmesi aynı zamanda Amazon'un kendisinin nasıl yapılandırıldığına da uzanıyor. Dadgar, mikro hizmetler gibi teknoloji yaklaşımlarını DevOps'a yönelik daha büyük işlem hareketini destekleyen araçlar olarak açıklar. Jeff Bezos'un “İki Pizza Kuralı”, Amazon ekibinde yalnızca beş ila sekiz kişinin çalıştığı şekilde çalışır. Takım büyürse, ikiye ayrılır.
Amazon'un örgütsel hiyerarşisi, Dadgar'ın "işlevselliğin ayrışması" olarak tanımladığı şeye doğru eşlemeye başlar. Hem organizasyonel hem de modüler bir mimari düzeyde ayrılmış olan her ekip, her bir değişiklik için koordine etmeye gerek kalmadan daha özgürce geliştirme ve deneme yeteneğine sahiptir - tüm bunlar hala tek bir uyumlu uygulamanın parçası olarak çalışmaktadır.
Dadgar, "eBay, yekpare yaklaşımı benimsedi; eBay'in tamamını, 50 milyon dolarlık bir kod satırı olarak kurdular, " dedi. “Mikro hizmet yaklaşımı başlangıçta daha acı vericidir çünkü modülerlik ve birlikte çalışabilirlik sorunları bir monolitte olmayan sorunlardır. Ancak uygulama çok büyüdükçe işler bozulmaya başlar. Bir monolitte, ayrışma olmaz.
“Yüzlerce veya binlerce geliştiriciyi tek bir kod tabanında işbirliği yaparak ve koordine etmeye çalışmayı düşünün. Uygulamanın bir tarafına bir işlevsellik ekleyen bir QA ekibi diğer tarafta bir şeyleri kırabilir çünkü rollerin ve sorumlulukların net bir şekilde ayrılması söz konusu değildir. proje ekibiyle ne kadar hızlı çalışırsa çalışsın, haftalarca süren ve darboğazı gelişebilen QA süreci arasında daha fazla koordinasyona ihtiyaç duymaya başlıyorsunuz.
DevOps Dünyasında Konteynerler ve Mikro Hizmetler
İşletmenizin bir mikro hizmet mimarisini uygulama biçimi, yatırımın karşılığını alıp almayacağınızı belirleme yolunda uzun bir yol kat edecektir. Mikro hizmetler, başta tüm servislerin birbirleriyle konuşmasını sağlamak için gereken API entegrasyonunda çok fazla çalışmadır. Hilwa, mikro hizmetleri bir sisteme entegre etmeye çalışırken daha da karmaşık olduğunu açıkladı; işletmelere, mikro hizmetler için eski bir monolith uygulamasının yeniden tasarlanmasından ziyade, mümkün olduğunda yeni sistemler inşa etmelerini önerir.
Hilwa, "Geleneksel sistem mimarileri tipik olarak ayrıntılı normalleştirilmiş şemalara sahip büyük, karmaşık veri tabanı sistemlerini içerir" dedi. “Bu tür sistemleri kendi bağımsız sistemleriyle daha küçük bileşenlere ayırmak, çok sayıda veritabanı tasarım çalışması gerektirir ve temel uygulama mantığının çoğunu etkili bir şekilde yeniden yazar. Bu genellikle çoğu zaman maliyet ve zaman engelleyicidir.”
Eski bir uygulamayı yeniden tasarlarsanız, Hilwa aşamalı olarak yapmanızı önerir. API entegrasyonundan daha önemli olmasına rağmen, mikro hizmetler, arkasındaki DevOps kültürü olmadan çalışmaz. HashiCorp'un Dadgar'ı, DevOps'un daha büyük şemsiyesi söz konusu olduğunda, mikro hizmetlerin, uygulamalar sunduğumuz iş akışlarını temelden değiştirmeye yönelik daha büyük bir süreç kaymasını kolaylaştıracak bir araç olduğunu söyledi. Kurucu ortağı Mitchell Hashimoto'nun şirkete ne zaman başladığını ortaya koyan HashiCorp Tao'ya işaret etti: basit, modüler ve beste edilebilir.
Dadgar, "Bir şekilde DevOps, mikro hizmetlerden daha da aşırı bir terimdir" dedi. “Ancak bir işletme farklı bilgi birikimine sahip insanlardan oluşuyor: geliştiriciler, operatörler, güvenlik görevlileri. Ve sonra, bu insanları düzenleme biçiminiz işleniyor. O zaman bu işlemi destekleyecek araçlar var, bu da mikro hizmetlerin ve konteynerlerin bulunduğu yer. içeri gel."
Docker’ın açık kaynaklı patlamasıyla popüler olan konteynerler, işletmelerin mikro hizmetleri kolaylaştırmak için kullanabilecekleri tek araç olmaktan uzak. IDC'den Hilwa, konteynerlerin modern uygulamalarda CI / CD iş akışlarının bir parçası olarak ve bazı durumlarda üretime dağıtırken kullanıldığını söyledi. Ancak, mikro hizmetlerin kapsayıcılara ihtiyaç duymadan sanal makineleri (VM) de kullanabileceğini söyledi.
Bununla birlikte, iş bulutlarının evrimleşme şekilleri söz konusu olduğunda, Docker konteynerleri ve mikro hizmetleri, HashiCorp gibi girişimlerden Oracle gibi kurumsal devlere kadar her şekil ve büyüklükteki iş dünyası tarafından benimsenen güçlü bir takım birleşimidir. HashiCorp'un Babası, konteynerlerin Dev ve Ops'un (ve dernek olarak farklı ekipler ve hizmetler) birbirleriyle iletişim kurmasının uygun yol olduğunu söyledi.
Dadgar, “Geliştiricilerle operatörler arasında geçirdiğimiz eser nedir? Ne işliyor ve etrafta dolaşıyoruz? Konteynerler dolaşmak için uygun bir birimdir” dedi. “Dünyanın dört bir yanındaki küresel bir nakliye şirketi hakkında bir düşünün. Yük gemisi, kargo treni veya kamyon olsun, tüm sistem boyunca akan aynı birim.”
DevOps ve mikroservisler hala yaygın kurumsal kabulden uzak ama pazar sadece büyüyor. IDC raporuna göre, mikro hizmetler mimarisi önümüzdeki beş yıl içinde bir olgunlaşma aşamasına girecek. Bu vade, 2020 yılına kadar kuruluşların yüzde 50'sine ulaşan DevOps kültürü, yazılım otomasyon araçlarının sürekli gelişmesi ve Amazon Web Services (AWS) ve Microsoft Azure'un sağladığı ucuz, ölçeklenebilir bulut altyapısının hakimiyetinde gerçekleşecek.
Dadgar, şu anda DevOps'u ve mikro hizmetleri kuran işletmelerin küçük bir kısmıyla bile, HashiCorp'un zaten abartılı olduğunu söyledi. Git aylık yedi milyon aktif kullanıcısı olan açık kaynaklı bir topluluğun üzerine, sadece dokuz aylık kurumsal satışlardan sonra ilk yedi rakamlı gelirini vurdu. Mikro hizmetler, HashiCorp'un iş akışı uygulaması takım boru hattı ve daha büyük DevOps altyapı yol haritasının sadece bir parçasıdır. Ancak, şirketin inşa ettiği her şeyin altındaki modülerlik ve birlikte çalışabilirlik, Silikon Vadisi'ndeki en sıcak yazılımlardan birinin meteorik yükselişine neden oldu.
Dadgar, “Dört yıl önce başladığımızda toplantılara gider ve altyapının nasıl yönetileceği konusundaki vizyonumuzu geliştirirdik” dedi. “Tam olarak odadan dışarı çıkmadık; erken olduğunu biliyorduk. Ama şimdi Terraform gibi araçlarımız endüstri standardı olma yolundalar. Göreceğimiz şey, rekabet baskısının domino etkisi ve Uzun vadede, rolümüz, almaları gereken süreç değişimini anlamak için CIO'lar ve CTO'larla birlikte çalışacak.
Dadgar, “O gün Toyota'yı tekrar düşünün” dedi. “Ürünler üreten bir sürü araba şirketiniz vardı, ancak maliyeti olması gerekenden daha fazlaydı. Toyota bir arabanın ne olduğunu yeniden keşfetmedi; süreç konusunda daha titiz ve artımlıydılar; Rekabetçi kalmak için aynı uygulamaların benimsenmesi için sektörün geri kalanı … Şu anda, nasıl rekabet avantajı elde edebileceklerini soran sektör liderlerimiz var ve bunların yanıtları, pazarın Google ve Amazon'larının uygulamalarını benimsemektir. gelin, kritik bir kitleye çarpacak. "
