Microsoft Nano Server và tương lai của devops

Các hệ điều hành hạng nhẹ như Nano Server và CoreOS cung cấp một phần nền tảng quan trọng cho cơ sở hạ tầng đám mây lập trình mai sau.

Nếu bạn là một nhà lập trình, thì tại sao bạn lại lo lắng về cơ sở hạ tầng? Xét cho cùng, chúng ta đã quen với việc viết code đơn giản, chuyển nó sang môi trường staging, và để cho nhóm vận hành đẩy code ra như một ứng dụng user-facing.

Nhưng hiện nay mọi thứ đã khác. Chúng ta đang viết các ứng dụng mà cần được chuyển giao nhanh chóng, vận hành linh hoạt, và tận dụng các khả năng của các trung tâm dữ liệu được định rõ bằng phần mềm của mai sau.

Thông báo của Microsoft gần đây về Nano Server là một phản ánh thú vị về xu hướng này. Nano Server được thiết kế nhẹ, dễ triển khai dựa vào hệ điều hành cho các hypervisor và container, Nano Server có thể được nghĩ đến như là một điểm nơi mà các cơ sở hạ tầng lập trình được và vận hành hệ thống đáp ứng. Nó cũng được nghĩ đến như là đương lượng Windows của CoreOS, một phiên bản rút gọn đến mức đơn giản nhất của Linux mà đã trở thành hệ điều hành được ưa thích hơn để chạy các container của Docker.

Trong khi Nano Server nhìn giống như một Windows Server mỏng manh với tất cả UI không liên quan được loại bỏ, nó thật sự là một nền tảng cho việc chuyển giao các tính năng của chương trình, ở đây bạn có thể sử dụng các công cụ DSC (Desired State Configuration) của PowerShell để triển khai các tính năng này khi cần thiết.

Có một sức mạnh tổng hợp ở đây với các công cụ quản lý cấu hình như Chef, người có “các công thức” bao gồm chi tiết về các dịch vụ cần thiết của một ứng dụng. Với Nano Server, bạn sẽ có thể không chỉ triển khai các hệ điều hành, mà còn định dạng và triển khai các dịch vụ cho một ứng dụng đơn giản chỉ cần bằng cách kích hoạt bộ hoạt động DSC.

Một sự kết hợp của Nano Server và Chef cung cấp một lựa chọn thú vị cho các nhóm hoạt động vì nó đẩy phần lớn trách nhiệm cho việc quản lý cơ sở hạ tầng của một ứng dụng tới devops. Thay vì phải quản lý nhiều hình ảnh máy chủ, một nhóm hoạt động cần có một hình ảnh hệ điều hành cơ sở duy nhất có thể được quản lý và vá, trong khi đội devops xử lý các dịch vụ và tính năng của các ứng dụng – và chỉ có các ứng dụng của họ – cần.

Nếu chúng ta cung cấp khả năng mở rộng cao, các dịch vụ đám mây rất linh hoạt để hỗ trợ các ứng dụng, thì chúng ta sẽ cần phải bắt đầu suy nghĩ về cách chúng ta quản lý sự thay đổi vào các trách nhiệm. Containerization cho phép chúng ta tóm tắt các ứng dụng từ các hệ điều hành, trong khi tất cả các kỹ thuật ảo hóa khác nhau mà chúng ta đang sử dụng để chúng ta làm như vậy đối với cơ sở hạ tầng.

Hầu hết thời gian chúng ta thiết kế các ứng dụng cho cơ sở hạ tầng tĩnh, nơi trường hợp máy chủ xác định các yếu tố của các ứng dụng. Mô hình hoạt động tốt cho các hình mẫu quen thuộc MVC và MVVM, nơi chúng ta đang xây dựng các ứng dụng lấy dữ liệu từ các điểm cuối, sau đó quá trình, định dạng, và chuyển giao nó tới một điểm cuối khác. Nhưng những gì của các ứng dụng internet trong tương lai, nơi mà chúng ta cần phải xử lý thông tin từ hàng ngàn, nếu không phải hàng triệu điểm cuối? Không có điểm cuối nào sẽ được đồng bộ hóa với các máy khác.

