　パブリッククラウドを利用したITサービス提供が一般的ではない時代。アプリケーション開発と言えば、個人のPCでプログラム開発を行い、そのソースコードをバージョンコントロールシステム(VCS)で管理し、それをビルド(コンパイル)したものをサーバに配置するのが主流でした。
　また、すべてのアプリケーションはサーバ上で動作することが前提だったため、サーバ上に配置したもの全体がひとまとめに管理されており、ビジネス要件に合わせて開発対象となるさまざまな機能をひとまとめに作り込むことができました。
　そして、開発手法の発展の過程で、仕様を抽象的な表現で定義できるオブジェクト指向開発やその後派生した考え方が取り入れられ、従来の開発における開発負担の軽減や品質の向上が進みました。

　上記で述べた従来の開発と比較して、パブリッククラウドを利用したアプリケーション開発は考え方が異なります。
　パブリッククラウド環境下においては、自前で開発していた機能やOSS、ミドルウェア、サーバ相当の部分をマネージドサービスに置き換えることが可能となったため、自前で開発するアプリケーションの範囲をなるべく小さくする傾向が強くなっています。そのため、従来の開発で意識されていた抽象化の検討を重要視せずに開発を進められるようになりました。
　さらにマネージドサービスの種類が充実し、改良が進むにつれ、マネージドサービスが連携されたアーキクチャ設計の選択肢が広がり、より個々のビジネス要件に応えられるシステム開発が可能となりました。

　これからの開発者は従来の開発のやり方の延長から離れ、頻繁な利用が想定されるマネージドサービスの機能(仕様)や従量課金方式を十分理解した上で、各種マネージドサービスの組合せの検討やパラメータ定義も含めた動作検証をしながら、マネージドサービスのメリットを最大限に活かしつつ、デメリットを補うためにどの部分を自前で開発するべきなのか、全体のアーキテクチャを検討出来るクラウドネイティブアプリケーション開発という開発スキルを身に付ける必要があります。
　これはマネージドサービスの利用範囲が広がるにつれて、従来の開発部分の稼働は減るものの、更新サイクルが早いマネージドサービスを定常的に学習する負担が新たに増えることを意味します。
　また、様々な種類のマネージドサービスを活用することにより、従来の開発に比べ小さい機能が増えるため、機能間のインターフェースの定義数が増え、それらの仕様を決める作業が増大します。
　クラウドネイティブアプリケーション開発者が扱う技術領域は広くなり、作業負荷が増大する部分はありますが、開発者同士での仕様検討においては、開発作業の過程で重要な機能の実際の動作を明らかにして進められます。そのため、ウォーターフォールモデルのような従来の開発とは違い、出戻りを逃れることを意識し、本来のあるべき姿を見失うような議論が行われないという大きなメリットがあります。そのため、机上ベースではなく、実物ベースで議論できる点が大きなメリットと言えます。

　始めてクラウドネイティブアプリケーション開発を行う際の注意点として、同じ用語でも従来の開発とクラウドネイティブアプリケーション開発で微妙に意味が異なる場合があるので、どちらの意味を意図して会話をしているのかお互いに十分に確認を取る必要があります。

マイクロサービスアーキテクチャのメリットと注意点

　クラウドネイティブアプリケーション開発をする上で、マイクロサービスアーキテクチャの考え方は切り離せないトピックのため、以下に要点をまとめした。

　マイクロサービスアーキテクチャではパブリッククラウド環境のマネージドサービスとそれをつなぐ関数を1つのマイクロサービスとして疎結合に組合せて構成されています。そのため、従来の開発のようにモノリシックなシステム上の各機能をオブジェクト指向的に整理する作業とは異なり、関数指向的な考え方に基づき、従来よりも細かい単位で業務の分解を行い、組み立て直す作業が発生します。

　また、従来の開発は自前で開発する範囲が広いため、ビジネス要件に沿って全体像を意識しながら各種機能を定義することになりますが、マイクロサービスアーキテクチャを扱う開発ではパブリッククラウドが提供するマネージドサービスの特性を十分活かした機能単位でマイクロサービスを定義することになります。
　始めてマイクロサービスを扱う開発者は、パブリッククラウドベンダーが次々と展開する様々なマネージドサービスを日々学習する必要があり、従来の開発手法の延長線上と捉えて設計を進めないよう注意する必要があるでしょう。

　従来はビジネスロジック以外の機能部分も開発者が品質を保証する必要がありましたが、パブリッククラウド環境を利用することにより、この責任をマネージドサービスに渡すことができ、その機能に関わる開発や検証作業の負荷が大幅に削減されます。つまり、これはマネージドサービスを活用する範囲が広がるほど、開発者の検証作業の負担が軽減されることを意味します。
　一方、もし手慣れていることを理由に、利用するパブリッククラウドサービスの選択を仮想サーバのみに限定してしまった場合には、パブリッククラウドサービスが保証する範囲がIaaS部分までに狭まるため、開発者が責任を負う範囲は従来とあまり変わらない状況となりえます。また、仮想サーバ利用を前提とすることにより、マイクロサービスを意識した設計から離れて、従来の開発手法を用いる傾向が強くなるため、結果的にパブリッククラウドだからこそ得られるはずのメリットが得られない結果となってしまいます。
　それゆえ、スピーディーな開発を目指す上で、マイクロサービスアーキテクチャを採用する判断は必然となりつつあります。

　以下より、マイクロサービスの内部における開発者の責任範囲について特に重要な点を2つ挙げます。

　1つ目はマイクロサービスの構成要素である関数の部分で、マネージドサービスをより効果的に機能させるために開発者はビジネスロジックも含んだ関数部分の設計・実装に責任を持つことになります。
　マネージドサービスの仕様に関するドキュメントの更新がされていないため、関数を実装した後に想定したマイクロサービスの動きをしないことが発覚することがあります。この場合、マネージドサービスが仕様通りに動作しない問題が発生している状態となるが、開発側の都合でマネージドサービス側の仕様を変更することはできないため、関数側の修正をすることになります。
　上記の問題を回避するために、開発者は早い段階で実際のマネージドサービスを利用した動作検証を行っておく必要があります。特にマネージドサービス側のインターフェースの定義と実際の動作の違いについて十分注意を払う必要があります。

　2つ目に、マイクロサービスの「選択」と「設定値の決定」が開発側の責任範囲として存在します。
　最近はマネージドサービスの種類が年を追うごとに増え、アップデートもされるため、設計時に選択したマネージドサービスが実装時には最も要件に適したアーキテクチャではなくなるケースもあります。
　環境の変化が激しい現状では、実装前に机上での完璧な設計を心がけるよりも、開発対象部分と関係しそうなマネージドサービス全般の動向を把握しておき、アーキテクチャの選択肢がいくつかある場合には、それぞれの動作検証を行いながら、機能単位の検討も含めて設計内容を決めていく必要があります。

　上記はマイクロサービス内部の説明でありましたが、システム全体から見た構成要素となるマイクロサービス単位でも連携するマイクロサービス間のインターフェースの仕様をお互い順守することで同じように責任範囲を分けることができます。

　このようにマイクロサービス単位で責任分界点が明確になったことで、マイクロサービス単位に各開発チームが異なる開発言語や関数を使うことができ、これまでシステム全体が守らなければいけなかった共通ルールを気にせずに開発を進めることがきるようになりました。

　責任範囲を分けることにより、事前に机上で完璧な機能設計を行うことをせずに、重要な機能から順に開発を行い、途中で必要ないと気づいた機能を除外することや、追加したい機能を増やすことが可能となります。

Infrastructure as Codeとは

　Infrastructure as Codeとは、インフラの構成を定義ファイルとしてコード化し、インフラ環境の管理(プロビジョニング／オーケストレーション含む)を自動化するプロセスを指します。
最近はパブリッククラウド環境の様々なマネージドサービスに対応したInfrastructure as Codeを実現するツール（IaCツール）が提供されています。代表的なIaCツールとして、Terraformなどがあります。これらのツールはCI/CDツールとの連携も考慮されており、アプリケーション開発のワークフローとの統合も容易です。

　従来、OSやミドルウェアなどシステムの基盤となるインフラ環境はインフラ担当者が設計書、環境設定書、手順書を作成し、それらのドキュメント通りに手動で構築作業を行っていましたが、Infrastructure as Codeを適用することで、各種ドキュメントはコード化され、IaCツールを利用することでインフラ構築の自動化が可能となりました。
　Infrastructure as Codeを適用することでコスト削減、作業時間の短縮、手作業によるミス防止、変更管理の厳格化による品質向上など様々なメリットが得られるため、IaCツールやVCSツールを組合せてCI/CD環境を用意するケースが増えています。

　IaCツールがサポートするマネージドサービスが増えることで、インフラ技術領域の知識がなくてもインフラ環境の構築が可能となるため、開発者でもIaCツールを利用したインフラ構築が行えるようになります。これはアーキテクチャの検討やパフォーマンステストの際に、インフラ担当者を介さずにインフラ環境を用意でき、よりスピーディーな開発が可能となることを意味します。
　今後、開発者は開発作業だけではなく、マネージドサービスに関しても十分な知識を有することが大前提とはなりますが、これまでのインフラ技術領域の難易度と比較すると習得する負担は少ないため、総合的に見るとメリットの方が大きいといえるでしょう。