Serverless không phải là bạn không cần server

Serverless là gì?

Serverless (hay còn được gọi là nền tảng không máy chủ) là một nền tảng tạo ra môi trường cho phép lập trình viên code các ứng dụng hay dịch vụ mà không cần phải quan tâm quá nhiều đến vấn đề máy chủ. Ứng dụng Serverless có thể được hiểu như một server đảm nhận việc vận hành hệ thống nội tại bên trong như phân bổ, quản lý tài nguyên hệ thống, nâng cấp và bảo mật. Việc của IT chỉ là tập trung để phát triển sản phẩm.

Serverless framework mang lại những lợi ích gì?

Tạo lập ứng dụng trên Serverless framework đồng nghĩa với việc bạn chỉ tập trung chú trọng vào giá trị cốt lõi. Bạn không cần phải quan tâm đến việc quản lý và vận hành nhiều máy chủ hoặc thời gian chạy, dù bạn điều chỉnh ứng dụng trên nền tảng đám mây hay hệ thống máy chủ.

Khối lượng công việc được cắt giảm,giúp cho các nhà phát triển có thêm thời gian và công sức để tập trung vào việc nâng cao chất lượng sản phẩm công nghệ.

Không cần quản lý máy chủ

Bạn sẽ không cần phải quản lý bất kỳ vấn đề liên quan đến máy chủ nhứ phần mềm hoặc thời gian chạy để cài đặt, nâng cấp hoặc quản trị vì đã có bên thứ ba đảm nhận.

Thay đổi quy mô một cách linh hoạt

Với Serverless, bạn có thể điều chỉnh chế độ thay đổi quy mô tự động hoặc bằng cách điều chỉnh dung lượng thông qua việc chuyển đổi đơn vị sử dụng. Đối với máy chủ độc lập, việc này sẽ phức tạp hơn rất nhiều.

Độ sẵn sàng cao

Ứng dụng Serverless có độ sẵn sàng tích hợp và dung sai cao. Bạn sẽ không cần tạo kiến trúc cho các hiệu năng này bởi nền tảng không máy chủ đã cung cấp cho ứng dụng theo mặc định. Ngoài ra, Serverless cho phép người dùng chọn trung tâm dữ liệu (một hoặc nhiều nơi) để triển khai sản phẩm một cách dễ dàng.

Tiết kiệm chi phí

Khi sử dụng Serverless, bạn sẽ không còn chi trả chi phí quản lý, vận hành. Dựa vào số lượng request (được gọi là yêu cầu) , thời gian, dung lượng bộ nhớ của mỗi lần sử dụng function (được gọi là chức năng) mà hệ thống sẽ tính phí. Điều này có nghĩa là bạn sử dụng bao nhiêu thì tính tiền bấy nhiêu.

Những mặt hạn chế của Serverless framework

Bạn có thể thấy rằng Serverless là một “kỳ công thần thánh” phải không? Tuy nhiên nền tảng vẫn chưa hoàn hảo, Serverless vẫn có những bắt cặp mà các nhà lập trình viên cũng phải cân nhắc kỹ lưỡng trước khi quyết định sử dụng.

Độ trễ

Hiệu suất có thể là một điểm trừ đối với mô hình này vì Serverless còn hạn chế về tốc độ xử lý các lệnh mà ứng dụng đưa ra cho các nguồn tài nguyên điện toán . Nghĩa là thời gian khớp lệnh sẽ lâu hơn. Nếu khách hàng đòi hỏi hiệu suất cao, sử dụng các máy chủ ảo được phân bổ sẽ là một giải pháp tuyệt vời.

Tính năng gỡ lỗi (Debug)

Công việc giám sát và gỡ lỗi của Serverless Computing cũng không phải là một thế mạnh. Bạn không thống nhất sử dụng một máy chủ, điều này gây trở ngại cho cả hai hoạt động trên.

