在構建整個系統之前，先構建3個互相交互的服務原型，找出實現非功能需求的解決方案，比如安全問題、服務發現、健康監控、回壓、失效備援，等等。

在被問及是否可推薦一些用于微服務開發的特定開發語言或技術時，研討會參與嘉賓之一的Adam Bien說：

Java已經誕生20多年了，它是一門成熟的開發語言，具有強大的工具和監控能力。Java在一開始就融入了微服務概念，比如Jini/JXTA框架，它們與No-SQL數據庫（比如JavaSpaces）混在一起。可以說，Java超前了15年，那個時候市場還沒有做好使用這些技術的準備。不過，從1999年以來的那些技術在今天仍然適用。我們并沒有重新造輪子。

在過去的一年甚至更長的時間中，大家總是將Linux容器和微服務等同看待，這也影響到了在監控上的考量。最近，在對來年的發展做出預測時，RisingStack的CTO Péter Márton給出了一些意見。他首先闡述了一些基本理念：

當前市面的APM（應用性能監控，Application Performance Monitoring）解決方案，例如NewRelic和Dynatrace，嚴重依賴于不同層級上的儀表展示（Instrumentation），這就是為什么這些產品必須要安裝軟件廠商特定的代理才能采集度量。代理可以采集應用的各種度量，包括垃圾回收行為等底層語言特定的度量，以及RPC和數據庫延遲等軟件庫特定的度量。

Péter進而指出，應注意不要過于快速推進乃至深入APM路線。他給出了如下的預測：

使用軟件廠商特定的代理會導致一個問題，當開發人員開始將多種監控解決方案和代理一并使用時，會丟失當前APM解決方案的一些特性。多代理通常意味著對同一構件代碼（code picec）給出多種儀表顯示方式，這可能會導致不必要的性能開銷、虛假的度量，甚至是軟件缺陷。我認為在未來使用軟件廠商特定代理的趨勢將發生變化，APM軟件提供商將通過共同努力提出儀表顯示的開放標準。未來將是獨立于軟件廠商的時代，所有價值來自于不同的后端和UI特性。

之后，Péter跳轉到分布式追蹤（distributed tracing）相關問題上。在他看來，為了監控并調試所涌現的容器和微服務，驅使開發人員提高實現可觀測性方法。過去我們也曾探討過分布式追蹤技術，例如Zipkin，以及近期Cindy Sridharan對可觀測性的介紹：

日志、指標和請求跟蹤是可觀測性的基礎。日志為數據（如指標）提供額外的上下文。不過，日志對性能的影響也很大。相比之下，指標的開銷是不變的，而且有利于預警。總而言之，日志和指標可以為觀察單獨的系統提供方便，但是對于穿過多個系統的請求，很難提供其生命周期的信息。跟蹤提供了跟蹤在各個系統之間傳遞的請求的能力。

Péter也同意上述觀點。在文章中探討OpenTracing技術及其重要性之前，他給出了一些例子，說明了想要提供的內容：

(……）標準，以及用于分布式追蹤儀表顯示的接口，這些接口是獨立于軟件廠商的。Opentracing提供了一套標準的API，對代碼情況做儀表顯示，并連接到各種追蹤后端。它也可以在任何時候對代碼做儀表顯示。不存在任何問題，并更改追蹤后端。

他給出了一些在原始技術中使用OpenTracing的例子，特別是從Node.js開發的角度。在文章結尾處，他作出了一個強調聲明，也可以說是一個請求：“我希望將來會有越來越多的標準化儀表顯示解決方案，也希望有一天，所有的APM軟件廠商能共同努力，提供最好的軟件廠商獨立的代理”

但是，文章中更多內容是對OpenTracing的介紹。文中介紹了OpenTracing是如何與ElasticSearch和Prometheus一起工作的，其中給出一些例子和展示圖。正如Péter所指出的，這些例子顯示了OpenTracing在架構拓撲可視化上的強大功能，有助于理解發生問題時的相關情況。進一步，文中引用了RisingStack的一個Node.js的Metrics Tracer項目。據Péter介紹，該項目可用于：

（……）基于這些度量信息，對整體拓撲結果做逆向工程，并可視化各服務間的依賴關系。從這些度量中，我們可以獲得微服務架構中應用和數據庫間通量和延遲的相關信息。

在2016年早期，我們曾就“對大規模容器進行監控所面臨的挑戰”問題訪談了部分人士。當時就如何理解和使用追蹤所采集數據方面的問題，Dynatrace的首席技術戰略師Alois Reitbauer給出了以下觀點：

（……）每個人都必須了解這些監控數據。這也是為什么我們花費了大量時間以創建自解釋的信息圖表，讓每個人都能夠其中的意義。另一個關鍵需求是對異常情況的檢測。由于系統的巨大規模，沒有任何人能夠做到手動查看所有數字。因此，監控系統必須了解什么是正常的行為，并當系統的行為出現異常時進行提示。最后一個方面在于具備上下文的語義信息。舉例來說，監控系統需要“理解”指標所代表的意義，以及它與其他指標的關聯。我們需要了解整個應用中的所有依賴，將這此信息用于問題的分析。

在文章最后，Péter總結并給出了如下預測：

要使微服務的監控和觀測性更上一層樓，并步入下一代APM工具的時代，需要給出一種開放的、獨立于軟件廠商的儀表顯示標準，正如OpenTracing那樣。該新標準需應用于APM軟件廠商、服務提供商和開源軟件維護者。