Arda Çetinkaya Yazılım ve arada kendim ile ilgili saçmaladıklarım…

Dağıtık SistemlerBulut bilişim kavramı son bir kaç yılın, hatta gelecek bir kaç yılın da en önemli yazılım kavramlarından bir tanesi. Tanışma fırsatı elde etmediyseniz, çok yakında yollarınız kesişecektir zaten. Ama biraz öncesine gidip, “cloud-computing“(bulut bilişim)’in de bir parçası hatta belki temeli olarak yorumlanabilecek “distributed system“den (dağıtık sistemler) bahsetmek istiyorum. Cloud, biraz daha pazarlama üzerine ortaya çıkan bir kavram olduğu için, temelinde yatan “dağıtık sistemler” kavramlarının bazen atlandığını düşünüyorum. Bundan dolayı, eski konulara gidip biraz daha temellerden bahsetmek ihtiyacını hissettim…

Dağıtık sistem…

Ortak bir amaç için, çeşitli iletişim protokolleri ile birbirleri ile iletişim halinde olan birden fazla yazılım sisteminin oluşturduğu sistemlere dağıtık sistemler diyoruz. Basit olması ve daha kolay anlaşılması adına, multi-player bilgisayar oyunlarını örnek verebilirim. Tek bir bilgisayarda bir oyunu, aynı anda 100 kişi oynamaya çalıştığınızı düşünün…Yemez, ayy pardon olmaz… :) Bunun  için ne yeriniz, ne işlem gücünüz ne de zamanınız yeterli olacaktır. Ama bir çok bilgisayar ile, farklı lokasyonlardan yüzlerce kişi ile, büyük bir işlem gücü ile oyunun en zor bölümünü daha rahat bir şekilde geçebilirsiniz.

Bir dağıtık sistem anatomisi…

Dağıtık sistemler ile, pratikte tek bir işlem gücüyle yapılabilecek işleri daha büyük ölçekte yapabilmek amaçlanır. Geliştirilen yazılım sistemlerinin belli bir süreden sonra çeşitli problemlere çözüm sağlayamaması, bu yazılım sistemlerini değiştirmeyi ya da genişletmeyi gerektirir. En basitinden CPU, RAM ve disk boyutu arttırma gibi fiziksel değişiklikleri düşünebiliriz. Hem ekonomik, hem de teknolojik bazı kısıtlamalardan dolayı ne yazık ki bir bilgisayara sınırsız CPU ya da hafıza eklemeniz mümkün değil. Teknolojik kısıtlarına gelene kadar, ekonomik olarak zaten herkes zorlanacaktır.

Dağıtık Sistemler

Zamanla birden fazla kullanıcı ile de problemlere çözüm sağlama ihtiyacımızdan dolayı, belli bir ağ içerisinde birbiri ile iletişim halinde olan bilgisayarları devreye almaya başlarız. İşte bu noktada artık merkezi sistemimizi dağıtmaya başlamış oluyoruz. Yeni problemlere de merhaba diyoruz tabi ki. Bu problemlere sonradan geleceğim…Şimdilik devam edelim.

Birbiri ile iletişimde olan farklı bilgisayarların iletişimlerini sağlıklı yapabilmesi için, belli protokoller radarımıza girer. Sistemimizi buna göre geliştiririz. Bazen bu protokoller yeterli olmaz ya da farklı ihtiyaçlar ortaya çıkar, dolayısıyla farklı yeni protokoller ile de iletişim sağlayacak ara katmanlar yapmamız gerekir. Fazla bileşen ve farklı sistemler olunca güvenlik konuları da ortaya çıkar. Hem iletişimin, hem de yapılan işlemlerin güvenilir olmasını sağlamak birden öncelikli olur.

Bir bakmışız, sistemle büyüyen ve gelişen iş ihtiyaçları artık farklı coğrafyalarda da sistemin 7/24 çalışmasını gerektirir. Farklı coğrafyalarda, aynı verinin güvenli bir şekilde iletilmesi ve işlenmesi gibi bir durum ortaya çıkar. Bütün bunları yaparken de, bu ayrı sistemlerin hata durumlarını yönetebileceğimiz bir senaryomuz ve hatta belli ölçekte yedek ikinci sistem ihtiyaçlarımız ortaya çıkar…

Basit olarak neden dağıtık sistemlere ihtiyaçımız olduğu ortaya çıktı aslında. Biraz daha canlanması adına havayolu yönetim sistemleri, multi-player bilgisayar oyunları, tedarik zinciri sistemleri ve ödeme sistemleri günümüzde hepimizin karşısına çıkan dağıtık sistem örnekleri olarak düşünülebilir. Hatta son zamanlarda oldukça popüler olan yazılım mimari stili olan Microservices yaklaşımı da, bu dağıtık sistem modellerinden biridir. Neyse…Şimdi tekrar oraya girmeyelim.

Karakteristik özellikleri…

Dağıtık sistemler ortaya çıktıkça belli özellikleri sağlamak ile yükümlü olurlar. Bu karakteristik özellikleri sağlıyor olmak, dağıtık sistemlerin en büyük ve en zor problemidir.  Önce bu özelliklere bir bakalım, sonra gerçekten sağlamak mümkün mü bakarız…

  • Yüksek Erişebilirlik: Dağıtık sistemlerin, erişebilirliğinin olabildiğince yüksek olması beklenir. Başarısız bir işlem olsa bile, işlemi tetikleyen kaynağın mutlaka sisteme bir şekilde erişimi olması beklenir.
  • Güvenlik: Dağıtık sistemlerde, işlemlere ve veriye erişim yetkilendirilir.
  • Performans: Dağıtık sistemlerin, kendi performanslarının farkında olması beklenir. Belli sistem yoğunluklarında alacağı aksiyonların belirli olması sistem tasarımında önemlidir.
  • Açıklık: Dağıtık sistemler genişletilmeye açık olmalıdır. Sisteme kolaylıkla alt sistem bileşenleri eklenebilmelidir.
  • Ölçeklenebilirlik: Dağıtık sistemler kaynak kullanımı konusunda kolayca ölçeklenebilmelidir. Kaynak kullanımına göre sistemin verimli çalışmaya devam etmesi bir şekilde sağlanmalıdır.
  • Tutarlılık: Sistemin tutarlı olması beklenir. Aynı anda, aynı veri kaynağına erişen sistemlerin uyumlu ve tutarlı çalışması gerekmektedir.

