Thay đổi cấu hình ứng dụng web(Angular/ Reactjs) bằng biến môi trường mà không cần rebuild

Mở đầu

   Process triển khai phổ biến hiện nay của các  Single Page Application (SPA) hiện nay là Code => Build => Package => Deploy. Trong đó Build phase sẽ biên dịch code từ frame work thành code HTML, CSS, JS  mà trình duyệt có thể hiểu được. Package phase đóng gói code đã được biên dịch vào một Web server image(Nginx, Apache) và sau đó Deploy phase sẽ triển khai Image lên các Container Engine Platform(Docker, K8S, Aws ECS, Sun Spinner...).

    Trong phase Build , build command với tham số biến môi trường, các file config chứa biến môi trường tương ứng sẽ được biên dịch cùng với source code. Cách làm truyền thống này đáp ứng được hầu hết các yêu cầu trong quá trình phát triển nhưng vẫn tồn tại một số hạn chế:

• Tiêu tốn thời gian build không cần thiết: Do mỗi môi trường yêu cầu một phase build khác nhau mặc dù Source code sau khi biên dịch không có gì khác nhau ngoài các biến môi trường. Trên thực tế các dự án mình đã trải qua, quá trình build production của ứng dụng Angular mất khoảng 15 phút, thời gian build của react js thậm chí còn lên tới 30 phút hoặc hơn nữa. Thời gian build có thể thay đổi phụ thuộc khối  lượng source code và cách optimize, nhưng rõ ràng những con số trên đáng để cân nhắc một giải pháp tối ưu hơn cho thời gian triển khai CICD. 
• Không đủ linh hoạt cho các bài toán Cloud solution, dynamic config: Các bài toán về ứng dụng cloud, multi tenant sẽ không khả thi nếu Source code sau khi build chỉ có thể làm việc với một bộ configuration duy nhất
• Vấn đề Security: Do dữ liệu cấu hình là một phần của source code, Mỗi thành viên đều có thể truy cập config của tất cả các môi trường, dẫn đến rủi ro về bảo mật và vận hành .

Các ứng dụng backend cũng gặp vấn đề này nhưng được giải quyết đơn giản bằng native Environment của phía server, các biến môi trường có thể được inject qua phase Package nên một source code có thể làm việc với nhiều cấu hình khác nhau.

Cách giải quyết

Vậy giải pháp sẽ là phải làm sao để một bộ source code sau khi build có thể được inject các biến môi trường khác nhau tương tự như cách ứng dụng backend hoạt động. Sau đây là cách giải quyết vấn đề, nguyên lý chung này có thể áp dụng cho các web framework và ngôn ngữ khác nhau.

1. Chuẩn bị giải pháp cho phép ứng dụng đọc cấu hình từ một nguồn độc lập với source code(File, API)
2. Chỉnh sửa code của ứng dụng để thay thế các biến môi trường từ nguồn trên
3. Đảm bảo Cấu hình được load xong trước tiên, làm nguồn cho các render chức năng, giao diện về sau

Thực hành với Angular

Mặc định các file config tồn tại trong thư mục src/environments/ với format environment.<env name>.ts và chỉ dẫn build được đặt trong file angular.json. Với lệnh ng build --configuration=production Angular CLI sẽ thay thế file environment.ts bằng file environmen.prod.ts theo chỉ dẫn fileReplacement 

Và các file logic code sẽ import và sử dụng biến môi trường từ file environment.ts.

Ta sẽ bỏ qua các cài đặt mặc định của Angular để thực hiện giải pháp theo các nguyên lý đã nêu ở trên.

1. Tạo một file cấu hình JSON có các key giống với file environment.ts trong src folder. Ví dụ env.json
   
   
   
2. Cấu hình location của file env.json vào phần assets trong angular.json để webpack giữ nguyên file này như một file assets
3. Tạo một service để đọc cấu hình từ file env.json, lưu ý vị trí tương đối của Service này với file env.json
   
   
   
   
4. Đảm bảo dữ liệu config được load đầu tiên khi khởi động ứng dụng
5. Kết quả 
   
   
   
   
   
   
   

