Time For Me To Fly… To Render

Chu kỳ cường điệu của Gartner , được minh họa bên dưới, có thể được áp dụng cho hầu hết các khía cạnh của công nghệ:

Khi những cải tiến mới bước vào chu kỳ tương ứng của chúng, những kỳ vọng cuối cùng cũng được hiện thực hóa—dẫn đến một số mức độ áp dụng.

Mục tiêu của mọi đổi mới là đạt được mức cao nhất về năng suất khi người tiêu dùng đã xác định rằng phần thưởng của việc áp dụng đổi mới vượt xa mọi rủi ro đã biết.

Đồng thời, có một thời điểm mà cao nguyên năng suất bắt đầu giảm dần, dẫn đến một cuộc di cư khỏi sự đổi mới đó. Một ví dụ đơn giản là máy nhắn tin (hoặc máy nhắn tin), vốn phổ biến trước khi điện thoại/thiết bị di động đạt đến đỉnh cao về năng suất.

Là các nhà công nghệ, chúng tôi cố gắng cung cấp các tính năng, khuôn khổ, sản phẩm hoặc dịch vụ giúp tăng năng suất ổn định. Điều tương tự cũng đúng với những cái mà chúng ta sử dụng.

Gần đây, tôi cảm thấy như nền tảng lưu trữ hiện tại của mình bắt đầu giảm năng suất. Trên thực tế, một thông báo gần đây khiến tôi tự hỏi liệu đã đến lúc xem xét các lựa chọn khác hay chưa.

Vì tôi đã có trải nghiệm tích cực khi sử dụng Render PaaS, nên tôi muốn xem tôi có thể chuyển đổi một trong các ứng dụng Heroku của mình dễ dàng như thế nào, sử dụng PostgreSQL và chuyển sang Render. Tôi đang mô tả cuộc hành trình đó trong loạt bài gồm hai phần này:

• Phần 1: Chúng tôi sẽ tập trung vào việc di chuyển các dịch vụ phụ trợ của tôi (Spring Boot và ClearDB MySQL).
• Phần 2: Chúng tôi sẽ tập trung vào việc chuyển và di chuyển ứng dụng khách Angular giao diện người dùng của tôi.

Tại sao tôi chọn Render

Nếu bạn chưa bao giờ nghe nói về Render trước đây, hãy xem một số ấn phẩm trước đây của tôi:

• Không tốn thời gian cho DevOps với Render PaaS

• Đám mây hoàn hảo: AWS, GCP và Azure tất cả trong một

• Thiết kế microservice theo mục đích

• Khởi động ý tưởng khởi nghiệp của bạn trong một ngày

• Cách tôi sử dụng kết xuất để mở rộng quy mô ứng dụng Microservices của mình một cách dễ dàng

Điều tôi thấy thú vị về Render là họ tiếp tục leo lên con dốc của sự khai sáng trong khi tích cực cung cấp giải pháp vững chắc cho những người chấp nhận nhận ra mức cao nhất của năng suất.

Như tôi đã lưu ý trong các bài viết của mình, Render đưa ra lời hứa “Zero DevOps”. Điều này hoàn toàn phù hợp với nhu cầu của tôi vì tôi không có thời gian tập trung vào các nhiệm vụ DevOps.

Nền tảng Heroku có một số thứ mà tôi không thích lắm:

• Khởi động lại hàng ngày dẫn đến thời gian ngừng hoạt động không mong muốn cho một trong các dịch vụ của tôi.

• Cấp đầu vào (tất cả những gì tôi thực sự cần) Postgres trên Heroku cho phép bốn giờ ngừng hoạt động mỗi tháng.

• Mức giá, từ góc độ người tiêu dùng, không mở rộng quy mô tốt.

Từ góc độ định giá, tôi hy vọng sẽ tiết kiệm được đáng kể chi phí sau khi di chuyển tất cả các ứng dụng và dịch vụ của mình từ Heroku sang Render. Điều tuyệt vời hơn là tôi đang nhận được bộ nhớ và CPU tốt hơn với mức giá đó, với khả năng mở rộng tuyến tính khi lượng ứng dụng của tôi cần tăng lên.

