Blog - FPT Smart Cloud

FPT ArgoCD được xây dựng để khởi tạo và quản lý ArgoCD thông qua giao diện FPT Cloud Portal. ArgoCD là một công cụ mã nguồn mở dùng để triển khai các ứng dụng trên Kubernetes. Dịch vụ cho phép các nhóm phát triển quản lý và triển khai các ứng dụng mà không cần phải tìm hiểu nhiều về Kubernetes. Trong phiên bản cập nhật V1.1 của FPT AgroCD bao gồm: - Quản lý Admin Account - Tích hợp quản lý user thông qua việc cấu hình OIDC tích hợp với hệ thống SSO của người dùng. - Support version v2.8.7, v2.9.0, v2.9.1, v2.9.2, v2.9.3 - Hỗ trợ enable applications set phục vụ người dùng tạo/update multiple applications - Hỗ trợ enable và cấu hình notifications Quản lý Admin Account, Anonymous user User có thể thực hiện enable/disable admin account, anonymous user. Thực hiện thay đổi password của admin account để đăng nhập vào argocd instance Cấu hình  OIDC Scope phục vụ tích hợp SSO User có thể tích hợp OIDC với hệ thống SSO như keycloack để quản lý user đăng nhập vào ArgoCD instance. Hệ thống cho phép người dùng enable/disable chức năng cấu hình OIDC: Sau khi enable OIDC hệ thống cho phép người dùng thêm mới một OIDC config: Thực hiện chỉnh sửa cấu hình sau khi đã thêm mới: Thực hiện xoá OIDC khi không sử dụng: Thực hiên enable Applications set phục vụ tạo applications User có thể thực hiện enable/disable chức năng Applications set: Thực hiện cấu hình Notifications User có thể thực hiện cấu hình notifications để gửi thông báo khi applications có sự thay đổi. User có thể thực hiện enable/disable chức năng notifications Cấu hình channel để gửi thông báo khi có sự thay đổi tới telegram/email/slack Thực hiện thay đổi thông tin đã cấu hình Thực hiện xoá channel nếu không muốn sử dụng Upgrade Versions User có thể thực hiện tạo/upgrade version argocd instance lên một số version khác nhau bao gồm: v2.8.7, v2.9.0, v2.9.1, v2.9.2, v2.9.3

Kafka là một nền tảng distributed event streaming cho phép người dùng thu nhận và xử lý các event, message real time. Nó hoàn toàn có thể là xương sống cho ngành bán lẻ nơi mà khách hàng luôn cần thông tin và phản hồi ngay lập tức kể cả trong việc xem hàng, mua hàng hay thanh toán. Nó cũng có thể là phần hậu phương đủ lớn cho việc phân tích, xử lý data với các nền tảng IOT, big data. Vậy thì, để làm được những điều phi thường đó, kafka đã làm như thế nào? Từ đâu mà Kafka được tạo nên? Kafka được vận hành trên ý tưởng về async programing và message driven programing. Ý tưởng về async programing sinh ra nhằm giải quyết bài toán khi có nhiều services trong 1 hệ thống cùng contact lẫn nhau, services A và B cùng gọi tới service C thì cái nào sẽ được giải quyết trước? Cũng như con người, khi 2 người cùng đưa ra yêu cầu tới một nhân viên chăm sóc KH, họ giải quyết cho KH A mất thời gian quá lâu sau đó tới giờ nghỉ trưa thì KH B có thể tới ngày hôm sau mới được chăm sóc, hoặc mất luôn KH B. Để giải quyết bài toán đó có 2 cách. Cách số 1: tăng thêm nhân viên chăm sóc KH. Điều này sẽ dẫn tới phối hợp 1 – 1 và làm cho công ty không scale được khi có thêm KH. Cách số 2 cũng là cách mà async programing based trên: cho phép xử lý song song cả 2 request bởi cùng 1 người. Điều này sẽ tránh được việc blocking request. Cụ thể, async programming là cách tách biệt giữa request và response giữa các services: Service A request tới service B Service C request tới service B Service B nhận 2 request, phản hồi lại với A và C là đã nhận request Service B xử lý request A và C tùy cái nào tới trước sau đó response lại Service A và C trong lúc chờ đợi sẽ tiếp tục gửi request tới service B và cuốn chiếu tracking response trở về. Ý tưởng về asynchronous programming không phải toàn năng, nó sẽ gặp vấn đè nếu server chung (ví dụ như service B) quá tải và ngừng hoạt động. Lúc đó service C hay A sẽ phải retry gửi lại request và càng lúc càng bị đầy request lên. Vấn đề thứ 2, async giải quyết được 1 service nhận nhiều request, nhưng không tính tới tình huống 1 request gửi đi nhiều service khác nhau và track response. Đó là lúc có message driven programing ra đời. Message-driven programing là lập trình điều hướng các message. Khi có nhiều request từ nhiều services có nhu cầu gửi tới nhiều servies khác, sẽ phải có 1 cái gì đó điều phối ở giữa để đảm bảo tất cả các request đều tới đích và nhận được response phù hợp. Client và server sẽ không giao tiếp trực tiếp với nhau nữa, 2 service cũng không thông trực tiếp với nhau mà sẽ qua 1 bên điều phối thứ 3 gọi là message broker. Message broker bản thân như một môi giới trong bất kỳ ngành nghề gì, kết nối người mua - người bán một mặt hàng nào đó với nhau. Cùng 1 lúc 1 môi giới BĐS có thể đưa 10 KH khác nhau match với 10 căn nhà khác nhau thành công. Message broker cũng như vậy, tiếp nhận message từ client, từ services, từ KH, từ mọi nguồn và phân phối nó tới chỗ nó cần tới trong 1 system. Trên thị trường có rất nhiều message broker như RabbitMQ, ActiveMQ thậm chí là Redis, nhưng, Kafka Apache có những unique selling point nếu so sánh với phần đông thị trường. Không chỉ phân phối được message (như mọi loại message queue), Kafka có các lợi thế sau  nếu so sánh với các loại sản phẩm khác: Đảm bảo việc gửi nhận không bị gián đoạn Có cơ chế xử lý lỗi Performance cao High availability Scalability          Dựa trên các ý tưởng trên, Kafka được phát triển ra và khẳng định sức mạnh của mình ở khoản performance mạnh mẽ trong việc điều phối data. Tiếp theo sẽ là cách mà kafka vận hành. Các thuật ngữ trong Kafka Để hiểu cách Kafka vận hành, có 2 loại khái niệm cần phải nắm được. Loại khái niệm đâu tiên chia theo chiều đi của message: message được gửi từ đâu tới đâu. Chiều thứ 2 là kafka có những component nào để vận hành. Khái niệm theo cách thức vận hành: Topic: Là các luồng data chạy trên kafka (bản chất là 1 chuỗi các message chạy liên tục). Các topic được chia thành các partition và các message được lưu thành các offset trên partition (xem mục partition và offset). Một topic sẽ có các đặc điểm sau: Xếp hàng: Khi có event/message mới ghi vào topic, message/event đó sẽ được nối vào cuối log của topic. Bất biến: Message/event được ghi vào sẽ không thể bị chỉnh sửa. Tuần tự: Consumer (tham khảo ở dưới) sẽ đọc log bằng cách đi tìm các offset và đọc các entries ghi theo lượt tuần tự Nhân bản: mỗi topic của kafka luôn là multi-producer và multi-subscriber: tức là cùng 1 lúc 1 topic có thể có nhiều nguồn gửi data vào và nhiều nguồn hứng data trong pipeline Không giống như các hệ thống stream message khác, dữ liệu trên kafka sẽ không bị xóa đi sau khi đã truyền tới đích. Thay vào đó, kafka cho phép setup thời hạn expired data khi data đạt tới độ lớn hoặc một khoảng thời gian nhất định Offset: Message khi chảy vào 1 topic sẽ được lưu vào thành offset của 1 partition. 2 message khi chảy vào có thể ghi thày cùng 1 offset và cùng 1 offset có thể ghi ở nhiều partition khác nhau. Thứ tự của 1 offset chỉ được đảm bảo trong cùng 1 partition Ví dụ: trong cùng partition 1, message có offset = 5 chắc chắn đến sau message có offset = 4. Producer: Là nơi tạo ra data/message/event cho các topics của Kafka (write). Các “producer” sẽ kiểm soát dữ liệu nào sẽ đi vào “partition” nào trong 1 topic. Rule phân bổ là theo round-robin để cân bằng tải hoặc theo rule set stream theo event key Consumer: Là nơi hứng các data/message/event sinh ra topics của Kafka (read). Thông thường, một consumer sẽ phải đọc 1 bản ghi sinh ra 1 cách tuần tự, tuy nhiên, kafka cho phép kiểm soát thứ tự bản ghi theo từng người dùng, dẫn tới việc mỗi consumer hoàn toàn có thể nhảy cóc thứ tự đọc nhằm đảm bảo tính real time của dữ liệu VD: 1 consumer có thể tái sử dụng 1 bản ghi cũ để làm bản ghi mới hoặc có thể nhảy cóc qua các bản ghi đang sinh ra để đọc bản ghi gần nhất và ngay lập tức sử dụng bản ghi đó Một Kafka consumer có thể vào đọc và sử dụng tài nguyên mà không ảnh hưởng tới cluster của các consumer khác.       Kết luận lại: multi-producers sẽ tạo (writre) ra nhiều message/event/data đẩy vào trong topic. Data đó sẽ được lưu thành các offset. Multi-consumer/subscriber vào check offsets để đọc (read), sau đó sẽ xử lý tiếp request. Tiếp đến, kafka có các khái niệm bổ dọc theo tầng hệ thống: Partition: Các partition là các phần nằm bên trong 1 topic cho phép khi có nhiều offset cùng vào topic tại một thời điểm, các offset sẽ được chia cho nhiều partition để phân phối tới consumer. Một partition sẽ độc lập với các partition khác. Số lượng partition cho mỗi topic thì tuỳ theo nhu cầu của ứng dụng do người dùng quy định. Trong mỗi partition sẽ lưu nhiều offset, số lượng offset của mỗi partition có thể là khác nhau, tùy vào rule phân phối đã set vd theo round-robin hoặc event key rule. Broker: Message được lưu tại offset của partition, partition lưu ở trong topic. Các topic sẽ được lưu trên kafka broker Bản thân 1 broker của kafka là 1 server nằm trong cụm cluster của kafka để lưu trữ dữ liệu Thông thường theo mô hình truyền thống, 1 kafka server sẽ tương ứng với 1 cụm cluster dựng trên máy chủ vật lý. Khi server này chết thì toàn bộ dữ liệu sẽ mất cùng với nó luôn. Đây gọi là single-point failure. Cụm cluster Kafka sẽ phân tán các partition của cùng 1 topic ra nhiều broker nhất có thể để đảm bảo khi có 1 con broker chết, sẽ có con khác backup và giải quyết vấn đề không bị gián đoạn hệ thống Tuy nhiên, việc chia broker và partition vẫn chưa giải quyết được hết single point failure do nếu data store trên 2 broker và cả 2 con cùng ngừng hoạt động thì bản chất vẫn là single point. Do đó, Kafka có khái niệm thứ 3: replication. Replication: Là bản sao của topic ở trên 1 broker sang 1 broker khác VD: Có 3 topic và 3 brokers Topic A lưu ở broker 1 và 2 Topic B lưu ở broker 2 và 3 Nếu broker 1 và 2 ngừng hoạt động thì Topic A cũng sẽ ngừng hoạt động Do đó, kafka sẽ có replica topic A sang broker 3 để hệ thống vẫn stream bình thường. Tương tác với topic B rồi C Trên 1 broker sẽ có lưu 1 phần topic này và replica của topic kia để đảm bảo khi có 1 broker hoặc 1 cụm broker ngừng hoạt động thì vẫn sẽ có bản lưu ở 1 chỗ nào đó khác. Kafka vận hành ra sao Bên trên là một số các khái niệm cơ bản khi tìm hiểu về kafka. Tiếp theo, bài viết sẽ giới thiệu cụ thể cách kafka vận hành: Input data from producers Đầu vào của hệ thống nằm ở producer tạo ra (write) message gửi vào các topic trong cụm kafka cluster. Lập trình viên sẽ setup để producer write vào topic nào và dừng lại ở đó. Khi có message vào, producer tự động biết nên write vào broker nào và partition nào. Nếu ghi fail thì sẽ có cơ chế retry thành công Việc “tự động” write được vào partition nào là do cơ chế round-robin của kafka: Có 3 brokers: message đầu tiên sẽ vào broker 1, message thứ 2 vào broker 2, message thứ 3 vào broker 3, message 4 sẽ vào broker 1,… Khi write vào partition, có cơ chế acks (acknowledgment) để báo producer biết message đã gửi thành công. Ack có 3 states: Acks = 0: producer gửi message và không chờ phản hồi (có thể dẫn tới mất data) Acks = 1: producer chờ tới khi nhận được phản hồi nhưng không lưu lại message sau khi write thành công. State này dẫn tới nếu broker đó chết, message sẽ mất theo Acks = 2: producer chờ nhận phản hồi và chắc chắn phản hồi đã được lưu lại trên broker chính và toàn bộ các bản replica (sẽ có ảnh hưởng tới performance do phải chờ response write data thành công) Processing data Kafka implement message bằng cách chỉ định 1 replication bất kỳ làm leader. Cơ chế này là leader partition concept. Tại một thời điểm, mỗi partition có duy nhất 1 replication leader, các replication còn lại là ISR – In sync replica sẽ đồng bộ lại data đã ghi ở leader. Nếu replication leader ngừng hoạt động, hệ thống tự động chỉ định 1 ISR bất kỳ đứng lên làm leader. Việc chỉ định này được thông qua thuật toán của Kafka Zookeeper. Với khái niệm replication như trên, 1 partition sẽ được nhân bản (replicate) lưu trên nhiều broker khác nhau. Vậy thì, khi producer write được data vào topic, data này bản thân được lưu ở đâu, lưu vào bản replica nào, theo rule gì? Kafka Zookeeper là core dùng để quản lý metadata của kafka. Metadata này bao gồm: Toàn bộ các action phát sinh trong hệ thống: CRUD topics, crud brokers, crud partitions, status,…. Brokers nào nằm ở cụm kafka cluster nào Configuration, permissions của các topics Việc kiểm soát các metadata này cho phép zookeeper tính toán để chỉ định các replication leader và ISR cũng như điều phối để các broker hoạt động một cách bình thường. Khi các broker được điều hướng để hoạt động, các messages khi producers write xuống các topics sẽ được đảm bảo được tính tin cậy và bền vững. Các message được write thành các offset xếp theo thứ tự trên partition trong một topic lưu trên 1 broker và được replica sang các ISR khác. Tiếp theo, consumer sẽ vào để “sử dụng” các offset này. Consume messages Các consumer đọc message từ topic theo topic name. Tuy nhiên, như đã mô tả phía trên, 1 broker sẽ có các replica để store topic, vậy nên consumer sẽ đọc theo leader replication. Tiếp đến, nếu quá trình read gặp lỗi,  kafka có cơ chế tự phục hồi để đảm bảo dữ liệu tới nơi toàn vẹn. Việc đọc của consumer sẽ diễn ra tuần tự trong 1 partition, offset nào tới trước sẽ được đọc trước. Một consumer có thể đọc nhiều message trong nhiều partition khác nhau trong 1 topics. Do thứ tự message trong partition không thay đổi thứ tự nên khi read từ nhiều partition sẽ có những tình huống consumer đọc offset = 3 ở partition 1 - trước khi đọc được offset = 1 ở partition 3. Tuy nhiên, kafka cho phép xử lý multi – multi, tức là multiple message được read bởi multiple consumer. Nếu như chỉ có 1 consumer đọc toàn bộ message của toàn bộ các partition thì sẽ xảy ra tình trạng quá tải. Vậy nên, kafka giải bài toán đó thông qua consumer group. 1 consumer group sẽ nhận toàn bộ data của các partition và chia cho các consumer bên trong quản lý. Mỗi consumer trong 1 group sẽ đọc toàn bộ data của một hoặc nhiều partition để đảm bảo messasge ordering. Một consumer có thể read message từ nhiều partition nhưng 1 partition sẽ không thể gửi message cho nhiều consumer trong 1 group. Cơ chế consumer group sinh ra nhằm đảm bảo không có consumer nào bị quá tải khi nhận message từ brokers. Tổng kết lại message được sinh ra từ 1 producer, gửi topic. Topic được vận hành bởi các broker, trên các broker sẽ có replication leader của topic này và các ISR của topic khác. Việc phân phối chỉ định leader do Kafka Zookeeper phân phối. Message từ producer sẽ được ghi thành các offset trên partition trong topic. Consumer group nhận toàn bộ message từ partition và phân phối cho các consumer bên trong để sử dụng. Toàn bộ cơ chế trên chính là việc implement queue và topic trong message broker. Có 2 dạng phân phối message khi nói về message broker là queues (point-tpoint messaging) và topic (broadcast messaging) Queue: là 1 dạng phân phối message quan hệ 1 – 1 (point to point messaging) giữa client và server (hoặc giữa các services). Mỗi message chỉ có 1 đầu vào và 1 điểm tới. Bản thân queueing trong kafka chính là việc message từ 1 topic A (bất kể có bao nhiêu partition) sẽ chỉ được gửi tới 1 consumer group B (bất kể có bao nhiêu consumer) Broastcast messaging: một message được gửi tới nhiều địa chỉ, chỉ khi subscribe địa chỉ thì mới nhận được message đó. Trong kafka, khái niệm này chính là dạng 1 topic gửi message tới nhiều consumer groups. Consumer nào subscribe topic mới read được message đó. Bên trên là toàn bộ các khái niệm cũng như basic cách kafka apache vận hành. Bằng cách cung cấp service Kafka, FPT Smart Cloud đồng thời cung cấp toàn bộ những ưu điểm của kafka apache như sự ổn định, tính bền vững và khả năng scaling cũng như performance mạnh mẽ của nền tảng này. Đăng ký sử dụng thử miễn phí ngay: https://fptcloud.com/lien-he/   Nguyễn Quý Hiếu

