SOLID Principles - Kim Dung Truyện

 

SOLID Principles - Kim Dung Truyện

                                                                 (internet)


https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

 

SOLID Principles - Kim Dung Truyện
                                                                 Tổ sư, bang chủ Robert C. Martin (internet)


Trong thế giới code hiệp, khi kể đến cao thủ của môn phái Cái Bang, không ai không biết đến bang chủ Robert C. Martin, được gọi thân mật là lão "Uncle Bob". Ông là người đưa đến Cái Bang bí kiếp quý báu đầu tiên đó là cuốn bí kiếp "Design Principles and Design Patterns". 

Cuốn sách này không chỉ là một tuyển tập kiến thức, mà chính là nguồn cảm hứng, là nền tảng vững chắc cho các đệ tử của Cái Bang.

Uncle Bob, với tư cách là bang chủ của Cái Bang, đã truyền đạt những nguyên lý thiết kế và các mẫu thiết kế quý báu, giúp các võ sư trẻ có thể đối mặt với mọi thử thách trong thế giới rộng lớn của lập trình. Như một bậc thầy kiến thức, ông không chỉ dạy kỹ thuật, mà còn truyền đạt tinh thần võ học - lòng kiên nhẫn, sự quyết tâm và lòng trung hiếu đạo.

Dưới bàn tay của bậc kỳ tài code học Uncle Bob, những nguyên lý trở thành bậc thang của võ công lập trình, giúp các võ sư xây dựng mã nguồn vững chắc và dễ dàng bảo trì. Thay vì chỉ dẫn đạo về cú đấm mạnh mẽ, Uncle Bob đã dạy cho các môn sinh cách sử dụng chiêu thức linh hoạt và thông minh, giống như những tuyệt kỹ trong võ lâm.

Nhưng trên hết, Uncle Bob không chỉ là một bang chủ của Cái Bang, mà còn là một huyền thoại trong thế giới võ hiệp lập trình. Nhờ những công trình của mình, ông đã giúp cho Cái Bang phát triển mạnh mẽ, từ những kẻ ăn mày hôi hám vô danh trở thành các cao thủ và có vị thế trong võ lâm.

Vậy nên, tại cái bang, Uncle Bob không chỉ là một lão ăn mày bang chủ, mà là một huyền thoại sống động, một nguồn động viên mãnh liệt và một nguồn đạo lý đằng sau cho mỗi đệ tử trẻ cố gắng trên con đường rèn luyện võ công của mình. Trong lòng môn phái Cái Bang, Uncle Bob không chỉ là một bang chủ, mà là một người anh hùng, một tấm gương sáng của lòng trung hiếu và lòng đam mê không ngừng được sánh ngang với các bang chủ đời trước như Hồng Tứ Hải, Tiêu Phong,Hồng Thất Công

Và nơi đó vị bang chủ này đã khai sinh ra một môn võ công mà đến mãi sau này, các truyền nhân tế hệ sau đã thừa hưởng và phát triển thêm, đến cuối cùng nó được Cái Bang sau này gọi là....


SOLID Principles 


SOLID Principles - Kim Dung Truyện
                                                                 Bang chủ Michael Feathers (internet)


Sự thế thừa đó cuối cùng đã cho ra một cái tên là SOLID, mặc dù không chỉ riêng một người đặt ra mà là các cao thủ của Cái Bang đời sau kế thừa lại. Sự kết hợp của các bang chủ đời sau và các cao thủ trong bang đã cho ra đời cái tên SOLID , và cái tên này được nhiều thế hệ sau nhớ tới bắt nguồn từ  bang chủ đời tiếp theo là bang chủ Michael Feathers.

Câu chuyện về việc Michael Feathers đặt ra từ viết tắt SOLID như một bí mật sâu thẳm đang lan truyền như một truyền thuyết. Người ta kể rằng, sau khi tiếp nhận vị trí bang chủ Cái Bang đời tiếp theo của môn phái, Michael Feathers đã được các bô lão trong bang truyền cuốn bí kiếp võ công từ bang chủ đời trước,một cuốn bí kiếp cổ xưa  cũ kỹ bụi bặm của thời gian.

Cuốn sách này chứa đựng những bí mật của một truyền thống võ học mà không ai biết tới, bí kiếp SOLID. Thông qua nghiên cứu sâu rộng và sự siêng năng lớn lao, đã giải mã được bí mật này và đặt ra từ viết tắt SOLID, mở ra một trang mới trong cuốn sách của võ lâm lập trình.

