Khải Trần: tư duy ngắn hạn - tư duy dài hạn qua câu chuyện xây kho dữ liệu trên mây

Lời tòa soạn: một bài khác của anh Khải Trần gửi đăng.

Tôi nghĩ đằng sau tư duy của Amazon và Snowflake là hai chiến lược kinh doanh rất khác nhau. Để hiểu rõ hơn về hai chiến lược kinh doanh này, mời mọi người xem bài Strategy Letter I: Ben and Jerry’s vs. Amazon của Joel Spolsky. Nhắc đến Joel chắc ít người biết, nhưng chắc ai cũng biết StackOverflow. Joel là founder và CEO của StackOverflow. Ông ấy còn là một trong những kỹ sư đầu tiên tạo ra Microsoft Excel.

Tôi thích đọc blog của ổng, còn mua cả sách về đọc. Hồi xưa lúc ở Việt Nam và bây giờ cũng vậy, tôi ước có cơ hội được làm việc với ông Joel. Sau này khi mở công ty riêng, tôi sẽ làm theo mô hình của Joel: chỉ tuyển người giỏi nhất và đối xử với họ và khách hàng thật tốt. Thực tập sinh phỏng vấn với công ty của Joel được cho đi máy bay business class, ở khách sạn 5 sao, có phòng làm việc riêng với đầy đủ trang thiết bị tốt nhất và đương nhiên là trả lương hậu hĩnh.

Nhân anh Khải nhắc đến Google Cloud, tôi cũng muốn chia sẻ đôi chút. Google chậm hơn Amazon vì nhận định sai lầm của giới lãnh đạo rằng cloud là cuộc chiến về giá. Họ nghĩ rằng cloud của Amazon chỉ gói gọn trong S3 và EC2 thôi, chứ chẳng có gì khác hết. Cách đây 10 năm, tôi cũng đã nghĩ như vậy (xem bài này là cloud computing -- hồi xưa mình không biết gì mà phán cứ như đúng rồi).

Mãi gần đây giới lãnh đạo Google mới nhận ra sai lầm. Các bố các mẹ mở miệng ra là tầm nhìn, là chiến lược, nhưng thật ra chẳng mấy ai dự đoán được trào lưu và xu hướng phát triển của thế giới. Google nổi tiếng ra quyết định bằng dữ liệu, nhưng khi không có dữ liệu thì cũng phải đoán bừa hoặc làm theo đối thủ.

Cái hay của Google là văn hóa sửa lỗi, chứ không đổ lỗi. Sai thì cùng nhau làm lại cho đúng, chứ không quy trách nhiệm cá nhân. Với sự đầu tư lớn, lợi thế về AI và developer productivity cùng tiềm năng cực lớn của thị trường, tôi có nhiều kỳ vọng cloud computing sẽ thay thế quảng cáo, trở thành đầu tàu kéo công ty tăng trưởng.

---

Đây là hai cách tư duy trái ngược nhau trong việc xây dựng hệ thống cloud data warehouse của AWS Redshift, team cũ của tôi, và Snowflake, startup đình đám nhất về database, hiện đang được định giá 3.5 tỉ USD (mới tăng từ 1.5 tỉ từ vòng gọi vốn 9 tháng trước đây). Tôi thấy cả hai đều rất thành công, nhưng các bạn thử đoán trước xem ai ngắn hạn, ai dài hạn rồi kiểm tra ở phần dưới xem đúng không nhé.

Trước tiên là hiểu qua các khái niệm cơ bản đã.

Kho dữ liệu (data warehouse)

Các hệ thống cơ sở dữ liệu thường được phân thành hai loại: một là loại để tương tác hàng ngày với khác hàng, thao tác viên, thực hiện các giao dịch, hai là loại dùng để tổng hợp, phân tích dự liệu. Trong khi loại một chỉ yêu cầu các tính toán đơn giản nhưng cần nhanh gọn và xử lý được nhiều thao tác cùng lúc thì loại hai không cần xử lý nhiều thao tác nhưng các thao tác thường yêu cầu các tính toán phức tạp trên một lượng dữ liệu lớn. Kho dự liệu là hệ thống thuộc loại thứ hai.

Điện toán đám mây (cloud computing)