(Tin tốt là nhà phát triển nền tảng không máy chủ hứa sẽ cải thiện xử lý tính năng giám sát và gỡ lỗi tốt hơn trong thời gian tới.)

Giới hạn về bộ nhớ, thời gian

Nhà cung cấp Serverless framework đều giới hạn dung lượng bộ nhớ và thời gian thực thi (timeout).

Ví dụ như sau:

• Giả sử timeout tối đa là 5 phút, nếu bạn chạy quá 5 phút, hệ thống tự động ngưng kết nối.
• Về bộ nhớ, thì sẽ thiết lập mỗi mức khác nhau tùy nhà cung cấp, AWS có dung lượng là 3008MB (sẽ được cấp CPU cao tương ứng), nếu ứng dụng yêu cầu bộ nhớ lớn thì sẽ không đáp ứng được.
• Trong quá trình lập trình nên tối ưu hóa dung lượng bộ nhớ, để tiết kiệm chi phí.

Phụ thuộc nhà cung cấp

Bạn không thể muốn chạy phần mềm trên nền tảng chính xác như bạn muốn mà phải phụ thuộc vào nền tảng của nhà cung cấp.

Ví dụ: bạn cần 10x mà nhà cung cấp chỉ hỗ trợ đến 8x, bạn sẽ không sử dụng được nền tảng này. Như vậy, bạn phải cân nhắc các nền tảng được hỗ trợ trước khi sử dụng.

Chi phí ngầm

Vấn đề này tùy thuộc vào nhà cung cấp nhưng cơ bản là sẽ phát sinh thêm phụ phí như sau:

• Chi phí lưu trữ mã nguồn,
• Chi phí lưu tữu băng thông
• Chi phí về lưu trữ dữ liệu

Mặc dù, tuy không nhiều nhưng nếu không tính toán rõ ràng, các phần chi phí ngầm sẽ còn cao hơn cả chi phí cho Serverless.

Thời gian để nghiên cứu

Để có thể sử dụng Serverless framework, bạn cần thời gian để nghiên cứu. Bạn cần hiểu rõ cách quản lý các tài nguyên trong nền tảng này mặc dù kiến thức không quá khó nhưng bạn vẫn phải tìm hiểu trước nếu muốn sử dụng.

Ví dụ: bạn phải dành thời gian để hiểu về cách sử dụng các phần mềm như CloudFormation, IAM policies, quản lý cấu hình về stage, region, memory của Functions…

Tóm lại, chúng ta có thể thấy rằng Serverless framework là một trong những công nghệ đầy hứa hẹn trong tương lai. Tuy nhiên, hiện tại Serverless framework vẫn còn nhiều hạn chế chưa được cải thiện. Vì vậy, trước khi quyết định sử dụng nền tảng này, bạn nên cân nhắc thật kỹ.

Chi phí của Serverless và Server thường khác nhau như thế nào?

Bài viết bên trên đã để cập về vấn đề này, nhưng trong câu hỏi này TinoHost sẽ giải thích một cách dễ hiểu hơn. Bạn vẫn sẽ phải trả tiền hàng tháng cho dù cái máy chủ ảo không chạy, hoặc bạn chỉ sử dụng 5 – 10% công suất.

Bạn có thể hiểu Serverless như gói cước điện thoại được tính theo giây, gọi bao nhiêu trả tiền bấy nhiêu, còn máy chủ ảo thì phải trả tiền thuê bao hàng tháng dù có phải sử dụng hay không.

Có những nhà cung cấp dịch vụ Serverless đáng tin cậy nào trên thị trường?

Hiện nay, có rất nhiều nhà cung cấp mô hình Serverless để bạn thực hiện các functions một cách dễ dàng. Sau đây là ba nhà cung cấp lớn và uy tín trên thị trường.