Bu özelliklere sahip olmak ve bunları belli bir kalite düzeyinde sağlamak oldukça zor. Hatta hepsinin birden sağlanamayacağına dair teoriler olsa da sonradan farklı yaklaşımlarda olmuştur. Eric Brewer’ın CAP teorisi ve sonrasındaki yaklaşımına göz atmanızı tavsiye ederim. (CAP Twelve Years Later: How the “Rules” Have Changed)

Dağıtık sistemlerin bu karakteristik özelliklerinden dolayı, çeşitli programlama yaklaşımları, prensipler ve kalıplar bu sistem tasarımlarında kullanılmaktadır. SOA prensipleri, mesajlaşma kalıpları, kuyruklama alt yapıları, senkron ve asenkron programlama modelleri dağıtık sistem programlama yaklaşımlarında temel olarak tercih edilen bir kaç kavramın başında gelir.  Tabi sistemin amacına göre başka farklı kavramlar da gündeminize girecektir. “Service Bus”lar, “Message Broker”lar falan filan…

Dağıtık sistem tasarlarken ya da bir şekilde içinde bir geliştirme yaparken, yukarıda bahsetmiş olduğum özellikleri sağlamanın da vermiş olduğu bir kaç yanılgıya düşeriz. Peter Deutsch, zamanında bunları çok güzel tanımlamış ve “The 8 fallacies of distributed systems” diye yazmış. Bir sonraki yazılarda bu yanılgıların ne olduğunu ve bu yanılgılardan nasıl kurtulabiliriz bunları anlatmaya çalışacağım…Şimdilik bu kadar. Fazla dağıtmayın… :)

Az biraz beni takip edenler, özellikle Twitter ve Instagram‘dan, yaklaşık 2 yıldır yelken ile haşır neşir olmaya çalıştığımı hatırlarlar. Hatta geçen sene yine bu zamanlar  “Büyük Yarış” yazısını ile kesinlikle unutamayacağım bir yelken yarışından bahsetmiştim… Bu sene de, yine kesinlikle unutamayacağım, unutamayacağım gibi; ileride, yaşlanınca dönüp dönüp aynı şeyi anlatacağım bir yarış haftasında buldum kendimi.

Ülkenin kara suları yetmedi, biz de Garanti Bankası Yelken Kulübü olarak İngiltere’ye Cowes Week‘e gittik. Cowes Week,  1826‘dan beri düzenlenen dünyanın en eski yelken yarışlarından biri.  Günde 40’a yakın yarış, 1000 küsur yelkenli tekne ve binlerce yelkenci… Toplam 7 gün aralıksız, gün boyu yarışlar ile oldukça efor da gerektiren bir yarış. Coğrafi olarak gerçekleştiği yer, İngiltere’nin güneyinde Isle Of Wight adasında Cowes kasabasında, denizde de Solent bölgesinde… Rüzgarından çok akıntıları ile meşhur bir yer. Rüzgar problemi yetmezmiş gibi bir de akıntı derdi var yani… Kısacası uzun süre yelken ile uğraşanlar için bile oldukça heyecan verici. Benim gibi 2 yıldır uğraşmaya çalışan biri için ise uzaya çıkmak gibi birşey…Ki cidden öyle oldu…

 

IMG_1643

DirekYelken takımımızda daha önce, 2012’de yine bir Cowes Week tecrübesi olduğu için, hazırlanma sürecim düşündüğümden daha rahat oldu. İlk bu yarışa katılacağımız belli olduğu zaman, görev dağılımı yaptığımızda, “ahaaaa s.çtık” dedim. Daha önce hiç bilmediğim bir teknede, daha önce hiç yapmadığım bir görevle karşı karşıya kalmıştım… Bowman, bizdeki adı “Başüstü Adamı“.  Ama İngiltere’ye gidiyoruz ya, gazım… Her türlü atraksiyona açığım. Yemişim baş üstünü… Yarışacağımız teknenin aynısını burada bulma şansını elde edip, bir kaç antreman yapma şansımız oldu. Takım arkadaşlarımın desteği ve yardımları ile beni nelerin beklediğini önceden az çok kestirebildim. Burdan tekrar hepsine bir daha teşekkür edim…

Marina

Yarışlar başlamadan 1 gün önceden adaya gittik ve yarışmak için kiraladığımız tekneyi aldık. Yol yorgunluğu falan dinlemeden, hemen bir tekneyi tanıyalım turu ile son antremanımızı yaptık.  Ortamın verdiği heyecan ile çok iyi bir antreman olmasa da, yarına hazırdık…

VOROrtamın verdiği heyecan diyorum, çünkü Cowes kasabası hazırlıklarını çoktan bitirmiş. Kasaba yarış haftasından dolayı oldukça kalabalıktı. Bizim teknenin olduğu marinada yüzlerce tekne, denizde de bir o kadar tekne… Kasabadaki yelken dükkanları, restoranlar, kafeler ve organizasyon firması çeşitli alanlar ile hazırlıklarını bitirmiş tam bir festival havası oluşturmuşlar. Yarış için gelen binlerce insan da olunca, insan gerçekten heyecanlanıyor.Gelen ekipler de oldukça profesyonel, ünlü yelkencilerden ve teknelerden oluşan ekipler. Ortam bayaa ciddi yani… Bu seneki Volvo Ocean Race yarışından kadınlar takımı Team SCA, Donfeng, dünyaca ünlü yelkenci Alex Thomson ve benim daha bilmediğim yüzlerce profesyonel takım ve kişi…Ne işim var lan ben burada….

 