Khái niệm này chắc nghe nhiều đến phát chán rồi nhỉ? Tạm quên chuyện kéo mây đi, khi nói đến đến cloud, bạn chỉ cần nhớ hai từ này là đủ: rẻ và tiện. Cả hai đặc tính này đều đến từ một đặc tính chung là economies of scale: cái gì làm càng lớn, càng nhiều thì càng rẻ, càng tiện lợi.

Để hiểu về ưu điểm của cloud thì người ta hay so sánh với quá trình sản xuất và sử dụng điện. Bây giờ thử hình dung để có điện thắp sáng, xem tivi, chạy tủ lạnh... trong nhà thì bạn có hai lựa chọn: một là mua một cái máy phát về nhà rồi tự vận hành và sản xuất điện, hai là bạn chỉ cần nối dây điện nhà mình với mạng lưới điện có sẵn, được sản xuất từ một nhà máy phát điện khổng lồ nào đó. Cách nào rẻ và tiện hơn thì khỏi phải bàn. Trong chuyện tính toán thì việc tự mua máy chủ, làm trung tâm dữ liệu là cách một, còn dùng cloud là cách hai. Đơn giản vậy thôi.

Bây giờ tôi muốn nói về vòng xoáy về quan hệ giữa quy mô, giá cả, và các tính năng khi cung cấp các dịch vụ cloud. Khi quy mô càng lớn thì chi phí vận hành và chi phí cho việc nghiên cứu và phát triển các tính năng mới trên một đơn vị tính toán sẽ giảm theo. Giá thành giảm và nhiều tính năng mới sẽ kéo theo nhiều người dùng hơn, công ty thu được nhiều lợi nhuận hơn và họ dùng tiền đó để tiếp tục tăng quy mô và các tính năng. Vì tiềm năng của thị trường rất lớn, còn rất xa mới đến mức bão hoà nên các công ty cung cấp dịch vụ cloud phồng lên nhanh chóng, tăng trưởng cho cloud liên tục 50-100% một năm là chuyện bình thường. (mây to như thế thì khó kéo lắm đấy nhé!)

Miếng bánh béo bở như vậy ai mà chả muốn, nhưng để có thể nhảy được vào vòng xoáy này thì cần hai yếu tố: một là phải nhảy vào đủ sớm, hai là phải có đủ tiềm lực cả về tài chính lẫn hạ tầng tính toán. Thiếu một trong hai là không đủ sức mà cạnh tranh. Như Rackspace là một công ty cung cấp dịch vụ hạ tầng cloud từ khá sớm, nhưng sau không đủ sức mà đua với các đại gia nên không thể phát triển được. Facebook thì hạ tầng tính toán và tiềm lực tài chính bây giờ đều rất mạnh, nhưng tiếc là đã quá chậm chân rồi.

Theo xu hướng hiện tại thì cuối cùng chỉ còn lại thế chân vạc giữa ba công ty:

• Amazon: Người tiên phong về cloud, có ưu thế của người đi trước, xoáy được vài vòng rồi đối thủ mới nhảy vào. Thê nên họ là market leader, chiếm phần lớn của miếng bánh.
• Microsoft: Chậm chân hơn Amazon một chút, nhưng có ưu thế về kinh nghiệm làm việc với các khách hàng doanh nghiệp.
• Google: Vừa chậm lại vừa thiếu kinh nghiệm làm việc với khách hàng doanh nghiệp, nhưng Google có hạ tầng tính toán cực tốt.

Tại sao lại cần data warehouse trên cloud

Các ưu điểm của cloud so với tự làm (gọi là on premise) được thể hiện rất rõ nét qua việc xây kho dữ liệu. Trước đây, để có được một kho dữ liệu thì doanh nghiệp phải chi rất nhiều tiền: chi phi cố định cho việc mua phần cứng, bản quyền phần mềm, sau đó là chi phí cho việc vận hành và bảo trì. Đây là thứ đồ xa xỉ mà chỉ các doanh nghiệp lớn mới đủ tiền chơi. Nhưng cloud đã thay đổi luật chơi: không cần chi phí cố định, không cần lo việc vận hành và bảo trì, dùng bao nhiêu trả bấy nhiêu.

Vì thế thời khởi thuỷ của cloud đầu những năm 2010, nhiều chuyên gia về cơ sở dữ liệu đã tìm cách xây dựng hệ thống kho dữ liệu trên mây. Có hai cách tiếp cận điển hình sau đây.

Cách tiếp cận của Amazon Redshift

