Tương lai của kiến trúc hệ thống

Linh Le

Dịch chuyển tâm điểm từ triển khai hệ thống sang tái cấu hình nguồn tài nguyên có sẵn để tăng năng suất doanh nghiệp.

sdn software defined network architecture

Dù chúng ta có nhận ra hay không thì kiến trúc hệ thống cũng đang phát triển. Trong vài thập kỷ qua, kiến trúc hệ thống giống như kiến trúc xây dựng vậy. Quyết định việc hệ thống cần làm, xác định các hệ thống phụ chủ đạo cần thiết và cách chúng sẽ kết nối với nhau, và tiếp tục phân tích cho tới khi đủ chi tiết cho team phát triển xây dựng từng hệ thống phụ và tích hợp chúng nhằm tạo ra hệ thống mong muốn. Mô hình này đã thay đổi những năm gần đây, nhưng tốc độ thay đổi vẫn đang tăng.

Ảnh hưởng của hệ thống mạng

Thiết lập kiến trúc hệ thống bắt đầu thay đổi khi hệ thống nối mạng trở nên phổ biến hơn vào những năm 1990. Kiến trúc khách-chủ nổi lên như mô hình thiết kế ưu việt đã khiến cho việc thêm giao diện mạng vào trở nên cần thiết hơn. Các hệ thống không còn là những đơn vị riêng lẻ được triển khai ở một chỗ và dùng ở những điểm cố định nữa mà nó đã trải rộng khắp một khu vực địa lý rộng lớn.

Ảnh hưởng lớn tiếp theo của mạng với sự phát triển của kiến trúc hệ thống là hy vọng tích hợp các hệ thống. Không mất nhiều thời gian để nhận ra rằng việc nhập cùng dữ liệu vào các hệ thống khác nhau tốn thời gian và có thể gây ra lỗi, vì vậy chúng ta đã bắt đầu thử và tích hợp các hệ thống để chúng có thể chia sẻ dữ liệu. Điều này dẫn đến việc phát triển kiến trúc định hướng dịch vụ (SOA). Ý tưởng cơ bản của SOA là những nhà cung cấp tiềm năng có thể đưa ra các dịch vụ mà chúng có thể được gọi ra từ bất cứ ứng dụng nào trên mạng. Một “dịch vụ” không có gì hơn là một giao diện được định nghĩa chuẩn với một số tính năng cần thiết. SOA hứa hẹn một kỷ nguyên ứng dụng đa thành phần bùng nổ có thể được các doanh nghiệp đón nhận khi họ nổi lên mà không cần đến những ứng dụng phải viết lại code

Sự lớn mạnh của các dịch vụ

Cũng như nhiều công nghệ mới đang nổi đình đám, SOA không bao giờ hoàn toàn tốt như những hứa hẹn ban đầu. Nhưng cũng giống như những công nghệ đang nổi, một thâp kỷ sau khi sự thổi phồng qua đi, chúng ta sẽ thấy được những lợi ích thực sự của triết lý SOA. Nhiều tính năng tồn tại dưới dạng các dịch vụ, và chúng ngày càng được các doanh nghiệp sử dụng nhiều hơn. Ví dụ, Facebook, Google và những phần mềm khác có dịch vụ xác thực danh tính. Nếu bạn chạy một trang web và muốn xác thực người dùng trước khi cho phép họ truy cập tất cả các tính năng của trang, bạn không cần phải làm chủ hệ thống phụ có xác thực của mình – bạn có thể chỉ dùng một trong các tính năng dưới dạng dịch vụ là đủ. Tương tự như vậy, các luồng bình luận, việc tích hợp truyền thông xã hội, số liệu người dùng và các chức năng khác cũng được cung cấp dưới dạng dịch vụ. Cuộc cách mạng điện toán đám mây thực chất là sự chuyển đổi phần cứng máy tính thành dịch vụ cần thiết cho người dùng.

Mặc dù nó không giống với những hình dung ban đầu, nhưng cuộc cách mạng SOA đã xảy ra một cách dứt khoát nhất. Hầu hết các nỗ lực tích hợp doanh nghiệp ngày nay tập trung và việc tạo giao diện hệ thống cho công chúng. Điều này thường được xem là “triết lý đầu tiên của giao diện lập trình ứng dụng (API)”. Ví dụ phổ biến nhất của triết lý đầu tiên API có lẽ là bức thư được biết tới với cái tên là “bài diễn văn của Steve Yegge,” trong đó anh ta đã chỉ trích Google vì không tiếp nhận triết lý thiết kế đầu tiên của API từ Amazon. Sự công kích cơ bản từ lá thư đó nói rằng tất cả các tính năng nên được đưa ra trên mạng thông qua các API để thúc đẩy việc tích hợp và giảm lượng tính năng bị trùng lặp mà doanh nghiệp đang tạo ra (và phải trả tiền).

Cách thức API đang vận hành kiến trúc hệ thống

Tính tới hiện tại, tác dụng cơ bản của chỉ thị đầu tiên của API là để các lập trình viên đảm bảo họ viết tài liệu cho các API của họ và ra mắt chúng. Nhưng áp lực chính của chỉ thị đầu tiên của API từ Amazon là để giảm chi phí từ việc phát triển các tính năng bị trùng lặp trong nhiều hệ thống.

Vì hầu hết các doanh nghiệp không cập nhật hệ thống của họ vài năm một lần, nên chỉ thị đầu tiên của API sẽ mất thời gian để tạo nên ảnh hưởng cho doanh nghiệp. Nhưng theo thời gian, những ảnh hưởng này sẽ được mọi người nhận ra, nhất là khi một chỉ thị đầu tiên của API được kết hợp với một chỉ thị dùng lại-trước khi-tạo mới. Loại chỉ thị này yêu cầu các lập trình viên hệ thống dùng lại các tính năng có sẵn trong doanh nghiệp trước khi xây dựng các tính năng mới.

Vì ngày càng nhiều hệ thống có tính năng thông qua API, và các team phát triển phần mềm được yêu cầu dùng lại trước khi xây dựng cái mới, nên sẽ tới lúc việc xây dựng hệ thống mới được thay thế bằng việc tái tạo các tính năng có sẵn thành những tính năng mới. Số lượng các tính năng dư thừa khắp các hệ thống với những mục đích khác nhau sẽ rất đáng kinh ngạc. Hầu hết các hệ thống cần một giải pháp lưu trữ và gọi dữ liệu ra. Hầu hết các hệ thống cần một giải pháp để xác nhận và cấp quyền cho người dùng. Hầu hết các hệ thống cần khả năng hiển thị văn bản và diễn tả tranh đồ họa. Danh sách các tính năng có thể được dùng lại từ nguồn tài nguyên có sẵn trong doanh nghiệp sẽ càng lúc càng dài ra. Vào những ngày đầu phát triển hệ thống, một lập trình viên sẽ cần phải tạo ra từng tính năng để có một hệ thống thiết thực tối thiểu. Với rất nhiều tính năng cơ bản ở dạng dịch vụ, một công việc của nhà thiết kế hệ thống sẽ liên quan từ việc thiết kế toàn bộ hệ thống cho tới việc thiết kế cải tiến các tính năng phụ trợ trong hệ sinh thái doanh nghiệp.

Tiến tới kiến trúc tập trung vào tính năng

Hệ sinh thái doanh nghiệp mà chúng ta đang đối mặt ngày nay là một hệ sinh thái trong đó một tập hợp các tính năng rộng mở chưa từng thấy tồn tại dưới dạng một dịch vụ, nhất là trong môi trường đám mây. Các nhà cung cấp dịch vụ đám mây chạy đua để đưa ra nhiều tính năng hơn, và giờ đây đã có thể phát triền các hệ thống cơ bản bằng việc gắn các dịch vụ lại với nhau bằng ngôn ngữ kịch bản và gắn kết. Để làm điều đó, các lập trình viên có thể tạo ra một hệ thống thiết thực tối thiểu trong vài tuần thay vì vài tháng. Hệ thống cơ bản này có thể được cải tiến nhanh chóng bằng việc kết hợp vào các dịch vụ mới hoặc cài đặt các module có sẵn khi nó không có dịch vụ nào đó. Trong một môi trường như thế, một pha thiết kế kéo dài nhiều tháng với nỗ lực tìm ra các chi tiết của hệ thống trước khi tiến hành xây dựng là điều không hợp lý. Chúng ta cần một cách nghĩ mới về kiến trúc và thiết kế  hệ thống.