Vậy là ứng dụng đã đọc được nội dung từ một file hoặc từ một API độc lập. Nhưng từ từ đã, đến đây đã đạt được dự định ban đầu chưa, ta chưa thấy cách inject được giá trị configuration khác. Trên thực tế, sau khi tách file cấu hình ra khỏi phase Build là đã có thể giải quyết được vấn đề. Sau đây là một vài cách để thực hiện việc inject giá trị config.

1. Inject value vào file env.json trong phase Package của quá trình CICD(thay thế giá trị của file này)
2. Sử dụng API để lấy cấu hình từ phía backend không cần ghi đè file: Sử dụng API với các param đặc trưng cho phía client như IP, location, hostname... để làm parameter cho việc lấy cấu hình. Ví dụ một api với param /env?hostname=localhost:4200 sẽ trả về env với apiEndpoint là localhost:3000, hostname có thể lấy qua biến window.location  của trình duyệt.
3. Khi triển khai ứng dụng bằng các Container Engine Platform: các Engine này có hỗ trợ tính năng mount volume, ta chỉ cần cấu hình mount các file chứa biến môi trường tương ứng từ hệ thống quản lý biến môi trường của Container Engine thay thế vào vị trí file env.json bên trong container chứa source code.

Đọc thêm: 

Hướng dẫn cấu hình ConfigMap K8S

Hướng dẫn mount ConfigMap với Sun Spinner

Kết

    Với các thay đổi theo hướng dẫn ở trên, có thể triển khai ứng dụng web với các biến môi trường khác nhau gần như ngay lập tức, các sửa đổi biến môi trường cũng được apply gần như real time. 

    Tham khảo Sunteco Cloud để có thêm nhiều giải pháp cho hệ thống của bạn.

Microservice thực chiến - API as a service P1 - Project requirement and system architect

Mở đầu 

        Hi các bạn, sau khi bài viết trước nhận được khá nhiều sự quan tâm, mình quyết định sẽ tiếp tục việc chia sẻ trải nghiệm của mình với microservice cũng như mong muốn nhận được những góp ý từ phía mọi người. Nếu như bài viết trước cắt ngang vào việc chuyển đổi từ monolith sang microservice thì từ bài viết này mình sẽ bắt đầu một series về xây dựng các dự án từ mức độ ý tưởng/ requirement, thiết kế kiến trúc, coding và deploy xoay quanh kiến trúc micorservice, từ đó nhìn nhận các khó khăn trong quá trình phát triển dự án với kiến trúc microservice và hướng khắc phục. Các dự án có thể là các project cũ bản thân đã từng trải qua trong quá trình làm việc, các business phổ biến trên thị trường, hoặc nếu các bạn muốn mình làm về chủ đề nào thì để lại requirement dưới comment. 

Project Requirement

    Ban đầu ý tưởng của mình là làm một trang thương mại điện tử trên nền microservice, nhưng nghĩ lại thì để full flow với hệ sinh thái đầy đủ từ warehouse, product, order, khuyến mãi, shiping, accounting, shop, supplier ... sẽ là hơi over cho một sự bắt đầu. Vậy nên sau đó mình nghĩ sẽ làm một ứng dụng đơn giản hơn chút. Business của mình sẽ là application dạng API as a service - Cung cấp dịch vụ qua API. Để dễ hiểu hơn thì các bạn có thể thấy các dịch vụ của google dành cho nhà phát triển có rất nhiều dịch vụ dạng API as a service, ví dụ như các dịch vụ về bản đồ, notification, verify phone number. 

    Mô hình kinh doanh của ứng dụng đã có rồi, vậy sẽ phục vụ nhu cầu gì của thị trường bây giờ? Vài năm trước có một người em nhờ mình tư vấn về giải pháp xác định đơn vị hành chính(phường/ xã, quận/ huyện, tỉnh/ thành phố ) dựa trên input là location(longtitude, latitude). Use case ở đây là các thiết bị có hỗ trợ GPS sẽ gửi location về máy chủ, từ đó máy chủ cần detect  được location theo đơn vị hành chính để thực hiện các business tiếp theo. Ví dụ:

