CHƯƠNG 2 Sự tiến hoá của kiến trúc phần mềm

Như chúng ta đã thấy cho đến nay, microservice cung cấp cho chúng ta rất nhiều sự lựa chọn và theo đó là rất nhiều quyết định để đưa ra. Ví dụ, chúng ta nên sử dụng bao nhiêu công nghệ khác nhau, chúng ta nên để các nhóm khác nhau sử dụng các thành ngữ lập trình khác nhau, và chúng ta có nên tách hoặc hợp nhất một dịch vụ không? Làm thế nào để chúng ta đưa ra những quyết định này? Với tốc độ thay đổi nhanh hơn và môi trường linh hoạt hơn mà các kiến trúc này cho phép, vai trò của kiến trúc sư của hệ thống cũng phải thay đổi. Trong chương này, tôi sẽ có một cái nhìn khá chắc chắn về vai trò của một kiến trúc sư của hệ thống là gì và hy vọng sẽ khởi động một cuộc tấn công cuối cùng vào toà tháp ngà voi (ám chỉ việc xa rời thực tế)

Việc so sánh khập khiễng

Bạn tiếp tục sử dụng từ đó. Nhưng tôi không nghĩ rằng nó có nghĩa là những gì bạn nghĩ nó.

— Inigo Montoya, từ Cô dâu công chúa

Kiến trúc sư của hệ thống là một công việc quan trọng. Họ chịu trách nhiệm đảm bảo rằng chúng ta có một tầm nhìn kỹ thuật hợp nhất, một tầm nhìn sẽ giúp hệ thống của chúng tôi có thể đáp ứng được nhu cầu của khách hàng. Ở một số công ty, họ có thể chỉ phải làm việc với một nhóm, trong trường hợp đó, vai trò của họ và trưởng nhóm kỹ thuật thường giống nhau. Ở những người khác, họ có thể xác định tầm nhìn cho toàn bộ chương trình làm việc, phối hợp với nhiều nhóm trên toàn thế giới, hoặc thậm chí có thể là toàn bộ tổ chức. Ở bất kỳ cấp độ nào họ hoạt động, vai trò này rất khó để xác định rõ ràng, và mặc dù nó thường là một bước tiến nghề nghiệp rõ ràng cho developer trong các tổ chức doanh nghiệp, nó cũng là một vai trò nhận được nhiều chỉ trích hơn hầu hết vai trò bất kỳ nào khác. Hơn bất kỳ vai trò nào khác, họ có thể có tác động trực tiếp đến chất lượng của các hệ thống được xây dựng, đến điều kiện làm việc của đồng nghiệp và khả năng của tổ chức của họ để đáp ứng với sự thay đổi, nhưng dường như chúng ta thường làm sai vài trò của công việc này. Tại sao vậy?

Ngành công nghiệp (phần mềm) của chúng ta là một ngành trẻ. Đây là điều mà chúng ta dường như đã quên, nhưng chúng ta chỉ tạo ra các chương trình chạy trên thứ mà chúng ta gọi là máy tính trong khoảng 70 năm trở lại đây. Vì vậy, chúng ta không ngừng tìm kiếm một thứ tương tự ở các ngành nghề khác để cố gắng giải thích những gì chúng ta đang làm. Chúng ta không phải là bác sĩ hay kỹ sư y tế, nhưng cũng không phải là thợ sửa ống nước hay thợ điện. Thay vào đó, chúng ta thường nằm ở lưng chừng, điều này khiến xã hội khó hiểu chúng ta, hoặc chúng ta không hiểu chúng ta đang ở đâu.

Vì vậy, chúng ta vay mượn từ các ngành nghề khác. Chúng tôi tự gọi mình là “kỹ sư” phần mềm, hoặc"Kiến trúc sư." Nhưng chúng ta không phải kiến trúc sư, nhỉ? Kiến trúc sư và kỹ sư (ở ngành khác) có một sự nghiêm khắc và tinh tế mà chúng ta chỉ có thể mơ ước, và tầm quan trọng của họ trong xã hội được hiểu rõ. Tôi nhớ đã nói chuyện với một người bạn của tôi, một ngày trước khi anh ta trở thành một kiến trúc sư có trình độ. “Ngày mai,” anh ấy nói, "nếu tôi cho bạn lời khuyên ở quán rượu về cách xây dựng một thứ gì đó và điều đó là sai, tôi sẽ phải chịu trách nhiệm. Tôi có thể bị kiện, vì theo pháp luật, tôi bây giờ là một kiến trúc sư có năng lực và tôi phải chịu trách nhiệm nếu tôi làm sai. " Tầm quan trọng của những công việc này đối với xã hội có nghĩa là cần phải có những bằng cấp cần thiết để đáp ứng. Ví dụ, ở Anh, bạn phải học tối thiểu bảy năm trước khi được gọi là kiến trúc sư. Nhưng những công việc này cũng dựa trên một lượng kiến thức có từ hàng nghìn năm trước. Và chúng ta? Không hẳn. Đó cũng là lý do tại sao tôi xem hầu hết các hình thức chứng chỉ CNTT là vô giá trị, vì chúng hầu như không thể khẳng định chúng ta tốt như thế nào.

Một phần trong chúng ta có nhu cầu được công nhận, vì vậy chúng tôi mượn tên từ những ngành nghề khác đã có được sự công nhận mà chúng tôi là một ngành khao khát. Nhưng điều này có thể gây hại gấp đôi. Đầu tiên, nó ngụ ý rằng chúng ta biết mình đang làm gì, khi nào thì rõ ràng là không. Tôi sẽ không nói rằng các công trình xây dựng và cầu nối không bao giờ sụp đổ, nhưng tỉ lệ ít hơn nhiều so với số lần các chương trình của chúng ta sẽ gặp sự cố, khiến cho việc so sánh với các kỹ sư là khập khiễng. Thứ hai, các phép loại suy bị chia nhỏ rất nhanh khi chỉ nhìn lướt qua. Để xoay chuyển tình thế, nếu việc xây dựng cây cầu giống như một chương trình, chúng tôi sẽ phát hiện ra rằng bờ biển xa bây giờ đã xa hơn 50 mét, rằng nó thực sự là bùn chứ không phải đá granit, và thay vì xây dựng một cây cầu mà đáng lẽ chúng tôi sẽ xây dựng – thay vào đó là một cây cầu đường bộ. Phần mềm của chúng ta không bị ràng buộc bởi các quy tắc vật lý giống như các kiến trúc sư hoặc kỹ sư thực sự phải đáp ứng và những gì chúng tôi tạo ra được thiết kế để linh hoạt, thích ứng và phát triển theo yêu cầu của người dùng.

Có lẽ thuật ngữ kiến trúc sư(Solution Architect hay Software Architect) đã gây hại nhiều nhất. Ý tưởng về một người lập kế hoạch chi tiết cho người khác giải thích và mong muốn điều này được thực hiện. Một sự cân bằng giữa một nghệ sỹ và một kỹ sư, giám sát việc tạo của những thứ tông thường với một tầm nhìn duy nhất, với tất cả các quan điểm khác là không phù hợp, ngoại trừ sự phản đối không thường xuyên từ kỹ sưvề các quy luật vật lý. Trong ngành của chúng ta, quan điểm này của kiến trúc sư của hệ thống dẫn đến một số thực hành khủng khiếp. Sơ đồ này đến sơ đồ khác, trang này qua trang khác của tài liệu, được tạo ra với mục đích cung cấp thông tin về việc xây dựng một hệ thống hoàn hảo, mà không tính đến tương lai về cơ bản không thể biết trước được. Hoàn toàn không có bất kỳ hiểu biết nào về mức độ khó thực hiện, hoặc chỉ là nó có thực sự hoạt động hay không, hãy để một mình có khả năng thay đổi khi chúng ta có hiểu biết nhiều hơn.