Chuyển đổi một dịch vụ duy nhất

Như tôi đã lưu ý ở trên, đây là phần một của loạt bài gồm hai phần và tôi sẽ tập trung vào cấp dịch vụ trong bài viết này. Dịch vụ tôi muốn chuyển đổi có các thuộc tính sau:

• Khởi động mùa xuân Dịch vụ API RESTful

• Trình môi giới tin nhắn Heroku CloudAMQP (RabbitMQ)

• Cơ sở dữ liệu Heroku ClearDB (MySQL) (lược đồ đơn)

• Tích hợp Okta

Về phía Render PaaS, thiết kế dịch vụ mới sẽ như sau:

• Kết xuất Dịch vụ web lưu trữ Dịch vụ API Spring Boot RESTful (thông qua Docker)

• Kết xuất dịch vụ riêng lưu trữ RabbitMQ Message Broker (thông qua Docker)

• Kết xuất Postgres với khả năng tồn tại nhiều lược đồ

• Tích hợp Okta

Dưới đây là so sánh song song của hai hệ sinh thái:

Kế hoạch tấn công cấp cao của tôi để chuyển đổi như sau:

Chuẩn bị Heroku để chuyển đổi

Trước khi bắt đầu, bạn nên đặt tất cả các dịch vụ Heroku hiện có vào Chế độ bảo trì . Điều này sẽ cấm bất kỳ người tiêu dùng nào truy cập vào các ứng dụng hoặc dịch vụ.

Mặc dù mã nguồn đã được sao lưu và lưu trữ trong kho lưu trữ dựa trên git, nhưng bạn nên đảm bảo rằng bản sao lưu cơ sở dữ liệu đã được tạo thành công.

Chuyển đổi Dịch vụ Heroku

Từ góc độ chuyển đổi, tôi có hai mục cần chuyển đổi: bản thân dịch vụ và cơ sở dữ liệu ClearDB (MySQL).

Việc chuyển đổi dịch vụ Spring Boot RESTful của tôi không liên quan nhiều đến công việc. Trên thực tế, tôi đã có thể tận dụng cách tiếp cận mà tôi đã sử dụng cho một dự án trước đây của mình.

Đối với cơ sở dữ liệu, tôi cần chuyển đổi từ MySQL sang PostgreSQL. Mục tiêu của tôi là sử dụng Trình di chuyển Heroku của Kết xuất để dễ dàng di chuyển Heroku Postgres sang Kết xuất Postgres, nhưng trước tiên tôi cần chuyển đổi từ MySQL sang PostgreSQL.

Ban đầu, tôi bắt đầu sử dụng đường dẫn pgloader , đây dường như là cách tiếp cận phổ biến để chuyển đổi cơ sở dữ liệu. Tuy nhiên, việc sử dụng MacBook Pro chip M1 của tôi đã dẫn đến một số sự cố không mong muốn.

Thay vào đó, tôi đã chọn sử dụng NMIG để chuyển đổi MySQL sang PostgreSQL. Để biết thêm thông tin, vui lòng xem phần “ Điểm nổi bật từ chuyển đổi cơ sở dữ liệu ” bên dưới.

Tạo dịch vụ trong Render

Sau khi chuyển đổi cơ sở dữ liệu và dịch vụ Spring Boot RESTful chạy bên trong Docker, bước tiếp theo là tạo Render Web Service cho dịch vụ Spring Boot RESTful API.

Điều này dễ dàng như việc tạo dịch vụ, đặt tên cho dịch vụ và trỏ đến kho lưu trữ thích hợp cho mã của tôi trong GitLab.

Vì tôi cũng cần một dịch vụ RabbitMQ nên tôi đã làm theo các hướng dẫn sau để tạo một Dịch vụ riêng của RabbitMQ chạy trên Render. Điều này bao gồm việc thiết lập một lượng nhỏ dung lượng lưu trữ trên đĩa để lưu giữ các thư chưa được xử lý.

Cuối cùng, tôi đã tạo các biến môi trường cần thiết trong Bảng điều khiển kết xuất cho cả dịch vụ Spring Boot RESTful API và trình môi giới thông báo RabbitMQ.

