Tại sao các tập đoàn công nghệ lớn bị ám ảnh bởi việc tạo ra các giải pháp độc quyền

Xin chào! Tôi muốn nói về lý do tại sao các tập đoàn công nghệ lớn bị ám ảnh bởi việc tạo ra các giải pháp độc quyền cho cơ sở hạ tầng của họ. Câu trả lời có vẻ hiển nhiên: đó không gì khác hơn là hội chứng NIH. Nhưng câu trả lời này còn lâu mới hoàn thiện, chưa kể còn khách quan.

Tôi là CTO của nhóm Kỹ thuật nền tảng Yandex và mục tiêu của chúng tôi là hỗ trợ các kỹ sư xây dựng toàn bộ chu trình phát triển, từ viết mã đến vận hành dịch vụ, để làm cho quy trình đó hiệu quả hơn. Điều này bao gồm việc hợp lý hóa quy trình: chúng tôi không chỉ phát triển các dịch vụ dưới dạng dịch vụ mà còn hỗ trợ triển khai chúng trong công ty. Điều này hoạt động trên quy mô của Yandex: dịch vụ của chúng tôi được hàng nghìn nhà phát triển trên toàn công ty sử dụng.

Ví dụ về các công cụ tổ chức chu trình phát triển

Để giải quyết vấn đề, chúng tôi thường phát triển các công cụ độc quyền thay vì triển khai các công cụ có sẵn. Ví dụ: khi vẫn là lập trình viên trong nhóm, tôi đã làm việc trên hệ thống giám sát định lượng bằng C++ và Python và giúp mở rộng quy mô lên hàng chục tỷ số liệu được xử lý. Vì vậy, dựa trên kinh nghiệm của bản thân, tôi biết động lực và con đường phát triển nào dẫn đến sự xuất hiện của các công cụ nội bộ: dưới đây, tôi sẽ cố gắng xác định những lý do cơ bản cho việc tạo ra chúng bằng cách sử dụng các giải pháp của chúng tôi làm ví dụ.

Câu chuyện số 1: Đám mây nội bộ của Yandex

Đặt nhiệm vụ. Mục tiêu của Runtime Cloud nội bộ của chúng tôi, hay RTC, là cung cấp cho người dùng nội bộ các công cụ quản lý lưu lượng và triển khai đơn giản. Người dùng RTC cũng chính là những kỹ sư phát triển dịch vụ Yandex. Và họ cần khởi chạy hàng chục nghìn ứng dụng mà họ đã tạo ở đâu đó, gửi yêu cầu của người dùng đến đó, cân bằng tải và xử lý các sự cố, cùng nhiều việc khác.

Nhu cầu về đám mây nội bộ xuất hiện vào đầu những năm 2010, khi số lượng dịch vụ đã lên tới hàng trăm và tổng số lõi được phân bổ tăng hàng chục phần trăm mỗi năm. Việc có các máy chủ chuyên dụng cho mỗi dịch vụ trở nên cực kỳ tốn kém và chúng tôi yêu cầu các công cụ cho phép chúng tôi chạy các ứng dụng từ nhiều dịch vụ trên một máy chủ. Chúng tôi đã có một số yêu cầu đối với những công cụ này ngay từ đầu:

• Cần phải tự động hóa các hành động thường ngày để tiết kiệm tài nguyên vận hành và giảm số lượng sự cố trong quá trình phát hành.
• Một nhiệm vụ quan trọng riêng biệt là tăng cường sử dụng đám mây, đặc biệt vì hầu hết các dịch vụ đều có quy trình tải hàng ngày và đám mây không hoạt động vào ban đêm. Tình hình còn phức tạp hơn bởi thực tế là không phải tất cả các dịch vụ Yandex đều được lưu trữ trên đám mây trong những năm đó và số lượng máy chủ tăng liên tục đã khiến vấn đề trở nên trầm trọng hơn.
• Điều quan trọng là phải nhanh chóng triển khai các tính năng hoặc sửa lỗi cho người dùng vì điều này ảnh hưởng trực tiếp đến tốc độ phát triển Yandex.
• Chỉ cần hỗ trợ IPv6: để cung cấp kết nối đầu cuối giữa các nhóm, các trung tâm dữ liệu của chúng tôi được xây dựng chỉ dành cho IPv6, vì ở quy mô của chúng tôi, phạm vi địa chỉ IPv4 sẽ không đủ đối với chúng tôi.