• AWS Lambda: AWS vấn đang dẫn đầu trên thị trường Serverless và họ cũng cung cấp hệ thống Lambda để người dùng có thể sử dụng và tạo ra các chức năng trên mô hình Serverless.. AWS Lambda hỗ trợ các ngôn ngữ khác nhau như Node.js, Java, C#, Python,…
• Google Cloud Function: họ chỉ hỗ trợ Nodejs
• Azure Functions: đến từ hãng Microsoft, hỗ trợ C#, JavaScript, F#, Python, Batch, PHP, PowerShell

Mô hình Serverless có thực sự cần thiết hay không?

Serverless cùng với những tính năng nổi bật của mình đã mang lại những lợi ích đáng kể trong quá trình coding đối với người lập trình viên. Bên cạnh đó, mô hình này cũng có những nhược điểm cần lưu tâm. Vì vậy, tùy theo hình thức cũng tính chất công việc mà bạn có thể cân nhắc sử dụng mô hình Serverless tiềm năng này.

Nhược điểm lớn nhất của Serverless là gì?

Nhược điểm lớn nhất của mô hình này là tính chất phụ thuộc vào nhà cung cấp. Trong trường hợp có những vấn đề rủi ro xảy ra như sập server, treo hệ thống hay thậm chí email của khách hàng không nhận được hàng loạt thì bạn không thể tự xử lý mà phải đợi bên nhà cung cấp.

Serverless được dùng để ám chỉ những ứng dụng sử dụng phần lớn (hoặc toàn bộ) dịch vụ “nhà hàng xóm” (third-party), được host trên cloud, cho các vấn đề ở phía server là logic và state (ví dụ trạng thái đăng nhập, một dạng của dịch vụ chăm sóc khách hàng thân thiết). Những ứng dụng để sử dụng (không phải những trang profile công ty, show hiệu ứng bay lượn portfolio, ví dụ như Facebook, ứng dụng đăng ký môn học, hoặc ứng dụng điện thoại bị chửi bới quá trời FaceApp, tức là mô hình này không chỉ áp dụng riêng cho web). Những dịch vụ thường được outsource cho nhà hàng xóm là gì: database có Parse, Firebase, authentication có Auth0, AWS Cognito. Mấy nhà này nằm trong khu “Backend as a Service” – BaaS, khi gắn vào hậu tố as a Service bạn có thể biết là nó nằm ở nhà hàng xóm.

Serverless cũng có nghĩa là ứng dụng đó logic server vẫn có, developer vẫn phải viết logic này, tuy nhiên, không giống kiến trúc truyền thống, nó chạy theo cơ chế “tiền trao-cháo múc” (event-trigger), không quan tâm anh bạn có ở chung nhà mình không (stateless compute container). Khái niệm này được @marak trên Twitter gọi là Function as a Service – FaaS, bạn có nhu cầu cắt tóc, gội đầu, uống cafe, đánh giày thì bạn ra tiệm hết, không dùng đồ nhà có sẵn nữa. Hiện tại, AWS Lambda là một trong những platform nổi tiếng nhất khi nói đến FaaS

Giờ nói tới FaaS, nó đang là trend, nó thay đổi cách chúng ta trước đây vẫn nghĩ về kiến trúc dưới server.

Tất cả những ông lớn đều có các sản phẩm BaaS và FaaS, Amazon Serverless, Google Cloud Functions for Firebase.

Một kiến trúc Serverless nó như thế này

