실천 사항에 따라 작업하고, 결정할 트레이드 오프에 대해 고민할 때 찾아내야 할 핵심 균형 중 하나는 여러분 시스템이 얼마나 많은 변동성을 허용할 수 있는가 하는 점이다. 서비스와 서비스간에 어떤 부분이 일정해야 하는지 식별하는 비결 중 하나는 바람직하게 동작하는 서비스의 모습을 정의하는 것이다.
넷플릭스의 소프트웨어 엔지니어인 벤 크리텐셀이 언급한 것처럼 우리가 큰 틀에서 시스템을 생각한다면 자율적인 수명주기를 가지면서도 함께 협없하는 수 많은 작음 부분으로 구성된 응집력 있는 시스템이 되어야 한다.
그러므로 우리는 거시적 시각을 잃지 않으면서도 개별 마이크로서비스 간의 자율성 최적화와 관련한 균형을 찾아야 한다. 이를 위한 확실한 방법 중 하나는 각 서비스가 가져야 할 명확한 속성을 정의하는 것이다.
우리는 서비스 간 경계를 넘어 시스템 상태를 일관되게 살펴 볼 수 있어야 한다. 즉, 서비스 세부 상태가 아닌 시스템 전체 상태를 볼 수 있어야 한다. 개별 서비스 상태를 아는 것도 유용하지만 때로는 광범위한 문제와 동향을 분석하고 이해해야 할 때가 있다. 이를 가능한 한 쉽게 실현하기 위해 필자는 모든 서비스가 자기 상태와 일반적인 모니터링 관련 지표를 동일한 방식으로 전송할 것을 제안한다.
어떤 것을 선택하든 표준을 유지하고 박스 안의 기술을 불투명하게 만들고, 모니터링 시스템을 지원하는 이유로 이를 변경하지 않도록 하라. 로깅 역시 모니터링과 같은 범주에 속하며, 한 곳에서 수집되록 해야 한다.
서비스 간 인터페이스 기술의 개수는 가능한 한 최소로 유지하는 편이 새로운 소비자(서비스)를 통합하는 데 도움이 된다. 표준은 하나인게 좋고 두 개도 그리 나쁘지는 않으나, 스무개는 너무 많다. 이는 단순히 기술이나 프로토콜을 선택하는 문제가 아니다.
아키텍트는 오동작하는 하나의 서비스가 전체를 망카뜨리게 해서는 안 되며, 서비스들이 비정ㅅ항적인 하위 호출로부터 자신을 잘 보호하도록 해야 한다. 서비스가 하위 호출의 잠재적 실패에 적절히 대비하지 못할 수록 시스템은 더 취약해진다.