Benim İçin Uçma Zamanı... Render Yapma Zamanı

Aşağıda gösterilen Gartner heyecan döngüsü teknolojinin birçok yönüne uygulanabilir:

Yeni yenilikler kendi döngülerine girdikçe, beklentiler eninde sonunda gerçekleşir ve bu da belli düzeyde benimsenmeye yol açar.

Her yeniliğin hedefi, tüketicilerin yeniliği benimsemenin getirdiği ödülün bilinen risklerden çok daha ağır bastığına karar verdikleri üretkenlik platosuna ulaşmaktır.

Aynı zamanda üretkenlik platosunun azalmaya başladığı ve bu inovasyondan kaçışa yol açtığı bir nokta var. Basit bir örnek, cep telefonları/cihazları üretkenlik düzeyine ulaşmadan önce yaygın olan çağrı cihazları (veya çağrı cihazları) olabilir.

Teknoloji uzmanları olarak üretkenliği artıran özellikler, çerçeveler, ürünler veya hizmetler sunmaya çalışıyoruz. Aynı şey kullandıklarımız için de geçerli.

Son zamanlarda mevcut barındırma platformumun üretkenlik platosundan düşmeye başladığını hissettim. Aslında yakın zamanda yapılan bir duyuru , diğer seçenekleri değerlendirmenin zamanının gelip gelmediğini merak etmeme neden oldu.

Render PaaS'ı kullanırken olumlu bir deneyim yaşadığım için Heroku uygulamalarımdan birini ne kadar kolay dönüştürebileceğimi, PostgreSQL'i benimseyebildiğimi ve Render'a geçebildiğimi görmek istedim. Bu iki bölümlük seride bu yolculuğu anlatıyorum:

• Bölüm 1: Arka uç hizmetlerimi (Spring Boot ve ClearDB MySQL) taşımaya odaklanacağız.
• Bölüm 2: Ön uç Angular istemcimi taşımaya ve taşımaya odaklanacağız.

Neden Render'ı Seçtim?

Render'ı daha önce hiç duymadıysanız önceki yayınlarımdan bazılarına göz atın:

• Render PaaS ile DevOps'a Sıfır Zaman Harcayın

• Mükemmel Bulut: AWS, GCP ve Azure hepsi bir arada

• Amaca Odaklı Mikro Hizmet Tasarımı

• Girişim Fikrinizi Bir Günde Başlatın

• Mikro Hizmetler Uygulamamı Kolaylıkla Ölçeklendirmek İçin Render'ı Nasıl Kullandım

Render'da heyecan verici bulduğum şey, bir yandan aydınlanmanın zirvesini tırmanmaya devam ederken, bir yandan da üretkenliğin zirve noktasını fark eden benimseyenlere aktif olarak sağlam bir çözüm sunmasıdır.

Yazılarımda da belirttiğim gibi Render “Sıfır DevOps” vaadi sunuyor. DevOps görevlerine odaklanacak zamanım olmadığı için bu benim ihtiyaçlarıma mükemmel bir şekilde uyuyor.

Heroku platformunda pek hoşlanmadığım birkaç şey var:

• Günlük yeniden başlatmalar, hizmetlerimden birinde beklenmedik kesintilere yol açtı.

• Giriş seviyesi (gerçekten ihtiyacım olan tek şey) Heroku'daki Postgres ayda dört saatlik kesinti süresine izin veriyor.

• Tüketici açısından bakıldığında fiyatlandırma seviyeleri iyi ölçeklenmiyor.

Fiyatlandırma açısından bakıldığında, tüm uygulamalarımı ve hizmetlerimi Heroku'dan Render'a geçirdikten sonra önemli ölçüde maliyet tasarrufu görmeyi bekliyorum. Daha da şaşırtıcı olanı, uygulama ayak izimin büyümesi gerektiğinden doğrusal ölçeklendirmeyle bu fiyata daha iyi bellek ve CPU elde ediyorum.

Tek Bir Hizmeti Dönüştürme

Yukarıda belirttiğim gibi bu, iki bölümlük bir serinin birinci kısmıdır ve bu makalede hizmet katmanına odaklanacağım. Dönüştürmek istediğim hizmet aşağıdaki özelliklere sahip:

• Spring Boot RESTful API Hizmeti

• Heroku CloudAMQP (RabbitMQ) Mesaj Aracısı

• Heroku ClearDB (MySQL) Veritabanı (tek şema)

• Okta Entegrasyonu

Render PaaS tarafında yeni hizmet tasarımı şu şekilde görünecek:

• Spring Boot RESTful API Hizmetini barındıran Render Web Hizmeti (Docker aracılığıyla)

• RabbitMQ Mesaj Brokerını barındıran Render Özel Hizmeti (Docker aracılığıyla)

• Postgres'i birden çok şemanın var olma özelliğiyle işleme

• Okta Entegrasyonu

Aşağıda iki ekosistemin yan yana karşılaştırması verilmiştir:

