Tạm biệt Cloud Development Environment (CDE) với gói Flexible Plan của UpCloud

Câu chuyện xây dựng Cloud Development Environment cùng UpCloud

Cuối năm 2019 nhóm chúng tôi có 5 thành viên ở Việt Nam do một công ty có trụ sở ở Nhật Bản lần đầu mở rộng nhân sự ra nước ngoài bằng việc thuê nhân sự ngồi làm việc từ Việt Nam, văn phòng mới chỉ là tạm thuê chưa ổn định có thể điều chỉnh theo nhu cầu nhận sự của các tháng sắp tới, nên việc mua sắm và setup máy móc chưa sẵn sàng, do đó sếp đã quyết định mọi người sẽ sử dụng "Cloud Development Environments" (CDE).

Khái niệm này rất đơn giản: thay vì source code, tài nguyên và môi trường chạy dự án nằm trên máy cá nhân của mỗi người (local development), tất cả sẽ được đặt gọn gàng trên một "cloud server". Nhà cung cấp cloud server thì rất nhiều, cả trong lần ngoài nước và chúng tôi được chỉ định sử dụng UpCloud với sản phẩm Flexible Plans.

Tại sao lại Upcloud (nhà cung cấp hạ tầng đến từ Phần Lan) mà không phải một nhà cung cấp từ Việt Nam

Đây là câu hỏi mà nhiều người thắc mắc, lý do nằm ở tính năng họ có và chi phí tối ưu thời điểm đó.

Thời điểm đó Upcloud offer một sản phẩm đó là Cloud server with flexible plan , tức là chúng tôi có thể tùy ý điều chỉnh cấu hình sau khi server đã deploy: như tăng giảm CPU, RAM, đăng ký thêm thêm storage nếu cần, và quan trọng là tính tiền sử dụng tài nguyên theo giờ.

Tính năng tính tiền sử dụng theo giờ có lẽ chính là điểm khác biệt lúc đó: họ tính tiền cố định với tài nguyên như storage, IPv4, nhưng thời gian sử dụng CPU và RAM chỉ tính khi server bật, server tắt sẽ không tính vào chi phí. Thử làm một phép toán tiết kiệm: Nếu một dev chỉ làm việc 8 tiếng/ngày, 5 ngày/tuần, họ sẽ tiết kiệm được một khoản chi phí kha khá so với việc trả tiền cho tài nguyên chạy 24/7.

Thời điểm đó hay cả một vài năm sau cũng một số nhà cung cấp ở Việt Nam đã liên hệ và gợi ý việc chuyển đổi nhưng điểm duy nhất họ hơn đó là: tốc độ kết nối vì truyền tải trong nước, còn với upcloud chúng tôi phải kết nối qua tài nguyên bên Singapore. Tính năng bật tắt server trực tiếp trên UI cũng có nhưng dù có tắt server cách tính chi phí cũng là cố định chứ không theo giờ được, chi phí họ cũng offer cắt giảm N % để đạt với giá mà chúng tôi đang dùng của Upcloud với server đặt tại Sing nhưng để có thể thuyết phục được sếp chuyển đổi thì là chưa đủ.

Các bước "nhập môn" (onboard) với thành viên với Cloud Development Environment

• Trước tiên họ cần deploy một cloud server với cấu hình cơ bản được thống nhất từ trước. Bước này thì đăng nhào upcloud rồi thao tác vài bước trên giao diện là xong.
• Chạy set up script: Chạy một Shell Script chung đã chuẩn bị sẵn để cài đặt các công cụ cần thiết như Docker, gcloud CLI, Node version control, Firebase tools, v.v.
• Thiết lập SSH config: Tạo SSH key và thiết lập cấu hình để máy cá nhân (local) có thể ssh vào cloud server. Ngoài ra, chúng tôi thiết lập SSH Tunnel Forwarding Port, điều này giống như việc bạn xây dựng một đường ống kết nối giữa máy local và cloud: các port của DB, dịch vụ Backend hay Frontend đang chạy trên server sẽ được chuyển hướng để có thể truy cập chúng qua chính localhost trên máy cá nhân. Đảm bảo cảm giác "local" nhất có thể.
• Thiết lập bảo mật cơ bản cho Cloud Server: chỉ cho phép ssh lên server thông qua key, không cho phép sử dụng password, thiết lập firewall với tập rule được chia sẻ đảm bảo rằng chỉ tin tưởng một số IP nhất định, và một số port nhất định, ngoài ra còn một số quy định khác với application environment, đơn giản như không chấp nhận empty password nếu setup mysql với docker chẳng hạn.
• Kết nối IDE: Công đoạn cuối cùng là kết nối code. Thay vì chạy code trên local, chúng tôi sử dụng VS Code trên máy cá nhân, kết nối với source code trên cloud server thông qua extension Remote - SSH của Microsoft.