Khi chúng ta so sánh mình với các kỹ sư hoặc kiến trúc sư, chúng ta có nguy cơ khiến mọi người trở thành kẻ phá hoại. Thật không may, chúng tôi đang mắc kẹt với từ kiến trúc sư cho đến bây giờ. Vì vậy, điều tốt nhất chúng ta có thể làm là xác định lại ý nghĩa của nó trong ngữ cảnh của chúng ta.

Một tầm nhìn tiến hóa cho kiến trúc sư

Các yêu cầu của chúng tôi thay đổi nhanh hơn so với những người thiết kế và xây dựng các tòa nhà — các công cụ và kỹ thuật theo ý của chúng tôi cũng vậy. Những thứ chúng ta tạo ra không phải là những điểm cố định trong thời gian. Sau khi được đưa vào môi trường production, phần mềm của chúng tôi sẽ tiếp tục phát triển khi cách thức sử dụng thay đổi. Đối với hầu hết những thứ chúng tôi tạo ra, chúng tôi phải chấp nhận rằng một khi phần mềm đến tay khách hàng, chúng tôi sẽ phải phản ứng và thích nghi, thay vì nó là một sản phẩm không bao giờ thay đổi. Do đó, các kiến trúc sư của chúng tôi cần phải thay đổi suy nghĩ của họ thay vì việc tạo ra sản phẩm cuối cùng hoàn hảo, mà tập trung vào việc giúp tạo ra một framework trong đó các hệ thống phù hợp có thể xuất hiện và tiếp tục phát triển khi chúng tôi có hiểu biết nhiều hơn.

Mặc dù cho đến nay, tôi đã dành phần lớn thời lượng của chương để cảnh báo bạn không nên so sánh bản thân của chúng ta quá nhiều với các ngành nghề khác, nhưng có một điểm tương đồng mà tôi thích khi nói đến vai trò của kiến trúc sư của hệ thống CNTT và tôi nghĩ tốt hơn nên gói gọn những gì chúng ta muốn. vai trò hiện hữu. Erik Doernenburg lần đầu tiên chia sẻ với tôi ý tưởng rằng chúng ta nên nghĩ về vai trò của mình với tư cách là nhà quy hoạch thành phố hơn là kiến trúc sư cho môi trường xây dựng. Vai trò của người lập kế hoạch thị trấn hẳn đã quen thuộc với bất kỳ bạn nào đã chơi SimCity trước đây. Vai trò của người lập quy hoạch thành phố là xem xét vô số nguồn thông tin và sau đó cố gắng tối ưu hóa bố cục của thành phố để phù hợp nhất với nhu cầu của người dân hiện nay, có tính đến việc sử dụng trong tương lai. Tuy nhiên, cách anh ấy ảnh hưởng đến cách thành phố phát triển là rất thú vị. Anh ta không nói, “xây dựng tòa nhà cụ thể này ở đó”; thay vào đó, anh ta tạo ra các vùng trong**thành phố. Vì vậy, như ở SimCity, bạn có thể chỉ định một phần thành phố của mình là khu công nghiệp và một phần khác là khu dân cư. Sau đó, những người khác sẽ quyết định những tòa nhà chính xác được tạo ra, nhưng có những hạn chế: nếu bạn muốn xây dựng một nhà máy, nó sẽ cần phải ở trong một khu công nghiệp. Thay vì lo lắng quá nhiều về những gì xảy ra trong một khu vực, thay vào đó, người lập kế hoạch thành phố sẽ dành nhiều thời gian hơn để tìm hiểu cách thức di chuyển của mọi người và các tiện ích từ khu vực này sang khu vực khác.

Nhiều người đã ví một thành phố như một sinh vật sống. Thành phố thay đổi theo thời gian. Nó thay đổi và phát triển khi những cư dân sử dụng nó theo những cách khác nhau, hoặc khi các lực lượng bên ngoài định hình nó. Người quy hoạch thành phố cố gắng hết sức để dự đoán những thay đổi này, nhưng chấp nhận rằng việc cố gắng kiểm soát trực tiếp tất cả các khía cạnh của những gì xảy ra là vô nghĩa.

Việc so sánh với phần mềm nên rõ ràng. Khi người dùng sử dụng phần mềm của chúng tôi, chúng tôi cần phản ứng và thay đổi. Chúng ta không thể lường trước mọi điều sẽ xảy ra, và vì vậy thay vì lập kế hoạch cho bất kỳ trường hợp nào, chúng ta nên lên kế hoạch cho phép thay đổi bằng cách tránh việc tạo ra một điều cuối cùng không bao giờ thay đổi. Thành phố của chúng ta — hệ thống — cần phải là một nơi tốt đẹp, hạnh phúc cho tất cả những ai sử dụng nó. Một điều mà mọi người thường quên là hệ thống của chúng tôi không chỉ đáp ứng người dùng; nó cũng tạo điều kiện cho các developer và nhà kinh doanh, những người cũng phải làm việc ở đó và những người có công việc đảm bảo rằng nó có thể thay đổi theo yêu cầu. Để mượn một thuật ngữ từ Frank Buschmann, các kiến trúc sư của hệ thống có nhiệm vụ đảm bảo rằng hệ thống cũng có thể sử dụng được cho các developer.

Một nhà quy hoạch, cũng giống như một kiến trúc sư, cũng cần biết khi nào kế hoạch của mình không được sử dụng hoặc tuân thủ. Vì anh ta có ít chỉ thị hơn, nên số lần anh ta cần tham gia để chỉ ra sự đúng sai là ít nhất, nhưng nếu ai đó quyết định xây dựng một nhà máy xử lý nước thải trong khu dân cư, anh ta cần phải có khả năng đóng cửa nó.

Vì vậy, các kiến trúc sư của hệ thống của chúng tôi với tư cách là những nhà quy hoạch thị trấn cần phải định hướng theo hướng tổng quan và chỉ tham gia vào việc cụ thể hóa chi tiết thực hiện trong một số trường hợp cụ thể. Họ cần đảm bảo rằng hệ thống phù hợp với mục đích ngay bây giờ, nhưng cũng là một nền tảng cho tương lai. Và họ cần đảm bảo rằng đó là một hệ thống khiến người dùng và developer hài lòng như nhau. Điều này nghe có vẻ như một yêu cầu khá cao. Vậy, chúng ta bắt đầu từ đâu?

Phân vùng

Vì vậy, tiếp tục ẩn dụ về kiến trúc sư của hệ thống là người quy hoạch thành phố thêm một chút nữa, chúng ta có những khu vực nào? Đây là các ranh giới dịch vụ của chúng tôi hoặc có thể là danh sách các dịch vụ được nhóm lại một cách chi tiết. Là kiến trúc sư, chúng ta cần ít để ý về những gì xảy ra bên trong từng khu vực hơn là những gì xảy ra giữa các khu vực với nhau. Điều đó có nghĩa là chúng tôi cần dành thời gian suy nghĩ về cách các dịch vụ của chúng tôi nói chuyện với nhau hoặc đảm bảo rằng chúng tôi có thể duy trì tình trạng hoạt động tổng thể của hệ thống một cách chính xác. Mức độ tham gia của chúng tôi vào bên trong khu vực sẽ khác nhau

