Xây dựng các ứng dụng dựa trên serverless và container: 7 xu hướng bạn cần biết (Phần 1)

Serverless technology và container orchestration—đặc biệt là với Docker và Kubernetes—đang giúp thay đổi bộ mặt của ngành điện toán đám mây. Và mọi chuyện chỉ mới bắt đầu, bởi sự ảnh hưởng của những công nghệ này sẽ lan truyền ra các ngành khác trong nhiều năm tiếp theo.Trong khi nhiều người vẫn còn chú ý về những công nghệ riêng lẽ thì một số các chuyên gia đã nhận ra những thay đổi rộng lớn hơn, có khả năng ảnh hưởng tới cả nhu cầu tìm kiếm nhân lực IT.

Sau đây là 7 xu hướng quan trọng trong điện toán đám mây bởi  Amazon Web Services’ (AWS) Lambda, mà các công ty nên đọc qua.  

Cloud đang phát triển từ tập hợp hệ điều hành qua một hệ điều hành mới hợp nhất

Trong những năm đầu của AWS, Amazon đã dành hầu hết thời gian nghiên cứu và phát triển nhằm biến việc mua sắm và quản lý phần cứng thành một vấn đề về phần mềm; với sự xuất hiện của Amazon S3 object storage – lưu trữ đối tượng và Elastic Compute Cloud (EC2) là những ví dụ rõ ràng nhất về điều này. Là một nền tảng cho việc cung cấp cơ sở hạ tầng-như-một-dịch vụ (IaaS), AWS đã xây dựng mộtcloud tương đương với hardware abstraction layer (HAL).

Sau khi hoàn thành, AWS lập tức phát triển lên stack, và tập trung vào cải thiện chất lượng dịch vụ (QoS) và các API liên quan, bao gồm query và hệ thống notification, một hệ thống được đăng kí trong DynamoDB, và nhiều cái khác nữa.

Vào năm 2015, AWS Lambda đã đạt đến giai đoạn sẵn sàng. Amazon đã hoàn thành phần cuối cùng của hệ điều hành đám mây đầu tiên trên thế giới, cũng như hoàn chỉnh với các thành phần như HAL, QoS.

Điều làm cho AWS Lambda (và các đối tác của nó trên các nền tảng đám mây khác) quan trọng là vì nó đã làm thay đổi cách mọi người suy nghĩ về giá trị của điện tử đám mây. Với Internet of Things (IoT), machine learning, và các thay đổi khác đang lan rộng, Amazon thừa nhận sự cần thiết phải chuyển đổi từ platform-as-a-service (PaaS) sang toolchain-as-a-service (TCaaS).

Các sản phẩm của PaaS như HAmazon’s Elastic Beanstalk được kết hợp rất chặt chẽ, cũng như vertically integrated software stacks dành cho xây dựng nền tảng của app. Ngược lại, các dịch vụ TCaaS được kết hợp mở đi kèm với horizontally integrated cloud application để kết hợp các hệ thống phần mềm độc lập cho việc giải quyết một số nhu cầu kinh doanh.

Với sự xuất hiện của các cloud-based toolchain và cơ sở hạ tầng cần thiết để hỗ trợ chúng, AWS đang phát triển từ một tập hợp các hệ điều hành phụ thành một nhà cung cấp hệ điều hành. Thay vì xây dựng và triển khai các ứng dụng trong cloud, giờ đây bạn đã có thể xây dựng và triển khai các ứng dụng trên chúng. Các nhà cung cấp khác cũng giới thiệu các dịch vụ tương tự như (FaaS), do đó mở rộng xu hướng này.

Những sự thay đổi này không chỉ là chiến thuật mà nó còn mang tầm chiến lược. Ban đầu, hầu hết các công ty không nhận ra những ý nghĩa chiến lược và họ vẫn làm việc theo cách truyền thống vốn vô cùng giới hạn.

Silo bắt đầu bị thoái trào và chết mòn

Với việc Cloud hoạt động như hệ điều hành, mô hình DevOps vốn phổ biến cho đến năm 2015 giờ đây đã lỗi thời. Trong mô hình này, các công ty tự tổ chức thành các cơ sở kỹ thuật, cơ sở hạ tầng và quản lý chất lượng. Khi đó, đội cơ sở hạ tầng sẽ chịu trách nhiệm giải quyết hầu hết các vấn đề liên quan đến AWS, Azure, Google Compute Cloud, v.v.

DevOps là phần mềm mà một quản trị viên hệ thống viết để cung cấp tài nguyên cần thiết cho việc đáp ứng các yêu cầu của bên kỹ thuật. Vì vậy nên các administrator thường sử dụng những giải pháp như CloudFormation của Amazon, Red Hat’s Ansible hoặc Terraform của HashiCorp.