Nghe thì có vẻ phức tạp với nhiều anh em chưa quen với thao tác trên cloud server, nhưng mọi thao tác trên có hướng dẫn và cũng khá dễ làm theo, việc cài đặt có thể hoàn tất trong vài chục phút là chúng ta đã có thể bắt tay vào thiết lập và chạy thử dự án.

Quản lý chi phí cũng như thao tác thay đổi trạng thái Upcloud development server

Như đã nói thì upcloud server tính tiền hạ tầng theo giờ sử dụng, vậy vấn đề là làm sao để anh em Dev không quên tắt server khi hết giờ làm việc? Việc này giống như việc phải nhớ "tắt đèn khi ra khỏi nhà" để tiết kiệm điện vậy.

UpCloud cung cấp Open API, và chúng tôi đã tận dụng nó để viết một ứng dụng nhỏ, tích hợp với Slack (công cụ chat nội bộ). Chỉ cần gõ một slash command đơn giản trên Slack:

• Bật/tắt server mà không cần phải đăng nhập vào UpCloud.
• Tự động kiểm tra và tắt server của tất cả mọi người vào 18:00 hàng ngày.
• Gõ lệnh để gia hạn thời gian tắt máy nếu có nhu cầu làm thêm giờ.

Hệ thống hẹn giờ này vừa tiện lợi, vừa đảm bảo chi phí luôn được kiểm soát chặt chẽ, tránh những khoản phí không đáng có. Upcloud không những cung cấp giao diện người dùng, mà cả openapi để tương tác với các trạng thái của cloud server cũng rất hiệu quả, đây cũng là điểm khác biệt mà các nhà cung cấp sau này chúng tôi có liên hệ nhưng họ đều chưa sẵn sàng (cũng có thể chúng tôi chưa đủ nguồn lực để tìm hiểu hết) ít nhất là các nhà cung cấp trong nước khi đó.

Như vậy là tạm ổn, chi phí cloud server trên mỗi nhân sự rơi vào khoảng 30$ mỗi tháng.

Thuận Lợi và Khó Khăn: Giữa Cloud và Local

Sau thời gian sử dụng và trải nghiệm thì những điểm tôi đánh là thuận lợi và khó khăn với "cloud development environment" (CDE) như sau:

Thuận lợi/Phù hợp:

• Tôi nghĩ CDE phù hợp với chúng tôi ở tính thời điểm, khi số lượng nhân sự còn nhỏ, việc đầu tư ngay vào máy móc là chưa thực sự sẵn sàng. Anh em cũng có kinh nghiệm và khả năng làm quen với cloud server cũng khá nhanh.
• Linh hoạt cấu hình: Với server flexible plan đã lựa chọn thì có thể điều chỉnh cấu hình máy theo cá nhân khi nhu cầu tăng lên, so với máy local thì chắc là đổi máy hoặc tính toán một cấu hình phù hợp cho một vài năm sau ngay từ đầu.
• Chia sẻ tài nguyên: Có thể dễ dàng chia sẻ tài nguyên cũng như kiểm thử sớm và từ xa: ví dụ một vài ông có thể không cần cài đặt database vì nhu cầu đặc thù, họ chỉ cần connect đến DB của một ai đó trong team thông qua trực tiếp Public IP, và tất nhiên ông nào đang vận hành cloud server đó thì cần thiết lập firewall để mở port cũng như thêm địa chỉ IP của ông connect tới và whitelist rồi.
• Ít phụ thuộc vào máy cá local: Có đổi máy cá nhân thì cũng không cần cài lại các dự án cũ, vốn vẫn nằm trên cloud server. Bạn có thể thiết lập để cho phép nhiều máy tính local của mình có thể connect tới cloud server, điều này vừa giảm thiểu rủi ro mất ssh key không thể kết nối lại cũng như thuận tiện cho công việc remote hoặc di chuyển khi đi công tác. Bạn chỉ cần một máy tính có kết nối ssh được với cloud server là có thể làm việc.
• Cơ hội cho anh em vọc vạch cloud: Một cơ hội tuyệt vời để các dev làm quen với public cloud, thử nghiệm các công nghệ mới như K3s mà không làm ảnh hưởng đến máy local.
• Với góc nhìn công ty: về chi phí mỗi tháng cho một máy cloud server như vậy sử dụng trong giờ hành chính là khoảng 25-30$ cho máy đặt ở region Singapore. Như vậy một năm chi phí một máy sẽ cần khoảng 8 - 9 triệu đồng, sử dụng 3 năm cũng có thể coi là khấu hao bằng một chiếc máy cá nhân. Về lâu dài nếu máy cái nhân dùng không hỏng hóc thì sau 3 năm tôi nghĩ máy cá nhân sẽ có chi phí đầu là ưu việt so với CDE.
• Với CDE thì team secure có thể truy cập trực tiếp đi scan định kỳ hoặc ngẫu nhiên không báo trước được.

