Büyük Teknoloji Şirketleri Neden Tescilli Çözümler Yaratmaya Takıntılı?

Merhaba! Büyük teknoloji şirketlerinin neden altyapıları için özel çözümler üretme konusunda takıntılı olduklarından bahsetmek istiyorum. Cevap açık gibi görünüyor: NIH sendromundan başka bir şey değil. Ancak bu cevap tam olmaktan çok uzak, objektiflikten bahsetmiyorum bile.

Yandex Platform Mühendisliği ekibinin CTO'suyum ve amacımız, mühendislere kod yazımından işletim hizmetlerine kadar tüm geliştirme döngüsünü daha verimli hale getirme konusunda yardımcı olmaktır. Buna süreç kolaylaştırma da dahildir: yalnızca hizmet olarak teklifler geliştirmekle kalmıyoruz, aynı zamanda bunların şirket içinde uygulanmasına da yardımcı oluyoruz. Bu, Yandex ölçeğinde işe yarar: Hizmetlerimiz şirket genelinde binlerce geliştirici tarafından kullanılmaktadır.

Geliştirme döngüsünü organize etmeye yönelik araç örnekleri

Bir sorunu çözmek için genellikle hazır olanları uygulamak yerine özel araçlar geliştiririz. Örneğin, hâlâ ekipte bir programcıyken, C++ ve Python'da niceliksel bir izleme sistemi üzerinde çalıştım ve bu sistemin on milyarlarca işlenmiş ölçüme ölçeklendirilmesine yardımcı oldum. Dolayısıyla, kendi deneyimlerime dayanarak, şirket içi araçların ortaya çıkmasına hangi motivasyonların ve gelişim yollarının yol açtığını biliyorum: Aşağıda, çözümlerimizi örnek olarak kullanarak bunların yaratılmalarının temel nedenlerini belirlemeye çalışacağım.

Hikaye #1: Yandex'in dahili bulutu

Görevi ayarlama. Dahili Çalışma Zamanı Bulutumuzun veya RTC'nin amacı, dahili kullanıcılara basit dağıtım ve trafik yönetimi araçları sağlamaktır. RTC kullanıcıları, Yandex hizmetlerini geliştiren mühendislerle aynıdır. Ve diğer şeylerin yanı sıra, oluşturdukları on binlerce uygulamayı bir yerde başlatmaları, kullanıcı isteklerini oraya göndermeleri, yükü dengelemeleri ve olaylarla ilgilenmeleri gerekiyor.

Dahili bir bulut ihtiyacı, hizmet sayısının yüzlerce olduğu ve tahsis edilen çekirdeklerin toplam sayısının yılda yüzde onlarca arttığı 2010'ların başında ortaya çıktı. Her hizmet için özel sunuculara sahip olmak aşırı derecede pahalı hale geldi ve birden fazla hizmetteki uygulamaları tek bir sunucuda çalıştırmamıza izin verecek araçlara ihtiyacımız vardı. Başlangıçta bu araçlara yönelik çeşitli gereksinimlerimiz vardı:

• İşletim kaynaklarından tasarruf etmek ve sürümler sırasındaki olay sayısını azaltmak için rutin eylemlerin otomatikleştirilmesi gerekir.
• Ayrı bir önemli görev de bulut kullanımını artırmaktı; özellikle çoğu hizmetin yükü günlük bir düzene sahip olduğundan ve bulut geceleri boşta olduğundan. O yıllarda tüm Yandex hizmetlerinin bulutta barındırılmaması ve sunucu sayısındaki sürekli artışın sorunu daha da ağırlaştırması durumu daha da karmaşık hale getirdi.
• Yandex'in geliştirme hızını doğrudan etkilediği için özelliklerin veya hata düzeltmelerinin kullanıcılara hızlı bir şekilde sunulması kritik önem taşıyordu.
• Yalnızca IPv6 desteği gereklidir: kapsüller arasında uçtan uca bağlantı sağlamak için veri merkezlerimiz yalnızca IPv6 için oluşturulmuştur, çünkü bizim ölçeğimizde IPv4 adres aralığı bizim için yeterli olmayacaktır.

Temelde Kubernetes'e ihtiyacımız vardı (ve zamanla RTC buna çok yaklaştı). Ama işin püf noktası şu: k8s yalnızca 2014'te duyurulmuştu. O zamanlar Apache Mesos vardı ama henüz emekleme aşamasındaydı.