Trước AWS Lambda, sự phân chia tương đối rõ ràng giữa đội kỹ thuật và đội cơ sở hạ tầng. Nhưng tất cả đã thay đổi vào năm 2015, khi Cloud được định nghĩa lại như một hệ điều hành.

Trớ trêu thay, chính mô hình DevOps này góp phần khiến hầu hết các doanh nghiệp bị chậm chạp trong việc nhận ra tầm quan trọng của AWS Lambda.

Hơn nữa AWS Lambda lại nhắm mục tiêu tới đối tượng chủ yếu là các developer, những người thường khá lạ lẫm với các sản phẩm của Amazon. Điều này dẫn tới tình trạng tiến thoái lưỡng nan cho các team sử dụng mô hình DevOps.

Một bên, bạn đã có đội ngũ cơ sở hạ tầng, với quyền truy cập vào nhiều công nghệ cốt lõi, cùng nhiệm vụ cung cấp các nguồn lực sản xuất và bảo vệ những tài nguyên đó trước các sự gián đoạn.

Mặt khác, bạn đã có các developer, những người không thể nắm rõ và hiểu một hệ điều hành mới mà không cần bỏ công tìm hiểu về nó. Hãy tưởng tượng việc xây dựng một ứng dụng Mac hoặc Windows mà không biết rằng mouse event dispatch loop vốn đã được tích hợp trong các tính năng chính; và thường thì bạn sẽ phí thời gian để sử dụng một phương pháp kém hiệu quả hơn.

Nói cách khác, developer xây dựng phần mềm cho một hệ điều hành mà họ không được phép khám phá sẽ dẫn tới việc họ phí thời gian phát triển các ứng dụng vốn đã được tích hợp sẵn.

Để khắc phục điều này, developer nên ngừng sử dụng AWS và các nền tảng điện toán đám mây khác như là domain của nhóm cơ sở hạ tầng và các nhà tuyển dụng nên dừng việc hạn chế các developer không được quyền truy cập vào những hệ điều hành để học hỏi và tìm hiểu.

Một khi các developer không còn xem cloud như là cơ sở hạ tầng mà là một hệ điều hành với những khả năng giúp cải thiện cho công việc của họ, thì các giải pháp mới sẽ tự xuất hiện.

Nói cách khác, các mô hình DevOps đã trở nên lụi tàn và AWS Lambda buộc phải định nghĩa lại ý nghĩa của thuật ngữ DevOps.

DevOps lại phải thay đổi thêm lần nữa

Một trong số các chủ đề mới nổi gần đây là khái niệm “blast-radius containment”. Nói cách khác, các developer được cung cấp một sandbox nơi họ có thể học hỏi, thử nghiệm và thậm chí là thổi tung mọi thứ trong khi vẫn đảm bảo rằng nó không ảnh hưởng tới quá trình phát triển của nhóm.

Tại sự kiện AWS re:Invent 2016, Amazon vạch ra một chiến lược cải thiện nó. Ngoài ra, một số serverless tool và thư viện để cung cấp sự hỗ trợ cho các developer.

Một chủ đề mới khác trong DevOps là tái cấu trúc phân chia trách nhiệm giữa cơ sở hạ tầng và kỹ thuật như là một cách tiếp cận phân cấp, theo thứ bậc.

Trong mô hình này, các môi trường được bảo vệ và nằm dưới sự giám sát chặt chẽ của đội cơ sở hạ tầng. Nhưng các môi trường ít được bảo vệ hơn, như dev và staging, có quyền được thoải mái hơn, nhờ đó mà có khả năng kiểm soát đầy đủ hơn cho các nhóm kỹ sư. Về mặt khái niệm, điều này khá rõ ràng – những thách thức thực sự nằm ở việc mở rộng và sử dụng các phương pháp pass để hợp tác, phân cấp.

Trong bài phát biểu của tôi tại hội nghị 2016 All Things Open, tôi đã miêu tả sự thay đổi này là “Devleps nhỏ giọt” (xem Hình 2). Nhưng sau đó thì đã đổi tên nó lại là “DevOps hợp tác”, vì mô hình DevOps cũ trước đó không thực sự hợp tác – ít nhất là giữa các nhóm kỹ thuật và cơ sở hạ tầng.

Trong những nhóm hợp tác của  DevOps, các nhóm cơ sở hạ tầng và kỹ thuật sử dụng các toolchain chung, với những phương pháp, và key/value . Điều này giúp cả hai nhóm có khả năng chỉ định, cung cấp, triển khai và đưa ra một loạt các môi trường với mức độ cho phép quản lý các đội, thành viên nhóm và môi trường continuous integration (CI) với khả năng truy cập đầy đủ vào từng môi trường mục tiêu.

Techtalk via techbeacon