1. Phần authen trước đây được gửi nhà hàng xóm làm (cơ quan nhà nước chuyên cung cấp CMND)
2. Dữ liệu được đưa một về nhà kho quản lý, kiểu như Tiki bây giờ quá mệt quản lý kho hàng, các cửa hàng nhỏ lẻ tự quản lý kho, Tiki bán được thì chạy tới kho của bên thứ 3 lấy.
3. Với 2 thay đổi ở trên, điều này có nghĩa là một vài logic đã được nằm ở phía client, thí dụ, user session, bạn sẽ thấy rõ nhất ở các Single Page App chúng ta build, phần logic giao diện cho user đã và chưa đăng nhập nằm ở client – nhà user, những route nào user có thể vào nằm ở code client
4. Một vài hiển thị, ràng buộc tất nhiên vẫn được server nắm. Thí dụ “search”. Chúng ta có thêm một nhà gọi là “API Gateway”, dịch vụ giao nhận, tất cả các yêu cầu từ client đưa về đây, các anh em HTTP sẽ đi lấy dữ liệu từ kho về cho chúng ta.
5. Với tính năng đặt hàng, nó do một nhà** khác cung cấp. Những logic khác nhau, được tách và deploy thành những cục* khác nhau như vậy cách tiếp cận của FaaS cũng là cách tiếp cận rất phổ biến trong “Microservices”

Nó sẽ có những lợi ích i chang như Microservices, tất nhiên là có trả giá, có nhiều thứ để kiểm soát và theo dõi hơn, vấn đề bảo mật cũng không phải đơn giản như xưa, nằm ở nhiều nơi quá mà, bài toán đi đi lại tránh kẹt xe giữa các hệ thống khác nhau, biết đâu đi lạc vào chổ nào đó mất CMND luôn !!

Function as a Service

(1) FaaS là chạy backend code mà không cần quan tâm việc quản lý và bảo trì hệ thống server.

(2) FaaS không yêu cầu một framework hay thư viện cụ thể nào. Các function trên Lambda có thể được viết bằng Javascript, Python, Go, Java, Clojure, Scala, .NET.

(3) Deploy sẽ rất khác với hệ thống truyền thống. Tới *nhà** của FaaS chúng ta đưa đoạn code cho chủ nhà, còn lại chủ nhà làm gì thì làm.

(4) Scale sẽ tự động được chủ nhà làm. Nếu hệ thống cần đáp ứng 1000 request đồng thời, chủ nhà sẽ lo, bạn chỉ cần bơm tiền. Quan trọng nhất, bên cung cấp dịch vụ sẽ quản lý hết toàn bộ resource, xin giấy phép, nói chung là toàn bộ – bạn không cần làm gì với cluster, VM cả.

(5) Cung cấp cơ chế trigger ứng với các event bạn muốn.

(6) Mấy bên cung cấp dịch vụ, cho phép các function này trigger theo những sự kiện HTTP request, như ví dụ là search, và purchase, hoặc gọi trực tiếp lên các API được cung cấp bởi bên cung cấp

Case Study

PhotoVogue trang Vogue của Ý, chạy từ năm 2011, sau một năm chạy, photographer bu vô như kiến, server ở nhà riêng quá tải không chịu nổi.

Giám đốc kỹ thuật quyết định chuyển đổi toàn bộ hệ thống server ở nhà riêng sang AWS trong 3 tháng.

Chạy theo trend này, còn có những cái tên rất phổ biến là Uber, Pokemon Go, Airbnb, Clash of Clans và rất nhiều ứng dụng khác khi số lượng user và real-time data lớn

Những vấn đề mà team PhotoVogue đã gặp

• Có hơn 130,000 photographer trên khắp thế giới sử dụng hệ thống để đưa ảnh lên, ước tính có khoảng 400,000 ảnh, với dung lượng tối đa mỗi hình là 50MB (bọn này chơi sang nhỉ)
• Số lượng truy cập ngày càng tăng
• Trải nghiệm sử dụng của user không tốt, thao tác xử lý quá chậm, up ảnh quá rùa

Với AWS, nó đã giải quyết các vấn đề sau cho PhotoVogue

• Khả năng scale, dễ maintenance, quản lý chi phí rõ ràng
• Lưu trữ hình trên Amazon S3
• Khi up lên Amazon S3, bật trigger sử dụng AWS Lambda function, convert các file này qua gif, jpeg, png, tiff
• Amazon API Gateway được sử dụng để làm tầng caching của REST API, Amazon CloudFront cho CDN

