Mặc dù các công nghệ không có máy chủ đã nhanh chóng trở nên phổ biến trong những năm gần đây, nhưng vẫn còn nhiều quan niệm sai lầm và nỗi sợ hãi liên quan đến chúng. Sự phụ thuộc vào nhà cung cấp, công cụ, quản lý chi phí, khởi động nguội, giám sát và vòng đời phát triển đều là những chủ đề nóng khi nói đến công nghệ serverless. Trong bài viết này, chúng ta sẽ khám phá một số chủ đề được đề cập, cũng như chia sẻ các mẹo và liên kết đến các nguồn thông tin hữu ích để giúp những người mới bắt đầu tạo các ứng dụng serverless mạnh mẽ, linh hoạt và tiết kiệm chi phí.
Những quan niệm sai lầm về công nghệ Serverless
Nhiều người nghĩ rằng xử lý serverless và serverless (, FaaS) gần như giống nhau. Điều này có nghĩa là sự khác biệt không quá lớn và đáng để giới thiệu một tính năng mới. Mặc dù AWS Lambda là một trong những ngôi sao của thời kỳ hoàng kim không có máy chủ và là một trong những yếu tố phổ biến nhất của kiến trúc không có máy chủ, tuy nhiên, kiến trúc này còn hơn cả FaaS.
Nguyên tắc cơ bản đằng sau các công nghệ không có máy chủ là bạn không phải lo lắng về việc quản lý và mở rộng cơ sở hạ tầng của mình, bạn chỉ trả tiền cho những gì bạn sử dụng. Nhiều dịch vụ đáp ứng các tiêu chí này - AWS DynamoDB, S3, SNS hoặc SQS, Graphcool, Auth0, Now, Netlify, Firebase và nhiều dịch vụ khác. Nói chung, serverless có nghĩa là sử dụng toàn bộ sức mạnh của điện toán đám mây mà không cần quản lý cơ sở hạ tầng và tối ưu hóa cơ sở hạ tầng đó để mở rộng quy mô. Điều đó cũng có nghĩa là bảo mật ở cấp độ cơ sở hạ tầng không còn là mối quan tâm của bạn, đây là một lợi ích to lớn do sự khó khăn và phức tạp của việc đáp ứng các tiêu chuẩn bảo mật. Cuối cùng, bạn không phải mua cơ sở hạ tầng được cung cấp cho bạn.
Serverless có thể được coi là một “trạng thái tâm trí”: một tâm lý nhất định khi thiết kế các giải pháp. Tránh các phương pháp yêu cầu bảo trì bất kỳ cơ sở hạ tầng nào. Với cách tiếp cận không có máy chủ, chúng tôi dành thời gian giải quyết các nhiệm vụ ảnh hưởng trực tiếp đến dự án và mang lại lợi ích cho người dùng: chúng tôi tạo logic kinh doanh bền vững, phát triển giao diện người dùng và phát triển API thích ứng và đáng tin cậy.
Ví dụ: nếu có thể tránh việc quản lý và duy trì nền tảng tìm kiếm văn bản miễn phí, thì đó là điều chúng tôi sẽ làm. Cách tiếp cận này để xây dựng các ứng dụng có thể tăng tốc đáng kể thời gian đưa ra thị trường, bởi vì bạn không còn cần phải suy nghĩ về việc quản lý cơ sở hạ tầng phức tạp. Loại bỏ trách nhiệm và chi phí quản lý cơ sở hạ tầng và tập trung vào việc xây dựng các ứng dụng và dịch vụ mà khách hàng của bạn cần. Patrick Debois gọi cách tiếp cận này là , thuật ngữ này được sử dụng trong cộng đồng serverless. Các chức năng nên được coi là một liên kết đến các dịch vụ dưới dạng các mô-đun có thể triển khai (thay vì triển khai toàn bộ thư viện hoặc ứng dụng web). Điều này cung cấp mức độ chi tiết đáng kinh ngạc để quản lý triển khai và thay đổi ứng dụng. Nếu bạn không thể triển khai các chức năng theo cách này, thì điều đó có thể cho thấy rằng các chức năng đó thực hiện quá nhiều tác vụ và cần được cấu trúc lại.
Một số bối rối bởi sự phụ thuộc vào nhà cung cấp khi phát triển các ứng dụng đám mây. Điều này cũng đúng với các công nghệ không có máy chủ và đây hầu như không phải là một quan niệm sai lầm. Theo kinh nghiệm của chúng tôi, việc xây dựng các ứng dụng serverless trên AWS, kết hợp với khả năng kết hợp các dịch vụ AWS khác của AWS Lambda, là một phần sức mạnh của kiến trúc serverless. Đây là một ví dụ điển hình về sức mạnh tổng hợp, khi kết quả của sự kết hợp không chỉ là tổng của các điều khoản. Cố gắng tránh phụ thuộc vào nhà cung cấp có thể gặp nhiều vấn đề hơn. Khi làm việc với các vùng chứa, việc quản lý lớp trừu tượng của riêng bạn giữa các nhà cung cấp đám mây sẽ dễ dàng hơn. Nhưng khi nói đến các giải pháp không có máy chủ, nỗ lực sẽ không được đền đáp, đặc biệt nếu tính đến hiệu quả chi phí ngay từ đầu. Hãy chắc chắn để tìm hiểu làm thế nào các nhà cung cấp cung cấp dịch vụ. Một số dịch vụ chuyên biệt dựa trên các điểm tích hợp với các nhà cung cấp khác và có thể cung cấp khả năng kết nối plug-and-play ngay lập tức. Việc cung cấp lệnh gọi Lambda từ điểm cuối API cổng dễ dàng hơn là ủy quyền yêu cầu cho một số vùng chứa hoặc phiên bản EC2. Graphcool cung cấp cấu hình dễ dàng với Auth0, dễ dàng hơn so với việc sử dụng các công cụ xác thực của bên thứ ba.
Việc chọn nhà cung cấp phù hợp cho ứng dụng serverless của bạn là một quyết định mang tính kiến trúc. Khi bạn tạo một ứng dụng, bạn không mong đợi một ngày nào đó sẽ quay lại quản lý máy chủ. Chọn nhà cung cấp đám mây không khác gì chọn sử dụng vùng chứa hoặc cơ sở dữ liệu hoặc thậm chí là ngôn ngữ lập trình.
Coi như:
- Bạn cần dịch vụ gì và tại sao.
- Những dịch vụ mà nhà cung cấp dịch vụ đám mây cung cấp và cách bạn có thể kết hợp chúng với giải pháp FaaS đã chọn của mình.
- Ngôn ngữ lập trình nào được hỗ trợ (với kiểu gõ động hoặc tĩnh, được biên dịch hoặc diễn giải, điểm chuẩn là gì, hiệu suất khi khởi động nguội là gì, hệ sinh thái nguồn mở là gì, v.v.).
- Yêu cầu bảo mật của bạn là gì (SLA, 2FA, OAuth, HTTPS, SSL, v.v.).
- Cách quản lý CI/CD và các chu kỳ phát triển phần mềm của bạn.
- Bạn có thể tận dụng các giải pháp cơ sở hạ tầng dưới dạng mã nào.
Nếu bạn mở rộng một ứng dụng hiện có và thêm dần chức năng serverless, điều này có thể hạn chế phần nào khả năng khả dụng. Tuy nhiên, hầu hết tất cả các công nghệ serverless đều cung cấp một số loại API (thông qua REST hoặc hàng đợi tin nhắn) cho phép bạn tạo các tiện ích mở rộng độc lập với lõi ứng dụng và tích hợp dễ dàng. Hãy tìm kiếm các dịch vụ có API rõ ràng, tài liệu tốt và cộng đồng mạnh mẽ và bạn không thể mắc sai lầm. Tính dễ tích hợp thường có thể là một chỉ số quan trọng và có lẽ là một trong những lý do chính khiến AWS thành công như vậy kể từ khi Lambda được phát hành vào năm 2015.
Khi không có máy chủ là tốt
Các công nghệ không có máy chủ có thể được áp dụng ở hầu hết mọi nơi. Tuy nhiên, ưu điểm của chúng không chỉ giới hạn ở một cách ứng dụng. Rào cản gia nhập điện toán đám mây ngày nay rất thấp nhờ các công nghệ không có máy chủ. Nếu các nhà phát triển có ý tưởng, nhưng họ không biết cách quản lý cơ sở hạ tầng đám mây và tối ưu hóa chi phí, thì họ không cần phải tìm một loại kỹ sư nào đó để thực hiện. Nếu một công ty khởi nghiệp muốn xây dựng một nền tảng nhưng lo ngại rằng chi phí có thể vượt quá tầm kiểm soát, họ có thể dễ dàng chuyển sang các giải pháp serverless.
Do tiết kiệm chi phí và dễ dàng mở rộng quy mô, các giải pháp serverless đều có thể áp dụng như nhau cho cả hệ thống bên trong và bên ngoài, cho đến một ứng dụng web có nhiều triệu đối tượng. Các tài khoản được đo lường thay vì bằng đồng euro, nhưng bằng xu. Thuê phiên bản đơn giản nhất của AWS EC2 (t1.micro) trong một tháng sẽ có giá €15, ngay cả khi bạn không làm gì với nó (ai lại quên tắt nó chứ?!). Để so sánh, để đạt được mức chi tiêu này trong cùng khoảng thời gian, bạn cần chạy Lambda 512 MB trong 1 giây khoảng 3 triệu lần. Và nếu bạn không sử dụng tính năng này, thì bạn không phải trả bất cứ điều gì.
Bởi vì serverless chủ yếu dựa trên sự kiện, nên khá dễ dàng để thêm cơ sở hạ tầng serverless vào các hệ thống cũ hơn. Ví dụ: sử dụng AWS S3, Lambda và Kinesis, bạn có thể tạo dịch vụ phân tích cho hệ thống bán lẻ cũ có thể nhận dữ liệu thông qua API.
Hầu hết các nền tảng serverless đều hỗ trợ nhiều ngôn ngữ. Thông thường đó là Python, JavaScript, C#, Java và Go. Thông thường không có giới hạn nào đối với việc sử dụng thư viện trong tất cả các ngôn ngữ, vì vậy bạn có thể sử dụng các thư viện mã nguồn mở yêu thích của mình. Tuy nhiên, không nên lạm dụng các phụ thuộc để các chức năng của bạn hoạt động tối ưu và không phủ nhận lợi ích của khả năng mở rộng khổng lồ của các ứng dụng serverless của bạn. Càng nhiều gói hàng cần được chất vào thùng chứa thì thời gian khởi động lạnh càng lâu.
Khởi động nguội là khi bạn cần khởi tạo vùng chứa, thời gian chạy và trình xử lý lỗi trước khi sử dụng chúng. Do đó, độ trễ khi thực hiện các chức năng có thể lên tới 3 giây và đây không phải là lựa chọn tốt nhất cho những người dùng thiếu kiên nhẫn. Tuy nhiên, khởi động nguội xảy ra ở lần gọi đầu tiên sau vài phút không hoạt động của chức năng. Vì vậy, nhiều người coi đây là một phiền toái nhỏ có thể khắc phục bằng cách thường xuyên ping chức năng này để giữ cho chức năng không hoạt động. Hoặc họ bỏ qua khía cạnh này hoàn toàn.
Mặc dù AWS đã phát hànhTuy nhiên, cơ sở dữ liệu SQL không lý tưởng cho ứng dụng này vì chúng phụ thuộc vào kết nối để thực hiện giao dịch, điều này có thể nhanh chóng trở thành nút cổ chai với lưu lượng truy cập lớn trên AWS Lambda. Có, các nhà phát triển không ngừng cải thiện Serverless Aurora và bạn nên thử nghiệm nó, nhưng ngày nay các giải pháp NoSQL như. Tuy nhiên, không có nghi ngờ rằng tình hình này sẽ sớm thay đổi.
Bộ công cụ cũng áp đặt rất nhiều hạn chế, đặc biệt là trong lĩnh vực thử nghiệm cục bộ. Mặc dù có các giải pháp như Docker-Lambda, DynamoDB Local và LocalStack, nhưng các giải pháp này yêu cầu công việc khó khăn và số lượng cấu hình đáng kể. Tuy nhiên, tất cả các dự án này đều được phát triển tích cực, do đó, việc bộ công cụ đạt đến mức chúng tôi cần chỉ còn là vấn đề thời gian.
Tác động của các công nghệ serverless đối với chu kỳ phát triển
Vì cơ sở hạ tầng của bạn chỉ là một cấu hình nên bạn có thể xác định và triển khai mã bằng cách sử dụng các tập lệnh, chẳng hạn như tập lệnh shell. Hoặc bạn có thể sử dụng các giải pháp lớp cấu hình dưới dạng mã như . Mặc dù dịch vụ này không cung cấp cấu hình cho tất cả các khu vực, nhưng dịch vụ này cho phép bạn xác định các tài nguyên cụ thể để sử dụng làm hàm Lambda. Nghĩa là, khi CloudFormation làm bạn thất bại, bạn có thể viết tài nguyên của riêng mình (hàm Lambda) để thu hẹp khoảng cách này. Bằng cách này, bạn có thể làm bất cứ điều gì, thậm chí định cấu hình các phần phụ thuộc bên ngoài môi trường AWS của mình.
Vì tất cả chỉ là cấu hình nên bạn có thể tùy chỉnh các tập lệnh triển khai của mình cho các môi trường, khu vực và người dùng cụ thể, đặc biệt nếu bạn đang sử dụng các giải pháp cơ sở hạ tầng dưới dạng mã như CloudFormation. Ví dụ: bạn có thể triển khai một bản sao của cơ sở hạ tầng cho từng nhánh trong kho lưu trữ để bạn có thể kiểm tra chúng hoàn toàn tách biệt trong quá trình phát triển. Điều này tăng tốc đáng kể phản hồi cho các nhà phát triển khi họ muốn hiểu liệu mã của họ có hoạt động hiệu quả trong môi trường trực tiếp hay không. Người quản lý không cần lo lắng về chi phí triển khai nhiều môi trường vì họ chỉ trả tiền cho mức sử dụng thực tế.
DevOps ít phải lo lắng hơn vì họ chỉ cần đảm bảo rằng các nhà phát triển có cấu hình chính xác. Bạn không cần phải quản lý các phiên bản, bộ cân bằng hoặc nhóm bảo mật nữa. Do đó, thuật ngữ NoOps ngày càng được sử dụng nhiều hơn, mặc dù khả năng định cấu hình cơ sở hạ tầng vẫn rất quan trọng, đặc biệt khi nói đến cấu hình IAM và tối ưu hóa tài nguyên đám mây.
Có những công cụ giám sát và trực quan hóa rất mạnh mẽ như Epsagon, Thundra, Dashbird và IOPipe. Chúng cho phép bạn theo dõi trạng thái hiện tại của các ứng dụng serverless, cung cấp tính năng ghi nhật ký và theo dõi, nắm bắt các chỉ số hiệu suất và tắc nghẽn kiến trúc, thực hiện phân tích và dự báo chi phí, v.v. Chúng không chỉ cung cấp cho các kỹ sư, nhà phát triển và kiến trúc sư DevOps cái nhìn toàn diện về hiệu suất ứng dụng mà còn cho phép các nhà quản lý theo dõi tình hình trong thời gian thực, với chi phí tài nguyên mỗi giây và dự báo chi phí. Việc tổ chức điều này với một cơ sở hạ tầng được quản lý sẽ khó khăn hơn nhiều.
Thiết kế ứng dụng serverless dễ dàng hơn nhiều vì bạn không phải triển khai máy chủ web, quản lý máy ảo hoặc vùng chứa, máy chủ vá lỗi, hệ điều hành, cổng internet, v.v. Bằng cách trừu tượng hóa tất cả các trách nhiệm này, kiến trúc serverless có thể tập trung vào cốt lõi - các giải pháp kinh doanh và nhu cầu của khách hàng.
Mặc dù bộ công cụ có thể tốt hơn (nó trở nên tốt hơn mỗi ngày), các nhà phát triển có thể tập trung vào việc triển khai logic nghiệp vụ và phân phối tốt nhất độ phức tạp của ứng dụng trên các dịch vụ khác nhau trong kiến trúc. Quản lý ứng dụng serverless dựa trên sự kiện và được trừu tượng hóa bởi nhà cung cấp đám mây (ví dụ: sự kiện SQS, S3 hoặc luồng DynamoDB). Do đó, các nhà phát triển chỉ cần viết logic nghiệp vụ để đáp ứng một số sự kiện nhất định và không phải lo lắng về cách triển khai cơ sở dữ liệu và hàng đợi tin nhắn tốt nhất hoặc cách tổ chức công việc tối ưu với dữ liệu trong kho lưu trữ phần cứng cụ thể.
Mã có thể được chạy và sửa lỗi cục bộ, như với bất kỳ quy trình phát triển nào. Kiểm tra đơn vị vẫn giữ nguyên. Khả năng triển khai toàn bộ cơ sở hạ tầng ứng dụng với cấu hình ngăn xếp tùy chỉnh cho phép các nhà phát triển nhanh chóng nhận được phản hồi quan trọng mà không cần nghĩ đến chi phí thử nghiệm hoặc tác động đến các môi trường được quản lý đắt đỏ.
Các công cụ và kỹ thuật để xây dựng các ứng dụng serverless
Không có cách cụ thể nào để xây dựng các ứng dụng serverless. Cũng như một tập hợp các dịch vụ cho nhiệm vụ này. AWS là công ty hàng đầu trong số các giải pháp serverless mạnh mẽ hiện nay, nhưng hãy xem thêm , и . Nếu bạn đang sử dụng AWS, phương pháp được đề xuất để thu thập ứng dụng là (SAM), đặc biệt khi sử dụng C#, vì Visual Studio có công cụ tuyệt vời. SAM CLI có thể làm mọi thứ mà Visual Studio có thể làm, vì vậy bạn sẽ không mất gì nếu chuyển sang IDE hoặc trình soạn thảo văn bản khác. Tất nhiên, SAM cũng hoạt động với các ngôn ngữ khác.
Nếu bạn đang viết bằng các ngôn ngữ khác, Serverless Framework là một công cụ mã nguồn mở tuyệt vời cho phép bạn định cấu hình mọi thứ bằng các tệp cấu hình YAML rất mạnh mẽ. Serverless Framework cũng hỗ trợ nhiều dịch vụ đám mây khác nhau, vì vậy chúng tôi khuyên dùng nó cho những ai đang tìm kiếm giải pháp nhiều đám mây. Nó có một cộng đồng khổng lồ đã tạo ra rất nhiều plugin cho bất kỳ nhu cầu nào.
Đối với thử nghiệm cục bộ, các công cụ nguồn mở Docker-Lambda, Serverless Local, DynamoDB Local và LocalStack rất phù hợp. Các công nghệ không có máy chủ vẫn đang trong giai đoạn phát triển ban đầu, cũng như các công cụ dành cho chúng, vì vậy khi thiết lập cho các kịch bản thử nghiệm phức tạp, bạn sẽ phải làm việc chăm chỉ. Tuy nhiên, chỉ cần triển khai ngăn xếp trong một môi trường và thử nghiệm ở đó là cực kỳ rẻ. Và bạn không cần tạo một bản sao cục bộ chính xác của môi trường đám mây.
Sử dụng AWS Lambda Layers để giảm kích thước của các gói đã triển khai và tăng tốc độ tải xuống.
Sử dụng đúng ngôn ngữ lập trình cho các tác vụ cụ thể. Các ngôn ngữ khác nhau đều có ưu và nhược điểm riêng. Có nhiều điểm chuẩn, nhưng JavaScript, Python và C# (.NET Core 2.1+) dẫn đầu về hiệu suất của AWS Lambda. AWS Lambda gần đây đã giới thiệu API thời gian chạy, cho phép bạn chỉ định môi trường và ngôn ngữ thời gian chạy mong muốn, vì vậy hãy thử nghiệm.
Giữ kích thước gói nhỏ để triển khai. Chúng càng nhỏ thì tải càng nhanh. Tránh sử dụng các thư viện lớn, đặc biệt nếu bạn sử dụng một vài tính năng từ chúng. Nếu bạn đang lập trình bằng JavaScript, hãy sử dụng công cụ xây dựng như Webpack để tối ưu hóa bản dựng của bạn và chỉ bao gồm những gì bạn thực sự cần. .NET Core 3.0 có QuickJit và Tiered Compilation giúp cải thiện hiệu suất và giúp ích rất nhiều cho những lần khởi động nguội.
Sự phụ thuộc của các chức năng serverless vào các sự kiện có thể gây khó khăn cho việc phối hợp logic kinh doanh lúc đầu. Về vấn đề này, hàng đợi tin nhắn và máy trạng thái có thể cực kỳ hữu ích. Các hàm lambda có thể gọi lẫn nhau, nhưng chỉ thực hiện việc này nếu bạn không mong đợi phản hồi ("cháy và quên") - bạn không muốn bị tính phí vì chờ đợi một hàm khác hoàn thành. Hàng đợi tin nhắn rất hữu ích để cô lập các phần logic nghiệp vụ, quản lý các nút thắt cổ chai của ứng dụng và xử lý giao dịch (sử dụng hàng đợi FIFO). Các chức năng AWS Lambda có thể được gán cho hàng đợi SQS dưới dạng hàng đợi tin nhắn bị kẹt giúp theo dõi các tin nhắn bị lỗi để phân tích sau này. AWS Step Functions (máy trạng thái) rất hữu ích để quản lý các quy trình phức tạp yêu cầu xâu chuỗi các chức năng. Thay vì một hàm Lambda gọi một hàm khác, các hàm Step có thể điều phối các chuyển đổi trạng thái, truyền dữ liệu giữa các hàm và quản lý trạng thái chung của các hàm. Điều này cho phép bạn xác định các điều kiện thử lại hoặc phải làm gì khi xảy ra một lỗi cụ thể - một công cụ rất mạnh trong một số điều kiện nhất định.
Kết luận
Trong những năm gần đây, các công nghệ không có máy chủ đã phát triển với tốc độ chưa từng thấy. Có một số quan niệm sai lầm liên quan đến sự thay đổi mô hình này. Bằng cách trừu tượng hóa cơ sở hạ tầng và quản lý mở rộng quy mô, các giải pháp không có máy chủ mang lại những lợi ích đáng kể, từ quá trình phát triển và DevOps đơn giản hóa đến giảm đáng kể chi phí vận hành.
Mặc dù phương pháp không có máy chủ không phải là không có nhược điểm, nhưng có những mẫu thiết kế mạnh mẽ có thể được sử dụng để xây dựng các ứng dụng không có máy chủ mạnh mẽ hoặc tích hợp các phần tử không có máy chủ vào các kiến trúc hiện có.
Nguồn: www.habr.com