Nhưng điều kỳ diệu không chỉ đến từ việc Michael Feathers giải mã SOLID, mà còn từ việc ông biết cách tận dụng kiến thức này để giúp đỡ các đệ tử trẻ trên con đường của họ. Ông truyền dạy về Nguyên tắc trách nhiệm duy nhất (Single Responsibility Principle (SRP)), về Nguyên tắc đóng mở (Open-Closed Principle (OCP)), về Nguyên tắt thay thế (Liskov Substitution Principle (LSP)), về Nguyên tắt phân chia Interface (Interface Segregation Principle (ISP) và về Nguyên tắt mềm dẻo không phụ thuộc (Dependency Inversion Principle (DIP)) như những phép thuật lập trình.

Từ khi Michael Feathers tiết lộ ra từ viết tắt SOLID, võ lâm lập trình chưa bao giờ yên bình như vậy. Các đệ tử trẻ không chỉ học được những kỹ năng mới, mà còn nhận thức được giá trị thực sự của việc giữ gìn truyền thống và học hỏi từ những bậc tiền bối. Ông không chỉ là một người giỏi võ công, mà còn là nguồn động viên mãnh liệt, là nguồn sáng soi đường cho tất cả những ai đam mê hành nghề lập trình.

Từ viết tắt SOLID của Michael Feathers, võ lâm lập trình tiếp tục phát triển, rộng mở và hùng mạnh. Những câu chuyện về những người anh hùng giống như ông là nguồn động viên không ngừng, là ngọn đèn soi sáng con đường dẫn đến đỉnh cao của võ học, nơi mà mọi cao thủ đều ao ước đặt chân đến.


Hồi I. Single Responsibility Principle (SRP)

 Single Responsibility Principle (SRP) là một trong những nguyên tắc quan trọng trong lập trình hướng đối tượng. Theo nguyên tắc này, mỗi class hoặc module trong một chương trình nên chỉ có một trách nhiệm duy nhất, nghĩa là chỉ nên thay đổi vì một lý do duy nhất.

Giống như một môn đồ trong môn phái Cái Bang, người tuân thủ nguyên tắc cần chú tâm vào việc truyền đạt và luyện tập các chiêu thức võ công của mình một cách chính xác và hiệu quả nhất. Họ không bao giờ truyền thụ cho môn đồ khác các chiêu không cần thiết hoặc không nằm trong các chiêu thức không phù hợp.

Ví dụ : Trong Cái BangHàng long thập bát chưởng Đã cẩu bổn pháp, là các môn võ trấn bang vì vậy khi truyền lại cho truyền nhân đời tiếp theo cần luyện tập theo cấp độ và từng bước một.

Giống như một môn đồ khi luyện tập chiêu thức thứ nhất của Hàng long thập bát chưởng như :  

Phi Long Tại Thiên: nhảy lên không trung, từ trên cao đánh xuống, uy lực cực mạnh trong một cú. Khi chưa thuần thục hoặc đang xuất chiêu thứ nhất đánh vào đối thủ nhưng đối thủ lại trúng chiêu thứ hai là Kiến Long Tại Điền : chuyển thủ làm công, có thể hóa giải thế lao của địch, thuận thế phản công, phát ra chiêu thức vừa mạnh vừa mau.

Trong lập trình, việc tuân thủ nguyên tắc Single Responsibility Principle đồng nghĩa với việc mỗi class hoặc module chỉ nên chịu trách nhiệm về một nhiệm vụ cụ thể. 

Ví dụ :  Một lớp quản lý người dùng không nên đồng thời chịu trách nhiệm về việc xác thực người dùng và lưu trữ thông tin người dùng vào cơ sở dữ liệu. Thay vào đó, chúng ta nên tách thành hai lớp riêng biệt: một lớp xác thực người dùng và một lớp quản lý cơ sở dữ liệu người dùng. Điều này giúp cho mã nguồn dễ đọc, dễ hiểu và dễ bảo trì hơn.

Nếu ta không tuân thủ nguyên tắc Single Responsibility Principle, mã nguồn có thể trở nên phức tạp và khó hiểu, khiến cho việc phát triển và bảo trì trở nên khó khăn. 

Việc chia nhỏ trách nhiệm giúp chúng ta tối ưu hóa sự linh hoạt và dễ dàng mở rộng hệ thống mà không ảnh hưởng đến các phần khác của mã nguồn, giống như việc các cao thủ trong môn phái Cái Bang chỉ tập trung vào việc rèn luyện võ công của mình mà không làm xao lãng sự chú ý và tập trung. Điều này giúp họ trở thành những cao thủ không ngừng hoàn thiện kỹ năng và đồng thời giữ vững vị thế của môn phái Cái Bang trong võ lâm.


SOLID Principles - Kim Dung Truyện

 

 Hồi II. Open-Closed Principle (OCP)

Open-Closed Principle là một trong những nguyên tắc quan trọng trong nguyên tắc SOLID của lập trình hướng đối tượng. Nguyên tắc này nói rằng một lớp nên mở rộng để mở rộng các chức năng hoặc thêm các tính năng mới mà không cần sửa đổi mã nguồn hiện tại.

Trong các loại võ công  của Cái Bang, việc tuân thủ nguyên tắc Open-Closed Principle giống như việc một môn đồ không cần phải sửa đổi các kỹ thuật võ công cơ bản của mình khi họ học thêm các kỹ thuật mới hoặc phát triển các chiêu thức riêng.

Thay vào đó, họ có thể mở rộng kiến thức của mình mà không ảnh hưởng đến những gì họ đã học trước đó giống như học Đã cẩu bổn pháp không cần phải tập lại đứng tấn vậy.

Trong lập trình, việc tuân thủ nguyên tắc Open-Closed Principle đồng nghĩa với việc chúng ta nên thiết kế các Class và modules sao cho chúng có thể được mở rộng mà không cần phải thay đổi mã nguồn đã tồn tại. Thay vì sửa đổi mã nguồn của một lớp khi cần thêm chức năng mới, chúng ta nên tạo ra các Class mới hoặc Interfaces để thêm các chức năng mới mà không làm ảnh hưởng đến các phần đã hoạt động.

Việc tuân thủ nguyên tắc Open-Closed Principle giúp mã nguồn trở nên linh hoạt hơn và dễ dàng mở rộng trong tương lai mà không phải lo lắng về việc gây ra lỗi trong các phần đã hoạt động. Điều này tạo điều kiện thuận lợi để phát triển và bảo trì ứng dụng một cách hiệu quả và an toàn.


SOLID Principles - Kim Dung Truyện

 

Hồi III. Liskov Substitution Principle (LSP)

Liskov Substitution Principle là một trong những nguyên tắc quan trọng của nguyên tắc SOLID trong lập trình hướng đối tượng. Nguyên tắc này đặt ra rằng các thực thể của một lớp cơ sở(superclass) nên có thể được thay thế bằng các thực thể của lớp con(subclass) mà không làm thay đổi tính đúng đắn của chương trình.

Trong môn phái Cái Bang, việc tuân thủ nguyên tắc Liskov Substitution Principle có thể được hiểu như việc bất kỳ đệ tử nào của môn phái Cái Bang cũng nên có thể tham gia vào các trận đấu võ thuật mà không làm mất đi danh dự hoặc hiệu suất của môn phái. Điều này đảm bảo rằng mỗi đệ tử đều có khả năng thể hiện bản thân một cách đồng nhất và đúng đắn như các cao thủ.

Trong lập trình, việc tuân thủ nguyên tắc Liskov Substitution Principle đồng nghĩa với việc các lớp con(subclasses) nên thừa hưởng và mở rộng (inherit và extend)các chức năng của lớp cơ sở(superclass) mà không làm thay đổi hành vi của chương trình khi sử dụng các thực thể của các lớp con(subclasses) thay thế cho lớp cơ sở(superclass). Điều này giúp cho việc sử dụng các đối tượng tương tự nhau một cách nhất quán và dễ dàng bảo trì.

Nếu nguyên tắc Liskov Substitution Principle không được tuân thủ, việc sử dụng các đối tượng của các lớp con(subclasses) có thể dẫn đến các hành vi không mong muốn hoặc lỗi trong chương trình, gây ra các vấn đề khó xác định và sửa chữa. Điều này làm giảm tính linh hoạt và sự tin cậy của mã nguồn, gây khó khăn trong việc phát triển và bảo trì ứng dụng.


SOLID Principles - Kim Dung Truyện


Hồi IV. Interface Segregation Principle (ISP)

Interface Segregation Principle  là một trong những nguyên tắc trong nguyên tắc SOLID của lập trình hướng đối tượng. Nguyên tắc này đề xuất rằng một lớp không nên bị ép buộc để triển khai các phương thức mà nó không sử dụng. Thay vào đó, nên tạo ra các giao diện nhỏ, tinh gọn chỉ chứa các phương thức cần thiết cho các lớp sử dụng chúng.

Trong môn phái Cái Bang, việc tuân thủ nguyên tắc Interface Segregation Principle  có thể được hiểu như việc mỗi môn đồ chỉ nên học những kỹ thuật và chiêu thức võ công mà họ thực sự cần để trở thành cao thủ võ lâm. Họ không nên bị ép buộc phải học những chiêu thức không liên quan chỉ để đạt được danh hiệu hoặc vị thế trong môn phái.

Ví dụ  : nếu một cao thủ Cái Bang học Hàng long thập bát chưởng nếu xuất sắc chỉ cần đến cấp 12 như Kháng Long Hữu Hối : chiêu thức cực mạnh, bá lực đương thời là vô địch, lợi hại ở chỗ xuất chiêu vẫn bảo lưu, nhân lúc kẻ địch hấp hối thì vồ thêm một cú cũng đủ làm cho đối phương phá vỡ toàn bộ kinh mạch không thể cứu chữa.

Trong lập trình, việc tuân thủ nguyên tắc Interface Segregation Principle  đồng nghĩa với việc tạo ra các interfaces nhỏ và tinh gọn chứa ít phương thức nhất có thể. Điều này giúp tránh việc các lớp phải triển khai các phương thức không liên quan đến chúng, giảm thiểu sự phức tạp và làm cho mã nguồn trở nên dễ đọc và hiểu hơn.

Khi các giao diện được thiết kế chính xác và tách biệt, các lớp chỉ cần triển khai các phương thức cần thiết cho chúng. Điều này tăng tính modularity(một khái niệm chia nhỏ trong hệ thống thành các  modules hoặc components), giúp cho việc mở rộng và bảo trì mã nguồn trở nên dễ dàng hơn. 

Việc tuân thủ nguyên tắc Interface Segregation Principle  giúp tránh được sự phụ thuộc không mong muốn giữa các lớp và giao diện, giữ cho hệ thống linh hoạt và dễ dàng thay đổi khi cần thiết.

SOLID Principles - Kim Dung Truyện



Hồi V. Dependency Inversion Principle (DIP)

Dependency Inversion Principle  là một trong những nguyên tắc quan trọng của nguyên tắc SOLID trong lập trình hướng đối tượng. Nguyên tắc này nói rằng các module cấp cao(high-level modules) không nên phụ thuộc vào các module cấp thấp(low-level modules). Cả hai nên phụ thuộc vào một Interface hoặc các lớp trừu tượng (Abtraction Class) và không nên phụ thuộc vào chi tiết cụ thể.

Trong môn phái Cái Bang, việc tuân thủ nguyên tắc Dependency Inversion Principle  có thể được hiểu như việc khi học xong Hàng long thập bát chưởng có 18 thức (Phi Long Tại Thiên, Kiến Long Tại Điền, Hồng Tiệm Vu Lục, Tiềm Long Vật Dụng, Lợi Thiệp Đại Xuyên, Thần Long Bãi Vĩ, Đột Như Kì Lai, Song Long Thủ Thủy, Thời Thừa Lục Long, Long Chiến Tại Dã, Lí Sương Băng Chí, Kháng Long Hữu Hối, Tả Hữu Thần Long, Giao Long Phiên Giang, Cuồng Long Loạn Vũ, Bất Kham Nhất Kích, Long Du Thiên Địa, Long Đằng Ngũ Nhạc) thì mỗi môn đồ những ai được truyền thụ qua các đời khi đã luyện thành thì khi sử dụng chiêu thức tùy vào tình huống có thể xuất chiêu, cũng như có thể dùng Cuồng Long Loạn Vũ hay  Song Long Thủ Thủy…  không phải cần xuất chiêu thứ tự chiêu thứ nhất đến chiêu cuối cùng.

Giống như việc cao thủ này vẫn phải tuân thủ các quy tắc và cách xuất chiêu của 18 thức, nhưng có thế chọn 1 trong các chiêu phù hợp vào từng tình huống.

Trong lập trình, việc tuân thủ nguyên tắc Dependency Inversion Principle  đồng nghĩa với việc các lớp cấp cao(high-level classes) không nên biết về chi tiết cụ thể của các lớp cấp thấp(low-level classes), mà cả hai nên phụ thuộc vào các giao diện hoặc lớp trừu tượng(interfaces hoặc abstract classes). Điều này tạo ra sự linh hoạt trong việc thay đổi và cải thiện các module mà không làm ảnh hưởng đến các phần khác của hệ thống.

Khi các phụ thuộc được quản lý thông qua các giao diện hoặc lớp trừu tượng(interfaces hoặc abstract classes), chúng ta có thể dễ dàng thay đổi hoặc thay thế các module mà không làm ảnh hưởng đến các phần khác của hệ thống. 

Điều này giúp cho mã nguồn trở nên dễ dàng bảo trì, mở rộng và thử nghiệm, đồng thời tăng cường tính linh hoạt và tái sử dụng trong quá trình phát triển ứng dụng.

SOLID Principles - Kim Dung Truyện


 

Nhãn:

The Twelve Factor App - Kim Dung Truyện


The Twelve Factor App - Kim Dung Truyện
                                                                            (internet)
https://12factor.net/

 

Hồi I. Codebase

Codebase của một ứng dụng 12 factor giống như một quyển bí kíp võ công được lưu giữ cẩn thận trong mật thất của một môn phái. Nó được theo dõi chặt chẽ trong hệ thống kiểm soát phiên bản và có thể được triển khai nhiều lần.


Hồi II. Dependencies

Dependencies của một ứng dụng 12 factor giống như những thuộc tính của một cao thủ võ lâm. Chúng cần được khai báo và cô lập một cách rõ ràng để tránh những xung đột không đáng có.


Hồi III. Config 

Cấu hình của một ứng dụng 12 factor giống như những quy tắc của một môn phái võ công. Chúng cần được lưu trữ trong môi trường để tất cả các đệ tử đều có thể dễ dàng tiếp cận và tuân theo.


Hồi IV. Backing services

Backing services của một ứng dụng 12 factor giống như những tài nguyên của một môn phái võ công, chẳng hạn như binh khí, áo giáp, ngựa chiến,... Chúng cần được coi như những tài nguyên được đính kèm và có thể được sử dụng một cách linh hoạt.


Hồi V. Build, release, run

Các giai đoạn xây dựng, phát hành và chạy của một ứng dụng 12 factor giống như những giai đoạn luyện tập, thi đấu và thực chiến của một môn phái võ công. Chúng cần được tách biệt hoàn toàn để đảm bảo rằng ứng dụng luôn có thể hoạt động một cách ổn định và hiệu quả.


Hồi VI. Processes

Một ứng dụng 12 factor được thực thi dưới dạng một hoặc nhiều quy trình không trạng thái. Điều này giống như việc một cao thủ võ lâm cần phải giữ cho tinh thần của mình luôn tỉnh táo và sáng suốt trong khi chiến đấu.


Hồi VII. Port binding 

Các dịch vụ của một ứng dụng 12 factor được xuất thông qua việc liên kết cổng. Điều này giống như việc một môn phái võ công cần phải có một tấm biển hiệu để cho mọi người biết rằng họ đang mở một võ đường.


Hồi VIII. Concurrency

Một ứng dụng 12 factor có thể được mở rộng quy mô theo mô hình quy trình. Điều này giống như việc một môn phái võ công có thể đào tạo nhiều đệ tử cùng một lúc.


Hồi IX. Disposability

Một ứng dụng 12 factor phải có khả năng khởi động nhanh chóng và đóng cửa duyên dáng. Điều này giống như việc một cao thủ võ lâm cần có thể sẵn sàng chiến đấu bất cứ lúc nào và rút lui một cách an toàn khi cần thiết.


Hồi X. Dev/prod parity

Các môi trường phát triển, dàn dựng và sản xuất của một ứng dụng 12 factor phải được giữ càng giống nhau càng tốt. Điều này giống như việc một môn phái võ công cần phải có những môi trường luyện tập mô phỏng theo môi trường chiến đấu thực tế nhất có thể.


Hồi XI. Logs 

Các nhật ký của một ứng dụng 12 factor được coi như những kinh nghiệm chiến đấu của một môn phái võ công. Chúng cần được ghi chép lại một cách cẩn thận để có thể rút ra được những bài học quý giá và cải thiện sức mạnh của môn phái.


Hồi XII. Admin processes

Các tác vụ quản trị/quản lý của một ứng dụng 12 factor được chạy dưới dạng các quy trình một lần. Điều này giống như việc một môn phái võ công cần phải có những chiến thuật cụ thể để đối phó với những tình huống bất ngờ.


Tóm lại, 12 factor app giống như một quyển bí kíp võ công giúp các nhà phát triển xây dựng và triển khai các ứng dụng một cách hiệu quả và đáng tin cậy. Nó giúp các ứng dụng có thể dễ dàng mở rộng quy mô, chịu lỗi cao và dễ dàng bảo trì.


Hồi I : 

The Twelve Factor App - Kim Dung Truyện
                                                                        (internet)

Codebase giống như một bí kíp võ công được lưu giữ cẩn thận trong mật thất của một môn phái. Nó bao gồm tất cả các bí quyết võ công của môn phái, từ những chiêu thức cơ bản đến những chiêu thức cao cấp.

Bí kíp võ công này được ghi chép lại trong một quyển sách, và tất cả các đệ tử của môn phái đều có thể tham khảo quyển sách này để học tập và luyện tập. Tuy nhiên, mỗi đệ tử đều có thể có một bản sao của quyển sách này, và họ có thể tự do nghiên cứu và phát triển thêm các chiêu thức võ công mới.

Tương tự như vậy, codebase của một 12 factor app được lưu trữ trong một hệ thống kiểm soát phiên bản, chẳng hạn như Git, Mercurial hoặc Subversion. Tất cả các nhà phát triển của ứng dụng đều có thể truy cập codebase này để chỉnh sửa và phát triển ứng dụng. Tuy nhiên, mỗi nhà phát triển đều có thể có một bản sao riêng của codebase, và họ có thể tự do phát triển các tính năng mới mà không ảnh hưởng đến những người khác.

Một lợi ích quan trọng của việc có codebase duy nhất là nó giúp cho việc triển khai ứng dụng trở nên dễ dàng hơn. Các nhà phát triển có thể chỉ cần triển khai codebase mới nhất lên môi trường sản xuất, và ứng dụng sẽ được cập nhật lên phiên bản mới nhất.

Ngoài ra, việc có codebase duy nhất cũng giúp cho việc bảo trì ứng dụng trở nên dễ dàng hơn. Các nhà phát triển có thể dễ dàng theo dõi các thay đổi đã được thực hiện cho ứng dụng, và họ có thể dễ dàng khắc phục các lỗi.

Tóm lại, codebase duy nhất là một yếu tố quan trọng của 12 factor app. Nó giúp cho việc phát triển, triển khai và bảo trì ứng dụng trở nên dễ dàng hơn.

Ví dụ:

Một môn phái võ công tên là Cái Bang có một quyển bí kíp võ công có tên là Cái Bang Đả Cẩu Bổng Pháp. Quyển bí kíp này được lưu giữ cẩn thận trong mật thất của môn phái, và tất cả các đệ tử của Cái Bang đều có thể tham khảo quyển sách này để học tập và luyện tập.

Mỗi đệ tử của Cái Bang đều có một bản sao của quyển bí kíp võ công này, và họ có thể tự do nghiên cứu và phát triển thêm các chiêu thức võ công mới. Tuy nhiên, tất cả các chiêu thức võ công mới này đều phải dựa trên nền tảng cơ bản của Cái Bang Đả Cẩu Bổng Pháp.

Tương tự như vậy, codebase của một 12 factor app cũng phải được quản lý một cách cẩn thận và thống nhất. Tất cả các nhà phát triển của ứng dụng đều phải tuân theo các quy tắc nhất định khi phát triển ứng dụng, chẳng hạn như sử dụng cùng một ngôn ngữ lập trình, cùng một bộ khung phát triển và cùng một quy ước lập trình.

Việc quản lý codebase một cách cẩn thận và thống nhất sẽ giúp cho việc phát triển, triển khai và bảo trì ứng dụng trở nên dễ dàng hơn.


Hồi II : 

The Twelve Factor App - Kim Dung Truyện

                                                                        (internet)

Dependencies trong 12 factor app giống như những bí quyết võ công của một môn phái.

Mỗi môn phái võ công đều có những bí quyết võ công riêng, và những bí quyết võ công này được truyền thụ từ đời này sang đời khác. Các đệ tử của môn phái phải học tập và luyện tập những bí quyết võ công này để có thể trở thành những võ sĩ giỏi.

Tương tự như vậy, mỗi 12 factor app đều có những dependencies riêng. Dependencies là những thư viện hoặc công cụ mà ứng dụng cần để có thể hoạt động. Các nhà phát triển của ứng dụng phải khai báo rõ ràng tất cả các dependencies của ứng dụng, và họ phải sử dụng các dependency manager để quản lý các dependencies này.

Việc khai báo rõ ràng dependencies của ứng dụng có nhiều lợi ích. Đầu tiên, nó giúp cho việc thiết lập môi trường phát triển và môi trường sản xuất cho ứng dụng trở nên dễ dàng hơn. Thứ hai, nó giúp cho việc bảo trì ứng dụng trở nên dễ dàng hơn. Thứ ba, nó giúp cho ứng dụng có thể hoạt động một cách ổn định và đáng tin cậy hơn.

Ví dụ:

Môn phái Cái Bang có một bí quyết võ công gọi là Cái Bang Đả Cẩu Bổng Pháp. Bí quyết võ công này bao gồm tất cả các chiêu thức võ công của môn phái Cái Bang, từ những chiêu thức cơ bản đến những chiêu thức cao cấp.

Để học tập và luyện tập bí quyết võ công này, các đệ tử của môn phái Cái Bang phải có cây đả cẩu bổng. Cây đả cẩu bổng là một vũ khí quan trọng của môn phái Cái Bang, và nó được sử dụng trong hầu hết các chiêu thức võ công của môn phái này.

Tương tự như vậy, một 12 factor app cần phải có một dependency manager để quản lý các dependencies của nó. Dependency manager là một công cụ giúp cho các nhà phát triển có thể khai báo rõ ràng tất cả các dependencies của ứng dụng, và nó giúp cho họ có thể dễ dàng cài đặt và cập nhật các dependencies này.

Một số dependency manager phổ biến hiện nay là Maven (Java), Gradle (Java), Bundler (Ruby), Pip (Python), npm (JavaScript).

Tóm lại, dependencies là một yếu tố quan trọng của 12 factor app. Việc khai báo rõ ràng dependencies của ứng dụng và sử dụng dependency manager để quản lý các dependencies này sẽ giúp cho việc phát triển, triển khai và bảo trì ứng dụng trở nên dễ dàng hơn.


Hồi III :

The Twelve Factor App - Kim Dung Truyện
                                                                        (internet)

Config trong 12 factor app giống như những quy tắc võ công của một môn phái.

Mỗi môn phái võ công đều có những quy tắc võ công riêng, và những quy tắc võ công này được truyền thụ từ đời này sang đời khác. Các đệ tử của môn phái phải tuân theo những quy tắc võ công này để có thể trở thành những võ sĩ giỏi.

Tương tự như vậy, mỗi 12 factor app đều có những config riêng. Config là những thông tin về cách cấu hình ứng dụng, chẳng hạn như thông tin về cơ sở dữ liệu, thông tin về các dịch vụ bên ngoài và thông tin về các giá trị mặc định của ứng dụng.

Các config của ứng dụng phải được lưu trữ trong môi trường (environment). Điều này có nghĩa là các config phải được lưu trữ ở một nơi mà tất cả các bản triển khai của ứng dụng đều có thể truy cập được, chẳng hạn như trong hệ thống môi trường của máy chủ.

Việc lưu trữ config trong môi trường có nhiều lợi ích. Đầu tiên, nó giúp cho việc triển khai ứng dụng trở nên dễ dàng hơn. Thứ hai, nó giúp cho việc bảo mật các thông tin nhạy cảm của ứng dụng trở nên tốt hơn. Thứ ba, nó giúp cho việc quản lý các config của ứng dụng trở nên dễ dàng hơn.

Ví dụ:

Môn phái Cái Bang có những quy tắc võ công riêng, chẳng hạn như quy tắc về cách sử dụng đả cẩu bổng, quy tắc về cách di chuyển và quy tắc về cách chiến đấu. Các đệ tử của môn phái Cái Bang phải tuân theo những quy tắc võ công này để có thể trở thành những võ sĩ giỏi.

Tương tự như vậy, một 12 factor app có những config riêng, chẳng hạn như config về kết nối cơ sở dữ liệu, config về kết nối các dịch vụ bên ngoài và config về các giá trị mặc định của ứng dụng. Các config này phải được lưu trữ trong môi trường (environment).

Một số cách lưu trữ config trong môi trường phổ biến hiện nay là:

Sử dụng các biến môi trường (environment variables)

Sử dụng các tệp cấu hình (configuration files)

Sử dụng các cơ sở dữ liệu (databases)

Tóm lại, config là một yếu tố quan trọng của 12 factor app. Việc lưu trữ config trong môi trường sẽ giúp cho việc triển khai ứng dụng, bảo mật các thông tin nhạy cảm của ứng dụng và quản lý các config của ứng dụng trở nên dễ dàng hơn.


Hồi IV: 

The Twelve Factor App - Kim Dung Truyện

                                                                     (internet)

Backing services trong 12 factor app giống như những tài nguyên hỗ trợ của một môn phái võ công.

Mỗi môn phái võ công đều có những tài nguyên hỗ trợ riêng, chẳng hạn như binh khí, áo giáp, ngựa chiến,... Những tài nguyên hỗ trợ này giúp cho các đệ tử của môn phái có thể luyện tập võ công và chiến đấu một cách hiệu quả hơn.

Tương tự như vậy, mỗi 12 factor app đều có những backing services riêng. Backing services là những dịch vụ mà ứng dụng sử dụng để hoạt động bình thường. Ví dụ về các backing services bao gồm:

Cơ sở dữ liệu (database)

Hệ thống nhắn tin (messaging system)

Hệ thống cache (caching system)

Dịch vụ gửi email (SMTP service)

Các backing services của một 12 factor app được coi là những tài nguyên được đính kèm. Điều này có nghĩa là các backing services có thể được kết nối và ngắt kết nối với ứng dụng một cách dễ dàng.

Việc coi các backing services là những tài nguyên được đính kèm có nhiều lợi ích. Đầu tiên, nó giúp cho việc triển khai ứng dụng trở nên dễ dàng hơn. Thứ hai, nó giúp cho việc bảo trì ứng dụng trở nên dễ dàng hơn. Thứ ba, nó giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn.

Ví dụ:

Môn phái Cái Bang có những tài nguyên hỗ trợ riêng, chẳng hạn như đả cẩu bổng, áo giáp và ngựa chiến. Những tài nguyên hỗ trợ này giúp cho các đệ tử của môn phái Cái Bang có thể luyện tập võ công và chiến đấu một cách hiệu quả hơn.

Tương tự như vậy, một 12 factor app có những backing services riêng, chẳng hạn như cơ sở dữ liệu, hệ thống nhắn tin và hệ thống cache. Những backing services này giúp cho ứng dụng có thể hoạt động một cách bình thường.

Các backing services của một 12 factor app được coi là những tài nguyên được đính kèm. Điều này có nghĩa là các backing services có thể được kết nối và ngắt kết nối với ứng dụng một cách dễ dàng.

Ví dụ, nếu cơ sở dữ liệu của ứng dụng đang gặp vấn đề, quản trị viên của ứng dụng có thể chuyển sang sử dụng một cơ sở dữ liệu khác mà không cần thay đổi mã của ứng dụng.

Tóm lại, backing services là một yếu tố quan trọng của 12 factor app. Việc coi các backing services là những tài nguyên được đính kèm sẽ giúp cho việc triển khai ứng dụng, bảo trì ứng dụng và mở rộng quy mô ứng dụng trở nên dễ dàng hơn.


Hồi V:

The Twelve Factor App - Kim Dung Truyện
                                                                        (internet)

Build, release, run trong 12 factor app giống như những giai đoạn luyện tập, thi đấu và thực chiến của một môn phái võ công.

Giai đoạn build giống như giai đoạn luyện tập của một môn phái võ công. Trong giai đoạn này, các môn đồ sẽ học tập các lý thuyết võ công và luyện tập các chiêu thức võ công cơ bản.

Giai đoạn release giống như giai đoạn thi đấu của một môn phái võ công. Trong giai đoạn này, các môn đồ sẽ tham gia các cuộc thi đấu để kiểm tra trình độ võ công của mình và để học hỏi thêm kinh nghiệm.

Giai đoạn run giống như giai đoạn thực chiến của một môn phái võ công. Trong giai đoạn này, các môn đồ sẽ sử dụng võ công của mình để chiến đấu với kẻ thù.

12 factor app có sự tách biệt rõ ràng giữa ba giai đoạn build, release và run. Điều này giúp cho việc phát triển, triển khai và bảo trì ứng dụng trở nên dễ dàng hơn.

Ví dụ:

Môn phái Cái Bang có ba giai đoạn luyện tập, thi đấu và thực chiến.

Giai đoạn luyện tập: Trong giai đoạn này, các đệ tử của Cái Bang sẽ học tập các lý thuyết võ công Cái Bang Đả Cẩu Bổng Pháp và luyện tập các chiêu thức võ công cơ bản.

Giai đoạn thi đấu: Trong giai đoạn này, các đệ tử của Cái Bang sẽ tham gia các cuộc thi đấu võ công với các môn phái khác để kiểm tra trình độ võ công của mình và để học hỏi thêm kinh nghiệm.

Giai đoạn thực chiến: Trong giai đoạn này, các đệ tử của Cái Bang sẽ sử dụng võ công Cái Bang Đả Cẩu Bổng Pháp để chiến đấu với kẻ thù.

12 factor app có sự tách biệt rõ ràng giữa ba giai đoạn build, release và run. Điều này giúp cho việc phát triển, triển khai và bảo trì ứng dụng trở nên dễ dàng hơn.

Ví dụ:

Một ứng dụng 12 factor app có ba giai đoạn build, release và run.

Giai đoạn build: Trong giai đoạn này, các nhà phát triển sẽ biên dịch và đóng gói mã ứng dụng thành một gói thực thi.

Giai đoạn release: Trong giai đoạn này, các nhà phát triển sẽ kết hợp gói thực thi với tệp cấu hình của ứng dụng để tạo thành một bản phát hành.

Giai đoạn run: Trong giai đoạn này, các nhà phát triển sẽ khởi động ứng dụng từ bản phát hành.

Sự tách biệt rõ ràng giữa ba giai đoạn build, release và run giúp cho việc phát triển, triển khai và bảo trì ứng dụng 12 factor app trở nên dễ dàng hơn.


Hồi VI:

The Twelve Factor App - Kim Dung Truyện
                                                                            (internet)

Processes trong 12 factor app giống như những đệ tử của một môn phái võ công.

Mỗi đệ tử của một môn phái võ công đều phải học tập các lý thuyết võ công và luyện tập các chiêu thức võ công. Khi ra đòn, mỗi đệ tử đều phải sử dụng hết sức mạnh của mình để đánh bại đối thủ.

Tương tự như vậy, mỗi process trong 12 factor app đều phải thực hiện các công việc được giao một cách độc lập và hiệu quả. Các process không được lưu trữ bất kỳ dữ liệu nào trong bộ nhớ của mình. Tất cả dữ liệu đều phải được lưu trữ trong các backing services, chẳng hạn như cơ sở dữ liệu.

Việc sử dụng các process stateless có nhiều lợi ích. Đầu tiên, nó giúp cho việc triển khai ứng dụng trở nên dễ dàng hơn. Thứ hai, nó giúp cho việc bảo trì ứng dụng trở nên dễ dàng hơn. Thứ ba, nó giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn.

Ví dụ:

Môn phái Cái Bang có nhiều đệ tử. Mỗi đệ tử đều phải học tập các lý thuyết võ công Cái Bang Đả Cẩu Bổng Pháp và luyện tập các chiêu thức võ công. Khi ra đòn, mỗi đệ tử đều phải sử dụng hết sức mạnh của mình để đánh bại đối thủ.

Tương tự như vậy, một 12 factor app có nhiều process. Mỗi process đều phải thực hiện các công việc được giao một cách độc lập và hiệu quả. Các process không được lưu trữ bất kỳ dữ liệu nào trong bộ nhớ của mình. Tất cả dữ liệu đều phải được lưu trữ trong cơ sở dữ liệu.

Việc sử dụng các process stateless có nhiều lợi ích. Đầu tiên, nó giúp cho việc triển khai ứng dụng trở nên dễ dàng hơn. Thứ hai, nó giúp cho việc bảo trì ứng dụng trở nên dễ dàng hơn. Thứ ba, nó giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn.

Ví dụ:

Một 12 factor app có nhiều process, chẳng hạn như process xử lý yêu cầu HTTP, process xử lý yêu cầu email và process xử lý yêu cầu cron. Mỗi process đều có trách nhiệm riêng của mình và không được lưu trữ bất kỳ dữ liệu nào trong bộ nhớ của mình. Tất cả dữ liệu đều phải được lưu trữ trong cơ sở dữ liệu.

Việc sử dụng các process stateless giúp cho việc triển khai ứng dụng trở nên dễ dàng hơn. Các nhà phát triển chỉ cần triển khai các process mới lên môi trường sản xuất và ứng dụng sẽ được cập nhật lên phiên bản mới nhất.

Việc sử dụng các process stateless cũng giúp cho việc bảo trì ứng dụng trở nên dễ dàng hơn. Các nhà phát triển có thể dễ dàng theo dõi các thay đổi đã được thực hiện cho ứng dụng và họ có thể dễ dàng khắc phục các lỗi.

Việc sử dụng các process stateless cũng giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn. Các nhà phát triển có thể dễ dàng thêm các process mới vào ứng dụng để xử lý nhiều yêu cầu hơn.

Tóm lại, processes là một yếu tố quan trọng của 12 factor app. Việc sử dụng các process stateless sẽ giúp cho việc triển khai ứng dụng, bảo trì ứng dụng và mở rộng quy mô ứng dụng trở nên dễ dàng hơn.


Hồi VII : 

The Twelve Factor App - Kim Dung Truyện
                                                                            (internet)

Port binding trong 12 factor app giống như việc các đệ tử của một môn phái võ công mở võ đường để truyền dạy võ công.

Mỗi võ đường đều có một địa chỉ cụ thể, và các đệ tử võ công có thể đến võ đường để học tập và luyện tập võ công.

Tương tự như vậy, mỗi process trong 12 factor app đều có một port cụ thể, và các ứng dụng khác có thể kết nối với process đó để sử dụng các dịch vụ mà process đó cung cấp.

Việc sử dụng port binding có nhiều lợi ích. Đầu tiên, nó giúp cho việc triển khai ứng dụng trở nên dễ dàng hơn. Thứ hai, nó giúp cho việc bảo trì ứng dụng trở nên dễ dàng hơn. Thứ ba, nó giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn.

Ví dụ:

Môn phái Cái Bang có một võ đường ở thành phố A. Các đệ tử võ công có thể đến võ đường này để học tập và luyện tập võ công Cái Bang Đả Cẩu Bổng Pháp.

Tương tự như vậy, một 12 factor app có một process cung cấp dịch vụ HTTP. Process này sẽ binding với một port cụ thể, chẳng hạn như port 80. Các ứng dụng khác có thể kết nối với port này để sử dụng dịch vụ HTTP của process này.

Việc sử dụng port binding có nhiều lợi ích. Đầu tiên, nó giúp cho việc triển khai ứng dụng trở nên dễ dàng hơn. Các nhà phát triển chỉ cần triển khai process mới lên môi trường sản xuất và ứng dụng sẽ được cập nhật lên phiên bản mới nhất.

Việc sử dụng port binding cũng giúp cho việc bảo trì ứng dụng trở nên dễ dàng hơn. Các nhà phát triển có thể dễ dàng theo dõi các thay đổi đã được thực hiện cho ứng dụng và họ có thể dễ dàng khắc phục các lỗi.

Việc sử dụng port binding cũng giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn. Các nhà phát triển có thể dễ dàng thêm các process mới vào ứng dụng để xử lý nhiều yêu cầu hơn.

Tóm lại, port binding là một yếu tố quan trọng của 12 factor app. Việc sử dụng port binding sẽ giúp cho việc triển khai ứng dụng, bảo trì ứng dụng và mở rộng quy mô ứng dụng trở nên dễ dàng hơn.


Hồi VIII:

The Twelve Factor App - Kim Dung Truyện
                                                                            (internet)

Concurrency trong 12 factor app giống như việc các đệ tử của một môn phái võ công phối hợp với nhau để chiến đấu với kẻ thù.

Mỗi đệ tử võ công đều có những kỹ năng và sức mạnh khác nhau. Khi chiến đấu, các đệ tử võ công có thể phối hợp với nhau để phát huy tối đa sức mạnh của mình và đánh bại kẻ thù.

Tương tự như vậy, mỗi process trong 12 factor app đều có những chức năng khác nhau. Các process có thể phối hợp với nhau để xử lý nhiều yêu cầu hơn và tăng hiệu suất của ứng dụng.

Việc sử dụng concurrency có nhiều lợi ích. Đầu tiên, nó giúp cho ứng dụng có thể xử lý nhiều yêu cầu hơn. Thứ hai, nó giúp cho ứng dụng có thể phản hồi yêu cầu của người dùng nhanh hơn. Thứ ba, nó giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn.

Ví dụ:

Một môn phái võ công có nhiều đệ tử, mỗi đệ tử đều có những kỹ năng và sức mạnh khác nhau. Khi chiến đấu với kẻ thù, các đệ tử võ công có thể phối hợp với nhau để phát huy tối đa sức mạnh của mình và đánh bại kẻ thù. Ví dụ, một đệ tử võ công có thể tấn công kẻ thù từ phía trước, trong khi một đệ tử võ công khác có thể tấn công kẻ thù từ phía sau.

Tương tự như vậy, một 12 factor app có nhiều process, mỗi process đều có một chức năng khác nhau. Ví dụ, một process có thể xử lý yêu cầu HTTP, trong khi một process khác có thể xử lý các tác vụ nền dài hạn. Các process có thể phối hợp với nhau để xử lý nhiều yêu cầu hơn và tăng hiệu suất của ứng dụng.

Việc sử dụng concurrency có nhiều lợi ích. Đầu tiên, nó giúp cho ứng dụng có thể xử lý nhiều yêu cầu hơn. Thứ hai, nó giúp cho ứng dụng có thể phản hồi yêu cầu của người dùng nhanh hơn. Thứ ba, nó giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn. Ví dụ, nếu một ứng dụng có nhiều người dùng truy cập cùng lúc, các nhà phát triển có thể dễ dàng thêm các process mới vào ứng dụng để xử lý nhiều yêu cầu hơn.

Tóm lại, concurrency là một yếu tố quan trọng của 12 factor app. Việc sử dụng concurrency sẽ giúp cho ứng dụng có thể xử lý nhiều yêu cầu hơn, phản hồi yêu cầu của người dùng nhanh hơn và mở rộng quy mô một cách dễ dàng hơn.


Hồi IX:

The Twelve Factor App - Kim Dung Truyện

                                                                            (internet)

Disposability trong 12 factor app giống như việc các đệ tử của một môn phái võ công phải luôn sẵn sàng chiến đấu.

Các đệ tử võ công phải luôn sẵn sàng chiến đấu, bất kể ngày đêm, bất kể thời tiết. Họ phải có thể nhanh chóng vào vị trí và chiến đấu với kẻ thù.

Tương tự như vậy, các process trong 12 factor app phải luôn sẵn sàng xử lý yêu cầu, bất kể thời gian nào trong ngày. Các process phải có thể nhanh chóng khởi động và bắt đầu xử lý yêu cầu.

Việc sử dụng disposability có nhiều lợi ích. Đầu tiên, nó giúp cho ứng dụng có thể phản hồi yêu cầu của người dùng nhanh hơn. Thứ hai, nó giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn. Thứ ba, nó giúp cho ứng dụng có thể phục hồi sau lỗi nhanh hơn.

Ví dụ:

Một môn phái võ công có nhiều đệ tử, và các đệ tử này luôn sẵn sàng chiến đấu. Khi kẻ thù tấn công, các đệ tử võ công có thể nhanh chóng vào vị trí và chiến đấu với kẻ thù.

Tương tự như vậy, một 12 factor app có nhiều process, và các process này luôn sẵn sàng xử lý yêu cầu. Khi có yêu cầu từ người dùng, các process có thể nhanh chóng khởi động và bắt đầu xử lý yêu cầu.

Việc sử dụng disposability có nhiều lợi ích. Đầu tiên, nó giúp cho ứng dụng có thể phản hồi yêu cầu của người dùng nhanh hơn. Ví dụ, nếu một ứng dụng có nhiều người dùng truy cập cùng lúc, các nhà phát triển có thể dễ dàng thêm các process mới vào ứng dụng để xử lý nhiều yêu cầu hơn.

Thứ hai, việc sử dụng disposability giúp cho ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn. Ví dụ, nếu một ứng dụng có nhiều người dùng truy cập cùng lúc, các nhà phát triển có thể dễ dàng thêm các process mới vào ứng dụng để xử lý nhiều yêu cầu hơn.

Thứ ba, việc sử dụng disposability giúp cho ứng dụng có thể phục hồi sau lỗi nhanh hơn. Ví dụ, nếu một process gặp lỗi, các nhà phát triển có thể dễ dàng khởi động lại process đó mà không ảnh hưởng đến các process khác.

Tóm lại, disposability là một yếu tố quan trọng của 12 factor app. Việc sử dụng disposability sẽ giúp cho ứng dụng có thể phản hồi yêu cầu của người dùng nhanh hơn, mở rộng quy mô một cách dễ dàng hơn và phục hồi sau lỗi nhanh hơn.


Hồi X:

The Twelve Factor App - Kim Dung Truyện
                                                                            (internet)

Dev/prod parity trong 12 factor app giống như việc các đệ tử của một môn phái võ công phải luyện tập võ công theo cùng một phương pháp, bất kể họ đang ở đâu.

Các đệ tử của một môn phái võ công phải luyện tập võ công theo cùng một phương pháp, bất kể họ đang ở đâu, trong võ đường hay trên chiến trường. Điều này giúp cho các đệ tử võ công có thể dễ dàng phối hợp với nhau khi chiến đấu.

Tương tự như vậy, các môi trường phát triển, staging và sản xuất của một 12 factor app phải được cấu hình giống nhau nhất có thể. Điều này giúp cho các nhà phát triển dễ dàng triển khai ứng dụng lên môi trường sản xuất hơn và giúp cho ứng dụng hoạt động ổn định hơn trên môi trường sản xuất.

Việc sử dụng dev/prod parity có nhiều lợi ích. Đầu tiên, nó giúp cho các nhà phát triển dễ dàng triển khai ứng dụng lên môi trường sản xuất hơn. Thứ hai, nó giúp cho ứng dụng hoạt động ổn định hơn trên môi trường sản xuất. Thứ ba, nó giúp cho các nhà phát triển dễ dàng khắc phục lỗi hơn.

Ví dụ:

Môn phái Cái Bang có nhiều võ đường trên khắp cả nước. Các đệ tử của Cái Bang ở tất cả các võ đường đều luyện tập võ công theo cùng một phương pháp. Điều này giúp cho các đệ tử Cái Bang ở các võ đường khác nhau có thể dễ dàng phối hợp với nhau khi chiến đấu.

Tương tự như vậy, một 12 factor app có nhiều môi trường khác nhau, bao gồm môi trường phát triển, môi trường staging và môi trường sản xuất. Tất cả các môi trường này đều được cấu hình giống nhau nhất có thể. Điều này giúp cho các nhà phát triển dễ dàng triển khai ứng dụng lên môi trường sản xuất hơn và giúp cho ứng dụng hoạt động ổn định hơn trên môi trường sản xuất.

Việc sử dụng dev/prod parity có nhiều lợi ích. Đầu tiên, nó giúp cho các nhà phát triển dễ dàng triển khai ứng dụng lên môi trường sản xuất hơn. Ví dụ, nếu các nhà phát triển phát triển ứng dụng trên môi trường macOS, họ có thể dễ dàng triển khai ứng dụng lên môi trường sản xuất chạy Linux.

Thứ hai, việc sử dụng dev/prod parity giúp cho ứng dụng hoạt động ổn định hơn trên môi trường sản xuất. Ví dụ, nếu các nhà phát triển sử dụng cùng một cơ sở dữ liệu trong cả môi trường phát triển và môi trường sản xuất, thì ứng dụng sẽ hoạt động ổn định hơn trên môi trường sản xuất.

Thứ ba, việc sử dụng dev/prod parity giúp cho các nhà phát triển dễ dàng khắc phục lỗi hơn. Ví dụ, nếu một lỗi xảy ra trên môi trường sản xuất, các nhà phát triển có thể dễ dàng tái tạo lỗi đó trên môi trường phát triển và khắc phục lỗi đó.

Tóm lại, dev/prod parity là một yếu tố quan trọng của 12 factor app. Việc sử dụng dev/prod parity sẽ giúp cho các nhà phát triển dễ dàng triển khai ứng dụng lên môi trường sản xuất hơn, giúp cho ứng dụng hoạt động ổn định hơn trên môi trường sản xuất và giúp cho các nhà phát triển dễ dàng khắc phục lỗi hơn.


Hồi XI:

The Twelve Factor App - Kim Dung Truyện
                                                                            (internet)

Logs trong 12 factor app giống như những tin tức võ lâm lưu truyền trong giang hồ.

Tin tức võ lâm là những thông tin về các sự kiện xảy ra trong giới võ lâm, chẳng hạn như các trận đấu võ, các cuộc họp mặt của các môn phái, và các tin đồn về các cao thủ võ lâm. Tin tức võ lâm được lưu truyền rộng rãi trong giang hồ, và mọi người đều có thể truy cập vào tin tức võ lâm.

Tương tự như vậy, logs trong 12 factor app là những thông tin về các sự kiện xảy ra trong ứng dụng, chẳng hạn như các yêu cầu của người dùng, các phản hồi của ứng dụng, và các lỗi của ứng dụng. Logs được lưu trữ trong một nơi trung tâm, và mọi người đều có thể truy cập vào logs.

Việc sử dụng logs có nhiều lợi ích. Đầu tiên, logs giúp cho các nhà phát triển có thể theo dõi hoạt động của ứng dụng và khắc phục lỗi. Thứ hai, logs giúp cho các nhà quản trị hệ thống có thể theo dõi hiệu suất của ứng dụng và phát hiện các vấn đề. Thứ ba, logs giúp cho các nhà phân tích có thể tìm hiểu về hành vi của người dùng và cải thiện trải nghiệm của người dùng.

Ví dụ:

Một môn phái võ công có một kênh tin tức võ lâm, nơi các đệ tử của môn phái có thể chia sẻ tin tức võ lâm với nhau. Kênh tin tức võ lâm này được lưu trữ trong một nơi trung tâm, và mọi đệ tử của môn phái đều có thể truy cập vào kênh tin tức võ lâm.

Tương tự như vậy, một 12 factor app có một nơi lưu trữ logs, nơi các process của ứng dụng có thể ghi logs. Nơi lưu trữ logs này được lưu trữ trong một nơi trung tâm, và mọi người đều có thể truy cập vào logs.

Việc sử dụng logs có nhiều lợi ích. Đầu tiên, logs giúp cho các nhà phát triển có thể theo dõi hoạt động của ứng dụng và khắc phục lỗi. Ví dụ, nếu một lỗi xảy ra trong ứng dụng, các nhà phát triển có thể kiểm tra logs để tìm hiểu nguyên nhân của lỗi và khắc phục lỗi.

Thứ hai, logs giúp cho các nhà quản trị hệ thống có thể theo dõi hiệu suất của ứng dụng và phát hiện các vấn đề. Ví dụ, nếu ứng dụng chạy chậm, các nhà quản trị hệ thống có thể kiểm tra logs để tìm hiểu nguyên nhân của vấn đề và khắc phục vấn đề.

Thứ ba, logs giúp cho các nhà phân tích có thể tìm hiểu về hành vi của người dùng và cải thiện trải nghiệm của người dùng. Ví dụ, các nhà phân tích có thể kiểm tra logs để tìm hiểu những trang web mà người dùng truy cập nhiều nhất, và họ có thể sử dụng thông tin này để cải thiện trải nghiệm của người dùng trên những trang web đó.

Tóm lại, logs là một yếu tố quan trọng của 12 factor app. Việc sử dụng logs sẽ giúp cho các nhà phát triển, các nhà quản trị hệ thống và các nhà phân tích có thể theo dõi hoạt động của ứng dụng, khắc phục lỗi, theo dõi hiệu suất của ứng dụng, phát hiện các vấn đề và tìm hiểu về hành vi của người dùng.


Hồi XII :

The Twelve Factor App - Kim Dung Truyện

                                                                            (internet)

Admin processes trong 12 factor app giống như những môn đồ của một môn phái võ công làm các công việc quản lý và bảo trì võ đường.

Các môn đồ của một môn phái võ công không chỉ tập luyện võ công, mà còn phải làm các công việc quản lý và bảo trì võ đường, chẳng hạn như dọn dẹp võ đường, sửa chữa võ đường, và chuẩn bị đồ ăn thức uống cho các đệ tử tập luyện.

Tương tự như vậy, admin processes trong 12 factor app là những process thực hiện các công việc quản lý và bảo trì ứng dụng, chẳng hạn như chạy các tác vụ di chuyển dữ liệu, chạy các tác vụ sửa lỗi, và chạy các tác vụ sao lưu dữ liệu.

Việc sử dụng admin processes có nhiều lợi ích. Đầu tiên, nó giúp cho các ứng dụng dễ dàng bảo trì hơn. Thứ hai, nó giúp cho các ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn. Thứ ba, nó giúp cho các ứng dụng có thể hoạt động ổn định hơn.

Ví dụ:

Một môn phái võ công có nhiều môn đồ, mỗi môn đồ có một nhiệm vụ khác nhau. Một số môn đồ phụ trách dọn dẹp võ đường, một số môn đồ phụ trách sửa chữa võ đường, và một số môn đồ phụ trách chuẩn bị đồ ăn thức uống cho các đệ tử tập luyện.

Tương tự như vậy, một 12 factor app có nhiều admin processes, mỗi admin process có một nhiệm vụ khác nhau. Một admin process phụ trách chạy các tác vụ di chuyển dữ liệu, một admin process phụ trách chạy các tác vụ sửa lỗi, và một admin process phụ trách chạy các tác vụ sao lưu dữ liệu.

Việc sử dụng admin processes có nhiều lợi ích. Đầu tiên, nó giúp cho các ứng dụng dễ dàng bảo trì hơn. Vì mỗi admin process có một nhiệm vụ khác nhau, nên các nhà phát triển có thể dễ dàng bảo trì các ứng dụng bằng cách sửa đổi các admin process.

Thứ hai, việc sử dụng admin processes giúp cho các ứng dụng có thể mở rộng quy mô một cách dễ dàng hơn. Ví dụ, nếu một ứng dụng có nhiều người dùng truy cập cùng lúc, các nhà phát triển có thể dễ dàng chạy nhiều admin process hơn để xử lý các tác vụ.

Thứ ba, việc sử dụng admin processes giúp cho các ứng dụng có thể hoạt động ổn định hơn. Vì các admin process được chạy riêng biệt với các process chính của ứng dụng, nên nếu một admin process gặp lỗi, thì các process chính của ứng dụng sẽ không bị ảnh hưởng.

Tóm lại, admin processes là một yếu tố quan trọng của 12 factor app. Việc sử dụng admin processes sẽ giúp cho các ứng dụng dễ dàng bảo trì hơn, có thể mở rộng quy mô một cách dễ dàng hơn và hoạt động ổn định hơn.


Nhãn:

TLS Termination - Upstream TLS - Kubernetes kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises

Như bài viết trước nói về vấn đề kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises , có thể tham khảo bài trước đó để biết thêm chi tiết. Bài hôm nay là phần bổ trợ thêm đó là cài TLS cho dự án này để đảm bảo tính bảo mật hơn.

Trước tiên để việc với TLS thì cần cần hiểu một số khái niệm khái quát sau, khái quát thôi nhé muốn chuyên sâu về nó thì google thêm, vì nếu không hiểu khái niệm nó là gì thì chỉ thấy chạy lên là vỗ tay bốp bốp mà không hiểu thì cũng không hay lắm. Các khái niệm bên dưới sẽ giúp bạn những thứ bạn có thể đi tiếp, trong bài này chỉ là ví dụ cơ bản nó sẽ không diễn tả hết được, nhưng thông qua các keywork sẽ giúp mườn tượng ra được nhiều thứ hay ho để làm hơn. 

TLS Termination

Là khái niệm chỉ việc kết thúc kết nối TLS ở một thiết bị trung gian thay vì ở điểm cuối.

Client (trình duyệt) thiết lập kết nối TLS tới Load Balancer. 

Load Balancer giải mã dữ liệu TLS và chuyển tiếp dữ liệu đã giải mã tới các backend server (không còn mã hóa). Đây được gọi là TLS termination tại Load Balancer.

Client <===TLS===> Load balancer <===HTTP==> Server app


Mutual TLS

Cho phép cả server và client xác thực lẫn nhau trong quá trình thiết lập kết nối bảo mật.

Client sẽ xác thực danh tính của server bằng cách kiểm tra chứng chỉ (certificate) mà server cung cấp.

Server cũng sẽ xác thực danh tính của client bằng cách yêu cầu client cung cấp chứng chỉ.

Chỉ khi cả hai bên đều xác thực thành công danh tính của nhau, kết nối mới được thiết lập.


Client <===client & server auth ===> Load balancer <===client & server auth ==> Server app


Upstream TLS

Là việc sử dụng TLS ở phía upstream, tức là mã hóa kết nối giữa proxy server (ví dụ Nginx) và backend server (ví dụ API server). Proxy server sẽ mở kết nối TLS với backend server để đảm bảo dữ liệu truyền tải là riêng tư.


TLS Upstream 

Là việc sử dụng TLS ở phía client, tức là mã hóa kết nối giữa client (trình duyệt web, ứng dụng...) và proxy server. Client sẽ mở kết nối TLS với proxy server để đảm bảo dữ liệu truyền tải từ client lên là riêng tư.


Client <===TLS===> Load balancer <===TLS ==> Server app


Cấu hình môi trường thì dùng lại lab bài hôm trước, click vào link trên để xem, giờ có các manifest và kịch bạn theo lý thuyết ở trên sẽ  như sau : 


TLS Termination :

Đối với phần này thì khá đơn giản, copy lại manifest của bài trước, thêm vài thứ vào là xong, phần này khá là nhẹ.

Tạo namespace

kind: Namespace
apiVersion: v1
metadata:
  name: chemgio-project-tls

Tạo cert và tạo secret

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt


~/chemgio-project-tls/certs$ k create secret tls chemgio-secret-project-tls --key=ca.key --cert=ca.crt -n chemgio-project-tls


Tạo deploy


kind: Deployment
apiVersion: apps/v1
metadata:
  name: chemgio-project-tls
  namespace: chemgio-project-tls
spec:
  replicas: 2
  selector:
    matchLabels:
      app: chemgio-project-tls
  template:
    metadata:
      labels:
        app: chemgio-project-tls
    spec:
      containers:
      - image: nginx
        imagePullPolicy: IfNotPresent
        name: http
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}