Dönüşüm için üst düzey saldırı planım şöyle:

Heroku'yu Dönüşüme Hazırlayın

Başlamadan önce mevcut tüm Heroku hizmetlerinin Bakım Moduna getirilmesi önerilir. Bu, tüketicilerin uygulamalara veya hizmetlere erişmesini yasaklayacaktır.

Kaynak kodun zaten yedeklenmesi ve git tabanlı bir depoda saklanması gerekirken, veritabanı yedeklemesinin başarıyla oluşturulduğundan emin olmak iyi bir fikirdir.

Heroku Hizmetlerinin Dönüştürülmesi

Dönüşüm açısından bakıldığında dönüştürmem gereken iki öğe vardı: hizmetin kendisi ve ClearDB (MySQL) veritabanı.

Spring Boot RESTful hizmetimin dönüşümü çok fazla iş gerektirmedi. Aslında daha önceki bir projemde kullandığım yaklaşımdan faydalanabildim.

Veritabanı için MySQL'den PostgreSQL'e dönüştürmem gerekiyordu. Amacım, Heroku Postgres'i Render Postgres'e kolayca taşımak için Render'ın Heroku Migrator'unu kullanmaktı, ancak önce MySQL'den PostgreSQL'e dönüştürmem gerekiyordu.

Başlangıçta, veritabanı dönüşümü için yaygın bir yaklaşım gibi görünen pgloader yolundan başladım. Ancak M1 çipli MacBook Pro'mu kullanmak bazı beklenmedik sorunlara yol açtı.

Bunun yerine MySQL'i PostgreSQL'e dönüştürmek için NMIG'yi kullanmayı tercih ettim. Daha fazla bilgi için lütfen aşağıdaki “ Veritabanı Dönüşümünden Önemli Noktalar” bölümüne göz atın.

Render'da Hizmetler Oluşturun

Veritabanını ve Docker içerisinde çalışan Spring Boot RESTful hizmetini dönüştürdükten sonraki adım, Spring Boot RESTful API hizmeti için Render Web Service oluşturmaktı.

Bu, hizmeti oluşturmak, ona bir ad vermek ve GitLab'daki kodum için uygun depoyu işaret etmek kadar kolaydı.

Benim de bir RabbitMQ servisine ihtiyacım olduğundan Render üzerinde çalışan bir RabbitMQ Private Service oluşturmak için bu talimatları takip ettim. Bu, işlenmemiş mesajların kalıcı olması için küçük miktarda bir disk depolama alanı oluşturulmasını da içeriyordu.

Son olarak Render Dashboard'da hem Spring Boot RESTful API hizmeti hem de RabbitMQ message broker için gerekli ortam değişkenlerini oluşturdum.

Hizmetleri Başlatın ve Doğrulayın

Bir sonraki adım hizmetlerime başlamaktı. Çalıştırıldıktan ve API'ler Postman koleksiyonum kullanılarak doğrulandıktan sonra, istemci uygulamamı yeni Render hizmeti konumunu işaret edecek şekilde güncelledim.

Her şey çalışır duruma geldiğinde, Render Dashboard'um aşağıda gösterildiği gibi göründü:

Sonraki adımlar

Bu noktada geriye kalan tek şey, hala Heroku üzerinde çalışan veritabanlarını silmek ve taşınan hizmetleri Heroku ekosisteminden kaldırmaktı.

Heroku'yu kullanırken, kodu hizmet havuzumun ana dalıyla birleştirdiğimde, kaynak havuzumdaki Heroku'ya dağıtmak için GitLab CI/CD'yi kullanmam şartıyla kod otomatik olarak dağıtıldı.

Ancak Render ile kaynak dosya deposuna kod eklemenize gerek yoktur. Hizmet için İşleme Kontrol Panelinde Oluştur ve Dağıt Şubesini belirtmem yeterliydi:

Sıfır DevOps vaadini seviyorum.

Veritabanı Dönüşümünde Öne Çıkanlar

Yukarıdaki adımları takip ettiğinizde Heroku'dan Render'a dönüşüm sorunsuz ve başarılı oldu. Benim için en büyük zorluk verilerin dönüştürülmesiydi. Yüksek düzeyde, bu çoğunlukla MacBook Pro'mun terminalinden yürütülen bir dizi komuttan ibaretti.

İlk önce Docker aracılığıyla yerel bir Postgres örneğini başlattım:

 docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres

Daha sonra aşağıdaki komutu (veya pgAdmin'i) kullanarak "örnek" adında bir veritabanı oluşturdum:

 createdb example

Heroku'da çalışan ClearDB (MYSQL) örneğimi yerel olarak çalışan örnek Postgres veritabanıma dönüştürmek için Node.js tabanlı bir veritabanı dönüştürme yardımcı programı olan NMIG'yi kullandım.

NMIG'yi yükledikten sonra, veritabanı uç noktası bilgileri ve kimlik bilgileriyle config.json dosyasını kurdum ve ardından şunu çalıştırdım:

 /path/to/nmig$ npm start

Daha sonra aşağıdaki komutu kullanarak verileri bir dosyaya yedekledim:

 pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump

AWS'de imzalı bir URL oluşturma zahmetine katlanmak yerine, yedeği Heroku'da yeni oluşturulan Postgres örneğine aktarmak için pgAdmin istemcisini kullandım.

Postgres örneği çalışırken ve veriler doğrulandıktan sonra Render PaaS'de yeni bir Postgres veritabanı oluşturdum . Daha sonra tek yapmam gereken şu komutu vermekti:

 pg_restore --verbose --no-acl --no-owner -d postgres://username:[email protected]/example example.dump

Yol Boyunca Öğrenilen Dersler

Heroku'dan Render'a dönüşümüme dönüp baktığımda, bu süreçte öğrendiğim bazı dersler:

• Postgres veritabanının tarih/saat değerini DST uzaklığını içerecek şekilde güncellemesiyle ilgili küçük bir sorun yaşadım. Bu, orijinal veritabanı tasarımımla ilgili bir sorun olabilir, ancak bunu iletmek istedim. Benim durumumda, etkilenen sütun yalnızca Tarih değerleri için kullanılıyor ve bu benim için değişmedi.

• Tablolarımdan birine END adında bir veritabanı sütunu ekledim; bu, Postgres veya Hibernate yerel bir sorgu döndürmeye çalıştığında soruna neden oldu. Hizmet, END sütununun adını gördü ve bunu bir SQL anahtar sözcüğü olarak enjekte etti. İlk etapta yapmamayı bilmem gereken bu sorunu düzeltmek için sütunu yeniden adlandırdım.

• Render ile, Web Hizmeti seçeneği beklenen bağlantı noktasını göstermediğinden RabbitMQ hizmetini Özel Hizmet haline getirmem gerekiyordu. Ancak bu yaklaşımla Özel Hizmetler harici olarak açığa çıkmadığından RabbitMQ yönetici arayüzüne erişim yeteneğimi kaybettim. Görünüşe göre Render bu özellik isteğini karşılamayı planlıyor.

Sonuçta bu küçük engeller Render'a geçme kararımı etkileyecek kadar önemli değildi.

Çözüm

Gartner'ın üretkenlik platformunun en önemli yönü, tüketicilerin gelişmesine ve hedeflerine ulaşmasına olanak tanıyan ürünler, çerçeveler veya hizmetler sunmaktır. Üretkenlik platosu metaforik anlamda gösterişli veya modaya uygun olmak için tasarlanmamıştır.

Bu sonucu Render'ın Geliştirici Avukatı Ed ile paylaştığımda, onun yanıtı paylaşmak istediğim bir şeydi:

“Render açıkça 'modaya uygun' olmaya çalışmıyor. Şaşırtıcı olmayan ve güvenilir olmaya çalışıyoruz.

Ed'in yanıtı bende derin yankı uyandırdı ve bana eski meslektaşımın kodumun kendisine "sıkıcı" geldiğini söylediği zamanı hatırlattı. Onun yorumu alabileceğim en büyük iltifat oldu. Daha fazlasını buradan okuyabilirsiniz.

Teknolojinin herhangi bir alanında, hangi sağlayıcının seçileceğine ilişkin karar her zaman teknoloji konumunuza uygun olmalıdır. Emin değilseniz Gartner heyecan döngüsü harika bir referans noktasıdır ve burada onların hizmetlerine abone olarak başlayabilirsiniz.

Her BT uzmanına uygulanabileceğini düşündüğüm aşağıdaki misyon beyanına odaklandım:

“Zamanınızı fikri mülkiyetinizin değerini artıran özellikler/işlevsellik sunmaya odaklayın. Diğer her şey için çerçevelerden, ürünlerden ve hizmetlerden yararlanın.”

-J.Vester

Render PaaS ekosistemine baktığımda, hem misyon beyanıma uyan, hem de heyecan döngüsü tercihim dahilinde kalan bir çözüm görüyorum.

İşleri daha iyi yapan şey, cepten kişisel masraflarımda %44'lük bir tasarruf görmeyi tamamen beklememdir; hatta hizmetlerimin dikey olarak ölçeklenmesi gerektiğinden daha da fazla.

Barındırma çözümleri düşünenler için, inceleme ve analiz için sağlayıcılar listesine Render'ı eklemelerini öneririm. Bu bağlantıyı takip ederek ücretsiz olarak başlayabilirsiniz.

Bu serinin ikinci bölümü heyecanlı olacak. Angular'da yazılmış statik istemcim için ödeme yapmaktan nasıl kurtulacağımı ve Vue veya Svelte'yi kullanarak Render'ın ücretsiz Statik Siteler hizmetinden nasıl yararlanacağımı göstereceğim. Hangi çerçeveyi seçeceğim… ve neden?

Gerçekten harika bir gün geçirin!