Tránh sai lầm như Frankenstein khi chuyển sang microservices

Đầu tháng 10 đánh dấu sự bắt đầu của mùa Halloween, nhưng một điều bạn không muốn làm người dùng sợ hãi hoặc sợ hãi là ứng dụng của bạn. Có rất nhiều lợi ích để di chuyển các ứng dụng nguyên khối của bạn đến các dịch vụ nhỏ, nhưng nó có thể nói dễ hơn làm. Không có khả năng quản lý dịch vụ, thiết lập các ranh giới dịch vụ tốt và cung cấp độ tin cậy kết thúc tìm kiếm những gì mà một số ngành trong ngành gọi là các dịch vụ nhỏ của Frankenstein.

Frankenstein bắt đầu với ý định tốt để hiểu cách cơ thể con người hoạt động như thế nào, nhưng những gì ông đã kết thúc là một phiên bản bị xáo trộn và biến dạng của những gì ông dự định và có hiệu ứng xếp tầng khủng khiếp, theo Michael Hamrah, kiến trúc sư trưởng tại Namely. nhà cung cấp phần mềm.

Hamrah phát biểu tại hội nghị O’Reilly Velocity của tuần này tại thành phố New York để thảo luận cách tránh quái vật của các dịch vụ nhỏ của Frankenstein. Theo Hamrah, các công ty trở thành nạn nhân của cùng một vấn đề khi họ tham gia vào các dịch vụ nhỏ, và những gì họ kết thúc với một quá trình rất thủ công và đau đớn.

Phân khúc, một công ty hạ tầng dữ liệu khách hàng, gần đây đã viết một bài đăng trên blog có tên: Goodbye Microservices: Từ 100s vấn đề trẻ em đến 1 siêu sao. “Đầu năm 2017, chúng tôi đã đạt đến điểm bùng phát với một phần cốt lõi của sản phẩm của Phân đoạn. Có vẻ như chúng tôi đang rơi từ cây microservices, đánh vào mọi nhánh cây trên đường xuống. Thay vì cho phép chúng tôi di chuyển nhanh hơn, nhóm nhỏ thấy mình mệt mỏi vì bùng nổ sự phức tạp. Lợi ích thiết yếu của kiến trúc này trở thành gánh nặng. Khi vận tốc của chúng tôi giảm mạnh, tỷ lệ khuyết tật của chúng tôi bùng nổ, ”công ty viết.

Để tránh điều này, Hamrah đưa ra một số lời khuyên quan trọng:

• Giúp DevEx trở nên tuyệt vời
• Quyền sở hữu là một tính năng
• Khả năng quan sát là một tính năng
• Triển khai là một tương lai
• Quản lý giao thông là một tính năng
• Tiêu chuẩn là quan trọng, nhưng không tuyệt đối

Theo Hamrah, cách mà các dịch vụ siêu nhỏ hoạt động giống như “nước”. Ông đưa ra một ví dụ về cách Uber nghĩ, đó là “vận chuyển đáng tin cậy như nước chảy.” Ý của ông là ở thế giới thứ nhất, chúng ta lấy nước cho được cấp. Chúng tôi sử dụng nó để rửa bát đĩa, vòi sen và đồ uống, trong số những thứ khác. Tuy nhiên, chúng ta quên rằng vẫn còn một số lượng lớn cơ sở hạ tầng và phức tạp đi sâu vào nó. Có luật, hệ thống vệ sinh, thợ ống nước và kỹ sư liên quan.

Một dịch vụ nên sở hữu dữ liệu và chức năng, ngăn chặn sự kết nối, tạo ra cơ hội và có mục tiêu mức dịch vụ, theo Hamrah.

Nếu doanh nghiệp của bạn không thể xác định nhóm nào sở hữu dịch vụ thì họ sẽ không chuẩn bị sẵn sàng khi có sự cố. Hamrah giải thích các doanh nghiệp cần phải suy nghĩ về các đội và cách họ phân bổ các đội và công cụ để chạy và quản lý các dịch vụ. Bước tiếp theo là chọn một giải pháp tuần tự hóa và vận chuyển cho các dịch vụ có thể nói chuyện với nhau như thế nào. Hamrah đề xuất gRPC, một khung công tác RPC nguồn mở để xác định các dịch vụ. Sau đó, các doanh nghiệp sẽ muốn suy nghĩ về cách họ triển khai. “Hầu hết các vụ mất điện xảy ra từ một triển khai xấu”, Hamrah nói. Doanh nghiệp phải có khả năng hiển thị rõ ràng về những gì đang chạy trong từng môi trường và một nơi trung tâm để quản lý thay đổi. Ngoài ra, họ không bao giờ nên phối hợp triển khai, bởi vì đó là một hình thức khớp nối chặt chẽ.

Một doanh nghiệp yếu tố khác cần xem xét là khám phá dịch vụ và quản lý lưu lượng truy cập. Làm thế nào để bạn muốn xử lý và lưu lượng truy cập trực tiếp nếu có điều gì đó không ổn. Sau đó, suy nghĩ về khả năng quan sát. Bạn không muốn một bảng điều khiển cho mỗi microservice vì có thể có hàng chục hoặc hàng trăm, Hamrah giải thích. Công cụ phù hợp có thể giúp rút ra các chỉ số phù hợp.

Một điểm mấu chốt là nhớ mọi thứ luôn thất bại, Hamrah giải thích. Để chuẩn bị, anh đề nghị xem xét kỹ thuật hỗn loạn, một cách tiếp cận nhằm phá vỡ các hệ thống nhằm tìm ra các lỗ hổng và giải quyết chúng trước khi chúng xảy ra.

Cuối cùng, Hamrah nói sẽ mở ra những cơ hội mới. Ví dụ, Namely có ba cấp độ khi nói đến việc đưa công nghệ vào luồng công việc của họ. Đầu tiên, nó có các dịch vụ ưa thích mà nó đề xuất các đội của nó sử dụng. Tuy nhiên, công ty không muốn ngăn chặn cơ hội, vì vậy cấp độ tiếp theo được hỗ trợ công nghệ, nơi nó sẽ hỗ trợ một số công cụ nhất định. Cấp độ cuối cùng là công nghệ thử nghiệm. Đây là nơi ai đó có thể thử một cái gì đó mới và làm cho các trường hợp cho nó. Cụ thể sau đó sẽ đưa nó vào xem xét và nếu công ty cảm thấy như nó là mất tích từ hệ sinh thái của nó và nó cải thiện hệ sinh thái tổng thể, nó sẽ di chuyển nó đến các cấp độ công nghệ được hỗ trợ hoặc ưa thích.

“Tiêu chuẩn là quan trọng, nhưng không tuyệt đối. Mở khóa giá trị và tăng vận tốc tổng thể, ”ông nói. “Đẩy mã ra sản xuất. Làm điều đó một cách an toàn. ”

Nguồn bài viết : https://sdtimes.com