Tạo service

kind: Service
apiVersion: v1
metadata:
  name: chemgio-project-tls
  namespace: chemgio-project-tls
spec:
  selector:
    app: chemgio-project-tls
  ports:
    - port: 80
      targetPort: 80


Tạo HTTPProxy


apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: chemgio-project-tls
  namespace: chemgio-project-tls
spec:
  virtualhost:
    fqdn: chemgio.loc
    tls:
      secretName: chemgio-secret-project-tls
  routes:
    - services:
        - name: chemgio-project-tls
          port: 80


Cuối cùng là xong phần TLS Termination, phần này khá nhẹ nhàng và đơn giản, vì bên trong không bận tâm gì nhiều. :)


TLS Termination  - Upstream TLS - Kubernetes kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises



TLS Termination  - Upstream TLS - Kubernetes kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises


Upstream TLS :

Tạo Namespace


kind: Namespace
apiVersion: v1
metadata:
  name: demo1-project-tls-upstream


Tạo ConfigMap : Có thể tạo config map từ manifest or import từ default.conf cũng được.


apiVersion: v1
data:
  default.conf: |-
        server {
                listen 80 default_server;
                listen [::]:80 default_server ipv6only=on;
                server_name localhost;

                location / {
                        return 301 https://$host$request_uri;
                }
        }

        server {
                listen 443 ssl;
                listen [::]:443 ssl;
                server_name localhost;

                ssl_certificate /etc/nginx/ssl/tls.crt;
                ssl_certificate_key /etc/nginx/ssl/tls.key;


                root /usr/share/nginx/html;
                index index.html;

                location / {
                        try_files $uri $uri/ =404;
                }
        }