Alan

İlk gün gelip çattığında çeşit çeşit tekne, hepsi kendi sınıfında yarışmaya hazır; Start çizgilerine doğru sabahtan yol alıyor. Gün içinde farklı sınıflar için farklı start’lar ile birden fazla yarış var. Ve bu yarışların rotası, start’dan 10-15 dakika önce telsiz ve sms ile paylaşılıyor. Ahaaa da başka bir heyecan…Nereye gideceğiz ulan…

Yarış

İlk gün heyecanı ile ilk yarışımızı oldukça güzel bir havada yaptık. Problemsiz ve güzel bir yarış oldu. Hem yarış havasını soluduk, filodaki rakiplerimizi tanıdık, hem de tekneye alıştık… Ben mi?

Kendi adıma ilk günü atlattıktan sonra oldukça rahatladım. Problemsiz ve rahat bir yarış oldu benim için. A2 balonu donat, sancaktan balon indireceğiz,  yok iskeledeki iskotayı al, izbarço at, kavançaya hazırlan, balon mandarına dikkat et derken temel şeyleri oturtmuştum. Haaa 7 gün boyunca, yapmadım hata… Tabi ki yaptım, hem de en güzellerini yaptım. Ama öğrendim… Bu açıdan da bu yarış haftası benim adıma çok anlamlı oldu. Yelkende yarış atmosferinde en zevkli pozisyonun baş üstü pozisyonu olduğunu düşünüyorum. Neyse “lessons learned” yapmayacağım size.

Devam

Windows 10 ile beraber, Microsoft yeni bir browser duyurdu bildiğiniz üzere. Önceleri Project Spartan kod adı ile anılan daha sonra resmi olarak Microsoft Edge ismini alan bu browser, Windows 10’nun en çok merak edilen uygulamalarından biri. Dolayısıyla en çok konuşulan, bundan dolayı da en çok yanlış anlaşılmaya sebep olan konusu… Bakalım bizi neler bekliyor…

Microsoft bu yeni browser(Microsoft Edge) ile gerçekten Internet Explorer’ı öldürüyor mu?

Bu sorunun cevabı, şimdilik hayır. Windows 10 ile beraber Internet Explorer kullanmaya devam edebileceğiz. Yani basitçe Windows 10’da Microsoft’un desteklediği iki browser olacak.

Internet Explorer 11Internet Explorer 11, uygulamaların uyumluluk gereksiniminden dolayı bir süre daha ortalıkta olacak. 2016’nın Ocak ayından sonra IE 11 dışındaki tüm diğer versiyonlara destek kalkacak. 2018’den sonra da IE 11’e olan destek kalkacak. Ama “extended” olarak adlandırılan destek 2023’e kadar devam edecek. Sadece güvenlik yamaları ile güncellenecek IE 11, yeni özellikler ile zenginleştirilmeyecek. Internet Explorer’ın hala yaşayacak olmasının sebebi de, hali hazırda kurumsal tarafta olan uygulama uyumluluğu ve diğer Windows sürümlerinin yaşayacak olması.

Peki bu “Microsoft Edge” ne?

Microsoft EdgeEdge kavramı aslında, HTML 5, ES6, CSS 3.0 ile farklılaşan web teknolojilerinden ortaya çıkan bir uyumluluk kavramı. Internet Explorer’ın güncel versiyonlarında, “document mode” kavramından da hatırlayanlar ya da bilenler olacaktır. Windows 10 ile beraber, bu yeni nesil standartlar artık varsayılan özellikler olarak Microsoft Edge tarayıcısı ile özerkliğini kazanıyor. Farklı bir alt yapı ile çalışan Microsoft Edge tarayıcısı, Windows 10 ile beraber Microsoft’un yeni standart tarayıcısı olacak.

Biraz daha derinlere inelim… Internet Explorer, MSHTML olarak adlandırılan bir görüntüleme motoruna sahip. Kısaca IE’deki tüm alt yapının adı MSHTML(Trident diye de biliniyor). Microsoft Edge ile beraber, bu alt yapı ciddi bir şekilde yeniden düzenlenip/yazılıp EdgeHTML olarak adlandırılıyor. Bu alt yapı, güncel tüm web standartlarını destekleyecek şekilde geliştirildiği için yeni nesil web uygulamaları için doğal olarak daha başarılı.

EdgeHtml

Internet Explorer’da olan MSHTML, kısmen de olsa Edge modu ile yeni nesil uygulamalara destek verebilmekte. Ama artık eski bir kod tabanı olduğundan, sürekli gelişen,yeni standartlara destek olması zor. Bundan dolayı da Internet Explorer’ın edge modu, Windows 10’daki Microsoft Edge ile aynı denklikte değil. Yani basitçe, Windows 10’da, Internet Explorer 11’i edge modunda kullanmak ile Microsoft Edge tarayıcısını kullanmak aynı şey değil.

Internet Explorer ve Microsoft Edge arasındaki en büyük farklılıklardan bir tanesi de Silverlight desteği. Microsoft Edge’de Silverlight desteği olmayacak. Dolayısıyla eğer Silverlight’a hala yatırım yapıyorsanız, bir kere daha düşünün.

Kısacası Microsoft Edge, Windows 10’nun karakteristik özelliklerine ve yeni nesil web standartlarına uygun ve bunları temel alarak geliştirilmiş bir tarayıcı. Standart internet tarayıcılarından farklı olarak sunduğu fonksiyonlar ile Windows 10’nun en önemli uygulaması olduğunu düşünüyorum. Tarayıcı rekabetine yeni bir soluk getireceği kesin. Ama ne yazık ki bu rekabet, bize, web uygulamaları geliştirenlere, tasarımcılara vs. yeni problemler yaratacak, benden söylemesi :)