Temel fonksiyonların uygulanması. Sorunu bir tür MVP ile çözmeye başladık; basit bir araç seti, daha çok rutin eylemleri otomatikleştiren bir dizi yapı taşına benziyordu, örneğin:

• küme kaynaklarının tahsisi;
• uygulamanın gerekli sürümünün ve çeşitli yapıların kümeye teslimi;
• uygulamanın gerekli sürümünün kümede başlatılması.

Zamanla, bu yapı taşlarını kullanarak (sürekli teslimata benzer şekilde) tam teşekküllü bir hizmet yerleşim grafiği oluşturmak mümkün hale geldi. Belirli sayıda yinelemeden sonra, 2013 yılında RTC'de çalışan hizmetleri yönetmeye yönelik bir sistem olan Nanny ortaya çıktı.

Dadı'nın bir diğer temel yönü de kaynak tüketimine dayalı uygulama yalıtımının uygulanmasıydı. Başlangıçta çeşitli hizmetlerden uygulamaları kaynak izolasyonu olmadan başlattık ve bu da çok sayıda operasyonel sorun ve olayla sonuçlandı.

O zamanlar tek hazır çözümler, geliştirmeyi durdurmuş olan LXC ve yalnızca IPv6'yı kullanamayan ve dockerd'i güncellerken tüm konteynerleri yeniden başlatarak kullanıcıyı etkilemeden dockerd'in güncellenmesini imkansız hale getiren Docker'dı. Sonuç olarak, ürünlerimizi geliştirmeye başladık. Porto 2014'ün ortalarında Linux çekirdek grubunun üstüne konteynırlaştırma sistemi. Sunuculardaki çoğu uygulama ve bazı sistem aracıları 2015 yılında zaten Porto konteynerlerine taşınmıştı.

Kullanım sorunlarını çözmek. O zamanlar dahili buluttaki kaynak yönetimi, depoya yapılan taahhütler yoluyla gerçekleştiriliyordu. Ancak bu, Yandex'in gelişimini yavaşlattı ve kullanımı artırma göreviyle çelişiyordu: sorunu çözmek için harita azaltma sistemimizi bulutlara yerleştirmemiz gerekiyordu; YTsaurus - o zamanlar yaklaşık 7 yıldır geliştirmekte olduğumuz, büyük verileri ve dağıtılmış bilgi işlemi depolamak için özel dahili sistemimiz. Dahili buluta getirilmesi gerekiyordu ama aynı zamanda kullanıcı uygulamalarıyla birlikte çalışması da gerekiyordu.

YTsaurus'u RTC'ye getirmek için bölmeleri depo taahhütleri yerine dinamik olarak yönetme yeteneği gerekiyordu. Bu nedenle 2018'de yarattık Yandex Planlayıcı , küme bilgi işlem kaynaklarını yönetmek için bir sistem. Yandex Planner, mevcut Nanny dağıtım sistemiyle entegre edilerek YTsaurus geçişinin engeli kaldırıldı ve RTC tam teşekküllü bir buluta dönüştürüldü. O zamanlar RTC'nin onbinlerce sunucusu vardı ve harita küçültme özelliğinin getirilmesiyle bu sayı önemli ölçüde arttı.

Yeni büyüyen acılar. Aynı dönemde k8s çok daha olgun bir çözüme dönüştü ve 2017'de AWS hizmetlerinden biri haline geldi. Ancak yine de tüm gereksinimlerimizi karşılamadı:

• Onbinlerce sunucunun ölçeği - bir k8 kurulumu hala bizim ölçeğimizi karşılayamıyor.
• Çift yığınlı IPv6 ve IPv4 desteği k8'lerde yalnızca 2020'de ortaya çıktı ve IPv6 bizim için başından beri kritik öneme sahipti.
• Ayrı toplu iş ve hesaplama zamanlayıcıları oluşturmaya karar verdiğimiz için ihtiyaç duyduğumuz iç içe kapsayıcılar desteği. Bu seçeneğin etkinliğini bir noktada genel planlayıcınınkiyle karşılaştırdık ve her şey için genel bir programlayıcı yapmaya çalışmamak daha kullanışlı ve karlıydı.

