設計上の選択が適切ならば，クラウドプロジェクトのオーバーエンジニアリングと大失敗はどちらも避けられる – 少し前に行われたMicrosoft Build 2015のセッション“Surviving Success: Architecting Web Sites and Services for Rapid Growth”の中で，Mark Simms氏とMark Souza氏はこのように述べた。
設計上の選択として両氏は，４つのカテゴリを挙げた - 拡張性，管理性，可用性，そして実現可能性だ。
拡張性は，データセンタからクラウドへ移行する時の最大の変化点だ。リソースを固定資産として余分に購入するのではなく，効果的かつ段階的にリソースを追加する方法を学ぶ必要がある。
テレメトリとALMによる管理性を忘れてはならない。それなくしては，問題の所在や解決法を知ることができないし，新たな変更による影響も分からない。望ましくない変更をしていることもあるのだ。
可用性とは，アプリケーションやその基盤となるサービスが，避けることのできない一時的ないし永続的障害にいかに耐え得るか，ということだ。
実現可能性とは，所定の期間と予算の下で，大きな技術的負債を被ることなく，新たな機能を永続的に追加できる能力だ。
時間や人材や資金をつぎ込まずに，このような非機能設計の選択を成し遂げることで，愉快な経験ではないにせよ，開発の“学びの時(learning moment)”を体験できるだろう，とSimms氏とSouza氏は主張する。
講演の中で両氏が強調したのは，設計上の意思決定に対して教育的判断を行う手段としてのテレメトリの必要性だ。システムの確認を日々の経験の一部にする必要がある。
４つのカテゴリに対処する上で，まず第１に両氏が挙げたのは，アプリケーションの性質を理解して，状況と一貫性に特別な注意を払いながら負荷を分散する，という作業だ。そのシステムは，バーストモードのアプリケーションだろうか？ 特定の時間(例えば午前9時から午後5時まで)内は，一貫して問題なく稼働しなければならないものだろうか？ 同時更新を伴うリアルタイムイベントを処理するモバイルプラットフォームならば，頻度の低いバッチ更新は分単位でも構わないが，読み取り一貫性については3～5秒のレベルで求められる場合もある。不測の事態を避けるためには，継続的に十分な時間を取ってテストすることが必要だ。
これらのことを理解した上で，お金と交換で貴重なエンジニアリング時間を手に入れよう。リソースが限られているならば，仮想マシンの管理をするよりもPAAS(Platform as a Service)を使った方が，さまざまな設計上の選択や解析が必要ない分，簡単になる。
ユーザよりも先に限界点を見つけることが必要だ。最小限のデプロイメント上で，破壊的なロードテストを実行しよう。競合点やスケールユニットを見つけられる。それによって，パフォーマンスの改善が必要かどうかを判断できるし，クラウドリソースを追加することで，新たな機能を追加する時間を捻出できる。
次はデータを使用して，リソースの追加が必要な場所を特定する。ボトルネックや競合点を特定するためにデータを利用しよう。将来的に必要になりそうな機能(キャッシュなど)が特定できるだろうか？
最後に検討するのは，複数のデータセンタによる運用への準備だ。フロントエンドあるいは中間層では，リソースの低い状態とコード複製が必要である。高度にステートフルなデータベースでは，結果整合性を持ったデータレプリケーションが必要だ。パフォーマンスとローカルベースのDNSルーティングを確保しなければならない。これらの項目をいくつも処理できるように，システムで準備しておこう。 自動公開と名前付きのデプロイメントを活用して，命令的ではなく規範的にシステムを定義しよう。そうすればテレメトリデータで，新たなデプロイメントを区別することができる。
Simms氏とSouza氏は講演の要約として，３つの点を強調した。機能を適切に実装する時間を確保するために，ダイナミックなクラウド環境を利用すること。問題点の選択と解決のための確立した基盤として，テレメトリデータを利用すること。そして，負荷状態の解析にデータを活用することだ。