Tại sao tôi đi học và làm sản phẩm / dịch vụ trên nền tảng Native Cloud?

Ai cũng có một câu chuyện khi bắt đầu hoặc kết thúc một điều gì đó. Tôi cũng vậy, khi bắt đầu từ làm các dự án với thiết kế lẫn quản trị truyền thống tôi cũng đã học hỏi được rất nhiều về kỹ thuật lẫn cách thức đều ok cả. Nhưng đến một ngày, tôi nhận thấy một số bất cập trong công việc tư vấn, báo giá, triển khai lẫn vận hành các hệ thống lớn (big enterprise system). Hôm nay tôi sẽ chia sẻ với các bạn câu chuyện tại sao tôi lại tập trung theo hướng chuyển đổi lên cloud cả về làm dịch vụ lẫn sản phẩm mặc dù hiện tại ở Việt Nam việc chuyển đổi cloud còn khá nhiều khó khăn về mặt tâm lý, công nghệ lẫn độ trưởng thành của doanh nghiệp để thích nghi với các tư duy mới.

Minh bạch là cách tạo dựng sự uy tín bền vững nhất

Khi mới bắt đầu sự nghiệp ở thế hệ tôi mọi người rất đề cao kỹ năng đàm phán thương lượng, và đây có lẽ là kỹ năng quan trọng ở mọi thời đại, tôi cũng đồng ý về điều này. Nhưng thực tế trải nghiệm việc đàm phán để win-win là rất khó khăn mà thường đàm phán theo hướng có lợi cho bản thân, có nhiều cuộc đàm phán mà hai bên không hiểu nhau như bán rau ngoài chợ, đạp giá vô tội vạ hay đưa giá ảo tưởng. Việc đàm phán, cụ thể là đàm phán giá là cơ sở giữa cung và cầu (bởi cuối cùng dù làm công nghệ hay làm gì cũng sẽ quay về vấn đề giá cả), nó cần có một thước đo minh bạch, văn minh hơn trong cách mua bán.

Kể chuyện của Grab, thật ra giá cả đi xe của Grab còn đắt hơn truyền thống, nhưng bản thân tôi dù ra ngoài các hãng taxi Mai Linh, Vinasun có đậu đầy ngoài đường cũng không hề bắt bởi vì trong tâm lý tôi là luôn bị đi đường vòng vừa tốn thời gian lẫn tiền bạc. Đặc biệt thời gian vài năm trở về trước đi taxi ở Hà Nội là một cực hình khi mình là người trong Sài Gòn ra đó họ phát hiện tiếng mình là ko rõ nên toàn chở lòng và chặt tiền mình. Có lần hài nhất là chở mình đi tốn hơn trăm ngàn mới nói anh ơi em ko biết đường, anh bắt xe khác và … “cho em xin tiền đi nãy giờ”. Rất bực mình và lắm lúc mình có cảm giác bị lừa. Grab ra đời theo mình thành công nhất là giải quyết câu chuyện niềm tin, tôi biết trước tôi phải trả bao nhiêu, khi tôi thấy ok thì tôi mới dùng.