một phần nào đó. Nhiều tổ chức đã áp dụng microservices để tối đa hóa quyền tự chủ của các nhóm, điều mà chúng tôi sẽ mở rộng trong Chương 10. Nếu bạn ở trong một tổ chức như vậy, bạn sẽ dựa nhiều hơn vào nhóm đó để đưa ra quyết định phù hợp tại từng chỗ.

Nhưng giữa các khu vực, hoặc các ô trên bản đồ kiến trúc truyền thống của chúng tôi, chúng tôi cần phải cẩn thận; làm sai ở đây dẫn đến tất cả các loại vấn đề và có thể rất khó sửa chữa.

Trong mỗi dịch vụ, bạn có thể đồng ý với nhóm sở hữu khu vực đó chọn một kho lưu trữ dữ liệu hoặc công nghệ khác nhau. Tất nhiên, những mối quan tâm khác có thể xuất hiện ở đây. Xu hướng để các nhóm chọn công cụ phù hợp cho công việc của bạn có thể bị hạn chế bởi thực tế là việc thuê người hoặc di chuyển họ giữa các nhóm trở nên khó khăn hơn nếu bạn có 10 ngăn xếp công nghệ khác nhau để hỗ trợ. Tương tự, nếu mỗi đội chọn một kho dữ liệu hoàn toàn khác nhau, bạn có thể thấy mình thiếu đủ kinh nghiệm để chạy bất kỳ kho dữ liệu nào trong số họ trên quy mô lớn. Netflix, ví dụ, hầu hết đã chuẩn hóa và sử dụng Cassandra như một kho lưu trữ dữ liệu. Mặc dù nó có thể không hẳn đã là công nghệ phù hợp nhất cho tất cả các trường hợp, nhưng Netflix cảm thấy rằng giá trị thu được bằng cách xây dựng công cụ và kiến thức chuyên môn xung quanh Cassandra quan trọng hơn việc phải hỗ trợ và vận hành trên quy mô nhiều nền tảng khác có thể phù hợp hơn cho từng các nhiệm vụ nhất định. Netflix là một ví dụ điển hình, trong đó quy mô có thể là yếu tố mang tính quyết định mạnh nhất, bạn có thể thấy ý tưởng đó khá rõ ràng.

Tuy nhiên, phần giữa các dịch vụ với nhau mới là nơi mọi thứ có thể trở nên lộn xộn. Nếu một dịch vụ quyết định cung cấp REST thông qua HTTP, một dịch vụ khác sử dụng giao thức bộ đệm và một dịch vụ thứ ba sử dụng Java RMI, thì việc tích hợp chúng có thể trở thành một cơn ác mộng vì các dịch vụ sử dụng chúng phải chịu và hỗ trợ nhiều kiểu giao thức. Đây là lý do tại sao tôi cố gắng bám sát tôn chỉ rằng chúng ta nên “lo lắng về những gì xảy ra giữa các hộp và tự do trong những gì xảy ra bên trong.”

Kiến trúc mã nguồn

Nếu chúng tôi muốn đảm bảo rằng các hệ thống chúng tôi tạo ra có thể sử dụng được cho các developer của chúng tôi, thì các kiến trúc sư của chúng tôi cần phải hiểu tác động của các quyết định của họ. Ít nhất, điều này có nghĩa là dành thời gian cho nhóm và lý tưởng là nó có nghĩa là những developer này cũng thực sự dành thời gian viết mã nguồn cho nhóm. Đối với những bạn thực hành phát triển theo cặp**(pair-programing),** việc một kiến trúc sư tham gia nhóm trong một thời gian ngắn với tư cách là một thành viên của cặp sẽ trở thành một vấn đề đơn giản. Tốt nhất, bạn nên làm những câu chuyện bình thường, để thực sự hiểu công việc bình thường là như thế nào. Tôi không thể nhấn mạnh tầm quan trọng của kiến trúc sư khi làm việc cùng nhóm! Điều này hiệu quả hơn đáng kể so với việc gọi điện hoặc chỉ nhìn vào mã nguồn của cô ấy.

Về mức độ thường xuyên mà bạn nên làm điều này, điều đó phụ thuộc rất nhiều vào quy mô của (các) nhóm mà bạn đang làm việc. Nhưng điều quan trọng là nó phải là một hoạt động thường xuyên. Ví dụ: nếu bạn đang làm việc với bốn nhóm, dành nửa ngày cho mỗi nhóm bốn tuần một lần đảm bảo bạn xây dựng nhận thức và cải thiện giao tiếp với các nhóm mà bạn đang làm việc.

Phương pháp tiếp cận có nguyên tắc

Các quy tắc dành cho sự vâng lời của những kẻ ngu ngốc và sự hướng dẫn của những nhà thông thái.

— Thường được cho là của Douglas Bader

Việc đưa ra quyết định trong thiết kế hệ thống, tất cả chỉ xoay quanh sự đánh đổi và microservice mang đến cho chúng ta rất nhiều đánh đổi! Khi chọn một kho dữ liệu, chúng ta có chọn một nền tảng mà chúng ta có ít kinh nghiệm, nhưng điều đó mang lại cho chúng ta khả năng mở rộng tốt hơn không? Chúng tôi có thể sử dụng hai stack công nghệ khác nhau trong hệ thống của mình không? Vậy nếu sử dụng ba thì sao? Một số quyết định có thể được thực hiện hoàn toàn ngay tại chỗ với thông tin có sẵn cho chúng tôi, và đây là những thứ dễ thực hiện nhất. Nhưng những quyết định có thể phải được thực hiện trên thông tin không đầy đủ thì sao?

Việc lập khung ở đây có thể hữu ích và một cách tuyệt vời để giúp lập khung cho việc ra quyết định của chúng ta là xác định một bộ các nguyên tắc và thực hành hướng dẫn nó, dựa trên các mục tiêu mà chúng ta đang cố gắng đạt được. Chúng ta hãy xem xét từng thứ một.

Mục tiêu chiến lược

Vai trò của kiến trúc sư đã đủ khó khăn, vì vậy, may mắn là chúng tôi thường không phải xác định các mục tiêu chiến lược! Các mục tiêu chiến lược phải nói lên được vị trí của công ty và cách công ty tự thấy là tốt nhất để làm cho khách hàng hài lòng. Đây sẽ là những mục tiêu cấp cao và có thể hoàn toàn không bao gồm công nghệ. Chúng có thể được xác định ở cấp độ công ty hoặc cấp độ phòng ban. Chúng có thể là những thứ như “Mở rộng sang Đông Nam Á để mở khóa các thị trường mới” hoặc “Hãy để khách hàng đạt được càng nhiều càng tốt bằng cách sử dụng các dịch vụ tự phục vụ.” Điều quan trọng là đây là nơi tổ chức của bạn đứng đầu, vì vậy bạn cần đảm bảo công nghệ phù hợp với nó.

