Trong phần 2 của loạt bài này , chúng tôi đã áp dụng các khái niệm được giới thiệu lần đầu trong phần 1 và thiết kế một phần mềm khởi động phần mềm hẹn hò trực tuyến hư cấu có tên là eTumble. Chúng tôi đã tạo ra những “tài liệu sống” cho chiến lược, thiết kế và kiến ​​trúc của mình. Mục đích của bài đăng này là tập hợp mọi thứ lại với nhau và lập kế hoạch cho cơ sở hạ tầng cần thiết để biến ý tưởng của chúng tôi thành hiện thực và đáp ứng nhu cầu mở rộng quy mô trong tương lai của chúng tôi.

Điều kiện tiên quyết để tiến về phía trước

• Bạn đã đọc phần 1 của bộ truyện
• Bạn đã quen thuộc với các khuôn khổ / phương pháp mà chúng tôi khám phá bên dưới bằng cách ít nhất xem các liên kết video được chia sẻ trong phần 1
• Bạn đã đọc phần 2 của bộ truyện

Không cần viết một dòng mã nào hay tiêu bất kỳ khoản tiền nào , các bài tập “tài liệu sống” của chúng tôi được tạo ra trong phần 2 đã tiết lộ các yêu cầu hệ thống cung cấp thông tin về nhu cầu cơ sở hạ tầng lưu trữ trong tương lai của chúng tôi:

Chúng tôi không cần phải đáp ứng tất cả các nhu cầu “ngoài” ngay lập tức, nhưng nhận thức được chúng trong khi thiết kế và xây dựng MVP của chúng tôi có thể giúp giảm thiểu việc làm lại. Hãy cùng khám phá xem thế nào nhé!

Phạm vi MVP ban đầu dựa trên bản đồ câu chuyện và OGSM

eTumble đang chuẩn bị trở thành điều quan trọng tiếp theo trong hẹn hò trực tuyến. Nhóm của chúng tôi đã dành thời gian một cách khôn ngoan để thực hiện phân tích SWOT, ghi lại kế hoạch chiến lược 3–5 năm của chúng tôi bằng Khung OGSM, trực quan hóa và ưu tiên MVP của chúng tôi bằng Sơ đồ câu chuyện, đồng thời thiết kế và ghi lại kiến ​​trúc của chúng tôi bằng các phần của phương pháp Mô hình C4.

Kế hoạch OGSM của chúng tôi đã xác định mục tiêu ban đầu là 25.000 người dùng trong năm 1 và các chiến thuật để đạt được mục tiêu của chúng tôi, chẳng hạn như chương trình giới thiệu và bản trình diễn trong khuôn viên trường đại học. Sau nhiều lần lặp lại ánh xạ câu chuyện, chúng tôi đã giải quyết được phạm vi MVP của mình — và viết nó xuống .

Nếu chúng tôi bỏ qua việc lập kế hoạch chiến lược để xác định tầm quan trọng của các chương trình khuyến mãi, chúng tôi có thể đã không lặp lại đủ trên bản đồ câu chuyện để giải quyết MVP, điều này giúp ưu tiên những gì chúng tôi xây dựng trước. Thậm chí đáng sợ hơn, chúng tôi có thể đã gọi nó là “Mike's Match Maker” (ở trên) thay vì cái tên thú vị hơn của chúng tôi, eTumble. ;-)

Việc nhanh chóng đưa MVP của chúng tôi đến tay người dùng dự định sẽ giúp chúng tôi hiểu rõ hơn về miền vấn đề và do đó ảnh hưởng đến các quyết định ở cấp độ chiến lược và ý tưởng. Đây là lý do tại sao các kế hoạch của chúng tôi được gọi là "tài liệu sống" và nên được lặp lại theo thời gian khi chúng tôi tìm hiểu.

Chọn nền tảng lưu trữ đám mây của chúng tôi

