5 ‘myths’ about microservices that people believe about but not always true

I want to share this article:
Microservices? Please, Don’t
Although the title of the article is “Don’t” but actually it is not dis-encourage you to not using microservice. It just talks about 5 ‘myths’ about microservices that people believe about but not always true.

Fallacy #1: Cleaner Code

“You don’t need to introduce a network boundary as an excuse to write better code.”

Fallacy #2: It’s Easier

“Distributed transactions are never easy.”

Fallacy #3: It’s Faster

“You could gain a lot of performance in a monolith by simply applying a little extra discipline.”

Fallacy #4: Simple for Engineers

“A bunch of engineers working in isolated codebases leads to ‘not my problem’ syndrome.”

Fallacy #5: Better for Scalability

“You can scale a microservice outward just as easily as you can scale a monolith.”

IT狗up – 講API platform solution講trend講生態

而家個時代是開始興唔玩monolith,轉玩API﹑microservice﹑container﹑distributed system等。

之前自己睇過既,坊間都開始有好多圍繞住API生態既platform solution。
而好多platform solution,簡單地說實際在做的都是這幾件事:
1) API owner 管理 API definition
2) 幫API owner 起隻 API portal
3) third party developer subscribe API
又或者我換個角度去概括呢幾件事,其實成套野就係facilitate去幫API owner同thirdparty developer做API形態既contract initiation。

但而家仲係個trend既岩岩開始,所以果d API生態未係好成熟,而platform solution亦可能同步地有少少濟後。
前面都有說過,坊間Platform solution,比較集中於API contract initiation。
但其實我看到的是,那些solution比較缺少了API integration test﹑後續維護的部份。

過往既API service形態都係一d比較concrete,少change的穩定soa service。
現時(2017)坊間大部份生態都是舊生態,都是比較CONCRETE﹑少CHANGE的穩定soa service。
所以在build contract之後也未必會改動;
所以即管platform solution缺少了API integration test﹑後續維護的部份,問題並不大。

我預期過多三兩年,IT architecture生態開始改變,應該會越來越多microservice/API as service既形態。
「你d API係咁change,我d API又係咁change,點maintain呀大佬?」
當成個生態都keep changing,2017當下這種純粹build contract的solution顯然是不夠的。

到時,除了當下較著重的API/microservice各自獨立的unit test,亦更著重如何做mock/integration test。
API management platform solution生態圈中需要的add-on,可能是API signiture management。
而unit test ﹑ API signiture ﹑ platform solution,會有更緊密的串連。