Serverless là mô hình thực thi điện toán đám mây trong đó nhà cung cấp đám mây tự động quản lý việc phân bổ và cung cấp máy chủ. Một ứng dụng không có máy chủ chạy trong các compute containers không trạng thái được kích hoạt sự kiện, không lâu (có thể tồn tại trong một lần gọi) và được nhà cung cấp đám mây quản lý hoàn toàn. Giá cả được dựa trên số lượng thực thi thay vì được cố định trước đó, đó có phải là framework lý tưởng cho dự án mà bạn đã lên kế hoạch từ lâu không? Nếu có, tiếp tục tìm hiểu nhé. Các ứng dụng không có máy chủ là các hệ thống dựa trên đám mây theo sự kiện, trong đó việc phát triển ứng dụng chỉ dựa vào sự kết hợp của các dịch vụ bên thứ ba, logic phía máy khách và các cuộc gọi thủ tục từ xa được lưu trữ trên đám mây (Chức năng như một Dịch vụ). Hầu hết các nhà cung cấp đám mây đã đầu tư rất nhiều vào serverless và đó là rất nhiều tiền; với chương trình khuyến mãi lớn và cung cấp thực tế, bạn có thể cho rằng serverless là một trong những dịch vụ đám mây được sử dụng nhiều nhất trong những năm tới. Dưới đây là một số dịch vụ đám mây hiện có:

• AWS Lambda
• Google Cloud Functions
• Azure Functions
• IBM OpenWhisk
• Alibaba Function Compute
• Iron Functions
• Auth0 Webtask
• Oracle Fn Project
• Kubeless

Traditional vs. Serverless Architecture

Trong nhiều năm, các ứng dụng của bạn đã chạy trên các máy chủ mà bạn phải liên tục cài đặt bản vá, cập nhật và liên tục "để mắt" thậm chí cả vào những đêm muộn và sáng sớm do tất cả các lỗi không thể tưởng tượng đã phá vỡ production của bạn. Serverless có xu hướng không giống như đã nói ở trên, bạn không còn phải lo lắng về các máy chủ. Lý do là chúng không còn được bạn quản lý nữa và với sự quản lý ra khỏi image, trách nhiệm thuộc về các nhà cung cấp dịch Đám mây. Nhưng bất kể là các tính năng thú vị của Serverless vượt trội hơn trong một số trường hợp, kiến trúc truyền thống vẫn đang có phần vượt trội Serverless

Chúng ta cùng lướt qua một số so sánh nhanh dưới đây:

Giá cả(price):

Một trong những lợi thế chính của việc sử dụng Serverless là giảm thiểu chi phí. Mô hình chi phí của Serverless tính toán dựa trên những gì thực thi, nghĩa là tính phí cho số lần thực hiện. Bạn đã phân bổ một số giây sử dụng nhất định thay đổi theo dung lượng bộ nhớ bạn yêu cầu. Tương tự, giá mỗi MS (mili giây) thay đổi theo dung lượng bộ nhớ bạn yêu cầu. Rõ ràng, các chức năng chạy ngắn hơn có thể thích ứng hơn với mô hình này với thời gian thực hiện cao nhất là 300 giây đối với hầu hết các nhà cung cấp Đám mây. OK. trong tiêu chí này chiến thắng thuộc về Serverless Architecture.

Mạng(network)

Nhược điểm là các chức năng Serverless chỉ được truy cập dưới dạng API riêng. Để truy cập chúng, bạn phải thiết lập API Gateway. Điều này không có tác động đến giá cả hoặc quy trình của bạn, nhưng điều đó có nghĩa là bạn không thể truy cập trực tiếp vào chúng thông qua IP thông thường! OK, chiến thắng ở đây thuộc về Kiến trúc truyền thống.

Phụ thuộc bên thứ 3 (3rd Party Dependencies)