Về cơ bản, chúng tôi cần Kubernetes (và theo thời gian, RTC đã tiến rất gần). Nhưng đây là điều đáng chú ý: k8s chỉ được công bố vào năm 2014. Apache Mesos tồn tại vào thời điểm đó, nhưng nó vẫn còn ở giai đoạn sơ khai.

Thực hiện các chức năng cơ bản. Chúng tôi bắt đầu giải quyết vấn đề bằng một loại MVP - một bộ công cụ đơn giản, giống như một tập hợp các khối xây dựng tự động hóa các hành động thông thường, ví dụ:

• phân bổ tài nguyên cụm;
• phân phối phiên bản yêu cầu của ứng dụng và các tạo phẩm khác nhau cho cụm;
• khởi chạy phiên bản ứng dụng được yêu cầu trên cụm.

Theo thời gian, người ta có thể tập hợp một biểu đồ bố cục dịch vụ hoàn chỉnh bằng cách sử dụng các khối xây dựng này (tương tự như phân phối liên tục). Sau một số lần lặp lại nhất định, Nanny, một hệ thống quản lý các dịch vụ chạy tại RTC, đã xuất hiện vào năm 2013.

Một khía cạnh cơ bản khác của Nanny là việc thực hiện cách ly ứng dụng dựa trên mức tiêu thụ tài nguyên. Ban đầu, chúng tôi đã khởi chạy các ứng dụng từ nhiều dịch vụ khác nhau mà không cách ly tài nguyên, dẫn đến một số lượng lớn sự cố và sự cố vận hành.

Vào thời điểm đó, các giải pháp làm sẵn duy nhất là LXC, lúc đó đã ngừng phát triển và Docker, không thể sử dụng IPv6 và khởi động lại tất cả các vùng chứa khi cập nhật dockerd, khiến không thể cập nhật dockerd mà không ảnh hưởng đến người dùng. Kết quả là chúng tôi bắt đầu phát triển hệ thống container hóa trên nhóm nhân Linux vào khoảng giữa năm 2014. Hầu hết các ứng dụng và một số tác nhân hệ thống trên máy chủ đã được chuyển sang vùng chứa Porto vào năm 2015.

Giải quyết vấn đề sử dụng. Vào thời điểm đó, việc quản lý tài nguyên trên đám mây nội bộ được thực hiện thông qua các cam kết đối với kho lưu trữ. Tuy nhiên, điều này đã làm chậm sự phát triển của Yandex và mâu thuẫn với nhiệm vụ tăng cường sử dụng: để giải quyết vấn đề này, chúng tôi cần đặt hệ thống thu nhỏ bản đồ của mình lên đám mây, cụ thể là - hệ thống nội bộ độc quyền của chúng tôi để lưu trữ dữ liệu lớn và điện toán phân tán mà chúng tôi đã phát triển khoảng 7 năm vào thời điểm đó. Nó phải được đưa vào đám mây nội bộ nhưng cũng phải chạy cùng với các ứng dụng của người dùng.

Để đưa YTsaurus lên RTC, cần có khả năng quản lý nhóm một cách linh hoạt thay vì thông qua các cam kết của kho lưu trữ. Vì vậy, năm 2018, chúng tôi đã tạo ra , một hệ thống quản lý tài nguyên điện toán cụm. Yandex Planner được tích hợp với hệ thống triển khai Nanny hiện có, bỏ chặn quá trình di chuyển YTsaurus và biến RTC thành một đám mây chính thức. RTC có hàng chục nghìn máy chủ vào thời điểm đó và với việc giới thiệu tính năng thu nhỏ bản đồ, con số này đã tăng lên đáng kể.

