Các chuyên gia viết chia sẻ kiến thức – FPT CLoud

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. >>> Xem thêm: Platform là gì? 10 mô hình platform nổi bật và linh hoạt 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. >>> Xem thêm: Sandbox là gì? Cách thức thiết lập Sandbox vào ứng dụng 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. Những bài viết liên quan: Server là gì? Phân loại & Vai trò của máy chủ server Server Rack là gì? Server Rack loại nào tốt nhất? Blade Server là gì? Toàn tập kiến thức Blade Server từ A – Z Addon Domain là gì? Cách tạo & thêm addon Domain vào hosting 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

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  

Hiện nay, việc chuyển ứng dựng lên Cloud là một trong nhưng yêu cầu có độ ưu tiên cao nhất. Vậy làm thế nào để việc chuyển đổi được thực hiện bài bản, có hiệu quả và đáp ứng được yêu cầu sản xuất kinh doanh, vận hành tốt nhất? Bài viết trình bày các kinh nghiệm thực tế về quá trình “lên mây” – còn gọi là Cloudification. Nhìn từ góc nhìn nhà đầu tư, Cloudification thực tế mang lại nhiều hạn chế và rủi ro hơn là lợi ích. Xác định được yếu tố đảm bảo cho dự án Cloudification thành công và phương án để biến các yếu tố đó thành hiện thực là cách để bắt đầu. Ba yếu tố then chốt gồm: Tính hiệu quả: tối ưu chi phí, thời gian và nguồn lực sử dụng trong dự án; Tính an toàn: giảm thiểu tối đa rủi ro có thể diễn ra trong dự án; Khả năng quản lý: dự doán và kiểm soát chặt chẽ thời gian, ngân sách và nguồn lực. Mô hình Migration Factory được FPT xây dựng nhằm giải quyết các thách thức trên và đã được áp dụng thành công cho nhiều khách hàng trong nhiều năm qua. [caption id="attachment_6036" align="aligncenter" width="624"] Hình 1 – Migration Factory và ba bước cơ bản “lên mây”.[/caption] Bắt đầu cẩn trọng với Cloud assessment Cloud assessment giúp định nghĩa chiến lược, giải pháp và lộ trình để chuyển đổi lên Cloud với chi phí và nguồn lực hợp lí. Bốn bước trong Cloud assessment bao gồm: Đánh giá thực trạng của landscape hiện tại như bugs và backlogs đang có, network design, security policy, development, deployment process. Thu thập yêu cầu trong và sau khi thực hiện migration như yêu cầu về data protection, cách thức quản lý, tối ưu tài chính. Đánh giá về khoảng cách giữa thực trạng và mong muốn. Đưa ra giải pháp để thực hiện chuyển đổi gồm giải pháp kỹ thuật, chi phí, công cụ và cách thức vận hành sau khi chuyển đổi. Cloud assessment giúp đánh giá toàn diện trên 3 yếu tố tài chính, kỹ thuật và quản trị dựa trên 5 con đường (5RE) có thể đưa ứng dụng lên Cloud. [caption id="attachment_6040" align="aligncenter" width="624"] Hình 2 – 5RE – 5 con đường lên Cloud.[/caption] Triển khai hiệu quả với Cloudification Cloudification trong mô hình Migration Factory là một quy trình chặt chẽ bao gồm: lên kế hoạch, lựa chọn nguồn lực phù hợp, đánh giá yêu cầu và giải pháp, thực hiện kiểm thử và điều chỉnh giải pháp, lựa chọn tool, thực hiện migration, thực hiện cutover. Quá trình cutover là quan trọng nhất nhằm đảm bảo việc chuyển tải sử dụng từ môi trường cũ sang môi trường mới diễn ra suôn sẻ. Nhiều phương án trong đó có giải pháp cho failback (chuyển ứng dụng quay lai môi trường cũ) cần được chuẩn bị kỹ càng. Việc dùng tool là tối quan trọng nhằm giảm thiểu chi phí, rút ngắn thời gian và đặc biệt là giảm thiểu rủi ro có thể phát sinh. FPT CLoud đã xây dựng Cloudification Suite, trong đó Cloudification Orchestration là trái tim của bộ tool này, để thực hiện những công việc sau: Quản lý toàn bộ môi trường migration. Đơn giản hóa hoạt động migration thông qua việc định nghĩa các bước thực hiện cũng như pipeline cho từng ứng dụng hay nhóm ứng dụng. Cung cấp giao diện thân thiện cho việc quản lý dự án. Quản lý tối ưu với Cloud managed Cloud tạo ra sự khác biệt lớn so với mô hình data center truyền thống, vì vậy việc quản lý Cloud và các ứng dụng triển khai trên Cloud cũng có sự khác biệt. Cloud và Something as a service (XaaS) xóa đi ranh giới của hạ tầng và ứng dụng, chỉ cần một nhóm duy nhất để thực hiện quản lý toàn bộ từ hạ tầng, bảo mật cho tới ứng dụng. Cloud chuyển mô hình quản lý và chi tiêu tài chính từ CAPEX (Capital Expense) sang OPEX (Operational Expense). Với các cơ chế tagging, tổ chức resource hoặc account theo nhóm sẽ cung cấp một cơ chế tốt để kiểm soát chi phí cho từng loại service, cost center cho tới từng cá nhân một cách hiệu quả. Cloud cũng mở ra cơ hội để tối ưu hóa chi phí sử dụng và vận hành toàn bộ các ứng dụng và hạ tầng. FPT Software đã xây dựng 7L framework để hỗ trợ khách hàng thực hiện tối ưu chi phí. 7L framework – tối ưu chi phí sử dụng Cloud Cloud với khả năng tự động hóa vốn có giúp tăng tính hiệu quả, giảm chi phí trong quản lý. Các hoạt động quản lí gồm: Hoạt động quản lý bằng con người: định kỳ thực hiện thông qua checklist và hướng dẫn. Hoạt động quản lý Hybrid: sử dụng các hệ thống giám sát tự động kết hợp định nghĩa các tham số để hệ thống thông báo xử lý sự cố khi xảy ra. Hoạt động quản lý tự động: sử dụng các hệ thống giám sát và ra quyết định tự động dựa trên phân tích, sử dụng công nghệ học máy và trí tuệ nhân tạo. Thêm vào đó, FPT Software đồng thời phát triển và cung cấp giải pháp Self Service Portal hướng tới những người dùng phổ thông không có kiến thức sâu về Cloud như quản trị hệ thống có thể dễ dàng sử dụng cho công việc hàng ngày.  FPT Cloud Self-Service Portal Có thể nói, Cloud đã và đang mở ra con đường cho doanh nghiệp, tổ chức thực hiện những cuộc cách mạng hoá nhằm cải tiến quy trình quản lý IT, ứng dụng và mô hình sản xuất kinh doanh ngày một hiệu quả.