Serverless – Giới thiệu chung chung

Serverless – Giới thiệu chung chung

Chào mọi người, đây là bài đầu tiên mình viết trên blog VTI cho nên có gì sai sót mọi người comment bên dưới để cùng thảo luận nhé.

Thời gian gần đây thì mình có làm 1 buổi seminar để giới thiệu về Serverless trong nội bộ công ty và để sau này có quên mà muốn đọc lại thì mình sẽ tổng hợp lại trên này cũng như để chia sẻ cho nhưng ai chưa biết. Bài viết đầu tiên này sẽ là những hiểu biết chung của mình về Serverless, các bài tiếp theo mình sẽ thêm vào các hướng dẫn sử dụng các dịch vụ của AWS, Azure,… #### Bắt đầu thôi!

Làm sao để có 1 server khi cần sử dụng?

Hiện nay có rất cách để dựng một server phục vụ cho việc deploy ứng dụng Web, API hay đơn giản chỉ là để chọc ngoáy học tập:

• Tự xây dựng: cách này chắc chỉ có mấy anh guru nghịch ngợm hay công ty cần bảo mật mới làm vì để tự xây dựng 1 hệ thống server riêng cần ít nhiều kiến thức về network và phần cứng, thường thì DEV hơi mù mờ cái này :))
• Đi thuê: cách này thì tiện hơn, chỉ cần tìm 1 nhà cung cấp có cung cấp gói server phù hợp với yêu cầu rồi trả tiền hàng tháng là mình đã có riêng 1 server trong tay rồi. Hiện nay với việc phát triển của Cloud Computing (mây mây mưa mưa) thì việc này trở nên càng đơn giản hơn nữa, thích thì bật, chán thì tắt chứ không phải trả tiền 1 cục trước cả tháng, cả năm gây lãng phí. Ngoài ra việc sử dụng cloud cũng giúp tối ưu vấn đề về Scaling để tăng khả năng chịu tải cũng như tránh rủi ro khi xảy ra sự cố.

Chi tiết về Cloud Computing trên AWS các bạn xem series bài viết này nhé: AWS Overview Part 1

Ơ, dùng Cloud ngon vậy sao còn Serverless làm gì?

Mọi thứ đều có những điểm mạnh, điểm yếu riêng. Điển hình như cloud sinh ra để giải quyết các vấn đề về chi phí cũng như giúp đơn giản hóa hơn nữa việc xây dựng 1 server đảm bảo các yếu tố như Elastic (co giãn), High Availability (luôn sẵn sàng). Tuy nhiên cũng có nhưng giới hạn mà mô hình server truyền thống không thể giải quyết được như:

• Chi phí: mặc dù việc co giãn số lượng server có thể giúp giảm thiểu chi phí khi server ở mức chịu tải thấp tuy nhiên chúng ta lại không thể tắt toàn bộ các server đang chạy vì việc này đồng nghĩa với việc hệ thống của bạn sẽ tắt hoàn toàn và không thể phản rồi lại các request đến nó. Việc luôn phải chạy ở mức tối thiểu dẫn tới lãng phí nếu trong 1 thời gian dài không hề có request đến hệ thống.
• Thời gian: để 1 server bắt đầu có thể tiếp nhận xử lí request tính từ lúc bắt đầu có yêu cầu gia tăng số lượng server do lượng yêu cầu xử lí lớn cần 1 khoàn thời gian nhất định, và điều này thì phụ thuộc vào việc bạn cài đặt cho server những gì. Nếu việc số lượng request tăng giảm nhanh bất ngờ có thể hệ thống sẽ không phản ứng kịp thời khiến hệ thống vấn bị quá tải hoặc dư thừa. (Nó giống như kiểu bạn chơi game ở PING cao vậy)
• Số lượng Server: để thiết lập các thông số cho việc scale up-down thì cần phải đưa ra được số lượng server tối thiểu và tối đa của hệ thống. Điều này sẽ dẫn tới vấn đề là nếu việc phán đoán là sai, mức server tối thiểu quá nhiều thì sẽ gây dư thừa hay mức tối đa quá ít sẽ khiến hệ thống bị quá tải.
• Bảo trì: khi bạn chạy 1 server thì cần phải update OS cũng như các dịch vụ sử dụng để đảm bảo hệ thống vận hành tốt nhất. Tuy nhiên để thực hiện điều này thì server cần phải có downtime và càng nhiều server thì việc này càng tốn nhiều công sức.