Nếu bạn là người xác định tầm nhìn kỹ thuật của công ty, điều này có thể có nghĩa là bạn sẽ cần dành nhiều thời gian hơn cho các bộ phận phi kỹ thuật trong tổ chức của mình (hoặc bộ phận kinh doanh, như chúng thường được gọi). Tầm nhìn thúc đẩy cho doanh nghiệp là gì? Và nó thay đổi như thế nào?

Nguyên tắc

Nguyên tắc là những quy tắc bạn đã thực hiện để điều chỉnh những gì bạn đang làm với một số mục tiêu lớn hơn và đôi khi sẽ thay đổi. Ví dụ: nếu một trong những mục tiêu chiến lược của bạn với tư cách là một tổ chức là giảm thời gian triển khai các tính năng mới, bạn có thể xác định một nguyên tắc nói rằng nhóm delivery có toàn quyền kiểm soát vòng đời của phần mềm của họ để deliver bất cứ khi nào họ sẵn sàng, độc lập với bất kỳ đội nào khác. Nếu một mục tiêu khác là tổ chức của bạn là dịch chuyển mạnh mẽ sang việc triển khai dịch vụ của mình ở các quốc gia khác, bạn có thể quyết định thực hiện một nguyên tắc rằng toàn bộ hệ thống phải có tính di động để cho phép nó được deploy tại các quốc gia đó nhằm tôn trọng chủ quyền của dữ liệu.

Bạn hoàn toàn không muốn có vô số nguyên tắc. Ít hơn 10 là một con số tốt – đủ nhỏ để mọi người có thể nhớ chúng hoặc để phù hợp với các áp phích nhỏ. Bạn càng có nhiều nguyên tắc, thì khả năng chúng trùng lặp hoặc mâu thuẫn với nhau càng lớn.

12 Factors của Heroku là một tập hợp các nguyên tắc thiết kế có cấu trúc xoay quanh mục tiêu giúp bạn tạo ra các ứng dụng hoạt động tốt trên nền tảng Heroku. Chúng cũng có thể có ý nghĩa trong các ngữ cảnh khác. Một số nguyên tắc thực sự là những ràng buộc dựa trên các hành vi mà ứng dụng của bạn cần thể hiện để hoạt động trên Heroku. Ràng buộc thực sự là một thứ rất khó (hoặc hầu như không thể) thay đổi, trong khi các nguyên tắc là thứ chúng ta quyết định lựa chọn. Bạn có thể quyết định gọi rõ ràng những điều đó là nguyên tắc so với những điều là ràng buộc, để giúp chỉ ra những điều bạn thực sự không thể thay đổi. Cá nhân tôi nghĩ rằng có thể có một số giá trị trong việc giữ chúng trong cùng một danh sách để khuyến khích những ràng buộc đầy thử thách thỉnh thoảng và xem liệu chúng có thực sự bất di bất dịch hay không!

Thực hành

Thực hành của chúng tôi là cách chúng tôi đảm bảo các nguyên tắc của chúng tôi đang được thực hiện. Chúng là một tập hợp các hướng dẫn chi tiết, thiết thực để thực hiện các nhiệm vụ. Chúng thường sẽ là công nghệ cụ thể, và phải đủ đơn giản để bất kỳ developer nào cũng có thể hiểu được chúng. Các phương pháp thực hành có thể bao gồm hướng dẫn mã hóa, thực tế là tất cả dữ liệu log cần được quản lý tập trung hoặc HTTP / REST là kiểu tích hợp tiêu chuẩn. Do bản chất kỹ thuật của chúng, các thực hành thường sẽ thay đổi thường xuyên hơn các nguyên tắc.

Cũng như các nguyên tắc, đôi khi thực hành phản ánh những hạn chế trong tổ chức của bạn. Ví dụ: nếu bạn chỉ hỗ trợ CentOS, điều này sẽ cần được phản ánh trong thực hành của bạn.

Thực hành nên làm nền tảng cho các nguyên tắc của chúng tôi. Một nguyên tắc nêu rõ rằng các nhóm deliver vận hành toàn bộ vòng đời của hệ thống của họ có thể có nghĩa là bạn có một thông lệ cho rằng tất cả các dịch vụ được deploy vào các tài khoản AWS riêng biệt, cung cấp khả năng tự quản lý tài nguyên và cách ly khỏi các nhóm khác.

Kết hợp các nguyên tắc và thực hành

Nguyên tắc của một người là thực hành của người khác. Ví dụ, bạn có thể quyết định gọi việc sử dụng HTTP/REST là một nguyên tắc hơn là một thực hành. Và điều đó sẽ ổn thôi. Điểm mấu chốt là giá trị khi có những ý tưởng bao quát hướng dẫn cách hệ thống phát triển và đủ chi tiết để mọi người biết cách thực hiện những ý tưởng đó. Đối với một nhóm đủ nhỏ, có lẽ là một nhóm duy nhất, việc kết hợp các nguyên tắc và thực hành có thể ổn. Tuy nhiên, đối với các tổ chức lớn hơn, nơi công nghệ và phương thức làm việc có thể khác nhau, bạn có thể muốn có một bộ thực hành khác ở những nơi chỗ khác nhau, miễn là cả hai đều hướng tới một bộ nguyên tắc chung. Ví dụ, một nhóm .NET có thể có một bộthực hành và một nhóm Java khác, với một bộ thực hành chung cho cả hai. Tuy nhiên, các nguyên tắc có thể giống nhau cho cả hai.

Một ví dụ trong thế giới thực

Đồng nghiệp của tôi, Evan Bottcher, đã phát triển sơ đồ thể hiện trong Hình 2-1 trong quá trình làm việc với một trong những khách hàng của chúng tôi. Hình này cho thấy sự tác động lẫn nhau của các mục tiêu, nguyên tắc và thực hành theo một định dạng rất rõ ràng. Trong vòng một vài năm, các hoạt động ở ngoài cùng bên phải sẽ thay đổi khá thường xuyên, trong khi các nguyên tắc vẫn khá tĩnh. Một sơ đồ như thế này có thể được in một cách độc đáo trên một tờ giấy và được chia sẻ, và mỗi ý tưởng đủ đơn giản để các developer trung bình có thể ghi nhớ. Tất nhiên, có nhiều chi tiết hơn đằng sau mỗi điểm ở đây, nhưng có thể trình bày rõ điều này ở dạng tổng hợp là rất hữu ích.

Có lý do để có tài liệu hỗ trợ một số mục này. Tuy nhiên, về cơ bản, tôi thích ý tưởng có một bộ mã nguồn mẫu mà bạn có thể xem, kiểm tra và chạy, là hiện thân của những ý tưởng này. Thậm chí tốt hơn, chúng ta có thể tạo ra công cụ làm đúng việc. Chúng ta sẽ thảo luận sâu hơn về vấn đề đó trong giây lát.

Tiêu chuẩn bắt buộc

