Series Nhận diện Idol: Phần 6.1 – Luận về Serverless – Vô Thai Kiếm

Toàn bộ series Nhận diện Idol:

Như đã nói trong bài đầu của series, mình áp dụng kiến trúc serverless trong thiết kế hệ thống. Kiến trúc này giúp ứng dụng có thể đáp ứng hàng triệu người truy cập với giá thành vô cùng rẻ. Trước khi bắt tay vào code, ta hãy cùng tìm hiểu khái niệm và kiến trúc Serverless nhé.

Serverless là cái chi chi?

Serverless được dùng để chỉ 2 khái niệm khác nhau (nhưng lại khá liên quan với nhau):

  1. Một số ứng dụng chuyển phần lớn logic về front-end, không có server để làm back-end (serverless)  mà chỉ sử dụng các API của bên thứ 3 để thay thế. Ví dụ trong Nhận diện Idol, mình không viết code trên server mà dùng API của Cloudinary upload ảnh và Firebase để hiển thị realtime. Nhiều ứng dụng di động cũng dùng kiến trúc này (Backend as a Service – BaaS).
  2. Một số trường hợp khác, lập trình viên phải tự viết code để làm back-end. Với mô hình client-server thông thường, ta phải thuê server rồi deploy ứng dụng lên server. Với mô hình serverless, thay vì deploy code này lên server, ta deploy nó đưới dạng một Function (Function as a Service – FaaS). Funtion này có thể được gọi dưới dạng RestAPI hoặc chạy theo lịch đã sắp sẵn.

Với FaaS, ta chỉ cần viết code mà không cần quan tâm đến việc server và code sẽ nằm ở đâu. Bên thứ 3 (Amazon, Microsoft) sẽ quản lý việc này. Trong Nhận Diện Idol, mình dùng Azure Funtion của Microsoft, viết vài dòng code ngăn ngắn để làm RestAPI.
1-ls17p1mtg51h3gdaeonrw

Hiện tại, khi nói đến serverless, người ta thường nói đến khái niệm thứ hai – FaaS. Năm 2014, Amazon là người đi đầu thị trường khi cung cấp nền tảng serverless mang tên AWS Lambda. Ban đầu nền tảng này chỉ chạy được code Node.js, giờ đây đã mở rộng cho phép chạy code Python, Java, C#.

Năm 2016, Microsoft cũng nhảy vào thị trường, ra mắt Azure Function (chạy được code Node.JS và C#). Ngoài ra, còn một số nền tảng serverless khác như Google Cloud Platform của Foogle, WebTask của oauth.

Client-Server vs Serverless

Ở đây ta sẽ dùng … con gái để so sánh hai kiến trúc. Hãy tưởng tượng mỗi lần người dùng request tới server là một lần “chịch” nhé:

  • Kiến trúc client-server giống như “gấu”: bạn phải dắt gấu đi ăn uống, hằng ngày, đây là phí thuê server. Ngoài ra, ta còn phải bảo trì server bằng cách trò chuyện, tâm sự, lắng nghe gấu. Mỗi lần gấu buồn, không cho chịch, tức server die, coi như ứng dụng của bạn tèo.  Dù có chịch hay ko thì bạn cũng tốn chừng ấy tiền. Ngoài ra, nếu số người dùng tăng lên, tức “nhu cầu chịch” của bạn tăng thì phải chịu khó nâng cấp thêm RAM cho server, thêm quà cho gấu để đáp ứng được nhu cầu.
  • Kiến trúc Serverless lại giống như “hàng”: bạn chẳng cần quan tâm tới việc mua quà, tâm trạng hay bảo trì server, toàn bộ việc đó đã có người khác lo. Nếu không có nhu cầu chịch thì bạn cũng không phải tốn tiền. Chịch bao nhiêu trả tiền bấy nhiêu. Khi nhiều người dùng, nhu cầu chịch tăng lên thì bạn chỉ việc trả thêm tiền. Vì “hàng” nhiều người dùng chung nên giá của serverless rất rẻ so với thuê server, chịch cả triệu lần chỉ tốn… 0.2$ tức khoảng 5.000 VND.
nu-hoang-noi-y-ngoc-trinh-mac-xi-tin-dep-thoi-mien-hinh-3-1470057670645-30-0-287-500-crop-1470057682189
Server kiểu Ngọc Trinh thì bảo trì chắc hết cả tiền….

Mình dùng Azure funtion, mỗi tháng được “chịch” miễn phí 4 triệu phát tức 4 triệu request. AWS Lambda cũng cho phép chịch miễn phí 1 triệu phát mỗi tháng (Phép so sánh vui thôi, không có ý định xúc phạm gì các chị em phụ nữ nhe).

Ưu điểm của Serverless Architecture

Đã nói ở phần trên rồi nên mình tổng kết lại:

  • Giá cả phải chăng: Với kiến trúc client-server, bạn phải thuê server theo tháng. Với kiến trúc Serverless, do chi phí được tính theo số lần gọi Function nên rất rẻ.
  • Dễ scale mở rộng: Khi số lượng request tăng cao, bạn phải nâng cấp server để đảm bảo tốc độ, việc này khá rườm rà mất thời gian. Với Serverless, bên thứ 3 sẽ tự động tạo thêm nhiều process khi có nhiều request .
  • Đơn giản hoá việc code và deploy: Với client-server, bạn phải biết cách build, deploy code lên server, bảo trì và kết nối tới server. Với Serverless, bạn chỉ việc code, mọi việc còn lại sẽ được thực hiện giúp bạn.

Nếu hệ thống tra cứu điểm thi ĐH hay mua vé tàu dùng kiến trúc này thì tốt quá, vừa tiết kiệm được tiền khi ích người dùng, lại không lo nghẽn mạng khi đông khách.

screen-shot-2017-01-16-at-3-36-47-pm
Back-end của Nhận diện Idol, mình thích thì mình bỏ code vô chạy thôi, khỏi lo chuyện deploy. Trăm nghìn request cũng chơi hết.

Nhược điểm

Tất nhiên, đi kèm với ưu điểm, kiến trúc Serverless cũng có một số nhược điểm:

  • Bảo mật: Code của bạn nằm chung chạ với nhiều ứng dụng khác trên một server nên hacker có thể lợi dụng để tấn công.
  • Không phù hợp với một số ứng dụng lớn và phức tạp
  • Performance: Có thể không nhanh bằng code trên server riêng vì code chỉ chạy mỗi khi có request nên sẽ mất khoảng 20-50ms để start-up.
  • Khó debug: Tài nguyên (CPU, RAM) được bên thứ 3 quản lý nên đôi khi ta sẽ khó mà tái tạo môi trường ở local để debug code của FaaS.

Một số tài liệu khác để tham khảo:

7 thoughts on “Series Nhận diện Idol: Phần 6.1 – Luận về Serverless – Vô Thai Kiếm”

  1. nếu mình có code python mà cần có các packages khác mới chạy dc thì sao để install hã anh? Em cũng muốn thử mà ko tìm dc tutorial đoạn này.(

    Like

    1. A ơi nếu mình cho người dùng lựa image trong máy rồi upload lên thì làm sao để lấy đc url của hình đó ạ

      Like

  2. A ơi cho em hỏi ngu 1 chút là nếu có 2 khuôn mặt trong một bức ảnh thì “nó” sẽ xử lý như thế nào ah a?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s