Vậy Serverless là cái gì mà lại tốt hơn?

Như đã viết về các điểm giới hạn của mô hình Server truyền thống ở trên thì tất nhiên Serverless sinh ra sẽ giải quyết được những cái đó rồi :D:D…

Vậy Serverless là gì? Có phải là không có server và code chạy trên mây đúng không? – tất nhiên là không rồi, code mà chạy trên mây thì làm gì phải mất tiền. Về cơ bản code của bạn vẫn sẽ được deploy lên 1 server nào đó được quản lí hoàn toàn bởi nhà cung cấp dịch vụ và công việc chúng ta đơn giản chỉ là đưa code của chúng ta lên đó và tận hưởng thành quả.

• Chi phí dựa theo lượng sử dụng: khi deploy ứng dụng serverless thì sẽ không còn chi phí cho việc quản lí, vận hành server mà chi phí sẽ được tính theo số lượng request, thời gian cũng như lượng bộ nhớ sử dụng mỗi lần 1 function được gọi. Phi phí có thể là 0 nếu hoàn toàn không có request nào. (Cái này nghe sướng phết nhỉ, deploy cái web cá nhân chả ma nào vô thì cả năm chả tốn đồng nào mà khi truy cập vẫn chày phà phà)
  

• Tự động co giãn: DEV sẽ chả cần phải xoắn não nghĩ xem setting lượng server max-min bao nhiêu cho phù hợp hay lo lắng khi nào có lượng truy cập lớn. Giờ đây việc đó sẽ hoàn toàn được thực hiện một cách tự động bời nhà cung cấp dịch vụ dựa theo số lượng truy cập vào hệ thống một cách nhanh nhất trong mọi thời điểm để đảm bảo mọi request đều được phản hồi. (Tuy nhiên thì thường các nhà cung cấp đều có 1 mức limit số lượng request cùng xử lí 1 lúc cho nên khi muốn vượt quá limit này thì phải contact trực tiếp với họ, cái gì không xử lí được bằng tiền thì sẽ giải quyết được bằng rất nhiều tiền)

• Không cần bảo trì: vì đã giao hết quản lí server cho nhà cung cấp thì tất nhiên cũng chả phải quan tâm đến việc bảo trì, update làm gì. (Bớt gánh bớt đau đầu)

• Tập trung vào phát triển: do đã bớt đau đầu cho mấy việc ở trên cho nên khi đó các DEV sẽ có thể tập trung vào code, nghiên cứu và phát triển ứng dụng của mình đáp ứng tốt nhất với yêu cầu từ người dùng.

Từ đây chúng ta cũng có 1 thuật ngữ là “Functions as a Service” bởi vì code của chúng ta sẽ được deploy dưới dạng các function riêng biệt và hoàn toàn không hề có liên quan tới nhau. Mỗi 1 request sẽ được xử lí độc lập chính vì vậy mà ứng dụng của bạn phải được thiết kế để đảm bảo các request hoàn toàn là stateless.

Serverless thật thần thánh, di cư hết lên thôi!!!

Không! Như đã nói ở trên thì mọi thứ đều có điểm mạnh và điểm yếu riêng và khi serverless được tạo ra để xứ lí các vấn đề của server truyền thống thì bản thân nó cũng sẽ lại có các vấn đề.

