Kiến trúc vi dịch vụ giải quyết các thách thức bằng cách chia nhỏ ứng dụng thành các thành phần hoặc dịch vụ nhỏ hơn. Cách tiếp cận này đã thu hút sự chú ý đáng kể trong những năm gần đây, phát triển từ một khái niệm mới lạ thành một mô hình kiến trúc chủ đạo.
Sự phát triển của kiến trúc ứng dụng
Chưa đầy 10 năm sau khi thuật ngữ này được đặt ra lần đầu tiên, kiến trúc vi dịch vụ đang ngày càng trở nên phổ biến. Tuy nhiên, quyết định giữa thiết kế đơn khối truyền thốngvà phương pháp tiếp cận vi dịch vụ vẫn là một cân nhắc quan trọng đối với nhiều tổ chức. Để hiểu được lý do ủng hộ và phản đối từng phương pháp tiếp cận kiến trúc, việc xem xét cách các ứng dụng, đặc biệt là cơ sở mã của chúng, phát triển theo thời gian sẽ rất hữu ích.
Monolithic so với Microservices
Kiến trúc nguyên khối là gì?
Với kiến trúc nguyên khối, rất ít thành phần chuyển động; hầu hết các tính năng được cung cấp bởi cùng một cơ sở mã, với các đối tượng có trạng thái được lưu trữ trong một cơ sở dữ liệu duy nhất. Cách tiếp cận này hiệu quả với các ứng dụng đơn giản được phát triển bởi một nhóm nhỏ. Mọi người tham gia đều hiểu cách thức hoạt động của từng thành phần ứng dụng, và với ít sự phụ thuộc, nhóm có thể kiểm tra và triển khai các thay đổi nhanh chóng. Đối với các công ty khởi nghiệp đang cố gắng đưa sản phẩm mới ra thị trường nhanh chóng, cách tiếp cận nguyên khối mang lại chi phí thấp và chu kỳ phát triển ngắn, cho phép họ triển khai nhanh chóng.
Tuy nhiên, khi ứng dụng trở nên phức tạp hơn và cơ sở mã phát triển, quá trình phát triển chậm lại và thời gian giữa các bản phát hành tăng lên. Tại sao điều này xảy ra? Khi nhiều tính năng và chức năng được thêm vào, cơ sở mã trở nên lớn hơn, khiến việc duy trì các trừu tượng mã sạch và duy trì tài liệu chính xác trở nên khó khăn hơn. Khi cần thay đổi, rất khó để cô lập các thử nghiệm và tránh tác động đến phần còn lại của ứng dụng, kìm hãm sự đổi mới. Một hệ thống lớn hơn đòi hỏi nhóm phát triển cũng phải phát triển, nhưng những người mới bắt đầu phải đối mặt với đường cong học tập dốc khi họ cố gắng nắm bắt toàn bộ hệ thống và dự đoán tác động mà những thay đổi của họ sẽ có. Tất cả những yếu tố này làm chậm chu kỳ phát triển và phát hành, gây ra sự thất vọng cho cả ban quản lý và kỹ sư, từ đó làm suy yếu tinh thần - điều cuối cùng bạn muốn khi thành công của bạn phụ thuộc vào sự sáng tạo và cam kết của nhóm.
Microservices là gì và chúng có tác dụng như thế nào?
Kiến trúc microservices giải quyết những thách thức này bằng cách chia nhỏ ứng dụng thành các thành phần hoặc dịch vụ nhỏ hơn. Mỗi thành phần chịu trách nhiệm cho một chức năng nghiệp vụ duy nhất (do đó được gọi là "microservice") và giao tiếp với các dịch vụ khác thông qua API và giao thức nhắn tin. Mỗi nhóm phát triển chịu trách nhiệm cho một dịch vụ riêng lẻ, và vì các dịch vụ giao tiếp với nhau thông qua API, các nhà phát triển không cần phải hiểu những phức tạp của các dịch vụ khác - chỉ cần hiểu các giao diện mà chúng hiển thị. Các nhóm có thể phát triển và triển khai các thay đổi một cách độc lập, và các thành viên mới có đường cong học tập nhẹ nhàng hơn nhiều, cho phép họ làm việc hiệu quả sớm hơn nhiều.
So sánh chi tiết: Kiến trúc Monolithic và Microservices
Ưu và nhược điểm của phương pháp tiếp cận đơn khối
Việc quản lý toàn bộ logic ứng dụng của bạn trong một quy trình duy nhất mang lại nhiều lợi thế, đặc biệt là đối với các ứng dụng đơn giản do một nhóm nhỏ phát triển.
Thuận lợi:
- Đã trở thành chuẩn mực trong nhiều năm, hầu hết các IDE đều hỗ trợ kiến trúc độc lập bằng cách cho phép bạn chạy và kiểm tra toàn bộ ứng dụng chỉ bằng một cú nhấp chuột.
- Các mối quan tâm chung như bảo mật, giới hạn tốc độ và giám sát đều có thể được xử lý tập trung cho toàn bộ ứng dụng.
- Vì có rất ít bộ phận chuyển động nên việc chạy thử nghiệm toàn diện tương đối dễ dàng.
- Đối với các cơ sở mã nhỏ hơn, khối đơn giản hơn để quản lý và triển khai và ứng dụng có thể được mở rộng theo chiều ngang phía sau bộ cân bằng tải.
Tuy nhiên, một số lợi ích này sẽ trở thành bất lợi khi ứng dụng trở nên phức tạp hơn và cơ sở mã nguồn mở rộng. Chúng tôi đã đề cập đến những khó khăn trong việc duy trì các quy trình viết mã tốt và phát triển đội ngũ cho một hệ thống lớn, nguyên khối. Ngoài ra:
Nhược điểm:
- Cách duy nhất để mở rộng quy mô một khối là sao chép toàn bộ ứng dụng, nhưng điều này không phải lúc nào cũng hiệu quả.
- Các nhà phát triển bị hạn chế bởi ngôn ngữ và khuôn khổ đã chọn ngay từ đầu.
- Việc kiểm thử và phát hành, ngay cả khi chỉ là một thay đổi nhỏ hoặc sửa lỗi, cũng đòi hỏi phải xây dựng và triển khai toàn bộ ứng dụng. Khi cơ sở mã nguồn phát triển, việc này ngày càng tốn thời gian.
- Sự cố ở bất kỳ phần nào của ứng dụng cũng có thể làm sập toàn bộ hệ thống.
Ưu và nhược điểm của phương pháp tiếp cận dịch vụ vi mô
Bằng cách chia các ứng dụng phức tạp thành các thành phần riêng lẻ, mỗi thành phần tập trung vào một chức năng kinh doanh duy nhất, kiến trúc vi dịch vụ mang lại nhiều lợi thế hơn so với thiết kế nguyên khối :
Thuận lợi:
- Các dịch vụ vi mô được kết nối lỏng lẻo và giao tiếp thông qua API, cung cấp một lớp trừu tượng hóa khỏi logic cơ bản. Nhờ đó, các nhóm có thể làm việc song song, phát triển và kiểm thử các thay đổi độc lập với phần còn lại của hệ thống, cho phép các chu kỳ phát triển lặp lại nhanh hơn.
- Vì mỗi dịch vụ đều độc lập, các nhóm có thể chọn ngôn ngữ và khuôn khổ phù hợp nhất với nhu cầu của mình. Điều này cũng tạo điều kiện cho các nhóm đổi mới và thử nghiệm mà không ảnh hưởng đến phần còn lại của hệ thống.
- Trách nhiệm đối với một dịch vụ vi mô cụ thể, được xác định rõ ràng sẽ giúp nhân viên mới dễ dàng học hỏi hơn, từ đó có thể làm việc hiệu quả sớm hơn nhiều.
- Vì mỗi microservice có thể được triển khai độc lập, chúng có thể được mở rộng quy mô riêng lẻ tùy theo tải của từng dịch vụ. Việc tạo thêm các phiên bản của từng dịch vụ riêng lẻ hiệu quả hơn so với việc sao chép toàn bộ hệ thống và cho phép các tổ chức tận dụng lợi ích của cơ sở hạ tầng đám mây linh hoạt.
- Nếu một phiên bản của microservice bị xâm phạm hoặc gặp sự cố, nó có thể được cô lập và đưa ngoại tuyến mà không ảnh hưởng đến phần còn lại của hệ thống. Cùng với khả năng mở rộng theo chiều ngang của từng microservice, điều này tạo nên một hệ thống mạnh mẽ và linh hoạt hơn.
Mặc dù kiến trúc vi dịch vụ mang lại nhiều lợi ích, nhưng vẫn có một số điểm phức tạp liên quan đến hệ thống phân tán:
Nhược điểm:
- Kiến trúc microservice bao gồm nhiều thành phần chuyển động hơn so với thiết kế nguyên khối, điều này làm tăng độ phức tạp ngay từ đầu. Đối với các ứng dụng đơn giản do các nhóm nhỏ quản lý, phương pháp microservice có thể là quá mức cần thiết.
- Việc hiển thị từng microservice riêng lẻ cho ứng dụng khách có thể gây khó khăn cho việc tương tác với hệ thống, vì các nhà phát triển ứng dụng khách phải hiểu cách định tuyến yêu cầu đến hàng chục hoặc hàng trăm dịch vụ tạo nên hệ thống. Vấn đề này có thể được giải quyết bằng cách thêm một cổng API làm lớp trừu tượng giữa các dịch vụ phụ trợ và ứng dụng khách để định tuyến yêu cầu và tổng hợp phản hồi.
- Các vấn đề liên ngành, chẳng hạn như bảo mật, xác thực và giám sát, cần được áp dụng cho từng dịch vụ vi mô, và chức năng phải được sao chép cho từng ngôn ngữ được sử dụng trong hệ thống. Tuy nhiên, việc quản lý các chức năng này tập trung từ một cổng API sẽ tránh được vấn đề này và đảm bảo một phương pháp tiếp cận nhất quán.
- Việc kiểm thử hiệu quả một hệ thống dựa trên microservice đòi hỏi nhiều lớp kiểm thử tự động để quản lý các phụ thuộc và cho phép các dịch vụ được triển khai độc lập. Mặc dù điều này nghe có vẻ hơi nặng nề, nhưng kiểm thử tự động là một khoản đầu tư xứng đáng, cho phép triển khai liên tục bất kỳ hệ thống nào, dù là monolithic hay microservice.
Những cân nhắc hiện đại trong cuộc tranh luận về Monolithic và Microservices
Khi công nghệ tiếp tục phát triển, các yếu tố mới đã xuất hiện ảnh hưởng đến sự lựa chọn giữa kiến trúc đơn khối và kiến trúc vi dịch vụ:
Phát triển trên nền tảng đám mây
Sự trỗi dậy của phát triển ứng dụng đám mây gốc đã khiến microservices trở nên hấp dẫn hơn bao giờ hết. Các nền tảng đám mây cung cấp các dịch vụ phù hợp với kiến trúc microservices, chẳng hạn như container hóa (ví dụ: Docker), orchestration (ví dụ: Kubernetes) và điện toán không máy chủ. Những công nghệ này giúp việc triển khai, quản lý và mở rộng microservices trở nên dễ dàng hơn.
DevOps và Phân phối liên tục
Việc áp dụng các phương pháp DevOps và quy trình phân phối liên tục đã giúp việc quản lý tính phức tạp của các dịch vụ vi mô trở nên dễ dàng hơn. Các công cụ kiểm thử, triển khai và giám sát tự động đã giảm thiểu chi phí quản lý nhiều dịch vụ.
Thiết kế API-First
Với tầm quan trọng ngày càng tăng của API trong phát triển phần mềm hiện đại, kiến trúc microservices phù hợp với các nguyên tắc thiết kế API-first . Mỗi microservices có thể cung cấp một API được định nghĩa rõ ràng, giúp tích hợp dễ dàng hơn với các dịch vụ khác và các hệ thống bên ngoài.
Điện toán biên
Sự phát triển của điện toán biên đã mang đến những cân nhắc mới. Các ứng dụng đơn khối có thể phù hợp hơn với việc triển khai ở biên giới nơi tài nguyên bị hạn chế, trong khi các dịch vụ vi mô có thể tận dụng kiến trúc lai giữa biên giới và đám mây để tối ưu hóa hiệu suất và khả năng mở rộng.
Kiến trúc không máy chủ
Điện toán không máy chủ (serverless computing) nổi lên như một phần mở rộng của khái niệm vi dịch vụ (microservices). Nó cho phép các nhà phát triển tập trung hoàn toàn vào việc viết mã cho các chức năng riêng lẻ, trong khi nhà cung cấp dịch vụ đám mây quản lý toàn bộ cơ sở hạ tầng cơ bản. Điều này có thể giảm thiểu chi phí vận hành và cải thiện khả năng mở rộng.
Phương pháp tiếp cận kết hợp
Điều đáng chú ý là sự lựa chọn giữa kiến trúc đơn khối và kiến trúc vi dịch vụ không phải lúc nào cũng là nhị phân. Nhiều tổ chức đang áp dụng các phương pháp kết hợp:
Monolith mô-đun
Monolith mô-đun là một đơn vị triển khai duy nhất, duy trì ranh giới rõ ràng giữa các mô-đun khác nhau. Cách tiếp cận này có thể mang lại một số lợi ích của microservice (như tổ chức mã và tính tự chủ của nhóm) đồng thời tránh được một số phức tạp của hệ thống phân tán.
Micro-Frontends
Mở rộng khái niệm microservices sang front-end, micro-frontends cho phép các nhóm phát triển, thử nghiệm và triển khai các thành phần giao diện người dùng một cách độc lập. Điều này đặc biệt hữu ích cho các ứng dụng web lớn và phức tạp.
Kiến trúc hướng dịch vụ (SOA)
SOA có thể được xem là tiền thân của microservices . Nó liên quan đến việc chia nhỏ ứng dụng thành các dịch vụ, nhưng các dịch vụ này thường lớn hơn và ít chi tiết hơn so với kiến trúc microservices. Một số tổ chức nhận thấy SOA là một giải pháp trung gian tốt giữa kiến trúc monolithic và microservices.
Đưa ra quyết định: Monolith hay Microservices?
Khi quyết định giữa kiến trúc đơn khối và kiến trúc vi dịch vụ, hãy cân nhắc các yếu tố sau:
- Độ phức tạp của ứng dụng: Các ứng dụng đơn giản với chức năng hạn chế có thể không được hưởng lợi từ độ phức tạp bổ sung của các dịch vụ vi mô.
- Quy mô và cấu trúc nhóm: Các nhóm hoặc tổ chức lớn có nhiều nhóm phát triển có thể được hưởng lợi nhiều hơn từ tính tự chủ mà các dịch vụ vi mô mang lại.
- Yêu cầu về khả năng mở rộng: Nếu các phần khác nhau trong ứng dụng của bạn có nhu cầu mở rộng rất khác nhau, thì dịch vụ vi mô có thể phù hợp hơn.
- Tần suất triển khai: Nếu bạn cần triển khai các bản cập nhật thường xuyên và độc lập cho các phần khác nhau của ứng dụng, các dịch vụ vi mô có thể hỗ trợ việc này.
- Tính đa dạng của công nghệ: Nếu bạn cần sử dụng các công nghệ hoặc ngôn ngữ lập trình khác nhau cho các phần khác nhau của ứng dụng, dịch vụ vi mô sẽ cho phép bạn thực hiện tính linh hoạt này.
- Mức độ trưởng thành của tổ chức: Các dịch vụ vi mô đòi hỏi một mức độ trưởng thành vận hành nhất định. Hãy đảm bảo nhóm của bạn có đủ kỹ năng và công cụ để quản lý hệ thống phân tán hiệu quả.
- Ngân sách và Tài nguyên: Microservices có thể đòi hỏi đầu tư ban đầu nhiều hơn vào cơ sở hạ tầng và công cụ. Hãy đảm bảo bạn có đủ các tài nguyên cần thiết.
- Tăng trưởng trong tương lai: Hãy cân nhắc tương lai của ứng dụng. Nếu bạn dự đoán sự tăng trưởng và độ phức tạp đáng kể, việc bắt đầu với các dịch vụ vi mô (hoặc một khối mô-đun) có thể giúp bạn tránh được quá trình tái cấu trúc phức tạp sau này.
Phần kết luận
Kiến trúc microservices mang lại nhiều lợi thế, đặc biệt là đối với các hệ thống lớn, phức tạp, đòi hỏi khả năng mở rộng và phục hồi cao. Tuy nhiên, kiến trúc này không phải là giải pháp hoàn hảo. Việc lựa chọn giữa kiến trúc monolithic và microservices nên dựa trên sự cân nhắc kỹ lưỡng về nhu cầu, nguồn lực và mục tiêu cụ thể của bạn.
Đối với nhiều tổ chức, hành trình chuyển đổi sang microservices diễn ra dần dần . Bắt đầu với một khối monolith được cấu trúc tốt và dần dần phân tách thành các microservices khi cần thiết có thể là một cách tiếp cận thực tế. Điều này cho phép các nhóm học hỏi và thích nghi trong quá trình triển khai, thay vì phải xử lý tất cả các vấn đề phức tạp của một hệ thống phân tán cùng một lúc.
Bất kể lựa chọn kiến trúc nào, chìa khóa thành công nằm ở các phương pháp phát triển phần mềm tốt: mã nguồn sạch, kiểm thử tự động, tích hợp và phân phối liên tục, và tập trung vào việc mang lại giá trị cho người dùng. Dù là monolithic hay microservices, mục tiêu cuối cùng là tạo ra các ứng dụng mạnh mẽ, có khả năng mở rộng và bảo trì, đáp ứng nhu cầu của người dùng và doanh nghiệp.
Câu hỏi thường gặp
H: Sự khác biệt chính giữa kiến trúc monolithic và microservices là gì?
A: Sự khác biệt chính nằm ở cách cấu trúc ứng dụng. Kiến trúc monolithic tập trung tất cả các tính năng vào một cơ sở mã duy nhất, trong khi kiến trúc microservices chia ứng dụng thành các dịch vụ nhỏ hơn, độc lập, mỗi dịch vụ chịu trách nhiệm cho một chức năng nghiệp vụ cụ thể.
H: Ưu điểm của kiến trúc khối là gì?
A: Ưu điểm của kiến trúc độc khối bao gồm: phát triển và triển khai đơn giản hơn cho các ứng dụng nhỏ, thử nghiệm đầu cuối dễ dàng hơn, xử lý tập trung các mối quan tâm xuyên suốt và hỗ trợ IDE tốt hơn để chạy và thử nghiệm toàn bộ ứng dụng.
H: Những lợi ích chính của kiến trúc vi dịch vụ là gì?
A: Những lợi ích chính của kiến trúc vi dịch vụ bao gồm: phát triển và triển khai dịch vụ độc lập, khả năng sử dụng các công nghệ khác nhau cho các dịch vụ khác nhau, dễ dàng mở rộng quy mô từng dịch vụ, cải thiện khả năng cô lập lỗi và nhanh chóng tuyển dụng thành viên mới vào nhóm.
H: Có nhược điểm nào khi sử dụng kiến trúc vi dịch vụ không?
A: Có, nhược điểm bao gồm độ phức tạp ban đầu tăng lên, thách thức trong việc quản lý giao tiếp giữa các dịch vụ, nhu cầu xử lý các vấn đề về hệ thống phân tán và yêu cầu về các chiến lược thử nghiệm và triển khai phức tạp hơn.
H: Phát triển trên nền tảng đám mây tác động như thế nào đến sự lựa chọn giữa kiến trúc đơn khối và kiến trúc vi dịch vụ?
A: Sự phát triển dựa trên nền tảng đám mây đã khiến các dịch vụ vi mô trở nên hấp dẫn hơn do các nền tảng đám mây cung cấp các dịch vụ phù hợp với các dịch vụ vi mô, chẳng hạn như container hóa (ví dụ: Docker), phối hợp (ví dụ: Kubernetes) và điện toán không máy chủ, giúp triển khai, quản lý và mở rộng các dịch vụ vi mô dễ dàng hơn.
H: Phương pháp kết hợp trong bối cảnh kiến trúc ứng dụng là gì?
A: Một phương pháp kết hợp kết hợp các yếu tố của cả kiến trúc monolithic và microservices. Ví dụ bao gồm monolithic mô-đun (một đơn vị triển khai duy nhất với ranh giới rõ ràng giữa các mô-đun), micro-frontend (áp dụng các khái niệm microservices vào phát triển frontend) và Kiến trúc hướng dịch vụ (SOA), nằm giữa monolithic và microservices về mức độ chi tiết của dịch vụ.
H: Làm thế nào để tôi quyết định nên sử dụng kiến trúc đơn khối hay kiến trúc vi dịch vụ cho ứng dụng của mình?
A: Hãy cân nhắc các yếu tố như độ phức tạp của ứng dụng, quy mô và cấu trúc nhóm, yêu cầu về khả năng mở rộng, tần suất triển khai, nhu cầu đa dạng công nghệ, mức độ trưởng thành của tổ chức, ngân sách và nguồn lực, cũng như dự báo tăng trưởng trong tương lai. Đối với các ứng dụng đơn giản với nhóm nhỏ, mô hình monolithic có thể phù hợp hơn, trong khi các hệ thống lớn, phức tạp với nhiều nhóm có thể được hưởng lợi nhiều hơn từ mô hình microservices.
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