Khởi tạo và xác thực dịch vụ

Bước tiếp theo là bắt đầu các dịch vụ của tôi. Khi chúng đang chạy và các API được xác thực bằng bộ sưu tập Postman của tôi, tôi đã cập nhật ứng dụng khách của mình để trỏ đến vị trí dịch vụ Kết xuất mới.

Khi mọi thứ đã sẵn sàng và chạy, Render Dashboard của tôi xuất hiện như hình bên dưới:

Bước tiếp theo

Tất cả những gì còn lại vào thời điểm này là xóa cơ sở dữ liệu vẫn đang chạy trên Heroku và xóa các dịch vụ đã di chuyển khỏi hệ sinh thái Heroku.

Khi sử dụng Heroku, bất kỳ lúc nào tôi hợp nhất mã vào nhánh chính của kho lưu trữ dịch vụ của mình, mã sẽ tự động được triển khai, miễn là tôi đã sử dụng GitLab CI/CD để triển khai lên Heroku trong kho lưu trữ nguồn của mình.

Tuy nhiên, không cần thêm mã vào kho lưu trữ tệp nguồn bằng Render. Tôi chỉ cần chỉ định Nhánh Xây dựng & Triển khai trong Bảng điều khiển kết xuất cho dịch vụ:

Tôi thích lời hứa Zero DevOps.

Điểm nổi bật từ chuyển đổi cơ sở dữ liệu

Bằng cách làm theo các bước trên, quá trình chuyển đổi từ Heroku sang Render diễn ra suôn sẻ và thành công. Thách thức lớn nhất đối với tôi là chuyển đổi dữ liệu. Ở cấp độ cao, điều này chủ yếu được rút gọn thành một loạt lệnh được thực thi từ thiết bị đầu cuối của MacBook Pro của tôi.

Đầu tiên, tôi bắt đầu một phiên bản Postgres cục bộ thông qua Docker:

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

Tiếp theo, tôi đã tạo một cơ sở dữ liệu có tên là “ví dụ” bằng cách sử dụng lệnh sau (hoặc pgAdmin):

 createdb example

Để chuyển đổi phiên bản ClearDB (MYSQL) đang chạy trên Heroku sang cơ sở dữ liệu Postgres mẫu chạy cục bộ, tôi đã sử dụng NMIG , đây là một tiện ích chuyển đổi cơ sở dữ liệu dựa trên Node.js.

Sau khi cài đặt NMIG, tôi thiết lập tệp config.json với thông tin xác thực và thông tin điểm cuối cơ sở dữ liệu, sau đó tôi chạy:

 /path/to/nmig$ npm start

Tiếp theo, tôi sao lưu dữ liệu vào một tệp bằng lệnh sau:

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

Thay vì gặp rắc rối khi tạo một URL đã ký trong AWS, tôi chỉ sử dụng ứng dụng khách pgAdmin để nhập bản sao lưu vào một phiên bản Postgres mới được tạo trên Heroku.

Với phiên bản Postgres đang chạy và dữ liệu đã được xác thực, tôi đã tạo một cơ sở dữ liệu Postgres mới trên Render PaaS. Sau đó, tất cả những gì tôi phải làm là đưa ra lệnh sau:

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

Bài học kinh nghiệm dọc đường

Nhìn lại quá trình chuyển đổi của tôi từ Heroku sang Render, đây là một số bài học tôi đã học được trong suốt quá trình:

• Tôi gặp sự cố nhỏ với cơ sở dữ liệu Postgres cập nhật giá trị ngày/giờ để bao gồm phần bù DST. Đây có thể là một vấn đề với thiết kế cơ sở dữ liệu ban đầu của tôi, nhưng tôi muốn vượt qua vấn đề này. Trong trường hợp của tôi, cột bị ảnh hưởng chỉ được sử dụng cho các giá trị Ngày, giá trị này không thay đổi đối với tôi.

