Aşağıda gösterilen teknolojinin birçok yönüne uygulanabilir: Gartner heyecan döngüsü 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 (veya çağrı cihazları) olabilir. çağrı cihazları 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 , diğer seçenekleri değerlendirmenin zamanının gelip gelmediğini merak etmeme neden oldu. yakın zamanda yapılan bir duyuru 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: Render 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 getirilmesi önerilir. Bu, tüketicilerin uygulamalara veya hizmetlere erişmesini yasaklayacaktır. Bakım Moduna 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 kullandığım yaklaşımdan faydalanabildim. daha önceki bir projemde 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 kullanmaktı, ancak önce MySQL'den PostgreSQL'e dönüştürmem gerekiyordu. Heroku Migrator'unu Başlangıçta, veritabanı dönüşümü için yaygın bir yaklaşım gibi görünen yolundan başladım. Ancak M1 çipli MacBook Pro'mu kullanmak bazı beklenmedik sorunlara yol açtı. pgloader Bunun yerine MySQL'i PostgreSQL'e dönüştürmek için kullanmayı tercih ettim. Daha fazla bilgi için lütfen aşağıdaki “ Noktalar” bölümüne göz atın. NMIG'yi Veritabanı Dönüşümünden Önemli 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 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. bu talimatları Son olarak Render Dashboard'da hem Spring Boot RESTful API hizmeti hem de RabbitMQ message broker için gerekli oluşturdum. ortam değişkenlerini 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 kullanmam şartıyla kod otomatik olarak dağıtıldı. Heroku'ya dağıtmak için GitLab CI/CD'yi 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 kullandım. NMIG'yi 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 istemcisini kullandım. pgAdmin Postgres örneği çalışırken ve veriler doğrulandıktan sonra Render PaaS'de . Daha sonra tek yapmam gereken şu komutu vermekti: yeni bir Postgres veritabanı oluşturdum pg_restore --verbose --no-acl --no-owner -d postgres://username:password@hostname.zone-postgres.render.com/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 karşılamayı planlıyor. özellik isteğini 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 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ı okuyabilirsiniz. eski meslektaşımın buradan 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 onların hizmetlerine abone olarak başlayabilirsiniz. burada 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. takip ederek ücretsiz olarak başlayabilirsiniz. Bu bağlantıyı 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!

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

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

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

Çok uzun; Okumak

@johnjvester

İLGİLİ ÖYKÜLER