Hầu hết, nếu không muốn nói là tất cả các dự án của bạn đều có sự phụ thuộc bên ngoài, chúng dựa vào các thư viện không được tích hợp vào ngôn ngữ hoặc khung bạn sử dụng. Bạn thường sử dụng các thư viện có chức năng bao gồm mật mã, xử lý hình ảnh, v.v., những thư viện này có thể khá nặng. Không có quyền truy cập cấp hệ thống, bạn phải đóng gói các phụ thuộc này vào chính ứng dụng.

Phát minh lại bánh xe không phải là một ý tưởng tốt. Chiến thắng ở đây cũng dựa trên bối cảnh. Đối với các ứng dụng đơn giản có ít phụ thuộc, Serverless là người chiến thắng; Đối với bất cứ điều gì phức tạp hơn, Kiến trúc truyền thống là người chiến thắng. xem như ở tiêu chí này cả hai hòa nhau.

Môi trường

Thiết lập các môi trường khác nhau cho Serverless cũng dễ như thiết lập một môi trường duy nhất.Cho nó trả tiền cho mỗi lần thực hiện, đây là một cải tiến lớn so với các máy chủ truyền thống, bạn không còn cần phải thiết lập các môi trường dev, staging, and production. Cuối cùng, bạn sẽ mất số lượng tất cả các môi trường tại một số điểm.

Người chiến thắng ở đây là Serverless Architecture.

Timeout

Với tính toán Serverless, có giới hạn thời gian chờ 300 giây. Các chức năng quá phức tạp hoặc hoạt động lâu không tốt cho Serverless, nhưng thời gian chờ quá khiến bạn không thể thực hiện một số tác vụ nhất định. Giới hạn cứng vào thời điểm này làm cho Serverless không thể sử dụng được cho các ứng dụng có thời gian thực hiện thay đổi và đối với một số dịch vụ yêu cầu thông tin từ nguồn bên ngoài.

Dành chiến thắng ở tiêu chí nàyrõ ràng ở đây là Kiến trúc truyền thống.

Scale

Quá trình mở rộng cho Serverless là tự động và liền mạch, nhưng thiếu kiểm soát hoặc thiếu hoàn toàn kiểm soát. Mặc dù tự động mở rộng rất tuyệt vời, nhưng khó có thể giải quyết và giảm thiểu các lỗi liên quan đến các trường hợp Serverless mới.

Nó liên kết giữa Serverless và Kiến trúc truyền thống.

Khi nào nên sử dụng serverles

Có rất nhiều trường hợp có thể ứng dụng được serverless, điểm chung là tất cả những ứng dụng không dính dáng đến điểm yếu của serverless

Websites và APIs: hoàn toàn có thể xây dựng 1 website hoặc API, website có thể là động hoặc là bán tĩnh (bán tĩnh nghĩa là nguồn gốc file là tĩnh, nhưng dùng route động). Thường thì người ta hay xây dựng Restful API với serverless, nhưng mình thích áp dụng cho Graphql hơn, vì Restful có thể trả về dữ liệu không dùng tới nhưng mình phải trả tiền băng thông

Xử lý đa phương tiện: các thao tác xử lý hình ảnh, video với yêu cầu không quá cao như cắt, nén, định dạng kích thước ảnh, tạo ảnh thumbnail, hoặc chuyển đổi bộ mã của video để phù hợp với thiết bị tương ứng.

Xử lý sự kiện: có thể đóng vai trò như 1 công tắc cầu giao để thực hiện một loạt các hành động khác khi được kích hoạt tuỳ theo sự kiện.

Xử lý dữ liệu: tuỳ theo ngữ cảnh mà có thể ứng dụng như chatbot, IoT,… lý do mà serverless thích hợp với mảng này vì với chatbot hay IoT chúng ta không biết khi nào dữ liệu sẽ tới, khi nào sẽ cần xử lý dữ liệu nên chúng ta không cần phải xây dựng máy chủ luôn luôn chạy và lãng phí ở thời gian chờ.

So sánh một số nhà cung cấp hàng đầu

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