- Các thiết bị thông minh/IoT có kết nối wifi/GPS cần gửi các thông số thiết bị về máy chủ để hỗ trợ quá trình chăm sóc khách hàng, bảo hành. Đi kèm với các thông số là data về location, xác định được đơn vị hành chính mới có thể phân phối thông tin đến các bộ phận cskn, bảo hành ở đúng khu vực một cách tự động

- Các doanh nghiệp logistic cũng cần một mapping từ các văn phòng/ kho hàng của họ đến các địa điểm lấy hàng của khách đề điều chuyển resource một cách hợp lý.

Vậy là đã xác định được core business của dự án, cùng điểm qua một số specification:

• Business cung cấp khả năng xác định đơn vị hành chính(xã/phường- quận/huyện - tỉnh/ thành phố) từ vị trí GPS(*)
• Mô hình kinh doanh API as a service, khách hàng sẽ trả phí để để có một lượng request nhất định
• Hệ thống đo được lượng request của khách để giới hạn nếu đã hết quota
• Dịch vụ có khả năng tích hợp API vào hệ thống của khách hàng.

(*)Trong series bài viết này mình không đi sâu vào phần core function của sản phẩm mà trập trung vào cách triển khai và sự liên kết giữa các phần trong dự án. Phần core function của dự án mình sẽ lướt qua nhé, coi như đã có giải pháp cho phần đó rồi :))

Research

    Cùng lượn qua thị trường một chút trước khi bắt tay vào việc, đợt có làm cái dự án về công nghệ bản đồ nên mình cũng có hiểu biết chút về mảng này. Một vài bên có dịch vụ tương tự mình định làm là Google Map và Mapbox, sang bên đó tham khảo xem dịch vụ họ đang cung cấp như thế nào.

Google Map services

                                                                     Mapbox services

     Về cơ bản thì dịch vụ mình định làm khá giống geocoding của Google và Mapbox. Dịch vụ của họ support convert từ Geo location sang địa chỉ dạng text hoặc ngược lại

Đánh giá dùng thử dịch vụ

    Dữ liệu của google sát hơn với requirement mà mình vừa đề ra ở trên, có các trường dữ liệu rõ ràng phân chia theo level của đơn vị hành chính(level 1 - n). Nhưng vẫn có những nhược điểm như:

- Request 1 điểm mà kết quả dữ liệu trả về 1 mảng,

- Mỗi kết quả trong mảng lại có các level về đơn vị hành chính không đồng nhất(có kết quả có phường-quận- thành phố, nhưng cũng có những kết quả chỉ có quận- thành phố...)

- Không có loại đơn vị hành chính mà chỉ có level

- Giới hạn request free trial rất thấp cho khu vực Việt Nam(3-4 request/day)

Pricing

Pricing của mỗi bên, khảo sát qua tí để đưa ra mức giá phù hợp :))

    Google geocoding pricing

Mapbox geocoding pricing

Brainstorming

    Từ các spec chính đã nêu ở trên, cùng đi chi tiết hơn một chút. Nhìn từ góc độ khách hàng và hệ thống  để xem mỗi bên sẽ ứng xử như thế nào để yêu cầu và đáp ứng được dịch vụ.

• Khách hàng tiếp cận dịch vụ như thế nào?
• Làm sao để dùng thử được dịch vụ trước khi quyết định mua hàng?
• Làm sao để giới hạn số lượng request của khách.
• Làm sao để khách hàng trên toàn thế giới có thể thanh toán tiền cho hệ thống?
• Trang portal của khách sẽ có những tính năng gì?

