station d

Công nghệ Cloud tuy chỉ mới phổ biến ở Việt Nam những năm gần đây, tuy nhiên tại Singapore, cloud đã được triển khai rộng rãi. Hãy cùng tìm hiểu về bối cảnh, kinh nghiệm và lợi ích mà cloud, infrastructure as code mang lại qua buổi trò chuyện cùng anh Tuấn Lê – Cloud SA @Orient Software.

Về khách mời

Anh Tuấn Lê, hiện là Cloud Solution Architect của Orient Software – một công ty chuyên về Software Development.
Công việc Cloud SA của anh hiểu cơ bản là Solution Architect trên cloud, những thứ mà anh thiết kế hoàn toàn xoay quanh cloud.
Anh Tuấn có hơn năm kinh nghiệm 10 năm làm về Solution Consultant và hiện tại vừa chuyển qua in-house ở Orient Software được 1 năm..

Ginco đã sử dụng và tối ưu Cloud Functions như thế nào

Business Intelligence (BI) là gì? Trò chuyện cùng chuyên gia Trường Phan để hiểu hơn về vai trò của BI trong hệ thống

Cung & Cầu trong mảng Cloud Consulting Việt Nam ra sao?

Hiện tại, những công ty đang sử dụng cloud ngày càng xuất hiện nhiều, đặc biệt là ở những startup. Còn những công ty chuyên làm về Cloud Consulting thì cũng đã có những cái tên, chẳng hạn như FSoft, tuy nhiên họ làm ở thị trường Nhật là chủ yếu.

Trong quá trình làm Solution Consultant tại Việt Nam và cả ở Singapore, có một điều mình nhận ra khi làm consulting đó là mình không thực sự hiểu về chuyên môn của khách hàng, không hiểu về Software Development Knowledge của khách hàng. Vì vậy khi tư vấn, mình không thực sự sâu sát với những thứ đang diễn ra với khách hàng, cả khách hàng Việt lẫn Sing.

Theo anh, khi xây dựng hệ thống Cloud sẽ có những thách thức nào?

Đầu tiên, Cloud khác hẳn so với on-premise ở chỗ tất cả những dịch vụ sử dụng (theo các best practices) đều đã có sẵn. Tuy nhiên, thách thức lớn nhất là làm sao để biết tất cả những dịch vụ ấy, mỗi cái dùng để làm gì. Riêng như AWS khoảng 200 services và features sử dụng là khoảng 7000 cái. Bạn buộc phải biết tất cả những thứ đó để làm gì, mức độ làm như thế nào, có thể thay thế bằng alternative solutions (giải pháp thay thế) nào khác hay không hay là bản thân nó dùng đủ tốt rồi.

Trong nhiều trường hợp, bạn buộc phải tuân theo best practices để research và test xem hiện tại nó đã adapt theo nhu cầu của mình ra làm sao. Nghĩa là nhu cầu của bạn phải có trước và bạn phải tự định nghĩa nhu cầu ấy thật chi tiết về mặt kỹ thuật. Tóm lại là bạn sẽ không phải tự hỏi là mình đang cần cụ thể một giải pháp gì, mà câu hỏi sẽ là setup như vậy để làm việc gì.

Còn để làm được việc đó trên Cloud sẽ có nhiều phương án:

Hoặc là phương án server-based
Hoặc là cái phương án trên một service có sẵn
Hoặc là một phương án third-party nào đó

Mình sẽ chọn những phương án này sau. Vấn đề trước mắt là làm sao để biết được cái nào đang có sẵn để lựa chọn. Bởi vì một trong những ưu điểm của Cloud là khả năng tích hợp và đưa bất kỳ phương án nào rất là nhanh, và gọn, và biết nó tồn tại để bạn có thể sử dụng.

Ví dụ như với một số dịch vụ về AI/Maching Learning, như Speech to Text chẳng hạn. Thì trong phần lớn trường hợp là bạn sẽ phải tự build platform bằng một số workload bên dưới để training trước, tìm nguồn để mà train và rồi sau đó là chạy. Còn khi đã đưa lên cloud rồi thì top 3 Cloud như AWS, Google Cloud Platform và Azure luôn có sẵn rất nhiều dịch vụ. Bạn chỉ cần đẩy dữ liệu qua API xuống, họ đã train sẵn, mình chỉ việc dùng thôi.