Şimdilik bu kadar. Umarım biraz netleşmesi adına faydalı olmuştur. Bakalım ilerleyen zamanlarda daha neler olacak…

Bazı ülkeler vardır, gitmek isterseniz ama hiç bir zaman önceliği yoktur…3-5 fotoğraf görünce gaza gelirsiniz, ama yurt dışı gezi fırsatı çıktığında planlarınız dahilinde aklınıza bile gelmez. Norveç, işte benim için böyle bir ülkeydi.

Bu yazıyı yazarken, hala Oslo’dayım…Bir kaç gün sonra dönüp, dönünce sakin kafayla yazarım diyordum ki, “sakinliğin” ülkesine gelmişim zaten, daha ne sakin kafası olacak diyerekten şimdiden bir şeyler yazmak istedim. Sıcak sıcak, taze taze… Oslo ile ilgili de bir şeyler yazacağım ama o sonra… Şimdi sadece bir gece kaldığım, Norveç’in ikinci büyük şehri Bergen’e gidelim…

Bergen, Norveç’in ikinci büyük şehri olmasından daha çok, Norveç’in meşhur fiyortlarına(fjord) kapı niteliği taşıdığı için turizm açısından baya popüler. Cumartesi öğlene doğru Oslo’ya inip, trenle Bergen’e gidip, bir gece orada kaldıktan sonra, ertesi akşam tekrar Oslo’ya dönmek şeklinde bir plan yaptım. Oslo’dan Bergen’e trenle gitmek turisti turist yapan 10 maddeden biri olduğu için, 7 saatlik yolculuk ilk başta gözüme yorucu gelse de, tren biletlerimi önceden alıp, hazırlıklarımı tamamladım. Gerçekten mutlaka yapılması gereken bir atraksiyonmuş… Hayatımda geçirdiğim en güzel yolculuktu diyebilirim. Siz de yapın, yaptırın. Yazının sonunda teknik ayrıntılara gireceğim…Biraz sabır.

IMG_1282 IMG_1306

Coğrafya dersi niteliğinde, dağ,bayır,çayır,çimen eşliğinde, ciddi anlamda doğanın içinde seyahat ettiğiniz bir yolculuk sizi bekliyor. Oslo’dan uzaklaşmaya başladığınız andan itibaren, bütün yol boyunca hiç sıkılmadan dışarıyı izleyebilirsiniz. Özellikle yolculuğun sonlarına doğru iş iyice çığrından çıkıyor… Eğer zamanınızı ayarlayabilirseniz, Myrdal istasyonunda inip, Flam treni ile fiyortları tren ile de gezebilirsiniz. Ama açıkcası daha sonra tekrar Bergen’e dönmek sıkıntı olacaktır. Otobüsle falan uğraşmanız gerekecek, o yüzden boşverin…Bergen’de bir gece geçirdikten sonra, ertesi gün turla yapmanız daha sağlıklı olacaktır.

Ben bu kısmını otobüsle yapmak durumunda kaldım. Tren hatlarındaki bakımdan dolayı, böyle bir şeye yönelmekten başka şansım yoktu. O yüzden önceden ayarlamanızda fayda var. Neyse geldik zaten Bergen’e…

Bergen

Bergen, Norveç’in ikinci büyük şehri ama hiç öyle bir hissiyat vermiyor açıkcası. Oldukça küçük, kendi halinde, sakin bir şehir. Bütün şehri yürüyerek, yarım günde dolaşabilirsiniz. Norveç’in doğasına giriş için bir kapı niteliğinde olduğu için ikinci büyük şehri olmuş kendiliğinden bence. Haziran dönemi, daha doğrusu yaz dönemi giderseniz Norveç’de günler ciddi anlamda uzun. Bergen’e vardığımda saat akşam 10.30 civarıydı, ama oldukça aydınlık ve güneşli bir hava beni bekliyordu. “Yılın 260 günü yağış olur” gibi bir bilgiyle vardığım için şehre, biraz şaşırdım, ve sevindim…Akşamın geç saati olmasına rağmen kendi çapında bir hareketi var. Ama güneşin durumunu düşünce, insan daha fazla bir canlılık bekliyor açıkcası. Cumartesi olmasına rağmen, beklediğim hareketi göremedim. Kuzey ülkesi işte…

IMG_1398

Sözde balık pazarı…

Ertesi gün dönüş saatim ile katılmayı düşündüğüm gezilerin zamanı risk yarattığından, şehirde kalıp, şehri gezmeyi tercih ettim. İlk başta biraz pişman olsamda, sonradan açıkcası iyiki şehirde kalmışım dedim. Dediğim gibi şehir oldukça küçük ve yarım günde çok rahatlıkla gezilebiliniyor. Mutlaka görülmesi, gidilmesi gereken müzemsi bir yeri de yok açıkcası, yani bence… Yok ben her yeri gezeceğim derseniz, bir kalesi(tabi ki) ve bir akvaryumu var gezilebilecek. Liman kenti olduğu için, olmazsa olmazı balık pazarı mevcut.

IMG_1396

Eski tahta evler

Bergen çok eskiden büyük bir yangın geçirmiş ve bir çok ev yanmış. Eski evlerden ve mimarisinden çok küçük bir kısım kalmış. Direkt şehir merkezinde, yan yana renkli evler zaten hemen dikkatinizi çekecektir. İçlerine ve ara sokaklarına girebiliyorsunuz belli saatler arası. Çok ilginç olmasa da, görmekte fayda var. Evlerin önünde oturup bir şeyler içmek daha cazip gelebilir ama benden söylemesi.