Những nỗi đau mới lớn dần. Trong cùng khoảng thời gian đó, k8s đã phát triển thành một giải pháp hoàn thiện hơn nhiều, trở thành một trong những dịch vụ AWS vào năm 2017. Tuy nhiên, nó vẫn chưa đáp ứng được tất cả các yêu cầu của chúng tôi:

• Quy mô hàng chục nghìn máy chủ - một bản cài đặt k8s vẫn không thể xử lý được quy mô của chúng tôi.
• Hỗ trợ cho IPv6 và IPv4 xếp chồng kép chỉ xuất hiện trong k8 vào năm 2020 và IPv6 rất quan trọng đối với chúng tôi ngay từ đầu.
• Hỗ trợ cho các vùng chứa lồng nhau mà chúng tôi yêu cầu vì chúng tôi đã quyết định tạo các bộ lập lịch tính toán và lô riêng biệt. Tại một thời điểm, chúng tôi đã so sánh tính hiệu quả của tùy chọn này với tùy chọn của một công cụ lập lịch chung và sẽ thuận tiện và có lợi hơn nếu không cố gắng tạo một công cụ lập lịch chung cho mọi thứ.

YTsaurus tích cực sử dụng khả năng tạo các vùng chứa Porto lồng nhau thay vì tạo một bộ lập lịch duy nhất. Tất nhiên, chúng tôi có thể tự thêm hỗ trợ cho cùng một ngăn xếp kép trong k8. Tuy nhiên, trải nghiệm phát triển nhân Linux đã chỉ ra rằng không phải mọi thứ đều có thể được gửi tới nguồn mở và chúng tôi cố gắng giữ mức delta từ nhân ngược dòng ở mức tối thiểu để đơn giản hóa việc cập nhật lên phiên bản mới.

Giải pháp của chúng tôi ngày hôm nay. Kiến trúc của RTC rất giống với Kubernetes. Người dùng mô tả khai báo dịch vụ của họ dưới dạng một số thông số kỹ thuật mô tả cách khởi chạy ứng dụng được chỉ định và trung tâm dữ liệu nào. Mỗi trung tâm dữ liệu có bản cài đặt Yandex Planner riêng, một mặt đóng vai trò là cơ sở dữ liệu cho tất cả các đối tượng cụm và mặt khác là bộ lập lịch nhóm. Mỗi máy chủ trong trung tâm dữ liệu chạy một tác nhân nhận thông số kỹ thuật nhóm từ Yandex Planner và khởi chạy chúng bằng hệ thống chứa Porto độc quyền của chúng tôi.

Hiện tại, RTC đã tung ra hàng chục nghìn dịch vụ, phân bổ hơn 5 triệu lõi cho hơn 100.000 máy chủ. Mỗi ngày, có hơn 100.000 thay đổi về thông số kỹ thuật dịch vụ được thực hiện.

Các kế hoạch. Điều gì sẽ xảy ra nếu k8s có thể xử lý quy mô của chúng tôi? Đặc biệt là kể từ khi hệ sinh thái k8s bắt đầu hoạt động tốt hơn chúng tôi về mặt chức năng ở một thời điểm nào đó. Sẽ tốt hơn nếu chuyển sang k8s và hy vọng rằng các công cụ làm sẵn cuối cùng sẽ cung cấp khối lượng mà chúng tôi yêu cầu? Trên thực tế, chúng tôi tiếp tục là người tiêu dùng thích hợp cho k8 vì chỉ một tỷ lệ nhỏ các công ty hoạt động ở quy mô lớn như vậy, mỗi công ty đều có giải pháp đám mây nội bộ của riêng mình.

Một điểm quan trọng khác cần nhớ là vấn đề di chuyển. Theo tháng 7 năm 2018 báo cáo, 90% ứng dụng hiện đại sẽ vẫn được sử dụng vào năm 2025 và nợ kỹ thuật để phát triển các hệ thống này sẽ chiếm hơn 40% ngân sách CNTT. Điều này gần với thực tế, dựa trên kinh nghiệm của chúng tôi khi di chuyển dịch vụ người dùng sang Yandex Planner: vào năm 2023, khoảng 100 nghìn lõi vẫn đang chờ đến lượt chuyển sang Yandex Planner.