• Phụ thuộc nhà cung cấp: do đã giao phó hết việc quản lí server cho nên bạn sẽ chẳng thể điều chỉnh thoải mái theo ý muốn mà phải dựa trên những gì được cung cấp. Ví dụ hiện nhà cung cấp chỉ support version NodeJS 12.x,14.x nhưng khi có update bạn muốn cao hơn thì phải chờ đến khi nó được support hoàn toàn bới chính nhà cung cấp dịch vụ. Ngoài ra bạn cũng chẳng thể chọn Apache hay Nginx gì cả :v :v
• Giới hạn về bộ nhớ, thời gian: các nhà cung cấp dịch vụ đều setting 1 mức giới hạn tối đa cho thời gian chạy của 1 function cũng như lượng bộ nhớ mà nó có thể sử dụng. Ví dụ với AWS là memmory – 10GB, timeout – 900ms hay Google là 500ms, Azure là 10 phút. Vì vậy với các yêu cầu cần thời gian xử lí lâu, sử dụng nhiều tài nguyên sẽ không thể sử dụng, nếu có sử dụng sẽ phải kết hợp với các service khác khi đó serverless functions sẽ đảm nhiệm vai trò là trigger.
• Không có storage: vì các functions trong serverless là stateless cho nên không nên lưu trữ dữ liệu vào bộ nhớ local mà nên sử dụng các dịch vụ storage như S3, RDS,…
• Debug: hiện nay có thể sử dụng các framework để hỗ trợ cho việc xây dựng môi trường phát triển ở local, triển khai cũng như debug. Tuy nhiên vẫn còn khá giới hạn.
• Độ trễ: sẽ cần 1 chút thời gian để khởi chạy 1 functions (khoàng vài ms cho đến vài giây) khi có request đến vì vậy sẽ không phù hợp với các hệ thống yêu cầu phản hồi tức thì.

Làm sao để tạo hệ thống sử dụng Serverless?

Hiện nay có rất nhiều nhà cung cấp dịch vụ giúp bạn tạo ra các functions sử dụng mô hình serverless một cách khá dễ dàng:

• AWS Lambda: nói về thị phần cung cấp hạ tầng cloud hiện nay thì AWS vấn đang dẫn đầu và họ cũng đưa ra dịch Lambda để người dùng có thể sử dụng và tạo ra các functions trên mô hình serverless. Khi kết hợp với các dịch vụ khác như API Gateway, S3,.. thì có thể tạo được một API server hay một hệ thống tự động xử lí khi có file upload lên S3. AWS Lambda hỗ trợ khá nhiều ngôn ngữ như Node.js, Java, C#, Python,…
• Google Cloud Function: thằng này chỉ hỗ trợ Nodejs
• Azure Functions: hàng của Microsoft, hỗ trợ C#, JavaScript, F#, Python, Batch, PHP, PowerShell

Còn nhiều nhà cung cấp khác như Kubeless, Fn,… tuy nhiên 3 ông ở trên có lẽ có thị phần lớn nhất và được quan tâm hơn. Ở dưới là chi tiết so sánh 1 số thông số giữa AWS Lambda, Google Cloud Function và Azure Function.

Kết luận

Serverless hiện nay đang là xu hướng khi các nhà cung cấp dịch vụ cloud đều đang đưa đưa mô hình này áp dụng cho các dịch vụ của mình. Tuy nhiên để lựa chọn giữa server truyền thống sẽ cần cân nhắc giữa các điểm mạnh điểm yếu của từng mô hình kết hợp với yêu cầu hệ thống đồng thời cũng phụ thuốc vào khả năng của chính team phát triển. Nếu chỉ với mục đích vọc vạch hay đơn giản là dự án cá nhân thì tội gì không thử nhỉ? :))

Tham khảo

• AWS Serverless Computing and Applications
• CloudAcademy – Microsoft Azure Functions vs. Google Cloud Functions vs. AWS Lambda
• Serverless Computing Pros and Cons

From Mạnh with love