各位參賽選手～我是今天的主播 小笠宏樹！各位準備好了！！！3 2 1 ～ 比賽開始！

今天來推腦洞神劇好了
Moonmen Music Video (Complete) feat. Fart and Morty | Rick and Morty | Adult Swim

今天要來進一步聊聊我根據分拆公司去推演微服務可能情況的第二部分。

缺點

• 溝通成本

  • 雖然昨天的文章有提到分拆可以將溝通的邏輯變簡單，找到資源變容易，但假如我們將溝通分成前半部和後半部的話，分拆是將前半部變得異常簡單，但後半部就會因為掛公司的關係而導致難度上升。
  • 程式的邏輯應該也會差不多，雖然微服務可以讓你不用在茫茫的程式海裡找，可以直接有個大方向找哪一個微服務，但後續如果需要多次溝通做客製化的部分就會很麻煩

• 區域最佳解

  • 雖然說拆分可以讓各個子公司的核心業務目標越明確，這的確可以幫助子公司在優化自身業務時可以更方便，但是所謂的“區域最佳解”不一定是“全域最佳解”，有時候某一小部分的優化不代表是整體速度最快花費最少的方式。
  • 程式也是一樣的，雖然微服務可以讓架構變簡單，因此優化邏輯容易，但牽涉到微服務間的互相配合的時候就不一定是最快的解法了。

• 資源分配問題

  • 通常對於公司來講最重要的資源就是錢了，因此對於分公司來說分配資源有一個很好的比較基準就是賺不賺錢，當然就如同我們在財報那個所提到的可以用各式各樣的比較基準去衡量每一間分公司。
  • 這點如同上面寫的好像不是缺點，但是在程式中可是沒有一個方便的東西來當作衡量基準的，因此要如何分配工程師在每一個微服務所要花的精力就是一件非常麻煩的事。

• 主控權

  • 通常當拆分成各個子公司一段時間後，就會期望各個子公司可以各自找到更多的生存方式，不論是從各個分公司中組合出新的產品，或是從外部接到新的客源，但這些做了之後反而會造成合作間困難，哪個產品是核心？如果我找物流子公司做事跟找外面的子公司一樣要被加價沒有人情價和客製化，那我還需要物流子公司嗎？
  • 對於軟體更是這樣，拆成微服務的目的就是希望可以從中組合出更多產品的樣貌，但假如真的產生更多的產品樣貌了，那之後微服務該以哪個產品當主導權，比如：今天有一個產品的合作需要使用者微服務改變原本既有的API流程，並且使得使用它的其他產品都需要跟著變動，那它是改還是不改？那假設今天有100個產品都用同一個微服務，那這個微服務是根據這100個產品各種有些微差距的需求去做出“聯集”的功能還是我只做出“交集”的功能，要用不用隨便其他人？抑或是不那麼極端某些做“聯集”某些取“交集”，那要怎麼定義這個“某些”？

• 重工

  • 這應該不用解釋過多，拆分公司後每間分公司也會需要各自的人資、財會、行政等等重工的部門。
  • 程式也一樣，每個微服務都必須處理各自的基礎設定，像是網路服務、API介面、DB的處理等等。

• 知識領域的疆界

  • 當拆分成子公司後，同樣的是將某些知識領域從原本的母公司拆分出去了，這時候要如何做出一個從生產到物流到行銷都配合得恰到好處一個專案呢？可以認為一個專案要做得好可以不用所有的知識領域的配合嗎？但假如需要深度的配合，就很有可能會又掉回第一點“溝通成本”的問題。
  • 微服務也是，當兩個負責不同微服務的工程師要跟對方溝通，也會產生很多溝通障礙，由於不懂的對方微服務的知識，因而很有可能設計出不合適的API溝通方式。

市面上的解法

• 事業群負責人 - 將多個子公司的負責人都掛同一個。

  • 這個是為了解決“溝通成本”、“區域最佳解”、“資源分配問題”、“主控權”和少少的“知識領域的疆界”，可以利用這個負責人來處理跨子公司之間的知識問題，或是子公司之間的配合問題。
  • 從軟體的方法解釋這件事也很簡單，就是會讓好幾個微服務都給同一個工程師管，甚至是交錯管理以便產生更好的配合和分工，比如：Ａ工程師管a、b微服務，B工程師管b、c，C工程師管a、c。
  • 還有一種跟事業群負責人蠻像的是叫做對接窗口，他們會是有著其他子公司知識的人來其他常合作的子公司當溝通窗口，當然他沒有主控權，但可以彌補在“溝通成本”、“區域最佳解”和“知識領域的疆界”這些部分

• 控股公司 - 成立另外一家控股公司用以負責投資每間集團子公司。

  • 這個是為了解決“區域最佳解”、“資源分配問題”、“主控權”，可以利用這個控股公司來控制整體子公司的前進方向。
  • 從軟體的角度可能是人為的上司的命令，比較體制化可能會是PM會先開個會確定這次產品前進的方向會需要哪些微服務，然後看要投資多少人力在哪些微服務上。

• 母公司 - 就是產品的需求來源都來自同一個，其他公司只是輔助的角色。

  • 這個是為了解決“溝通成本”、“區域最佳解”、“資源分配問題”、“主控權”，母公司有很大的權力去要求子公司去配合它的需求，因此也會安插很多母公司的管理直到子公司，因此溝通成本可以降低，主控權也會極高。
  • 對於軟體來說就是所有微服務基本上還是只為了一個大的產品需求跑，但這個的後果很容易就是有拆等於沒拆，基本上還是被當作同一套軟體在運作，個人不推薦但很常見。

• 外包 - 子公司都只用外包的方式在處理其他人的需求

  • 這個是為了解決“溝通成本”、“資源分配問題”，這種方法的主控權很低，基本上就是與另外一間公司合作的感覺，但在溝通上因為會有外包的一套SOP，因此溝通上會比較容易（要嘛接受要嘛找別人），也會有另外一個好處是，子公司如果能做到這個程度也就可以沒有任何負擔的接外部的客戶。
  • 意思就是將微服務之間的耦合程度降到最低，基本上只能靠著特定幾個不變的API做溝通，因此就解決了溝通成本這件事，但微服務之間會很難配合新的彈性化的需求，但基本上這個微服務也可以開放給外部使用了。

糟糕的狀況

• 遇過幾個還蠻不好的例子的，這邊就敘述它們遇到的情況

1. 母公司要求就一定要做到，賠本也要做。
2. 每年其他公司都會給訂單，所以子公司的效率極差。
3. 之間由於知識差太多，反而會花很多時間在來回開會上。
4. 產品端時常覺得各個子公司的配合度極差。
5. 母公司的分配資源方式不公平。

PS：在寫區域最佳解的時候很有感，所以不得不來寫一段數據分析式的管理學
可以將公司想像成一個有深度的模型
當是一間大公司時這個模型就會是非常深的
此時假如一個非常深的模型想要到達預測的最佳解，只要投了足夠多的數據量（錢）、人力和物力，總是能在千辛萬苦後還是能達到最佳解。
而如果將大公司這個模型拆成很多小模型（子公司），再用線性回歸的方式串起來，那每個模型其實不用很多的資源就能達到最佳解了，但此時的最佳解跟大公司模型比起來還是輸了一節。
但這時候還是要注意一點，模型也不是越深越好，最直接的一點數據量（錢）、人力和物力都不是無限的，因此管理者始終要在一個大公司以及多個小公司之間做時機和市場上的抉擇。

好啦～由於想到一大堆害我打了好多字。
明天就是倒數第二篇了
會來講些比較軟的事情
明天的題目是“軟體教我的那些人生守則”