Trong việc phát triển phần mềm kỹ thuật nói riêng và khi bàn về công nghệ nói chung, cụm từ Kafka thường hay xuất hiện như là một giải pháp truyền dữ liệu real time (thời gian thực). Hiểu một cách đơn giản là khi 1 khách hàng đang mua hàng trên 1 app di động, để họ xem được mặt hàng, gửi đơn hàng tới các bên xử lý một cách nhanh nhất thì luồng dữ liệu đi dưới hệ thống phải được thông suốt càng nhanh càng tốt mà không phải chờ đợi. Nếu chỉ có một khách hàng giao tiếp với một hệ thống thì sẽ không có chuyện gì để bàn. Nhưng khi có cả triệu khách hàng giao tiếp cùng lúc với một hệ thống, số lượng data truyền xuống từ một khách hàng là vô cùng lớn, chưa kể trong 1 hệ thống thường được cấu thành bởi vô vàn các services, các component khác nhau. Bài toán lúc này không nằm ở việc app đầy đủ thông tin hay được trang điểm đẹp đẽ, mà trở thành làm thế nào để cả triệu khách hàng cùng nhận được thông tin một cách nhanh chóng? Vào ngày 11 tháng 1 năm 2011, Kafka Apache ra đời để giải quyết bài toán trên. Vậy Kafka là gì, FPT Smart cloud cung cấp giải pháp gì liên quan tới Kafka Apache? Kafka là gì? Kafka là một nền tảng phân phối sự kiện dữ liệu (message and event) cho phép: Publish và subscribe các luồng sự kiện, message (event stream) Lưu trữ, xử lý và phân phối dữ liệu thời gian thực Để hiểu được việc phân phối dữ liệu, sự kiện (distributed event streaming) thì trước hết cần hiểu 1 sự kiện (event) là 1 bản ghi 1 action trong hệ thống. Ví dụ khi 1 khách hàng vào app thì sẽ sinh ra 1 event như sau: eventKey: “FPT_Cloud_Kafka” eventValue: “Open Application” EventTimestramp: “Aug.25.2023.13:06” Event được định nghĩa bởi: user – action – time. Việc phân phối dữ liệu, sự kiện sẽ bắt đầu từ khi bắt được các event như ví dụ trên từ nhiều nguồn khác nhau như database, app mobiles, cloud services, backend services, software application,… Một nền tảng streaming dữ liệu sẽ bắt được các event theo thứ tự và xử lý các dữ liệu này trước khi đưa vào lưu trữ tập trung một cách real time để có thể sử dụng về sau (có thể là ngay lập tức). Các event này sẽ được đưa vào các stream pipeline - các luồng đi của dữ liệu được dựng lên. Dòng chảy này sẽ có các đặc tính sau: Toàn vẹn dữ liệu: dữ liệu từ lúc tiếp nhận cho tới khi đến đích phải nguyên vẹn Thời gian thực: dữ liệu truyền đi ngay khi event được sinh ra Đúng địa chỉ: dữ liệu sẽ phải được truyền tới đúng đích đã setup. Để làm được điều này Kafka sẽ được dựng trên một cụm cluster trải dài trên nhiều trung tâm dữ liệu (datacenter) và cung cấp các chức năng của nó theo cách phân tán (distributed), khả năng mở rộng và đàn hồi cao (scalable and elastic) cũng như khả năng chịu lỗi tốt và vô cùng bảo mật. Kafka có thể được dựng trên máy chủ vật lý, trên máy trạm ảo, trên các container của K8S hoặc tối ưu nhất là trên các nền tảng cloud. Bản thân việc dựng được một cụm cluster Kafka không phải chuyện đơn giản do người dùng sẽ phải có kiến thức nhất định về hạ tầng và cài đặt vận hành nền tảng. Hiểu được điều này, FPT Smart Cloud cung ứng dịch vụ Kafka as a service cho phép dựng sẵn một cụm cluster kafka mà người dùng không cần có những hiểu biết nêu trên. Ngoài ra, sản phẩm còn có nhiều Ưu và nhược điểm khi sử dụng Ưu/nhược điểm của việc sử dụng Kafka là gì? Lợi ích khi sử dụng Kafka Sử dụng Apache Kafka mang lại nhiều lợi ích cho việc xây dựng và triển khai các hệ thống xử lý dữ liệu thời gian thực và streaming. Dưới đây là một số lợi ích chính khi sử dụng Kafka: Xử lý Dữ liệu Thời gian thực: Kafka được thiết kế để xử lý dữ liệu thời gian thực và streaming, cho phép bạn đáp ứng nhanh chóng đối với sự kiện mới xảy ra. Điều này rất hữu ích cho việc giám sát, phân tích, và ứng phó tức thì với các tình huống thay đổi. Tính Nhất quán và Độ Tin cậy Cao: Kafka giữ cho bạn tính nhất quán dữ liệu thông qua quá trình sao lưu và sao chép thông điệp giữa các broker. Điều này đảm bảo dữ liệu không bị mất mát và luôn sẵn sàng cho các ứng dụng tiêu thụ. Mở Rộng Dễ Dàng: Kafka có khả năng mở rộng dễ dàng bằng cách thêm các broker vào cluster. Điều này cho phép bạn tăng khả năng xử lý dữ liệu mà không cần thay đổi cấu trúc toàn bộ hệ thống. Dữ liệu Đa Dạng: Kafka không chỉ hỗ trợ dữ liệu thông thường mà còn có khả năng xử lý dữ liệu đa dạng như logs, trạng thái ứng dụng, sự kiện liên quan đến giao dịch tài chính, và nhiều loại dữ liệu khác. Khả năng Chia Lượng Lớn: Nhờ việc sử dụng phân vùng (partitioning), Kafka có khả năng xử lý lượng dữ liệu lớn một cách hiệu quả. Điều này làm cho nó phù hợp cho các tình huống cần xử lý hàng tỷ sự kiện mỗi ngày. Tích hợp linh hoạt: Kafka có khả năng tích hợp với nhiều công nghệ và ứng dụng khác. Bạn có thể sử dụng các ngôn ngữ lập trình khác nhau để viết các ứng dụng producer và consumer, và Kafka cũng hỗ trợ các giao thức truyền tải khác nhau. Lưu trữ Dữ liệu Lâu Dài: Ngoài việc xử lý dữ liệu thời gian thực, Kafka cũng có khả năng lưu trữ dữ liệu lâu dài. Điều này cho phép bạn lưu trữ và truy xuất lại dữ liệu sự kiện trong tương lai để phân tích và kiểm tra. Hệ Thống Log: Kafka hoạt động như một hệ thống log, cho phép bạn lưu trữ và tìm kiếm thông tin sự kiện theo thời gian. Điều này rất hữu ích cho việc gỡ lỗi, phân tích dữ liệu và theo dõi hoạt động hệ thống. Nhược điểm của Kafka Phức Tạp trong Cài Đặt Ban Đầu: Cài đặt và cấu hình ban đầu của Kafka có thể phức tạp đối với những người mới bắt đầu sử dụng. Yêu Cầu Hiểu Biết Sâu về Hệ Thống: Để triển khai và quản lý Kafka hiệu quả, cần có kiến thức về hệ thống và mạng. Yêu Cầu Tài Nguyên: Kafka yêu cầu một số lượng tài nguyên tương đối lớn để hoạt động tốt, bao gồm bộ nhớ và khả năng xử lý. Khó Để Hiểu và Sử Dụng Cho Người Mới: Với những người mới sử dụng, Kafka có thể đầy thách thức và yêu cầu thời gian để hiểu rõ về cách làm việc của nó. Không Phải Là Giải Pháp Tất Cả Các Trường Hợp Sử Dụng: Mặc dù Kafka rất mạnh mẽ, nhưng nó không phải là giải pháp phù hợp cho tất cả các tình huống. Có những trường hợp sử dụng khác có thể phù hợp hơn. Khả Năng Quản Lý Dữ Liệu Lâu Dài Hạn: Mặc dù Kafka có thể lưu trữ dữ liệu lâu dài, nhưng việc quản lý và tìm kiếm dữ liệu trong các phiên bản sau này có thể đòi hỏi công việc phức tạp và tài nguyên. Usecases Kafka là một nền tảng streaming dữ liệu thời gian thực. Vì thế, nó đượng ứng dụng một cách rộng rãi trong nhiều ngành nghề và tổ chức. Kafka as a messaging system Trong ngành tài chính, các khoản payment và transactions khi phát sinh sẽ yêu cầu tốc độ xử lý càng nhanh càng tốt. VD: KH có nhu cầu rút tiền, process này diễn ra chỉ trong khoảng 5 – 10s sau khi nhập hết thông tin order VD: trong chứng khoán, giá của các mã chứng khoán thay đổi trong thời gian thực và nó ảnh hưởng trực tiếp tới giá trị giao dịch của cả ngàn KH một lúc Kafka lúc này sẽ được cài đặt và tinh chỉnh để trở thành 1 hệ thống truyền các message qua lại giữa nhiều hệ thống khác nhau VD: dữ liệu giá từ sở giao dịch tới công ty chứng khoán, dữ liệu mã chứng khoán từ trung tâm lưu ký tới công ty chứng khoán và ngân hàng Nếu không có kafka, các message sẽ có độ trễ, dẫn tới việc giao dịch có thể bị mất do lúc đó giá trị giao dịch không còn chính xác. Kafka as activity tracker Trong khối ngành logistic, một bài toán đặt ra là phương tiện chuyên chở đang đi tới đâu, bao lâu nữa tới nơi. Việc di chuyển diễn ra liên tục dẫn tới nhu cầu kiểm soát đước hoạt động này trở nên khó khăn VD: Đặt 1 course taxi, người dùng sẽ muốn biết xe đang tới đâu để có thể căn thời gian chuẩn bị, di chuyển tới điểm đón. Việc căn thời gian, đường đi này cần track được đường có đang tắc ở đâu không, có vướng mắc gì trên đường đi hay không Kafka as data processing Với trending nhà thông minh, việc ứng dụng IOT (internet on things) trở nên phổ biến hơn bao giờ hết. Để vận hành được thì các vật dụng cảm biến (sensor) trong nhà sẽ cần phải thu thập ược dữ liệu, sau đó phân tích xử lý dữ liệu đó trước khi truyền tới hệ thống để có action tiếp theo. VD: Khi người dùng nói: “Bật đèn”, micro hứng trong nhà sẽ phải bắt được câu “bật đèn”, xử lý dữ liệu để dịch ra ngôn ngữ hệ thống: eventKey: “guest” eventValue: “turn on the light” EventTimestramp: “Aug.25.2023.13:06” Sau khi xử lý xong, hệ thống sẽ truyền dữ liệu này tới bộ xử lý IOT. Bộ xử lý IOT sẽ truyền action tương ứng tới hệ thống điện trong nhà để bật đèn. Kafka sẽ cho phép quá trình thu thập và xử lý data xảy ra một cách nhanh nhất trước khi truyền dữ liệu đi. Nếu không có ứng dụng này, người dùng bình thường có thể mất tới vài lần nói thật to may ra mới bật được đèn một cách tự động Trong tương lai, việc phân tích và xử lý data có thể tiến tới tầm cao mới. Ví dụ như camera nhìn thấy sắc mặt của chủ nhà để bật nhạc tùy tâm trạng. Để xử lý được khối dữ liệu khổng lồ này thì sẽ cần một nền tảng đủ mạnh như kafka. Tiến tới xa hơn thì kafka hoàn toàn có thể làm xương sống cho việc xử lý big data của các công ty với khả năng xử lý dữ liệu của mình Ngoài 3 usecase chính về streaming message real time, tracking activity và xử lý data, Kafka còn nhiều ứng dụng khác như connect và storage dữ liệu, stream processing vv. Từ khi ra đời tới nay, Kafka đã giúp thay đổi bộ mặt của nhiều ngành nghề cũng như ảnh hưởng lớn tới việc số hóa dữ liệu, quy trình và sản phẩm. Nhưng để thực sự hiểu và dựng được lên một cụm cluster kafka thì một người dùng sẽ phải quan tâm tới nhiều khía cạnh khác như tài nguyên, vận hành, cài đặt cũng như theo dõi sửa lỗi, nâng cấp. Nắm được nhu cầu đó, FPT Smart Cloud cung cấp giải pháp Kafka as a service, đáp ứng được toàn bộ yêu cầu về mặt bảo mật, scaling, high availability, cài đặt, vận hành cũng như có nhiều tính năng bổ trợ để phân quyền, quản lý kafka dễ dàng. Giải pháp FPT Cloud Kafka as a Service sẽ giúp các Developer có thể tự động hóa hoàn toàn việc quản lý, duy trì và mở rộng các cụm Apache Kafka mà không tốn công sức triển khai, dễ dàng quản lý giúp tối ưu chi phí tài nguyên, nguồn lực. Đăng ký sử dụng thử miễn phí ngay: https://fptcloud.com/lien-he/ Nguyễn Quý Hiếu