User flows:

• User sử dụng thử chức năng geo location to administrative location trên trang example
• User đăng ký tài khoản và verify account.
• User xem hướng dẫn sử dụng dịch vụ
• User tạo api key
• User tích hợp API vào hệ thống
• User nhận được mail báo lượng request usage và thanh toán cho hệ thống

System flow:

• Hệ thống đếm và lưu lại số lần request của khách hàng
• Hệ thống verify request của khách hàng
• Hệ thống xử lý request và trả về kết quả
• Hệ thống tính lượng request của khách để đưa ra bill thanh toán theo chu kỳ
• Hệ thống gửi mail thanh toán đến email của khách hàng
• Hệ thống theo dõi tình trạng hóa đơn của khách hàng để đưa ra quyết định

    Phần feature sẽ có thể rất rộng, ở đây mình chỉ hình dung các flow chính để thiết kế hệ thống cho phù hợp.

System architect

    Vậy là đã tạm đủ dữ liệu để hình dung ra bước tranh tổng thể của dự án này rồi. Giờ là lúc lên kiến trúc cho dự án

Logical

Microservices responsibility

• Admin site:  Trang quản trị hệ thống
• Client site: Trang portal chính mà khách hàng sẽ tương tác
• Backend gateway: Gateway cho hệ thống backend phía sau
• User authentication: Service xác thực định danh của khách hàng 
• Billing service: Service thực hiện việc thanh toán, các nghiệp vụ liên quan đến charge tiền khách hàng,
• CRM service: Quản lý khách hàng, Subscription, Controller chính của hệ thống backend
• Report service: Chứa log, phân tích số liệu request của hệ khách hàng
• Geo service: Core service thực hiện các functional liên quan đến geo-location
• Integration API gateway: Gateway cho Geo-service, vì đặc trưng của hệ thống là API as a service nên phải có gateway riêng cho các API dịch vụ expose ra cho khách hàng sử dụng
• API key authentication: Service riêng authenticate các API dịch vụ và trigger request event để limit số lượng request của khách hàng
• Message queue: Hệ thống microservice không thể thiếu được thành phần này, đóng vai trò là kênh giao tiếp bất đồng bộ và xử lý các nghiệp vụ bắt buộc dùng queue
• Notification: Các chức năng liên quan đến gửi thông báo, email...

    Một product đưa ra kinh doanh còn phải kể đến các trang static content như branding site, documentation site, nhưng vì không giao tiếp trực tiếp với các thành phần còn lại nên mình sẽ không đề cập.

Tech stack

    Architect bao gồm các thành phần Frontend, Backend, Message Queue, API Gateway, Database. Các bạn có thể lựa chọn stack phù hợp với bản thân:

• Backend Services: Java Spring
• Frontend: Angular
• Message queue: Kafka
• API gateway: Spring gateway
• Database: Mysql

    Database nên triển khai theo mô hình Database per service, lúc đầu có thể thấy phiền phức vì nhiều DB phải maintain, nhưng sẽ không gặp phải tình trạng bottle neck nếu một service nào đó sử dụng nhiều tài nguyên database, chưa kể đến khả năng phát triển độc lập các service, security.

Kết

   Project này thể hiện được một phần các thành phần của kiến trúc micorservice, với project khác có thể triển khai kết hợp với nhiều stack, concept hơn nữa. Các service  cũng có thể được tách nhỏ hơn nữa tùy điều kiện.

    Bài viết sau mình sẽ triển khai break chi tiết một vài requirement để làm story và đưa vào triển khai trên phạm vi team.

Powered by Sunteco Cloud

    

API as a service P1 - Project requirement and system architect

API as a service P2 - Break story and development strategy

API as a service P3 - Setup environment and develop flow

API as a service P4 - Coding

API as a service P5 - Các vấn đề thường gặp khi triển khai microservice

API as a service P6 - Release production

Transform monolith to microservices in action