Olmazsa olmazı dedim balık pazarı ile ilgili, ama açıkcası cidden olmazsa olurmuş. Küçücük bir yer. Pazar kısmından çok yeme kısmı ön planda. Hemen orada alıp, pişirtip yiyebiliyorsunuz. Bilimum kabuklu şey, somon ve balina eti sizi bekliyor. Buraya kadar gelip, yemeden gitmek olmaz(mış)…Yiyin, özellikle balina etini deneyin derim.

Bergen’nin etrafı dağlar ile çevrili. Dolayısıyla etrafında gezecek bir çok yer var. Çeşitli yürüyüş turları falan düzenlenmekte. Şehir merkezinde, kocaman bir turist info’su mevcut. Yapabileceğiniz her türlü aktivite hakkında geniş bilgiyi bulabilirsiniz, zaman konusunda sıkıntınız yoksa değerlendirin derim.

IMG_1355IMG_1382

Fløibanen yani bir feniküler ile şehrin merkezinden, bu dağlardan birine, Floyen’e çıkmanız mümkün. Önünde biraz sıra oluyor ama gözününü korkutmasın. Hızlı ilerliyor… Sadece yukarı çıkış için bilet alın. İnerken yürürsünüz. 1 saat kadar sürüyor iniş ama oldukça keyifli. Floyen’e çıkınca, şahane bir manzara sizi bekliyor. Bütün Bergen’i ayağınız altına alabiliyorsunuz… Floyen’nin daha güzel yanı, içerileri doğru yürüyüş yollarının olması. Ormanın içinde güzel bir yürüyüş yapabilirsiniz, yapın da zaten mutlaka. Kaybolurum diye korkmayın, kaybolmazsınız… Olmadı, insanları takip edin…

IMG_1367

Panoramik…

Bergen’den dönüşü yine trenle yapabilirsiniz ama önceden uçak bileti ayarlayabilirseniz, Norwegian Airlines’ı tavsiye ederim, 1 saatlik uçak yolculuğu ile dönüşünüzü yapabilirsiniz.

Şimdilik bu kadar, Oslo’da görüşmek üzere…

Özet
  • Oslo-Bergen arası tren yolculuğu olmazsa olmaz…Mutlaka yapın ama önceden alın biletleri. NSB’nin sitesinden almanız mümkün. Alırken bileti, “NSB komfort” sınıfından alın. Ekstra küçük bir miktar daha fazla veriyorsunuz, ama yol boyunca ücretsiz çay-kahve imkanı ve internet-elektrik hizmeti olarak geri dönüyor. Uzun yol, lazım olur…
  • Bergen’e gitmeden önce buradan “Norway in a nutshell” turundan alın. Hem tren olayını halletmiş, hem de fiyord turunu halletmiş olursunuz.
  • Fiyord turunu, Bergen’nin şehir merkezinden de yapabilirsiniz. Ama sabah 8.30 gibi var. Uzun sürdüğü için bu kadar erken ve bir tane var. O yüzden erken kalkmanız gerekmekte. Bilet konusunda da riskli olabilir.
  • Daha kısa fiyord turları da mevcut, turist information binasından saatleri ve ayrıntıları öğrenebiliyorsunuz.
  • Norveç genel olarak pahalı bir ülke, Bergen pahalı yani…
  • Yemek konusunda bir sürü alternatif var. Ama akşam 10.30-11.00’den sonra mutfağı açık olan çok fazla yer kalmıyor. Havanın geç kararıyor olmasına sakın aldanmayın.
  • Balık pazarı kılıklı yerde mutlaka bir şeyler yiyin…Ama martılara dikkat edin, tabağınızdan gözünüzü ayırdığınız an dalıyorlar…

 

Uzun zamandır Mikroservisler(Microservices) ile ilgili bir şeyler karalama niyetindeydim. Bu zamana kısmetmiş… Açıkcası,  mikroservislerin ne olduğunu, zaten internette kolaylıkla bulabileceğiniz kavramlardan bahsederek anlatmak istemiyorum.  O yüzden biraz daha örnekler üzerinden, canlandırabileceğiz şekilde, bir kaç özelliğinden bahsederek anlatmaya çalışacağım… Öncesinde geçen sene yapmış olduğum sunuma da göz atabilirsiniz.

Mikroservis kavramı, ilk konuşulmaya başladığı zaman servis odaklı mimari(SOA) için alternatif bir mimari model olarak yorumlandı. Ancak kesinlikle SOA’ya alternatif bir model ya da yaklaşım değil. Bunun altını özellikle çizmek isterim. Mikroservisleri, SOA mimarisinin karmaşıklığını, pratikleştiren ve yönetimini kolaylaştıran bir kavram olarak yorumlayabiliriz.

micro-service-architecture

Mikroservisler(Microservices), SOA mimarisi ile uygulama geliştirmek için tercih edilebilecek bir yaklaşım, bir mimari stil…

Burada önemli olan kelime “tercih“.  İhtiyaçlar doğrultusunda, getirilerini ve götürülerini ölçüp, biçip tercih edilmeli. Açıkcası mikroservisler sizi alıp, Mars’a götürmüyor; ya da tüm problemlerinizi düzeltmiyor. Getirilerinin yanında, götürüleri ve belli bir olgunluk seviyesinde olmak gibi şartları var.  Bu şartları sağlayabilecek olgunlukta ne kadar olursanız, o kadar faydasını görürsünüz.

Mikroservis mimari stili ile geliştirilen uygulamalar, pratikte bir birinden bağımsız bir kaç servisin beraberce kullanıldığı uygulamalar olarak karşımıza çıkıyor. Mobil, web ya da masa üstü, hatta hatta konsol uygulamaları, bu sayede aynı servisleri kullanarak geliştiriliyor. Dolayısıyla, aynı iş mantığı farklı platformalara kolaylıkla sağlanıyor. Microservices’lerin en önemli noktası; bu servislerin kendi başlarına çalışan, tek bir sorumluluğu olan, bağımsız servisler olmalarıdır. Mesela Amazon’nun web sitesi bir çok servis(microservice) ile geliştirilmiş bir web uygulaması. Aynı servisleri Amazon’nun mobil uygulaması ve B2B uygulamaları da kullanmakta.