Họ muốn là người đưa ra dịch vụ kho dữ liệu trên mây đầu tiên (người của Amazon vẫn tự hào với khẩu hiệu “We pioneer” - chúng tôi là những người đi đầu). Mà để xây được cái lõi cho kho dữ liệu - hệ thống cơ sở dữ liệu tính toán song song, thì cần mất rất nhiều thời gian, ít cũng phải 3-5 năm. Vì thế cách họ là trả một ít tiền cho một startup làm về hệ thống cơ sở dự liệu tính toán song song để lấy bản quyền sử dụng mã nguồn, rồi phát triển thêm phần dịch vụ triển khai trên mây, thế là họ có dịch vụ kho dữ liệu trên mây đầu tiên.

Đây là một lựa chọn rất khôn ngoan để trở thành người đi đầu. Và Redshift đã trở thành dịch vụ phát triển nhanh nhất trong các dịch vụ của AWS trong một thời gian tương đối dài. Và cũng cần lưu ý khi AWS bán dich vụ Redshift, họ chỉ thu tiền từ việc thuê các máy ảo EC2 tạo thành Redshift cluster chứ không thu thêm chút tiền nào về công sức viết phần mềm trên đó. Điều đó có nghĩa là bất cứ một công ty nào khác làm điều tương tự như thế và chạy trên AWS thì không bao giờ có lãi, dù có bỏ không công sức.

Thế nhưng do phần lõi là phần xây dựng theo kiến trúc cũ, không hợp với môi trường cloud khi phần tính toán và phần lưu trữ bị gắn chặt với nhau trong cùng một server, dẫn đến hai hệ quả sau:

• Lưu trữ dữ liệu trên EC2 đắt đỏ hơn lưu trữ ở dịch vụ lưu trữ S3 rất nhiều. Vì vậy nếu kho dữ liệu bạn có rất nhiều dữ liệu nhưng lại ít khi truy nhập thì sẽ lãng phí khá nhiều tiền khi lưu tất cả trên Redshift cluster.
• Hệ thống không thể tự động “co dãn” nhanh chóng. Ví dụ như có thời điểm bạn cần tính toán nhiều thì mới cần nhiều máy, tính toán ít thì nên dùng ít máy để tiết kiệm chi phí.

Trong thời gian tôi còn ở Redshift cách đây hơn 2 năm thì họ bắt đầu khắc phục hai nhược điểm này. Thời gian sau thì thấy họ làm được điều số 1 khi cho phép Redshift truy nhập và tính toán trên data từ S3. Còn số 2 thì có vẻ khó làm hơn.

Cách tiếp cận của Snowflake

Snowflake được thành lập bởi các cựu binh dày dặn kinh nghiệm về cơ sở dữ liệu từ Oracle, Microsoft, và Vectorwise (một hệ thống cơ sở dữ liệu cho việc phân tích data khá thành công qua việc tận dụng tốt ưu thế của các bộ vi xử lý song song). Cách tiếp cận của họ là phải xây lại một kiến trúc mới cho hệ thống kho dữ liệu: phải tách biệt phần tính toán và phần lưu trữ. Kiến trúc này sẽ giúp cho hệ thống không bị mắc vào hai nhược điểm nêu trên: dữ liệu lưu ở S3, tính toán được thực hiện bởi EC2 và hệ thống tính toán có thể “co dãn” tuỳ ý theo số lượng máy người dùng chọn.

Snowflake là một câu chuyện thần kỳ khi họ là database unicorn startup đầu tiên (tôi không tính những sản phẩm như MongoDB là database) và có thể cạnh tranh sòng phẳng với các công ty lớn. Startup về database cực kỳ khó thành công vì phát triển một hệ thống database mới rất mất nhiều thời gian và công sức trong khi khách hàng thường ưa thích danh tiếng và sự ổn định của các công ty lớn.

• Snowflake thành lập năm 2012 và đến tháng 6/2016 thì họ mới giới thiệu sản phẩm của mình cùng với một bài báo ở SIGMOD conference.
• Thời điểm trước khi tôi đi, Redshift còn không coi Snowflake là đối thủ cạnh tranh vì doanh thu của Snowflake lúc đó chưa đến $10M, bằng một phần rất nhỏ của Redshift.
• Hiện tại Snowflake đã có doanh thu tầm $100M với 1000 khách hàng và được định giá $3.5B.
• Đã làm về database thì không thể nào thiếu được người Wisconsin, và VP Engineering hiện tại của Snowflake là cựu sinh viên của Wisconsin.