1. Why microservices ? 

Microservice là kiến trúc hệ thống phần mềm hướng dịch vụ, chia nhỏ hệ thống ra thành các dịch vụ nhỏ , isolate về  business và dữ liệu. Microservices đã trở nên phổ biến trong những năm trở lại đây, với những ưu điểm nổi bật, nó đang thay thế các ứng dụng monolith. Một số đặc trưng của microservice như sau.

- Triển khai độc lập

Nhờ chia nhỏ 1 ứng dụng lớn ra làm nhiều ứng dụng nhỏ hơn, hệ thống trở lên linh hoạt trong triển khai. Linh hoạt từ việc lựa chọn công nghệ cho đến phân phối tài nguyên. Hệ thống có thể đạt được tiêu chí  scalability, high availability

- Giảm sự phụ thuộc

Các module được xác định rõ trách nhiệm, Việc ràng buộc trong sử dụng chung code business, model và database được giảm xuống.

- Định hướng xoay quanh nghiệp vụ

Microservices hướng đến các dịch vụ xoay quanh business, một service là một ứng dụng có thể chạy độc lập. Development teams thường sẽ chỉ phải tập trung vào phát triển business

- Khả năng phát triển, bảo trì và kiểm thử

Các stack khác nhau có thể được áp dụng chung trong giải pháp tổng thể, thậm chí tái sử dụng từ một hệ thống khác mà không phải lo về sự tương thích. Việc kiểm thử cũng dễ triển khai hơn với các dịch vụ nhỏ, các nghiệp vụ rõ ràng.

Trong bài viết này mình sẽ không đi sâu để so sánh giữa monolith và microservices, xem thêm tại => Monolith and microservice considering.

2. The Microservices Layer ?

    Nếu chúng ta đã quen làm việc với monolith, từ việc code tất cả  trên cùng một repo, một máy chủ dedicated về cấu hình, một database phục vụ tất cả các mục đích... thì việc chuyển đổi qua microservice thực sự là một thử thách. Ở vị trí của người thiết kế hệ thống, có quá nhiều thứ mới để hiểu và áp dụng để có thể có được best P/P (price/ performance) mà vẫn có khả năng mở rộng.

Một kiến trúc microservice hiệu quả là sự phối hợp một các hợp lý giữa các tech stack

Ta có thể chia Microservice làm 4 layer:

2.1 Infastructure layer

    Sự chuyển dịch từ traditional computing sang distributed computing/ cloud computing tạo điều kiện rất thuận lợi cho việc áp dụng kiến trúc microservice. Việc triển khai microservice mà không có sự hỗ trợ từ hạ tầng sẽ tốn nhiều công sức hơn đáng kể. Ở dưới cùng là hạ tầng với các thành phần cơ bản:

- Servers

- Host level loging/ monitoring

- Operating systems

- Resource isolation

- Configuration management

2.2 Communication layer

    Layer này dễ gây nhầm lẫn, bởi vì nó chạm đến tất cả các layer khác trong hệ sinh thái. Nó bao gồm tất cả mọi thứ liên quan đến  giao tiếp giữa ứng dụng, hệ thống và  dịch vụ bao gồm:

- DNS

- Endpoint

- Load balancing

- Messaging

- Network

- Service registry

- Service discovery

2.3 The Application platform

    Layer thứ 3 là nơi chứa tất cả các công cụ nội bộ, hệ thống, dịch vụ mà các microservice chạy trên đó. Một application platform tốt là nơi các công cụ được centralize về mặt quản lý, system-wide về mặt phạm vi. Development teams chỉ cần quan tâm đến các microservice mà họ làm việc, không phải những thứ stuff phía dưới. Layer này bao gồm

- Deployment management(tools and pipeline)

- Development environment

- Application-level logging and monitoring

- Test, package, build and release tools

2.4 The Microservices Layer