Vào năm 2021, chúng tôi đã ước tính chi phí để chuyển từ hệ thống triển khai này sang hệ thống triển khai khác khi chọn chiến lược phát triển của mình. Việc chuyển đổi Yandex sang vanilla k8 sẽ là một nhiệm vụ cực kỳ tốn kém, tiêu tốn hàng trăm năm công.

Theo cách đơn giản này, chúng tôi đã đạt được đám mây bên trong của mình, thứ mà chúng tôi khó có thể từ bỏ trong 5 năm tới, ngay cả khi chúng tôi đặt mục tiêu như vậy.

Nên làm gì khi thiếu chức năng đám mây nội bộ so với k8? Trên thực tế, khách hàng của chúng tôi có thể sử dụng Kubernetes được quản lý trong Đám mây Yandex. Tùy chọn này chủ yếu được sử dụng cho các dự án phải đáp ứng các yêu cầu tuân thủ nghiêm ngặt - đây là một tỷ lệ nhỏ các nhóm, dưới 1%. Vì những lý do nêu trên, phần dân số còn lại không nhận được nhiều lợi ích từ việc di chuyển.

Đồng thời, chúng tôi đang tích cực xem xét k8 và xem xét cách tiến gần hơn đến các tiêu chuẩn được chấp nhận chung. Chúng tôi đã tích cực thử nghiệm k8 trong một số tác vụ, chẳng hạn như khởi động đám mây hoặc tổ chức IaaC ở quy mô toàn bộ Yandex. Lý tưởng nhất là chúng tôi muốn sử dụng lại giao diện k8s trong khi vẫn duy trì cách triển khai của riêng mình sao cho phù hợp với nhu cầu của chúng tôi nhất có thể. Tất cả những gì còn lại là tìm ra cách thực hiện nó trong thực tế.

• Còn những người khác thì sao? Vì chúng ta đang thảo luận về công nghệ lớn nói chung trong bài viết này nên cần lưu ý rằng trường hợp của chúng tôi không phải là duy nhất. Kiểm tra hoặc trường hợp để lấy ví dụ.

Câu chuyện số 2: kho lưu trữ đơn

Vấn đề và yêu cầu giải pháp . Kho lưu trữ đơn của chúng tôi, Arcadia, có cùng mục tiêu chính với đám mây nội bộ của chúng tôi: cung cấp các công cụ phát triển thuận tiện. Điều này bao gồm toàn bộ hệ sinh thái phát triển trong trường hợp kho lưu trữ:

• hệ thống kiểm soát phiên bản (Arc),
• Giao diện (Arcanum),
• xây dựng hệ thống (ya thực hiện),
• CI/CD (CI mới).

Arcadia nổi lên cùng thời điểm với đám mây nội bộ của Yandex. Một trong những lý do tạo ra kho lưu trữ đơn là nhu cầu sử dụng lại mã trong Yandex. Điều này đã bị cản trở vào thời điểm đó bởi sự hiện diện của một số hệ thống xây dựng. Cần có một hệ thống thống nhất hỗ trợ các bản dựng phân tán hiệu quả để hoạt động trên quy mô của toàn bộ Yandex. Nó cũng phải ổn định và có thể sử dụng được.

Triển khai hệ thống xây dựng thống nhất. Hệ thống xây dựng ya make độc quyền của chúng tôi ra mắt vào năm 2013, khi đó nó chỉ dành cho mã C++. Trước khi bạn thực hiện, chúng tôi đã sử dụng CMake, nhưng tốc độ của nó đã ngăn cản nó mở rộng quy mô của một kho lưu trữ đơn lẻ. Công cụ ya make độc quyền hoạt động nhanh hơn nhiều với Arcadia. Không có tùy chọn nguồn mở nào khác có thể giải quyết vấn đề của chúng tôi: ví dụ: Bazel được phát hành muộn hơn nhiều, vào năm 2015.

