Scale là gì?

Introduction

Bài viết này sẽ đề cập tới một khái niệm quen thuộc nhưng dưới một góc nhìn của một startup CTO hoặc đơn giản là Product Owner, và chỉ giới hạn trong lĩnh vực Web Application.

Khi nói tới scale, có lẽ chúng ta ai cũng nghĩ ngay tới duy nhất một vấn đề: làm sao để hệ thống đáp ứng được số lượng lớn dữ liệu. Dữ liệu ở đây có thể là dữ liệu người dùng, tải băng thông, số lượng request, vâng vâng. Scale luôn là vấn đề mà mọi hệ thống đều cần phải giải quyết, có thể kể tới horizontal scale và verticle scale.

Tuy nhiên, có một loại scale mà tôi muốn đề cập trong bài viết này, và theo tôi, nó còn khó hơn là hai loại scale ở trên, đó là team scale. Hay nói cách khác, tôi thường dùng cụm từ team capacity.

Team scale và những vấn đề

Để cho dễ phân biệt, tôi gọi scale về mặt hệ thống (horizontal scale và vertical scale) là traditional scale. Scale kiểu này sẽ giải quyết vấn đề thuần về kỹ thuật.

Tương tự với traditional scale, team scale là thuật ngữ tôi dùng để ám chỉ một vấn đề: khi số lượng lẫn chất lượng team member thay đổi, hay nói đơn giản là teamwork hoặc team communication sẽ phải thay đổi ra sao để đáp ứng từ sự thay đổi về nguồn nhân lực.

Tôi tin chắc sẽ có bạn đồng ý với tôi về một quan điểm: quản lý nguồn nhân lực là bài toán khó hơn rất rất nhiều so với những vấn đề thuần về kỹ thuật.

Hãy thử nghĩ về những vấn đề này cùng nhìn lại tại sao team scale lại khó khăn và cần được suy nghĩ một cách nghiêm túc:

  • Team của bạn tốn bao nhiêu thời gian cho việc họp hành?
  • Documentation của team bạn đã đủ tốt hay chưa? Mọi thành viên có đều sử dụng document đó hay họ tự document lại theo cách của riêng mình?
  • Team member trao đổi thông tin bằng cách nào, chat, call hay cách nào khác? Bạn đã gặp vấn đề khi nhiều team member khác múi giờ làm việc từ xa hay chưa, và giải quyết vấn đề đó ra sao?
  • Như thế nào là definition of done của một đầu việc?
  • Team của bạn tốn bao nhiêu thời gian cho việc integration giữa các bên liên quan?
  • Làm sao để mọi team member cùng hiểu một vấn đề về business logic như nhau?

Còn rất nhiều câu hỏi khác thiết nghĩ tôi cũng không nên kể thêm, tóm lại chúng ta cần giải pháp cho những vấn đề chính sau đây:

  • Integration: tích hợp các bên liên quan lại với nhau, dù công việc của mỗi bên là hoàn toàn tách biệt.
  • Productivity: làm sao để cải thiện tốc độ làm việc của cả team, hay nói cách khác, fast delivery.
  • Centralized documentation: documentation là một việc tốn nhiều thời gian và công sức nhưng bù lại, nó mang lại hiệu quả lâu dài về maintenance.

Giải pháp cho Team Scale

Agile

Agile là một phương pháp quản lý dự án (Project Methodology) đang được áp dụng rộng rãi. Thiết nghĩ hầu hết chúng ta đã và đang làm cho dự án theo mô hình này. Agile giúp cải thiện một cách đáng kể năng suất làm việc của cả team thay vì mô hình như Waterfall truyền thống.

Sẽ thật là phiến diện và thiết sót nếu như tôi không đề cập tới Agile dẫu cho bài viết này lại hướng về kỹ thuật. Tuy nhiên, bất kể là vị trí gì trong quá trình phát triển web nói riêng và phần mềm nói chung, quy trình làm việc chính là một trong những yếu tố then chốt (nếu không nói là quan trọng nhất) để hoàn thành dự án.

Có thể văn hóa Á Đông một phần rất không thích sự rập khuôn và chính xác những thứ lặt vặt. Bạn có thể sẽ thấy phiền khi phải quản lý JIRA ticket, đặt tên theo đúng chuẩn, tạo GIT branch theo đúng convention, vâng vâng. Tuy nhiên chính những điều lặt vặt đơn giản đó nếu làm đúng, sẽ mang lại cho cả tập thể một quy trình làm việc cực kỳ chuyên nghiệp.

Đừng mong đợi môi trường chuyên nghiệp dành cho bạn, hãy thay đổi để trở nên chuyên nghiệp từ bây giờ, bắt đầu bằng những việc nhỏ ở trên.

GraphQL

Nếu bạn vẫn chưa biết GraphQL là gì, có thể bạn sẽ cần đọc lại một bài viết ngô nghê của tôi từ cách đây rất lâu. Bạn có thể tìm hiểu thêm về GraphQL chỉ với vài phút Google. Cũng xin nói thêm, tôi không thích nói về thuần một công nghệ nào vì công nghệ sẽ là thứ thay đổi theo thời gian. Bạn nào làm frontend developer giống tôi sẽ càng thấm thía điều này hơn.

