Cuộc điện thoại từ người bạn cũ
Vào một buổi sáng mùa hè tháng 4 năm 2020, tôi nhận được cuộc gọi từ một người bạn thân lâu năm tên là Trần Lâm. Sau đôi lời hỏi thăm tình hình lẫn nhau và trao đổi về dịch bệnh ‘Covid’, anh Lâm nhờ tôi tư vấn về việc nâng cấp hệ thống phần mềm doanh nghiệp của anh.
Đó là một hệ thống đã được xây dựng từ khi anh mới thành lập doanh nghiệp cách đây 15 năm. Khi đó, với tầm nhìn của một doanh nhân trẻ, anh đã đặt mục tiêu sử dụng công nghệ để phát triển kinh doanh ngay từ ban đầu. Cho đến 2010, anh đã sở hữu 1 hạ tầng nội bộ (on-premise) lên đến hàng chục server, vận hành đồng thời 7-8 dịch vụ kinh doanh cùng lúc. Song song với sự thành công về xây dựng hạ tầng công nghệ thông tin là sự thành công về kết quả kinh doanh rất tốt, anh đã phát triển doanh nghiệp đạt đến qui mô trên 500 nhân viên.
Tuy nhiên những năm gần đây anh cảm nhận tốc độ phát triển kinh doanh có phần chậm lại. Anh chia sẻ rằng không phải do dịch bệnh Covid, ngược lại còn nhiều cơ hội hơn! Vấn đề là tốc độ cập nhật và tạo mới các sản phẩm ứng dụng của anh không theo kịp với yêu cầu hay các mục tiêu của bên kinh doanh. Anh vẫn có những nhân sự tốt nhất về công nghệ tham gia vào việc phát triển ứng dụng nhưng anh không rõ tại sao kết quả không như kì vọng.
Anh kể rằng khi mỗi chỉnh sửa bổ sung đưa ra , đội ngũ kĩ thuật lại cảm thấy e ngại vì đôi khi không biết sẽ phải bắt đầu chỉnh sửa hệ thống từ đâu, liệu các chính sửa đó có ảnh hưởng, gián đoạn hệ thống đang chạy hay không? Bản thân hệ thống đã phức tạp trong khi đội ngũ thực hiện nó qua thời gian cũng không còn như ban đầu, có người đã rời đi, có người đã chuyển qua nhiệm vụ khác nên không còn nắm rõ.
Những cuộc tranh luận về tiếp tục kế thừa hay xây lại hệ thống mới ngày một nhiều hơn, để rồi vẫn là quyết định “tiếp tục kế thừa” vì guồng máy doanh nghiệp không chờ được nếu phải xây hệ thống mới. Và mỗi sự mở rộng lại tiếp tục tạo ra những mức độ phức tạp mới mà không một ai trong công ty anh có thể nắm rõ tường tận mức độ ảnh hưởng của chúng tới đâu.
Ngoài ra, anh không duy trì được sự bền vững khi kinh doanh tăng trưởng. Sự gia tăng của lưu lượng truy cập tăng dần cùng sự gia tăng số khách hàng lại dẫn tới sự quá tải cho hệ thống và xảy ra nhiều sự cố hơn thông thường. Nếu như trước đây anh chỉ cần nâng cấp server, mở rộng băng thông vv… là có thể giải quyết được vấn đề, thì bây giờ qui mô truy cập của những năm 2020 lớn hơn 5 năm trước rất nhiều, hệ thống phần mềm của anh lại chủ yếu dựa trên kiến trúc tập trung nhiều thành phần vào 1 tiến trình duy nhất (monolith) nên có nhiều khó khăn và tốn kém hơn mức cần thiết khi muốn kết hợp năng lực xử lý của nhiều server phục vụ tăng hiệu suất cho phần mềm đó.
Nghe đến đây tôi hiểu ngay vấn đề của anh. Nó nằm ở chính hệ thống công nghệ thông tin anh đang sử dụng. Có lẽ hệ thống hiện tại vốn dĩ từng là cái tên lửa kéo doanh nghiệp của anh tăng trưởng đi lên trong thời kì trước thì nay lại như một chiếc xe quá tải, mỗi sự bổ sung, tác động, thay đổi phải được tính toán phức tạp hơn mức cần thiết để đạt được những di chuyển chậm chạp.
Nó là một vấn đề quen thuộc không phải riêng doanh nghiệp của anh gặp phải. Không phải lần đầu tôi được nghe về vấn đề này. Sắp tới, anh lại có kế hoạch về bán vé 1 dịch vụ thể thao qua ứng dụng thay vì mua trực tiếp ở quầy, anh muốn nhân dịp này tìm 1 lời giải mới cho không chỉ ứng dụng đó mà cả các dịch vụ khác về sau. Xác định đây chính là 1 bài toán “Chuyển đổi số” chứ không chỉ là tư vấn về 1 tình huống khó trong nghiệp vụ hay 1 phương án kĩ thuật cụ thể thì trao đổi qua điện thoại là không đủ. Một buổi trao đổi kéo dài cả buổi sáng giữa tôi và anh tại công ty anh đã diễn ra ngay hôm sau.
Chuyển đổi số, từ lý thuyết đến thực tế
Chuyển đổi số, không phải là vấn đề chuyển dịch từ lưu trữ dữ liệu văn bản cứng, tìm kiếm, sắp xếp bằng sức lực con người lên lưu trữ thông tin trong máy chủ, cho phép tìm kiếm, sắp xếp, chỉnh sửa bằng phần mềm. Đó mới chỉ là quá trình số hoá thông tin. Rồi sau đó doanh nghiệp phát triển ra các ứng dụng, thực hiện các nghiệp vụ dựa trên các dữ liệu đã được số hoá. Đó là quá trình khai thác tài nguyên số. Hiện có nhiều doanh nghiệp đã đi được đến bước khai thác tài nguyên số, nhưng chưa phải là chuyển đổi số.
Đối với 1 doanh nghiệp đã sẵn có hệ thống số và khả năng khai thác nó rồi như doanh nghiệp anh Lâm, chuyển đổi số là việc chuyển dịch từ hệ thống thông tin sử dụng công nghệ cũ sang hệ thống thống tin sử dụng công nghệ mới để đạt được hiệu quả kinh doanh cao hơn khi mà hệ thống cũ không còn đáp ứng được các nhu cầu ở hiện tại.
Trong buổi trao đổi giữa 2 anh em tại công ty của anh, chúng tôi đã bắt đầu từ việc xác định nhiệm vụ “chuyển đổi số” mà anh cần phải quyết tâm thực hiện. Sau đó chúng tôi đi vào những vấn đề chi tiết. Thấy rằng chúng khá thú vị, rất thực tế chứ không sách vở, các doanh nghiệp khác quan tâm thì có thể dùng để tham khảo, nên tôi xin được chia sẻ thêm chi tiết dưới đây.
Tôi đã nói với anh về một số công nghệ mới có thể hay thế công nghệ anh đang dùng, như chuyển đổi kiến trúc monolith sang kiến trúc micro-service (tạm dịch là kiến trúc đa vi dịch vụ), áp dụng chiến lược scale cho các vi dịch vụ chịu tải cao, đưa hệ thống lên cloud vv…
Anh thở dài: “Những cái đó anh cũng biết rồi, được tư vấn và hiểu lợi ích rồi nhưng anh vẫn chưa thực hiện được.
Một là khả năng kiểm soát công nghệ và áp dụng vào nghiệp vụ cụ thể. Công nghệ bây giờ rộng và phức tạp hơn xưa. Đội ngũ của mình cần thời gian tìm hiểu cách làm cụ thể rồi mới làm được, trong khi các dịch vụ mới tính năng mới vẫn liên tục cần làm. Tuyển chuyên gia về chuyển đổi thì không dễ tìm, cần thông thạo từ phần mềm ở trên đến nền tảng, hạ tầng ở dưới, thành thạo về DevOps, Cloud… nói chung là 3 đầu 6 tay, mình tìm mãi chưa ưng được ai Châu ạ.
Ngoài ra, biết làm công nghệ hiện đại là 1 chuyện, thông hiểu nghiệp vụ – cấu trúc hệ thống hiện tại và các vấn đề phức tạp bên trong của nó để phân tách, chuyển đổi lại là chuyện khác.
Hai là vấn đề thời gian chuyển đổi. 1- 2 tháng thì được, chứ 6 tháng, 1 năm thì không ổn. Mình không muốn đặt hệ thống kinh doanh quan trọng của mình vào 1 cuộc chuyển đổi mang tính hên xui đến tận năm sau mới biết kết quả.
Ba là, chi phí duy trì hệ thống trên Cloud anh được các nhà cung cấp giới thiệu là dùng đến đâu trả tiền đến đấy, tiết kiệm chi phí so với tự sở hữu mà thực tế anh thấy vẫn cao, nhất là các dịch vụ Cloud của nước ngoài như AWS hay Azure. Vì mấy vấn đề ấy nên mình mới cần tham khảo Châu về hướng làm đúng”.
Sau khi cân nhắc về vấn đề Một, tôi thấy rằng anh đang đi đúng hướng. Thay vì chờ đợi tuyển dụng được đúng người, anh đã đi theo hướng nhanh hơn là nhờ tôi tư vấn. Sau buổi gặp gỡ hôm ấy, tôi đã trực tiếp phối hợp với đội nhóm của anh để tìm hiểu cụ thể hiện trạng và trực tiếp hỗ trợ quá trình chuyển đổi. Nhờ sự hỗ trợ của đội BA và QA tôi được nắm qua về các nghiệp vụ, xem phân tích hiệu năng, trực quan nhìn thấy các nghiệp vụ, chức năng chưa đạt chất lượng. Qua các leader tôi được thấy rõ hơn về kiến trúc, sự vận hành liên kết các thành phần từ hạ tầng lên ứng dụng.
Sau khi bắt bệnh thì đến kê đơn. Các “chiêu thức” được tung ra.
Tôi cho chia tách 3 nghiệp vụ có lượng truy cập cao nhất từ chạy hệ thống chung (monolith) thành các vi dịch vụ chạy riêng (micro-service), ví dụ như dịch vụ nhận đơn đặt hàng. Tránh hướng đi tham lam là chuyển đổi hàng loạt dịch vụ cùng lúc, chỉ nên dừng lại không quá 3 dịch vụ trong bước đầu tiên.
Tiếp theo là đóng gói các dịch vụ đó vào container (là 1 dạng “cô lập” môi trường chạy dịch vụ ở mức hệ điều hành) thay vì để trong máy chủ ảo (VM – “cô lập” môi trường dịch vụ cả ở mức hệ điều hành lẫn phần cứng) giúp tiết kiệm rất nhiều chi phí sử dụng tài nguyên.
Sau đó là vấn đề giao tiếp nội bộ giữa các hệ thống. Nó luôn là “ác mộng” trong các công ty lớn vì sự ràng buộc chồng chéo nhau giữa các hệ thống. Ví dụ như hệ thống nhận đơn hàng giao tiếp với cả hệ thống kho với hệ thống giao hàng. Đâu đó hệ thống giao hàng lại cần giao tiếp sang hệ thống kho ví dụ khi có đổi trả hàng. Ngược lại, hệ thống kho lại cần báo cho hệ thống tìm kiếm hàng hoá phía khách hàng. Tất cả giao tiếp đang sử dụng kiểu truyền thống là dùng REST API, là kiểu giao tiếp đồng bộ point-to-point yêu cầu bên gửi phải có thông tin bên nhận và bên gửi phải trực tiếp gửi thông tin đến địa chỉ đó. Là giao tiếp đồng bộ thì sẽ có khả năng bị mất đồng bộ khi 1 trong 2 bên gửi – nhận thông tin bị trục trặc hay có thay đổi, dẫn đến mất mát thông tin trong quá trình giao tiếp. Mất đồng bộ là có khả năng khách hàng không tìm thấy hàng dù hàng đang có trong kho. Hay tệ hơn nữa là có khả năng thanh toán đã nhận nhưng đơn hàng thì không được ghi nhận. Các khiếu nại, sửa chữa sự cố phát sinh sau đó lại càng làm giảm hiệu quả kinh doanh. Để tránh gặp các sự cố như thế này, khi có thay đổi hay mở rộng nghiệp vụ mới, các đội phát triển rất mất thời gian trong kiểm tra sự thay đổi có liên quan đến những thành phần nào, nếu có là phải sửa cả những thành phần đó. Đây chính là lý do hạn chế khả năng mở rộng của hệ thống.
Để giải quyết cái sự phức tạp trong giao tiếp đồng bộ như vậy, tôi cho chuyển đổi sang dùng giao tiếp bất đồng bộ sử dụng Message Broker của Kafka. Loại giao tiếp này cho phép các bên uỷ quyền việc chuyển thông tin cho bên trung gian là Message Broker, giúp tách biệt nghiệp vụ gửi thông tin và nghiệp vụ nhận thông tin, không còn phải quan tâm đến “địa chỉ” của nhau nữa, lại không bao giờ mất dữ liệu cho dù dịch vụ tạm thời gián đoạn đi nữa vì thông tin vẫn còn ở trong hàng đợi (queue) của Broker. Do không còn ràng buộc với nhau, các bên có thể độc lập phát triển các nghiệp vụ mới mà không phải can thiệp, chỉnh sửa nghiệp vụ cũ.
Sau giao tiếp, là đến dữ liệu. Cụ thể là các xử lý với Database/Caching. Tôi cho hạn chế việc truy cập vào Database một cách tối đa. Những nghiệp vụ không đòi hỏi dữ liệu mới nhất hay dữ liệu không quá quan trọng, tôi cho tận dụng tối đa Caching. 1 ví dụ: rất là không hiệu quả nếu như kể cả dữ liệu như FAQ (câu hỏi thường gặp) chúng ta cũng phải gọi đến database để lấy ra. Nội dung ít thay đổi như thế này tốt nhất để lên CDN.
Bước cuối cùng là cài đặt giám sát đo lường hiệu năng hệ thống vv… cho phép đánh giá được kết quả cải thiện hệ thống sau mỗi bước thay đổi.
Về cụ thể cần tối ưu database nào, cần giám sát cái gì thì hơi dài dòng và không phải là thông tin mang tính tổng thể, phổ quát nhất để áp dụng được cho các doanh nghiệp. Trong phạm vi bài viết này tôi xin phép không đi quá sâu các việc đó.
Sau khi có hướng đi về áp dụng công nghệ như thế nào, thì bước tiếp theo là vấn đề thời gian để thực hiện, triển khai hệ thống như đã thiết kế. Nó liên quan vấn đề Hai mà anh Lâm đã nêu, anh luôn băn khoăn vì nếu thời gian triển khai quá lâu thì ảnh hưởng, gián đoạn các công việc khác, lỡ mất các cơ hội trong thời gian chuyển đổi và phát sinh nhiều chi phí.
Để xây dựng nhanh thì không phải không làm được, khi đã có các giải pháp Cloud, dịch vụ Managed Service (các dịch vụ công nghệ đã được tạo ra sẵn và được quản lý, duy trì vận hành bởi các bên thứ 3). Nhưng đổi lại sẽ cần chi phí lớn. Hiện nay đa số các dịch vụ như vậy mà có chất lượng tốt thường được cung cấp bởi các doanh nghiệp nước ngoài có mức giá chưa hẳn phù hợp với thị trường Việt Nam. Ví dụ như dịch vụ Pub/Sub Messaging của Confluent ước tính 1 năm sẽ phải trả hơn 1 tỉ đồng cho 1 mức lưu lượng trung bình 50MBps. Ngoài ra nhiều Cloud cung cấp ra quá nhiều lựa chọn và cấu hình riêng lẻ, đòi hỏi cần nắm sâu về các dịch vụ trên đó để có thể lựa chọn và kết hợp lại để ra được hệ thống có hiệu năng tốt nhất và chi phí tốt nhất. Trong bối cảnh ưu tiên gấp rút triển khai khi đó, tôi đã tư vấn anh Lâm đưa 1 phần hệ thống lên 1 Cloud quốc tế, chấp nhận một chi phí duy trì vận hành tương đối lớn trên Cloud đó.
Về vấn đề Ba – chi phí. Mặc dù bằng cách chuyển đổi kiến trúc sang micro-service, cho phép co dãn riêng các vi dịch vụ (micro-service) thiết yếu và yêu cầu tải cao, đã giúp tiết kiệm hơn nhiều là co dãn nguyên toàn bộ hệ thống monolith bằng sử dụng các VM và Load Balancer, thì tôi thấy rằng vẫn có thể tối ưu hơn nữa các chi phí trên Cloud bằng cách tối ưu hơn khả năng khai thác hạ tầng ở dưới thông qua nền tảng (platform nằm trên hạ tầng). Trong rất nhiều dự án phần mềm, chúng ta chỉ cần sử dụng không quá 10 dịch vụ thiết yếu để dựng lên được hệ thống có hiệu suất cao. Ví dụ như máy ảo, database hay cache, queue. Do đó nếu như thay vì phải chuyển đổi lên 1 hệ thống Cloud phức tạp, nếu như có sẵn 1 nền tảng (platform) nào đó đáp ứng các dịch vụ thiết yếu nhất, được thiết kế kết hợp 1 cách tối ưu sẵn để khai thác tối đa hạ tầng ở dưới và không yêu cầu cấu hình phức tạp về phía người dùng, thì quá trình chuyển đổi của anh Lâm sẽ ngắn và tiết kiệm hơn nhiều.
Kết quả chuyển đổi và suy ngẫm
Cho đến bây giờ anh Trần Lâm đã có thể yên tâm với hệ thống mới và tiếp tục tập trung vào bài toán kinh doanh. Anh liên tục hồ hởi báo với tôi về các dự án mới được khởi động, tần suất hơn hẳn trước đây. Anh nói về các câu chuyện kinh doanh nhiều hơn, thay vì những lo lắng liên quan kĩ thuật như trước đây.
Cũng trong giai đoạn 2020-2021, thông qua vai trò giám đốc kĩ thuật-giải pháp, tôi tiếp tục tư vấn hoặc trực tiếp tham gia chuyển đổi số thành công cho nhiều doanh nghiệp, ví dụ như chuyển đổi kiến trúc micro-service cho startup Logivan của Việt Nam, giải pháp thương mại điện tử và quản lý dịch vụ cho Wilson Security của Úc, hay triển khai bán hàng trực tuyến cho khu vực châu Á Thái Bình Dương cho tập đoàn Electrolux của Thuỵ Điển. Tôi nhận thấy thay vì trực tiếp làm việc với từng doanh nghiệp riêng lẻ, nếu như có thể đưa những kinh nghiệm chuyển đổi số “xương máu” thực tế không chỉ của tôi mà còn của các chuyên gia kĩ thuật khác vào cái nền tảng mà tôi đề cập tới ở trên thì có thể giúp được nhiều doanh nghiệp hơn, giúp cho công việc chuyển đổi số ấy sẽ nhanh hơn và rẻ hơn.
Doanh nghiệp của anh Trần Lâm không phải doanh nghiệp duy nhất gặp phải khó khăn trong chuyển đổi số. Nhiều doanh nghiệp nhận thức rõ lợi ích của chuyển đổi số nhưng không phải doanh nghiệp nào cũng dễ dàng thực hiện nó. Vấn đề là ở con đường thực hiện để đáp ứng hiện trạng và bối cảnh thực tế chứ không phải chỉ ở những lý thuyết, biện pháp kĩ thuật trong sách vở hay những slide đẹp đẽ. Đó là những điều tôi được chứng kiến thực tế ở các công ty trong và ngoài nước, từ startup đến qui mô tập đoàn lớn. Ngay cả các doanh nghiệp lớn với nhân lực dồi dào và sự chuẩn bị kĩ lưỡng, việc chuyển đổi 1 hệ thống đồ sộ chưa bao giờ là dễ dàng. Bản thân doanh nghiệp anh Trần Lâm là 1 doanh nghiệp lớn, thậm chí đi lên từ công nghệ từ đầu và có nguồn lực công nghệ tốt mà vẫn bị mất phương hướng trong thời kì này khi mọi thứ thay đổi quá nhanh. Sẽ càng không dễ dàng đối với các doanh nghiệp vừa và nhỏ (SMB).
Sự ra đời của Sunteco Cloud
Xuất phát từ nhu cầu các doanh nghiệp như của anh Trần Lâm, xuất phát từ kinh nghiệm hỗ trợ chuyển đổi số cho các doanh nghiệp và nhận định nhu cầu về nền tảng (platform) là chìa khoá quan trọng cho chuyển đổi số, là sự bước tiếp theo sau sự chuyển đổi về hạ tầng (infrastructure), năm 2021 tôi và các cộng sự đã bắt tay vào xây dựng nền tảng Sunteco Cloud.
Các dịch vụ trong hệ sinh thái
Với sự ủng hộ, đầu tư của các nhà đầu tư, với hạ tầng Data Center đạt tiêu chuẩn T-3 cho thiết kế lẫn thi công duy nhất ở Việt Nam tính đến thời điểm này, hệ thống truyền dẫn cáp quang có tổng chiều dài 15000km nhiều nhất Việt Nam, và sự đóng góp xây dựng phương án kỹ thuật của các chuyên gia giàu kinh nghiệm trong lĩnh vực Cloud, Network, Linux, kiến trúc phần mềm mà tôi may mắn được cộng tác, nền tảng Sunteco Cloud đã và đang được hiện thực hoá. Với triết lý luôn luôn đi trước trong áp dụng các công nghệ mới, đem lại lợi thế cạnh tranh tốt nhất cho doanh nghiệp với chi phí hợp lý, công ty đã sẵn sàng đồng hành cùng quá trình chuyển đổi số của các doanh nghiệp.
Những vấn đề mà Sunteco Cloud giải quyết:
- Cung cấp ra tập hợp các công nghệ thiết yếu, quan trọng nhất trong 1 stack được tối ưu, vận hành và quản lý trên Cloud bởi nguồn lực chuyên gia hàng đầu. Ví dụ như cơ sở dữ liệu có khả năng co dãn và phân tán, hệ thống bộ nhớ đệm không giới hạn (in-memory cache) hay hệ thống nhật ký vận hành hệ thống độc lập với hệ thống của ứng dụng vv… Cho phép khách hàng sử dụng được luôn vào phát triển ứng dụng.
- Tạo nền tảng đóng gói sẵn các vấn đề về công nghệ và hạ tầng liên quan kiến trúc micro-service, cho phép khách hàng chuyển đổi sang kiến trúc phần mềm micro-service dựa trên container hiện đại trong thời gian ngắn. Quan trọng hơn, Sunteco Cloud cung cấp công cụ và dịch vụ cho phép khai thác tối đa các lợi ích của kiến trúc micro-service và container, như khả năng đáp ứng tức thời khi tải tăng cao, zero down-time, phân tán hệ thống ở nhiều khu vực hay tận dụng các hạ tầng có sẵn giúp tiết kiệm tối ưu chi phí vv,…
- Loại bỏ, tối giản thời gian và nguồn lực của khách hàng dành cho việc quản lý cấu hình và vận hành hạ tầng, dù là hạ tầng đặt trên Cloud. Cho phép khách hàng tập trung vào tầng ứng dụng, giúp triển khai dễ dàng hơn, nhanh hơn các ứng dụng, dịch vụ phục vụ kinh doanh.
- Thông qua công nghệ Sun Spinner, tập trung vào khả năng tăng cường đối đa khả năng co dãn, chịu tải của hệ thống, để luôn đảm bảo trải nghiệm tốt nhất cho khách hàng, người dùng hệ thống của doanh nghiệp.
- Ưu tiên khả năng đáp ứng liên tục (High Availability), khả năng chịu lỗi, khả năng phục hồi dịch vụ sau sự cố cho khách hàng. Cung cấp khả năng roll-back, roll-forward cho phép khách hàng quay ngược thời gian về thời điểm cũ hoặc tiến thẳng sang bản nâng cấp mới dễ dàng, không mất mát dữ liệu.
- Thông qua công nghệ Sun Highway, cung cấp kênh giao tiếp hiệu năng cao, bất đồng bộ giữa các micro-service, cùng khả năng lưu trữ các thông tin trong lịch sử giao tiếp. Cung cấp công cụ quản lý trực quan, giám sát kênh giao tiếp dưới dạng trực quan.
- Cung cấp kênh phối hợp làm việc nhóm (team collaboration) và khả năng phân quyền để các nhân viên trong doanh nghiệp với các vai trò khác nhau có thể cùng tham gia làm việc với hệ thống, thực hiện nhiệm vụ của mình, hỗ trợ được team mà không gây các ảnh hưởng ngoài vai trò của mình đến hệ thống. Cung cấp giao diện dễ sử dụng cho người dùng kĩ thuật lẫn người dùng thông thường.
- Chuyên gia trực tiếp hỗ trợ tại chỗ cho doanh nghiệp trong các vấn đề và nhu cầu riêng trong chuyển đổi nếu có.
Để có thể đáp ứng tốt nhất cho nhu cầu cụ thể của doanh nghiệp, đội ngũ SUNTECO và tôi luôn mong muốn được lắng nghe, tiếp thu các yêu cầu, chia sẻ và phản hồi của doanh nghiệp hay các chuyên gia trong làng công nghệ. Mọi thông tin liên hệ, xin gửi về:
Email công ty: info@sunteco.io
Email của tôi: chau.nguyen@sunteco.io
Xin cảm ơn quý độc giả và các bạn đã dành thời gian đọc bài viết! Chúc quý độc giả và các bạn dồi dào sức khoẻ, thành công trên những hành trình chuyển đổi và làm mới bản thân, làm mới doanh nghiệp!
Đọc thêm về các bài viết công nghệ chuyên sâu tại Tech Sharing
Trải nghiệm các dịch vụ trong hệ sinh thái Sunteco Cloud tại dashboard.sunteco.vn