Mở rộng quy mô hệ thống kiểm soát phiên bản. Yandex trước đây đã sử dụng SVN làm hệ thống kiểm soát phiên bản. SVN tuy có dung lượng lớn nhưng vẫn còn hạn chế và khó bảo trì. Hơn nữa, chúng tôi biết rằng cuối cùng chúng tôi sẽ gặp phải những hạn chế về khả năng và sự tiện lợi của SVN. Ví dụ: phương pháp phỏng đoán được sử dụng để triển khai khả năng chỉ tải xuống phần được yêu cầu của kho lưu trữ hoặc kiểm tra có chọn lọc. Do đó, vào năm 2016, chúng tôi đã bắt đầu thử nghiệm các hệ thống kiểm soát phiên bản khác ngoài SVN.

Mercurial là sự lựa chọn đầu tiên. Nhưng vấn đề chính chúng tôi gặp phải là tốc độ. Chúng tôi đã cố gắng trong một năm rưỡi để đưa Mercurial vào sản xuất nhưng kết quả thật đáng thất vọng. Ví dụ: cuối cùng chúng tôi phải viết lại các phần của Mercurial để hỗ trợ FUSE, nếu không chúng tôi sẽ phải đưa toàn bộ kho lưu trữ vào máy tính xách tay của từng nhà phát triển.

Cuối cùng, hóa ra việc viết một giải pháp nội bộ ngay từ đầu sẽ rẻ hơn và vào năm 2019, Arc đã xuất hiện - một hệ thống kiểm soát phiên bản mới dành cho người dùng Arcadia với UX giống git. Nền tảng của Arc là FUSE (hệ thống tập tin trong không gian người dùng) thay vì kiểm tra có chọn lọc. Ngoài ra, YDB hoạt động như một cơ sở dữ liệu có thể mở rộng, giúp đơn giản hóa đáng kể hoạt động của Arc khi so sánh với Mercurial.

Chúng tôi thường được hỏi tại sao chúng tôi không sử dụng git. Bởi vì nó cũng có những hạn chế về quy mô và chức năng: nếu chúng ta chỉ nhập trung kế Arcadia vào git, trạng thái git sẽ mất vài phút ở quy mô này. Đồng thời, không có triển khai FUSE ổn định được xây dựng dựa trên git: VFS cho Git không còn được phát triển nữa và EdenFS cuối cùng đã được chuyển thành Sapling, nhưng điều này xảy ra muộn hơn nhiều.

Tình trạng hiện tại và kế hoạch cho tương lai của Solution. Để bắt đầu phát triển, người dùng nội bộ chỉ cần tạo một thư mục trong kho lưu trữ đơn của chúng tôi, viết mã và cho bạn biết cách xây dựng ứng dụng của mình bằng cách thêm bản kê khai bản dựng. Kết quả là người dùng nhận được yêu cầu kéo, cấu hình CI và khả năng sử dụng lại bất kỳ mã nào trong công ty.

Về quy mô, trung kế hiện chứa 10 triệu tệp, tổng kho lưu trữ vượt quá 2 TiB và hơn 30 nghìn cam kết được thực hiện mỗi tuần.

Kết quả là, trong hệ sinh thái mà chúng tôi tạo ra, chúng tôi phải tạo ra nhiều thành phần từ đầu. Tuy nhiên, hiện nay nó đang hướng tới việc tuân thủ các tiêu chuẩn toàn cầu. Ví dụ: Arc hỗ trợ làm việc với Git cho một nhóm dự án được xác định trước.

• Còn những người khác thì sao? Một lần nữa, nếu bạn nhìn vào công nghệ lớn nói chung, thì bạn nên chú ý đến một ví dụ Và .

Những câu chuyện này có điểm gì chung

Vậy tại sao các công ty công nghệ lớn phải phát minh ra giải pháp của riêng họ và tại sao không thể thay thế chúng bằng những giải pháp tuân thủ tiêu chuẩn được chấp nhận rộng rãi?

