Nhiều người thuê nhà hay đa thể?

Tôi đang cố gắng xây dựng một giải pháp SaaS dựa trên web và tôi đã đi vào một con đường mà tôi không chắc chắn sử dụng nhiều hợp đồng thuê nhà hay đa thể. Tôi sẽ cố gắng mô tả những gì tôi đang cố gắng đạt được, và mỗi cách tiếp cận đều có ưu điểm và nhược điểm (theo ý kiến ​​của tôi, theo những gì tôi đọc). Vui lòng bao gồm các đề xuất của bạn trong trường hợp tôi bỏ lỡ bất cứ điều gì trong một phương pháp khác.

Ứng dụng mà tôi đang cố gắng xây dựng là, như tôi đã đề cập, một giải pháp SaaS nơi các công ty có thể tạo tài khoản của họ và mỗi tài khoản / công ty đều có người dùng, khách hàng, sản phẩm, dịch vụ ... vv. Mỗi người dùng; ai là nhân viên công ty; liên quan đến một tài khoản / công ty sẽ chỉ có quyền truy cập vào khách hàng, sản phẩm và dịch vụ của công ty. Các công ty có thể có số lượng khách hàng, sản phẩm và dịch vụ không giới hạn, do đó mỗi công ty nên có trung tâm dữ liệu riêng.

Vì vậy, tôi đã quyết định tạo một cơ sở dữ liệu dùng chung (lưu tất cả thông tin đăng nhập của người dùng cho mục đích đăng nhập) và nhiều lược đồ chia sẻ cơ sở dữ liệu (cơ sở dữ liệu cho mỗi tài khoản / công ty). Về cơ bản, thuê nhà nhiều .