Khi bạn đang nghiên cứu các phương pháp của mình và suy nghĩ về những đánh đổi mà bạn cần thực hiện, một trong những điểm cân bằng cốt lõi cần tìm là mức độ biến thiên cho phép trong hệ thống của bạn. Một trong những cách quan trọng để xác định những gì nên không đổi từ dịch vụ này sang dịch vụ khác là xác định một dịch vụ tốt, hoạt động tốt trông như thế nào. Dịch vụ “tốt” trong hệ thống của bạn là gì? Nó cần có những khả năng nào để đảm bảo rằng hệ thống của bạn có thể quản lý được và một dịch vụ không tốt sẽ không làm hỏng toàn bộ hệ thống? Và, cũng như với mọi người, những gì một công dân tốt trong một bối cảnh không phản ánh những gì nó trông như thế nào ở một nơi khác. Tuy nhiên, có một số đặc điểm chung của các dịch vụ hoạt động tốt mà tôi nghĩ là khá quan trọng để quan sát. Đây là một số lĩnh vực chính mà việc mọi thứ có quá nhiều khác biệt có thể dẫn đến một thời kì cực kì khó khăn. Như Ben Christensen từ Netflix đã nói, khi chúng ta nghĩ về bức tranh lớn hơn, “nó cần phải là một hệ thống gắn kết được tạo thành từ nhiều bộ phận nhỏ có vòng đời tự trị nhưng tất cả lại kết hợp với nhau”. Vì vậy, chúng tôi cần tìm sự cân bằng giữa việc tối ưu hóa choquyền tự chủ của từng microservice mà không làm hỏngbức tranh toàn cảnh. Xác định các thuộc tính rõ ràng mà mỗi dịch vụ phải có là một cách để xác định rõ ràng sự cân bằng đó nằm ở đâu.

Giám sát

Điều cốt lõiở đây là chúng tôi có thể vẽ ra các quan điểm nhất quán, tầm nhìn xuyên suốt các service về tình trạng sức khoẻ của hệ thống. Đây phải là cái nhìn toàn hệ thống, không phải là từng dịch vụ đơn lẻ. Như chúng ta sẽ thảo luận trong Chương 8, việc biết tình trạng của từng dịch vụ là hữu ích, nhưng thường chỉ khi bạn đang cố gắng chẩn đoán một vấn đề rộng hơn hoặc hiểu một xu hướng lớn hơn. Để làm cho điều này dễ dàng nhất có thể, tôi khuyên bạn nên đảm bảo rằng tất cả các dịch vụ cần đưa ra các chỉ số liên quan đến sức khỏe và giám sát chung theo cùng một cách.

Bạn có thể chọn áp dụng cơ chế đẩy (push), trong đó mỗi dịch vụ cần đẩy dữ liệu này vào một trung tâm xử lý. Đối với các chỉ số, đây có thể là Graphite, và đối với sức khoẻ của hệ thống, nó có thể là Nagios. Hoặc bạn có thể quyết định sử dụng hệ thống polling để lấy dữ liệu từ chính các nút. Nhưng bất cứ điều gì bạn chọn, hãy cố gắng giữ cho nó được chuẩn hóa. Làm cho công nghệ bên trong hộp trở nên mờ đục và không yêu cầu hệ thống giám sát của bạn phải thay đổi để hỗ trợ nó. Có một yêu cầu ở đây: log cần đặt tập trung ở một chỗ

Giao diện – Giao thức

Chọn một số lượng nhỏ các công nghệ giao diện đã xác định sẽ giúp tích hợp những người dùng mới. Một là một con số tốt khi nói về số lượng tiêu chuẩn. Hai cũng không quá tệ. Có 20 kiểu tích hợp khác nhau thì không tốt. Đây không chỉ là việc chọn công nghệ và giao thức. Ví dụ: nếu bạn chọn HTTP/REST, bạn sẽ sử dụng động từ hay danh từ? Bạn sẽ xử lý việc phân trang tài nguyên như thế nào? Bạn sẽ xử lý việc lập phiên bản của các điểm cuối như thế nào?

An toàn về mặt kiến trúc

Chúng tôi không thể để một dịch vụ có hành vi xấu làm hỏng bữa tiệc của tất cả mọi người. Chúng tôi phải đảm bảo rằng các dịch vụ của chúng tôi bảo vệ bản thân chúng khỏi nhưng vấn đề như downtime hay không thể gọi đến dịch vụ. Chúng ta càng có nhiều dịch vụ mà không xử lý đúng về khả năng thất bại của các dịch vụ khác khi gọi đến, thì hệ thống của chúng ta sẽ càng trở nên mong manh hơn. Điều này có nghĩa là bạn có thể sẽ muốn bắt buộc tối thiểu mỗi dịch vụ mà gọi đến dịch vụ khác phải có connection pool riêng và bạn thậm chí có thể đi xa hơn khi nói rằng mỗi dịch vụ cũng sử dụng một bộ ngắt mạch (circuit breaker). Điều này sẽ được đề cập sâu hơn khi chúng ta thảo luận về microservices ở quy mô lớn trong Chương 11.

Chơi theo luật cũng quan trọng khi nói đến mã phản hồi (response code). Nếu bộ ngắt mạch của bạn dựa vào mã HTTP và một dịch vụ quyết định gửi lại mã 2XX do lỗi hoặc nhầm lẫn mã 4XX với mã 5XX, thì các biện pháp an toàn này có thể bị ảnh hưởng. Các mối quan tâm tương tự sẽ áp dụng ngay cả khi bạn không sử dụng HTTP; hiểu sự khác biệt giữa một yêu cầu OK và được xử lý chính xác, một yêu cầu không tốt và ngăn dịch vụ làm bất cứ điều gì với nó và một yêu cầu có thể OK nhưng chúng tôi không thể biết được vì máy chủ không hoạt động là chìa khóa để đảm bảo chúng tôi có thể thất bại nhanh chóng và theo dõi các vấn đề. Nếu các dịch vụ của chúng tôi hoạt động nhanh và lỏng lẻo với các quy tắc này, chúng tôi sẽ dẫn đến một hệ thống dễ bị tấn công hơn.

Quản trị thông qua quy tắc

Cùng nhau và thống nhất về cách mọi thứ có thể được thực hiện là một ý kiến hay. Nhưng dành thời gian để đảm bảo rằng mọi người đang tuân theo các nguyên tắc này sẽ kém thú vị hơn, vì đang đặt gánh nặng lên các developer trong việc deploy tất cả những điều tiêu chuẩn này mà bạn mong đợi mỗi dịch vụ thực hiện. Tôi rất tin tưởng vào việc giúp bạn dễ dàng làm điều đúng đắn. Hai kỹ thuật mà tôi thấy hoạt động tốt ở đây là sử dụng các mẫu và cung cấp các khuôn mẫu dịch vụ.

Người làm mẫu

Viết tài liệu là tốt và hữu ích. Tôi thấy rõ giá trị, nên sau tất cả tôi đã viết cuốn sách này. Nhưng các developer cũng thích viết mã nguồn, và mã nguồn là thứ mà họ có thể chạy và khám phá. Nếu bạn có một bộ tiêu chuẩn hoặc phương pháp hay nhất mà bạn muốn khuyến khích, thì việc có những ví dụ mẫu mà bạn có thể chỉ cho mọi người sẽ hữu ích. Ý tưởng là mọi người không thể sai lầm chỉ bằng cách bắt chước một số bộ phận tốt hơn trong hệ thống của bạn.

Lý tưởng nhất, đây phải là những dịch vụ trong thế giới thực mà bạn có để làm mọi thứ ổn thỏa, chứ không phải là những dịch vụ biệt lập chỉ được deploy để trở thành những ví dụ hoàn hảo. Bằng cách đảm bảo rằng những ví dụ mẫu của bạn thực sự đang được sử dụng, bạn đảm bảo rằng tất cả các nguyên tắc bạn thực hiện thực sự có ý nghĩa.