Khi kiến trúc hệ thống tăng về quy mô và độ phức tạp, các nhóm IT, DevOps phải đối mặt với áp lực ngày càng lớn để theo dõi và ứng phó với các sự cố. Việc có được một hệ thống quan sát tốt là rất quan trọng để đảm bảo rằng hệ thống đang hoạt động ổn định và tối ưu. Vậy Observability là gì? Tại sao nó lại quan trọng và nó có thể giúp các tổ chức đạt được những gì trong thực tế? Hãy cùng FPT Cloud phân tích thông qua bài viết này. Observability là gì? Trong lĩnh vực Công nghệ thông tin và Điện toán đám mây, Observability là khả năng đo lường trạng thái hiện tại của một hệ thống dựa trên dữ liệu mà nó tạo ra, chẳng hạn như logs, metrics và traces. Một hệ thống quá phức tạp có thể bao gồm hàng trăm, thậm chí hàng ngàn máy chủ, dịch vụ và ứng dụng. Các lỗi có thể xuất hiện ở bất kỳ đâu trong hệ thống, việc phát hiện và sửa chúng có thể là một nhiệm vụ khó khăn. Observability giải quyết vấn đề này bằng cách cung cấp các công cụ và kỹ thuật cho phép bạn quan sát hệ thống, xem xét các sự kiện trong quá khứ, theo dõi hiệu suất hiện tại, tìm kiếm, giải quyết các vấn đề kỹ thuật và dự đoán các vấn đề tiềm ẩn trong tương lai. Các tổ chức thường triển khai Observability bằng cách sử dụng kết hợp các phương pháp công cụ đo lường bao gồm các công cụ đo lường mã nguồn mở, chẳng hạn như OpenTelemetry. Nhiều tổ chức cũng áp dụng giải pháp Observability để giúp phát hiện và phân tích tầm quan trọng của các sự kiện đối với hoạt động của họ, với vòng đời phát triển phần mềm, bảo mật ứng dụng và trải nghiệm của người dùng cuối. Tham khảo thêm dịch vụ của FPT đang được quan tâm nhất: Cho thuê máy chủ vật lý Sự khác biệt giữa monitoring và observability? Mặc dù Monitoring và Observability có liên quan đến nhau và có thể bổ sung cho nhau, nhưng thực tế chúng là hai khái niệm khác nhau. Dưới đây là những khác biệt chính:   Monitoring Observability Mục đích Giám sát các yếu tố của hệ thống để phát hiện lỗi, vấn đề, đưa ra cảnh báo Tập trung vào việc giúp quản trị viên và nhà phát triển hiểu rõ hơn về hoạt động của hệ thống, giúp họ phát hiện và giải quyết các vấn đề một cách nhanh chóng và hiệu quả hơn Phạm vi Tập trung vào giám sát các yếu tố định sẵn, thu thập thông tin một cách thụ động, hầu hết trong số đó lại là không quan trọng Tập trung vào việc thu thập các thông tin cần thiết, tập hợp dữ liệu từ nhiều nguồn khác nhau, giúp hiểu được mối tương quan giữa chúng, từ đó nhanh chóng xác định được vấn đề cụ thể Tính linh hoạt  Chưa linh hoạt bằng observability Linh hoạt hơn so với monitoring. Giúp tìm hiểu các thông tin về hệ thống một cách nhanh chóng và dễ dàng hơn, bất kể độ phức tạp của hệ thống. Tại sao observability lại quan trọng? Trong môi trường doanh nghiệp, Observability giúp các nhóm hiểu và trả lời các câu hỏi cụ thể về những gì đang diễn ra trong các hệ thống phân tán. Observability cho phép bạn hiểu những gì chậm hoặc bị lỗi và những gì cần phải làm để cải thiện hiệu suất. Với một giải pháp Observability được thiết lập, các nhóm có thể nhận được cảnh báo về các vấn đề và giải quyết chúng một cách chủ động trước khi chúng ảnh hưởng đến người dùng. Với các hệ thống phân tán, việc hiểu một vấn đề hiện tại là một thách thức to lớn, phần lớn là do nó tạo ra nhiều “ẩn số chưa biết - unknown unknowns” hơn các hệ thống đơn giản hơn. Bởi vì monitoring yêu cầu “những ẩn số đã biết - known unknowns”, nên nó thường không giải quyết được các vấn đề một cách thỏa đáng trong những môi trường phức tạp này. Observability phù hợp hơn với tính không thể đoán trước của các hệ thống phân tán, chủ yếu là vì nó cho phép bạn đặt câu hỏi về hành vi của hệ thống khi có vấn đề phát sinh. “Tại sao X bị lỗi?” hoặc "Điều gì đang gây ra độ trễ?" là một số câu hỏi mà Observability có thể trả lời. Tóm lại, observability là rất quan trọng để đảm bảo các hệ thống phức tạp hoạt động tốt nhất có thể và giảm thiểu các rủi ro liên quan đến hiệu suất, bảo mật, tính sẵn sàng của hệ thống và trải nghiệm người dùng. Observability cung cấp một cái nhìn toàn diện về hành vi và hiệu suất hệ thống, giúp các nhóm nhanh chóng phát hiện, chẩn đoán và giải quyết các vấn đề để cải thiện độ tin cậy và sự hài lòng của người dùng. Các thành phần trong observability Observability bao gồm 3 thành phần chính để giúp quản trị viên, nhà phát triển và các chuyên gia tìm hiểu về hoạt động của hệ thống. Các thành phần này bao gồm: Logs: Đây là những bản ghi văn bản có cấu trúc hoặc không có cấu trúc được ghi lại bởi hệ thống. Chúng bao gồm thông tin về các lỗi, cảnh báo, tình trạng hoạt động, các yêu cầu được xử lý và các hoạt động xảy ra tại một thời điểm cụ thể. Logs là một phần quan trọng trong observability, bởi vì chúng cho phép bạn xem xét các sự kiện trong quá khứ và tìm kiếm nguyên nhân của các vấn đề. Metrics: Đây là các số liệu đo lường về hiệu suất và hoạt động của hệ thống, bao gồm thông tin về tài nguyên sử dụng, lưu lượng truy cập, thời gian phản hồi,... Các metrics được thu thập và lưu trữ liên tục, giúp cho quản trị viên và nhà phát triển theo dõi hoạt động của hệ thống và phát hiện các vấn đề liên quan đến hiệu suất. Traces: Đây là các thông tin về quá trình xử lý các request trong hệ thống. Các traces cho phép bạn theo dõi các request được xử lý thông qua các hệ thống khác nhau trong hệ thống tổng thể. Những lợi ích observability mang lại là gì? Các lợi ích của observability là rất đa dạng và có thể được áp dụng cho nhiều mục đích khác nhau. Dưới đây là một số lợi ích chính của observability: Phát hiện và giải quyết sự cố nhanh chóng: Observability cung cấp một cái nhìn toàn diện về hệ thống, giúp bạn nhanh chóng phát hiện và giải quyết các sự cố. Nâng cao hiệu suất hệ thống: Observability cung cấp thông tin về hiệu suất của hệ thống, giúp người dùng hiểu được tình trạng của hệ thống và đưa ra các quyết định để nâng cao hiệu suất. Gia tăng trải nghiệm người dùng: Công cụ observability giúp xác định các vấn đề có thể ảnh hưởng đến trải nghiệm người dùng và giải quyết chúng để cải thiện sự hài lòng của người dùng. Nâng cao khả năng dự báo: Dữ liệu từ logs, metrics và traces có thể được sử dụng để xác định các xu hướng và mô hình hoạt động của hệ thống. Điều này giúp bạn dự đoán các sự cố tiềm ẩn trước khi chúng xảy ra và đưa ra các biện pháp ngăn chặn trước khi vấn đề trở nên nghiêm trọng. Cải thiện chất lượng sản phẩm: Dữ liệu từ logs, metrics và traces có thể giúp developer kiểm tra, đánh giá chất lượng của mã nguồn, xác định lỗi và điều chỉnh mã nguồn để cải thiện chất lượng của ứng dụng. Cải thiện tính khả dụng của hạ tầng và dịch vụ: Với việc sử dụng observability, các vấn đề có thể được giải quyết nhanh chóng hơn, giúp giảm thời gian chết của hệ thống. Điều này cũng giúp đảm bảo hệ thống được sử dụng đúng cách và đáp ứng được các yêu cầu của người dùng. Những thách thức của observability là gì? Mặc dù observability có nhiều lợi ích, nhưng cũng đem đến một số thách thức trong việc triển khai và sử dụng. Dưới đây là một số thách thức của observability: Khó khăn trong việc xử lý dữ liệu: Dữ liệu observability có thể được thu thập từ nhiều nguồn khác nhau và với khối lượng lớn, do đó việc xử lý dữ liệu có thể trở nên phức tạp. Sự phức tạp của hệ thống: Các hệ thống phức tạp, nhiều phần chạy song song và phụ thuộc vào nhiều dịch vụ khác nhau, điều này làm cho việc giám sát và đo lường trở nên khó khăn hơn. Độ tin cậy của dữ liệu: Để có được kết quả đáng tin cậy, dữ liệu observability phải được thu thập và lưu trữ một cách chính xác và đầy đủ. Nếu dữ liệu không chính xác hoặc thiếu, các kết quả sẽ không có giá trị. Chi phí: Việc triển khai và duy trì các công cụ observability có thể tốn kém, đặc biệt là đối với các hệ thống lớn và phức tạp. Kiến thức chuyên môn: Để triển khai và sử dụng các công cụ observability hiệu quả, người quản lý và phát triển hệ thống cần có kiến thức chuyên môn về các công nghệ, hiểu biết sâu rộng về cách hoạt động của hệ thống. Làm cách nào để triển khai observability? Để triển khai observability hiệu quả, bạn cần có công cụ thích hợp cho các hệ thống và ứng dụng của mình để thu thập dữ liệu. Bạn có thể tạo một hệ thống có thể quan sát được bằng cách xây dựng các công cụ của riêng mình, sử dụng phần mềm mã nguồn mở hoặc mua giải pháp observability thương mại. Thông thường, có bốn thành phần liên quan đến việc triển khai observability: Thiết bị đo đạc (Instrumentation): Đây là những công cụ đo lường thu thập dữ liệu từ container, service, ứng dụng, máy chủ và bất kỳ thành phần nào khác trong hệ thống của bạn, cho phép hiển thị trên toàn bộ cơ sở hạ tầng của bạn. Tương quan dữ liệu (Data correlation): Dữ liệu được thu thập từ các hệ thống của bạn sẽ được xử lý và tạo mối tương quan, điều này cho phép bạn quản lý dữ liệu tự động hoặc tùy chỉnh để trực quan hóa dữ liệu. Ứng phó sự cố (Incident response): Các công nghệ tự động hóa và quản lý sự cố nhằm mục đích chuyển dữ liệu về sự cố cho đúng người và nhóm dựa trên on-call schedules và khả năng kỹ thuật. AIOps: Các mô hình Machine learning được sử dụng để tự động tổng hợp, tương quan và ưu tiên dữ liệu sự cố, cho phép bạn lọc nhiễu cảnh báo (alert noise), phát hiện các sự cố có thể ảnh hưởng đến hệ thống và tăng tốc ứng phó sự cố khi chúng xảy ra. Kết luận Bài viết đã giới thiệu về các thành phần cơ bản của observability, tầm quan trọng, lợi ích của việc áp dụng observability. Chúng ta có thể kết luận rằng observability là một khái niệm quan trọng trong lĩnh vực quản lý và giám sát hệ thống. Nó cho phép chúng ta quan sát và hiểu được các hoạt động và hiệu suất của hệ thống, từ đó giúp phát hiện và giải quyết các vấn đề một cách nhanh chóng và hiệu quả hơn. Tuy nhiên, để áp dụng observability thành công, người sử dụng cần phải có kiến thức chuyên môn về hệ thống mà họ đang quan sát, hiểu về các công cụ quan sát và phân tích dữ liệu để có thể đưa ra những quyết định đúng đắn. Với sự phát triển của công nghệ và sự phổ biến của các hệ thống phân tán, observability đang trở thành một yếu tố quan trọng trong việc quản lý, đảm bảo chất lượng và sự ổn định của hệ thống phần mềm. Liên hệ với chúng tôi để biết thêm thông tin chi tiết về dịch vụ của FPT Smart Cloud Website: https://fptcloud.com/ Fanpage: https://www.facebook.com/fptsmartcloud Email: [email protected] Hotline: 1900 638 399