Sau đó, một số người đề nghị sử dụng Multi Instance thay vào đó, trong đó mỗi công ty sẽ có phiên bản ứng dụng riêng (ví dụ mã, thư viện, cơ sở dữ liệu, khung ... vv) hoàn toàn tách biệt với các công ty khác. Điều này nghe có vẻ tốt hơn vì tôi không phải chăm sóc thêm một lớp mà tôi cần đảm bảo rằng mỗi người dùng của người thuê chỉ có quyền truy cập vào dữ liệu của công ty họ. Tôi nghĩ thật tốt khi đề cập rằng tôi phụ thuộc vào Docker để đạt được phương pháp này (tôi chưa bao giờ sử dụng nó trước đây), nhưng tôi nghĩ rằng nó thiếu các tính năng (nhiều hơn về những điều này sau) tôi sẽ cần trong tương lai (ít nhất là tôi đã không 't tìm thấy chúng với một chút tìm kiếm).

Tuy nhiên, mỗi cách tiếp cận đều có ưu và nhược điểm, vì vậy tôi không thể đưa ra quyết định nên tiếp cận với phương pháp nào. Đây là một danh sách, nhưng trần trụi với tôi vì tôi thiếu kiến ​​thức về cả hai, vì vậy có thể có điều gì đó mà tôi không biết hoặc giải pháp cho một vấn đề tôi không tìm thấy trên web: [Mỗi cách tiếp cận đều có một danh sách theo thứ tự mà tôi đã theo dõi từng người một so sánh]

Nhiều người thuê nhà :

1. Máy chủ / phần cứng được chia sẻ, mã được chia sẻ và cơ sở dữ liệu đa.
2. Nó dễ dàng hơn để mở rộng chức năng của mã và sửa chữa lỗi (mã chia sẻ).
3. Việc mở rộng phần cứng trở nên khó khăn hơn (có thể sử dụng dịch vụ đám mây) hoặc di chuyển cơ sở dữ liệu của người thuê nhà sang hệ thống khác mà không thực hiện thay đổi mã.
4. Quan trọng nhất, như tôi đã đề cập trước đây, tôi cần thêm một lớp bổ sung vào hệ thống để đảm bảo rằng người dùng thực sự thuộc về công ty của họ và không truy cập thông tin của công ty khác.

Đa trường hợp :

1. Máy chủ / phần cứng được chia sẻ hoặc không chia sẻ, mã cho mỗi phiên bản và cơ sở dữ liệu cho mỗi phiên bản.
2. Việc mở rộng chức năng hoặc sửa lỗi khó hơn (Tôi không chắc có cách nào để thực hiện điều đó trong Docker hay không, nơi bạn có thể thêm chức năng / tính năng vào một phiên bản hoặc bộ chứa Docker và triển khai nó cho người khác).
3. Nó dễ dàng hơn để di chuyển toàn bộ dụ đến một máy chủ khác nhau / phần cứng.
4. Ví dụ, tôi không cần phải quan tâm đến lớp đó vì mỗi thể hiện sẽ có cơ sở dữ liệu riêng.

Tất cả các ưu điểm và nhược điểm đều dư thừa trong trường hợp tôi muốn làm bất cứ điều gì thủ công (như tạo một ví dụ cho mỗi người thuê một cách thủ công), và đó là lý do tại sao tôi nghi ngờ giải pháp Docker, trừ khi có cách giải quyết, đó có thể là chính lý do của câu hỏi. Tôi sẽ đánh giá cao nếu bạn trả lời câu hỏi với các tham chiếu đến các giải pháp và tại sao bạn nghĩ cách tiếp cận này tốt hơn phương pháp khác.

Trong trường hợp điều đó có ích (có thể?), Chúng tôi đang sử dụng Laravel làm khung chính cho back-end (tất cả RESTly).

Tôi đang tự hỏi chính mình cùng một câu hỏi tại thời điểm này.

Tôi đang nghiêng về giải pháp thuê nhà đơn lẻ nhiều trường hợp nhưng chưa đưa ra quyết định dứt khoát. Hãy để tôi chia sẻ một vài suy nghĩ của tôi:

Ưu điểm lịch sử chính của kiến ​​trúc nhiều bên thuê là sử dụng tốt hơn các tài nguyên cơ sở hạ tầng , bằng cách tương tác (hệ điều hành đơn, cơ sở dữ liệu đơn, lớp ứng dụng duy nhất) và chiếm dụng tốt hơn các tài nguyên đã nói (khi một người dùng ở xa người khác có thể sử dụng cùng một tài nguyên) .

Nó cũng đơn giản hóa rất nhiều vòng đời phần mềm : bạn triển khai các phiên bản mới cho bạn một phiên bản, tất cả các khách hàng được cập nhật cùng một lúc.

Tuy nhiên, có vẻ như những tiến bộ gần đây trong công nghệ đám mây tạo ra lớp lợi thế đầu tiên phần lớn có sẵn trong kiến ​​trúc đa thể hiện (ví dụ cho mỗi khách hàng) (tôi đang nghĩ cụ thể về một nền tảng như Jelastic ở đây nhưng tôi chắc chắn có những thứ khác cung cấp các tính năng tương tự):

• PaaS dựa trên container
• Cung cấp và tự động nhân rộng các container (container đàn hồi)

Vì vậy, quản lý phần cứng và nền tảng không còn là mối quan tâm của nhà cung cấp Phần mềm nữa. Các tài nguyên được tương tác hiệu quả hơn nhiều so với trước đây ở cấp độ cơ sở hạ tầng và bản đồ .

Vẫn sẽ có một chi phí chung cho nhiều trường hợp (một số ứng dụng và phần mềm trung gian sẽ được chạy N lần thay vì chỉ một lần), nhưng thấp hơn nhiều so với khi sử dụng một máy (ảo) riêng biệt cho mỗi phiên bản. Cơ sở dữ liệu có thể được chia sẻ bằng mọi cách (một lược đồ cho mỗi phiên bản, một số lược đồ cho máy chủ DB)

Cũng thế :

• Có thể tự động hóa việc tạo các phiên bản mới thông qua API PaaS
• Có thể tự động hóa việc triển khai các phiên bản mới thông qua API PaaS, với thời gian chết bằng không (cần thực hiện một số công việc)
• Mở rộng quy mô luôn luôn ra, không bao giờ lên. Chúng tôi không phải lo lắng về các bộ dữ liệu khổng lồ ở cấp độ cá thể.

Tất nhiên, chúng tôi sẽ cần một số loại dịch vụ trung tâm tự động quản lý tất cả điều này (ví dụ: tạo ví dụ khi người dùng mới tạo tài khoản). Điều này cũng sẽ quản lý các vấn đề thanh toán và cấp phép, tương tác giữa các trường hợp, v.v. Dịch vụ trung tâm này có thể khá phức tạp và khó phát triển, nhưng điều tốt là chúng tôi không phải triển khai trước (bây giờ chúng tôi không có nhiều tài nguyên) trong khi nhiều người thuê sẽ cần phải được đưa vào ứng dụng ngay từ đầu.

Điều này mang lại cho tôi những lợi thế cuối cùng của việc phát triển một người thuê nhà cho một dự án khởi nghiệp ở giai đoạn rất sớm (tiền đầu tư):

• Phiên bản tương tự (hoặc gần giống) của ứng dụng có thể được triển khai tại chỗ như một thiết bị ảo hoặc bộ chứa docker hoặc thậm chí trên máy do khách hàng quản lý (một số công ty vẫn miễn cưỡng đối với Cloud và nó có thể giúp khởi động giai đoạn đầu không đẩy ra những người chấp nhận sớm quan trọng)
• Nhanh hơn để đưa sản phẩm ra với nguồn lực hạn chế (lớp ứng dụng và lược đồ cơ sở dữ liệu khá ít phức tạp), có thể lấy sản phẩm một đối tượng thuê đơn lẻ "câm" ra trước (MVP) cho những người dùng đầu tiên và để hiển thị giá trị kinh doanh của ứng dụng cho các nhà đầu tư tiềm năng và thêm tất cả tự động hóa đám mây sau này
• Có thể được coi là một đối số bán hàng cho khách hàng lo lắng về bảo mật dữ liệu: dữ liệu được đóng gói tốt hơn vì mỗi khách hàng có lược đồ riêng hoặc thậm chí cơ sở dữ liệu. Ít rủi ro hơn về "sự cố tràn"

NB: Tôi rõ ràng đang nghĩ ở đây về một ứng dụng kinh doanh nơi khách hàng sẽ là doanh nghiệp (mỗi người có nhiều người dùng riêng lẻ) chứ không phải cá nhân. Sẽ không có ý nghĩa gì khi chạy một phiên bản riêng của một ứng dụng cho từng người dùng riêng lẻ (hoặc sẽ như vậy?)

Cũng có thể hỗ trợ cả hai tùy chọn (nhóm người thuê trong nhiều trường hợp).

Tôi ủng hộ nguyên nhân đa trường hợp của sự cô lập tự nhiên. Mỗi phiên bản của khách hàng chạy trong các quy trình riêng của nó và dữ liệu của nó được tách biệt trong cơ sở dữ liệu của chính nó. Bạn có thể nâng cấp phiên bản lên phiên bản mới trên cơ sở mỗi khách hàng / trường hợp khi muốn.

Hệ thống dựa trên người thuê đi kèm với một rủi ro bảo mật thông tin. Chỉ cần xem xét việc dễ dàng quên một mệnh đề "WHERE tenantId = x". Lý do chính để sử dụng một hệ thống có khả năng của người thuê sẽ là hiệu suất, các quy trình có trọng lượng lớn, bằng cách chia sẻ một quy trình mà bạn có khả năng có thể nhận được nhiều hơn từ một máy. Điều này đúng hơn tôi nghĩ trong một thế giới 32 bit thì ngày nay trên các máy 64 bit có nhiều RAM hơn.

Một hệ thống đa thể có lẽ sẽ cần thêm một chút công cụ để tạo và cấu hình môi trường như cơ sở dữ liệu và các trường hợp ứng dụng web. Người ta có thể lập luận rằng bạn cần phải có kịch bản này dù sao cho việc triển khai cá thể của bạn. Làm điều này có các đặc quyền khác cũng giống như khả năng thiết lập môi trường phát triển và thử nghiệm

Tôi sẽ loại bỏ các khả năng của người thuê cho đến khi bạn có thể tạo ra một trường hợp cho nó (chi phí kỹ thuật so với tiền tiết kiệm trên cơ sở hạ tầng (phần cứng) thông qua quá trình chia sẻ quy trình).