RedMonkのJames Governor氏は先日，マイクロサービスの廃棄性をテーマに，Dreamforceで行う予定のセッションについて，その内容を紹介する記事を書いた。最近交わした会話の中で，あるひらめきがあったのだ，と氏は言う。
コンテナ採用の大きな理由がインフラストラクチャの廃棄性にあるのと同じような意義が，マイクロサービスにもあるのです。
要するに，今日では広く理解されるようになった，インフラストラクチャに対するペットと畜牛(cattle)のアプローチ(Randy Bias氏がInfoQなどで論じている)の区別が，マイクロサービスにも適用可能であり，そうすべきだということだ。
使い捨ては古くからの夢でした。Googleのハードウェア障害の対処方法を聞いたときの驚きを，私は今でも覚えています。障害の起きた機器を時々廃棄するだけで，障害発生時には何もする必要がない，というのです。Googleでハードウェアを廃棄可能にしたのは，ソフトウェアのアーキテクチャでした。今日では，そのようなアーキテクチャの考え方が，クラウドネイティブなソフトウェアの中核的な設計原理になっています。
急激な採用の拡がりを見せる不変のインフラストラクチャアプローチは，廃棄性の重要な面を担っている。これについてChad Fowler氏は，自身の会社が初めて不変性の採用に動いた2013年，インフラストラクチャのアップグレードに伴う問題の多くがこれで解決すると思った，と述べている。
アップグレードが必要？問題ありません。アップグレードしたシステムを新たに構築して，古いものは捨てればいいのです。アプリの新リビジョンですか？同じことです。新しいリビジョンでサーバ(またはイメージ)を作って，古い方は捨てましょう。
しかしながら，2014年のバーチャルパネルセッションでMitchell Hashimoto氏が語ったように，不変性はすべてに有効な万能策ではないのだ。
利点もありますが，欠点もあります。全体としては妥当な選択であり，方向性は正しいと思いますが，銀の弾丸ではありませんし，(他の問題を解決する一方で，)それまでにはなかった新たな問題を引き起こすかも知れません。その点は理解が必要です。
今日の不変性はインフラストラクチャのレベルを重視したものだが，そのパターンは上位層にも適用できる，と氏は考えている。自身が書いたRedMonkの以前の記事を引用しながら，Stephen O’Grady氏はひとつの疑問を呈する。インフラストラクチャの最小単位は今後，どのようなものになるのだろう？
一般的なコンテナやDockerは，オペレーティングシステム以下のすべてを共通基盤として扱います。それらは関心の対象としては，もはやデータセンタのフリーアクセスフロアと変わりありません。コンテナにおける構造上の基本単位はアプリケーションであり，唯一のユニークな要素なのです。
不変性と同一視まではしていないものの，マイクロサービスは廃棄可能であるべきだという同様の主張は，過去数年の間に他でもあった。例えばKief Morris氏は以前に書いた記事の中で，マイクロサービスについて具体的に言及はしていないものの，次のように述べている。
ソフトウェアの継続的デリバリでは，特定のバージョンのアプリケーションをコンパイルして展開可能なアーティファクトを作成するのは，一度だけにした方が無難です。デプロイして実行中のアプリケーションをビルドした環境が，すべて一貫して把握できるからです。不変な(immutable)サーバでは，変更はすべてベースイメージに対して行いますから，そのイメージから生成されたインスタンスすべてに一貫性のあることが分かります。
また，InfoQでは今年の初めにも，不変性がマイクロサービス以外でも多くの影響をもたらしている，というSalesforceのPat Helland氏の意見をレポートしている。
コンピューティングの上では，さまざまなものが“追加のみ”です。監視情報は永遠に(あるいは長期間)保存され，結果は必要に応じて(あるいは前もって定期的に)計算で求められます。そして – 標準化は楽ではないのです！
このように，不変性とマイクロサービスとの関係については，一部で検討や実装の対象とされているが，一方のGovernor氏が語った廃棄性のひらめきについては，あまり議論されていない領域となっている。しかしGalen Gruman, Alan Morrisonの両氏は廃棄性について，マイクロサービスと不変アーキテクチャを論理的に進化させたものであることは間違いない，と次のように述べている。
MSAを，ローカルと外部にある別々のサービスの，ほぼプラグアンドプレイなアプリ内統合だと考えてみてください。これらのサービスには変更が予想されます。その結果として，いくつかは廃棄されることになるでしょう。サービスのフォーカスが小さければ，開発や理解，管理，統合は簡単になります。必要なことだけを実行し，必要がなくなれば削除したり無視したりできるのです。
Governor氏の結論はこうだ。
ですから，マイクロサービスは廃棄可能でなくてはなりません。障害が発生したり，もっとよいサービスが存在するならば，古いものは単に捨てればよいのです。
“なくてはなりません”というのは，表現が強すぎはしないだろうか？それともこれは，他のマイクロサービス開発者たちがすでに使用しているか，あるいは目指しているパターンのひとつなのだろうか？