Biên soạn: TechFlow TechFlow

Lưu ý: Bài viết này được bao gồm trong chủ đề TechFlow TechFlow "Ghi chú về khóa học khởi nghiệp YC bằng tiếng Trung" (được cập nhật hàng ngày, bài viết này là bài viết cuối cùng trong sê-ri.), dành riêng để thu thập và phân loại phiên bản tiếng Trung của khóa học YC và bài báo thứ hai mươi lăm là khóa học trực tuyến "Kinh nghiệm và hiểu biết sâu sắc về công nghệ và khởi nghiệp" của giám đốc công nghệ Amazon Werner Vogels.

trước khi gia nhập amazon

Trước khi gia nhập Amazon, tôi là một học giả đã dành 10 năm nghiên cứu khoa học tại Đại học Cornell và xây dựng các hệ thống phân tán quy mô lớn. Trước đó, tôi không phải là một nhà khoa học máy tính điển hình. Mãi đến năm 28 tuổi, anh mới thực sự quyết định quay lại trường để học tiếp. Trước đây, tôi làm việc trong lĩnh vực xạ trị tại các bệnh viện, thực hiện xạ trị cho các bệnh nhân ung thư tại Viện Ung thư Hà Lan. Một ngày nọ, tôi chợt nhận ra rằng tôi không thể chịu đựng được cái chết của những người xung quanh mình, vì vậy tôi quyết định làm một việc không liên quan gì đến nó. Khoa học máy tính dường như là một lựa chọn tốt.

Đó là giữa những năm 80 và khoa học máy tính chưa phổ biến như bây giờ. Tuy nhiên, hóa ra tôi có một tài năng mà lúc đó tôi không biết. Vì vậy, tôi bắt đầu tìm hiểu sâu hơn, bởi vì đó là điều tôi thực sự quan tâm. Tôi lấy bằng Tiến sĩ, làm việc vài năm tại một cơ sở nghiên cứu ở Bồ Đào Nha, rồi được mời vào làm việc tại Cornell.

Trong thời gian ở Cornell, ngoài công việc nghiên cứu, tôi thường tham khảo ý kiến ​​của các công ty lớn như HP và những công ty khác mà tôi nghe không rõ, đồng thời tham gia nhiều hội nghị khác nhau. Một lần, Amazon mời tôi trình bày một số tài liệu mà tôi đang nghiên cứu. Lúc đầu tôi hơi ngạc nhiên và bối rối: thật sao? Tôi có cần phải làm điều này?

Trình duyệt web và cơ sở dữ liệu hồi đó phức tạp như thế nào? Tuy nhiên, khi tôi bắt đầu bắt đầu, tôi nhận ra rằng đây thực sự là một thách thức kỹ thuật rất lớn. Amazon không chỉ là một nhà bán lẻ, đó là một công ty công nghệ hoạt động trên một quy mô mà tôi chưa từng thấy trước đây và chắc chắn không ngang bằng với bất kỳ công ty nào khác mà tôi từng tư vấn. Từ góc độ nghiên cứu hệ thống phân tán, những thách thức mà họ phải đối mặt là đáng kinh ngạc.

Khi Amazon đưa ra lời mời làm việc cho tôi, tôi đã nhận lời ngay mà không do dự.

Quy mô hoạt động và dẫn đầu về công nghệ của Amazon

Tôi nghĩ rằng hầu hết các nhà nghiên cứu phân tán đã nhận ra quy mô mà các công ty lớn này cần để hoạt động và thậm chí không giới hạn ở những công ty lớn này. Cho dù là một công ty Internet hay một công ty kỹ thuật số, để thành công, nó cần phải hoạt động ở quy mô lớn.

Nhìn lại năm 2004, khi tôi gia nhập Amazon, nhiều người có thể thấy việc vận hành ở quy mô như Amazon vào thời điểm đó là tương đối dễ dàng. Nhưng điều đó không có nghĩa là bạn có thể dựa vào một vị trí hoặc cơ sở hạ tầng thiết yếu. Do đó, rất nhiều công việc đã được thực hiện trên công nghệ đám mây và các công nghệ khác để đảm bảo rằng những lợi thế mà chúng mang lại có thể được tận dụng tối đa.

Amazon đã đạt đến một quy mô nhất định vào năm 2004 chỉ bằng cách thực hiện và không có cuốn sách hay hướng dẫn nào có thể làm rõ cách xây dựng một tổ chức hoặc công ty có thể mở rộng. Vì vậy, tôi nghĩ rằng Amazon đang dẫn đầu, đi trước từ 5 đến 10 năm, xét về mặt áp dụng công nghệ, sự phát triển công nghệ và quy mô hoạt động. Điều này đặc biệt quan trọng đối với các công ty theo đuổi tốc độ tăng trưởng nhanh.