Có lẽ thời gian gần đây khái niệm Serverless đã không còn xa lạ gì với những tín đồ công nghệ và cả những doanh nghiệp đang thực hiện quá trình chuyển đổi số. Thế thì Serverless thực chất là gì? Những đặc điểm nổi bật của nền tảng này? Tiện ích nền tảng mang lại là gì? Và phương pháp để các cá nhân, tổ chức có thể tiếp cận cũng như áp dụng serverless? Hãy cùng FPT Cloud phân tích thông qua bài viết này. [caption id="attachment_35539" align="aligncenter" width="2500"] Phương pháp triển khai ứng dụng qua từng giai đoạn[/caption] Lịch sử các phương pháp triển khai, vận hành ứng dụng Trước khi đi vào phân tích về serverless. Hãy cùng nhìn lại một vài nét về quá trình phát triển của phương pháp triển khai và vận hành một ứng dụng. Từ thời đại của hạ tầng vật lý, ứng dụng được triển khai trực tiếp lên hệ điều hành của một máy chủ, mô hình này sẽ đòi hỏi nhiều tài nguyên để vận hành cũng như việc đầu tư thiết bị đắt tiền cùng hàng loạt những vấn đề mà người quản trị phải giải quyết như sao lưu/phục hồi, lãng phí tài nguyên, đảm bảo tính sẵn sàng, mở rộng và bảo mật cho ứng dụng. Hệ thống ảo hoá ra đời đã giải quyết hầu như triệt để những vấn đề của mô hình vật lý. Hàng loạt những công nghệ ảo hoá ra đời và hiện nay vẫn đang được dùng rất nhiều như VMware, KVM, Xen, HyperV… Bằng việc phân tách một máy vật lý ra thành nhiều máy ảo chạy hệ điều hành độc lập sẽ tận dụng được nhiều tài nguyên hơn. Ngoài ra, các nền tảng ảo hoá còn có nhiều tính năng như mở rộng linh hoạt, sao lưu/khôi phục, snapshot, live-migrate, khả năng HA các máy ảo trong cụm vật lý… giúp ứng dụng được triển khai một cách đáng tin cậy hơn so với mô hình vật lý. Ảo hoá ngày nay vẫn là một công nghệ đang hot, các hãng tận dụng công nghệ này và phát triển thêm hàng loạt những dịch vụ đi kèm, tổ hợp thành các Public/Private Cloud mà ta đang sử dụng ngày nay. Tuy vậy, việc triển khai ứng dụng trên VM khá cồng kềnh gồm cả OS, middle layer (thư viện, runtime,…), app gây khó khăn cho các team phát triển về việc quản lý version, môi trường triển khai, đóng gói, time-to-market. Vì vậy mà container ra đời giúp các nhà phát triển đóng gói nhanh chóng ứng dụng trong một container image, triển khai container lại vô cùng nhanh chóng đi kèm khả năng tương thích với hầu hết hệ điều hành. Với kiến trúc phức tạp và xu thế ngày nay như microservice, CI/CD, GitOps container hầu như trở thành yếu tố bắt buộc phải có. Qua phân tích trên ta thấy rằng công nghệ triển khai ứng dụng thay đổi theo từng thời kỳ đều tuân theo quy luật tiện dụng, nhanh chóng, khả năng mở rộng, chịu lỗi tốt. Chính vì thế mà container đã bùng nổ như một cơn sốt công nghệ, đạt CAGR 30.8% năm 2017-2022 và sẽ còn tiếp tục tăng trưởng những năm sắp tới, nhiều doanh nghiệp đang chuyển đổi số hoặc trong giai đoạn phát triển ứng dụng mới đều sẽ tận dụng những tiện nghi của công nghệ microservice, container để giúp sản phẩm của họ nhanh chóng được đưa đến người dùng (tối ưu time-to-market), tiết kiệm đáng kể chi phí hạ tầng và nhân sự vận hành quản trị. [caption id="attachment_35540" align="aligncenter" width="1920"] Báo cáo thị trường container – Theo 451 Research[/caption] Tuy rằng có nhiều tiện ích trong việc phát triển ứng dụng nhưng chúng ta cần phải nhìn nhận rằng container nói chung hay Kubernetes nói riêng (công cụ quản trị, phân bố, tự động hoá trong triển khai container) vẫn còn nhiều điểm khó tiếp cận đến người dùng như: Vận hành quản trị: Đòi hỏi nhiều kỹ năng như network, system, develop, logging, monitoring,… Yêu cầu bảo mật cao cho ứng dụng container. Rất phức tạp cho người mới. Cần lựa chọn vendor cung cấp dịch vụ uy tín hoặc tự triển khai. Vấn đề về giải pháp lưu trữ dài hạn cho container. [caption id="attachment_35541" align="aligncenter" width="975"] Xếp hạng những khó khăn trong sử dụng Kubernetes (container) – Theo TheNewStack[/caption] Serverless – Xu thế tất yếu của điện toán đám mây Nhận định trên đưa ta đến một kết luận về sự ra đời tất yếu của nền tảng mới mà ở đó nhà phát triển ứng dụng sẽ chỉ cần tập trung vào việc coding, hoạch định bài toán kinh doanh còn lại toàn bộ hạ tầng đều được nhà cung cấp dịch vụ quản lý. Đó chính là công nghệ “Serverless”, serverless không có nghĩa là không cần máy chủ server để hoạt động, mà nó mang ý nghĩa trừu tượng về cách thức sử dụng, thực ra những máy chủ này đã được quản lý bởi nhà cung cấp dịch vụ (cloud provider) bao gồm hạ tầng, DC, network, storage, security, platform, auto-scale để người phát triển ứng dụng chỉ cần đẩy code lên để chạy, đồng thời chỉ chi trả cho những tài nguyên được tiêu thụ trong thời gian xử lý request. Việc này giúp tiết kiệm hơn rất nhiều so với mô hình cloud VM hoặc sử dụng dịch vụ Kubernetes đều phải trả chi phí hàng tháng dù tài nguyên có được sử dụng hoặc idle. Trong mô hình cung cấp dịch vụ của điện đoán đám mây, serverless được xếp vào lớp Function as a service (FaaS) – trong một số tài liệu vẫn xếp serverless vào lớp Platform as a service (PaaS) về bản chất FaaS hay PaaS đều cung cấp công cụ cho người dùng ở lớp nền tảng phát triển Application. Dịch vụ điển hình của PaaS như fully-managed kubernetes hoặc database engine cho phép người dùng sử dụng để triển khai (deploy) ứng dụng với một vài lượt nhấp hoặc kéo thả, tuy nhiên sẽ vẫn phải cần có kiến thức về DB hoặc K8S để thực hiện các task của DBA hoặc Devops khi cần triển khai ứng dụng. Còn đối với FaaS người dùng chỉ cần phát triển code để xử lý nghiệp vụ ứng dụng và hầu như không cần sự can thiệp về mặt hệ thống khi triển khai và vận hành. Bảng dưới đây so sánh sự khác nhau đặt trưng của IaaS, PaaS và FaaS: IaaS PaaS FaaS Unit of development Operating System Application Functions Provides VM package with OS Dev platform Execute code on-demand Abstracts Physical server OS & middleware Programing runtime [caption id="attachment_35542" align="aligncenter" width="1200"] Model FaaS giữ vị trí giữa PaaS và SaaS[/caption] Hiện nay trên thị trường serverless có lẽ chúng ta đã quá quen với những cái tên lớn như AWS Lamda, Azure Functions, Google Cloud Functions, các nền tảng này được áp dụng rộng rãi với nhiều câu chuyện thành công được chia sẻ. Ở phân khúc mã nguồn mở của serverless, những nền tảng có cộng đồng lớn có thể kể đến như KNative, OpenFaaS, Apache OpenWhisk, Kubeless, fission. Để hiểu rõ hơn ưu thế của serverless chúng ta cùng điểm qua một số tiện tích cốt lõi của serverless mang lại: Được quản trị hoàn toàn (fully managed): Các nhà phát triển sẽ không phải bận tâm về hạ tầng nữa. Dịch vụ serverless được cloud provider quản trị toàn bộ phần hạ tầng, hệ điều hành, middleware, runtime của ngôn ngữ lập trình và các module liên quan. Kiến trúc event-driven: Một trong những yếu tố then chốt trong microservice để giải quyết bài toán decoupling và phân tán. Các nền tảng serverless đều có cơ chế để được gọi thực thi khi xảy ra sự kiện từ hệ thống (e.g AWS Lamda được trigger khi có sự kiện trên dịch vụ notification SNS). Mở rộng không giới hạn (scale-out): Tận dụng lợi thế hạ tầng sẵn có của cloud provider, giúp người dùng dễ dàng mở rộng ứng dụng ứng dụng theo lượng tải đột biết hoặc giảm về 0 khi không được sử dụng. Tính sẵn sàng cao (high availability): Bản chất của serverless được cung cấp trên nền tảng hạ tầng kế thừa của cả mức IaaS và PaaS do đó khả năng HA đã được tích hợp sẵn bên trong. Less-Ops: Một số thao tác vận hành vẫn có ở serverless như database, debugging, testing,… trong môi trường container shell. Ngoài ra, kiến trúc serverless sẽ sử dụng một số dịch vụ đi kèm của cloud như Database Engine, Message Queue Engine, Monitor/Alert, Vault Engine,… giúp hạn chế tối đa thao tác vận hành. Tối ưu hoá chi phí: Chỉ chi trả cho lượng tài nguyên xử lý khi có request hoặc event và sẽ không mất phí khi ứng dụng rảnh rỗi (idle). Việc này tối ưu hơn rất nhiều so với chúng ta chạy VM và phải trả một chi phí cố định hàng giờ. No vendor lock-in: Với cùng một mã nguồn của nhà phát triển có thể triển khai được trên nhiều dịch vụ serverless của các nhà cung cấp khác nhau. Ngoài ra, khả năng tương thích này còn giúp quá trình dịch chuyển dịch vụ một cách nhanh chóng. Một số dịch vụ điển hình ứng dụng công nghệ serverless triển khai có thể kể đến như sau: Ứng dụng web: Static website, webapps, micro frontend, common framework flask/django/spring/fastapi,… Ứng dụng backend: Backend app/service, backend mobile, IoT edge,… Xử lý dữ liệu: Real-time data processing, Map reduce, batch processing, stream processing, ML inference,… Tác vụ tự động hoá IT: policy engine, infrastructure management,… Bên cạnh những tiện ích vượt trội, không phải ứng dụng IT nào cùng có thể triển khai trên nền tảng serverless. Để xác định ứng dụng doanh nghiệp của bạn có phù hợp để triển khai serverless hay không chúng ta có thể xét qua 07 tiêu chí dưới đây: 1. Ứng dụng stateless: Những tài nguyên phát sinh trong quá trình thực hiện một request sẽ mất sau khi kết thúc request đó. Việc này cần lưu ý đối với những ứng dụng cần giữ session trong phiên giao dịch, cần có thiết kế lưu trữ ở DB hoặc cache trong dịch vụ trước khi kết thúc chu trình. 2. Tính chất ephemeral: Bản chất của serverless hoạt động trên nền container, do đó tất cả dữ liệu file được ghi trên container này sẽ bị xoá đi khi container không còn tồn tại do quá trình auto-scale. 3. Hỗ trợ ngôn ngữ: Không phải nền tảng serverless nào cũng hỗ trợ đầy đủ ngôn ngữ lập trình, nên việc lựa chọn nền tảng thống nhất để đáp ứng toàn bộ ngôn ngữ lập trình cho dự án của bạn cũng rất quan trọng. 4. Chỉ duy trì khi hoạt động: Một số nền tảng sẽ giảm số lượng container về 0 khi dịch vụ không hoạt động (idle) quá lâu. Điều này sẽ ảnh hưởng đến việc khi cần sử dụng ứng dụng sẽ mất thời gian để khởi động lại gây ảnh hưởng đến trải nghiệm. Nên thiết kế để dịch vụ luôn có ít nhất một thành phần sẵn sàng nhận request hoặc chạy keep-alive dịch vụ. 5. Cơ sở dữ liệu: Sử dụng serverless với cơ sở dữ liệu quan hệ (relational database) sẽ có nhiều hạn chế do cơ chế giới hạn concurrent connection của DB, nên việc lựa chọn NoSQL trong serverless sẽ có nhiều lợi thế hơn. 6. Không cho phép truy tập file system: Như tính chất stateless và ephemeral của serverless kể trên, việc ứng dụng sử dụng config từ file system hoặc ghi dữ liệu ra tệp tin sẽ không được hỗ trợ như sử dụng Cloud VM. 7. Logging & Monitoring: Mỗi nền tảng serverless sẽ có cơ chế lấy log cũng như khả năng giám sát giới hạn các thông tin có thể cung cấp đồng nghĩa với việc không thể tận dụng cũng như tích hợp được với các phần mềm có sẵn của người dùng. Hiện tại các nhà phát triển, doanh nghiệp đã có thể dễ dàng đăng ký cũng như sử dụng, trải nghiệm công nghệ Serverless của các nhà cung cấp cloud nước ngoài như AWS, Azure, Google Cloud. Đối với các nhà cung cấp cloud trong trước hiện tại vẫn chưa có đơn vị cung cấp dịch vụ serverless nên việc trải nghiệm sẽ còn hạn chế, thay vào đó bạn vẫn hoàn toàn có thể tự triển khai riêng cho mình một hệ thống serverless local dựa trên các dịch vụ có sẵn của nhà cung cấp trong nước. Dưới đây là một ví dụ tham khảo việc triển khai nền tảng serverless sử dụng mã nguồn OpenFaaS - mã nguồn mở cho phép triển khai hệ thống serverless với các tính năng cơ bản đáp ứng mức production ready (https://www.openfaas.com). Chuẩn bị hạ tầng: o Sử dụng Cloud Virtual Machine để tự triển khai Docker, Kubernetes bằng các công cụ như Rancher, Kuberspray, kubeadm, openshift,… tuy nhiên sẽ tương đối phức tạp cần có nhiều kiến thức để triển khai và vận hành hiệu quả. o Phương án sử dụng dịch vụ cloud có cung cấp sẵn nền tảng Managed Kubernetes – FPT Kubernetes Engine (FKE) của FPTCloud là một dịch vụ điển hình, bạn có thể tham khảo thêm tại đây. Triển khai dịch vụ Serverless: o Tham khảo hướng dẫn triển khai trên nền K8s tại đây. Cấu hình expose dịch vụ: o Đối với phương án tự triển khai trên virtual machine bước này sẽ cần bạn phải triển khai thêm dịch vụ LB trên K8s như MetalLB, Cilium,… và ingress controller như nginx, traefik, haproxy,… o Với cách sử dụng dịch vụ managed Kubernetes thì loadbalancer và ingress đã được tích hợp sẵn ở mức hạ tầng, bạn chỉ cần expose service ở tầng dịch vụ K8s, nhà cung cấp dịch vụ Cloud sẽ tự động hoá hoàn toàn các bước. Sau đó bạn chỉ cần truy cập từ domain đã khai báo ở phần cài đặt trên và trải nghiệm. [caption id="attachment_35543" align="aligncenter" width="2403"] Mô hình triển khai Serverless in-house[/caption] Kết luận Ngày nay, với sự bùng nổ trong nền công nghiệp 4.0, hàng loạt những công nghệ mới ra đời nhằm đáp ứng được nhu cầu ngày càng cao của con người. Xuyên suốt bài viết chúng ta đã sơ lược qua quá trình phát triển của lĩnh vực điện toán và sự xuất hiện tất yếu của nền tảng Serverless. Chúng ta cũng đã định hình được vị trí của FaaS trong mô hình cung cấp dịch vụ của điện toán đám mây cũng như đã liệt kê ra được những lợi ích và hạn thế mà nền tảng này mang lại, đồng thời đưa ra những ứng dụng cụ thể của serverless trong việc phát triển phần mềm. Vẫn còn quá sớm để có thể kết luận được serverless có thể hoàn toàn thay thế được toàn bộ workload IT trong tương lai hay không, do về cơ bản, bản thân cơ chế hoạt động, lưu trữ của serverless chưa phù hợp cho các ứng dụng đặc thù, ứng dụng cơ sở dữ liệu, ứng dụng cần tính toán lớn,… Tuy nhiên với vị trí của một công nghệ mới nổi (emerging technology) cùng với những tính chất vượt trội như tối ưu hoá chi phí hạ tầng/vận hành, tối ưu time-to-market, nhanh chóng và đảm bảo; serverless hoàn toàn có thể là một công nghệ được sử dụng nhiều nhất trong thời gian sắp tới ở thời đại của microservice, edge computing. Trần Quốc Sang – Senior Cloud Engineer, FPT Smart Cloud

Bà Điệp khẳng định FRT sẽ tiếp tục mở mới 400-500 cửa hàng Long Châu trong năm 2023. Sau dược phẩm, FRT có thể nhắm đến một số ngành bán lẻ vừa triển vọng lại an toàn như ăn uống, hàng tiêu dùng, mẹ và bé… "Trước khi tham gia, chúng tôi mới chỉ nhìn thấy mảng thị trường nhà thuốc còn manh mún, nhỏ lẻ, chưa thấy ai mang lại dịch vụ chuyên nghiệp cho khách hàng nhưng khi nhập cuộc, chúng tôi nhận thấy có một số thứ có thể thay đổi, góp ích cho nền dược phẩm nước nhà và đó chính là con đường dài để Long Châu tiếp bước", bà Nguyễn Bạch Điệp – Chủ tịch FPT Retail, Tổng giám đốc FPT Long Châu chia sẻ. Trong năm 2022, Long Châu đạt được những cột mốc cực kỳ ấn tượng gồm đạt mốc 1.000 cửa hàng, 5 triệu khách hàng đến mua sắm/tháng; hơn 2,5 triệu khách hàng mua sắm trên nền tảng trực tuyến/ tháng trong khi ứng dụng Nhà thuốc FPT Long Châu cũng cán mốc hơn 2 triệu người dùng sau 1 năm ra mắt. Với Long Châu nói riêng và FPT Retail nói chung, 2023 sẽ là một năm như thế nào? Tôi cho rằng khó khăn có thể tiếp tục kéo dài đến giữa năm sau, thậm chí là hết năm. Với tình hình đó, người dân sẽ thắt chặt chi tiêu, tập trung vào các mặt hàng thiết yếu hơn. Đứng trước tình hình khó khăn này, FPT Long Châu càng chú trọng mục tiêu mở rộng, đến gần hơn nữa với người dân để mang đến những sản phẩm chất lượng với giá thật rẻ. FPT Long Châu sẽ vẫn là động lực tăng trưởng của FRT trong thời gian tới. Chúng tôi sẽ tiếp tục mở rộng chuỗi, dự kiến sẽ mở thêm 400-500 cửa hàng trong năm 2023. FRT cũng sẽ tiếp tục chuyển đổi số mạnh mẽ, ứng dụng công nghệ vào hoạt động của cả 2 chuỗi FPT Shop và FPT Long Châu nhằm gia tăng trải nghiệm khách hàng. Long Châu đã bứt lên rất nhanh trong năm 2022, đâu là động lực cho điều này? FPT Retail đã nhìn ra được điều gì ở bức tranh thị trường bán lẻ dược phẩm Việt Nam? Nói về động lực, thứ nhất, việc mở mới số cửa hàng Long Châu vượt kế hoạch có thể nói là như đang ở đà tiến lên. Trong quá trình triển khai, công ty nhận được sự hỗ trợ lớn của Tập đoàn về mặt công nghệ, nhiều quy trình được tự động hoá. Khi đi vào guồng thì sự phối hợp giữa các bộ phận, phòng ban nhuần nhuyễn hơn. Vì vậy, Long Châu quyết định tăng tốc luôn. Động lực thứ hai là FPT Retail nhìn thấy tiềm năng từ thị trường. Ở Việt Nam, số lượng các nhà thuốc nhỏ lẻ lên tới gần 60.000, vì vậy dư địa để mở rộng chuỗi Long Châu còn rất lớn. Đặc biệt là ở những nơi vùng sâu, vùng xa, người dân còn ít tiếp cận với các cửa hàng thuốc đầy đủ nhóm sản phẩm. Con số 1.000 gần như chốt cho năm 2022 nhưng chúng tôi sẽ không dừng lại. Chiến lược mở rộng vẫn là chiến lược chính trong năm 2023 với dự kiến mở mới 400-500 cửa hàng. Theo số liệu của Tổng cục Thống kê, dân số Việt Nam đang già đi với tốc độ gia tăng, kết hợp với tỷ lệ sinh thấp sẽ dẫn đến tỷ lệ người già trên 65 tuổi vào năm 2055 tăng cao. Trong khi đó, Quỹ tiền tệ quốc tế IMF đã dự báo, đến năm 2025, Việt Nam sẽ vươn lên đứng thứ 3 Đông Nam Á về quy mô kinh tế, với mức GDP chỉ xếp sau Indonesia và Thái Lan, vượt qua Malaysia, Philippines và Singapore. Mức sống nâng cao và cơ cấu dân số già được dự báo sẽ khiến cho người dân ngày càng chú trọng tới việc nâng cao sức khỏe và chi tiêu nhiều hơn cho các sản phẩm thực phẩm chức năng, sản phẩm chăm sóc sức khỏe và vật tư y tế, đồng thời có khuynh hướng sử dụng các sản phẩm dược mỹ phẩm với tiêu chí an toàn cho sức khỏe. Với Long Châu, trước khi tham gia, chúng tôi mới chỉ nhìn thấy mảng thị trường nhà thuốc còn manh mún, nhỏ lẻ, chưa thấy ai mang lại dịch vụ chuyên nghiệp cho khách hàng. Còn khi nhập cuộc, chúng tôi nhận thấy có một số thứ có thể thay đổi, góp ích cho nền dược phẩm nước nhà và đó chính là con đường dài để Long Châu tiếp bước. Đầu tiên là thuốc chính hãng, được kiểm soát chất lượng, với các chuỗi có hệ thống phần mềm hỗ trợ. Thứ hai là giá thành, việc quản trị bằng phần mềm tối ưu chi phí sẽ giúp hạ giá thành sản phẩm, người dân cũng được hưởng lợi. Và một điều mà tôi nghĩ rất quan trọng là đào tạo nhân viên, tư vấn khách hàng cách uống thuốc đúng, đủ, tránh lạm dụng kháng sinh. Với FPT Shop hay F.Studio trước đây, có thể thấy tốc độ mở mới cửa hàng không quá nhanh nhưng Long Châu là một câu chuyện hoàn toàn khác? Có phải đã có một sự thay đổi trong chiến lược kinh doanh của FPT Retail? Đầu tiên cần kể đến là quyết tâm làm và phải làm được của ban lãnh đạo và sự đồng lòng của CBNV. Kế đến, có thể nói, kinh nghiệm về xây dựng và phát triển chuỗi bán lẻ FPT Shop đã đem lại rất nhiều lợi thế cho FRT khi phát triển chuỗi dược. Khi mở rộng chuỗi Long Châu thì FRT đã chuyển nguồn lực từ FPT Shop sang. Ngoài ra, FRT còn được hỗ trợ thêm nguồn lực tài chính và công nghệ từ Tập đoàn FPT. Ngoài ra, chúng tôi phân công rõ ràng nhiệm vụ từng người. Tại FRT, người nào giữ trận, người nào mở cõi đều được xác định rõ, điều này giúp Công ty duy trì và tăng trưởng ở mảng cũ cũng như mở rộng được mảng mới. Long Châu lấy gì làm lợi thế cạnh tranh với các đối thủ (cửa hàng nhỏ, các hệ thống lớn khác)? FPT Long Châu được đánh giá có định hướng và vận hành đúng với ngành bán lẻ dược phẩm, chuyên về thuốc nhất, sở hữu danh mục sản phẩm đa dạng, đầy đủ nhóm thuốc chất lượng phục vụ người dân. Điều này cho phép Long Châu đáp ứng đủ nhất nhu cầu ngày càng cao về nhu cầu thuốc điều trị bệnh, đặc biệt là thuốc theo đơn bệnh viện các loại thuốc hiếm. Thứ nữa, FPT Long Châu thừa hưởng từ Tập đoàn FPT về phần công nghệ, từ quản trị cửa hàng giúp tối ưu hoá chi phí đến công nghệ phục vụ cho trải nghiệm khách hàng. Chúng ta thấu hiểu khách hàng bao nhiêu thì họ sẽ hài lòng bấy nhiêu. Về lâu dài, Long Châu còn mong muốn chuỗi nhà thuốc sẽ đưa thêm nhiều dịch vụ chăm sóc sức khoẻ tới khách hàng chứ không chỉ là thuốc. Đó chính là khai thác phần trên thượng tầng của lĩnh vực dược phẩm giúp mang lại hiệu quả tăng trưởng lâu bền. Năm 2022, An Khang của TGDĐ đã xác định dừng mở mới ở mốc hơn 500 cửa hàng, trong khi Long Châu đã mở cửa hàng thứ 1.000, khác biệt ở đây là gì? Như đã đề cập, việc mở mới số cửa hàng Long Châu vượt kế hoạch có thể nói là như đang ở đà tiến lên. Trong quá trình triển khai, công ty nhận được sự hỗ trợ lớn của Tập đoàn về mặt công nghệ, nhiều quy trình được tự động hoá. Tất cả những ứng dụng CNTT trong quản trị vận hành đã giúp chuỗi nhà thuốc FPT Long Châu nhanh chóng mở rộng quy mô lên đến 1.000 nhà thuốc trên toàn quốc trong thời gian ngắn. Khi đi vào guồng thì sự phối hợp giữa các bộ phận, phòng ban nhuần nhuyễn hơn. Vì vậy, Long Châu quyết định tăng tốc luôn. Ngoài ra, trong năm 2022, với mục tiêu "mọi hoạt động đều hướng đến khách hàng" được FPT Long Châu vinh dự khi được trao cơ hội phục vụ hơn 5 triệu khách hàng đến chuỗi nhà thuốc mua sắm/ tháng; hơn 2,5 triệu khách hàng mua sắm trên nền tảng trực tuyến/ tháng và hơn 4,2 triệu khách hàng thân thiết luôn đồng hành, tin tưởng lựa chọn trong suốt hành trình phát triển bền vững và đột phá đạt mốc 1.000 nhà thuốc của Long Châu. Trong tháng 12, ứng dụng Nhà thuốc FPT Long Châu chính thức cán mốc hơn 2 triệu người dùng sau 1 năm ra mắt. Đây là phiên bản ứng dụng hiện đại đã được Long Châu cập nhật giúp thân thiện với người dùng, là lựa chọn tối ưu cho khách hàng có thể thực hiện mua sắm các sản phẩm chăm sóc sức khỏe trực tuyến một cách thuận tiện, nhanh chóng nhất và được miễn phí giao hàng trong 3 giờ. Với Long Châu, người ta nhắc nhiều đến "công nghệ hóa chuỗi bán lẻ", bà có thể chia sẻ cụ thể hơn về việc Long Châu đã công nghệ hóa như thế nào? Chuyển đổi số trong bối cảnh số hóa đang là xu thế tất yếu của mọi doanh nghiệp, FPT Long Châu tự hào khẳng định uy tín và chất lượng đằng sau vẻ ngoài của một nhà thuốc truyền thống đã ứng dụng công nghệ thành công với những giải pháp tiên tiến như ứng dụng bán hàng tự động tại điểm bán, hệ thống quản trị logistic giao nhận hàng hoá, hệ thống quản trị tồn kho realtime,... Cụ thể, FPT Retail chuyển đổi thần tốc hệ thống bán hàng: từ POS, SAP truyền thống sang OMS hiện đại và có tính linh hoạt cao hơn. FRT đã đưa toàn bộ hệ thống bán lẻ lên cloud trong thời gian nhanh nhất với dự án thế kỷ "phóng Công ty tỷ đô lên mây", ứng dụng AI thành công trong công thức chia hàng hóa về shop giúp giảm 50% số lượng trường hợp bị stock-out tại cửa hàng. Tất cả những ứng dụng CNTT trong quản trị vận hành đã giúp chuỗi nhà thuốc FPT Long Châu nhanh chóng mở rộng quy mô lên đến 1.000 nhà thuốc trên toàn quốc trong thời gian ngắn. Chuyển đổi số thành công không chỉ giúp tiết giảm chi phí hoạt động sản xuất kinh doanh, tối ưu hóa năng suất mà còn giúp chúng tôi nuôi dưỡng tinh thần đổi mới, sáng tạo, xây dựng nền tảng văn hóa số trong tổ chức và hình thành nguồn nhân lực tài năng - nguồn tài nguyên chiến lược để phát triển bền vững trong nền kinh tế số. Ứng dụng công nghệ số hóa vào hoạt động của chuỗi Nhà thuốc FPT Long Châu là bước tiến vượt bậc và nỗ lực của công ty FRT nói riêng và cả Tập đoàn FPT nói chung trên hành trình sứ mệnh chăm sóc sức khỏe hàng triệu người dân Việt Nam bằng dịch vụ vượt trội, nhanh chóng và tiện lợi. Theo bà, đâu là yếu tố quyết định để Long Châu bứt phá trong 2 năm qua và cả các năm tới? Để FPT Long Châu có được chỗ đứng hiện tại là sự tổng hoà của nhiều yếu tố, có 3 cái chính: Thứ nhất, đó là quyết tâm làm và phải làm được của ban lãnh đạo và sự đồng lòng của CBNV. Thứ hai, kinh nghiệm về xây dựng, vận hành và phát triển chuỗi bán lẻ FPT Shop đã được mang sang chuỗi dược. Thứ ba, nguồn lực sẵn có từ FPT Shop. Khi mở rộng chuỗi Long Châu thì FRT đã chuyển nguồn lực từ FPT Shop sang. Ngoài ra, FRT còn được hỗ trợ thêm nguồn lực tài chính và công nghệ từ Tập đoàn FPT. Với sự hậu thuẫn mạnh mẽ từ "người khổng lồ" FPT - tập đoàn công nghệ hàng đầu Việt Nam, FPT Long Châu sẽ tiếp tục bứt phá dẫn đầu trên hành trình chuyển đổi số, đưa tự động hóa vào quá trình vận hành và tiến tới tự động hóa hoàn chỉnh nhằm khai thác hiệu quả nhất nguồn lực trong lĩnh vực chuỗi bán lẻ dược phẩm nói riêng và ngành Thương mại điện tử nói chung, đáp ứng nhu cầu với chất lượng phục vụ và trải nghiệm tốt nhất cho mọi khách hàng khắp Việt Nam. Long Châu nhìn thấy những điểm đặc thù nào của thị trường bán lẻ dược phẩm Việt Nam? Tại Việt Nam, thị trường bán lẻ dược phẩm có tính phân mảnh rất cao, với gần 60.000 nhà thuốc nhưng hầu hết là cơ sở kinh doanh nhỏ lẻ. Về thói quen của khách hàng, thông thường, khi gặp phải một số triệu chứng bệnh phổ thông như ho, sốt, đau bụng nhẹ,... người tiêu dùng Việt Nam thường có xu hướng tới các nhà thuốc quen thuộc để hỏi dược sĩ và mua thuốc. Trong đó, các tiêu chí được người tiêu dùng sử dụng khi lựa chọn mua thuốc như: Vị trí địa lý nhà thuốc, chất lượng thuốc, giá cả,... Cùng với đó là một số yếu tố để giữ chân người mua như: trình độ chuyên môn của dược sĩ đứng quầy, quá trình tư vấn, chăm sóc sau mua,... Ngoài ra, sau đại dịch Covid-19, hình thức mua hàng cũng đã trở thành một trong những căn cứ quan trọng của người tiêu dùng khi lựa chọn nhà thuốc. Các hình thức đặt hàng online, giao hàng tận nhà, tư vấn online,... trở thành ưu điểm trong mắt khách hàng nhờ vào tính tiện lợi, linh động, tiết kiệm thời gian,... Một số sản phẩm "mùa vụ" trong dịp Covid như laptop, smartphone (các thiết bị phục vụ nhu cầu học tập online, kết nối), dịch vụ Internet đều gặp tình trạng khủng hoảng thừa sau Covid, bà đánh giá thế nào về thị trường thuốc - sản phẩm cũng đã tăng vọt nhu cầu trong đại dịch? Về xu thế, khi đại dịch qua đi, nhóm sản phẩm chống dịch chắc chắn bị khủng hoảng thừa. Tuy nhiên, do đã ứng dụng công nghệ AI vào việc nhập hàng, nên FPT Long Châu vẫn kiểm soát được lượng hàng vào ra hợp lý, không bị ảnh hưởng nhiều. FPT Retail từng nói sẽ mở vài ngàn nhà thuốc trong 3 năm tới, FPT Retail sẽ tiến hành việc này như thế nào? Với FRT, khi tìm được công thức thành công thì chúng tôi mới dám mở rộng. FPT Retail đang hoạt động dưới sự giám sát của Tập đoàn và nhà đầu tư trên các KPI về doanh thu và lợi nhuận. Điều đó cũng có nghĩa là công ty đang rất quan tâm và quản lý chặt chẽ hiệu quả khi mở mới nhà thuốc, luôn cân bằng giữa cam kết với cổ đông và mở rộng thị phần. Về mặt quản trị thì mở 200, 300 hay 1.000 cửa hàng đều như nhau. Một phần mềm viết ra sẽ quản lý chi tiết đến từng mật mã hàng hoá, từng loại thuốc đến từng shop... Nhờ hệ thống phần mềm đó mà có thể nhìn tổng thể bức tranh về tài chính để theo dõi các chỉ số kinh doanh một cách tốt nhất, khu vực nào ổn, khi vực nào không ổn. FPT Retail có ý định rời xa ngành bán lẻ hay không? Sau dược phẩm, đích ngắm tiếp theo của FPT Retail là gì? FPT Retail định hướng trở thành công ty Bán lẻ đa ngành, chúng tôi đặt mục tiêu sẽ cung ứng tất cả các sản phẩm phục vụ đa dạng nhu cầu của khách hàng, len lỏi vào đời sống của tất cả người dùng Việt Nam. Năng lực cốt lõi của một công ty bán lẻ là xây dựng chuỗi bán lẻ và quản trị nó. Vì vậy không quan trọng là bạn bán cái gì mà bạn có năng lực cốt lõi đó hay không. Như FPT Retail, từ công nghệ chuyển sang một lĩnh vực không liên quan là dược phẩm, ban đầu mọi người cũng lo lắng, không có chuyên thì làm sao tham gia vào thị trường y tế? Nhưng cuối cùng chúng tôi cũng đã làm được vì đã có kinh nghiệm từ xây dựng chuỗi công nghệ. Tương lai, FPT Retail chắc chắn sẽ không dừng lại ở hai ngành nghề đang có. Các lĩnh vực bán lẻ có triển vọng lớn lại vừa an toàn là những sản phẩm thiết yếu như ăn uống, đồ tiêu dùng, mẹ và bé, siêu thị, giáo dục... Đây là những nhu cầu lặp đi lặp lại mỗi ngày, thường xuyên gắn với đời sống của một gia đình nên ở thời kỳ nào cũng sẽ tăng trưởng, phát triển tốt. Theo CafeF  

Năm 2021, trong một bài viết của mình, AWS đã thông báo AWS Outpost đã có thể đặt hàng thêm tại một số quốc gia, trong đó có Việt Nam. Song song với đó, tại AWS Reinvent 2021, AWS cũng giới thiệu các tùy chọn mới về phần cứng của AWS outpost theo người viết đánh giá là rất phong phú và phù hợp với rất nhiều phân khúc khách hàng, từ dòng server 1U, 2U đến rack 42U được đóng gói sẵn. Theo hướng dẫn, khách hàng chỉ cần thêm 2 kết nối: Service link – Internet, kết nối đến AWS và private link: kết nối vào mạng private của khách hàng là đã có thể lên portal của AWS để tiến hành cấu hình và bắt đầu tạo EC2 instance. Các dịch vụ trên Outpost Rack bao gồm EC2, ECS, EBS, EKS S3, RDS, ALB, EMR, CloudEndure (Outpost server ít dịch vụ hơn). Hiện AWS đã khá đầy đủ từ VM, container, storage đến Load balancer, Data analytics cho hầu hết khách hàng. Vậy AWS outpost hay PCOP (Public cCoud on-premises - theo cách viết tắt của người viết trong bài) là gì? PCOP khác biệt gì so với các giải pháp tương tự của Azure, GCP là Azure stack, Google Anthos? Tất cả sẽ được giải đáp thông qua bài viết dưới đây. Ưu thế của PCOP (Public cloud on-premises) PCOP phong phú về mặt dịch vụ hơn các giải pháp hiện có trên thị trường (ví dụ với các dịch vụ DBaaS, Container platform như AKS, EKS...). Việc này rất phù hợp với xu hướng phát triển và nhu cầu của khách hàng, họ không đơn giản chỉ cần các dịch vụ server, ảo hóa mà cần các dịch vụ mới hơn, đáp ứng cho kiến trúc ứng dụng theo kiểu micro-service - “cloud-native”. Bên cạnh đó, PCOP cũng luôn sẵn sàng cho việc thiết lập môi trường Hybrid, thống nhất (unified) về mặt quản trị, kết nối với hệ thống trên Public để có thể được triển khai tại nhiều nơi trên thế giới, phù hợp cho các công ty đa quốc gia. Một số nhà cung cấp PCOP thường có luôn cơ chế pay-as-you-go, trả tiền theo hàng tháng, giúp doanh nghiệp linh hoạt về chi phí. Khi doanh nghiệp sử dụng các dịch vụ PCOP sẽ được vận hành và theo dõi bởi nhà cung cấp, trong khi đó các giải pháp Private cloud, HCI vận hành bởi chính khách hàng. Đây là điểm mạnh giúp không mất quá nhiều nguồn lực cho vận hành - khai thác nhưng cũng có thể là rủi ro từ việc vận hành từ xa, cần chú ý và đánh giá thêm tiêu chí này. Mặt trái của PCOP Nói về Private cloud, các giải pháp như HCI hoặc build dựa trên VMware, Openstack, Promox... là giải pháp hoàn toàn private trong khi PCOP vẫn phải kết nối với AWS region để quản trị và bảo trì (hybrid), việc này có thể vi phạm chính sách bảo mật hoặc tiêu chuẩn của một số quốc gia, doanh nghiệp. Vendor lock-in: PCOP thường đi theo phần cứng và giải pháp của nhà cung cấp, khi khách hàng muốn mở rộng hoặc thay đổi thì đây là một khó khăn lớn so với các giải pháp khác sử dụng VMware hoặc Opensource sử dụng phần cứng phổ thông. Chuyện gì xảy ra nếu sau này lượng khách hàng, tài nguyên đủ lớn AWS, Azure sẽ thay đổi chính sách, giá? Việc này đã xảy ra với nhiều sản phẩm công nghệ. Mở rộng: Khi sử dụng gần hết năng lực, tài nguyên của server/storage là lúc cần mua bổ sung phần cứng và cấu hình mở rộng. Ví dụ cần mở rộng AWS Outpost rack thì sẽ phải đặt mua rack mới? Làm sao để đấu nối 2 Rack hay sẽ là 2 hệ thống độc lập?  Có mở rộng được từng phần riêng như storage, compute, thời gian đặt hàng, tích hợp mất bao nhiêu lâu? Và lưu ý là chúng ta chỉ có thể mua được từ AWS, với Azure stack thì dễ dàng hơn, hầu hết các vendor phần cứng nổi tiếng như HP, Dell đều có thiết bị được chứng nhận. Có thể thấy đây là những miếng bánh cuối cùng của thị trường điện toán, và nó tiếp tục bị xâm chiếm bởi các nhà cung cấp lớn? Một góc nhìn khác, chúng ta có thể cũng đã nghe đến VMware on AWS, VMware on Azure, GCP. VMware on Azure, VMware cloud on AWS cùng giúp thiết lập môi trường hybrid. Tuy nhiên các giải pháp này có sự khác biệt về cách tiếp cận: Azure stack mang Public cloud service đến on-premises, trong khi Vmware cloud on AWS mang private Vmware service to public enviroment. Vmware cloud on AWS hoặc Azure tiếp cận theo hướng giảm, tối ưu hạ tầng DC, sử dụng model Pay-as-you-go. Tuy nhiên hiện mới chỉ có trên một số region của các NCC và ít hoặc hạn chế hơn trong việc tích hợp với các dịch vụ khác như DbaaS, Container platform, ECS…. Giải pháp như Azure stack cho phép application developer triển khai ứng dụng tại bản địa tuy nhiên đội ngũ kĩ sư cũng cần học hỏi kiến thức mới để có thể triển khai và vận hành, vẫn là một quá trình cần transform cả về con người, quy trình và công nghệ. [caption id="attachment_35027" align="alignleft" width="300"] 2 cách tiếp cận kiến trúc Hybrid theo Gartner.[/caption] Các giải pháp của Azure, AWS… thường tiếp cận theo hướng Outside-in, theo cách mở rộng các dịch vụ Public vào môi trường private. Một số dịch vụ đã có trên public được thiết lập sẵn trên hạ tầng hardware & software. Ngược lại, VMware on Azure/Aws là Inside-out, tùy hiện trạng từng khách hàng nên chọn chiến lược phù hợp.     So sánh cơ bản giữa AWS Outpost, Azure Stack, Google Anthos Solution AWS outposts Google Anthos Azure Stack Hub Azure Stack HCI Azure Stack ARC Description Cung cấp một số dịch vụ AWS tại local Distributed K8s cluster, Multi-cloud Focus trực tiếp dịch vụ liên quan K8s Cung cấp một số dịch vụ của Azure tại Local HCI solution cho local hardware, virtualization layer. Software cho phép quản trị, vận hành local HW, k8s cluster với Azure tool và Azure resource management, hướng tới quản trị resource anywhere, Multi-Cloud Hardware AWS provided, serviced, owned. KH đơn giản là thuê và có chỗ đặt Khách hàng chuẩn bị, quản trị và vận hành. Microsoft partner certified  cung cấp và hỗ trợ. Khách hàng sở hữu. Microsoft partner certified cung cấp và hỗ trợ. Khách hàng sở hữu. Khách hàng chuẩn bị, vận hành và sở hữu (software only) Management Software AWS system software, không thể truy cập từ local Google provided GKE Azure system software, azure portal Microsoft Azure core service, Windows admin center. Truy cập được từ Local, cần kết nối với Azure mỗi 30 ngày. Customer cung cấp system software (linux, windows), cài đặt ARC agent. Why? Cung cấp AWS service với local HW Quản trị tất cả các cụm K8s từ Anthos UI và control plan trong GCP. Extend Cloud Run và một số dịch vụ GCP khác Cung cấp Azure service từ local HW Đơn giản hóa hạ tầng với Azure management Azure quản trị và thiết lập hạ tầng local, K8s cluster Service supported Rack: EC2, ECS, EBS, EKS S3, RDS, ALB, EMR, CloudEndure GKE, Cloud Run, Cloud logging & monitoring, Anthos service mesh… Not provide VM Compute, storage, containers, databases, IoT, data analytics, KMS, marketplace Virtualization AKS, Azure App services, Data services, ML (customer choose) Fees Fees charged based on cloud services consumed Additional fees for data egress, software licenses, etc   Fees charged based on resources usage vCPU Fees charged based on cloud services consumed (vCPU, Storage, application) Fees charged based on Physical CPU.   Deployment AWS ship appliance đã cài đặt sẵn toàn bộ software Khách hàng tự cài đặt phần cứng, triển khai Anthos KH chuẩn bị phần cứng, cài đặt Azure stack lên hoặc partner triển khai. Azure edge thì đã có sẵn software Competitor Azure Stack hub Azure Arc for K8s AWS outposts HCI, SDI solutions (Nutanix, Redhat, Vmware) Google Anthos, k8s management 3rd, AWS system management Kết luận Bài viết đã tóm tắt cơ bản về giải pháp AWS Outposts, Azure Stack và Google Anthos. Các giải pháp giúp mở rộng hạ tầng từ Public cloud xuống On-premise để xây dựng model Hybrid & Multi-Cloud. Có thể thấy Google Anthos, Azure Stack Arc hướng đến mô hình Multi-Cloud bằng cách quản trị các cụm K8s "any where". Trong khi, AWS, Azure Stack (Hub, HCI) có các model phần cứng, phần mềm hướng đến mở rộng hạ tầng thay thế private cloud, Edge. Hãy tiếp tục theo dõi các bài viết mới của FPT Cloud tại ĐÂY để hiểu rõ hơn về việc xây dựng các chiến lược Cloud migration, Hybrid – Multi Cloud. Một số hình ảnh của AWS Outposts Server: Tác giả: Nguyễn Khương Duy - FPT Smart Cloud Nguồn: Viet-AWS Group (https://www.facebook.com/photo?fbid=638463360494850&set=pcb.1098411517643483) https://aws.amazon.com/blogs/aws/new-aws-outposts-servers-in-two-form-factors/?fbclid=IwAR38Fn8GZBd-w8nbu4UfdrCACgelWskE0dsji-GDnKfVChoDULLEKyzicJ0  

  API là viết tắt của Application Programming Interface – phương thức trung gian kết nối các ứng dụng và thư viện khác nhau. API là cơ chế cho phép 2 thành phần phần mềm giao tiếp với nhau bằng một tập hợp các định nghĩa và giao thức. Để hiểu rõ hơn API là gì, hãy tưởng tượng bạn đang ngồi trong một nhà hàng, trước mặt bạn là menu để gọi thức ăn. Nhà bếp là một phần của “hệ thống”, nơi sẽ chuẩn bị những món ăn mà bạn gọi. Tuy nhiên, làm thế nào để nhà bếp biết được bạn muốn ăn món nào? Và làm sao để họ phân phối thức ăn đến bàn của bạn? Đây là lúc cần đến sự xuất hiện của người phục vụ, đóng vai trò như API. Người phục vụ (hay API) sẽ nhận yêu cầu từ bạn và truyền đạt với nhà bếp (hệ thống) những thứ cần làm. Sau đó người phục vụ sẽ phản hồi ngược lại cho bạn, trong trường hợp này, họ sẽ mang thức ăn sau khi nhà bếp hoàn thành đến tận bàn cho bạn. API thường ứng dụng vào đâu? Web API: là hệ thống API được sử dụng trong các hệ thống website. Hầu hết các website đều ứng dụng đến Web API cho phép bạn kết nối, lấy dữ liệu hoặc cập nhật cơ sở dữ liệu. Ví dụ: Bạn thiết kế chức nằng login thông Google, Facebook, Twitter, Github… Điều này có nghĩa là bạn đang gọi đến API của. Hoặc như các ứng dụng di động đều lấy dữ liệu thông qua API. API trên hệ điều hành: Windows hay Linux có rất nhiều API, họ cung cấp các tài liệu API là đặc tả các hàm, phương thức cũng như các giao thức kết nối. Nó giúp lập trình viên có thể tạo ra các phần mềm ứng dụng có thể tương tác trực tiếp với hệ điều hành. API của thư viện phần mềm hay framework: API mô tả và quy định các hành động mong muốn mà các thư viện cung cấp. Một API có thể có nhiều cách triển khai khác nhau và nó cũng giúp cho một chương trình viết bằng ngôn ngữ này có thể sử dụng thư viện được viết bằng ngôn ngữ khác. Ví dụ bạn có thể dùng Php để yêu cầu một thư viện tạo file PDF được viết bằng C++. API REST là gì? REST là từ viết tắt của Chuyển trạng thái đại diện. REST xác định một tập hợp các hàm như GET, PUT, DELETE, v.v. mà máy khách có thể dùng để truy cập vào dữ liệu của máy chủ. Máy khách và máy chủ trao đổi dữ liệu qua giao thức HTTP. Tính năng chính của API REST là tính không trạng thái. Tính không trạng trái nghĩa là máy chủ không lưu dữ liệu của máy khách giữa các yêu cầu. Các yêu cầu mà máy khách gửi cho máy chủ tương tự như URL mà bạn nhập vào trình duyệt để truy cập vào trang web. Phản hồi từ máy chủ là dữ liệu thuần chứ không được kết xuất thành đồ họa như thường thấy trên trang web. API REST mang lại những lợi ích gì? API REST mang lại 4 lợi ích chính: 1. Tích hợp API được sử dụng để tích hợp ứng dụng mới với hệ thống phần mềm hiện tại. Điều này làm tăng tốc độ phát triển vì không cần phải viết lại từng chức năng từ đầu. Bạn có thể sử dụng API để tận dụng mã hiện có. 2. Đổi mới Rất nhiều lĩnh vực có thể thay đổi khi một ứng dụng mới ra mắt. Doanh nghiệp cần khẩn trương phản ứng và hỗ trợ việc triển khai nhanh chóng các dịch vụ đổi mới. Họ có thể thực hiện việc này bằng cách thực hiện các thay đổi ở cấp độ API mà không cần phải viết lại toàn bộ mã. 3. Mở rộng API mang lại cơ hội độc đáo cho các doanh nghiệp để đáp ứng nhu cầu khách hàng của họ trên những nền tảng khác nhau. Ví dụ: API bản đồ cho phép tích hợp thông tin bản đồ qua các trang web, nền tảng Android, iOS, v.v. Mọi doanh nghiệp đều có thể cung cấp quyền truy cập tương tự vào cơ sở dữ liệu nội bộ của họ bằng API miễn phí hoặc trả phí. 4. Dễ duy trì API đóng vai trò là cổng giữa hai hệ thống. Mỗi hệ thống đều phải thực hiện các thay đổi nội bộ để API không bị tác động. Bằng cách này, mọi sự thay đổi về mã trong tương lai do một bên thực hiện sẽ không tác động đến bên còn lại. Làm thế nào để bảo mật API REST? Mọi API đều phải được bảo mật bằng phương thức xác thực và giám sát đầy đủ. Có 2 cách chính để bảo mật cho API REST: 1. Token xác thực Những token này được sử dụng để cho phép người dùng thực hiện lệnh gọi API. Token xác thực kiểm tra xem thông tin nhận dạng người dùng nhập có chính xác không và họ có quyền truy cập lệnh gọi API cụ thể đó không. Ví dụ: khi bạn đăng nhập vào máy chủ email, máy khách email của bạn sẽ dùng token xác thực để bảo mật hoạt động truy cập. 2. Khóa API Khóa API xác thực chương trình hoặc ứng dụng thực hiện lệnh gọi API. Các khóa này nhận dạng ứng dụng và đảm bảo khóa có quyền truy cập cần thiết để thực hiện lệnh gọi API cụ thể. Khóa API không bảo mật như token nhưng chúng cho phép giám sát API để thu thập dữ liệu về việc sử dụng. Bạn có thể nhận thấy những chuỗi ký tự và chữ số dài trong URL trình duyệt khi bạn truy cập các trang web khác nhau. Chuỗi này là một khóa API mà trang web sử dụng để thực hiện lệnh gọi API nội bộ. Đó là tất cả những thông tin liên quan đến API là gì? có đặc điểm nổi bật như thế nào? và các câu hỏi liên quan khác một cách chi tiết nhất để bạn có thể hiểu rõ hơn về API. Nếu trong quá trình tìm hiểu thông tin về công cụ lập trình này mà bạn có bất kỳ thắc mắc nào bên cạnh cần được giải đáp thêm thì hãy nhanh chóng liên hệ với FPT Cloud để được tư vấn thêm: Fanpage: https://www.facebook.com/fptsmartcloud/ Email: [email protected] Hotline: 1900 638 399 FPT Smart Cloud – Nhà cung giải pháp và tư vấn hàng đầu về Điện toán đám mây và Trí tuệ nhân tạo tại Việt Nam