25 Nisan'da Mail.ru Group olarak bulutlar ve çevresi hakkında bir konferans düzenledik - . Birkaç önemli nokta:
- Ana — Mail.ru Bulut Çözümleri, #CloudMTS, SberCloud, Selectel, Rostelecom Veri Merkezi ve Yandex.Cloud, bulut pazarımızın özellikleri ve hizmetleri hakkında konuştu;
- Bitrix24'teki meslektaşlarımız nasıl olduklarını anlattı ;
- Leroy Merlin, Otkritie, Burger King ve Schneider Electric ilginç bilgiler sağladı — işletmelerinin BT için hangi görevleri belirlediğini ve bulut teknolojileri de dahil olmak üzere hangi teknolojileri en umut verici olarak gördüklerini.
Tüm videoları mailto:CLOUD konferansından izleyebilirsiniz ve burada mikro hizmetler hakkındaki tartışmanın nasıl gittiğini okuyabilirsiniz. MegaFon iş sistemleri araştırma ve geliştirme merkezi başkanı Alexander Deulin ve M.Video-Eldorado grubunun bilgi teknolojisi direktörü Sergey Sergeev, monolitlerden kurtulmaya yönelik başarılı vakalarını paylaştı. Ayrıca BT stratejisi, süreçleri ve hatta İK ile ilgili konuları da tartıştık.
Panelistler
- Sergey Sergeev, Grup CIO'su "M.Video-Eldorado";
- Alexander Deulin, iş sistemleri araştırma ve geliştirme merkezi başkanı Megafon;
- Moderatör — Dmitry Lazarenko, PaaS Yönlendirme Başkanı Mail.ru Bulut Çözümleri.
Alexander Deulin'in konuşmasının ardından Tartışmaya M.Video-Eldorado'dan Sergey Sergeev ve Mail.ru Bulut Çözümleri'nden tartışma moderatörü Dmitry Lazarenko da katılıyor.
Aşağıda sizin için tartışmanın bir metnini hazırladık, ancak videoyu da izleyebilirsiniz:
Mikro hizmetlere geçiş pazar ihtiyaçlarına bir yanıttır
Dmitry:
Mikro hizmetlere geçiş konusunda başarılı bir deneyiminiz oldu mu? Ve genel olarak: Mikro hizmetleri kullanmanın veya monolitlerden mikro hizmetlere geçmenin en büyük ticari faydasını nerede görüyorsunuz?
Sergey:
Mikro hizmetlere geçişte zaten bir miktar yol kat ettik ve bu yaklaşımı üç yılı aşkın süredir kullanıyoruz. Mikro hizmetlere olan ihtiyacı haklı çıkaran ilk ihtiyaç, çeşitli ön uç ürünlerin arka ofisle sonsuz entegrasyonuydu. Ve her seferinde şu veya bu hizmetin işleyişi için kendi kurallarımızı uygulayarak ek entegrasyon ve geliştirme yapmak zorunda kaldık.
Bir noktada sistemlerimizin çalışmasını ve işlevsellik çıktısını hızlandırmamız gerektiğini fark ettik. O an piyasada mikro hizmetler, mikro hizmet yaklaşımı gibi kavramlar zaten vardı ve biz de bunu denemeye karar verdik. Bu 2016 yılında başladı. Daha sonra platformun temeli atıldı ve ilk 10 hizmet ayrı bir ekip tarafından hayata geçirildi.
İlk hizmetlerden biri ve en yoğun olanı fiyat hesaplama hizmetiydi. İster bir web sitesi ister bir perakende mağazası olsun, M.Video-Eldorado şirketler grubuna, herhangi bir kanala her geldiğinizde, oradan bir ürün seçin, web sitesinde veya "Sepet"te fiyatı görün, maliyet otomatik olarak hesaplanır bir hizmet tarafından hesaplanır. Bu neden gerekli: Bundan önce her sistemin promosyonlarla - indirimlerle vb. - çalışmak için kendi ilkeleri vardı. Fiyatlandırmayı arka ofisimiz yönetir; indirim işlevi başka bir sistemde uygulanır. Bunun merkezileştirilmesi ve bunu uygulamamıza izin verecek bir iş süreci biçiminde benzersiz, ayrılabilir bir hizmetin yaratılması gerekiyordu. Hemen hemen böyle başladık.
İlk sonuçların değeri çok büyüktü. İlk olarak, ayrı ayrı ve toplu olarak çalışmamıza olanak tanıyan ayrılabilir varlıklar oluşturmayı başardık. İkinci olarak daha fazla sistemle entegrasyon açısından sahip olma maliyetini düşürdük.
Son üç yılda üç ön hat sistemi ekledik. Şirketin karşılayabileceği miktarda kaynakla bunları sürdürmek zordu. Bu nedenle görev, pazara hız, iç maliyetler ve verimlilik açısından yanıt veren yeni satış noktaları aramak olarak ortaya çıktı.
Mikro hizmetlere geçişin başarısı nasıl ölçülür?
Dmitry:
Mikro hizmetlere geçişte başarı nasıl belirlenir? Her şirkette “öncesi” neydi? Geçişin başarısını belirlemek için hangi ölçümü kullandınız ve bunu gerçekte kim belirledi?
Sergey:
Her şeyden önce, BT içerisinde yeni yeteneklerin “kilidini açan” bir kolaylaştırıcı olarak doğdu. Piyasadaki zorluklara yanıt vererek, nispeten aynı parayla her şeyi daha hızlı yapma ihtiyacımız vardı. Artık başarı, farklı sistemler tarafından yeniden kullanılan hizmetlerin sayısıyla, süreçlerin kendi aralarında birleştirilmesiyle ifade ediliyor. Şimdi öyle ama o anda bir platform oluşturmak ve bunu yapabileceğimiz hipotezini doğrulamak bir fırsattı, bu bir etki yaratacak ve iş senaryosunu hesaplayacak.
Alexander:
Başarı daha ziyade içsel bir duygudur. İş dünyası her zaman daha fazlasını ister ve birikmiş işlerimizin derinliği başarının kanıtıdır. Bana öyle geliyor.
Sergey:
Evet katılıyorum. Üç yıl içinde zaten iki yüzün üzerinde hizmetimiz ve birikimimiz var. Ekip içindeki kaynaklara olan ihtiyaç yılda sadece %30 oranında artıyor. Bu oluyor çünkü insanlar şunu hissetti: Daha hızlı, farklı, farklı teknolojiler var, tüm bunlar gelişiyor.
Mikro hizmetler gelecek ama çekirdek kalacak
Dmitry:
Gelişime yatırım yaptığınız hiç bitmeyen bir süreç gibidir. İşletmeler için mikro hizmetlere geçiş zaten bitti mi, bitmedi mi?
Sergey:
Cevaplamak çok kolay. Ne düşünüyorsunuz: telefonları değiştirmek sonsuz bir süreç mi? Her yıl kendimiz telefon alıyoruz. Ve işte burada: Hıza ihtiyaç olduğu sürece, pazara uyum sağlamak için bazı değişiklikler yapılması gerekecek. Bu, standart şeylerden vazgeçtiğimiz anlamına gelmiyor.
Ancak her şeyi aynı anda kapsayamayız ve yeniden yapamayız. Daha önce var olan eski, standart entegrasyon hizmetlerimiz var: kurumsal otobüsler vb. Ama birikmiş bir iş var, bir de ihtiyaç var. Mobil uygulamaların sayısı ve işlevleri artıyor. Aynı zamanda kimse size %30 daha fazla para verileceğini söylemiyor. Yani bir yanda ihtiyaçlar, diğer yanda verimlilik arayışı her zaman vardır.
Dmitry:
Hayat iyi durumda. (Gülüyor)
Alexander:
Genel olarak evet. Çekirdek kısmı manzaradan çıkarmak konusunda devrim niteliğinde yaklaşımlarımız yok. Sistemlerin mikroservis mimarisiyle daha tutarlı olacak şekilde ayrıştırılması, sistemlerin birbirleri üzerindeki etkisinin azaltılması yönünde sistematik çalışmalar yapılıyor.
Ancak operatörün alanında her zaman satın aldığımız bazı platformlar olacağından temel kısmı korumayı planlıyoruz. Yine sağlıklı bir dengeye ihtiyacımız var: Çekirdeği kesmek için acele etmemeliyiz. Sistemleri yan yana yerleştiriyoruz ve artık birçok temel parçanın üzerinde olduğumuz ortaya çıkıyor. Ayrıca işlevselliği geliştirerek iletişim hizmetlerimizle çalışan tüm kanallar için gerekli temsilleri oluşturuyoruz.
İşletmelere mikro hizmetler nasıl satılır?
Dmitry:
Ayrıca, geçiş yapmamış ama yapmayı planlayanlar için de ilgileniyorum: Bu fikri iş dünyasına satmak ne kadar kolaydı ve bu bir macera mı, bir yatırım projesi miydi? Yoksa bilinçli bir strateji miydi: Artık mikro hizmetlere gidiyoruz ve bu kadar, bizi hiçbir şey durduramaz. Senin için nasıldı?
Sergey:
Biz bir yaklaşım satmıyorduk, ticari fayda satıyorduk. İş hayatında bir sorun vardı, çözmeye çalıştık. O anda, farklı kanalların fiyatları hesaplamak için farklı ilkeleri (promosyonlar, promosyonlar vb. için ayrı ayrı) kullandığı ifade edildi. Bakımı zordu, hatalar oluştu ve müşteri şikayetlerini dinledik. Yani bir soruna çözüm satıyorduk ama platform oluşturmak için paraya ihtiyacımız olduğu gerçeğiyle geldik. Ve yatırımın ilk aşaması örneğini kullanarak bir iş senaryosu gösterdiler: Bunu nasıl telafi etmeye devam edeceğiz ve bu bize ne sağlayacak?
Dmitry:
Bir şekilde ilk aşamanın zamanını kaydettiniz mi?
Sergey:
Evet elbette. Çekirdeği platform olarak oluşturup pilotu test etmek için 6 ay ayırdık. Bu süre zarfında pilotun kayabileceği bir platform oluşturmaya çalıştık. Daha sonra hipotez doğrulandı ve işe yaradığına göre devam edebileceğimiz anlamına geliyor. Ekibi kopyalamaya ve güçlendirmeye başladılar; onu tam da bunu yapan ayrı bir bölüme taşıdılar.
Daha sonra iş ihtiyaçlarına, fırsatlara, kaynakların kullanılabilirliğine ve şu anda üzerinde çalışılan her şeye dayalı sistematik çalışma gelir.
Dmitry:
TAMAM. İskender, ne diyorsun?
Alexander:
Mikro hizmetlerimiz, kaynak tasarrufu, sunucu kapasitesi biçimindeki bazı artıklar ve ekip içindeki kuvvetlerin yeniden dağıtılması nedeniyle "deniz köpüğünden" doğdu. Başlangıçta bu projeyi işletmeye satmadık. Bu hem araştırdığımız hem de buna göre geliştirdiğimiz bir projeydi. 2018 yılının başında başladık ve bu yönü heyecanla geliştirdik. Satışlar yeni başladı ve devam ediyoruz.
Dmitry:
Bir işletme, haftada bir boş günde Google gibi şeyler yapmanıza izin veriyor mu? Böyle bir yönünüz var mı?
Alexander:
Araştırma yaparken aynı zamanda iş sorunlarını da ele aldık, dolayısıyla tüm mikro hizmetlerimiz iş sorunlarına çözüm oluyor. Başlangıçta abone tabanının küçük bir kısmını kapsayan mikro hizmetler oluşturduk ve şimdi neredeyse tüm amiral gemisi ürünlerde varız.
Ve maddi etki zaten açık; eğer eski yolu izlemiş olsaydık, zaten sayılabiliriz, ürün lansmanlarının hızı ve gelir kaybı tahmin edilebilir. Davayı bunun üzerine inşa ediyoruz.
Mikro hizmetler: heyecan mı yoksa zorunluluk mu?
Dmitry:
Sayılar sayılardır. Ve gelir veya tasarruf edilen para çok önemlidir. Diğer tarafa baktığınızda ne olur? Görünüşe göre mikro hizmetler bir trend, bir abartı ve birçok şirket bunu kötüye mi kullanıyor? Mikro hizmetlere yaptıklarınızı ve tercüme etmediklerinizi ne kadar net bir şekilde ayırıyorsunuz? Şimdi miras kaldıysa, 5 yıl sonra hâlâ mirasa sahip olacak mısınız? M.Video-Eldorado ve MegaFon'da çalışan bilgi sistemleri 5 yıl sonra ne kadar eski olacak? On yıllık, on beş yıllık bilgi sistemleri mi olacak, yoksa yeni nesil mi olacak? Bunu nasıl görüyorsunuz?
Sergey:
Bana öyle geliyor ki çok uzakları düşünmek zor. Geriye dönüp baktığımızda, makine öğrenimi ve yüz ile kullanıcı tanımlamayı da içerecek şekilde teknoloji pazarının bu şekilde gelişeceğini kim hayal edebilirdi? Ancak önümüzdeki yıllara bakarsanız bana öyle geliyor ki şirketlerdeki çekirdek sistemler, kurumsal ERP sınıfı sistemler oldukça uzun süredir çalışıyor.
Şirketlerimiz toplu olarak 25 yaşındadır ve klasik ERP, sistem ortamının çok derinlerinde yer almaktadır. Oradan bazı parçaları alıp mikro hizmetlerde birleştirmeye çalıştığımız açık, ancak çekirdek kalacak. Buradaki tüm çekirdek sistemleri değiştireceğimizi ve hızla yeni sistemlerin diğer parlak tarafına geçeceğimizi hayal etmek artık benim için zor.
Müşteriye ve tüketiciye daha yakın olan her şeyin en büyük ticari fayda ve değere sahip olduğu, uyarlanabilirliğin ve hıza, değişime, "dene, iptal et, yeniden kullan, farklı bir şey yap" üzerine odaklanmanın olduğu gerçeğinin destekçisiyim. gerekli “—işte manzaranın değişeceği yer burası. Ve kutulu ürünler oraya pek uymuyor. En azından biz görmüyoruz. En kolay, en basit çözümlere orada ihtiyaç var.
Bu gelişmeyi görüyoruz:
- temel bilgi sistemleri (çoğunlukla arka ofis);
- mikro hizmetler biçimindeki orta katmanlar çekirdeği birbirine bağlar, birleştirir, bir önbellek oluşturur vb.
- ön hat sistemleri tüketiciyi hedef alır;
- Genellikle pazaryerlerine, diğer sistemlere ve ekosistemlere entegre olan bir entegrasyon katmanı. Bu katman olabildiğince hafiftir, basittir ve minimum düzeyde iş mantığı içerir.
Ama aynı zamanda eski ilkelerin uygun şekilde kullanılması halinde kullanılmaya devam edilmesi taraftarıyım.
Diyelim ki klasik bir kurumsal sisteminiz var. Tek bir satıcının ortamında bulunur ve birbiriyle çalışan iki modülden oluşur. Ayrıca standart bir entegrasyon arayüzü de bulunmaktadır. Neden bunu yeniden yapıp oraya bir mikro hizmet getirelim?
Ancak arka ofiste, iş sürecinde bilgi parçalarının toplandığı ve daha sonra 5-8 ön hat sistemi tarafından kullanılan 10 modül olduğunda, fayda hemen fark edilir. Beş arka ofis sisteminden birini alıp iş sürecine odaklanan izole bir hizmet yaratırsınız. Hizmeti teknolojik olarak gelişmiş hale getirin; böylece bilgileri önbelleğe alır, hataya dayanıklı olur ve ayrıca belgelerle veya ticari varlıklarla çalışır. Ve bunu tüm ön saflardaki ürünlerle tek bir prensibe göre entegre edersiniz. Ön saftaki ürünü iptal ettiler; sadece entegrasyonu kapattılar. Yarın bir mobil uygulama yazmanız veya küçük bir web sitesi oluşturmanız ve yalnızca bir bölümü işlevselliğe koymanız gerekiyor - her şey basit: onu bir kurucu gibi bir araya getirdiniz. Bu yönde daha fazla gelişme görüyorum, en azından ülkemizde.
Alexander:
Sergey yaklaşımımızı tamamen anlattı, teşekkür ederim. Sadece kesinlikle nereye gitmeyeceğimizi söyleyeceğim - temel kısma, çevrimiçi faturalandırma konusuna. Yani, derecelendirme ve ücretlendirme aslında parayı güvenilir bir şekilde yazacak "büyük" bir harmanlayıcı olarak kalacaktır. Ve bu sistem düzenleyici otoritelerimiz tarafından sertifikalandırılmaya devam edecek. Müşterilere yönelik diğer her şey elbette mikro hizmetlerdir.
Dmitry:
Burada sertifikasyon bir hikaye. Muhtemelen daha fazla destek. Desteğe çok az para harcıyorsanız veya sistem destek ve değişiklik gerektirmiyorsa, ona dokunmamak daha iyidir. Makul bir uzlaşma.
Güvenilir mikro hizmetler nasıl geliştirilir?
Dmitry:
İyi. Ama hâlâ ilgileniyorum. Şimdi bir başarı öyküsü anlatıyorsunuz: her şey yolundaydı, mikro hizmetlere geçtik, fikri işletmeye savunduk ve her şey yolunda gitti. Ama başka hikayeler de duydum.
Birkaç yıl önce, bankalar için yeni bir mikro hizmet platformu geliştirmeye iki yıl yatırım yapan İsviçreli bir şirket, sonunda projeyi kapattı. Tamamen çöktü. Milyonlarca İsviçre Frangı harcandı ve sonunda ekip dağıldı - işe yaramadı.
Benzer hikayeleriniz oldu mu? Herhangi bir zorluk oldu mu veya var mı? Örneğin, mikro hizmetlerin sürdürülmesi ve izlenmesi de şirketin operasyonel faaliyetlerinde baş ağrısıdır. Sonuçta bileşen sayısı onlarca kat artıyor. Nasıl görüyorsunuz, burada başarısız yatırım örnekleri oldu mu? Peki insanlara bu tür sorunlarla karşılaşmamaları için ne tavsiye edebilirsiniz?
Alexander:
Başarısız örnekler arasında işletmelerin önceliklerini değiştirmesi ve projeleri iptal etmesi yer aldı. İyi bir hazırlık aşamasına gelindiğinde (aslında MVP hazırdır) işletme şöyle dedi: "Yeni önceliklerimiz var, başka bir projeye geçiyoruz ve bunu kapatıyoruz."
Mikro hizmetlerde küresel bir arıza yaşamadık. Huzur içinde uyuyoruz, tüm BSS'ye [iş destek sistemi] hizmet veren 24/7 görev vardiyamız var.
Ve bir şey daha - mikro hizmetleri kutulu ürünler için geçerli olan kurallara göre kiralıyoruz. Başarının anahtarı, öncelikle mikro hizmeti üretime tamamen hazırlayacak bir ekip kurmanız gerektiğidir. Gelişimin kendisi şartlı olarak% 40'tır. Gerisi analitik, DevSecOps metodolojisi, doğru entegrasyonlar ve doğru mimaridir. Güvenli uygulamalar oluşturma ilkelerine özellikle dikkat ediyoruz. Bilgi güvenliği temsilcileri her projeye hem mimari planlama aşamasında hem de uygulama sürecinde katılır. Ayrıca kodun güvenlik açıklarını analiz etmeye yönelik sistemleri de yönetirler.
Diyelim ki durum bilgisiz hizmetlerimizi dağıtıyoruz; bunları Kubernetes'te bulunduruyoruz. Bu, hizmetlerin otomatik ölçeklendirilmesi ve otomatik olarak yükseltilmesi nedeniyle herkesin huzur içinde uyumasına olanak tanır ve görev vardiyasında olaylar meydana gelir.
Mikro hizmetlerimizin tüm varlığı boyunca hattımıza ulaşan yalnızca bir veya iki olay yaşandı. Artık operasyonda herhangi bir sorun yok. Elbette 200 değil 50'ye yakın mikro hizmetimiz var ama bunlar amiral gemisi ürünlerde kullanılıyor. Başarısız olsalardı bunu ilk öğrenen biz olurduk.
Mikro hizmetler ve İK
Sergey:
Desteğe aktarım konusunda meslektaşımla aynı fikirdeyim - işin doğru şekilde organize edilmesi gerekiyor. Ama size elbette var olan sorunlardan bahsedeceğim.
Öncelikle teknoloji yeni. Bu iyi anlamda bir abartıdır ve bunu anlayacak ve yaratabilecek bir uzman bulmak büyük bir zorluktur. Kaynaklar için rekabet çılgınca, bu yüzden uzmanlar ağırlıkları kadar altın değerinde.
İkincisi, belirli peyzajların oluşturulması ve hizmetlerin artmasıyla birlikte yeniden kullanım sorununun sürekli çözülmesi gerekiyor. Geliştiricilerin yapmayı sevdiği gibi: “Şimdi buraya bir sürü ilginç şey yazalım…” Bu nedenle sistem büyüyor ve para, sahip olma maliyeti vb. açısından etkinliğini kaybediyor. Yani yeniden kullanımın sistem mimarisine dahil edilmesi, hizmetlerin tanıtılması ve mirasın yeni bir mimariye aktarılması için yol haritasına dahil edilmesi gerekiyor.
Bir diğer sorun da -her ne kadar bu kendi açısından iyi olsa da- iç rekabettir. "Ah, burada yeni moda adamlar ortaya çıktı, yeni bir dil konuşuyorlar." İnsanlar elbette farklıdır. Java ile yazmaya alışanlar da var, Docker ve Kubernetes yazıp kullananlar da var. Bunlar tamamen farklı insanlar, farklı konuşuyorlar, farklı terimler kullanıyorlar ve bazen birbirlerini anlamıyorlar. Uygulamayı, bilgiyi paylaşma yeteneği ya da başarısızlığı da bu anlamda bir sorundur.
Kaynakları ölçeklendirmek. "Harika hadi gidelim! Artık daha hızlı, daha fazlasını istiyoruz. Ne, yapamaz mısın? Yılda iki kat daha fazlasını teslim etmek mümkün değil mi? Ve neden?" Bu tür büyüyen acılar muhtemelen birçok şey için, birçok yaklaşım için standarttır ve bunları hissedebilirsiniz.
İzlemeyle ilgili. Bana öyle geliyor ki hizmetler veya endüstriyel izleme araçları zaten öğreniyor veya hem Docker hem de Kubernetes ile farklı, standart dışı bir modda çalışabiliyor. Böylece, örneğin, tüm bunların altında çalıştığı, yani toplandığı 500 Java makinesiyle karşılaşmazsınız. Ama bu ürünler henüz olgunlaşmamış, bunu aşmaları gerekiyor. Konu gerçekten yeni, gelişmeye devam edecek.
Dmitry:
Evet, çok ilginç. Ve bu İK için de geçerlidir. Belki İK süreciniz ve İK markanız bu 3 yılda biraz değişti. Farklı yetkinliklere sahip başka insanları işe almaya başladınız. Ve muhtemelen hem artıları hem de eksileri var. Daha önce blockchain ve veri bilimi ilgi odağıydı ve bu alandaki uzmanların değeri milyonlara ulaşıyordu. Artık maliyetler düşüyor, pazar doyuma ulaşıyor ve mikro hizmetlerde de benzer bir eğilim var.
Sergey:
Evet, kesinlikle.
Alexander:
İK şu soruyu sorar: "Arka uç ile ön uç arasındaki pembe tek boynuzlu atınız nerede?" İK mikro hizmetin ne olduğunu anlamıyor. Onlara sırrı anlattık ve arka ucun her şeyi yaptığını ve tek boynuzlu at diye bir şeyin olmadığını anlattık. Ancak İK değişiyor, hızla öğreniyor ve temel BT bilgisine sahip kişileri işe alıyor.
Mikro hizmetlerin evrimi
Dmitry:
Hedef mimariye baktığınızda mikro hizmetler tam bir canavara benziyor. Yolculuğunuz birkaç yıl sürdü. Bazılarının bir yılı var, diğerlerinin ise üç yılı. Tüm sorunları, hedef mimariyi öngördünüz mü, herhangi bir değişiklik oldu mu? Örneğin mikro hizmetler söz konusu olduğunda ağ geçitleri ve hizmet ağları artık yeniden ortaya çıkıyor. Başlangıçta bunları mı kullandınız yoksa mimarinin kendisini mi değiştirdiniz? Bu tür zorluklarınız var mı?
Sergey:
Zaten birkaç iletişim protokolünü yeniden yazdık. Başlangıçta bir protokol vardı, şimdi diğerine geçtik. Güvenliği ve güvenilirliği arttırıyoruz. Kurumsal teknolojilerle başladık - Oracle, Web Logic. Artık mikroservislerde teknolojik kurumsal ürünlerden uzaklaşıp, açık kaynak ya da tamamen açık teknolojilere geçiyoruz. Bu modelde veritabanlarını bırakıp bizim için daha etkili olana geçiyoruz. Artık Oracle teknolojilerine ihtiyacımız yok.
Önbelleğe ne kadar ihtiyacımız olduğunu, mikro hizmetle bağlantı olmadığı halde veriye ihtiyaç duyulduğunda ne yapacağımızı vb. düşünmeden, basitçe bir hizmet olarak başladık. Şimdi mimarinin tanımlanabilmesi için bir platform geliştiriyoruz. hizmet dilinde değil, iş dilinde, kelimelerle konuşmaya başladığımızda iş mantığını bir sonraki seviyeye taşıyın. Artık harflerle konuşmayı öğrendik ve bir sonraki seviye, hizmetlerin bir tür küme halinde toplanacağı, bu zaten bir kelime olduğunda - örneğin bir ürün kartının tamamı. Mikro hizmetlerden derlenmiştir ancak bunun üzerine inşa edilmiş bir API'dir.
Güvenlik çok önemlidir. Erişilebilir olmaya başladığınız ve birçok ilginç şeyi çok hızlı bir şekilde, bir saniye içinde alabileceğiniz bir hizmetiniz olduğunda, bunu en güvenli olmayan bir şekilde alma arzusu ortaya çıkar. Bundan kurtulmak için test ve izleme yaklaşımlarını değiştirmek zorunda kaldık. Ekibi, teslimat yönetimi yapısını ve CI/CD'yi değiştirmek zorunda kaldık.
Bu, telefonlarda olduğu gibi, yalnızca çok daha hızlı bir evrimdir: önce tuşlu telefonlar vardı, sonra akıllı telefonlar ortaya çıktı. Pazarın farklı bir ihtiyacı olduğu için ürünü yeniden yazıp yeniden tasarladılar. Biz böyle gelişiyoruz: birinci sınıf, onuncu sınıf, çalışma.
Yinelemeli olarak, teknoloji açısından her yıl bir şeyler, birikmiş işler ve ihtiyaçlar açısından başka bir şey ortaya konulur. Bir şeyi diğerine bağlıyoruz. Ekip, %20'sini teknik borç ve ekip için teknik desteğe, %80'ini ise ticari kuruluşa harcıyor. Ve biz bunu neden yapıyoruz, bu teknolojik gelişmeleri neden yapıyoruz, bunlar nelere yol açacak anlayışıyla hareket ediyoruz. Bunun gibi.
Dmitry:
Serin. MegaFon'da neler var?
Alexander:
Mikro hizmetlere geldiğimizde asıl zorluk kaosa düşmemekti. MegaFon'un mimarlık ofisi hemen aramıza katıldı, hatta öncü ve öncü oldu - artık çok güçlü bir mimariye sahibiz. Görevi, hangi hedef modele gideceğimizi ve hangi teknolojilerin pilot olarak kullanılması gerektiğini anlamaktı. Mimarlıkta bu pilot çalışmaları kendimiz yürüttük.
Bir sonraki soru şuydu: "Peki tüm bunlardan nasıl yararlanılır?" Ve bir tane daha: "Mikro hizmetler arasında şeffaf etkileşim nasıl sağlanır?" Servis ağı son soruyu cevaplamamıza yardımcı oldu. Istio'yu pilot olarak uyguladık ve sonuçları beğendik. Artık verimli bölgelere açılma aşamasındayız. Tüm zorluklara karşı olumlu bir tavrımız var - yığını sürekli değiştirmemiz, yeni bir şeyler öğrenmemiz gerektiği gerçeği. Biz eski çözümlerden yararlanmakla değil, geliştirmekle ilgileniyoruz.
Dmitry:
Altın sözler! Bu tür zorluklar ekibi ve işletmeyi tetikte tutar ve geleceği yaratır. GDPR, baş veri koruma görevlilerini oluşturdu ve mevcut zorluklar, baş mikro hizmetler ve mimari görevlilerini yarattı. Ve bu memnun ediyor.
Çok tartıştık. Önemli olan, mikro hizmetlerin ve mimarinin iyi bir tasarımının birçok hatadan kaçınmanıza olanak sağlamasıdır. Elbette süreç yinelemeli ve evrimseldir, ancak bu gelecektedir.
Tüm katılımcılara teşekkürler, Sergei ve Alexander'a teşekkürler!
Dinleyicilerden gelen sorular
Dinleyicilerden gelen soru (1):
Sergey, şirketinizde BT yönetimi nasıl değişti? Birkaç sistemden oluşan büyük bir yığın olduğunda, bunun nasıl yönetildiğinin oldukça açık ve mantıklı bir süreç olduğunu anlıyorum. Bu kadar kısa sürede çok sayıda mikro hizmet entegre edildikten sonra BT bileşeninin yönetimini nasıl yeniden oluşturdunuz?
Sergey:
Mimarlığın değişimin itici gücü olarak çok önemli olduğu konusunda meslektaşımla aynı fikirdeyim. Mimari bir bölüm kurarak başladık. Mimarlar aynı zamanda işlevselliğin dağılımının ve bunun peyzajda nasıl görüneceğine ilişkin gereksinimlerin de sahibidir. Yani onlar aynı zamanda bu değişikliklerin koordinatörü olarak da hareket ediyorlar. Sonuç olarak, bir CI/CD platformu oluşturduğumuzda belirli bir teslim sürecinde belirli değişiklikler oldu.
Ancak standart, temel geliştirme ilkeleri, iş analizi, test etme ve geliştirme iptal edilmedi. Sadece hız ekledik. Önceden döngü çok fazla zaman alıyordu, test ortamlarına kurulum ise çok daha fazla zaman alıyordu. Artık iş dünyası bunun faydasını görüyor ve şöyle diyor: “Aynısını neden başka yerlerde de yapamıyoruz?”
Bu, iyi anlamda, aşı formundaki bir enjeksiyonun şunu göstermesine benziyor: Bunu bu şekilde yapabilirsiniz, ancak başka bir şekilde de yapabilirsiniz. Elbette personelde, yeterlilikte, bilgide, dirençte sorun var.
Dinleyicilerden gelen soru (2):
Mikro hizmet mimarisini eleştirenler, test etme ve geliştirmenin zor olduğunu söylüyor. İşlerin karmaşıklaştığı yerde bu mantıklıdır. Ekibiniz hangi zorluklarla karşılaştı ve bunları nasıl aştınız? Herkese soru.
Alexander:
Mikro hizmetlerden platforma geçişte zorluklar yaşanır ancak bunlar çözülebilir.
Mesela 5-7 mikroservisten oluşan bir ürün yapıyoruz. Ana dallara geçişe yeşil ışık yakabilmek için mikro hizmet yığınının tamamında entegrasyon testleri sağlamamız gerekiyor. Bu görev bizim için yeni değildi: BSS'de bunu uzun süredir yapıyorduk, satıcı bize zaten teslim edilmiş çözümleri sağladı.
Ve bizim sorunumuz sadece küçük takımda. Bir koşullu ürün için bir QA mühendisine ihtiyaç vardır. Ve böylece 5-7'ü üçüncü taraflarca geliştirilebilen 2-3 mikro hizmetten oluşan bir ürün gönderiyoruz. Örneğin, faturalandırma sistemi satıcımız Mail.ru Group ve MegaFon Ar-Ge'nin katıldığı bir ürünümüz var. Bunu üretime göndermeden önce testlerle ele almamız gerekiyor. QA mühendisi bir buçuk aydır bu ürün üzerinde çalışıyor ve ekibin geri kalanı onun desteğinden yoksun kaldı.
Bu karmaşıklığa yalnızca ölçeklendirme neden olur. Mikro hizmetlerin boşlukta var olamayacağını, mutlak izolasyonun mevcut olmadığını anlıyoruz. Bir hizmeti değiştirirken her zaman API sözleşmesini korumaya çalışırız. Kaputun altında bir şeyler değişirse ön servis kalır. Değişiklikler ölümcülse, bir tür mimari dönüşüm gerçekleşir ve tamamen uyumsuz olan tamamen farklı bir veri meta modeline geçeriz - ancak o zaman v2 hizmeti API spesifikasyonunun ortaya çıkmasından bahsederiz. Birinci ve ikinci versiyonları aynı anda destekliyoruz ve tüm tüketiciler ikinci versiyona geçtikten sonra birincisini kapatıyoruz.
Sergey:
Eklemek istiyorum. Komplikasyonlar konusunda kesinlikle katılıyorum - bunlar oluyor. Ortam daha karmaşık hale geliyor ve özellikle test için genel giderler artıyor. Bununla nasıl başa çıkılır: Otomatik teste geçin. Evet, otomatik testler ve birim testleri yazmaya ek olarak yatırım yapmanız gerekecek. Geliştiricilerin testi geçmeden taahhütte bulunamaması için kodu değiştiremediler. Böylece otomatik test, birim testi olmadan basma düğmesi bile çalışmaz.
Önceki işlevselliği korumak önemlidir ve bu ek bir yüktür. Bir teknolojiyi başka bir protokole yeniden yazarsanız, her şeyi tamamen kapatana kadar onu yeniden yazarsınız.
Bazen bilerek uçtan uca testler yapmayız çünkü birbiri ardına gelen şeyler olmasına rağmen geliştirmeyi durdurmak istemiyoruz. Manzara çok büyük, karmaşık, birçok sistem var. Bazen sadece taslaktır; evet, güvenlik marjını azaltırsanız daha fazla risk ortaya çıkar. Ama aynı zamanda arzı da serbest bırakırsınız.
Alexander:
Evet, otomatik testler ve birim testleri yüksek kaliteli bir hizmet oluşturmanıza olanak tanır. Birim ve entegrasyon testleri olmadan geçilemeyecek bir boru hattından yanayız. Çoğu zaman emülatörleri ve ticari sistemleri test bölgelerine ve geliştirme ortamlarına sürüklemek zorunda kalıyoruz çünkü tüm sistemler test bölgelerine yerleştirilemiyor. Üstelik sadece ıslanmazlar; sistemden tam teşekküllü bir yanıt üretiriz. Bu, mikro hizmetlerle çalışmanın ciddi bir parçasıdır ve biz de buna yatırım yapıyoruz. Bu olmazsa kaos ortaya çıkar.
Dinleyicilerden gelen soru (3):
Anladığım kadarıyla mikro hizmetler başlangıçta ayrı bir ekipten büyüdü ve artık bu modelde var. Artıları ve eksileri nelerdir?
Benzer bir hikayemiz var: bir tür mikro hizmet fabrikası ortaya çıktı. Artık kavramsal olarak bu yaklaşımı akışlara ve sistemlere göre üretime genişlettiğimiz noktaya geldik. Yani mikro hizmetlerin, mikro hizmet modellerinin merkezi gelişiminden uzaklaşıyor, sistemlere yakınlaşıyoruz.
Buna göre bizim operasyonumuz da sistemlere gidiyor, yani bu konuyu merkezden uzaklaştırıyoruz. Yaklaşımınız ve hedef hikayeniz nedir?
Alexander:
"Mikro hizmet fabrikası" adını ağzınızdan çıkardınız - biz de ölçeklendirmek istiyoruz. Öncelikle artık gerçekten tek bir ekibimiz var. MegaFon'un sahip olduğu tüm geliştirme ekiplerine ortak bir ekosistemde çalışma fırsatı sağlamak istiyoruz. Şu anda sahip olduğumuz tüm geliştirme işlevlerini tamamen devralmak istemiyoruz. Yerel görev ölçeklendirmek, küresel görev ise mikro hizmet katmanındaki tüm ekiplere geliştirmeyi yönetmektir.
Sergey:
Size izlediğimiz yolu anlatacağım. Aslında tek bir ekip olarak çalışmaya başladık ama artık yalnız değiliz. Ben şunun savunucusuyum: Sürecin bir sahibi olmalı. Birisinin mikro hizmet geliştirme sürecini anlaması, yönetmesi, kontrol etmesi ve oluşturması gerekiyor. Kaynaklara sahip olmalı ve kaynak yönetimiyle meşgul olmalıdır.
Teknolojileri, ayrıntıları bilen ve mikro hizmetlerin nasıl oluşturulacağını anlayan bu kaynaklar, ürün ekiplerinde bulunabilir. Mobil uygulamayı yapan ürün ekibinde mikroservis platformundan kişilerin yer aldığı bir karmamız var. Oradalar ama geliştirme yöneticileriyle birlikte mikroservis platform yönetimi departmanının sürecine göre çalışıyorlar. Bu bölüm içerisinde teknolojiyle ilgilenen ayrı bir ekip bulunmaktadır. Yani ortak bir kaynak havuzunu kendi aramızda karıştırıp paylaştırıp ekiplere veriyoruz.
Aynı zamanda süreç genel, kontrollü kalır, genel teknolojik prensiplere göre, birim testlerle vb. - üstüne inşa edilen her şeyle ilerler. Ürün yaklaşımının farklı departmanlarından toplanan kaynaklar şeklinde sütunlar olabilir.
Alexander:
Sergey, aslında sürecin sahibi sensin, değil mi? Görev biriktirme listesi paylaşılıyor mu? Dağıtımından kim sorumludur?
Sergey:
Bakın: işte yine karışım. Teknolojik gelişmelere dayalı olarak oluşan bir birikim var - bu bir hikaye. Projelerden formüle edilen bir birikim var ve ürünlerden oluşan bir birikim var. Ancak hizmet ürünlerinin her birine giriş sırası veya bu hizmetin oluşturulması, bir ürün uzmanı tarafından geliştirilir. Bilgi işlem müdürlüğünde değil, özel olarak oradan çıkarıldı. Ama benim adamlarım mutlaka aynı sürece göre çalışıyorlar.
Birikmiş işlerin farklı yönlerdeki sahibi - değişikliklerin birikmiş listesi - farklı kişiler olacaktır. Teknolojik hizmetlerin bağlantısı, organizasyon ilkeleri - bunların hepsi BT'de olacak. Platform ve kaynaklar da bana ait. En üstte birikim ve işlevsel değişikliklerle ve bu anlamda mimariyle ilgili olan yer alıyor.
Diyelim ki bir işletme şöyle diyor: "Bu işlevi istiyoruz, yeni bir ürün yaratmak istiyoruz - krediyi yeniden yapılandırmak istiyoruz." Cevap veriyoruz: "Evet, yeniden yapacağız." Mimarlar şöyle diyor: “Düşünelim: mikro hizmetleri kredinin neresine yazacağız ve bunu nasıl yapacağız?” Daha sonra bunu projelere, ürünlere veya teknoloji yığınına bölüyor, ekiplere ayırıyor ve uyguluyoruz. Dahili olarak bir ürün oluşturup bu üründe mikro hizmetleri kullanmaya mı karar verdiniz? Biz diyoruz ki: "Artık sahip olduğumuz eski sistemler veya ön hat sistemleri bu mikro hizmetlere geçmeli." Mimarlar şöyle diyor: “Yani: ön saflardaki ürünlerdeki teknolojik birikimde - mikro hizmetlere geçiş. Gitmek". Ürün uzmanları veya işletme sahipleri ise ne kadar kapasitenin tahsis edildiğini, bunun ne zaman ve neden yapılacağını anlıyor.
Tartışmanın sonu, ama hepsi değil
mailto:CLOUD konferansı düzenlendi .
Ayrıca başka etkinlikler de yapıyoruz - ör. @Kubernetes Buluşması, her zaman harika konuşmacılar aradığımız yer:
- @Kubernetes'i ve diğer @Meetup haberlerini Telegram kanalımızdan takip edin
- @Meetup'lardan birinde konuşmak ister misiniz? için bir istek bırakın
Kaynak: habr.com