1. Sự đổi mới. Các tập đoàn lớn thường xuyên được yêu cầu phát triển các giải pháp cho những vấn đề sẽ chỉ trở nên phổ biến trong tương lai. Đây là cách các giải pháp sáng tạo có tiềm năng trở thành tiêu chuẩn thị trường có thể xuất hiện.

   
   

   Không phải lúc nào vấn đề do một công ty giải quyết cũng phải đối mặt với bất kỳ ai khác ngoài chính công ty đó. Đôi khi kinh nghiệm của các công ty công nghệ lớn về một vấn đề cụ thể giúp toàn bộ ngành tránh được vấn đề đó bằng cách đi theo một con đường phát triển hoàn toàn khác. Không phải lúc nào cũng có thể dự đoán được sự phát triển của thị trường và kết quả là, các ví dụ khác nhau về giải pháp độc quyền đã có những kết quả rất khác nhau.

   
   

   ClickHouse là một ví dụ về một dự án đổi mới thực sự thành công đã làm phong phú thêm lĩnh vực xử lý phân tích trực tuyến (OLAP). Tuy nhiên, đây không phải là trường hợp cho tất cả các dự án. Porto, khởi đầu là một dự án nguồn mở, đã không thu hút được sự chú ý vì nhiều lý do. Mặc dù một số tính năng của nó, chẳng hạn như khả năng tạo các vùng chứa lồng nhau, vẫn là duy nhất.

   
   

2. Tỉ lệ. Điểm này tương tự như điểm trước ở một số điểm, vì không phải công ty nào cũng gặp phải vấn đề về khả năng mở rộng. Đã có lúc 640 kbyte là quá đủ cho mọi người phải không?

   
   

   Trên thực tế, tải hệ thống tăng theo cấp số nhân là một trong những lý do quan trọng nhất cho sự phát triển của Arcadia và đám mây nội bộ. Đây là lý do tại sao Arc và Yandex Planner được phát triển. Arc được tạo ra để đáp ứng nhu cầu về một VCS thân thiện với người dùng, có thể cho phép người dùng làm việc với một kho lưu trữ đơn chứa hàng chục triệu tệp trong một thân cây mà không gặp khó khăn. Yandex Planner được tạo ra để đáp ứng nhu cầu làm việc hiệu quả với các cụm gồm hàng chục nghìn nút và hàng triệu nhóm.

   
   

   Các công cụ công cộng tiếp tục gặp vấn đề về quy mô (xét cho cùng, đây là một tình huống tương đối hiếm gặp và việc đầu tư vào nó thường đơn giản là không mang lại lợi nhuận).

   
   

3. Quán tính. Hãy xem xét một công cụ nội bộ có thể giải quyết vấn đề trong công ty. Một công ty tích cực sử dụng công cụ này sẽ dành nguồn lực để điều chỉnh nó tốt hơn theo nhu cầu của mình, cuối cùng biến nó thành một công cụ chuyên môn cao. Quá trình này có thể kéo dài trong nhiều năm.

   
   

   Bây giờ hãy xem xét khả năng, tại một thời điểm nào đó, một tiêu chuẩn được chấp nhận rộng rãi để giải quyết vấn đề cụ thể đó sẽ xuất hiện. Trong trường hợp này, chuyên môn hóa vẫn có thể là một yếu tố quan trọng trong việc quyết định giải pháp nội bộ. Hãy xem xét việc xây dựng hệ thống. Chúng tôi sử dụng ya make tại Arcadia, mặc dù có Bazel từ Google. Chúng giống nhau về mặt khái niệm, nhưng khi bạn đi vào chi tiết, nhiều kịch bản quan trọng được triển khai khác nhau vì kiểu tải cho mỗi khối lượng công việc có thể khác nhau đáng kể. Kết quả là, các nguồn lực đã sử dụng gần như chắc chắn sẽ phải được tái đầu tư để điều chỉnh một tiêu chuẩn mới được chấp nhận rộng rãi.

   
   

