在傳統企業做網際網路架構是什麼感受?
作者 | 王曄倞
責編 | 郭 芮
最近與某位搞風險投資的朋友聊起中美貿易戰,他對未來局勢的走向很是悲觀,而我卻不屑一顧。
在他眼裡,當下的美國已將中國列為競爭對手,曾今的大哥擺出了一副 “你若不死,絕不收手” 的架勢——無論你再妥協,再討好,甚至跪下,大哥恐怕也決不會罷休。因此,曾今的小弟也只能勉強還以 “你若強幹,奉陪到底” 的架勢,盡力不用任性、衝動的行為舉止來對待至關重要的中美經濟關係。
在聚會即將結束的時候,他說:“不過也只有在這種經濟背景下才能分辨企業價值的真偽,畢竟當經濟潮水退去之後,才知道誰在裸泳,你看那些天天嚷嚷著 ‘華為式狼性文化’ 的網際網路企業,如今還有幾家活著?反而是那些膽小謹慎的 ‘烏龜式傳統型企業’,雖說成本控制嚴緊,使得網際網路架構發展受限,但基本都還活得不錯。”
不過在我看來,在寒冬來臨之際,即便傳統企業已囤夠了食物與資源,在許多技術男眼裡,能去網際網路企業還是夢寐以求的願望,而傳統企業似乎早就已被歷史所唾棄,哪還會管它是死是活呢?
在傳統企業搞IT都會遭遇到什麼?
在傳統企業中,一般系統應用之間沒有太大的關聯,按業務功能垂直切分即可,聯通或互動均使用關係型資料庫來解決,同時連線多個數據庫無非多搞幾個連線池就行了。
在面對業務需求實現的時候,通常會有兩種應對方法:
第一種,如果要在原應用上增加新功能,或對某項功能進行擴充套件,就將原本較小的系統慢慢發育成較大的系統。這種方式適用於需求比較少,且對迭代速度要求不高的情況下。
第二種,另起爐灶,推翻原有系統,針對新需求進行重新設計、開發。
圖1 傳統的IOE架構
俗話說,什麼樣的土壤,就適合種植出什麼樣的植物。聊完技術視角,我們再來聊聊企業文化視角。
在傳統企業中,常會聽到 “技術不重要,不要過分強調” 這樣的論調,似乎是說,行業IT的主要目標是開發、支援業務應用系統,不管用什麼技術,只要可靠、穩妥、“成熟”,能把應用系統功能按業務部門要求做出來就行了。
什麼技術創新,什麼高擴充套件性,能通過加機器解決的場景都不是問題。管它什麼Java還是C++,還是其他什麼鬼,按時交貨、上線不出問題,就是好樣的。
比如,在強監管控制下的金融行業,不管用什麼技術,監管提出個新要求,無論你用外包還是自研,能跑通就萬事大吉了。
再比如,你技術團隊的老大很有技術情懷,想要自主研發了一套訊息中介軟體,首先團隊要發自肺腑的想幹這事,但要在不影響業務型專案進度的前提下、發揮極其巨大的“主觀能動性”、自發自覺加班加點,或者躲在家裡作為業餘興趣才能搞得起來。為什麼這麼說?因為在高層眼中,技術資源的配比都是按照業務功能對應計算得出的,假設A系統需要5個研發,再按業界標準配1個測試,運維工作可以共享,你說要加倆人搞個跟業務無關的東西?不好意思,一聽不懂,二不明白,三請拿出價值鏈導向公式,用非技術人能聽懂的邏輯關係說明白投入與回報之間的利益關係。
在我看來,在大部分的傳統企業中,最終決策的高管通常不僅都是前臺業務出生,而且從未經歷過網際網路文化的洗禮,對於技術與科技的認知只停留在工具化階層,怎麼理解這句話呢?比如,A銷售員每年能給公司帶來1000W的利潤,而B銷售員每年只能給公司帶來800W的利潤,那麼A銷售員必然會受到更多精神上的認可,物質上的獎賞,這個邏輯很好理解。但想要讓高管弄明白一套訊息中介軟體的奧妙,外加IT人天生口舌笨拙,他們自然不能理解為什麼需要投入這些無法見到收益的資源。
我覺得,傳統企業的IT特點通常可概括為以下幾點:
傳統架構被拋棄的真正原因是什麼?
在許多人眼裡,“資源成本高” 與 “人才招聘難” 是傳統架構被拋棄的兩大最根本原因。我覺得這種觀點既片面,且不客觀。
先來說說 “資源成本高”。有人抨擊Oracle、WebLogic這樣的商業軟體,不僅Listener貴,而且還必須跑在高昂的硬體資源上(比如小型機),而用MySQL不僅免費,而且還能上雲,既便宜,又實惠。
以我曾經在某家電商公司的Oracle10g為例,費用支出一般可以分為以下四個部分:
購買Oracle License;
購買Oracle第三方服務;
聘用資料庫管理員;
資料庫伺服器硬體。
記得曾粗略的估計過,每年成本投入在200萬左右。如果換成MySQL,除License能省點錢之外,其餘部分不見得能省多少。但還是有人會怒噴,說Oracle不能上雲,MySQL能上雲,上雲的費用比私有IDC便宜很多,這部分費用你怎麼不算?
以我現在的公司為例,為了上雲我們曾粗略的計算過成本,如果是公共雲,的確可以省去不少的成本,但對於金融等強監管領域,從政策維度就沒有可行性。如果是私有云,單硬體成本這項,就會比傳統機房高出20%以上,再加一些PaaS服務的購買,拿個計算器按按,心裡也會犯起嘀咕。
再來說說 “人才招聘難”。有人抨擊說現在懂Oracle、WebLogic這樣的商業軟體的工程師屈指可數,而且這些技術早就扔進了歷史的垃圾堆,不信?看看簡歷就知道啦,都是Redis、MySQL與MQ這樣的關鍵字,不是精通,就是熟悉。
有一種現象叫,“企業的技術選型方向,並非來自於技術本身的優略性,而通常來自於技術當家人的情懷癖好”。
在90後當道的今天,有許多技術經理或總監,從他踏入技術圈的那天起,腦海中就充斥著 “某某寶用雲服務,某某去IOE” 的經典橋段,先不評判這種教條是對是錯,至少它是客觀存在的,而且它影響著人的意識與判斷。因此,只要你簡歷上寫上Redis、MySQL與MQ這些關鍵詞,就能獲得更多的面試機會,只要你對Redis、MySQL與MQ這些技術原理與場景的經驗越豐富,就能獲得更好的晉升與加薪的機會。
為什麼傳統企業也來搞網際網路架構?
有人說,照你這麼說,傳統企業那就老老實實的搞IOE唄。但有個問題奇怪,為什麼類似於銀行、製造業,也都紛紛舉起網際網路架構的大旗,搖旗吶喊的往裡拱呢?
不可否認,傳統架構存在一些弊端,無法滿足傳統企業在業務上的演進需求。
比如,工程效率。很多企業的商業套件隨著需求的高效發展往往需要很長時間的迭代過程才能上線新的業務,而當下的業務都開啟 “快速試錯,快速迭代” 的節奏,不可能等上線之後再重新發起個全流程,重來一次。
再比如,彈性不足。很多傳統企業在IT資源投入採用預算制,也就是在年初就已將支撐的使用者數量確定好,要多少錢,多少人都數好,而隨著業務的快速發展,甚至遇到業務下降的時候,傳統架構,無論硬體的擴容或縮容,還是軟體的License都無法快速的得到控制與下降(比如Oracle License是按照年度付費,還有像雲節點是按照使用時間進行收費,高峰時間擴容出去用,低峰時間又可以縮容回來)。
還比如,技術氛圍。傳統企業與網際網路企業一樣,都希望能夠吸引優秀的工程師,更希望能有頭部工程師帶動與引領,這樣就能帶動整個團隊進行跨行業的、從其他地方來的新思維、新技術、新理念的碰撞,從而避免思想與文化始終處於一個封閉的環境中,這樣做不僅有利於團隊穩定,也更利於技術傳承,好一好還能拿出一些技術成果去某技術大會上秀一把,滿足大夥精神上的裝X訴求。
總結思考
無論這是歷史之潮流,還是人心之所向,雖說流行程度並不能代表適合程度,但傳統架構在這股浪潮的波濤之中,逐漸走向滅亡已是不爭的事實。
不過,任何技術都是為業務服務而存在的,脫離業務的任何技術解決方案都是耍流氓的一種手段罷了。雖說在傳統企業做網際網路架構,有時會感到孤單、畏懼、不被認可,但一名優秀的技術領導者,應該是集樂觀、積極心態與自律於一身的複合型人物,當看到創新機遇時,會想到利用新技術與傳統業務之間的結合,創造出更有效的價值。
誰規定搞傳統業務的企業,就不能用上最前沿最好玩的技術了?誰規定傳統企業就無法吸引到優秀工程師了?
事在人為,並不衝突。
作者:王曄倞,18年IT從業經驗,現任職好買財富平臺架構部技術總監,負責好買中介軟體及平臺化的研發及運營,團隊管理和實施重大技術決策。曾任大智慧測試總監,在2年內帶領團隊自研了“大智慧雲測試平臺”,通過平臺化將金融資料服務業務從瀑布式逐漸轉型為DevOps。
宣告:本文為作者投稿,版權歸作者個人所有。
熱 文 推 薦
☞ 誰人來幫庫克賣“蘋果”?
☞ 雷軍立 Flag:小米 5 年 100 億 All in AIoT
☞ 離開 PC,在 iPad Pro 上也能程式設計了?
☞ 剛剛!程式設計師集體榮獲2個冠軍,這份2018 IT報告還說這些!
print_r('點個好看吧!');
var_dump('點個好看吧!');
NSLog(@"點個好看吧!");
System.out.println("點個好看吧!");
console.log("點個好看吧!");
print("點個好看吧!");
printf("點個好看吧!\n");
cout << "點個好看吧!" << endl;
Console.WriteLine("點個好看吧!");
fmt.Println("點個好看吧!");
Response.Write("點個好看吧!");
alert("點個好看吧!")
echo "點個好看吧!"
點選“閱讀原文”,開啟 CSDN App 閱讀更貼心!
喜歡就點選“好看”吧