ikeike443のブログ

ソフトウェアビジネスに関心がある系のブログ

Kongにジョインしました

ジョインしました、というのはかなり正確な表現です。Kongはまだ日本法人がないため、契約上は業務委託となっているので、入社というのはちょっと違うからです。

法人もなければまだオフィスもないので、今のところ私の自宅がKong Japanです。 f:id:ikeike443:20200103172748p:plain

Kongはサンフランシスコに拠点を置く会社で、APIゲートウェイKubernetesIngress controllerおよびService meshの領域で複数のOSSとそのエンタープライズ・ソリューションを提供している会社です。競合はApigeeやMulesoftと言われることもありますが、むしろLinkerdや最近Service meshみが著しいConsulあたりになっていくかもしれない雰囲気を出し始めていて、なかなか面白いことになりそうだと感じています。(Istioも競合になり得るかもしれないけど、今はむしろ協調して使ってもらうイメージを考えてるっぽい)

github.com

github.com

kuma.io

まだ自分もジョインしたばかりで勉強中なのでアレですが、マイクロサービスを推進していく際に最初に導入すべきものとして認知されていってきてるのが強みかなと思います。様々ソリューションを出していて、それをエンタープライズ・ソリューションを使って統合すると、アプリ種別でいうと伝統的なモノリスアプリから、k8s、各種サーバレスアプリ、プロトコルでいうとREST, GraphQL, gRPC, etc... をもろもろ合わせて透過的に扱えるようになるはずです。

特に個人的には最近出したKumaに注目しています。CTOの下記メッセージがとても刺さったのがジョインのきっかけでもあります。

Before Kuma, service mesh was considered to be the last step of architecture modernization after transitioning to containers and perhaps to Kubernetes. We believe this philosophy is backwards. Service mesh should be available before implementing other massive transformations so that developers can keep the network both secure and observable in the process.

訳: Kuma以前だと、サービスメッシュというのはアーキテクチャのモダン化プロセスの中でのコンテナ化とかKubernetesへの移行を終えた後の最後のステップと捉えられがちでした。我々はこの考え方はまるっきり逆だと考えています。サービスメッシュは大きなアーキテクチャの移行を実施し始める前に導入すべきです。それによってネットワークをセキュアでモニタリング可能な状態に保ちながら、アーキテクチャの移行プロセスを進めることができるからです。

jaxenter.com

当分は自宅とサンフランシスコで研修を受けたあと、既存のパートナー様やお客様先などを訪問する予定です。(日本にはすでに複数お客様がいらっしゃいます)

さて、とりあえずしばらく日本でたった一人なので、よかったらランチとか、Co-workとか、誘ってくださいまし。