kind: ConfigMap
metadata:
  name: demo1-configmap-tls-upstream
  namespace: demo1-project-tls-upstream


Tạo Secrets : ở đây là môi trường lab, nhằm phục vụ cho môi trường private nên hiện tại đang dùng openssl để giả lập cert, với môi trường thực tế thì thay đổi lại sao cho phù hợp.

openssl genpkey -algorithm RSA -out private.key


openssl rsa -pubout -in private.key -out public.pem


openssl req -new -key private.key -out server.csr


openssl genpkey -algorithm RSA -out ca-private.key


openssl req -new -key ca-private.key -out ca-csr.pem


openssl x509 -req -in ca-csr.pem -signkey ca-private.key -out ca-certificate.pem


openssl x509 -req -in server.csr -CA ca-certificate.pem -CAkey ca-private.key -CAcreateserial -out server-certificate.pem


Sau khi chạy các lệnh trên thì được danh sách file như sau: 


ca-certificate.pem  ca-csr.pem  ca-private.key  private.key  public.pem  server-certificate.pem  server.csr


Sử dụng các file cần thiết như bên dưới để tạo secret, theo dõi bên dưới để biết file nào cần dùng.


Tạo secret private

kubectl create secret tls demo1-secret-tls-upstream-private --key="private.key" --cert="server-certificate.pem" -n demo1-project-tls-upstream