Nếu bạn muốn trở thành một công ty phát triển nhanh, bạn không thể giống như một doanh nghiệp truyền thống. Các doanh nghiệp truyền thống thường phải đối mặt với thế tiến thoái lưỡng nan của người đổi mới, trong đó một khi thứ gì đó thành công, nó sẽ trở nên rất chậm chạp.

Làm thế nào để xây dựng một công ty tiếp tục phát triển nhanh chóng là một câu chuyện hoàn toàn khác và bạn phải cân nhắc việc kinh doanh một cách cẩn thận. Ví dụ, cho dù tạo ra nợ kỹ thuật hay chịu đựng một số điều định kỳ, điều này là không khả thi trong các doanh nghiệp truyền thống, bởi vì hiệu quả là mục tiêu chính của họ.

Tại Amazon, nhanh chóng, đổi mới nhanh chóng và có một hệ thống thử nghiệm dài mới là điều quan trọng. Vì vậy, bạn sẵn sàng chịu đựng một số điều định kỳ, cho phép một số khoản nợ kỹ thuật phát sinh, miễn là bạn biết mình phải trả hết.

Vì vậy, thật khó để tìm thấy những loại thỏa hiệp mà Amazon sẵn sàng thực hiện trong các cuốn sách MBA truyền thống. Phần lớn, Amazon đã phải tự mình phát triển công nghệ, quy trình và quy trình kinh doanh. Tất nhiên, với một nhà lãnh đạo có tầm nhìn như Jeff Bezos, người thực sự hiểu tương lai sẽ ra sao và thế giới hiện đại sẽ như thế nào.

chìa khóa để tăng trưởng

Mặc dù Amazon đã đạt được thành công lớn về quy mô, nhưng chúng tôi vẫn phải đối mặt với thách thức đạt được tốc độ tăng trưởng lớn hơn. Để chuyển sang giai đoạn phát triển tiếp theo, chúng ta cần suy nghĩ và hành động chín chắn hơn.

Một ví dụ là các vấn đề về hiệu suất. Làm thế nào để đo lường hiệu suất? Chúng ta cần thực hiện các phép đo loại cơ sở hạ tầng nào? Để trở thành một công ty thực sự dựa trên dữ liệu và đưa ra các quyết định dựa trên dữ liệu, hãy bắt đầu bằng việc sở hữu dữ liệu và xây dựng văn hóa xung quanh cách đánh giá và diễn giải các phép đo đó.

Ngay cả một chút chậm trễ 1,2 giây trong thời gian tải trang cũng có thể có tác động tiêu cực đến trải nghiệm của khách hàng. Nó chỉ cho thấy rằng 50% trải nghiệm của khách hàng trở nên tồi tệ hơn và bạn cần hiểu nó tồi tệ như thế nào. Các kiểm soát như 99% hoặc 99,9% cũng trở nên quan trọng hơn từ góc độ kỹ thuật. Sau đó, bạn cần xây dựng một cơ chế có thể thực sự sử dụng 99% kỷ luật kỹ thuật và kết nối nó với các quyết định kinh doanh.

Tôi nghĩ vào năm 2004, độ tin cậy của chúng tôi khá cao. Có một số quy tắc ràng buộc chúng tôi, chẳng hạn như chúng tôi phải sử dụng trung tâm dữ liệu trong một khu vực cụ thể (SEA). Bất cứ điều gì bạn làm với các trung tâm dữ liệu SEA này đều cần được nhân rộng ở các trung tâm dữ liệu khác để nếu một trung tâm dữ liệu gặp sự cố, khách hàng sẽ không bị ảnh hưởng.

Mặc dù khách hàng có thể gặp phải sự chậm trễ nhưng chức năng sẽ không bị ảnh hưởng. Chúng tôi đã xử lý khá tốt tất cả các quy tắc này, cho đến một ngày chúng tôi quyết định ngắt kết nối một trong các trung tâm dữ liệu và xem điều gì đã xảy ra. Chỉ với một chút điều chỉnh mạng, một trung tâm dữ liệu có thể được cách ly khỏi các trung tâm khác.

Tuy nhiên, trên thực tế, tất cả những thứ trông rất đẹp mắt trên giấy tờ này lại không hoạt động hiệu quả trong thực tế như người ta vẫn nghĩ. Chúng tôi đã diễn tập trong suốt cả năm, mặc dù vẫn còn nhiều quy trình thủ công trong lần thử đầu tiên, chẳng hạn như chuyển đổi dự phòng cơ sở dữ liệu thủ công. Và khi bạn chạy đến lần chạy thứ ba hoặc thứ tư, bạn đã thực sự đạt đến mức gần như có thể tự động hóa quá trình chạy mà không cần sự can thiệp của con người. Điều này rất quan trọng để đảm bảo tính sẵn sàng cao và khả năng chịu lỗi của hệ thống.

Trong nỗ lực của mình, chúng tôi cũng tập trung phát triển phân tích dữ liệu và hiểu biết sâu sắc. Amazon có rất nhiều dữ liệu, nhưng làm thế nào để có được những thông tin chi tiết có giá trị từ đó là một thách thức. Chúng tôi tận tâm xây dựng các mô hình và công cụ phân tích dữ liệu mạnh mẽ giúp chúng tôi hiểu hành vi của khách hàng, xu hướng thị trường và cơ hội kinh doanh. Cách tiếp cận dựa trên dữ liệu này cho phép chúng tôi đưa ra quyết định tốt hơn và cung cấp các sản phẩm và dịch vụ được cá nhân hóa.

Ngoài ra, chúng tôi cũng đang nỗ lực cải thiện trải nghiệm người dùng. Chúng tôi đã nghiên cứu kỹ lưỡng nhu cầu và sở thích của người dùng trong quá trình mua sắm, đồng thời cải thiện trải nghiệm người dùng thông qua tối ưu hóa thiết kế, cải tiến giao diện và đề xuất được cá nhân hóa. Chúng tôi theo đuổi trải nghiệm mua sắm đơn giản, trực quan và liền mạch để đáp ứng mong đợi của khách hàng và giành được lòng trung thành của họ.

Vai trò thay đổi của CTO

Vai trò CTO của bạn thay đổi khi bạn trở thành nhà cung cấp công nghệ.

Tôi đã chạm vào vấn đề này trong một bài đăng trên blog. Theo tôi, một CTO có bốn loại trách nhiệm khác nhau:

• Đầu tiên là CTO cấp doanh nghiệp, người thường chịu trách nhiệm quản lý cơ sở hạ tầng, báo cáo với CIO và chịu trách nhiệm quản lý một lượng lớn cơ sở hạ tầng.
• Loại thứ hai là CTO đồng sáng lập kỹ thuật, phổ biến ở các công ty trẻ và họ có tầm nhìn kỹ thuật. Nhưng tôi nghĩ rằng có một số rủi ro trong vai trò này, bởi vì nhiều thứ khác, chẳng hạn như quản lý các nhóm kỹ sư, v.v., sẽ được đưa vào vai trò này. CTO có thể không nhất thiết phải giỏi xử lý những vấn đề này, nhưng chúng ta sẽ thảo luận chi tiết hơn về điều đó sau.
• Loại thứ ba là CTO là những người có tư tưởng lớn, họ thúc đẩy sự phát triển của đổi mới. Ví dụ, các công ty như AT&T và Lucent có CTO hoặc văn phòng CTO chuyên nghiên cứu và thử nghiệm các công nghệ thế hệ tiếp theo.
• Loại cuối cùng là CTO công nghệ đối mặt với bên ngoài, người chịu trách nhiệm tương tác kỹ thuật sâu sắc với khách hàng, hiểu cách khách hàng sử dụng sản phẩm của họ và tìm kiếm các mô hình sâu hơn, rộng hơn và các điểm đau của khách hàng. Vai trò này không chỉ tập trung vào công nghệ của riêng mình mà còn chú ý nhiều hơn đến tình hình chung.

Điều quan trọng cần lưu ý là những vai trò này tập trung vào khách hàng hơn là chỉ tập trung vào công nghệ. Điều quan trọng là mang lại phản hồi của khách hàng cho công ty và suy nghĩ về những tính năng hoặc sản phẩm mới nào cần được phát triển hoặc những quy trình nào cần được thay đổi để phục vụ khách hàng tốt hơn.

Do đó, vai trò CTO với tư cách là nhà cung cấp công nghệ hướng đến khách hàng hơn là chỉ tập trung vào bản thân công nghệ.

Văn hóa độc đáo của Amazon

Vì Amazon là công việc thực sự đầu tiên của tôi nên từ lâu tôi đã cho rằng văn hóa làm việc ở những nơi khác cũng tương tự như Amazon, nhưng thực tế không phải vậy.

Amazon có một nền văn hóa độc đáo phù hợp với một công ty đang phát triển nhanh chóng. Họ khuyến khích các nhóm càng độc lập càng tốt và cắt giảm hệ thống phân cấp và cấu trúc tổ chức. Thứ bậc dường như không tự nhiên đối với họ.

Họ muốn có các nhóm tự tổ chức và thuê những người thực sự muốn làm việc độc lập và sở hữu sản phẩm. Các doanh nghiệp trẻ đặc biệt cần điều này, không phải người theo dõi hay lập trình viên.

Amazon có một bộ nguyên tắc lãnh đạo, bao gồm 14 nguyên tắc như nỗi ám ảnh của khách hàng, quyền sở hữu và khai thác sâu, những thứ định hướng văn hóa của họ.

Tại Amazon, các cuộc phỏng vấn tuyển dụng cũng chủ yếu tập trung vào sự phù hợp với văn hóa, vì một nhân viên không phù hợp với văn hóa có thể gây ảnh hưởng rất lớn đến một nhóm nhỏ. Amazon rất tôn trọng các nhóm nhỏ, thường bao gồm từ 10 đến 12 người và mỗi thành viên đều biết nhiệm vụ của mình.

Khi doanh nghiệp phát triển, vai trò của CTO thay đổi, bắt đầu với việc chịu trách nhiệm về tất cả các vấn đề liên quan đến công nghệ và dần dần tập trung vào quản lý nhóm và đảm bảo rằng các kỹ sư có thể cung cấp công nghệ và sản phẩm cần thiết.

So với VP kỹ thuật, CTO quan tâm nhiều hơn đến các khía cạnh kỹ thuật như xây dựng công nghệ phù hợp và sử dụng các công cụ phù hợp.

Amazon đã phát triển như thế nào?

Amazon đã trải qua một loạt thay đổi trong nội bộ. Họ tạo ra các nhóm độc lập trông giống như các công ty khởi nghiệp và sở hữu các mục tiêu và chương trình đổi mới của riêng họ. Tuy nhiên, trong quá khứ, Amazon đã vi phạm các nguyên tắc kiến ​​trúc để phát triển nhanh chóng, dẫn đến cơ sở hạ tầng cơ sở dữ liệu back-end dễ hỏng và không thể phát triển được nữa.

Để giải quyết tình trạng mất hiệu quả này, họ chuyển sang kiến ​​trúc hướng dịch vụ, kiến ​​trúc này chia hệ thống thành các khối xây dựng chức năng độc lập hoặc vi dịch vụ.

Tuy nhiên, khi nhóm phát triển, mỗi dịch vụ cần quản lý cơ sở dữ liệu của riêng mình, dẫn đến tăng cường giao tiếp nhưng ít đổi mới hơn.

Để cải thiện tình hình, họ đã tạo ra một nền tảng dịch vụ chia sẻ, sử dụng công nghệ ảo hóa và API để quản lý máy chủ. Đầu tiên, họ xây dựng các công nghệ này trong nội bộ và sau đó tung ra các sản phẩm bên ngoài, chẳng hạn như Amazon S3 và EC2, các dịch vụ giúp sức mạnh lưu trữ và điện toán có thể lập trình và mở rộng quy mô, rất tiết kiệm chi phí cho các doanh nghiệp.

Mục tiêu của Amazon là đạt được sức mạnh tính toán và lưu trữ ở quy mô Internet, đồng thời cung cấp dịch vụ cho nhiều loại hình kinh doanh khác nhau.

Con đường đổi mới

Sự đổi mới của Amazon được chia thành hai cấp độ:

• Đầu tiên là đổi mới ở cấp độ nhóm.Mỗi nhóm chịu trách nhiệm xây dựng kế hoạch đổi mới của riêng mình cho năm tới và hoàn thành các nhiệm vụ một cách độc lập, chẳng hạn như cải thiện công cụ đề xuất để giảm số lượng hàng trả lại. Họ chịu trách nhiệm tạo lộ trình, thu thập nguồn dữ liệu mới và tương tác với khách hàng theo những cách khác nhau.
• Một lớp khác là những đổi mới đòi hỏi đầu tư vốn đáng kể, chẳng hạn như Kindle và Amazon Prime. Những dự án này đòi hỏi hỗ trợ tài chính đáng kể. Amazon đã đặt ra quy tắc rằng các khoản đầu tư vốn lớn sẽ chỉ được thực hiện nếu một dự án đổi mới có tiềm năng thành công và có tác động đáng kể đến bảng cân đối kế toán của công ty.

Amazon nhận ra rằng một số quyết định được đưa ra sớm trong quá trình phát triển công nghệ là thông minh và khi mở rộng quy mô, họ phải xem xét lại kiến ​​trúc và phát triển phần mềm thích ứng với thay đổi. Điều này liên quan đến việc sử dụng nhiều kiến ​​trúc và phiên bản để xử lý các thách thức kỹ thuật như công cụ lưu trữ.

Ngoài ra, giống như các công ty khác, Amazon nhận thấy rằng ngoài việc mở rộng quy mô kỹ thuật, họ cũng cần giải quyết các yếu tố phi công nghệ như bán hàng, kiến ​​trúc giải pháp, quản lý tài khoản kỹ thuật và hỗ trợ khách hàng. Những yếu tố này đều cần thiết để xây dựng một công ty thành công.

Làm thế nào để khởi động các dịch vụ mới?

Chúng tôi mong muốn tất cả các nhóm liên hệ chặt chẽ với khách hàng, vì khoảng 95% tính năng và dịch vụ mà chúng tôi cung cấp là nhằm đáp ứng nhu cầu trực tiếp của khách hàng. Lúc đầu, các dịch vụ đầu tiên mà chúng tôi thành lập đã đáp ứng hầu hết mọi mong đợi của khách hàng, bao gồm cơ sở hạ tầng CNTT cơ bản, lưu trữ, điện toán, cơ sở dữ liệu, mạng và bảo mật.

Tuy nhiên, theo thời gian, khách hàng nảy sinh nhiều nhu cầu khác. Họ muốn khả năng phân tích, công nghệ đám mây, phát triển di động và bây giờ chuỗi khối và các công nghệ khác mà họ muốn có thể sử dụng mà không cần phải quản lý chúng. Do đó, việc giúp khách hàng xây dựng các tính năng và công cụ phù hợp trở nên rất quan trọng.

Khi chúng tôi ra mắt sản phẩm và dịch vụ mới, chúng tôi tuân theo văn hóa mạnh mẽ về khởi chạy bộ tính năng tối thiểu (MVP). Nhưng đó chỉ là điểm khởi đầu để xây dựng công nghệ bạn cần để xây dựng doanh nghiệp của mình. Chúng tôi không thể giao một thứ gì đó dễ vỡ, chúng tôi cần đảm bảo rằng nó ổn định và đáng tin cậy. Sau đó, chúng tôi thảo luận về các yêu cầu đối với chức năng bổ sung với khách hàng.

Trong giai đoạn đầu của sản phẩm, chúng tôi không phải lúc nào cũng biết những tính năng bổ sung mà khách hàng muốn. Ví dụ: khi ra mắt DynamoDB, chúng tôi không biết khách hàng muốn có chỉ mục phụ. Chúng tôi đã không cung cấp điều đó ngay từ đầu, nhưng rõ ràng đó là điều khách hàng muốn. Chúng tôi quan sát cách khách hàng sử dụng sản phẩm bằng cách khởi chạy dịch vụ với bộ tính năng tối thiểu, lặp đi lặp lại và thêm dần dần các tính năng và dịch vụ mới.

Ví dụ: khi chúng tôi ra mắt Lambda, đó là một môi trường không có máy chủ, giúp dễ dàng phát triển, chỉ cần viết mã và triển khai lên S3 mà không cần phải suy nghĩ về những thứ khác như máy chủ. Bạn chỉ trả tiền cho những gì bạn thực sự sử dụng và không cần phải lo lắng về những thứ như thời gian nhàn rỗi.

Cách này làm thay đổi quá trình phát triển, chúng ta có thể quan sát cách khách hàng sử dụng sản phẩm. Họ nhanh chóng bắt đầu lặp lại với môi trường gỡ lỗi giống tia X và sử dụng các hàm bậc thang để xây dựng các ứng dụng phức tạp hơn. Chúng tôi hiểu nhu cầu của khách hàng bằng cách quan sát thói quen sử dụng của họ, chẳng hạn như trong DynamoDB, chúng tôi nhận ra rằng các chỉ mục phụ quan trọng đối với khách hàng hơn là trung tâm dữ liệu thứ cấp.

Về cơ bản, khách hàng xác định lại lộ trình của chúng tôi và chúng tôi bắt đầu cung cấp các tính năng quan trọng nhất đối với họ. Đây là một phần rất quan trọng. Ngay cả khi nó trông giống MVP, chúng tôi không thể xem nó là MVP vì mọi người sẽ xây dựng doanh nghiệp của họ dựa trên nó và phụ thuộc vào nó. Do đó, một cấu trúc văn hóa khác được hình thành xung quanh sản phẩm.

Năm ngoái, chúng tôi đã phát hành 1400 tính năng và dịch vụ mới và con số đó tất nhiên sẽ tiếp tục tăng lên khi số lượng nhóm tăng lên. Chúng tôi sử dụng cùng một cấu trúc trong AWS, nơi mỗi nhóm làm việc với một phân khúc khách hàng cụ thể và xây dựng lộ trình dựa trên nhu cầu của họ. Khi số lượng dịch vụ tăng lên, lộ trình cũng vậy.

Tuy nhiên, đây là một môi trường phát triển nhanh chóng và cách xây dựng phần mềm đã thay đổi đáng kể. Nếu chúng tôi có thể quyết định cách khách hàng nên phát triển phần mềm, chúng tôi có thể vẫn đang làm theo cách chúng tôi đã làm cách đây 5 hay 10 năm. Thay vào đó, chúng tôi cần các cách để phát triển phần mềm bắt đầu từ năm 2020 hoặc 2025 bằng cách hợp tác chặt chẽ với khách hàng và để họ thúc đẩy động cơ đổi mới của chúng tôi.

Vì vậy, thay vì đưa ra quyết định thay cho khách hàng, chúng tôi cần hợp tác chặt chẽ với họ và để họ thúc đẩy động cơ đổi mới của chúng tôi. Chúng ta cần quan sát chặt chẽ cách khách hàng sử dụng sản phẩm của mình và liên tục lặp lại cũng như cải thiện dựa trên phản hồi của họ.

Nhìn chung, Amazon Web Services (AWS) áp dụng hai cấp độ là cấp độ nhóm và đầu tư vốn vào đổi mới. Bằng cách hợp tác chặt chẽ với khách hàng để hiểu nhu cầu và quan sát thói quen sử dụng của họ, AWS có thể cung cấp các tính năng và dịch vụ đáp ứng nhu cầu của khách hàng. Đồng thời, AWS cũng đầu tư nhiều vốn vào nghiên cứu và phát triển cũng như ra mắt các sản phẩm, dịch vụ và chức năng mới để đáp ứng nhu cầu thay đổi của thị trường.

Cách tiếp cận sáng tạo này cho phép AWS duy trì mối quan hệ chặt chẽ với khách hàng để đảm bảo rằng họ có thể cung cấp các giải pháp ổn định và đáng tin cậy, đáp ứng mong đợi của khách hàng. Thông qua chiến lược phát hành dựa trên bộ chức năng tối thiểu và lặp lại liên tục, AWS có thể nhanh chóng đáp ứng nhu cầu của khách hàng và tiếp tục cung cấp các chức năng và dịch vụ nâng cao hơn.

Con đường đổi mới của Amazon là một quá trình cải tiến và phát triển không ngừng, luôn lấy khách hàng làm trung tâm. Thông qua sự hiểu biết sâu sắc về nhu cầu của khách hàng, quan sát thói quen sử dụng của khách hàng và không ngừng đầu tư vào nghiên cứu và phát triển, AWS không ngừng thúc đẩy sự tiến bộ của công nghệ và kinh doanh, đồng thời cung cấp cho khách hàng các giải pháp điện toán đám mây ưu việt.

Xây dựng sản phẩm hướng đến khách hàng

Chúng tôi có mặt ở khắp mọi nơi, cho dù bắt đầu với khách hàng hay bên trong Amazon. Là một công ty công nghệ, chúng tôi rất tập trung vào việc phát triển những gì thực sự quan trọng đối với khách hàng của mình. Mặc dù chúng tôi là một công ty công nghệ nặng, nhưng kỹ sư và kỹ sư cũng chấp nhận rủi ro.

Chúng tôi tập trung vào sản phẩm, không chỉ công nghệ. Chúng tôi muốn biết những gì chúng tôi có thể làm cho khách hàng của chúng tôi. Chúng tôi cam kết xây dựng công nghệ tuyệt vời, nhưng đó không phải là điều duy nhất thúc đẩy hành động của chúng tôi. Điều chúng tôi quan tâm là giải quyết vấn đề của khách hàng.

Để đảm bảo chúng tôi tiếp tục tập trung vào khách hàng của mình, chúng tôi sử dụng một quy trình gọi là làm việc ngược. Đầu tiên, chúng tôi viết một thông cáo báo chí mô tả rõ ràng và chính xác những gì chúng tôi sẽ xây dựng. Sau đó, chúng tôi chuẩn bị một tài liệu với 20 câu hỏi thường gặp và trả lời chúng bằng ngôn ngữ dễ hiểu và đơn giản. Trong những trường hợp phức tạp hơn, chúng tôi có thể cần phải sửa đổi lặp đi lặp lại hai tài liệu này cho đến khi chúng tôi hoàn toàn hiểu rõ về những gì chúng tôi đang cố gắng xây dựng.

Tiếp theo, chúng tôi viết tài liệu trải nghiệm người dùng (UX) mô tả chi tiết cách khách hàng sử dụng sản phẩm của chúng tôi và cách họ tương tác với sản phẩm. Chúng tôi cũng viết hướng dẫn sử dụng, bảng thuật ngữ và các tài liệu liên quan khác.

Cuối cùng, chúng tôi kết thúc với một bộ bốn tài liệu mô tả chính xác những gì chúng tôi sẽ làm.

Với tư cách là Amazon, chúng tôi luôn tuân theo nguyên tắc này: chúng tôi sẽ không bị tính phí nhiều hơn những gì chúng tôi đã hứa. Chúng tôi không ngẫu nhiên thêm chức năng của phiên bản thứ hai vào phiên bản đầu tiên. Chúng tôi tập trung vào việc xây dựng các tính năng mà chúng tôi cam kết và chỉ có thế. Cách tiếp cận này cung cấp một cấu trúc mạnh mẽ để suy nghĩ về nhu cầu của khách hàng, trải nghiệm sản phẩm và công nghệ.

Tại hội nghị của Amazon, chúng tôi không sử dụng slide hay bài phát biểu. Chúng tôi có một tài liệu gọi là bản ghi nhớ dài sáu trang mà mọi người sẽ đọc thầm 30 phút trước khi cuộc họp bắt đầu. Bản ghi nhớ này rất quan trọng vì nó đảm bảo rằng mọi người đều hiểu rõ những gì chúng ta đang thảo luận.

Viết một câu chuyện rất khó, vì vậy chúng tôi khuyến khích cộng tác và phản hồi. Chúng tôi sửa đổi và tinh chỉnh bản ghi nhớ này nhiều lần cho đến khi chúng tôi mô tả rõ ràng một tính năng, sản phẩm hoặc lĩnh vực kinh doanh. Sau 30 phút đọc, mọi người trong phòng đều hiểu ý nhau, điều này góp phần tạo nên một cuộc thảo luận chất lượng cao.

Cùng nhau, chúng tôi có một nền văn hóa và quy trình độc đáo để đảm bảo chúng tôi luôn tập trung vào việc giải quyết các vấn đề của khách hàng và cung cấp các sản phẩm và dịch vụ đặc biệt.

công nghệ container

Ngày càng có nhiều công ty bỏ qua công nghệ container, đặc biệt là khi theo đuổi một môi trường microservice hơn. Một trong những lý do tại sao công nghệ container trở nên phổ biến là nó có thể dễ dàng nhận ra việc mở rộng lên và xuống của các thành phần, điều này phù hợp với khái niệm về microservice. Nhiều người đang bắt đầu phá vỡ các vùng chứa khỏi giai đoạn nguyên khối để phát triển, đặc biệt là xung quanh các môi trường không có máy chủ.

Tuy nhiên, đã có một số vấn đề xảy ra trước khi sử dụng công nghệ thùng chứa, đặc biệt là trước khi Fargate được chuyển giao. Bạn cần quản lý nhiều vùng chứa đang chạy trong nhiều vùng khả dụng và bạn cần ánh xạ chúng tới các máy ảo. Vì vậy, mặc dù các vùng chứa là một lựa chọn phát triển tuyệt vời, nhưng vẫn cần phải thực hiện nhiều công việc để chạy và quản lý chúng. Để đơn giản hóa quá trình này, chúng tôi cung cấp một giải pháp có tên là Fargate, giải pháp này về cơ bản sẽ loại bỏ tất cả quyền quản lý của máy ảo nằm bên dưới và chỉ cần đặt vùng chứa vào đó và nó sẽ chạy.

Trong tương lai, tôi nghĩ rằng sẽ ngày càng có nhiều công cụ, nền tảng hỗ trợ và cơ sở hạ tầng được phát triển xung quanh khả năng xây dựng các môi trường phi máy chủ phức tạp hơn. Tích hợp tốt hơn với các dịch vụ khác sẽ là một trong những hướng phát triển.

* TechFlow Lưu ý: Fargate là một dịch vụ điện toán được cung cấp bởi Amazon Web Services (AWS), là một công cụ điện toán không có máy chủ. Fargate giúp các nhà phát triển quản lý và triển khai các ứng dụng trong vùng chứa dễ dàng hơn mà không cần quan tâm đến cơ sở hạ tầng và máy chủ bên dưới.

Công nghệ bộ chứa là một công nghệ ảo hóa cho phép triển khai nhanh chóng và tính khả chuyển của các ứng dụng bằng cách đóng gói các ứng dụng và phần phụ thuộc của chúng vào các bộ chứa di động, độc lập. Công nghệ vùng chứa sử dụng một công cụ vùng chứa (chẳng hạn như Docker) để tạo, quản lý và chạy các vùng chứa, cho phép các ứng dụng chạy một cách nhất quán trong các môi trường điện toán khác nhau mà không phải lo lắng về sự khác biệt trong cơ sở hạ tầng bên dưới. Công nghệ container hóa được sử dụng rộng rãi trong phát triển và triển khai ứng dụng hiện đại, mang lại tính linh hoạt, khả năng mở rộng và tính di động cao hơn.

bảo vệ khách hàng

Tuy nhiên, tôi nghĩ vấn đề bảo mật sẽ được chú trọng. Trong 5 năm tới, mọi người nên đặt vấn đề bảo mật lên hàng đầu. Dù là CEO, CTO hay kỹ sư, tất cả chúng ta đều cần nhận thức về bảo mật và đóng vai trò của kỹ sư bảo mật. Chúng tôi, với tư cách là các nhà công nghệ và lãnh đạo doanh nghiệp kỹ thuật số, nên cảm thấy xấu hổ và phẫn nộ trước những vụ vi phạm dữ liệu lớn xảy ra hàng tuần trong vài năm qua. Bảo vệ dữ liệu của khách hàng là trách nhiệm của chúng tôi vì không bảo vệ khách hàng thì không có doanh nghiệp.

Chúng tôi cần bắt đầu suy nghĩ về cách bảo vệ dữ liệu chúng tôi thu thập từ khách hàng của mình, cho dù đó là dịch vụ cho thuê ô tô hay dịch vụ tiêu dùng khác. Bảo mật cần phải là một phần của mặc định, chẳng hạn như kích hoạt các sự kiện bảo mật trong quy trình tích hợp liên tục và triển khai liên tục, đảm bảo rằng các thư viện nguồn mở mới được xem xét và đánh giá khi chúng được thêm vào.

Bản thân quy trình phát triển cũng cần được bảo mật và được trang bị nhiều công cụ tự động khác nhau để kiểm tra lỗ hổng. Đặc biệt là trong các lĩnh vực chăm sóc sức khỏe và tài chính, có nhiều quy định và yêu cầu pháp lý cần được tuân thủ.

Trong 5 năm tới, tôi hy vọng tất cả chúng ta sẽ nhận thức rõ hơn về các vấn đề bảo mật và ưu tiên hàng đầu cho việc bảo vệ khách hàng của mình. Tại Amazon, bảo vệ khách hàng của chúng tôi sẽ luôn là lĩnh vực đầu tư số một của chúng tôi, cho dù về trí tuệ hay vốn tài chính.

Những sai lầm phổ biến mà các công ty khởi nghiệp mắc phải với AWS

Đầu tiên, đối với những người có kinh nghiệm về trung tâm dữ liệu truyền thống, lần đầu tiên sử dụng AWS có thể dẫn đến sự thiếu tự tin. Mặc dù AWS có những lợi thế về tính linh hoạt và tính khả dụng, nhưng chúng tôi không thể phát huy hết tiềm năng của nó nếu không sử dụng các dịch vụ cấp cao hơn như bảo mật, phân tích dữ liệu và tính di động, đặc biệt là trong các dự án phát triển quy mô lớn theo đuổi khía cạnh độ tin cậy cao.

Thứ hai, điều quan trọng là phải xác định loại hình và mục tiêu của công ty. Có hai phong cách công ty riêng biệt: các công ty phát triển nhanh, có lượng khách hàng lớn, ít tập trung vào doanh thu hơn và đầu tư mạnh để mở rộng nhanh chóng và có khả năng bị mua lại; và các công ty bền vững, Tìm cách xây dựng một doanh nghiệp lâu dài và không chỉ tập trung vào mua lại.

Hai loại công ty này sử dụng AWS rất khác nhau. Đối với các công ty theo đuổi tốc độ tăng trưởng nhanh, họ có thể yên tâm hơn khi sử dụng năng lực và dịch vụ do AWS cung cấp, vì họ không cần phải lo lắng quá nhiều về chi phí. Đối với các công ty theo đuổi sự phát triển bền vững, họ cần xây dựng một kiến ​​trúc khác, chú ý hơn đến việc kiểm soát chi phí và đảm bảo rằng có mối quan hệ rõ ràng giữa chi phí và việc thu hút khách hàng.

Đối với các nhà sáng lập startup, Jeff Bezos thường phân biệt giữa lính đánh thuê và nhà truyền giáo. Một lính đánh thuê dấn thân vào một công ty khởi nghiệp vì tiền, trong khi một nhà truyền giáo làm điều đó vì tình yêu với sản phẩm. Cả hai đều là những cách hiệu quả để bắt đầu kinh doanh, nhưng hỗ trợ kỹ thuật và kiến ​​trúc kỹ thuật được xây dựng sẽ khác nhau.

Vì vậy, hãy tìm hiểu loại hình công ty của bạn và chọn kiến ​​trúc và hỗ trợ công nghệ phù hợp.