Một dịch vụ mẫu phù hợp

Sẽ thật tuyệt nếu bạn có thể giúp tất cả các developer thực sự dễ dàng tuân theo hầu hết các nguyên tắc mà bạn có với rất ít công việc phải không? Điều gì sẽ xảy ra nếu, ngay từ đầu, các developer đã có hầu hết các mã nguồn để deploy các thuộc tính cốt lõi mà mỗi dịch vụ cần?

Dropwizard và Karyon là hai micro container mã nguồn mở, dựa trên JVM. Chúng hoạt động theo những cách tương tự, tập hợp một bộ các thư viện lại với nhau để cung cấp các tính năng như kiểm tra tình trạng, phục vụ HTTP hoặc hiển thị số liệu. Vì vậy, ngay từ đầu, bạn đã có một dịch vụ hoàn chỉnh với một servlet container có thể được nhúng và khởi chạy từ dòng lệnh. Đây là một cách tuyệt vời để bắt đầu, nhưng tại sao lại dừng lại ở đó? Trong khi bạn đang sử dụng nó, tại sao không lấy một cái gì đó như Dropwizard hoặc Karyon và thêm nhiều tính năng hơn để nó trở nên phù hợp với ngữ cảnh của bạn?

Ví dụ, bạn có thể muốn bắt buộc sử dụng bộ ngắt mạch. Trong trường hợp đó, bạn có thể tích hợp một thư viện như Hystrix. Hoặc bạn có thể có một thực tế rằng tất cả các chỉ số của bạn cần phải được gửi đến một máy chủ Graphite trung tâm, vì vậy có thể kéo thư viện mã nguồn mở như Dropwizard’s Metrics và định cấu hình nó để thời gian phản hồi và tỷ lệ lỗi được đẩy tự động đến một vị trí đã biết.

Bằng cách điều chỉnh một khuôn mẫu dịch vụ như vậy cho tập hợp các phương pháp phát triển của riêng bạn, bạn đảm bảo rằng các nhóm có thể tiến hành nhanh hơn và các developer cũng phải cố gắng làm cho dịch vụ của họ hoạt động dù trong điều kiện không tốt.

Tất nhiên, nếu bạn chấp nhận nhiều stack công nghệ khác nhau, bạn sẽ cần một khuôn mẫu dịch vụ phù hợp cho từng loại. Tuy nhiên, đây có thể là một cách bạn hạn chế một cách tinh vi các lựa chọn ngôn ngữ trong nhóm của mình. Nếu mẫu dịch vụ nội bộ chỉ hỗ trợ Java, thì mọi người có thể không khuyến khích chọn các stack thay thế nếu họ phải tự làm nhiều việc hơn. Netflix, chẳng hạn, đặc biệt quan tâm đến các khía cạnh như khả năng chịu lỗi, để đảm bảo rằng sự cố ngừng hoạt động của một bộ phận trong hệ thống của họ không thể khiến mọi thứ không hoạt động theo. Để xử lý điều này, một lượng lớn công việc đã được thực hiện để đảm bảo rằng có các thư viện trên JVM để cung cấp cho các nhóm các công cụ họ cần để giữ cho các dịch vụ của họ hoạt động tốt. Bất kỳ ai giới thiệu một stack công nghệ mới có nghĩa là phải tái tạo tất cả nỗ lực này. Mối quan tâm chính đối với Netflix không phải là về nỗ lực trùng lặp mà thiên về thực tế là rất dễ mắc phải sai lầm này. Rủi ro mà dịch vụ không thể chịu lỗi khi có nhưng phần được làm mới khi deploy là cao nếu nó có thể ảnh hưởng nhiều hơn đến hệ thống. Netflix giảm thiểu điều này bằng cách sử dụng các dịch vụ sidecar, giao tiếp cục bộ với một JVM đang sử dụng các thư viện thích hợp.

Bạn phải cẩn thận rằng việc tạo khuôn mẫu dịch vụ không trở thành công việc của một nhóm công cụ hoặc một nhóm kiến trúc sư tập trung, những người chỉ định cách mọi thứ nên được thực hiện, mặc dù thông qua mã nguồn. Việc xác định các phương pháp bạn sử dụng phải là một hoạt động tập thể, vì vậy, lý tưởng nhất là (các) nhóm của bạn nên chịu trách nhiệm chung về việc cập nhật khuôn mẫu này (phương pháp tiếp cận nguồn mở nội bộ hoạt động tốt ở đây).

Tôi cũng đã thấy tinh thần và năng suất của nhiều nhóm bị suy giảm nghiêm trọng khi có một framework bị áp đặt sử dụng. Trong nỗ lực cải thiện khả năng tái sử dụng mã nguồn, ngày càng nhiều công việc được đặt vào một framework tập trung cho đến khi nó trở thành một con quái vật khổng lồ. Nếu bạn quyết định sử dụng một khuôn mẫu dịch vụ phù hợp, hãy suy nghĩ thật kỹ về công việc của nó. Lý tưởng nhất, việc sử dụng nó nên hoàn toàn là tùy chọn, nhưng nếu bạn muốn áp dụng nó một cách mạnh mẽ hơn, bạn cần hiểu rằng tính dễ sử dụng cho các developer sẽ là động lực chính.

Cũng cần lưu ý về những nguy cơ khi mã nguồn được chia sẻ lại. Với mong muốn tạo ra mã có thể sử dụng lại, chúng ta có thể đã tạo ra nguồn gốc của sự bó buộc (coupling) giữa các dịch vụ. Ít nhất một tổ chức mà tôi đã nói chuyện với họ, họ lo lắng về điều này đến nỗi nó thực sự đã sao chép mã nguồn khuôn mẫu dịch vụ của mình theo cách thủ công vào mỗi dịch vụ. Điều này có nghĩa là việc nâng cấp lên khuôn mẫu dịch vụ cốt lõi sẽ mất nhiều thời gian hơn để được áp dụng trên toàn hệ thống, nhưng điều này ít liên quan đến nó hơn là nguy cơ của sự bó buộc. Các nhóm khác mà tôi đã nói chuyện chỉ đơn giản coi mẫu dịch vụ là một dependency kiểu nhị phân (đã được compile) được chia sẻ, mặc dù họ phải rất chăm chỉ trong việc không để bị DRY (don’t repeat yourself – đừng lặp lại chính mình) dẫn đến một hệ thống kết hợp quá chặt chẽ với nhau! Đây là một chủ đề mang nhiều sắc thái, vì vậy chúng ta sẽ khám phá chi tiết hơn trong Chương 4.

[note1]: Đây là một nguyên tắc trong việc phát triển phần mềm, nói đến việc không để mã nguồn bị lặp lại. Trong cuốn The Pragmatic Programer thì Dry được định nghĩa như sau: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

Nợ kỹ thuật – Technical Debt

