◯PaaSで十分なケースもある
Kubernetesの仕組みに関して、これは我々のサンプル的な、サービスメッシュを組むレベルでの簡易なアーキテクチャーなんですけど、ここまでやる仕組みってどれぐらいの規模なのかって話をすると、
僕はマイクロサービスの数が例えば10個、20個レベルでやる必要はないんじゃないかなと思っています。はっきり言って。
それだったら別にPaaSで十分だし、もっと言うとPaaSっていうか通常のコンテナで僕は全然いけると思うんですけど。
ここまでやる仕組みってそういうレベルじゃないと思うんですよね。
50個、100個、それ以上かもしれないし、しかもそれが複雑に絡み合って超クリティカルな仕組みを提供するようなものであれば、この手の仕組みが必要になってくるのかなとは思ってるんですけど。
そうじゃなくてはいけないのか?大規模システムじゃなくてはいけないのか?
というとそういうわけじゃない。
あくまでも導入するコストであったり、開発リソースであったり、そういうのを含めるとちょっと大げさなんじゃないかなっていうところあったりする。
なのでそこは上手く塩梅を作んなくちゃいけないですよね。
ただ実態として知っておくのはすごくいいと思います。
◯部門別に異なるお客様のニーズを理解する
じゃあこういったクラウドネイティブを提案する側として、どういうお客さんにどういうアプローチで提案すればいいんですか?っていう話もよく聞かれるんですよ。
そういったお客様には、我々はコンサルティングという形でいろいろ支援をさせて頂いてるんですけど、提案の仕方はおおよそ2つに分かれます。
それがこれです。だいたい2つに分かれる。
お客様のサービスがwebサービスなのか、そうじゃないかです。
webサービスかそうじゃないかと言うとすごいざっくりしちゃってるんですけど、要は
「金を生むサービスなのか、そうじゃないか」
で判断していいんじゃないかなと僕は思っているんです。
例えば情報システム部門のニーズって、少ない人数で多くのシステムを運用することです。
情報システム部門って社内のコストを管理する部門でもあるので、なるべく自分たちも自動化をしたり、最適化しながらやっていかなくちゃいけないわけですよね。
あとは事業部門からの要求にタイムリーに、柔軟に対応したいわけです。
例えば明日に誰かが一人アサインされるんだけど、そのアサインされるPCをすぐ用意してとかって、急に言われたりするわけですよ。
もしくはその逆ですね、チームが解体されるとか。
そういうニーズに対して柔軟に対応していきたいわけですよ。
直前になって何々が使えない、これを使うためには申請しなくちゃいけないとかって、すごく面倒くさいルールが発生しちゃうと柔軟に対応できない。
それでクレームというか、社内的にギスギスしちゃうわけです。
それが絡むと複雑なワークフローになったりするわけですね。
ハンコラリーとかそういうレベルじゃなくて、承認の段階がすごく複雑なんです。
この承認やったらこれやってあれやって、さらに承認やってあれやってこれやってみたいな、こういう手間があるとすごく大変ですよね。
ここらへんってさっき言ったSaaSを組み合わせるという考え方で上手くまとまるんじゃないかなと思ってるんですよ。
一方、サービス提供部門っていうのはスモールスタートでやりたいんですよね。
スモールスタートでやりたいから、最初にでっかい調達をしたくないわけです。
であればもうクラウド一択なんですね。
あとはJカーブに合わせた柔軟な環境を使いたいというニーズにですが、これはスタートアップに限る話じゃないです。はっきり言って。
どの事業においてもJカーブは絶対発生します。
スタートアップがJカーブって言っているけど、それは最近スタートアップのモデルを分かりやすく言うための言葉であって、昔からJカーブっていうのはどの事業でも絶対に発生するんですよね。
新しく何かやると全部Jカーブが出るんで、そうなった時に柔軟な環境を用意したいってよくある話じゃないですか。
僕はよく言うんだけど、右肩上がりの急カーブじゃなくてJなんですね。
赤を掘るんですよ。
でも赤を掘ってる時でもシステムを止められないじゃないですか。
そういう時にクラウドを活用できるということを言ってます。
あとはニッチな市場で尖ったサービスを提供したいお客様もいらっしゃいます。
その時に一から全部プラットフォームを作るの?っていう話です。
まずプロトタイプを作りましょう。だったらすぐにできる。
すぐに投下できるリソースが必要。だったらクラウドですよね。
あとストックモデルとしてweb を最大限活用したいニーズ。
これはSaaSですよね。SaaSビジネスをやりたいわけですよ。
サブスクとかイケてるサービスやりたいってなったらオンプレでもできるんですけど、さっき言ったように12 Factor Appだったり、そういった設計手法も既にあるわけですよ。
なのでそれを取り入れた方が早いので、情報システム部門とサービス提供部門がそれぞれにニーズが違うことを理解する必要があります。
例えば情報システム部門に一生懸命AIの提案しても通らないわけですよ。
もっともっとやるべきことが先にあるわけですね。
逆にサービス提供部門に頑張ってAD入れませんか?って言ってもそれもまた違うわけです。
上手くこの2つを理解して提案するといいなって思います。
それをオルターブースっていう会社はやっているわけです。
(つづく)
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
☆本記事は2020年3月23日に行われたライブ配信をもとに再構成しています
☆全編をご覧になりたい方はこちらから!