Nó chỉ ra rằng một trong những mẫu thiết kế lâu đời nhất hoạt động tốt ở đây: actor. Mục đích để xử lý và quản lý tin nhắn không đồng bộ, các mô hình actor là trung tâm của ngôn ngữ chức năng như Erlang và được sử dụng bởi nhiều hệ thống AI đám mây quy mô lớn – cũng như của cơ sở dữ liệu NoSQL được phân phối như Riak của Basho. Các Actor là những công cụ mạnh mẽ, và chúng vốn đã mở rộng: Khi bạn thêm các actor mới cho một dịch vụ, bạn cần phải làm là cập nhật bất kỳ danh sách địa chỉ để chuyển tải thông điệp một cách thích hợp.

Mẫu Actor có thể được áp dụng khá rộng rãi. Bạn có thể dễ dàng xem một Node.js chuyển đổi yếu tố trong một ứng dụng Node-red là một actor.

Actor là một công cụ quan trọng cho IoTs, nơi bạn cần phải làm việc với các tin nhắn từ bất kỳ thiết bị vào bất cứ lúc nào, chuyển đổi các sự kiện thành các dòng hoặc thành hành động, hoặc chỉ đơn giản là lưu trữ chúng như dữ liệu. Actor cũng là chìa khóa để mở rộng quy mô ứng dụng IOT của bạn và lợi dụng cách mà họ có thể mở rộng quy mô. Điều đó đáng để suy nghĩ về một actor như một microservice, với những thông điệp của nó như là một phiên bản mỏng và nhẹ của một chiếc xe buýt phục vụ doanh nghiệp.

Buộc một actor vào một container, sau đó đến một OS làm cho nó dễ dàng để mở rộng các ứng dụng nhanh chóng – đơn giản hóa việc triển khai hệ điều hành, cấu hình, và vận hành. Nếu bạn cần một ví dụ dịch vụ mới, bạn chỉ cần bắt đầu một container mới. Trong khi bạn có thể chưa sinh ra trường dịch vụ mới trong một phần nghìn giây cần cho AWS Lambda để kích hoạt một ứng dụng từ một sự kiện, bạn có thể sở hạ tầng trước tải, gây ra triển khai mới như các dịch vụ chạy. Các máy ảo bị treo thì rẻ, và nó mất rất ít thời gian để định dạng lại mạng được định rõ bằng phần mềm để hỗ trợ các máy ảo mới, đặc biệt là nếu Nano Server hoặc CoreOS là hệ điều hành cơ bản.

Làm việc với cơ sở hạ tầng có thể lập trình được, như các nguyên tắc phát triển nhanh nhẹn đề nghị, suy nghĩ tốt nhất là nguyên tắc đầu tiên – không phải là một mục để trang bị thêm sau khi bạn đã chuyển mã và người dùng của bạn đã làm việc với một ứng dụng. Hiểu được cách ứng dụng của bạn và cơ sở hạ tầng của nó tương tác là một phần của bất kỳ quá trình phát triển, do đó, bạn đã sẵn sàng để tung ngay sau khi bạn nhấn nút triển khai.

Đưa sự phát triển và hoạt động với nhau là chìa khóa để chuyển giao thành công các microservice dựa trên mẫu thiết kế khả năng mở rộng, đặc biệt là về một thế hệ mới của các hệ điều hành được tối ưu hóa để làm việc với các container. Điều đó có nghĩa các đội phát triển cần phải có một sự hiện diện devops nhúng sâu sắc, do đó, các cơ sở hạ tầng và các công cụ được sử dụng để quản lý nó là một phần của tất cả mọi thứ bạn làm.

Nguồn bài viết : http://www.infoworld.com/