Với một doanh nghiệp đã có sẵn một số dịch vụ, việc xây dựng một hệ thống mới nên bắt đầu bằng việc xác định rõ những tính năng nào mà hệ thống cần có để thực hiện và so sánh nó với danh sách tính năng của dịch vụ đã có sẵn. Điều này sẽ cho thấy hệ thống mong muốn đã có sẵn trong doanh nghiệp bao nhiêu phần trăm và cần phải xây dựng thêm bao nhiêu để hoàn thiện. Sự khác biệt giữa các tính năng có sẵn và các tính năng cần có xác định khoảng cách giữa các tính năng hiện tại và mong muốn của doanh nghiệp. Vì chúng ta luôn tới tới tương lai, nên nhiệm vụ chính của kỹ sư thệ thống sẽ liên quan tới việc thiết kế toàn bộ hệ thống cho tới định nghĩa chi tiết tính năng hiện tại và thiết kế những phương pháp tốt nhất nhằm rút ngắn khoảng cách đó lại.

Hiện tại kiến trúc tập trung vào tính năng này hoàn toàn không phải dễ dàng với chúng ta. Khả năng hiểu được những dịch vụ nào hiện đang có trong doanh nghiệp của chúng ta khá hạn chế. Bất cứ nhà quản lý mạng thành thật nào cũng sẽ thừa nhận rằng họ không thật sự xử lý hết tất cả các dịch vụ có trên mạng của họ. Họ có thể biết chiếc máy nào kết nối với mạng nào, phần mềm nào đang chạy trên mạng nào cũng như cổng và các giao thức nào đang mở trên từng thiết bị. Nhưng thông tin đó chỉ nói cho chúng ta biết về các khía cạnh cấp độ của mạng của những thứ đó –  nó không cho thấy bất cứ điều gì về việc những thứ đó được sử dụng ra sao. Ví dụ, một hệ thống trên mạng có cổng 8443 mở và chấp nhận các kết nối giao thức HTTP có thể cung cấp các trang web hoặc các dịch vụ REST qua giao thức đó.

Có một số cách vượt qua được sự thiếu hụt trong hiểu biết này, nhưng hầu hết đều thủ công. Ví dụ, việc bảo trì một trang wiki, trang chuyên liệt kê danh sách các dịch vụ trong doanh nghiệp yêu cầu các lập trình viên thêm các dịch vụ họ đã triển khai và duy trì danh sách đó. Những phương pháp tự động cho việc xác nhận và phân loại giao diện dịch vụ trong thời gian gần với thực tại sẽ hiệu quả hơn. Nhưng chúng ta sẽ nói về chủ đề này trong bài viết khác.

Có những ngoại lệ

Có vài lĩnh vực mà các kiến trúc hệ thống truyền thống vẫn sẽ tồn tại nhờ vào môi trường mà hệ thống đó cần vận hành. Bất cứ môi trường vận hành nào mà khi cần tới một chức năng của doanh nghiệp có thể gây ra phiền phức đều sẽ cần thực hiện thiết kế hệ thống toàn phạm vi theo kiểu truyền thống. Ví dụ, hệ thống kiểm soát chuyến bay nhân tạo thật sự không thể dựa vào khả năng yêu cầu dịch vụ nằm dưới đất khi cần bất cứ chức năng liên quan tới an toàn chuyến bay nào. Tương tự, hệ thống vệ tinh và các loại phần mềm nhúng khác sẽ cần cung cấp tất cả các tính năng cần thiết cục bộ.

Cách thiết kế kiến trúc hệ thống truyền thống sẽ không biến mất hoàn toàn, nhưng cũng đã khá trễ để chúng ta bắt đầu suy nghĩ về cách cải tiến hiệu quả việc sử dụng kiến trúc hệ thống của chúng ta, để chúng có thể hỗ trợ tình hình kinh doanh phát triển nhanh chóng ngày nay.

 

Chia sẻ bài viết ngay

Nguồn bài viết : https://www.cio.com