Các developer forcus tại layer này và tập trung vào business. Layer này nên độc lập với các layer phía dưới. Nó chỉ chứa các microservices và các cấu hình giữa chúng.

- Microservice

- Microservice configuration

3. Transform the Monolith to Microservice in action

    Cùng xem xét một ứng dụng monolith truyền thống với các tier Presentation, Business logic và Data access layer.

3.1 Business and Tech Stacks:

Các đặc trưng của hệ thống hiện tại

Business: Ứng dụng thương mại điện tử.

Architect: 3 Tiers Application  bao gồm Presentation, Business logic, Data access layer sử dụng Spring MVC, Spring Data

Database: Database sử dụng Mysql

Hosting: Ứng dụng được triển khai bằng file jar và database  trên server đặt tại công ty

3.2 Các issue hệ thống đang gặp phải

- Spring MVC dựa trên kiến trúc server side rendering, multiple pages application, dẫn đến việc load trang lâu hơn

- Hệ thống downtime mỗi khi nâng cấp phiên bản mới, cho dù là tính năng nhỏ nhất của một module

- Hiện tượng bottle neck xuất hiện mỗi khi có nhiều người cùng truy cập hoặc thực hiện các tác vụ nặng, lost các đơn hàng, hệ thống order không hoạt động ổn định, thậm chí down cả dịch vụ. Tăng cấu hình tài nguyên thì tốn kém khi hệ thống tải thấp, nhưng vẫn ko đủ phục vụ khi hệ thống tải cao.

- Chức năng tìm kiếm sản phẩm chậm do dùng query truyền thống

- Quản lý build number của app và data một cách thủ công, bằng cách backup các file vật lý(.jar, sql)

- Hệ thống trace log cũng thủ công bằng cách write ra file, khó để trace lại khi có error

- Hệ thống chứa nhiều module nghiệp vụ, code đang phức tạp và khó maintain, việc phát triển tính năng mới đòi hỏi phải test lại toàn bộ hệ thống

- Ảnh sản phẩm được lưu trữ trực tiếp trên một máy chủ khác, khó quản lý

3.3 Chuyển đổi hệ thống sang microservice

- Chuyển đổi các business module sang microservice: 

    + Authentication, 

    + Product management , 

    + Warehouse,  

    + Order/Payment, 

    + Shipping, 

    + Report,  

    + Client site

    + Cms site

- Chuyển đổi về architect :

    Như phân tích ở trên, vấn đề khó khắc phục nhất trong các issue là vấn đề ứng dụng chạy trên nền tảng dedicated resource ( VM ) dẫn đến không thể kịp thời scale theo lượng tài nguyên yêu cầu, ảnh hưởng trực tiếp đến chất lượng hệ thống và trải nghiệm người dùng. Xem xét các chuyển đổi về architect:

    + Triển khai ứng dụng dựa trên container orchestration (K8S concept) , phục vụ mục đích scalability, high availability

    + Tối ưu tìm kiếm sản phẩm bằng việc dựng thêm elastic service, đồng bộ với Product database

    + Xem xét nâng cấp database sang mô hình master-slave để tối ưu hiệu quả đọc ghi.

    + Load balancer cân bằng tải cho các instance mỗi khi hệ thống cao tải

    + API gateway giúp ẩn kiến trúc phía sau và authentication/ request logging tập trung

    + Lựa chọn công nghệ message queue cho giao tiếp bất đồng bộ giữa microservices

    + Client site và cms site sử dụng công nghệ client site rendering (angular/react) để đạt higher             performance. Việc phát triển tầng UI và business logic được tách biệt 

    + Separate các database cho mỗi dịch vụ, tăng resource cho các database có nhiều request, thậm chí áp dụng DB replica, master/slave   => tăng tính bảo mật và upgrade về sau

    + Sử dụng docker hub hoặc private image registry để lưu trữ các bản build của service dưới dạng image tag.

    + Áp dụng các công nghệ có thể backup data dưới dạng backup volume bên cạnh dạng backup file truyền thống

    + Chọn một stack cho việc lưu trữ file (ảnh sản phẩm, Database backup ) : Object storage  technology(Sun S3)

