Tại sao các engineer lại lo xanh mặt khi nghe tới scaling?

Nếu bạn là một CEO hoặc làm trong kinh doanh, khi nhắc tới việc “Scaling” bạn sẽ nghĩ rằng “Thật là tuyệt khi công ty có thể tăng qui mô làm việc của mình”

Còn nếu bạn là dev backend, thì khi nghe sếp nhắc tới “Scaling” là bạn sẽ muốn hét lên “Ôi thánh thần ơi! Liệu Platform của mình chịu nổi không?”

Là một CTO, scaling luôn là thứ khiến tôi điên đầu nhất. Nhớ lại hồi trước khi còn làm ở công ty cũ, sếp thông báo rằng công ty sẽ được featured trên Shark Tank, mọi người đều ăn mừng còn tôi thì sợ xám mặt luôn. Với hơn triệu lượt người dùng sẽ truy cập vào platform, ngay trong cùng một lúc đủ khiến mọi thứ hỗn loạn rồi. Đã thế đây lại là cơ hội duy nhất, chỉ có thể thành công.

Nguyên nhân chính khiến cho việc scaling cực kì áp lực là bởi vì nó không nhất quán: hệ thống của bạn có thể trông như hoạt động tốt chỉ mới một phút trước đó thôi nhưng với một lượng số người dùng tăng tiếp đó ngay lập tức khiến cho nó bị sập. Đã thế, bạn cũng không thể nói với CEO rằng ta phải giảm số lượng người dùng lại trừ khi bạn muốn được cho nghỉ việc. Ngoài ra, để giải quyết vấn đề về scaling còn khó khăn hơn việc gỡ bug rất nhiều lần, bởi bạn chỉ có thể copy toàn bộ production environment, cực kì tốn kém, hoặc là chạy performance test cho production vốn làm ảnh hưởng tiêu cực lên trải nghiệm của người dùng.

Một trong những lỗi mà các startup mắc phải là ra quyết định quá sớm khi mà bạn còn trong giai đoạn prototype như làm việc với outsourced developer nhằm tiết kiệm tiền. Và nếu bạn chọn sai database hoặc hosting platform, nó có thể tốn tới vài năm công sức chỉ để cải thiện và sửa chữa.

Nhiều người lầm tưởng rằng sử dụng các hosting platforms như AWS sẽ giúp giải quyết vấn đề scaling và chỉ cần nâng cấp phần cứng thôi. Tuy nhiên, AWS thực chất chỉ là một phần của quá trình và nó chỉ giúp việc scaling trở nên đơn giản hơn. Ngay cả full-service platforms như Heroku, Firebase, và Lambda cũng chật vật trong việc giải quyết vấn đề scaling. Mặt khác, qui mô càng lớn thì tiền tốn càng nhiều.

Điều đáng sợ nhất khi nói về scaling là tình trạng outage liên quan đến scaling thường diễn ra vào thời điểm then chốt như thời điểm ra mắt tầm cỡ, thời điểm đẩy Marketing… Và thường là khi nó đã xảy ra thì bạn chỉ có thể giảm thiểu thiệt hại bởi dù các developer làm việc ngày đêm thì bản fix chỉ xuất hiện sau một thời gian. Mà nếu có thì chắc là chỉ khi bạn giàu nứt vách và mua những phần cứng khủng để giải quyết một cách nửa vời.

Vì thế khi backend dev nói với bạn rằng cần thêm thời gian để hoàn thiện thì hãy nghe lời họ. Có thể nó khiến việc tung ra tính năng mới bị chậm cũng như phải bỏ đi một vài thứ nhưng thế thì còn đỡ hơn là khi sản phẩm tung ra thị trường và thất bại một cách ê chề.

Nguồn: topdev.vn via hackernoon