別にクラウドの限ったことじゃないのだが。
帯域計画。
忘れてるところ、多くないだろうか？
利用する側は、複数のクラウドサービスを利用する時。
サービス提供側は複数テナントを収容する時。
1つ1つを利用開始／実装開始するときに、その1つが動くかどうかだけを確認して、特にサービス提供側は富豪プログラミングをしていないだろうか？
利用者サイドの引き込み線の帯域も、サーバサイドの帯域も(サーバサイドは札束でぶん殴ればある程度は広げられるけど)、限りがある。
プロセッサ自体の速度はバカみたいに上がっているけど、通信経路の速度はさほど上がってないので、インターネットレベルでも、筐体レベル(Ethernet)でも、プロセッサレベル(Cache)でも、どれだけデータの移動を減らせるかを考えないと、利用者数のたかが知れてる社内システムではないので、影響が大きい。
そこら辺をちゃんと設計できる力は、必要なはず。
実際、GCPにしろ、AWSにしろ、内部管理サービス連携はかなり前から着実に設計実装していて、素晴らしい出来になっている。
ここで大事になってくるのは、OJT技術者は触れたことがないかも知れないし、通産省系のプログラマ認定資格であれば学習しているはずの、「待ち行列の理論」。
これを知っていて、「待ち行列というのは××が〇〇で……」と定義を暗唱できても、実際にどういうこと？ というのを理解できている人は、想像以上に少ない。
実の所、「コンピュータシステムのありとあらゆるところに待ち行列が存在している」のに。
中央の処理プロセッサ(CPU/APU)の処理ユニットも、ネットワークプロセッサも、サーバアプリのポートも、全て「窓口」で、そこを通るデータは全て「客」だということ。
初期開発者曰く「最新の関数型プログラミングでマルチスレッドを駆使して処理速度をあげています」という(このセリフ自体、実は不正確)サービスが、負荷が増えると謎の障害が発生していたのは待ち行列を全く理解してないからだった(システム全体がこれな上、切り分けて置き換えができないくらい密結合な絡み合った実装でね。テストもアリバイ作りのものしかなかった)。
自分の専門の一つは、クライアントとのやりとりデータの極小化と、筐体レベルのデータ移動の極小化で、10年以上前から本格的にやっているのだが、これの重要性は知っている人にとってはWebに紹介記事を出すほどのこともないくらいごく当たり前のことなのだが、ヘルプに入った先の技術者は全く知らないどころか、説明しても理解すらできない者がかなりの割合いた。
××というフレームワークをリンクするだけでOKというようなお手軽なものではなく、アーキテクチャレベルでの検討も必要なものなので敷居が高いかも知れないが、利用サーバを1／3に減らす(処理能力だけを考えればもっと減らせたが、冗長性確保のために複数台立てていたのでインパクトが薄まっている)とか、同時収容クライアントを10倍にするとか、元の設計が考慮なしの場合であれば、可能。
それのどこがおいしいかというと、つまり、原価がそれだけ減らせて(≒利益を増やせて)、多少の負荷変動も十分吸収できてオペレーションが減らせ(≒オペミスも減らせ)、大きな負荷変動がある場合も増減させるリソースの量が大幅に減らせる(≒リソース確保失敗による障害を減らせる)ということ。
「それいいね。うちでやってよ」
と言われても、元アーキテクチャによっては実装不可能な場合が多いので(直近2例は不可能で、Ver2を新規構築することになったので、今のところ100%すげ替え不能)、初期実装から参加させてもらえるとありがたいのです。
あと、関係技術者に理解する頭が必要です。
帯域は有限なので、一つ一つこまめに確認しないと、逼迫してからだとお手上げなのです。
モノによっては、社内にキャッシュサーバを設置することも想定した作りにしておくべきです。