Tuy nhiên trong tất cả các công nghệ tôi biết ở thời điểm hiện tại, GraphQL thực sự là một cuộc cách mạng và mang ý nghĩa khác biệt hoàn toàn, đặc biệt là cho Web Application. Bởi vì mặc dù GraphQL là một công nghệ thuần về kỹ thuật, nhưng nó lại giúp giải quyết vấn đề về cách làm việc, chính là thuật ngữ Team Scale mà tôi đang dùng.

Quay lại với ba vấn đề tôi nói ở mục trước, GraphQL giải quyết chúng như sau:

  • Integration giữa backend và frontend trở nên dễ dàng hơn, và quan trọng hơn là một sự tin cậy hầu như là tuyệt đối. Sẽ không bao giờ có chuyện frontend developer phải chờ đợi API từ bên backend, cũng như là cảm giác không đảm bảo khi integrate API khi mà bên frontend hoàn toàn không thể chủ động được data mình sẽ lấy những gì.
  • Productivity: việc chủ động về mặt cấu trúc dữ liệu của API còn dẫn tới việc giảm thiểu tối đa khoảng thời gian rảnh rỗi chờ đợi và kiểm tra lại dữ liệu khi integrate xong, mọi thứ có hoạt động đúng hay không. Và đây chính là đặc điểm quan trọng nhất của GraphQL khi nó giúp năng suất làm việc của cả team tăng lên rất nhiều lần.
  • Documentation: bạn sẽ không phải làm gì cả khi API documentation là tự động được sinh ra theo schema bạn quy định, không phải tốn dù chỉ một giây nào để viết API specs như khi bạn làm với Swagger.

Lúc trước, tôi luôn cảm thấy băn khoăn mỗi khi ai đó so sánh giữa GraphQL và REST. Về cơ bản, chúng không thể bị đem ra so sánh, mỗi cái đều sinh ra để giải quyết một vấn đề khác biệt. Ở thời điểm hiện tại, bạn vẫn sẽ phải dùng song song GraphQL với REST APIs. Tuy nhiên, tôi hoàn toàn có cơ sở tin rằng GraphQL chính là cốt lõi của một hệ thống Web Application theo hướng hiện đại. Hãy thôi so sánh GraphQL với REST đi, vì GraphQL là một cuộc cách mạng rồi.

DevOps

Dù bạn có biết hay không, tôi cũng cần phải khẳng định lại, DevOps là một nền văn hóa, không phải là một cá nhân có khả năng setup infrastructure hay là một bộ công cụ phục vụ cho việc đó.

Mặc dù thoạt nhìn vào, DevOps là tập hợp những con người và những công việc phức tạp thuần về kỹ thuật, nhưng ở góc nhìn khác, DevOps giúp giải quyết vấn đề về Team Scale. Chia nhỏ công việc, chuyên biệt hóa, mỗi người nên làm tốt nhất việc của mình chính là cốt lõi để giải quyết vấn đề scale.

Một trong những điểm mấu chốt khi làm việc theo hướng DevOps đó chính là nên để team DevOps tham gia vào dự án ngay từ thời điểm bao đầu. Tôi và rất nhiều người đã phải trả giá cho việc này khi mà infrastructure không thể theo kịp với tốc độ scale, lẫn traditional scale và team scale.

Quay lại ba tiêu chí ban đầu, làm việc theo hướng DevOps sẽ giúp cải thiện hai vấn đề:

  • Integration: CI/CD đã trở nên phổ biến hiện nay. Backend developers sẽ giảm tải rất nhiều thời gian về việc infrastructure bên dưới và tập trung vào business logic.
  • Productivity: automation tools không chỉ giúp quy trình làm việc của cả team trở nên mượt mà hơn, mà quan trọng hơn, là dễ tìm và xử lý lỗi.

Lời kết

Năm 2020 là một năm đầy sóng gió và cũng là một năm thú vị để chúng ta thay đổi dần cách tiếp cận đối với quy trình phát triển phần mềm, và đặc biệt là Web Application. Bài viết này còn rất nhiều thiếu sót, mong được nhận nhiều ý kiến đóng góp từ mọi người.

Cảm ơn vì đã đọc hết bài viết khô khan này.


ShinaBR2 30-11-2020

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

ShinaBR2

15 bài viết.
135 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
72 16
Đây là một vấn đề kinh điển, và có rất nhiều bài viết về nó, tuy nhiên đa phần là dịch từ bản gốc ra và sao chép lại một vài câu lệnh, và câu hỏi t...
ShinaBR2 viết hơn 3 năm trước
72 16
White
47 11
Vào một ngày đẹp trời, khi bạn nhận được yêu cầu phải thiết kế database cho một hệ thống, câu hỏi đầu tiên được đặt ra, quy trình làm ra nó sẽ cụ t...
ShinaBR2 viết hơn 3 năm trước
47 11
White
40 10
Bàn về code thối Hãy tự đặt câu hỏi cho bạn, khi bắt đầu lập trình, bạn nghĩ tới điều gì? Đi phỏng vấn Điều đầu tiên tôi muốn nói về những câu hỏ...
ShinaBR2 viết 3 năm trước
40 10
Bài viết liên quan
White
25 2
DevOps6 series NOTE: Đây là Phần 1 trong chuỗi bài viết của mình Ai nên đọc tiếp Nếu anh em là dev muốn sự nghiệp của mình lái nhẹ sang hướng k...
huskykun viết hơn 1 năm trước
25 2
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
15 bài viết.
135 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!