3.3 Lựa chọn tech stack, provider và triển khai

    Với cùng một thiết kế hệ thống, chúng ta có thể điều chỉnh lựa chọn tech stack và provider phù hợp với hoàn cảnh của mỗi công ty. Trên thị trường quốc tế có các tên tuổi lớn về cloud provider và app platform nổi tiếng như AWS, GCP, Microsoft azure. Trong nước thì có các nhà cung cấp như VNG cloud, Viettel IDC, CMC, FPT, Sunteco cloud với các mức giá và dịch vụ khác nhau. Mình sẽ triển khai hệ thống này trên Sunteco cloud, lấy trọng tâm là Sun Spinner, đây là dịch vụ dựa trên concept của K8S, hỗ trợ sẵn Load balancing, HA và scability chỉ với vài click. Một Sun-spinner có thể chứa một hoặc nhiều container.

- Sau khi build các service sang dạng image và đẩy lên docker hub, setup các Sun Spinner cluster từ giao diện

- Sun Spinner cho phép run bất kì image nào trên docker hub hoặc các image registry khác, thao tác hoàn toàn qua UI

- Database có thể được triển khai qua 3 cách trên Sunteco cloud, 

    + Tạo một mysql-spinner sau đó sử dụng persistance volume(Vùng nhớ lưu trữ lâu dài)  và mount vào data stored path của mysql-spinner 

    + Cách truyền thống hơn là sử dụng dịch vụ Sun VM để host database với dedicated resource 

    + Dịch vụ Database as a service (Comming soon)

- Các service-config được setup qua hệ thống Secret/ Configmap và mount trực tiếp vào Spinner . Đơn giản hóa quá trình quản lý configuration

- Các trang static web(landing page) có thể host trên Sun VM hoặc Sun S3 storage

- Message queue sử dụng Sun Highway (kafka as a service)

    Vòng đời của các service: CICD => push to docker hub => Sun spinner pull image =>Service booting =>  Service running. Có một góp ý nhỏ là Spinner chưa có cơ chế tích hợp với hệ thống CICD của các doanh nghiệp, có lẽ cần một api callback để trigger việc cập nhật ứng dụng lên phiên bản mới. Hiện tại phải lên portal của Sunteco Cloud để manual update version mới hoặc setup Sun Spimner với auto update policy. Nhờ việc chỉ cần facing ứng dụng web và api gateway ra ngoài, các ứng dụng phía sau giao tiếp với nhau qua internal endpoint, message broker mà performance và security được nâng cao. Mình chưa đề cập đến vấn đề database relication, xin hẹn ở những bài viết sau.

4. Conclusion

     Bạn có thể cân nhắc chuyển đổi toàn bộ hoặc từng phần ứng dụng của doanh nghiệp với mức chi phí nhỏ nhất để đặt được hiệu quả tốt nhất. Công nghệ container cho phép ứng dụng có thể scale một các tùy ý. Spinner của Sunteco có pricing theo giờ, có nghĩa là nếu hệ thống tải bình thường thì lượng tiêu thụ chỉ tương đương với VM cùng cấu hình, nhưng khi hệ thống tăng tải, cấu hình được tự động scale ngay lập tức để đáp ứng nhu cầu, khi hệ thống giảm tải, cấu hình lại trở về mức bình thường. Tất cả các nhu cầu này nếu tự dựng một hệ thống K8S rồi tự setup sẽ tốn khá nhiều nguồn lực và chưa chắc đã hoạt động ổn định.Việc chuyển đổi từ kiến trúc monolith sang microservice hoặc xây dựng mới hoàn toàn là không dễ dàng, nhưng nó rất đáng giá để thực hiện.

Reference

https://www.susanjfowler.com/blog/2016/12/18/the-four-layers-of-microservice-architecture