Chúng ta thường bị đặt vào những tình huống mà chúng ta không thể theo kịp về tầm nhìn kỹ thuật của chúng ta. Thông thường, chúng ta cần phải lựa chọn cắt một vài góc để có được một số tính năng cấp thiết. Đây chỉ là một sự đánh đổi nữa mà chúng ta sẽ thấy mình phải thực hiện. Tầm nhìn kỹ thuật của chúng ta tồn tại là có lý do. Nếu chúng ta đi chệch khỏi lý do này, nó có thể mang lại lợi ích ngắn hạn nhưng phải trả giá dài hạn. Một khái niệm giúp chúng ta hiểu sự đánh đổi này là nợ kỹ thuật (technical debt). Khi chúng ta tích lũy món nợ này, cũng giống như nợ trong thế giới thực, nó có chi phí liên tục và là thứ chúng ta muốn trả bớt.

Đôi khi nợ kỹ thuật không chỉ là thứ mà chúng ta gây ra bằng cách đi tắt. Điều gì xảy ra nếu tầm nhìn của chúng ta đối với hệ thống thay đổi, nhưng không phải tất cả hệ thống của chúng ta đều phù hợp? Trong tình huống này, chúng tôi đã tạo ra các nguồn nợ kỹ thuật mới.

Công việc của kiến trúc sư hệ thống là nhìn vào bức tranh toàn cảnh hơn và hiểu được sự cân bằng này. Có một số quan điểm về mức độ nợ và những chỗ ảnh hưởng, là điều quan trọng. Tùy thuộc vào tổ chức của bạn, bạn có thể cung cấp một hướng dẫn theo kiểu nhẹ nhàng, và để các nhóm tự quyết định cách theo dõi và thanh toán khoản nợ. Đối với các tổ chức khác, bạn có thể cần phải làm việc có nguyên tắc và cấu trúc hơn, có thể là duy trì việc log những khoản nợ và xem xét thường xuyên.

Xử lý ngoại lệ

Vì vậy, các nguyên tắc và thực tiễn của chúng ta hướng dẫn cách xây dựng hệ thống của chúng ta. Nhưng điều gì xảy ra khi hệ thống của chúng ta đi chệch hướng này? Đôi khi chúng ta đưa ra quyết định chỉ là một ngoại lệ của quy tắc. Trong những trường hợp này, bạn nên ghi lại quyết định như vậy vào log ở đâu đó để tham khảo trong tương lai. Nếu tìm thấy đủ các trường hợp ngoại lệ, chúng ta cũng có thể thay đổi nguyên tắc hoặc thông lệ để phản ánh một cách hiểu mới về thế giới. Ví dụ, chúng tôi có thể có một thông lệ nói rằng chúng ta sẽ luôn sử dụng MySQL để lưu trữ dữ liệu. Nhưng sau đó chúng tôi thấy những lý do thuyết phục để sử dụng Cassandra để lưu trữ có khả năng mở rộng cao, tại thời điểm đó, chúng tôi thay đổi cách nói của mình để nói, “Sử dụng MySQL cho hầu hết các yêu cầu lưu trữ, trừ khi bạn mong đợi sự tăng trưởng lớn về khối lượng dữ liệu, trong trường hợp đó hãy sử dụng Cassandra.”

Tuy nhiên, tôi cần phải nhắc lại rằng mọi tổ chức đều khác nhau. Tôi đã làm việc với một số công ty nơi các nhóm phát triển có mức độ tin cậy và quyền tự chủ cao và ở đó các nguyên tắc rất gọn nhẹ (và nhu cầu xử lý ngoại lệ công khai sẽ giảm đáng kể nếu không bị loại bỏ). Trong các khu tổ chức có cấu trúc hơn, trong đó các developer có ít tự do hơn, việc theo dõi các ngoại lệ có thể rất quan trọng để đảm bảo rằng các quy tắc được đưa ra phản ánh đúng những thách thức mà mọi người đang phải đối mặt. Với tất cả những gì đã nói, tôi là một fan hâm mộ của microservices như một cách tối ưu hóa quyền tự chủ của các nhóm, mang lại cho họ nhiều quyền tự do nhất có thể để giải quyết vấn đề trong tầm tay. Nếu bạn đang làm việc trong một tổ chức đặt ra nhiều hạn chế về cách các developer có thể thực hiện công việc của họ, thì microservices có thể không dành cho bạn.

Quản trị và Lãnh đạo từ Trung tâm

Một phần của những gì kiến trúc sư hệ thống cần xử lý là quản trị. Quản trị mà tôi muốn đề cập đến là gì? Hóa ra Kiểm soát mục tiêu đối với Công nghệ Thông tin và những thứ Liên quan (Control Objectives for Information and Related Technology – COBIT) có một định nghĩa khá hay:

Quản trị đảm bảo rằng các mục tiêu của doanh nghiệp đạt được bằng cách đánh giá các nhu cầu, điều kiện và lựa chọn của các bên liên quan; thiết lập phương hướng thông qua ưu tiên và ra quyết định; và giám sát việc thực hiện, tuân thủ và tiến độ so với chỉ đạo và mục tiêu đã thống nhất. — COBIT 5

[note2]: đây một framework được đề xuất bởi ISACA (Hiệp hội Kiểm tra và Kiểm soát Hệ thống Thông tin), nhằm giúp các tổ chức đang tìm cách phát triển, triển khai, giám sát và cải thiện quản trị CNTT và quản lý thông tin.

Quản trị có thể áp dụng cho nhiều thứ trong diễn đàn CNTT. Chúng tôi muốn tập trung vào khía cạnh quản trị kỹ thuật, điều mà tôi cảm thấy là công việc của kiến trúc sư. Nếu một trong những công việc của kiến trúc sư là đảm bảo tầm nhìn kỹ thuật, thì quản trị là đảm bảo những gì chúng tôi đang xây dựng phù hợp với tầm nhìn này và phát triển tầm nhìn nếu cần.

Kiến trúc sư chịu trách nhiệm về rất nhiều thứ. Họ cần đảm bảo có một bộ nguyên tắc có thể hướng dẫn sự phát triển và những nguyên tắc này phù hợp với chiến lược của tổ chức. Họ cũng cần đảm bảo rằng những nguyên tắc này không yêu cầu các phương pháp làm việc khiến các developer phải khổ sở vì nó. Họ cần cập nhật công nghệ mới và biết khi nào cần đánh đổi đúng. Đây là một trách nhiệm lớn khủng khiếp. Tất cả những điều đó, và họ cũng cần kéo mọi người theo — nghĩa là, để đảm bảo rằng các đồng nghiệp mà họ đang làm việc hiểu được các quyết định đang được đưa ra và được đưa vào thực tế để thực hiện chúng. Ồ, và như chúng tôi đã đề cập: họ cần dành một chút thời gian với các nhóm để hiểu tác động của các quyết định của họ và thậm chí có thể viết mã nguồn nữa.

Đó là một yêu cầu cao? Chắc chắn rồi. Nhưng tôi chắc chắn với quan điểm rằng họ không nên làm điều này một mình. Một nhóm quản trị hoạt động tốt có thể làm việc cùng nhau để chia sẻ công việc và định hình tầm nhìn.

Thông thường, quản trị là hoạt động của nhóm. Đó có thể là một cuộc trò chuyện thân mật với một nhóm đủ nhỏ hoặc một cuộc họp thường xuyên có cấu trúc hơn với tư cách thành viên nhóm chính thức cho phạm vi lớn hơn. Đây là lúc tôi nghĩ các nguyên tắc mà chúng ta đã đề cập trước đó nên được thảo luận và thay đổi theo yêu cầu. Nhóm này cần được dẫn dắt bởi một tay công nghệ và chủ yếu bao gồm những người đang thực hiện công việc được quản lý. Nhóm này cũng phải chịu trách nhiệm theo dõi và quản lý các rủi ro kỹ thuật.