YTsaurus, tek bir zamanlayıcı oluşturmak yerine iç içe geçmiş Porto konteynerleri oluşturma yeteneğini aktif olarak kullandı. Elbette k8'lerde aynı ikili yığın için desteği kendimiz ekleyebiliriz. Ancak Linux çekirdeği geliştirme deneyimi, her şeyin açık kaynağa gönderilemeyeceğini gösterdi ve yeni sürümlere güncellemeyi kolaylaştırmak için yukarı akış çekirdeğindeki deltayı minimumda tutmaya çalışıyoruz.

Bugünkü çözümümüz. RTC'nin mimarisi Kubernetes'in mimarisine çok benzer. Kullanıcı, hizmetlerini, belirtilen uygulamanın nasıl ve hangi veri merkezlerinde başlatılacağını açıklayan bazı spesifikasyonlar şeklinde bildirimli olarak açıklar. Her veri merkezinin, bir yandan tüm küme nesneleri için veri tabanı, diğer yandan da kapsül zamanlayıcı görevi gören kendi Yandex Planner kurulumu vardır. Veri merkezindeki her sunucu, Yandex Planner'dan kapsül özelliklerini alan ve bunları tescilli Porto konteynerizasyon sistemimizi kullanarak başlatan bir aracıyı çalıştırır.

Şu anda RTC, 100.000'den fazla sunucuya 5 milyondan fazla çekirdek tahsis ederek on binlerce hizmeti başlattı. Hizmet özelliklerinde her gün 100.000'den fazla değişiklik yapılmaktadır.

Planlar. Ya k8'ler bizim terazimizi idare edebilirse? Özellikle k8s ekosistemi bir noktada işlevsellik açısından bizden daha iyi performans göstermeye başladığından beri. K8'lere geçip, hazır araçların sonunda ihtiyacımız olan hacmi sağlayacağını ummak daha iyi olmaz mıydı? Uygulamada, k8'ler için niş bir tüketici olmaya devam ediyoruz çünkü şirketlerin yalnızca küçük bir yüzdesi bu kadar büyük bir ölçekte faaliyet gösteriyor ve her birinin kendi kurum içi bulut çözümleri var.

Unutulmaması gereken bir diğer kritik nokta ise göç meselesidir. Temmuz 2018'e göre Gartner Çok Platformlu Uygulama Modernizasyonu İş Senaryosu Oluşturuyor Rapora göre, modern uygulamaların %90'ı 2025 yılına kadar hâlâ kullanımda olacak ve bu sistemlerin geliştirilmesine yönelik teknik borç, BT bütçelerinin %40'ından fazlasını oluşturacak. Kullanıcı hizmetlerini Yandex Planner'a taşıma deneyimimize dayanarak, bu gerçeğe yakın: 2023'te yaklaşık 100 bin çekirdek hâlâ Yandex Planner'a geçmek için sırasını bekliyordu.

2021'de geliştirme stratejimizi seçerken bir dağıtım sisteminden diğerine geçmenin ne kadara mal olacağını tahmin ettik. Yandex'in klasik k8'lere geçişi, yüzlerce adam-yıla mal olan son derece maliyetli bir iş olacaktır.

Bu kadar basit bir şekilde, böyle bir hedef koysak bile önümüzdeki 5 yıl içinde terk etmemizin mümkün olmadığı iç bulutumuzu elde etmiş olduk.

K8'lere kıyasla dahili bulut işlevselliğinin eksikliği konusunda ne yapılmalı? Uygulamada müşterilerimiz Yönetilen Kubernetes'i Yandex Cloud'da kullanabilirler. Bu seçenek öncelikli olarak katı uyumluluk gerekliliklerinin karşılanması gereken projeler için kullanılır; bu, ekiplerin küçük bir oranıdır, %1'den azdır. Yukarıda belirtilen nedenlerden dolayı nüfusun geri kalanı taşınmanın pek bir faydasını görmüyor.

Aynı zamanda k8'leri aktif olarak inceliyor ve genel kabul görmüş standartlara nasıl yaklaşabileceğimizi düşünüyoruz. Bulut önyüklemesi veya IaaC'nin tüm Yandex ölçeğinde düzenlenmesi gibi bazı görevlerde k8'leri zaten aktif olarak deniyoruz. İdeal olarak, ihtiyaçlarımıza mümkün olduğunca uygun hale getirilmiş kendi uygulamamızı sürdürürken k8s arayüzünü yeniden kullanmak isteriz. Geriye kalan tek şey bunun pratikte nasıl yapılacağını bulmaktır.