Làm các dự án truyền thống cũng vậy, luôn có hai hướng chính đó là bán cho thị trường đám đông (massive hay industrial) hoặc bán cho một vài khách hàng premium (các doanh nghiệp lớn có nhu cầu về CNTT lớn). Mỗi hướng đều có pros & cons của riêng nó. Riêng mình thì hay làm cho các khách hàng doanh nghiệp lớn hơn, mình thấy với cách làm truyền thống có khá nhiều bất cập khiến lòng tin sụt giảm.

  1. Mua trần – Doanh nghiệp (DN) luôn phải mua trần, trong khi nhu cầu sử dụng cho DN ko phải lúc nào cũng ở mức cao nhất. Ví dụ khách hàng cần một hệ thống phục vụ cho 1000 người dùng, thì tất cả sizing thiết kế về phần cứng cần đạt 1000 người dùng. Sizign ở mức tối đa, nhưng vấn đề là không phải lúc nào cũng có 1000 người dùng, 1000 người dùng này là chỉ vào giờ cao điểm thôi, còn bình thường họ chỉ có 200-500 thôi chẳng hạn. Vậy DN lúc này luôn phải mua hạ tầng sẵn sàng ở mức 1000 người dùng (có thể tắt hay mở tùy vào thời điểm nhưng phần cứng luôn ở đó, rất tốn kém về facility).
  2. Nhìn mặt bán hàng – Bán đồ công nghệ mà như kiểu bán rau, thấy khách hàng giàu có nhiều tiền để tiêu hoặc … để rửa thì bán giá cao, còn chỗ khác thì bán giá rẻ. Mình ko hợp triết lý bán hàng mà kiểu ép nhau lắm.
  3. Giãn nở (Elasticity) – Cùng theo ví dụ ở trên việc giảm xuống là ko thể do đã mua theo trần 1000. Rồi giả sử vào các dịch lễ tết số lượng người dùng truy cập hệ thống tăng đột xuất lên 2000 => Không lẽ lúc này đi mua thêm phần cứng rồi lắp vào. Thề chứ, để làm cái này nhanh lắm cũng mất vài tuần với các hệ thống lớn.
  4. Luôn phải tính cua trong lỗ – Là luôn phải dự báo những thứ xảy ra trong các năm tiếp theo theo các chiều hướng ngược nhau, mà có những ngữ cảnh ko thể foreseen được hết, cứ tính, cứ mua dự phòng, rồi triển khai ko thành công thì đắp chiếu. Dự án fail rất nhiều. Nếu doanh nghiệp nào càng có tinh thần startup, càng đề cao sự innovation mà vẫn theo hướng cứng nhắc kế hoạch 5 năm, kế hoạch 10 năm thì thật là khó. Đây là quan điểm cá nhân của mình, mọi người có thể chia sẻ thêm ở phần comment.
  5. Thời gian triển khai lâu – Các dự án truyền thống thường triển khai tính bằng tháng, thậm chí tính bằng năm. Việc này thường do cả hai bên triển khai lẫn bên khách hàng. Nhưng tựu chung lại làm công nghệ nó khá là vô hình, mọi người nếu ko đủ kiến thức và kinh nghiệm sẽ đi tranh cãi một thứ chưa có trước. Một số doanh nghiệp thông minh hơn thì phải có demo, POC này nọ nhưng cũng chỉ screening một lớp nào đó thôi, dự án fail là vẫn fail.
  6. Chi phí bảo trì cao & phức tạp – Việc bảo trì nào cũng tốn kém chi phí, nhưng có một số thứ bỏ tiền ra cũng ko làm được ví dụ như hệ điều hành thì cần nâng cấp, nhưng phần mềm lại chưa hỗ trợ phiên bản mới hệ điều hành, chưa tương thích. Lắm lúc một Change Request liên quan bảo trì thôi mà tưởng chừng như 01 dự án to rồi. Nghĩ lại cũng ám ảnh.

Vậy là mình tìm một hướng đi mới nhằm xóa bỏ những hạn chế trên đảm bảo những giá trị cốt lõi sau:

  1. Pay as you Go – Xài nhiêu trả nhiêu, nếu xài chất lượng kém có thể kết thúc hợp đầu với không ràng buộc về năm tháng gì. Điều này khiến áp lực và cũng là động lực cho những nhà làm công nghệ luôn phải trau dồi sản phẩm, đứa con tinh thần của mình hướng tới khách hàng, tạo ra sự thành công của khách hàng. Khách hàng thành công thì mình mới thành công.
  2. Agility – Sự nhanh nhẹn của công nghệ chuyển mình đáp ứng yêu cầu kinh doanh. Việc giãn nở về số học không phải là giới hạn công nghệ. Ví dụ: Hiện tôi có 1000 người dùng, mai tôi cần hệ thống đáp ứng 2000 người dùng là lập tức có liền.
  3. Open – Giá cả tường minh, tích hợp dễ dàng, ổn định.
  4. Minimize Maintenance Process – Tối thiểu hóa đau đớn mỗi lần maintenance, software patching, hot fix, OS scan… tối thiểu hóa thời gian chết (downtime) hệ thống vào các khung giờ hệ thống cập nhật. Quên đi nỗi lo tương thích phần mềm, nền tảng, cập nhật mà downtime lâu, downtime ko biết khi nào hết.
  5. Win-Win – Sự thành công khách hàng sẽ là câu trả lời tốt nhất cho sức khỏe giải pháp mà chúng ta cung cấp. Bất kể giải pháp công nghệ có tốt nhưng không áp dụng thành công và hướng theo business thì sẽ bị loại trừ nếu ko có sự cải tiến sáng tạo. Do đó đây vừa là động lực, vừa là áp lực với các công ty cung cấp công nghệ trong tương lai.

Thế là mình đã quyết đinh GO với Cloud. Nhưng đây cũng không phải là điều dễ dàng gì cho lắm, ở một bài khác mình sẽ chia sẻ những thuận lợi cũng như khó khăn khi phát triển công nghệ trên cloud.

iGà.

 

 

Topics #agility #aws #azure #cloud first #elasticity #gcp #pay as you go #scalability