Một mô hình mà tôi rất thích là có kiến trúc sư chủ trì nhóm, nhưng có phần lớn nhóm được thu hút từ các tay công nghệ của mỗi nhóm deliver sản phẩm — tối thiểu là những nhóm trưởng. Kiến trúc sư chịu trách nhiệm đảm bảo nhóm hoạt động, nhưng toàn bộ nhóm chịu trách nhiệm quản trị. Điều này chia sẻ công việc của kiến trúc sư và đảm bảo rằng có mức độ tham gia cao hơn vào các quyết định từ các nhóm. Nó cũng đảm bảo rằng thông tin luân chuyển tự do từ các nhóm vào toàn bộ tập thể và kết quả là việc đưa ra quyết định trở nên hợp lý và đầy đủ thông tin hơn nhiều.

Đôi khi, nhóm có thể đưa ra quyết định mà kiến trúc sư không đồng ý. Lúc này, kiến trúc sư phải làm gì? Tôi đã gặp tình trạng này trước đây, và có thể nói với bạn đây là một trong những tình huống khó khăn nhất phải đối mặt. Thông thường, tôi thực hiện cách tiếp cận mà tôi nên đi với quyết định của nhóm. Tôi cho rằng tôi đã cố gắng hết sức để thuyết phục mọi người, nhưng cuối cùng thì tôi thấy không đủ thuyết phục. Nhóm thường khôn ngoan hơn nhiều so với từng cá nhân, và tôi đã nhiều lần bị chứng minh là sai! Và hãy tưởng tượng việc một nhóm được cho không gian để đưa ra quyết định, và cuối cùng bị bỏ qua. Nhưng đôi khi tôi đã bác bỏ ý kiến của cả nhóm. Nhưng tại sao, và khi nào? Làm thế nào để bạn chọn cách làm?

Hãy nghĩ đến việc dạy trẻ đi xe đạp. Bạn không thể đi hộ cho họ. Bạn thấy chúng chao đảo, nhưng nếu bạn tham gia vào mỗi lần như thể chúng có thể ngã ra, thì chúng sẽ không bao giờ học được và trong mọi trường hợp, chúng sẽ ngã ra ít hơn bạn nghĩ! Nhưng nếu bạn thấy họ chuẩn bị lao vào dòng xe cộ hoặc vào một cái ao gần đó, thì bạn phải can thiệp. Tương tự như vậy, là một kiến trúc sư, bạn cần phải nắm chắc khi nào, theo nghĩa bóng, nhóm của bạn đang lái vào một cái ao. Bạn cũng cần lưu ý rằng ngay cả khi bạn biết mình đúng và bác bỏ ý kiến của nhóm, điều này có thể làm suy yếu vị trí của bạn và cũng khiến nhóm cảm thấy rằng họ không hề có tiếng nói. Đôi khi điều đúng đắn là đi cùng với một quyết định mà bạn không đồng ý. Biết khi nào nên làm điều này và khi nào không nên làm điều này là khó khăn, nhưng đôi khi đó lại là một điều quan trọng.

Xây dựng đội ngũ

Trở thành người chính chịu trách nhiệm về tầm nhìn kỹ thuật của hệ thống của bạn và đảm bảo rằng bạn đang thực hiện tầm nhìn này không chỉ là việc đưa ra quyết định về công nghệ. Chính những người bạn làm việc cùng sẽ thực hiện công việc. Phần lớn vai trò của người lãnh đạo kỹ thuật là giúp phát triển họ — giúp họ tự hiểu tầm nhìn — và cũng đảm bảo rằng họ cũng có thể là những người tham gia tích cực trong việc định hình và thực hiện tầm nhìn.

Giúp những người xung quanh bạn phát triển sự nghiệp có thể có nhiều hình thức, hầu hết đều nằm ngoài phạm vi của cuốn sách này. Tuy nhiên, có một khía cạnh mà kiến trúc microservice đặc biệt có liên quan. Với các hệ thống lớn hơn, monolithic, có ít cơ hội hơn để mọi người nâng cấp và sở hữu thứ gì đó. Mặt khác, với các microservice, chúng tôi có nhiều mã nguồn cơ sở tự trị và sẽ có các vòng đời độc lập của riêng chúng. Giúp mọi người thăng tiến bằng cách để họ làm chủ các dịch vụ riêng lẻ trước khi nhận thêm trách nhiệm có thể là một cách tuyệt vời để giúp họ đạt được mục tiêu nghề nghiệp của riêng mình, đồng thời giảm bớt gánh nặng cho người phụ trách!

Tôi rất tin tưởng rằng phần mềm tuyệt vời đến từ những con người tuyệt vời. Nếu bạn chỉ lo lắng về khía cạnh công nghệ của phương trình, bạn đang thiếu một nửa bức tranh rồi đó.

Tóm tắt

Để tóm tắt chương này, đây là những gì tôi thấy là trách nhiệm cốt lõi của kiến trúc sư khi phát triển:

1. Tầm nhìn

   Đảm bảo có một tầm nhìn kỹ thuật được truyền đạt rõ ràng cho hệ thống sẽ giúp hệ thống của bạn đáp ứng các yêu cầu của khách hàng và tổ chức của bạn

2. Đồng cảm

   Hiểu tác động của các quyết định của bạn đối với khách hàng và đồng nghiệp của bạn

3. Sự hợp tác

   Tương tác với càng nhiều đồng nghiệp và đồng nghiệp của bạn càng tốt để giúp xác định, tinh chỉnh và thực hiện tầm nhìn

4. Khả năng thích ứng

   Đảm bảo rằng tầm nhìn kỹ thuật thay đổi khi khách hàng hoặc tổ chức của bạn yêu cầu

5. Quyền tự trị

   Tìm sự cân bằng phù hợp giữa tiêu chuẩn hóa và tạo quyền tự chủ cho các nhóm của bạn

6. Quản trị

   Đảm bảo rằng hệ thống đang được deploy phù hợp với tầm nhìn kỹ thuật

Kiến trúc sư của hệ thống khi tiến hóa là người hiểu rằng để đạt được kỳ tích này là một sự cân bằng liên tục. Các lực đẩy luôn thúc đẩy bạn theo cách này hay cách khác, và việc đứng ở đâu để đẩy lùi hoặc đi đâu với dòng chảy thường là điều thường đi liền với kinh nghiệm. Nhưng phản ứng tồi tệ nhất đối với tất cả những lực đẩy chúng ta đến sự thay đổi là trở nên cứng nhắc hoặc cố định hơn trong suy nghĩ của chúng ta.

Mặc dù phần lớn lời khuyên trong chương này có thể áp dụng cho bất kỳ kiến trúc sư của hệ thống nào, nhưng các microservice cho chúng ta nhiều quyết định hơn để đưa ra. Vì vậy, có thể cân bằng tốt hơn tất cả những sự đánh đổi này là điều cần thiết.

Trong chương tiếp theo, chúng ta sẽ đưa ra một số nhận thức mới về vai trò của kiến trúc sư đối với chúng ta khi chúng ta bắt đầu suy nghĩ về cách tìm ra ranh giới phù hợp cho microservices.