Khó khăn/không phù hợp:

• Gánh nặng bảo mật:: Tôi nghĩ điều đầu tiên nhắc tới đó phải là bảo mật. Khi số lượng nhân sự là 5 bạn có 5 CDE cần quản lý, khi con số đó tăng lên 10-20 thì số lượng CDE bạn cần kiểm soát tăng lên. Mặc dù có những rule hay qui định chung rồi thì việc phải audit lại rule, cập nhật thường xuyên theo tình hình thời cuộc là cần thiết và tốn kém. Cũng như đào liên tục để nâng cao nhận thức của mọi người.
• Vấn đề bảo mật ở con người: Thật khó để yêu cầu mọi người đều hiểu rõ về bảo mật trên cloud server, ví dụ như một Frontend developer - bạn ấy có thể biết cloud server cơ bản, nhưng bảo mật thì chưa chắc, đây là một cloud server và nó có kết nối public internet, nếu những thiết lập bảo vệ không chặn chẽ rất dễ bị tấn công mạng. Đơn giản và thường gặp nhật như là brute force attack password checker hay scan opening port.
• Chi phí ẩn: Khi số lượng nhân sự tăng, chi phí có thể bùng nổ. Đặc biệt là chi phí Transfer Network Out (dữ liệu truyền ra khỏi Cloud Server). Nếu không kiểm soát chặt chẽ hoặc bị tấn công, con số này có thể "cắn" sâu vào ngân sách hạ tầng một cách vô hình.
• Nỗi ám ảnh "cá mập cắn cáp": Đây là điểm chí mạng! Vì server đặt ở Singapore, mọi thao tác SSH, gõ lệnh đều phải thông qua Internet. Khi đường truyền mạng Việt Nam gặp vấn đề đi quốc tế, trải nghiệm gõ lệnh trên CDE sẽ chậm như "rùa bò" thì sẽ tạo ra một trải nghiệm khá tệ.

Trở về với local development nhưng vẫn giữ một số cloud development

Hiện tại, team đã dần dịch chuyển trở lại với Local Development trên máy tính cá nhân. Khi vấn đề bảo mật trở nên quan trọng hơn, và rủi ro về chi phí Cloud có thể bùng phát là hiện hữu, sự an toàn và ổn định của máy local lại được ưu tiên.

Cũng như một thực tế là chi phí mua máy móc, phần cứng đang tốt hơn cho người mua.

Chúng tôi chỉ giữ lại CDE cho một số dự án hoặc nhân sự có nhu cầu đặc thù. Dù sao, trải nghiệm "Cloud Development Environment" bằng UpCloud cũng là một kỷ niệm đáng nhớ, giúp team vượt qua giai đoạn khó khăn ban đầu và học được rất nhiều về việc quản lý hạ tầng và chi phí.

Tạm kết

Lựa chọn CDE của chúng tôi là một giải pháp hoàn hảo cho tính thời điểm, ưu tiên tính linh hoạt chi phí. Nhưng về lâu dài, khi quy mô tăng, tính ổn định (tốc độ mạng) và bảo mật đã đưa chúng tôi trở về với những chiếc máy tính cá nhân quen thuộc.

Về sản phẩm flexible plan server của Upcloud đã dừng với người dùng đăng ký mới dịch vụ, nhưng họ vẫn tiếp tục với những user đang sử dụng flexible plan server nghĩa là chúng ta không bị ảnh hưởng, nhưng lại không còn nhiều nhu cầu. Thay vào đó họ cung cấp tới các compute server đã được tùy chọn sẵn cấu hình cho các mục đích khác nhau tùy nhu cầu ưu tiên Memory hay CPU, với một mức giá cố định kèm với "zero-cost transfer" tức là chi phí đã bao gồm cả phần transfer network data. Sản phẩm này cũng khá là hay với anh em hoặc tổ chức chưa có nhiều kinh nghiệm quản lý cloud cost, vì đôi khi việc deploy những dịch vụ cơ bản thì khá dễ dàng rồi, vấn đề chi phí phát sinh thường xảy ra trong quá trình vậy hành tùy vào mức độ sử dụng.

GitHub Codespaces gets you up and coding faster with fully configured, secure cloud development environments native to GitHub.

Về CDE: Bạn có thể tìm hiểu và trải nghiệm thêm với "GitHub Codespaces" - thời điểm 2020 mới chỉ là bản Beta nên chúng tôi chưa thử ở lúc đó.