Trước khi bắt tay vào thực hiện các tác vụ chính, chúng ta cần xem xét đánh giá lại tại hệ thống tại on premise. Chúng ta cần hiểu rõ hệ thống hiện tại bao gồm những thành phần gì, hoạt động ra làm sao, có những điểm yếu gì cần khắc phục trước khi đưa lên cloud. Tất nhiên bạn đã phải nắm rõ nó trong lòng bàn tay. Các việc mà mình đã xem xét đánh giá hệ thống tại on premise bao gồm:

1. Liệt kê danh sách các ứng dụng được đưa lên cloud

Đây chính là việc mình chuẩn bị đầu tiên. Chúng ta cần biết được những ứng dụng nào sẽ được đưa lên cloud, những ứng dụng nào sẽ ở lại hệ thống on premise. Nắm bắt được chính xác các ứng dụng được đưa lên cloud sẽ giúp bạn tránh việc lặp lại quy trình và các rắc rối trong toàn bộ quá trình. Hãy ngồi lại với đội Dev, đội QC để thảo luận về vấn đề này. Với mình thì sẽ lên một danh sách tất cả các ứng dụng hiện có, xong đưa cho Dev lead và anh sếp mình là CTO để xác nhận các ứng dụng được đưa lên. Các thông tin trong file sẽ bao gồm:

• Tên ứng dụng
• Repo
• Domain ứng dụng
• Domain nội bộ (nếu có)
• Whitelist
• Database
• Redis
• RabbitMQ
• Note Mĩnh nghĩ là sẽ còn nhiều thông tin nữa cần phải được list tùy thuộc vào mỗi hệ thống. Quan trọng là bạn hiểu rõ được ứng dụng của mình.

2. Các thành phần của ứng dụng

Khi bạn đã lên được cái danh sách các ứng dụng ở trên kia thì bạn cũng đã có câu trả lời cho phần này rồi. Một ứng dụng hoàn chỉnh thường sẽ có các thành phần như web, api, database, middleware như cache, message queue. Database thường sẽ có 2 loại là sql và nosql có thể kể đến như mysql, postgres, mongodb,... Bạn liệt kê sẵn các tên database, các kết nối hoặc các thành phần credentials sẽ có ích cho các bước sau.

3. Khả năng tương thích trên cloud

Khi bạn xây dựng các thành phần đó tại on premise thường sẽ build từ source. Nhưng trên môi trường cloud, đa số chúng ta sẽ prefer các managed service có sẵn. Vì vậy hay kiểm tra xem nếu bê nguyên cái app đó lên cloud, nó có work với các managed service đó không. Các thông tin có thể phải xem xét như:

• Version: Hãy đảm bảo ứng dụng của bạn tương thích tốt với version của các managed service. Nếu version của các thành phần đó tại on premise đã cũ quá hoặc unsupported, bạn hãy request đội dev upgrade code để tương thích với version cao hơn. Ví dụ với redis thì một số app bên mình vẫn dùng version 6.x mà trên cloud thì version tối thiểu là 7.0 . Mình phải dựng một cụm redis 7.0 mới tại on premise để cho đội dev tích hợp.

• SSL/TLS: Cái này thì mình thấy gặp nhiều hơn. Các hệ thống cũ thường không sử dụng tls đi kèm với authentication mode nào khiến cho tính security không được đảm bảo. Các managed service trên cloud thì mặc định sử dụng kết nối TLS thay cho tcp. VÌ vậy một công đôi việc chúng ta hãy nâng cấp bảo mật cho hệ thống của mình nhé. Với bên mình thì cần nâng cấp kết nối TLS cho Redis, RabbitMQ. Một số kinh nghiệm trong quá trình thay đổi của mình và đội dev (php) như sau:

  ❗️ Sử dụng predis/predis bản mới stable nhất là 2.2

  ❗️ Laravel/lumen: nên update bản 8.0 trở lên để phù hợp vs predis 2.2 trên, với lumen thì nên update thêm package illuminate/redis v8 nữa.

  ❗️ Nếu cài predis 2.2 mà không nâng ver của laravel hoặc lumen thì sẽ dễ gặp phải case:

   `AUTH failed: ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct?`
  

  👉️Nguyên nhân có vẻ là do bản redis server 6 trở lên sẽ hỗ trợ thêm phần ACL (access control list), và mặc định sử dụng username là default. Và predis bản mới 2.2 sẽ không nhận được các setup username/password từ laravel/lumen bản cũ hỗ trợ các thông tin đó. Đối với các ngôn ngữ khác (golang, node) thì mình không gặp vấn đề gì nghiêm trọng.

• Phân chia write/read cho database: Cái này bạn hãy khuyến nghị đội dev phân chia rõ ràng 2 luồng read/write của ứng dụng để tận dụng triệt để khả năng của cloud.

Tóm lại: Đây là khâu rất quan trọng và mất phần lớn thời gian trong việc dịch chuyển ứng dụng lên cloud. Việc phải upgrade code đối với các ứng dụng đã lâu không được phát triển không hề dễ dàng. Ngoài ra đội dev vẫn phải làm các task khác về business bên cạnh việc refactor code cũ. Tại bước này cần kết hợp nhuần nhuyễn giữa các team devops - dev - qc. Hãy kiên trì cho đến khi các ứng dụng sẵn sàng được đưa lên. Lúc đó chúng ta cũng sẽ sẵn sàng!