• Peki ya diğerleri? Bu makalede genel olarak büyük teknolojiyi tartıştığımız için, durumumuzun benzersiz olmadığını belirtmekte fayda var. Kontrol et Borg veya Sicim örnekler için vakalar.

Hikaye #2: tek depo

Sorunlar ve çözüm gereksinimleri . Tek depomuz Arcadia, dahili bulutumuzla aynı temel hedefi paylaşıyor: uygun geliştirme araçları sağlamak. Bu, depo söz konusu olduğunda tüm geliştirme ekosistemini içerir:

• versiyon kontrol sistemi (Arc),
• Arayüz (Arcanum),
• sistem oluştur (yaparsın),
• CI/CD (YeniCI).

Arcadia, Yandex'in dahili bulutuyla hemen hemen aynı zamanlarda ortaya çıktı. Tek deponun oluşturulmasının nedenlerinden biri, kodun Yandex'de yeniden kullanılması ihtiyacıydı. Bu, o zamanlar çeşitli yapı sistemlerinin varlığı nedeniyle sekteye uğradı. Tüm Yandex ölçeğinde çalışmak için verimli dağıtılmış yapıları destekleyen birleşik bir sistem gerekiyordu. Aynı zamanda sağlam ve kullanışlı olmalıdır.

Birleşik bir yapı sisteminin uygulanması. Tescilli make build sistemimiz, yalnızca C++ kodu için olduğu 2013 yılında piyasaya sürüldü. Yapmadan önce CMake'i kullandık, ancak hızı onun bir monorepository ölçeğine ölçeklenmesini engelliyordu. Tescilli markamız Arcadia'da çok daha hızlı çalıştı. Sorunumuzu çözebilecek başka açık kaynak seçeneği yoktu: örneğin Bazel çok daha sonra, 2015'te piyasaya sürüldü.

Sürüm kontrol sistemi ölçeklendirmesi. Yandex daha önce sürüm kontrol sistemi olarak SVN'yi kullanıyordu. SVN'nin kapasitesi büyük olmasına rağmen hâlâ sınırlıydı ve bakımı zordu. Dahası, eninde sonunda SVN'nin yetenekleri ve rahatlığıyla ilgili sınırlamalarla karşılaşacağımızın farkındaydık. Örneğin, veri havuzunun veya seçici ödemenin yalnızca gerekli kısmını indirme yeteneğini uygulamak için buluşsal yöntemler kullanıldı. Sonuç olarak 2016 yılında SVN'nin yanı sıra diğer sürüm kontrol sistemlerini de denemeye başladık.

Mercurial ilk tercihti. Ancak asıl sorunumuz hızdı. Bir buçuk yıl boyunca Mercurial'ı üretime sokmaya çalıştık ama sonuçlar hayal kırıklığı yarattı. Örneğin, sonunda FUSE'ı desteklemek için Mercurial'ın bazı kısımlarını yeniden yazmak zorunda kaldık, aksi takdirde deponun tamamını her geliştiricinin dizüstü bilgisayarına taşımak zorunda kalırdık.

Sonunda, sıfırdan şirket içi bir çözüm yazmanın daha ucuz olduğu ortaya çıktı ve 2019'da, Arcadia kullanıcıları için git benzeri bir UX'e sahip yeni bir sürüm kontrol sistemi olan Arc ortaya çıktı. Arc'ın temeli seçici ödeme yerine FUSE'dir (kullanıcı alanındaki dosya sistemi). Ayrıca YDB, Mercurial ile karşılaştırıldığında Arc'ın çalışmasını büyük ölçüde kolaylaştıran ölçeklenebilir bir veritabanı görevi görür.

Bize sık sık neden git kullanmadığımız soruluyor. Çünkü aynı zamanda ölçek ve işlevsellik sınırlamaları da vardır: Arcadia trunk'ı yalnızca git'e aktarırsak, bu ölçekte git durumu dakikalar alacaktır. Aynı zamanda, git üzerine kurulu istikrarlı bir FUSE uygulaması da yoktu: Git için VFS artık geliştirilmiyor ve EdenFS sonunda Sapling'e dönüştürüldü, ancak bu çok daha sonra gerçekleşti.

Çözümün mevcut durumu ve geleceğe yönelik planları. Geliştirmeye başlamak için, dahili bir kullanıcının tek depomuzda bir klasör oluşturması, kod yazması ve derleme bildirimini ekleyerek uygulamasını nasıl oluşturacağını söylemesi yeterlidir. Sonuç olarak kullanıcı çekme isteklerini, CI yapılandırmasını ve şirketteki herhangi bir kodu yeniden kullanma olanağını alır.