Việc chọn nhà cung cấp dịch vụ lưu trữ đám mây có thể trở thành một hoạt động chính trị hoặc tôn giáo trong bất kỳ tổ chức hoặc nhóm nào. Tôi muốn sử dụng phương pháp tiếp cận dựa trên dữ liệu cho các quyết định này và đã mô tả cách chúng tôi đã thực hiện điều đó tại một công ty trước đây trong cuộc phỏng vấn BrightTALK vào năm 2020 này.

Trong các phần trước của loạt bài này, tôi đã lảng tránh thực tế là chúng ta sẽ sử dụng Google Cloud Platform (GCP), vì vậy tôi sẽ giải thích ngắn gọn cách tiếp cận điển hình của mình.

Tôi đã sắp xếp quy trình này tại các tổ chức trước đây và một tổ chức có dòng sản phẩm với chiến lược ưu tiên thiết bị di động, vì vậy lý do tôi chọn GCP xuất phát từ kinh nghiệm trước đó và hỗ trợ hàng nghìn công ty tại DoiT. AWS Amplify là một giải pháp cạnh tranh, nhưng lại thua kém so với GCP Firebase khi sử dụng nhiều tiêu chí ở trên, đặc biệt là tính dễ sử dụng.

Bài viết này đi vào chi tiết hơn khi so sánh hai khung di động phổ biến, GCP Firebase so với AWS Amplify , nhưng nó nằm sau tường phí của Medium. Sự đồng thuận là Firebase toàn diện hơn, dễ sử dụng hơn và có thể tiết kiệm chi phí hơn.

Bất kể bạn chọn nền tảng nào, chúng tôi đã xác định các yêu cầu cả ngắn hạn và dài hạn đối với hệ thống của chúng tôi. Giả sử chúng ta đã trải qua quá trình đánh giá ở trên, chọn GCP vì nhiều lý do và bây giờ phải thiết kế cơ sở hạ tầng lưu trữ đám mây của mình.

Tự động hóa việc triển khai mã nguồn của chúng tôi

Bên cạnh con người, cốt lõi của mọi công ty khởi nghiệp phần mềm là mã nguồn của họ — văn bản có cấu trúc được chuyển đổi thành hướng dẫn mà máy tính có thể hiểu và xử lý. Để các chương trình của chúng tôi tiếp cận được đối tượng dự định của mình (giả sử không có “MVP màn ảnh khói” nào ở giai đoạn này), chúng cần được triển khai cho (các) môi trường lưu trữ đã chọn của chúng tôi.

Một trong những chiến lược của chúng tôi dành cho eTumble là đổi mới nhanh hơn những chiến lược khác. Mặc dù điều này có thể mô tả nhiều khía cạnh của quá trình khởi động phần mềm, nhưng chúng tôi sẽ tập trung vào tốc độ của nhà phát triển và tốc độ mà người dùng cuối có thể nhận ra chức năng mới (câu chuyện của người dùng). Đã có những nghiên cứu chứng minh đây là một lợi thế cạnh tranh, tuy nhiên, chúng tôi sẽ không đi sâu vào tất cả các chi tiết về DevOps và DevSecOps cũng như quy trình CI/CD trong bài viết này.

Làm thế nào điều này xảy ra có thể là sở thích cá nhân của nhóm phát triển. Nhiều nhà cung cấp dịch vụ lưu trữ mã nguồn (ví dụ: - Github.com, Gitlab.com hoặc Bitbucket.com) hiện có công cụ của riêng họ. Nhiều người cũng cung cấp webhook khi các sự kiện xảy ra kích hoạt các giải pháp của bên thứ ba. Mỗi nhà cung cấp dịch vụ lưu trữ đám mây cũng có các dịch vụ của riêng họ, chẳng hạn như Azure Dev Ops của Microsoft hoặc Cloud Build và Cloud Deploy của GCP.

Thông thường, khuyến nghị của tôi cho hầu hết các tổ chức là xem xét giải pháp của nhà cung cấp đám mây, tối thiểu là cho giai đoạn “triển khai” của quy trình xây dựng của bạn, bởi vì giải pháp này loại bỏ nhu cầu chia sẻ các khóa tài khoản dịch vụ tồn tại lâu dài (có thể bị xâm phạm) với bên thứ ba hệ thống. GCP cung cấp Liên kết nhận dạng khối lượng công việc cho phép bạn chỉ định các vai trò IAM cho giải pháp của bên thứ ba mà không cần chia sẻ khóa, đây cũng là một tùy chọn.

Cân nhắc để mở rộng quy mô trên đám mây

Để nguyên khối hay không

Hãy đối mặt với nó, hầu hết các công ty khởi nghiệp phần mềm thành công trên toàn cầu ngày nay đều bắt đầu dưới dạng ứng dụng nguyên khối 3 tầng. Không có gì sai với đá nguyên khối ở giai đoạn đầu. Việc ghép nối giảm thiểu nhiều sự phức tạp về kỹ thuật và vì “Cấu trúc liên kết nhóm” ngụ ý rằng những quyết định này thường liên quan đến tải trọng nhận thức trong nhóm của bạn . Với mục tiêu 25.000 người dùng trong năm đầu tiên của chúng tôi và trọng tâm là khuôn viên trường đại học, đây là một thiết kế hoàn toàn có thể chấp nhận được đối với những gì nằm trong phạm vi MVP của chúng tôi.

Sự cố thường xảy ra khi bạn bắt đầu mở rộng quy mô. Tuy nhiên, đừng sợ vì chúng tôi có thể thiết kế giải pháp “nhanh và gọn” để dễ dàng hướng tới kiến ​​trúc vi dịch vụ trong tương lai của chúng tôi.

Trong sơ đồ kiến ​​trúc Mô hình C4 của chúng tôi, chúng tôi đã xác định “Bộ điều khiển” trong chế độ xem thành phần, dành cho ứng dụng “API phụ trợ”. Ví dụ: các hàng biểu thị thông báo xuất bản tới Pub/Sub ban đầu có thể bao gồm logic vi dịch vụ trong ứng dụng API ở lớp “Mô hình” của kiến ​​trúc Model-View-Controller (MVC). Các tuyến API vẫn giữ nguyên.

Khi tính đến các dịch vụ siêu nhỏ, chúng tôi có thể chuyển chức năng “Mô hình” ra khỏi ứng dụng API thành các dịch vụ riêng biệt và giao tiếp qua HTTP/RPC hoặc nhắn tin không đồng bộ. Nếu có kế hoạch trước, bạn có thể thiết kế một lớp bao bọc cho các lệnh gọi hàm hoặc phương thức tương tác với lớp dữ liệu ban đầu và chuyển sang các lệnh gọi từ xa trong tương lai với các thay đổi mã tối thiểu.

Tuy nhiên, nếu bạn đã thiết kế đủ hệ thống phân tán, thay vào đó, bạn có thể chọn sử dụng kiến ​​trúc hướng sự kiện như được minh họa trong Sơ đồ vùng chứa của chúng tôi.

Đi “không có máy chủ” hoặc sử dụng vùng chứa

Ở phần đầu của loạt bài gồm 3 phần này, tôi đã nói rằng các công ty khởi nghiệp phần mềm ngày nay có lợi thế hơn những công ty khởi nghiệp phần mềm thậm chí từ 5 đến 10 năm trước, một phần là do các nhà cung cấp đám mây siêu quy mô. Các sản phẩm không có máy chủ như AWS Lambda, Google Cloud Function hay thậm chí Azure Function là một ví dụ điển hình. Các nhà phát triển có thể đẩy mã của họ tới các “thời gian chạy” này và hưởng lợi từ việc không cần bảo trì cơ sở hạ tầng và tự động mở rộng quy mô.

Mặc dù đây có vẻ là cách tiếp cận rõ ràng để khởi động MVP của bạn, nhưng hãy lưu ý đến bãi mìn kỹ thuật nợ mà bạn gieo rắc trên đường đi. Một số dịch vụ này cung cấp trình mô phỏng để bạn có thể xây dựng và thử nghiệm cục bộ, giúp giảm sự phụ thuộc và chi phí của môi trường khác.

Tôi muốn tận dụng các giải pháp serverless cho các tác vụ không đồng bộ nhỏ có mục đích đơn lẻ được kích hoạt bởi các sự kiện trong hệ thống của bạn như “tệp đã tải lên hoặc đã thay đổi” hoặc “thông báo đã xuất bản”.

Để xây dựng một API sẽ định tuyến các yêu cầu đến các phần phụ trợ khác nhau, một ứng dụng được đóng gói có thể là một lựa chọn khôn ngoan hơn. Vì tất cả các phụ thuộc được đóng gói trong hình ảnh, nên các vùng chứa đơn giản hóa quá trình phát triển và thử nghiệm cục bộ. Hầu hết các nhà cung cấp dịch vụ lưu trữ đám mây đều cung cấp giải pháp bộ chứa “không có máy chủ” như ECS trên AWS và Cloud Run hoặc App Engine Linh hoạt trên GCP.

Tôi thích tính di động của vùng chứa cho các ứng dụng phức tạp hơn và nếu bạn tuân theo các nguyên tắc của phương pháp ứng dụng 12 yếu tố , chúng cũng giảm nguy cơ trôi cấu hình len lỏi vào các môi trường khác nhau trong quy trình CI/CD của bạn.

Priyanka Vergadia tại Google cung cấp một bộ sưu tập “ghi chú phác thảo” và phần minh họa “ Tôi nên chạy công cụ của mình ở đâu ” dưới đây là một hướng dẫn hữu ích.

Tận dụng các nhóm email để mở rộng quy mô từ một đến nhiều nhóm

Giả sử chúng tôi bắt đầu với một vài người nhưng kế hoạch của chúng tôi cuối cùng yêu cầu hỗ trợ hàng chục triệu người dùng ở nhiều quốc gia. Chúng tôi chắc chắn sẽ mở rộng quy mô tổ chức của mình để bao gồm nhiều nhóm và chuyên gia (trục y và trục z của AKF Scale Cube cũng áp dụng cho tổ chức của chúng tôi).

Phương pháp hay nhất khi thiết lập Quản lý danh tính và truy cập (IAM) với nền tảng đám mây là chỉ định vai trò cho các nhóm thay vì từng người dùng. Trong một bài báo tôi đã viết cách đây vài năm về cấu trúc doanh nghiệp trên đám mây , tôi giải thích các nhóm ban đầu được đề xuất và hơn thế nữa.

các nhóm chúng tôi thành lập ở giai đoạn đầu có thể mở rộng quy mô theo tổ chức (chỉ các thành viên thay đổi theo thời gian)

Ngay cả khi công ty khởi nghiệp của chúng tôi bắt đầu với ba người, không có gì ngăn cản chúng tôi xác định các nhóm và thêm người vào một số nhóm để bắt đầu . Khi chúng tôi thuê thêm người, chúng tôi có thể dần dần giao các nhóm cho các chuyên gia.

Ở quy mô doanh nghiệp, cuối cùng bạn có thể tách các nhóm ra xa hơn theo nhu cầu và nhu cầu tải nhận thức. Bất kể bạn bắt đầu từ đâu, phương pháp hay nhất là cấp các vai trò IAM trên đám mây cho các nhóm, thay vì từng người dùng, để giúp họ dễ bảo trì hơn và giảm thiểu việc làm lại — lưu ý mẫu ở đây.

Thiết kế hệ thống phân cấp tài nguyên đám mây của bạn cho nhiều bên thuê

Danh sách kiểm tra Tham chiếu GCP bảo mật này mà tôi đã viết cách đây vài năm bao gồm một ví dụ minh họa về thiết kế thực tiễn tốt nhất được khuyến nghị. Vì chúng tôi đang thiết kế kiến ​​trúc đám mây cho MVP của mình, nên có thể có một số công việc “bỏ đi” trong giai đoạn đầu nhưng tôi vẫn đề xuất một cấu trúc tương tự khi thiết lập bất kỳ hệ thống phân cấp tài nguyên đám mây nào.

Khi tổ chức mở rộng quy mô, tiến tới các phiên bản mới hơn của sản phẩm được minh họa trong bản đồ câu chuyện người dùng của chúng tôi, chúng tôi có thể chuyển sang quản trị mạng tập trung, quản lý cụm Kubernetes và cấu trúc nhóm nhiều bên thuê. Điều này thường gây khó khăn cho các công ty khởi nghiệp phần mềm khi họ đạt đến những điểm uốn được mô tả trong phần 1 của loạt bài này.

có thể có một số công việc "vứt đi" trong giai đoạn đầu

GCP có một tài liệu tham khảo tuyệt vời mô tả cách thiết lập nhiều bên thuê doanh nghiệp với nhiều chi tiết hơn. Dưới đây là minh họa về cơ sở hạ tầng đám mây eTumble có thể trông như thế nào trong tương lai khi chúng tôi đạt được các mục tiêu Y2 và Y3 của mình (bỏ qua chế độ xem tài nguyên để đảm bảo tính ngắn gọn của bài viết).

Điểm mấu chốt ở đây là lưu ý rằng các dự án thư mục dịch vụ chia sẻ ban đầu không bao giờ thay đổi và các nhóm chúng tôi thành lập ở giai đoạn đầu có thể mở rộng theo tổ chức (chỉ các thành viên thay đổi theo thời gian). Mỗi đối tượng thuê (nhóm) duy trì các tài nguyên cụ thể của họ như cơ sở dữ liệu và bí mật trong các dự án tương ứng của họ và được tham chiếu từ các ứng dụng trong bộ chứa được triển khai tới các cụm trong không gian tên tương ứng của họ.

Các hệ thống bên ngoài (xác thực, thanh toán, email, v.v.)

Kế hoạch và thiết kế của chúng tôi cho thấy nhu cầu về các hệ thống bên ngoài như email giao dịch, thanh toán trực tuyến, và có thể cả nhận dạng và xác thực. Trong khi lựa chọn các nhà cung cấp giải pháp bên ngoài, hãy cân nhắc những điều sau:

• nhiều môi trường để thử nghiệm và sản xuất với xác thực riêng biệt
• duy trì và luân phiên thông tin xác thực trong kho lưu trữ bí mật được mã hóa
• khuyến khích thương mại có sẵn để được mua thông qua thị trường

Xin chúc mừng vì đã làm cho nó đến nay! Loạt bài gồm 3 phần này sẽ đưa bạn vào hành trình từ các phương pháp và khuôn khổ hữu ích, đến thiết kế khởi động phần mềm từ đầu và cuối cùng là sử dụng “tài liệu sống” để lập kế hoạch cơ sở hạ tầng đám mây cho cả giai đoạn đầu và giai đoạn sau.

• Phần 1: giới thiệu cơ sở và phương pháp luận
• Phần 2: triển khai các phương pháp với khởi động hư cấu
• Phần 3: thiết kế và mở rộng cơ sở hạ tầng đám mây

Tôi mong bạn áp dụng những nguyên tắc này và hoàn thành nơi chúng ta đã dừng lại để giúp giải quyết nỗi cô đơn trên quy mô hành tinh . ;-)

Nếu bạn cảm thấy loạt bài này sẽ hữu ích cho những người khác, xin đừng giữ bí mật. Dành cho mỗi phần một số "tình yêu" và vỗ tay, đồng thời chia sẻ với những người khác. Cảm ơn vì đã đọc!