Data science

Tính hai mặt của DBaaS: Bạn hay kẻ thù?

Nhấp để tìm hiểu thêm về tác giả Matt Yonkovit. Cháy rừng là một sức mạnh của thiên nhiên. Có khả năng phá hủy lớn, nhưng cũng có khả năng mang lại sự sống mới và tạo điều kiện cho sự phát triển tích cực. Các dịch vụ cơ sở dữ liệu đám mây như một dịch vụ có tính hai mặt tương tự. Sức mạnh của đám mây đã biến đổi cơ sở hạ tầng công nghệ của chúng tôi. Không nơi nào có điều này rõ ràng hơn sự gia tăng của dịch vụ cung cấp cơ sở dữ liệu đám mây. Những dịch vụ mạnh mẽ này (chẳng hạn như Amazon Aurora, Azure SQL, Google Cloud SQL và MongoDB Atlas) đã nhanh chóng trở thành cách phổ biến nhất để mọi người chạy cơ sở dữ liệu của họ trên đám mây. Ngoài ra còn có những thách thức và các vấn đề tiềm ẩn nếu không được sử dụng hoặc triển khai đúng cách. Trong Magic Quadrant mới nhất của mình, Gartner đã đưa ra các giả định chiến lược rằng 75% của tất cả các cơ sở dữ liệu sẽ được triển khai hoặc chuyển sang nền tảng đám mây, với chỉ 5% từng được xem xét cho hồi hương tại chỗ. Bởi 2023, sở thích Quản lý dữ liệu trên đám mây cũng sẽ làm giảm số lượng nhà cung cấp xung quanh trong khi đa đám mây sẽ làm cho mọi thứ phức tạp hơn xung quanh Quản trị dữ liệu và hội nhập. Các nhà phát triển luôn có mối quan hệ mật thiết (tốt nhất là) với cơ sở dữ liệu của họ. Cơ sở dữ liệu được / được coi là một thứ cần thiết khi xây dựng các ứng dụng. Mâu thuẫn giữa DBA và nhà phát triển thường do mỗi nhóm có các mục tiêu và kết quả khác nhau. DBA phải xem xét tính bền vững lâu dài, tính bảo mật, tính khả dụng và khả năng mở rộng. Mặt khác, nhà phát triển nghĩ về các tính năng, lịch phát hành và người dùng. Cơ sở dữ liệu dưới dạng dịch vụ (DBaaS) hứa hẹn sẽ tự động hóa những lo ngại về tính bền vững, bảo mật và tính khả dụng. Nó đặt quyền lựa chọn và vận hành cơ sở dữ liệu vào tay nhà phát triển, cho phép họ di chuyển nhanh chóng và gặt hái thành quả. Tuy nhiên, trong khi các giải pháp cơ sở dữ liệu như một dịch vụ loại bỏ nhiều công việc nhàm chán về cấu hình và vận hành cơ sở dữ liệu, chúng có xu hướng tập trung vào hiệu quả thấp nhất. Điều này để lại các hoạt động cơ sở dữ liệu quản trị hoặc khắc phục sự cố phức tạp hơn cho các nhà phát triển và / hoặc DBA. Ví dụ: bạn có thể có các công cụ để thực hiện sao lưu hoặc mã hóa dữ liệu của mình, nhưng bạn có đang thiết lập chúng một cách chính xác hay tránh những lỗi phổ biến không? Trong vài năm qua, nhiều công ty đã gây chú ý vì dữ liệu của họ cuối cùng đã rơi vào tay tin tặc. Tuy nhiên, trái với định kiến ​​của một hacker máy tính điên cuồng gõ mã vào máy tính xách tay, những vi phạm này thường là kết quả của việc các công ty không tuân theo các phương pháp hay nhất hoặc không hiểu những hạn chế của công nghệ mà họ triển khai. Một trong những nguồn rò rỉ phổ biến nhất là các thùng S3 không được bảo vệ chứa các tệp sao lưu. Chỉ vì bạn có thể nhấp vào nút sao lưu không có nghĩa là bản sao lưu của bạn được mã hóa hoặc bảo vệ đúng cách. Trong một số trường hợp, nó thậm chí còn có thể phục hồi. Đây là lý do tại sao bạn vẫn cần các nguồn lực có sẵn cam kết và hiểu biết để tư vấn về những rủi ro tiềm ẩn. Khi những vấn đề này ngày càng phổ biến, các nhà cung cấp cơ sở dữ liệu và nhà cung cấp đám mây đang thêm các tính năng để giúp giảm thiểu hoặc giải quyết chúng. Tuy nhiên, nhiều vấn đề sâu sắc nhất, có tác động lớn nhất vẫn dựa trên kiến ​​trúc của ứng dụng và cách cơ sở dữ liệu được thiết lập cho một ứng dụng cụ thể. Đây là lúc khái niệm “Trách nhiệm chung” ra đời. Các nhà cung cấp đám mây cung cấp cho bạn các thành phần cơ sở dữ liệu nền tảng để xây dựng một ứng dụng an toàn và có thể mở rộng. Điều đó không có nghĩa là ứng dụng của bạn có thể mở rộng và an toàn. Thông thường, chúng tôi nhận thấy rằng tâm lý “đặt nó và quên” đối với cơ sở dữ liệu (hay đúng hơn là tâm lý “đó là trách nhiệm của nhà cung cấp của tôi”) khiến người dùng phải trả chi phí cao hơn và nhiều công việc lâu dài hơn. Một báo cáo gần đây từ Andressen Horowitz đã nêu bật chi phí tiềm năng cao hơn của đám mây. Theo kinh nghiệm của tôi, chi phí cơ sở dữ liệu thường là một tỷ lệ phần trăm cao hơn theo tỷ lệ của tổng chi tiêu hơn bạn có thể mong đợi. Những chi phí gia tăng này thường là kết quả của việc các công ty giải quyết các vấn đề về cơ sở dữ liệu thông qua mở rộng quy mô bằng thẻ tín dụng (chuyển sang kích thước phiên bản tiếp theo, tăng không gian lưu trữ, v.v.). Đây là một nền kinh tế sai lầm và có thể nhanh chóng đi vào vòng xoáy. Thay vào đó, bằng cách thực hiện thiết kế, quản lý và hỗ trợ cơ sở dữ liệu thích hợp, chi phí có thể giảm tới 50%. Ngoài chi phí cho một giây, có một số điểm quan trọng bạn cần lưu ý khi xem xét cơ sở dữ liệu như một dịch vụ. Cơ sở dữ liệu dưới dạng dịch vụ tốt cho các nhà phát triển và người dùng, và thậm chí tốt hơn cho các nhà cung cấp cơ sở dữ liệu và đám mây (đặc biệt là trong không gian nguồn mở). Tuy nhiên, điều quan trọng cần nhận ra là bạn thường phải đánh đổi quyền kiểm soát và tính di động để dễ thiết lập và sử dụng. Bạn có thể đã nghe thuật ngữ “khóa” được đề cập trong cộng đồng mã nguồn mở. Khóa nhà cung cấp đề cập đến tình huống bạn gặp phải khi bắt đầu sử dụng một nhà cung cấp và sau đó kết thúc với họ trừ khi bạn trải qua một quá trình dài và tốn kém để phát triển lại các phần của ứng dụng của mình (hãy nghĩ về bài hát “Hotel California”: “Bạn có thể đăng ký nhưng bạn không bao giờ có thể rời đi”). Oracle trong 1990 có tiếng xấu về việc nhốt mọi người vào và sau đó chơi trò chơi với chi phí và giấy phép của họ. Trên thực tế, trải nghiệm tiêu cực đó là động lực để mọi người trong doanh nghiệp bắt đầu khám phá cơ sở dữ liệu mã nguồn mở như một giải pháp thay thế. Nếu chúng ta không cẩn thận, DBaaS có thể dẫn đến mức khóa cao nhất trong hơn 20 năm. Mã nguồn mở là một trong những công cụ mạnh mẽ nhất mà người dùng có để chống lại những trò lừa bịp và tai quái trong ngành công nghệ. Điều này đặc biệt được thể hiện tốt trong không gian cơ sở dữ liệu. Ví dụ, nếu bạn muốn chạy MySQL hoặc PostgreSQL, bạn có các tùy chọn. Bạn có thể chọn cách bạn chạy chúng, nơi bạn chạy chúng và loại ngăn xếp bạn chạy chúng với. Bạn có thể triển khai MySQL trên Azure Compute ngay hôm nay và tuần tới bạn có thể triển khai cùng một MySQL trên AWS EC2 và có trải nghiệm tương tự. Mức độ di động này đặc biệt có lợi cho những ứng dụng mới được thiết kế dưới dạng “gốc trên đám mây”, với bản thân các ứng dụng này sẽ có được tính di động cao hơn thông qua thiết kế. Sự gia tăng của các ứng dụng gốc đám mây chạy trên các vùng chứa thông qua Kubernetes đã tách ứng dụng khỏi nhà cung cấp cơ sở hạ tầng. Tính di động và khả năng chạy ở mọi nơi đang trở thành kỳ vọng của thiết kế ứng dụng gốc đám mây. Tuy nhiên, một số giá trị của tính di động này được cung cấp bởi cả nguồn mở và thiết kế ứng dụng có thể bị bù đắp hoặc bị che khuất bởi sự phát triển của các dịch vụ cơ sở dữ liệu dưới dạng dịch vụ. Nhiều nhà cung cấp dịch vụ đám mây cung cấp các dịch vụ DBaaS tương tự, nhưng không hoàn toàn giống nhau, hạn chế tính di động. Amazon Aurora có sự khác biệt về tính năng và các vấn đề tương thích với các phiên bản MySQL khác nhau. Chúng gần giống nhau, nhưng không 100% giống nhau… do đó Aurora tuyên bố là “Tương thích với nguồn mở”. Mỗi bước đi sâu hơn vào MySQL hoặc PostgreSQL DBaaS của nhà cung cấp khiến việc chuyển sang nhà cung cấp khác hoặc thậm chí phiên bản được quản lý của riêng bạn sẽ khó hơn một chút. Đây có thể là một vấn đề hoặc không, tùy thuộc vào mức độ linh hoạt mà ứng dụng của bạn yêu cầu. Nếu bạn cảm thấy thoải mái khi cam kết chạy trên một nhà cung cấp đám mây duy nhất, nhiều dịch vụ DBaaS này có thể mang lại giá trị tốt bằng cách tăng tốc độ quản lý và triển khai. Ngoài những khác biệt về kỹ thuật, nhiều nhà cung cấp cơ sở dữ liệu hiện cũng đang bảo vệ các luồng doanh thu “Dưới dạng dịch vụ” của họ bằng cách chuyển sang giấy phép cơ sở dữ liệu không phải nguồn mở dưới chiêu bài ngăn chặn các nhà cung cấp đám mây ăn cắp kinh doanh và kiếm tiền từ tác phẩm gốc của họ. Giấy phép Công cộng Phía Máy chủ (SSPL) là một ví dụ rõ ràng về điều này. MongoDB đã tạo giấy phép này để loại trừ những người khác tạo các dịch vụ “như một dịch vụ” cạnh tranh với MongoDB (cụ thể là sản phẩm Atlas của họ). Và MongoDB không phải là người duy nhất. Elastic gần đây đã thay đổi giấy phép của họ vì lý do tương tự. Những động thái này hạn chế sự lựa chọn của người dùng. Kết quả cuối cùng là thay vì phần mềm nguồn mở, giờ đây chúng tôi có các nhà cung cấp duy nhất cung cấp cơ sở dữ liệu được quản lý tự động với một khoản phí. Các nhà cung cấp cơ sở dữ liệu tương tự đang cải tiến DBaaS của họ với các tính năng và tùy chọn độc quyền. Ví dụ, Atlas đã công bố một dịch vụ mới Atlas Online Archive cho phép dữ liệu ít được sử dụng hơn được lưu trữ trong S3 hoặc bộ lưu trữ chậm hơn. Điều này có thể giúp giảm đáng kể chi phí và giúp tăng tốc hiệu suất bằng cách khai báo hệ thống với dữ liệu không sử dụng. Là một tính năng được tích hợp sẵn, mọi người nên tận dụng nó vì nó cung cấp một cách dễ dàng, nhất quán và dường như liền mạch để xử lý một vấn đề lâu dài. Như đã đề cập, đây là một ví dụ về giao dịch “dễ dàng” để có thể di chuyển và kiểm soát trong tương lai. Các công ty / ứng dụng có thể làm điều gì đó tương tự bằng cách xây dựng quy trình hoặc quy trình lưu trữ để xử lý những thứ như thế này, nhưng hiện tại không có mã nguồn mở nào tương đương với tính năng này. Vì vậy, nếu bạn quyết định ngừng thanh toán cho MongoDB Atlas, bạn sẽ mất quyền truy cập và sẽ cần phải viết lại các phần của ứng dụng của mình để xử lý chức năng hiện đang bị thiếu. Điều này tương tự với phần mềm độc quyền khác (một lần nữa, hãy nghĩ đến Oracle trong '90 s). Một lợi ích to lớn của mã nguồn mở là nếu chúng ta không thấy giá trị trong việc trả tiền cho nhà cung cấp hoặc đăng ký, chúng ta có các tùy chọn để đưa doanh nghiệp của mình đi nơi khác. Nếu bạn không hài lòng với nhà cung cấp PostgreSQL của mình, có rất nhiều chương trình khác để bạn lựa chọn. Khi các nhà cung cấp mã nguồn mở (hoặc trước đây là mã nguồn mở) di chuyển theo lộ trình DBaaS, ngày càng nhiều tính năng, công cụ và phần mềm của họ sẽ chỉ có sẵn thông qua việc cung cấp DBaaS của họ. Điều này có nghĩa là những người dùng muốn triển khai các phiên bản của riêng họ sẽ dần bị bỏ lại với các phiên bản cũ hơn, kém khả năng hơn và ít tính năng hơn. Cũng có nguy cơ chậm đổi mới vì sự đóng góp của cộng đồng cho phần mềm DBaaS là ​​không thực sự khả thi (bạn không có quyền truy cập vào mã đầy đủ). DBaaS có tệ không? Không! Không có gì. DBaaS cung cấp những lợi ích tuyệt vời cho người dùng và nhà cung cấp. Bất kỳ cơ sở dữ liệu nào được tạo ngày hôm nay đều sẽ coi là cloud-native và DBaaS cung cấp phương pháp triển khai go-to của họ. Người dùng có thể bắt đầu dễ dàng, tập trung vào đổi mới cho doanh nghiệp của họ và có được trải nghiệm nhất quán. Đây là tất cả các chiến thắng lớn. Tuy nhiên, những thắng lợi này không phủ nhận yêu cầu phải có chuyên môn và kiến ​​thức sẵn có để tư vấn cách tốt nhất để thiết kế và xây dựng giao diện giữa ứng dụng và cơ sở dữ liệu. Việc bỏ qua những lỗ hổng kiến ​​thức quan trọng này sẽ mang lại rủi ro (chẳng hạn như chi phí cao hơn và khả năng mất điện và rò rỉ). Điều quan trọng là phải hiểu rằng bạn có thể không còn tính di động mà bạn đã quen thuộc. Trong thế giới mới này, bạn không chỉ cam kết với một công nghệ mà còn là một nhà cung cấp. Cách cộng đồng phát triển và hướng DBaaS thực hiện sẽ quyết định nhà cung cấp nào được coi là đáng tin cậy và nhà cung cấp nào sẽ là câu chuyện cảnh giác cho thế hệ tiếp theo.

  • Trang chủ
  • CRM
  • Email doanh nghiệp
  • Email marketing
  • Marketing News
  • Marketing tổng thể
  • SEO
  • Thiết kế Website
  • Web Hosting
  • Chatbot
  • Data science
  • Back to top button