Ölçek açısından, trunk şu anda 10 milyon dosya içeriyor, deponun tamamı 2 TiB'yi aşıyor ve her hafta 30 binden fazla taahhüt yapılıyor.

Sonuç olarak oluşturduğumuz ekosistemde birçok bileşeni sıfırdan oluşturmamız gerekiyor. Ancak artık küresel standartlara uyum yolunda ilerlemektedir. Örneğin Arc, önceden tanımlanmış bir dizi proje için Git ile çalışmayı destekler.

• Peki ya diğerleri? Yine genel olarak büyük teknolojiye bakarsanız, örnek olarak şunlara dikkat etmelisiniz: Fidan Ve Piper .

Bu hikayelerin ortak noktası nedir

Peki neden büyük teknoloji şirketleri kendi çözümlerini icat etmek zorunda kalıyor ve neden bunların yerine genel kabul görmüş standartlara uyan çözümler getirilemiyor?

1. Yenilik. Büyük şirketlerin sıklıkla gelecekte sıradan hale gelecek sorunlara çözüm geliştirmeleri gerekiyor. Pazar standardı olma potansiyeline sahip yenilikçi çözümler bu şekilde ortaya çıkabilir.

   
   

   Bir firmanın çözdüğü bir problemin firmanın kendisi dışında başka birisiyle karşı karşıya kalması her zaman söz konusu değildir. Bazen büyük teknolojinin belirli bir sorunla ilgili deneyimi, tamamen farklı bir gelişim yolu izleyerek tüm sektörün bu sorundan kaçınmasına yardımcı olur. Pazarın gelişimini tahmin etmek her zaman mümkün değildir ve sonuç olarak farklı özel çözüm örnekleri çok farklı sonuçlara yol açmıştır.

   
   

   ClickHouse, çevrimiçi analitik işleme (OLAP) alanını büyük ölçüde zenginleştiren, gerçekten başarılı, yenilikçi bir projenin örneğidir. Ancak bu her proje için geçerli değildir. Açık kaynaklı bir proje olarak başlayan Porto, çeşitli nedenlerden dolayı ilgi çekmeyi başaramadı. Her ne kadar iç içe kapsayıcılar oluşturma yeteneği gibi bazı özellikleri benzersiz kalsa da.

   
   

2. Ölçek. Bu nokta bazı açılardan bir öncekine benziyor çünkü her şirket ölçeklenebilirlik sorunuyla karşı karşıya değil. 640 kbyte'ın herkese fazlasıyla yettiği bir dönem vardı, değil mi?

   
   

   Aslında sistem yükünün katlanarak artması, Arcadia'nın ve dahili bulutun gelişmesinin en önemli nedenlerinden biriydi. Arc ve Yandex Planner bu nedenle geliştirildi. Arc, kullanıcıların bir bagajda on milyonlarca dosya içeren bir tek depoyla zorluk yaşamadan çalışmasına olanak tanıyan kullanıcı dostu bir VCS ihtiyacına yanıt olarak oluşturuldu. Yandex Planner, onbinlerce düğüm ve milyonlarca kapsülden oluşan kümelerle etkili bir şekilde çalışma ihtiyacına yanıt olarak oluşturuldu.

   
   

   Kamu araçlarının ölçeklendirme sorunları devam ediyor (sonuçta bu nispeten nadir bir senaryo ve buna yatırım yapmak çoğu zaman kârsız oluyor).

   
   

3. Eylemsizlik. Bir şirket içindeki bir sorunu çözen şirket içi bir araç düşünün. Bu aracı aktif olarak kullanan bir şirket, kaynaklarını onu ihtiyaçlarına göre daha iyi uyarlamaya ayıracak ve sonunda onu oldukça uzmanlaşmış bir araca dönüştürecektir. Bu süreç yıllarca sürebilir.

   
   

   Şimdi, bir noktada söz konusu sorunun çözümü için evrensel olarak kabul edilmiş bir standardın ortaya çıkma olasılığını düşünün. Bu durumda uzmanlaşma, şirket içi çözüme karar vermede hâlâ önemli bir faktör olabilir. Sistem oluşturmayı düşünün. Google'dan Bazel olmasına rağmen Arcadia'da markanızı kullanıyoruz. Kavramsal olarak benzerler, ancak ayrıntılara indiğinizde birçok önemli senaryo farklı şekilde uygulanıyor çünkü her iş yükünün yük düzenleri büyük ölçüde farklı olabiliyor. Sonuç olarak, genel kabul görmüş yeni bir standardın özelleştirilmesi için zaten harcanmış olan kaynakların neredeyse kesinlikle yeniden yatırılması gerekecektir.

   
   

