Finans sektöründe nasıl daha verimli yazılımcılar olabiliriz. Yıllara dayanan tecrübe, gözlem ve biraz araştırmanın sonucu olarak hazırlanan maddeler ile cevap bulmaya çalışıyoruz.
Bu oturumumuzda kurumsal uygulamaları tanımaya çalışacağız. Temel karaktresitik özelliklerini, çeşitlerini, zorlu yanlarını açıklığa kavuşturacağız. Enterprise Mimari ile olan ilişkisine de bakacağız.
NoSQL databases get a lot of press coverage, but there seems to be a lot of confusion surrounding them, as in which situations they work better than a Relational Database, and how to choose one over another. This talk will give an overview of the NoSQL landscape and a classification for the different architectural categories, clarifying the base concepts and the terminology, and will provide a comparison of the features, the strengths and the drawbacks of the most popular projects (CouchDB, MongoDB, Riak, Redis, Membase, Neo4j, Cassandra, HBase, Hypertable).
istegelsin
Günlük market alışverişinizi yapabileceğiniz, tazeliğini bozmadan evinize kadar siparişinizi getiren bir e-ticaret altyapısı.
Business Logic yazıyoruz, Infrastructure değil
Sadece FaaS değildir
Microservices based services - but managed by AWS
SQL vs NoSQL - centralized vs distributed
SQL vs Serverless NoSQL (DynamoDB)
DynamoDB
Infrastructure as Code - CI & CD
Step Functions
GraphQL
Event Based
Observability
(Turkish) SAP Forum 2017: ING Bank Başarı Hikayesi Sunumu - Kurumsal Bilgi Yö...MDS ap
ING Bank's presentation of the joint project with MDS ap - "Data Modeling in SDLC". The presentation was delivered at SAP Forum Istanbul 2017.
***
ING Bank ile gerçekleştireceğimiz sunumda
“Yazılım Geliştirme Hayat Döngüsü” içinde modellemenin yeri ve kuruma getirdiği avantajlar dile getirilecektir. ING Bank, MDS ap ve SAP PowerDesigner seçimlerini, veri modelleme
projelerini ve deneyimlerini aktaracaktır.
Finans sektöründe nasıl daha verimli yazılımcılar olabiliriz. Yıllara dayanan tecrübe, gözlem ve biraz araştırmanın sonucu olarak hazırlanan maddeler ile cevap bulmaya çalışıyoruz.
Bu oturumumuzda kurumsal uygulamaları tanımaya çalışacağız. Temel karaktresitik özelliklerini, çeşitlerini, zorlu yanlarını açıklığa kavuşturacağız. Enterprise Mimari ile olan ilişkisine de bakacağız.
NoSQL databases get a lot of press coverage, but there seems to be a lot of confusion surrounding them, as in which situations they work better than a Relational Database, and how to choose one over another. This talk will give an overview of the NoSQL landscape and a classification for the different architectural categories, clarifying the base concepts and the terminology, and will provide a comparison of the features, the strengths and the drawbacks of the most popular projects (CouchDB, MongoDB, Riak, Redis, Membase, Neo4j, Cassandra, HBase, Hypertable).
istegelsin
Günlük market alışverişinizi yapabileceğiniz, tazeliğini bozmadan evinize kadar siparişinizi getiren bir e-ticaret altyapısı.
Business Logic yazıyoruz, Infrastructure değil
Sadece FaaS değildir
Microservices based services - but managed by AWS
SQL vs NoSQL - centralized vs distributed
SQL vs Serverless NoSQL (DynamoDB)
DynamoDB
Infrastructure as Code - CI & CD
Step Functions
GraphQL
Event Based
Observability
(Turkish) SAP Forum 2017: ING Bank Başarı Hikayesi Sunumu - Kurumsal Bilgi Yö...MDS ap
ING Bank's presentation of the joint project with MDS ap - "Data Modeling in SDLC". The presentation was delivered at SAP Forum Istanbul 2017.
***
ING Bank ile gerçekleştireceğimiz sunumda
“Yazılım Geliştirme Hayat Döngüsü” içinde modellemenin yeri ve kuruma getirdiği avantajlar dile getirilecektir. ING Bank, MDS ap ve SAP PowerDesigner seçimlerini, veri modelleme
projelerini ve deneyimlerini aktaracaktır.
Blockchain teknolojileri sayesinde alıştığımız internet büyük bir değişimden geçmek üzere. Web 3.0 adı da verilen bu yeni internet üzerinde geliştirilebilecek uygulamalar kullanıcılara yeni imkanlar ve özellikler sağlayacak.
Verinin temsili, işlenmesi, saklanmasında gelişen ve değişen
koşullar ele alındıktan sonra, büyük verinin işlenmesi konusu
ele alınıyor.
Verinin anlamlandırılması konusunda değişen terimler, ünvanlar, algoritmalar, kullanılan aletler konusunda değerlendirmeler paylaşıldı.
sunumun videosuna aşağıdaki adresten ulaşabilirsiniz.
https://www.youtube.com/watch?v=pnvvMU8L-O0
Bulutistan, 2015 yılında Bulut Bilişim’in Türkiye’deki gelişimine değer katmak ve KOBİ’lerden büyük kurumsal şirketlere kadar her ölçekte şirket için teknoloji köprüsü olmak amacıyla kurulmuştur. Yarattığı ekosistem ile dünyanın önde gelen tüm küresel oyuncularıyla birlikte çalışan Bulutistan, işletmelerin yatırım maliyetlerini optimize eden, yenilikçi bulut çözümlerini farklı ölçekte şirketlere “kullandığın kadar öde” iş modeliyle sunmaktadır.
Sürekli büyüyen verinin lokal veri merkezlerinde önem derecesine göre ayrıştırılarak saklanması amacıyla, İzmir’in en önemli veri merkezi işletmesi Netdirekt ile İstanbul’da butik bir veri merkezi yatırımı gerçekleştirilmiştir. İzmir’deki Felaket Yönetimi Merkezi ile entegre çalışan bu yeni nesil veri merkezi, kritik olmayan veriler ve iş süreçleri için yurt dışı telekom hatları ile doğrudan bağlantılar sağlayarak, hibrid bulut projelerinin kolaylıkla hayata geçmesine imkan tanımaktadır.
Monolitik Uygulamalarda Teknik Borçlanma ile Mücadele (Teori)Burak Selim Şenyurt
Developer Summit 2021'de gerçekleştirdiğim ve monolitik sistemlerde (özellikle legacy kabul edilen katmanlı modellerde) teknik borçla nasıl mücadele edileceğine dair anlatımın yer aldığı sunumdur. Sunumda teknik borçla ilgili istatistikler, tanım, mücadele şekilleri, yazılım mimariler arasındaki farklılıklara da yer verilmektedir.
Beş Dakikalik Yolu Bir Saatte Gitmek - Bir AntiPattern MacerasıBurak Selim Şenyurt
Teknik borçlanmanın ve ürünleri sevimsiz hale getiren etkenlerin başında da AntiPattern'ler geliyor. Doğuş Techdili Mekan sohbetleri kapsamında gerçekleştirdiğimiz etkinlikteki sunumum.
Kod tabanınız çok mu geniş? Takım çok mu kalabalık? Ufak bir değişikliği üretim ortamına almak için geçişi beklemeniz mi gerekiyor? Dönüşmeye karar verdiniz, eğitimler aldınız peki ya geçmişten kalan teknik borçların farkında mısınız?
Corona Virüs salgını sebebiyle ötelenen bir Üniversite ektiğinliğinde, çoğunluğu bilgisayar ve yazılım olmak üzere farklı mühendislik branşlarından oluşan genç ve hevesli zihinlere "Bugün Yarınların için Ne Yapacaksın?" isimli mesleki gelişim ve kariyer temalı bir sunum gerçekleştirecektim...
Sunumu destekleyen yazıya buradan ulaşabilirsiniz: https://bit.ly/2y8GAUI
Zonguldak Bülent Ecevit Üniversitesi tarafından düzenlenene etkinliği de buradan izleyebilirsiniz: https://youtu.be/6n4wj5zGSjQ
Teknolojinin birkaç yıl önce başlayan teknolojik dönüşümünün yarattığı kaosu çeşitli açılardan anlamladırmaya çalışırken, biz yazılımcıların bazen de over-engineering gitmesinin bunu körüklediğini anlatmaya çalıştığım sunumum.
Klaus Martin Schwab ın endişesinden, Ford'un Tesla karşısında panikleyip yaptığı hatalara, Agile-Waterfall ikileminden projelerinin başarı oranlarına ve nihayetinden basit bir problemi çözmek için ne kadar karmaşık düşünebileceğimize uzanan 25 dakikalık bir içeriktir.
Celal Bayar Üniversitesi Bilişimde Kariyer Zirvesi(http://www.bilisimdekariyerzirvesi.com/ ) etkinliği için hazırladığım sunumdur. Sunumda teknolojinin geçmişten günümüze hızla değişiminden dikey ve yatay uzmanlıklara, Endüstri 4.0 yeniliklerinden Gartner araştırma raporlarına, çalışma tekniklerinden takip edilmesi gereken kaynaklara farklı bir çok konuda bilgiler verilmeye çalışılmıştır.
Yaklaşık olarak 15 yıldır aktif olarak yazılım geliştirme işinde yer alıyorum. Son 4 yıldır ise bir bankanın kurumsal çözümlerinde çalışıyorum. Tüm yazılım hayatım boyunca ağırlıklı olarak .Net platformu üzerinde çalıştım. Zaman ilerledikçe sürekli olarak aynı şeylerle uğraşmanın beni paslandırdığını gördüm. İçimdeki araştırmacı kişiliği uyandıracak beni tekrardan keyiflendirecek bir şeyler gerekiyordu. Sonuç olarak çok sıkıldığım bir günün devamında yeni ne öğrenebilirim diye araştırmaya karar verdim. Daha önceden Java ile ilgili bir maceram olmuş ve 24 bölümlük bir makale serisi hazırlayabilmiştim. O zamanlar epeyce keyif alıyordum. Bu kez düşünce yapım biraz daha farklıkaştı. Çocuklara nasıl programlama öğretilebilir fikrinden yola çıktım. İlk iş bir Lego yapmaktı.ve devamı geldi...
12. Atomic :
Consistent :
Ya hep ya hiç
Veritabanı bütünlüğü
Isolated :
Durable :
söyledim
* Aksi durumlar söz konusu olabilir. Bunun için izolasyon seviyeleri ele alınır.
İşime karışma *
Son sözümü
13.
14. Firma
İstatistik
Aylık paylaşım sayısı
Facebook
Entegre çalışan Uygulama ve Web Sitesi Sayısı
Her gün kurulan uygulama sayısı
Wikipedia Wikipedia tarafından sunulan toplam makale sayısı
Her dakika yüklenen ortlama resim sayısı
Flickr
Youtube
Twitter
12.26.2013
Aylık olarak toplam gösterim sayısı
Dakika başına yüklenen toplam video süresi
Günlük ortalama tweet sayısı
Günlük Twitter Arama Motoru sorgu sayısı
Değer
70 Milyar
7 Milyon
20 Milyon
17 Milyon
3000
92 Milyar
65 Saat
190 Milyon
2.1 Milyar
Statistic Brain
23. Row ID
Column
Family
Row Key Timestamp
Column
Name
Name Family
First
Last
T4
T20
Jon
T45
Phone Number
Email
selim@buraksenyurt.com
444-55-66
Burak
T22
Connection Family
burak@blaba.com
122-54-64-555
jon@doe.doe.com
Şenyurt
T9
Row 2
Value
333-33-33
T1
Row 1
Timestamp
Do
Doe
Jon.doe@nosql.com.fr
24. Sepetim
Sepet ID Kullanıcı Oluşturulma
9005
Burki
4.12.2013
9006
ConDo
5.12.2013
Sepet Öğeleri
Öğe ID SepetID Miktar Ürün No
1001
9005
3
PRD-01
1002
9005
1
PRD-02
Ürün
Ürün No Adı
Fiyat Kategori
PRD-01
AyFone5
120
Telefon
PRD-02
Anduroit 190
Telefon
25. Row ID Time Kullanıcı SepetID Urun
stamp
Adı
T1
1506
Burki
Urun
No
Birim Adet Kategori
Fiyat
9005
T2
AyFone5 PRD-01 120
3
Telefon
T3
Anduroit PRD-02 190
1
Telefon
31. Ürün
Üretici
Tip
CAP Internal? Bazı Kullanıcıları
Dynamo
Amazon
Key Value
AP
Evet
Amazon
Cassandra
Facebook
Column Store
AP
Hayır
Facebook, Digg, Twitter, Rackspace, Cisco,
BigTable
Google
Column Store
CP
Evet
Google
MongoDB
10Gen
Document Store
CP
Hayır
EA, Newyork Times, Github, Sourceforge
CouchDB
Couchio
Document Store
AP
Hayır
BBC, Sauce Labs
SimpleDB
Amazon
Key Value
AP
Hayır
Alexa
Neo4J
Neo Technologies
Graph
??
Hayır
Adobe, Swedish Defence Forces,
Redis
VMware
Key Value
CP
Hayır
Twitter, The Guardian, Instagram, Stackoverflow
Voldemort
Linkedin
Key Value
AP
Hayır
Linkedin
Evet
LiveJournal, Flickr, Wikipedia, Youtube, Digg
Memcached LiveJournal
Key Value (In-Memory) CP
32. Eric Brewer
Symposium on Principles of Distributed Computing
Seth Gilbert
Nancy Lynch
güvenilir olmayan bir ağ üzerinde
aşağıdaki 3 özelliğin hepsini birden
Consistency :
Availability :
Partition Tolerance :
33.
34.
35.
36.
37. Bir yazma işlemini asla kesme.
Consistency’ ye değil işlem hacmine
odaklan (Big Data)
İyimser ol : Bir servis düşse bile doğal
olarak ayağa kalkacaktır.
Bazı raporlar bir süre için tutarsızlık
gösterebilir ama üzülme. Sonunda
doğru bilgiyi verir.
Lock’ lar dan uzak dur, basit düşün.
Editor's Notes
NoSQL kavramı ilk olarak 1998 de Carlo Strozzitarafından dile getirilmiştir. 2009’da Eric Evan tarafından yeniden tanıtılmıştır.
Live Journal, veritabanı sorgularının performansını arttırmak, (MemCached) - Youtube, Reddit, Facebook, Twitter, Tumblr, WikipediaGoogle, milyarlarca sayfa üzerinden yapılan arama sonuçlarını indekslerken düşük maliyetli sunucuları kullanabilmek, (MapReduce)Google, çok sayıda kolonla ifade edilebilecek veri tablolarını dağıtık mimaride olabildiğince esnek bir şekilde tutabilmek, (BigTable)Amazon, 7/24 bir web siparişini kabul edebilmek, (Dynamo)MarkLogic, standart sorgulama dilini kullanarak sıradan donanımlı sunucularda sakladığı devasa boyuttaki XML doküman koleksiyonları üzerinde sorgulama yapabilmek, (Müşterileri arasında Warner Bros, Citigroup, Dow Jones, Boeing) için kendi geliştirdikleri NoSQL sistemlerini tercih etmişlerdir.
1998 yılında tasarımcı Carlo Strozzi Unix sistemlerde çalışan shell tabanlı, SQL dilini kullanmayan bir veritabanı tasarlar. Kendisi RDBMS’ ler gibi ilişkisel olmayan bu veritabanı için NoREL ifadesinin kullanılmasını daha uygun bulur. Derken 2009 yılnda Atlanta’ da yapılan bir konferans’ da Eric Evans tarafından kavram tekrardan gündeme getirilir ve tanımlanır.Strozzi’ nin tasarladığı NoSQL sistemi ile ilişkili olarak http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page adresinde detaylı bilgi bulunmaktadır.
Scalability(Ölçeklenebilirlik)Horizontal Scalability:Sistemin kapanmadan paralelinde yeni makineler eklenerek genişlemesi ve hacimsel olarak büyümesi.Vertical scalability:Tek makineye ek donanım takviyeleri yapılarak genişletilmesi.
CAP Teoremi Cluster üzerindeki Partition’ lar arasında iletişim kopmaları yaşanabilen vakalarda uygulanmaktadır!!!Consistency : ACID’ deki Consistency değildir. Burada tüm istemciler için tek, güncel ve okunabilir bir data söz konusudur. N sayıda istemci replicate edilmiş partition’ lardan aynı öğeleri okur ve tutarlı sonuçlar elde eder.High Availability : Dağıtık bir veritabanı sistemi istemcilerinin veriyi update ederken gecikme yaşamasına müsaade etmez. Replicate edilmiş partition’ lar arasında oluşabilecek iletişim aksaklıkları güncellemeleri kesmemelidir.PartitionTolerence : Database partition’ ları arasında iletişim aksasa bile sistem istemcilerine cevap vermeye devam eder. Bu ilke NoSQL sistemlerinin makine kapatmadan yatayda kolayca genişleyebilmesine olanak tanımaktadır.
http://en.wikipedia.org/wiki/CAP_theorem
Basic Availability: Her request başarısız icra edilse de bir Response almalıdır. Garanti Response.Soft State: Sistemin durumu zaman içerisinde hiçbir veri girişi olmadığı halde değişiklik gösterebilir(Eventual Consistency’ ye ithafen)Eventual Consistency: Veri tabanı geçici olarak tutarsız bir konuma gelebilir ama nihayetinde tutarlılık kazanacaktır.
Veri büyürken ihtiyaçları karşılayacak şekilde ölçeği arttırmak beraberinde bazı soruları da getirir. Veriyi nereye nasıl saklayacağız, nasıl eşleştireceğiz ya da eşleştirmeyecek miyiz, veriyi bölecek miyiz, neye göre böleceğiz veya böldüysek taşırken sunucu kapatacak mıyız?Bir örnek ile devam edelim.Kullanıcılarının kendi kişisel alanlarını yarattıkları bir web sitemiz olduğunu düşünelim. Söz gelimi kendilerine özgün bir Second Life kurdukları bir sosyal ağ olsun. Beğendikleri ürünleri koyabilsinler, profilleri bulunsun, bol bol text ekleyebilsinler. Site verilerini bir RDBMS üzerinde tuttuğumuzu varsayalım. MySQL olabilir. Tek bir CPU su olan bir DB server da çalıştığımızı düşünelim. Site tuttu. İnsanlar arkadaşlarını davet etmeye başladılar ve olan oldu. Disk kapasitesi dolmaya başladı. Sadece %10 luk bir alanı boş. Şimdi ne yapacağız?Büyük ihtimalle yeni bir sistem satın alıp verinin bir kısmını onun üstüne aktaracağız. Bu kısaca Sharding dediğimiz mekanizma aslında. Bu arada hangi sunucudan bilgi okunacağına dair uygulama seviyesinde geliştirme yapmalıyız. Bunu yaparken ne yazık ki eksi sunucu ve db bir süreliğine kapalı kalacak. Veriyi tekil db’den çoklu ve dağıtık yapıdaki db’ sistemine dağıtırken başka sorular da karşımıza çıkacak. Örneğin;Hangi makine de hangi veri aralıklarını tutacağız? Buna nasıl karar vereceğiz? Peki ya bir partition da duran veri de değişiklik olur ve onun karar verdiğimiz ayırma prensibine göre diğer bir partition’ a taşınması gerekirse? Söz gelimi isminin baş harfi A ile K aralığındakileri X sunucusundaki DB’ de diğerlerini de Y sunucusundaki DB’ de tuttuğumuz var sayalım. Adam ismini değiştirip diğer aralığa girerse tüm verisini o DB’ ye taşımalı mıyız? Şimdilik sadece iki sunucuya bölündük. Ya veri iki kat büyürse. Tekrar sunucuları kapatıp, uygulamalarda değişiklik yapıp yeni makineleri sisteme bu şekilde mi dahil edeceğiz?
Veri parçalanarak dağıtılır. Replication’ da olduğu gibi tüm alt db’ ler de verinin aynısı bulunmaz.
Daha çok High Availability adına uygundur. Uygulamalar sadece Master DB’ ye veri yazar ve oradan okurlar. Master DB lerden birinin çökmesi halinde Slave DB hemen sorumluluğu üstlenir ve cevap verir. Bu High Availability anlamına gelir. Tabi yine de bir soru vardır. Ya Slave sistemlerden biri çökerse Bu tip durumlarda Reliable Messaging veya Message Store gibi Queue tabanlı sistemler kullanılarak çökmelerin önüne geçilir. Master DB’ ye bir şeyler yazıldığında hemen Slave’ lere de kopyalama olur. Bu nedenle kopylama işlemleri sırasında sistemde bir yavaşlık olabilir ve okuma hızları düşebilir.ACID ilkelelerinin garanti edilmesi istendiği durumlarda transaction’ ların aksamaması, garanti edilmesi ve yedeklerin tutarlı ve birebir alınması noktasında Replication bir çözümdür. Bu noktada Sharding in High Availability sunmadığını söyleyebiliriz.