Mikroservisler iş mantıklarını ve kurallarını kendi içinde tutmalıdırlar. “Ne yapıldığı” servisler tarafında, “nasıl yapıldığı” ise servisleri kullanan uygulamalar tarafında olmalıdır. Bu sayede iş mantığı tek bir yerde olup, sadece orada gelişecektir.

İş kabiliyetlerine göre ayrıştırılan servisler, tek başlarına çalışabilen servisler olmalıdır. Dolayısıyla platform, sistem, dil ya da framework bağımlılıkları yoktur. Yani bir e-ticaret sitesindeki kategori yönetimini sağlayan servisler .NET ile yazılabilirken, ürün görsellerini sağlayan servis node.js ile geliştirilebilir. Ödeme servisleri Scala ile olurken, istatistiksel verileri sağlayan kısımlar R dili ile yazılabilir. .NET servisleri, Windows sunucularda olurken, node.js *Unix tabanlı bir sistemde bulunabilir. Bu sayede belli bir teknolojiye bağımlılık da ortadan kalkmış oluyor.

continuous integrationBu servislerin bağımsızlık ilkesi, servislerin değişikliğini ve deployment’ını kolaylaştırıyor. Yani görselleri sağlayan servisdeki bir geliştirme, diğer servislerden bağımsız,  başka hiç bir servisi etkilemeden kolaylıkla yapılabilir. Benzer yaklaşım ile servislerin deployment’ları da bir birinden bağımsız ve bir birini etkilemeyecek şekilde gerçekleşebilir. Bu getirinin tabi ki bir şartı var. Oldukça düzgün, oturmuş ve sorunsuz bir Continuous Integration(CI) yönteminizin olması gerekmekte. Yani kodlarınız düzenli bir şekilde, belli aralıklar ile ortak kod deposuna gönderilmesi ve orada hatasız bir şekilde build edilmesi otomatik bir şekilde gerçekleşmeli. Aynı şekilde servisleri versiyonladığınız bir yönteme de sahip olmanız gerekmekte.

You had one jobAz önce dediğim iş kabiliyetlerine göre ayrışan bu servisler, bu ayrışmadan dolayı küçük olmalıdır. Tek bir sorumlukları olup, bu sorumlulukları sorunsuz bir şekilde gerçekleştirmelidirler. Bu da basit olmaları anlamına geliyor aslında. İş kabiliyetlerine göre basitlik kavramı değişse de, sonuçta tek bir sorumlulukları olduğu için karmaşıklıkları az olacaktır. Burada önemli olan anahtar kelime “sorunsuz“. Mikroservisler sorunsuz bir şekilde çalışmalıdır. Bu noktada test edilebilir şekilde geliştirilmeleri şartı ortaya çıkıyor. Servislerin sorunsuz olarak çalıştığını, hem birim testler ile hem de otomatikleşmiş testler ile sağlamak gerekli. Aksi takdirde problemi servisler, problemli uygulamalara yol açacaktır. Dolayısıyla test kültürünün takım ya da şirket içinde belli bir olgunluğa erişmiş olması gerekmekte.

Mikroservislerin en önemli özelliklerinden biri, “scale” edilebilir olmaları. Farklı sistemler ve platformlarda çalışabilen farklı servisler olarak geliştirildikleri için, ihtiyaça göre genişletilebilirler. Mesela yoğun “memory” kullanan bir servis ile yoğun I/O işlemi yapan bir servisi farklı şekillerde “scale” edip, kaynak kullanımını optimize etmek oldukça kolay olacaktır. Bu noktada microservices’lerin yönetimi ve monitör edilmesi şartı da karşımıza çıkacaktır. Dolayısıyla devops kültürünün yazılım ekibinde ya da şirkette kabul edilmiş ve oturmuş olması gerekmekte.

dev-ops

Bir çok servisin ortalıkta oluyor olması, bu servislerin monitör edilmesini gerektirecektir. Dolayısıyla öncelikle bu alt yapıyı sağlayan bir platform kurmak ya da araç kullanmak gerekli. Mümkün olabildiğince bu monitör alt yapısı ayrıntılı olmalıdır. Servislerin log’ları, servislere yapılan request sayıları, servis süreleri, servisleri kimlerin çağırdığı gibi kavramları merkezi bir yerden yönetebilmek servislerin operasyon kalitesini arttıracaktır.

Mikroservis mimari stilinin en zor noktası, servislerin büyüklüğü yönetmek. Servisler adet olarak çok fazla büyür ise, sorumlulukları tek bir  servis altında toplanacak şekilde, bir servismiş gibi ele almakta fayda olacaktır. Servislerin içerikleri ve kabiliyetleri ise büyüklük konusunun bir başka noktası. Bu noktada servisin yaptığı işi bilen, sınırları ve ihtiyaçları net bir şekilde tanımlayan kişiler mutlaka olmalıdır. Ya iş birimleri, analistler ya da teknik olarak yetkin kişiler; ve bu kişiler mutlaka tecrübeli olmalıdır. Aksi takdirde servislerin içinde kaybolmak kaçınılmaz olacaktır.

Mikroservislerin temel karakteristik özelliklerini kısaca anlatmaya çalıştım. Anlaşılması ve gerçekleştirilmesi zor olanlara yer vermeye çalıştım. Pratik olarak uygulamak ya da bu mimari stile göre uygulama geliştirmek zor olsa da, imkansız değil. Ama ciddi bir geliştirme kültürü değişikliği şart. Full-stack geliştiriciler, devops’lar ve yazılım prensipleri ile ilgili farkındalık arttıkça, ciddi anlamda tercih edilebilecek ve belki SOA’nın uygulanabilirliğini kolaylaştıracak bir yaklaşım olacaktır. Umarım bazı kavramlar biraz daha netleşmiştir. Bir sonraki yazıya kadar, hatasız build‘ler…

