libAlexandrina.so.octopress

Azure Service Fabric を検討しつつ IaaS な気持ちを忖度

| Comments

もう生VMインスタンスに生々しくOSを入れたり、サービス起動したりして、CPUやメモリの使用量であれこれというのは実質は時代遅れ。そういうのは俺たちの仕事ではない。最低限クラスタ管理ぐらいはやってくれないと〜という時代なのであろう。

私も結局そういったクラスタ管理とそのデプロイなどなどを使ってみて「そうかもしれないな」「これは便利かもな」と感じるまでは時間がかかった。

フルマネージドなサービス(= PaaS や SaaS)がイマイチ人気でないなかにおいて、IaaSは受け入れられた。そして運用した結果、「こんなんオンプレサーバがクラウドにいっただけやん。ダルイ。やっぱIaaSなんていらんのじゃね?」というところにまわりまわって行き着かせた。ということであろう。

客を成長させるというか「気づかせる」「欲しいものは与えるがきっとあなたが望んでいるものはその次だ」ところまでやり遂げるのはスゴイなーと感じるところ。(その結果、オンプレや IaaS を管理するお仕事の方々が、クラウド事業者とコストで勝負しないといけなくなっているんじゃないか?AWS、Azureなどに勝てるの? 無理じゃね? とは考えるがまぁこれはまた別の話)

そう思うこともあり、Facebook で「フィンテックだ!」とかいってシェアされた構成図を見ると

うんただのIaaSじゃん。何かこれ、革新的な見どころないじゃん?

という気持ち。某君と打ち合わせしたところ、先日のクラウドロードショウの話になった。やはり提示された内容はただ単にIaaSとしてAWSであり、特に見どころはない感じであった。どこの会社も結局のところ

  • AWS(IaaS)を採用し
  • 鉄板構成で配置(ELB + EC2 + DB + S3とか)

であり、すでにこの構成すら「保守的だなあ」という気持ち。おそらく、これですら、「先進的! 新しい!」とかそういう世界が現実なのであろう。先日行われたAWS-Summitの毎日新聞社さんの事例なんかは運用の話もあったので「これでもだいぶ業務が変わった、改善された」ということになっているのではないか。

さてそんなわけで、 Microsoft Azure では Azure Service Fabric というものが提供されており、軽く読んだところ Apache Mesos、Google Cluster Engine(Kubernetes) に相当するサービスなんだろうなーという気持ちになった。 Kubernetes での経験を言うと結局このポイントを抑えたい

  • こちらの用意したアプリはどうやって配置、指示するのか
  • 様々なミドルウェアサービス(例えばkvs、MySQL)の分散されるであろう内部アクセスエンドポイントの取得方法
    • どういう方法(例えば環境変数? 例えば内部DNS?)
  • こちらのインターネット(= ユーザ側へ)提供したい分散されるであろう外部エンドポイントの取得方法
  • アプリやミドルウェアのレプリカを増やした、減らした場合どうなんの?
  • VMをスケールアウトしたらどうなんの? どうすんの?
  • VMをスケールアップするのには停止がいるの? どうすんの?

このぐらいであろうか。しかし、学んでいただきたい(私は提案する立場であって、マジ運用する方々は別にいる前提)ことが多すぎてツライなーという気持ち。納期や予算があと3か月程度あればな。

C言語とかもそうだけれど、「自分で管理したい!」「何かあったらどうにかできるようにしておきたい」という気持ちはとてもよくわかるが、このあたりの「ここはまかせるべきだ」というバランス感覚というのはどうやったら育まれるのであろうか?

ほとんどの人間は「これまでどおりやりたい。それが一番自分の責任をとれるから」という気持ちからなかなか脱出できない。

私としてはその「何かあったら自力でなんとかしたい気持ち」はむしろ「大切」と考える。そしてそれが一般的なので一足とびに PaaS や SaaS にいかず、 IaaS からという実績、踏み台、順序が必要だったのであろう。

Comments