Tính năng	AWS Lambda	Google Cloud	Azure Functions
Khả năng mở rộng	Tự động	Tự động	Bằng tay hoặc theo plan đặt trước
Số Function tối đa	Không giới hạn	1000 trên 1 project	Không giới hạn
Xử lí đồng thời	1000 trên 1 account 1 region (soft limit)	Không giới hạn	Không giới hạn
Thời gian xử lí tối đa	300 sec (5 min)	540 seconds (9 minutes)	300 sec (5 min)
Ngôn ngữ	JavaScript, Java, C#, and Python	Only JavaScript	C#, JavaScript, F#, Python, Batch, PHP, PowerShell
Cài đặt dependencies	Đóng gói trong source packpage	npm package.json	Npm, NuGet
Deployments	Chỉ dùng ZIP upload (to Lambda or S3)	ZIP upload, Cloud Storage hoặc Cloud Source Repositories	Visual Studio Team Services, OneDrive, Local Git repository, GitHub, Bitbucket, Dropbox, External repository
Biến môi trường	Có	Chưa hỗ trợ	App Settings và ConnectionStrings trong App Services
Versioning	Versions và aliases	Cloud Source branch/tag	Cloud Source branch/tag
Event-driven	S3, SNS, SES, DynamoDB, Kinesis, CloudWatch, Cognito, API Gateway, CodeCommit, etc.	Cloud Pub/Sub hoặc Cloud Storage Object Change Notifications	Blob, EventHub, Generic WebHook, GitHub WebHook, Queue, Http, ServiceBus Queue, Service Bus Topic, Timer triggers
Hỗ trợ HTTP(S)	API Gateway	HTTP trigger	HTTP trigger
Orchestration	AWS Step Functions	Chưa hõ trợ	Azure Logic Apps
Logging	CloudWatch Logs	Stackdriver Logging	App Services monitoring
Monitoring	CloudWatch & X-Ray	Stackdriver Monitoring	Application Insights
In-browser code editor	Có	Chỉ cho Cloud Source Repositories	Functions environment, App Service editor
Granular IAM	IAM roles	Chưa hỗ trợ	IAM roles
Pricing	free 1M requests, sau đó $0.20/1M requests, thêm $0.00001667/GB-sec	free 1M requests, sau đó $0.40/1M requests, thêm $0.00000231/GB-sec	free 1M requests, sau đó $0.20/1M requests, thêm $0.000016/GB-s

Xây dựng hệ thống để trở thành nhà cung cấp serverless

Vì sự nổi trội về ưu điểm của serverless, nên hiện nay cũng đã có một số mã nguồn mở để xây dựng thành nền tảng cung cấp serverless

OpenFaaS – Serverless Functions Made Simple

https://github.com/openfaas/faas

FireCracker – Secure and fast microVMs for serverless computing

https://github.com/firecracker-microvm/firecracker

Mình thì chỉ quan tâm tới việc xài thôi, nên không tìm hiểu được ở mảng này.

Fullstack Station Tips

Ngày nay khi mà các công cụ hỗ trợ lập trình viên tập trung vào việc xây dựng sản phẩm càng nhiều, thì rõ ràng chính lập trình viên chính là những người hưởng lợi nhất. Serverless cũng là tương lai của những lập trình viên, khi không còn phụ thuộc vào phần cứng, máy chủ nữa.

Serverless giúp cho chúng ta không còn lo về chi phí duy trì máy chủ, không còn lo khi sản phẩm chưa có doanh thu đã phải trả tiền duy trì. Cho dù serverless là không hoàn hảo, nhưng với những ưu điểm nhiều hơn khuyết điểm và khả năng ứng dụng rộng lớn, serverless là một mảnh đất màu mỡ cho bạn phát triển.

Quan điểm của Fullstack Station là đa năng, gọn nhẹ và không phụ thuộc, muốn trở thành lập trình viên độc lập thì càng nên học và ứng dụng serverless.