Çok uzun zamandır merak ettiğim Brugge’e sonunda gitme fırsatı elde ettim. Gidenler genelde Brüksel merkezli, günü birlik(ya da max. 2 gün) Brugge ve Ghent şeklinde bir program yapıyor. En azından benim rastladığım, duyduğum hep bu şekildeydi. Kendileri yapmasa da, turlar falan bu şekilde sanırım. Kafamızı dinleyelim yeter, güzel zaman geçirelim, her yeri görmesek de olur kafasında, rahat bir tatil istediğimiz için, biz böyle yapmadık ve dolu dolu 4 gün Brugge’ün keyfini çıkardık.

Brugge’e, Brüksel üzerinden gitmek çok kolay. Brüksel hava alanından şehir merkezine, oradan da Brugge’e trenle 1 saatte gidebiliyorsunuz. Oldukça keyifli bir yolculuk, bunun da altını özellikle çizmek isterim.

Brugge

Brugge, oldukça küçük bir kent. Her tarafını yürüyerek dolaşabilirsiniz. Her yer bir birine oldukça yakın. Dolayısıyla kent merkezine, tren istasyonundan yürüyerek gitmek mümkün. Yok ben yürüyemem derseniz, hemen tren istasyonunun çıkışında otobüsler var…Yok ben otobüse de binmem derseniz de, taksiyle yaklaşık 15-20 euro civarı bir ücrete gitmek istediğiniz yere gidebilirsiniz.

BruggeBrugge, oldukça sevimli bir orta çağ kenti. Avrupa’nın büyük kesimini yıkan II. Dünya Savaşı’nı yara almadan atlatmış. Dolayısıyla hala bir “orta çağ” kenti. Açıkçası sadece mimarisinden dolayı değil…Sakinliği ve kendi halinde olması, filmlerde gördüğümüz o kuzeydeki kaleler içindeki kendine has yaşam tarzları Brugge’de de var. Mimarisi ile ruhu da korunmuş kentin… Yürüyerek her yere gidebildiğiniz için, önce mutlaka yürüyün…Bol bol yürüyün…Girebildiğiniz tüm sokaklara girin. Tüm binalara bakın, affetmeyin hiç. Daha sonra zamanınız olursa bir de bisiklet kiralayın diyor herkes ama biz kiralamadık. Açıkçası bisiklet ile keyifli bir şekilde dolaşmak, insan kalabalığında biraz zor olabilir. Tabanway rulessss….

BruggeBrugge’ün en büyük olayı, sanırım “bira”…Sonra çikolata, sonra dantel…Patates ve waffle bunların yanında biraz daha geride kalsa da, onları da her köşe başında bulabilirsiniz. Ama dediğim gibi “bira” en ağırlığı olan şey. Bir rivayet göre 16000 çeşit bira varmış…Siz düşünün artık. Gitmeden önce hiçbir yerde okumadığım ve görünce şaşırdığım, bir “çay” gerçeği de var. Açıkcası hiç bilmiyordum, ama çay da Brugge’de hatırı sayılır bir saygınlığa ve çeşitliliğe sahip. Çay dükkanlarına girip, kokuları ile kafa bulabilirsiniz…

2 günde çok rahat, keyifle gezilebilecek yerleri tamamlayabilirsiniz. Eğer zamanınız bolsa o yüzden sıkıştırmanın anlamı yok. Bilimum gezi sitesinde zaten gitmeniz gereken yerler ve yapmanız gerekenler hakkında bir çok şey bulabilirsiniz. O yüzden tek tek yazmayacağım ben de. Ama özellikle bir kaç yerden bahsetmek isterim.

Brugge’de ne yapalım…

BruggeMinnewaterpark ve Beguinage mahallesi…Burası kentin güneyinde, tren istasyonuna oldukça yakın bir bölge. Kuğuların yoğun olduğu, bol yeşilikli ve güzel bir manzarası olan, dinlendirici bir yer…Alın biranızı, oturun banka… Burayı sevmemin bir diğer sebebi, Brugge’e gitmişken gidilmezse olmazı, De Halve Maan‘ın buraya çok yakın olması. De Halve Maan, Brugge’de hala kentin içinde bira imalatı yapan, Brugge’deki en eski bira evi…Bir ara gazetelere de çıkmıştı. Birayı taşımak maliyetli oluyor diye, şehrin altından borular ile birayı diğer şehirlere ve Brüksel’e taşıyan yer…Neyse…Kendi birasını nasıl ürettiğini anlatan 1 saatlik bir turu ile içerisini gezmeniz mümkün. Biranın nasıl yapıldığını, hangi aşamalardan geçtiğini oldukça güzel ve keyifli bir şekilde anlatıyorlar. Turun sonunda da güzel bir bira ile yorgunluğunuzu atıyorsunuz.

BiraaaaBira ile devam edelim…Bir diğer güzel bira noktası, 2be Beerwall… Buranın yeri ve manzarası şahane…Kanalın dibinde, tam köşede…Oldukça geniş bir bira menüsüde var. Mix menü şeklinde 5 adet farklı bira alarak, bira tadımı yapmanız mümkün. Aslında Brugge’deki bir çok bira evinde bu şekilde menüler alarak farklı biraları deneme şansınız olabiliyor. Çok mantıklı ve güzel bir hareket…