4. Göçler. Önceki bölümde projenin kullanıcılara uyarlanması konusuna değinildiyse, şimdi de kullanıcıların kendilerinin taşınması konusuna değinelim. Bana göre teknolojide adlandırmadan sonraki en önemli sorun göç olarak adlandırılmalıdır. Halihazırda şirket içi bir şirket aracımız olduğunu varsayarsak ve onu standartlaştırılmış bir araçla değiştirmek istersek, kaçınılmaz olarak geçişlere ihtiyaç duyacağız.

   
   

   Dahili bir bulut geliştirme deneyimimizden birçok geçiş örneğini biliyoruz. Büyük ölçekli geçişler zaman alır, bu nedenle her iki aracın da uzun süreler boyunca aynı anda desteklenmesi gerekir. Bu süreç çok sayıda kullanıcıyı içeriyorsa yönetim sorunları kaçınılmazdır. Kullanıcı katılımı olmadan geçiş yapmaya çalışmak kesinlikle faydalıdır, ancak bu her zaman mümkün değildir.

   
   

5. İş devamlılığı. Doğrusunu söylemek gerekirse bu nokta son zamanlarda yeterince önem kazandı. Daha önce çok daha az sayıda şirket, satıcı bağımlılığıyla ilgili endişeler nedeniyle bunu ciddiye alıyordu. Kritik süreçleri, işbirliğini istediği zaman sonlandırabilecek bir satıcıya güvenmek risklidir. JetBrains, IDE'lerinin kullanımını belirli şirketlerle sınırlandırarak bunun en iyi örneğidir. Bir diğer örnek ise Rusya merkezli kullanıcı hesaplarını askıya almaya başlayan Github Enterprise'dır.

   
   

   Şirket içi çözümler genellikle bu soruna karşı bağışıktır. Bir yandan hala açık kaynaklı çözümler var. Öte yandan, açık kaynak modelinin tüm yol boyunca yanınızda olacağının garantisi yok: örneğin Facebook'un Hadoop MapReduce planlama yazılımına yönelik kendi bünyesinde geliştirdiği iyileştirme olan Corona, taahhüt edilememesi nedeniyle ilk etapta ortaya çıktı. Hadoop'u yukarı yönde ölçeklendirmek için gereken yamalar.

   
   

   Aynı zamanda konunun hukuki yönü de açık kaynağı etkiliyor: örneğin, golang veya k8'lerdeki taahhütler bir CLA'nın imzalanmasını gerektiriyor. Bu sorun olmaya devam edecek mi?

   
   

6. NIH. Evet, objektif nedenlerin yanı sıra alınan kararların pragmatik olmaması da mümkündür. Bu, en iyi haliyle NIH sendromudur.

   
   

   Örneğin, toplu işlemin bilgi işlem üzerindeki etkisini ortadan kaldırmak amacıyla Linux çekirdeğinde kendi zamanlayıcımızı oluşturmaya çalıştık. Pratikte bundan iyi bir şey çıkmadı; Linux çekirdeğinin mevcut yetenekleriyle yetinilebilirdi. Bununla birlikte, işçilik maliyetleri ne kadar yüksek olursa, sorunun detaylandırılması ve çözülmesi için o kadar fazla çaba harcanır ve NIH sendromundan muzdarip olma olasılığı da o kadar düşük olur.

   
   Özetlemek gerekirse , gördüğünüz gibi büyük şirketler için şirket içi çözümlere sıklıkla ihtiyaç duyulmaktadır. Bunların çoğunluğu gelecekte henüz olgunlaşmamış birleşik küresel standart çözümlerle birleşecek, geri kalanı ise tarih olacak. Her durumda, özel bir çözüm ile hazır bir çözüm arasında karar vermek, öncelikle bağlamı anlamadan ve böyle bir projenin maliyetini tahmin etmeden cevaplanamayacak zor bir soru olmaya devam ediyor.