4. Di cư. Nếu phần trước đề cập đến vấn đề điều chỉnh dự án cho phù hợp với người dùng thì bây giờ chúng ta hãy giải quyết vấn đề di chuyển chính người dùng. Theo tôi, di cư nên được gọi là vấn đề quan trọng tiếp theo trong lĩnh vực công nghệ sau khi đặt tên. Nếu chúng tôi cho rằng chúng tôi đã có một công cụ nội bộ của công ty và muốn thay thế nó bằng một công cụ được tiêu chuẩn hóa, chắc chắn chúng tôi sẽ cần phải di chuyển.

   
   

   Chúng tôi biết nhiều ví dụ về di chuyển từ kinh nghiệm phát triển đám mây nội bộ của chúng tôi. Việc di chuyển quy mô lớn cần có thời gian, vì vậy cả hai công cụ phải được hỗ trợ đồng thời trong thời gian dài. Nếu quá trình này có sự tham gia của nhiều người dùng thì vấn đề quản lý là khó tránh khỏi. Chắc chắn là đáng để thử di chuyển mà không có sự tham gia của người dùng, nhưng điều này không phải lúc nào cũng có thể thực hiện được.

   
   

5. Kinh doanh liên tục. Thành thật mà nói, điểm này gần đây đã trở nên quan trọng. Trước đây, một số ít công ty đã thực hiện nghiêm túc vấn đề này do lo ngại về việc khóa nhà cung cấp. Việc tin tưởng giao các quy trình quan trọng cho một nhà cung cấp có thể chấm dứt hợp tác bất cứ lúc nào là điều rủi ro. JetBrains là một ví dụ điển hình về điều này, đã hạn chế việc sử dụng IDE của nó đối với một số công ty nhất định. Một trường hợp khác là Github Enterprise, công ty đã bắt đầu đình chỉ tài khoản người dùng ở Nga.

   
   

   Các giải pháp nội bộ thường miễn nhiễm với vấn đề này. Một mặt, vẫn còn các giải pháp nguồn mở. Mặt khác, không có gì đảm bảo rằng mô hình nguồn mở sẽ luôn đồng hành cùng bạn: ví dụ: Corona, cải tiến nội bộ của Facebook đã phát triển cho phần mềm lập kế hoạch Hadoop MapReduce, xuất hiện ngay từ đầu do không thể cam kết các bản vá cần thiết để mở rộng quy mô ngược dòng của Hadoop.

   
   

   Đồng thời, khía cạnh pháp lý của vấn đề ảnh hưởng đến nguồn mở: ví dụ: các cam kết trong golang hoặc k8 bắt buộc phải ký CLA. Điều này sẽ tiếp tục là một vấn đề?

   
   

6. NIH. Đúng vậy, ngoài những lý do khách quan, có thể những quyết định đưa ra không thực tế. Đó là hội chứng NIH tốt nhất.

   
   

   Ví dụ: trong nỗ lực loại bỏ ảnh hưởng của lô đối với tính toán, chúng tôi đã cố gắng tạo bộ lập lịch của riêng mình trong nhân Linux. Trong thực tế, nó chẳng mang lại điều gì tốt đẹp cả; người ta có thể thực hiện được với các khả năng hiện có của nhân Linux. Tuy nhiên, chi phí lao động càng cao thì càng có nhiều nỗ lực để tìm hiểu và giải quyết vấn đề, đồng thời khả năng mắc phải hội chứng NIH càng thấp.

   
   Tóm lại , như bạn có thể thấy, các giải pháp nội bộ cho các công ty lớn thường được yêu cầu. Phần lớn trong số chúng sẽ hợp nhất với các giải pháp tiêu chuẩn toàn cầu thống nhất chưa trưởng thành trong tương lai, trong khi phần còn lại sẽ trở thành lịch sử. Trong mọi trường hợp, việc quyết định giữa giải pháp độc quyền và giải pháp làm sẵn vẫn là một câu hỏi khó không thể trả lời nếu trước tiên không hiểu bối cảnh và ước tính chi phí của một dự án như vậy.