Müze konusunda çok zengin bir yer değil Brugge. Ama açıkcası oldukça orijinal bir müzeye sahip, Historium… Orta çağ ortamını hissettiren, bir hikaye içinde gezdiğiniz interaktif bir müze…Brugge’ün orta çağ dönemindeki yaşantısını interaktif bir hikaye ile anlatıyor. Oldukça ilginç bir deneyimdi…Tavsiye ederim. Ve tabi ki kanal turu…Açıkcası turu yaptığınız araçlar biraz sıkışık ve kalabalık oluyor. O yüzden binerken biraz hayal kırıklığına bürünebilirsiniz. Ama tur başladıktan sonra oldukça keyifli oluyor. Yapmakta fayda var… Grote Mark ve Burg meydanı, Belfry saat kulesi, çikolata müzesi, patates müzesi falan bunlar zaten bir şekilde karşınıza çıkacak yerler. Zamanınız varsa, ayrıntılı olarak buralarıda gezebilirsiniz tabi.

Eee peki Brüksel…

Dediğim gibi tam tersi bir programla günü birlik Brüksel gezisini tercih ettik. Ve açıkcası iyi ki böyle yapmışız. Brüksel, oldukça standart ve boş bir şehir. Açıkcası pek sevmedim. Çok hazırlık yapmadan, spontene bir şekilde gitmiş olmamızdandır belki ama pek bizi cezbeden bir şey bulamadık şehirde. “Belgian Comic Strip Museum” özellikle görmek istediğim bir yer olduğu için biraz onun sayesinde, biraz da Delirium isimli bira evi sayesinde kendini kurtardı diyebilirim Brüksel. Belçika’ya gitmek gibi bir plan içindeyseniz ama, Brugge ve Ghent varken, Brüksel’i hiç düşünmeyin bile…

Evet Ghent…

GhentBrüksel dönüşü, akşama doğru Ghent yolumuzun üstü olunca bir akşamı orada geçirmeye karar verdik. Nasıl Brüksel’i beğenmediysem, tam tersi şeklinde de Ghent’i çok beğendim. Çok gezme fırsatım olamadı ama gördüğüm kadarıyla Brugge’ün devamı diyebilirim. Akşam saatleri ile havanın kararmasıyla, çok daha güzel bir hal aldı. Keyifli bir akşam yemeği ve sonrasında küçük bir tur ile ağzımız açık bir şekilde Ghent’den ayrıldık. Bir daha gidersem oralara, kesinlikle daha fazla zaman ayıracağım…Ahaaa da yazdım buraya…

Ghent

Neyse…Fazla da “spoiler” vermenin anlamı yok aslında. Çok uzun zamandır gitmek istediğim için, beklentimin yüksek olduğu bir yerdi Brugge. Kesinlikle beklentimi karşıladığını söyleyebilirim. Çok güzel ve özel bir tatildi. Şiddetle tavsiye ediyorum… Bir sonraki durakta görüşmek üzere, şimdilik benden bu kadar (:

 

 

Bir önceki yazımda .NET Core ve .NET Framework’ün arasındaki farkı ve .NET Core’un ortaya çıkışındaki amaçtan bahsetmeye çalışmıştım. Bu sefer biraz daha ayrıntılara girip, .NET Core ve hatta ASP.NET 5 ile haşır neşir olmaya başlayanların büyük bir ihtimal karşılaştığı dnvm, dnu ve dnx kavramlarından bahsetmeye çalışacağım.

net2015Yeni nesil .NET uygulamalarının çalışmaları için gerekli olan bu araçların hala gelişmekte olduğunu özellikle belirtmek isterim. Önceki isimleri ile; KLR,KVM,KRE olarak ilk başta çıktığında, tam oturmamış ve problemleri olan bu araçlar, artık biraz daha stabil ve yeni nesil .NET uygulamalarının temelini oluşturuyor. Açıkcası tamamen olgunlaştıklarında, bazı kavramların tamamen soyutlanacağını ve kolaylaşacağını düşünüyorum.

DNX

DNX, yeni nesil .NET uygulamalarının çalışmasını sağlayan “runtime” bileşeni diyebiliriz. Common Language Runtime’ı yükleyen ve onun çalışmasını sağlayan temel bileşen. Kendi içinde çalışma şekli olarak iki farklı yöntemi var. Bir tanesi .NET Core için, CoreCLR’ın çalışması için, diğeri de normal .NET Framework’ün yani .NET CLR’ın çalışması için. DNX bu iki ayrımı kendi içinte yönetip, bizden bu ayrımı soyutluyor. Kısacası yeni nesil .NET uygulamalarının kalbi.

dnx

DNVM

Yeni nesil .NET uygulamaları önceden duyurulduğu gibi artık daha yalın ve bağımsız. System.IO ve System.Console bileşenleri artık kendi versiyonları ile ayrı ayrı uygulamalarınızda çalışabiliyor. Yani System.IO’nun 1.0.0 versiyonu ile System.Console’un 2.0.0 versiyonunu, kendi uygulamamız içinde, bu ayrımı yaparak kullanabileceğiz. Bu durum, DNX içindeki bileşenlerin versiyonlarının yönetilmesi gerekliliğini ortaya çıkarıyor. .NET Version Manager(dnvm) da bu yönetimi sağlayan temel araç.

dnvmİstediğimiz DNX’i DNVM ile yükleyip, gerektiğini güncellemek bu araç ile yapabileceğimiz bir şey.

DNU

Yeni nesil .NET uygulamaları, hem geliştirme yöntemleri hem de proje şablonları açısından oldukça yalınlaşıyor. project.json isimli proje tanım dosyaları ile uygulamanızın runtime(DNX)’da nasıl çalışacağını json formatında belirtebiliyorsunuz. DNU bu aşamada bu proje dosyalarının DNX tarafından yorumlanmasını sağlıyor. Proje dosyanızda belirtilen, referansların getirilmesi, projenizin “build” edilmesini hatta projenizin nuget paketine dönüştürülmesini bu araç sağlıyor.

Bütün bu araçlar, open-source olarak GitHub’da mevcut tabii ki. Gelişme süreçlerini oradan çok yakın bir şekilde takip edip, gelişme süreçlerine dahil de olabilirsiniz.