Tạo secret public


kubectl create secret tls demo1-secret-tls-upstream-public --key="ca-private.key" --cert="ca-certificate.pem" -n demo1-project-tls-upstream



Tạo Deployment : Bên dưới là manifest tạo ra deployment và hiện tại đang replicas  tương ứng 2 pod sẽ chạy cho dự án này, cần chú ý rõ phần volumes vì nó dùng để mount các tls chạy nội bộ bên trong.


kind: Deployment
apiVersion: apps/v1
metadata:
  name: demo1-project-tls-upstream
  namespace: demo1-project-tls-upstream
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo1-project-tls-upstream
  template:
    metadata:
      labels:
        app: demo1-project-tls-upstream
    spec:
      containers:
      - image: nginx
        imagePullPolicy: IfNotPresent
        name: http
        ports:
        - containerPort: 80
        - containerPort: 443
        volumeMounts:
        - name: demo1-secret-tls-upstream-private
          mountPath: /etc/nginx/ssl
        - name: demo1-project-tls-upstream
          mountPath: /etc/nginx/conf.d
      volumes:
        - name: demo1-secret-tls-upstream-private
          secret:
            secretName: demo1-secret-tls-upstream-private
        - name: demo1-project-tls-upstream
          configMap:
            name: demo1-configmap-tls-upstream