Nói một cách đơn giản, mình chỉ việc đẩy API xuống vào file audio đó và mình sẽ có file text ra. Vấn đề ở chỗ là dùng service đó nó có chất lượng đủ tốt với mình hay chưa, và một số cái liên quan, chẳng hạn như chi phí đã phù hợp với dự án của mình hay chưa.

Xem thêm: “Cơ hội phát triển sự nghiệp AI với các ngành nghề là tương đồng” – Bảo Đại, AI Researcher tại Knorex

Vậy nếu mình muốn extract audio tiếng Việt hoặc ngôn ngữ khác ít resource thì mình làm như thế nào ạ?

Thực ra, đây là một vấn đề liên quan đến PM (Project Management) nhiều hơn là liên quan đến cloud.

Khi mình đã có những dịch vụ có sẵn và biết được mỗi dịch vụ đó nó đáp ứng như thế nào. Ví dụ Transcribe của AWS đang có sẵn tiếng Anh rồi. Trong trường hợp đó thực sự là công việc của PM; có nghĩa là mình phải test xem phương án nào đáp ứng được đúng nhu cầu của mình hơn là cố pushing là một cái cloud nào đang phù hợp với khách hàng, đó không phải là vấn đề.

Anh có thể chia sẻ một vài service của AWS mà anh hay sử dụng được không ạ?

Trước đây, khi làm cho những công ty Cloud Consultant bên Singapore thì gần như khách hàng dùng cái nào, mình sẽ research trước để tư vấn (như về server-based, serverless, Transcribe,…), và mình phải làm rất nhiều về network và security bởi vì hầu như tất cả các doanh nghiệp ở đây họ đều quan tâm đến network và security. Như về việc nó sẽ chuyển đổi kết nối giữa hệ thống mạng của công ty và cloud như thế nào; Còn security thì nó liên quan đến tiền bạc và một số quy tắc phải tuân thủ rồi.

Hiện tại, khi đã chuyển qua công ty software thì mọi thứ lại đi sâu hơn rất nhiều vào các service hỗ trợ dev.

Ví dụ như:

Về S3 cách sử dụng, resign URL trên đó, làm sao để lấy file và upload một cách bảo mật, hệ thống CDN CloudFront
Một số service thuần riêng của dev thì có một số service về message là SQS, rồi một số service gửi email, notification và có cả Elasticsearch… rất nhiều.

Hầu như đều xoay quanh các service của dev sẽ chạy như thế nào, trên cloud có sẵn sẽ làm những thứ đó.

Những trải nghiệm “nhớ đời” cùng các Service của Cloud?

Trước đây, phần lớn khách hàng có xu hướng sử dụng server-based. Họ xem EC2 instance như là một cloud server bình thường. Họ tự cài đặt trên đó và họ tận dụng cái phần của cloud (môi trường) vì đơn giản nó liên quan và có sẵn để chạy.

Về kinh nghiệm sử dụng, khi anh làm in-house tại Orient Software thì mọi thứ đang dần chuyển dịch rất nhiều từ phía cloud server sẽ bắt đầu chuyển sang container, Docker như thế nào… nên bắt buộc phải sử dụng những dịch vụ Container as Service như là EKS, ECS trên AWS. Hiện nay, với định hướng mà container đang theo là serverless, mọi thứ đều chạy trên service hết. Không có quản lý trên server nào cả. Thế thì, một cái kinh nghiệm là gần như bạn phải có một cái nhìn tổng thể rằng là những thứ mình đang làm, khi chuyển đổi sang serverless thì nó sẽ như thế nào. Có một số thứ sẽ cần lưu ý, ví dụ như không bị attached quá nhiều vô một phiên bản software nhất định nào đó chẳng hạn. Ví dụ cố gắng là dùng những standard protocol hoặc standard configuration thì việc chuyển đổi sẽ tốt hơn rất nhiều.

Cái thứ 2 là phải luôn đảm bảo một số tiêu chuẩn, chẳng hạn như hệ thống của bạn phải sẵn sàng có thể được clone, được scale bằng cách nào đấy. Thì những thứ liên quan đến log hay một số thông tin, một số loại storage khác là bắt buộc bạn phải tách riêng độc lập ra để có thể sẵn sàng cho việc sử dụng những dịch vụ ngoài chứ không chỉ dồn hết vào một node. Một số kinh nghiệm cơ bản mình chia sẻ là như thế.

Có một “bài học” mà anh muốn chia sẻ với mọi người khi làm việc với AWS không?

Khi còn làm bên Singapore, lúc ấy là làm dịch vụ billing – nghĩa là bên công ty anh sẽ trả tiền cho AWS và sẽ charge bill khách hàng như kiểu hóa đơn đỏ. Lúc ấy là anh làm cho một khách hàng thôi, là một MNC ở Singapore, Ấn Độ và Hàn Quốc.

Câu chuyện là vào thời điểm ấy, khi bên mình chưa kịp làm dịch vụ security và optimization hay bất kỳ thứ gì cho họ thì đã xuất hiện một sự cố. Đó là một user của họ để upload lên S3, nhưng trong cấu hình, user này là để full quyền admin. Thông tin đăng nhập của user đó (access key & secret key) bị lộ và đột nhiên cuối tháng cái bill bình thường của họ bị tăng thêm $10.000 và họ không biết làm sao cả.

Thì lúc này, client họ phải request partner gần nhất thôi là công ty billing – công ty anh. Sau khi research một vòng, coi cái log audit lại thì phát hiện ra họ bị lộ vấn đề như vậy. Lúc này có 2 vấn đề cần xử lý, một là phải khắc phục sự cố ngay. Người mà đã lấy access key & secret key đó, họ cũng hiểu về AWS và họ làm một việc là đến cái region ở châu u và tạo một đống EC2 để mining Bitcoin. Họ làm như vậy gần như là một động tác rửa tiền một cách hoàn hảo, bởi vì không thể nào truy vết được ai làm gì, như thế nào, ở đâu hết. Nó sẽ chuyển thẳng vô phần chi phí của phía khách hàng bị hack account và bill thì vẫn do công ty bên này chịu.

Bởi vì cách thiết kế của AWS là khi mình view một cái region này thì không thấy thông tin của region khác cho nên khi khách hàng chỉ coi 3 cái region ở châu Á thôi là sẽ không biết bất kỳ việc gì xảy ra ở region ở châu Âu cả.

Sau đó việc cuối cùng cần làm là xử lý lại, gọi là “xây chuồng lại sau khi đã mất bò”, thì nó đơn giản. Đó là bắt đầu apply một số security alert về tiền bạc, đảm bảo giới hạn quyền thấp nhất cho tất cả các function, các user, đặt cảnh báo về chuyện tiền bạc rồi có mở thêm cái audit log của tất cả các nơi. Nhưng đây vẫn là chuyện đơn giản. Việc phức tạp hơn rất nhiều đó là phải giải trình với AWS là tôi đã bị hack và để AWS trả lại số tiền đó. Nghĩa là mình vẫn phải trả số tiền đó trước và sau khi đã giải trình xong, AWS sẽ claim lại bởi việc này là vẫn có thể đáp ứng được. Nhưng có nhiều trường hợp nó phức tạp ở chỗ là bạn phải giải trình toàn bộ sự việc bằng văn bản kỹ thuật.

Vậy cuối cùng nó có thành công không ạ?

Và cuối cùng, case này đã thành công. Bởi vì AWS, anh đã từng làm việc nhiều với họ, họ không làm việc quá máy móc nguyên tắc mà chỉ đơn giản dựa trên kết quả cuối cùng. Nếu thật sự bạn thể hiện được case đó là khách hàng bị hack và partner hỗ trợ khách hàng show tất cả mọi thứ bằng evidence (chứng cứ) đầy đủ là được. Nó chỉ khó ở chỗ là làm đúng thủ tục và chứng minh qua những chứng cứ đó.

Có những công nghệ thú vị nào mà anh muốn chia sẻ cùng mọi người không?

Đó là Infrastructure as Code & Terraform.

Có một điều thú vị anh nhận thấy khi mới qua Singapore làm việc, đó là ngoại trừ các công ty MNC – họ đem toàn bộ adaptation có sẵn từ phía headquarter về Singapore làm, thì những người bên đó đã biết quá rành về Cloud và mọi thứ bên đó diễn ra như thế nào rồi. Còn đối với những công ty ở Singapore mà họ chỉ mới bắt đầu muốn sử dụng Cloud, thì mức độ adaptation ở những công ty này tại Singapore không hơn Việt Nam là mấy, nếu có hơn thì cũng chỉ hơn về số lượng, như các dự án làm rất nhiều thôi, còn về mức độ hiểu và sẵn sàng adapt Cloud thì giống hệt với VN thôi.

Câu chuyện là như lúc trước, sau khi làm optimization và propose, là một số activity mà công ty có thể làm cho khách hàng như: Professional Service thì sẽ charge thêm manday qua đó trên cái web console click kéo thả, cấu hình gì đấy để tương ứng, và sau đó screenshot lại các bước lại gửi cho khách hàng; Việc này cũng có thể tạm gọi là nhanh hơn so với cách cũ trên on-premise: phải cài đặt server, đưa server đến. Tuy nhiên, từ khi anh sử dụng Infrastructure as Code (IaC) thì các dự án thường từ mất vài ngày để thực hiện, nay nó chỉ mất vài tiếng để code Infrastructure, vài phút để plan và chạy.

IaC đem lại sự hiệu quả khủng khiếp, ít nhất là đối với Cloud Consulting. Ngoài ra còn rất nhiều lợi ích khác như nó sẽ không bị phụ thuộc vào 1 người. Ví dụ: anh có 2 người, làm 2 dự án cùng lúc. Nhưng khi chạy được code như vậy, 10 dự án hay 100 dự án nó vẫn chạy được.

Thứ hai nữa là về thời gian, nó sẽ nhanh hơn, một số ví dụ như về version, versioning như có làm sai thì việc rollback lại là việc cực kỳ dễ dàng.

Tiếp đến là về Document.

Document cũng đơn giản vì không cần screenshot các thao tác. Bởi thực ra, việc screenshot thao tác chỉ là để chứng minh tôi đã thực hiện đầy đủ dự án, chỉ vậy thôi. Còn việc document hóa toàn bộ những cái phần code và giải trình lại nó dễ hơn rất nhiều.

Sau đó khi làm việc tiếp một dự án của chính phủ Singapore, một điều thú vị là do đặc trưng địa lý của Singapore, toàn bộ cloud đã có ở Singapore, chính phủ Singapore khuyến khích sử dụng cloud rất mạnh. Toàn bộ các dự án, ít nhất là từ năm đó đều phải sử dụng cloud hết, không một dự án nào được triển khai ở các center. Vào thời điểm đó, có một điều khá buồn cười là trước những năm khoảng 2010s muốn sử dụng workload trên cloud phải giải trình bằng văn bản, nhưng hiện tại thì ngược lại, nếu còn triển khai trên data center là phải phải trình ngược lại.

Để hỗ trợ cho toàn bộ mọi thứ diễn ra suôn sẻ, Singapore đã hình thành một công ty GovTech. Họ hỗ trợ và audit các dự án để đưa lên cloud. Lúc ấy, Singapore đưa ra 1 framework là Government Commercial Cloud Infrastructure (GCCI), nghĩa toàn bộ tất cả các dự án chính phủ phải tuân theo framework đó. Nó bao gồm 1 bộ tiêu chuẩn gồm: các cách thiết kế bắt buộc phải có, các cách làm việc quy chuẩn phải có, đảm bảo traffic không bị lộ, dữ liệu không bị thất thoát, toàn bộ traffic phải được kiểm soát….

Lúc này, Singapore bắt buộc áp dụng một quy trình làm việc cực kỳ mới đó là toàn bộ các dự án triển khai phải bằng Infrastructure as Code. Tức là việc triển khai (cài đặt, cắm, gõ…) sẽ không còn do con người can thiệp nữa mà gần như là đưa vào khoảng code => bên phía GovTech review => nếu được thì mới triển khai. Nhờ vậy, mọi thứ trở nên nhanh chóng nhờ Infrastructure as Code. Bởi gần như, có những thứ chỉ IaC mới có thể làm được như vậy.

Còn nếu làm theo cách bình thường, tức là thuê một team vào làm, rồi phải cử một người review, xem ai đang làm gì thì nó sẽ tốn thời gian rất nhiều và khó rollback được khi có sự cố xảy ra.

Trước khi làm cùng Cloud cần biết những gì?

Mới đây, anh có phỏng vấn một số bạn cho vị trí DevOps thì thấy có những suy nghĩ của nhiều bạn chưa hợp lí lắm khi sử dụng dịch vụ Cloud là như thế này: Các bạn vẫn còn tìm cách manual quá nhiều.

Đối với cloud thì gần như mọi thứ, nó đã có API sẵn và có thể programming được, thì điều này đồng nghĩa việc chúng ta có thể automation được mọi thứ. Đặc biệt, điều cơ bản nhất là bạn phải biết cách để cài đặt package cho phía server chạy được.

Bạn sẽ phải viết mọi thứ thành bash script, đẩy vào user data của EC2 để sau đó tự cài đặt mọi thứ đó lên và chỉ việc review xem nó chạy có đúng hay không. Điều này sẽ hạn chế tối đa việc phải remote SSH vô từng server để cài đặt. Tất nhiên có những cái tool đã làm điều đó rất tốt rồi, giống như Ansible. Nhưng với cái cách thiết kế của cloud, bạn sẽ không cần phải làm những cái manual đó nữa. Cho dù manual đó đã tự động hóa bằng một configuration management rồi nhưng điều đó cũng không cần thiết.

Top 20 chứng chỉ IT được săn đón nhất trong ngành CNTT

Tiếp theo cần hiểu một xu hướng compute nó thay đổi và nâng dần. Trong cách thiết kế ngay từ đầu, cần phải gỡ từng workload ra. Ví dụ như storage, service này là phải tách riêng ra như thế nào. Điều này cũng giống như triết lý của monolithic chuyển sang microservice nhưng mà nó ở cơ chế rộng hơn, mở rộng hơn cho toàn bộ system. Ví dụ như là log có thể ghi được rất nhiều và cũng có thể ghi thêm một hệ thống khác, như cloud chẳng hạn.

Bên cạnh đó, có một điều bạn cần biết thêm nữa, đó là security và monitor trên cloud rất là rẻ. Nó rẻ bởi vì với một quy mô nhất định, nếu triển khai on-premise cho performance chừng đó về monitor và lâu chừng đó thì phải đâu đó $x00,000 cho một cái dự án như vậy, cho vài năm. Trong khi ở trên cloud chỉ tốn nhiều nhất vài chục đô đến vài trăm đô/tháng cho toàn bộ với quy mô chừng đó. Thì đó cực kỳ hiệu quả và nên tận dụng càng sớm càng tốt, càng nhiều càng tốt. Bởi vì nó available nhưng không có nghĩa nó turn on by default. Mình phải biết và phải turn on nó trước, để khi mà có sự cố, mình có thể coi lại log, coi lại bất cứ thứ gì để kiểm tra được ngay.

Về công ty Orient Software Development

Công ty Orient Software Development đã thành lập được 15 năm và hoạt động chuyên về Software Development trên web và mobile.
Thành công nhất là về các mảng AI, Machine Learning, IoT cho khách hàng, đặc biệt ở Châu Âu và Mỹ. Hiện tại anh Tuấn cùng công ty đang thực hiện một dự án cùng chính phủ Singapore.
Orient Software đang mở rộng mảng Cloud Consultant tại Việt Nam, cụ thể là AWS. Chuyên hỗ trợ khách hàng về Cloud Transformation Journey: từ hệ thống On-premise đang sử dụng như thế nào, lên cloud sẽ chuyển đổi ra làm sao, tối ưu trên cloud, quan trọng nhất là về Cost Optimization và Cloud Security.

Cảm ơn anh vì những chia sẻ với khán giả của Station D TV!