• Tôi đã bao gồm một cột cơ sở dữ liệu có tên END trong một trong các bảng của mình, điều này đã gây ra sự cố khi Postgres hoặc Hibernate cố gắng trả về một truy vấn gốc. Dịch vụ đã thấy tên cột KẾT THÚC và thêm nó làm từ khóa SQL. Tôi chỉ đơn giản đổi tên cột để khắc phục sự cố này, điều mà lẽ ra tôi không nên làm ngay từ đầu.

• Với Render, tôi cần đặt dịch vụ RabbitMQ thành Dịch vụ riêng vì tùy chọn Dịch vụ web không hiển thị cổng dự kiến. Tuy nhiên, với phương pháp này, tôi đã mất khả năng truy cập giao diện quản trị RabbitMQ, vì Dịch vụ riêng tư không được hiển thị bên ngoài. Có vẻ như Render có kế hoạch giải quyết yêu cầu tính năng này.

Nhìn chung, những rào cản nhỏ này không đủ quan trọng để ảnh hưởng đến quyết định chuyển sang Render của tôi.

Phần kết luận

Khía cạnh quan trọng nhất trong năng suất ổn định của Gartner là cung cấp các sản phẩm, khuôn khổ hoặc dịch vụ cho phép người tiêu dùng phát triển và đáp ứng các mục tiêu của họ. Cao nguyên của năng suất không nhằm mục đích hào nhoáng hay hợp mốt — theo nghĩa ẩn dụ.

Khi tôi chia sẻ kết luận này với Ed, Người ủng hộ nhà phát triển tại Render, phản hồi của anh ấy là điều tôi muốn chia sẻ:

“Render rõ ràng là không cố gắng trở thành 'thời trang'. Chúng tôi đang cố tỏ ra không ngạc nhiên và đáng tin cậy.”

Câu trả lời của Ed gây ấn tượng sâu sắc với tôi và khiến tôi nhớ lại thời điểm đồng nghiệp cũ của tôi nói với tôi rằng mã của tôi khiến anh ấy thấy “nhàm chán”. Nhận xét của anh ấy hóa ra là lời khen tuyệt vời nhất mà tôi có thể nhận được. Bạn có thể đọc thêm ở đây .

Trong bất kỳ khía cạnh nào của công nghệ, quyết định chọn nhà cung cấp nào phải luôn phù hợp với vị trí công nghệ của bạn. Nếu bạn không chắc chắn, chu kỳ cường điệu của Gartner là một điểm tham khảo tuyệt vời và bạn có thể bắt đầu đăng ký dịch vụ của họ tại đây .

Tôi đã tập trung vào tuyên bố sứ mệnh sau đây mà tôi cảm thấy có thể áp dụng cho bất kỳ chuyên gia CNTT nào:

“Hãy tập trung thời gian của bạn vào việc cung cấp các tính năng/chức năng giúp mở rộng giá trị tài sản trí tuệ của bạn. Tận dụng các khuôn khổ, sản phẩm và dịch vụ cho mọi thứ khác.”

- J. Vester

Khi tôi xem xét hệ sinh thái Render PaaS, tôi thấy một giải pháp tuân thủ tuyên bố sứ mệnh của mình trong khi vẫn nằm trong sở thích chu kỳ cường điệu của tôi.

Điều khiến mọi thứ trở nên tốt hơn là tôi hoàn toàn kỳ vọng sẽ tiết kiệm được 44% chi phí tự trả của cá nhân mình — thậm chí còn nhiều hơn khi các dịch vụ của tôi cần mở rộng quy mô theo chiều dọc.

Đối với những người đang xem xét giải pháp lưu trữ, tôi khuyên bạn nên thêm Render vào danh sách các nhà cung cấp để xem xét và phân tích. Bạn có thể bắt đầu miễn phí bằng cách nhấp vào liên kết này .

Phần thứ hai của loạt bài này sẽ rất thú vị. Tôi sẽ trình bày cách điều hướng khỏi việc trả tiền cho ứng dụng khách tĩnh được viết bằng Angular và tận dụng dịch vụ Trang web tĩnh miễn phí của Render bằng cách sử dụng Vue hoặc Svelte. Tôi sẽ chọn khung nào… và tại sao?

Có một ngày thực sự tuyệt vời!