Tạo Service : Sau khi chạy xong service này thì xem như phần bên trong đã hoàn tất, có thể test qua cổng serice thì xem như hoàn tất. Điểm lưu ý là phần annotations nếu muốn Upstream TLS thì bắt buộc phải có https://projectcontour.io/upstream-protocol.tls: "443,https" nếu không có sẽ bị lỗi ngay. Bên dưới sẽ có phần note để có thể hình dung ra.


apiVersion: v1
kind: Service
metadata:
  name: demo1-project-tls-upstream
  namespace: demo1-project-tls-upstream
  annotations:
    projectcontour.io/upstream-protocol.tls: "443,https"
spec:
  ports:
  - name: https
    port: 443
    targetPort: 443
  selector:
    app: demo1-project-tls-upstream

Đây là hình test bên trong trước, đảm bảo pod thông qua service đã hoạt động.


TLS Termination  - Upstream TLS - Kubernetes kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises



HTTPProxy : Thông qua cổng service sẽ cấu hình HTTPProxy cho web ra bên ngoài thông qua serice, và kết quả sẽ như sau.


apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: demo1-project-tls-upstream
  namespace: demo1-project-tls-upstream
spec:
  virtualhost:
    fqdn: demo1.loc
    tls:
      secretName: demo1-secret-tls-upstream-public
  routes:
  - services:
    - name: demo1-project-tls-upstream
      port: 443

Kết quả test bên ngoài như sau :


TLS Termination  - Upstream TLS - Kubernetes kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises



TLS Termination  - Upstream TLS - Kubernetes kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises

Note: Như phần service ở trên nói nếu bỏ annotations  thì sao, vấn đề sẽ xảy ra vì nó sẽ không hiểu và kết quả xảy ra như sau. Bên dưới là sau khi remove và replace force lại sevice.


TLS Termination  - Upstream TLS - Kubernetes kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises




TLS Termination  - Upstream TLS - Kubernetes kết hợp với MetalLB và Contour ingress controller trên Kubernetes On-Premises



Ở trên đây là ví dụ cụ thể được follow theo document của project contour, nếu bạn muốn nghiên cứu thêm có thể đọc tài liệu và nghiên cứu thêm, nó khá là nhiều nên cứ từ từ trải nghiệm :)


Nhãn: