（書きかけ）
マイクロサービスとは何か、原点を求め、2014年3月に Martin Fowler と James Lewis が書いたブログエントリ Microservices にあたってみた。
マイクロサービスとは
a definition of this new architectural term
The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
Microservices
「マイクロサービスアーキテクチャ」という用語はそれぞれ単独でデプロイ可能なサービスの集合体からなるアプリケーションの設計手法として生まれた。アーキテクチャスタイルの正確な定義はありませんが、共通の特徴があります。ビジネス能力についての組織、自動デプロイ、インテリジェントなエンドポイント、言語やデータの非中央集権化などです。
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
一言でいうと、マイクロサービスアーキテクチャは小さなサービスの集合体として一つのアプリケーションを開発するアプローチです。個々のサービスは独立したプロセスとして実行され、HTTP API のような軽量のメカニズムでやりとりを行います。それらのサービスはビジネスドメイン単位で開発され、個別に自動デプロイが可能です。これらのサービスの中央集権的な管理は最小限にとどめられ、異なるプログラミング言語が使われたり、異なるデータストレージ技術が使われたりします。
モノリシックアプリケーションとの比較
To start explaining the microservice style it's useful to compare it to the monolithic style: a monolithic application built as a single unit. Enterprise Applications are often built in three main parts: a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine) a database (consisting of many tables inserted into a common, and usually relational, database management system), and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable[2]. Any changes to the system involve building and deploying a new version of the server-side application.
Microservices
マイクロサービススタイルを説明するには、モノリシックスタイルと比較するのが有効です。モノリシックアプリケーションは単一のユニットとしてビルドされます。一般的にエンタープライズアプリケーションは３つのパーツから構成されます。クライアントサイドユーザーインターフェース（HTMLやJavascript）、サーバサイドアプリケーション。サーバサイドアプリケーションは HTTP リクエストをハンドリングして、ドメインロジックを実行し、データベースからデータを取得して更新し、HTML のビューに参照したデータを埋めてブラウザに返します。このサーバサイドアプリケーションはモノリシックな単一の実行可能プログラムです。システムに対するあらゆる変更は新しいバージョンのサーバサイドアプリケーションのビルドとデプロイを伴います。
Such a monolithic server is a natural way to approach building such a system. All your logic for handling a request runs in a single process, allowing you to use the basic features of your language to divide up the application into classes, functions, and namespaces. With some care, you can run and test the application on a developer's laptop, and use a deployment pipeline to ensure that changes are properly tested and deployed into production. You can horizontally scale the monolith by running many instances behind a load-balancer.
Microservices
システムを構築するにあたってこのようなモノリシックスタイルは自然な方法です。リクエストをハンドリングする全てのロジックはシングルプロセスで実行され、使用言語の基本機能を使ってアプリケーションをクラス、関数、ネームスベースで分けることができます。開発者のラップトップでアプリケーションを実行してテストし、デプロイメントのパイプラインを使って適切にテストされ本番環境にデプロイされます。ロードバランサーのは以下で多くのインスタンスを実行してモノリシックアプリケーションを水平にスケールさせることができます。
Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.
Microservices
モノリシックアプリケーションでうまくいくこともありますが、フラストレーションを感じる人が増えています。特に、さらに多くのアプリケーションがクラウドにデプロイされるようになると。変更サイクルが密接に結びついていて、アプリケーションのごく一部を変更するときもモノリシックアプリケーション全体をビルドしてデプロイし直す必要があります。時間の経過とともに適切なモジュール構成を保つことが難しくなり、変更の影響範囲をモジュール内に留めることが難しくなります。スケールアウトする際もパーツ単位ではなく全てのアプリケーションでとなるので多くのリソースを消費します。
These frustrations have led to the microservice architectural style: building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams .
We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix. But we do think that not enough people consider a microservice architecture and that many software developments would be better off if they used it.
Microservices
これらの不満がサービスの集合体としてアプリケーションを構築するマイクロサービススタイルへとつながりました。各サービスが単独でデプロイ可能でサービ単位でスケールアウトが可能であると同時に、厳格なモジュール境界を提供すつため、それぞれのサービスを異なるプログラミング言語でサービスを開発することが可能です。それらのサービスは異なるチームで管理することもできます。
マイクロサービススタイルは新しくも革新的でもありません、そのルーツは Unix の哲学に遡ります。 しかし、マイクロサービスアーキテクチャを検討している人は少ないですが、多くのソフトウェア開発ではマイクロサービススタイルを使ったほうがよいと考えています。
マイクロサービスの特徴
Characteristics of a Microservice Architecture
Microservices
We cannot say there is a formal definition of the microservices architectural style, but we can attempt to describe what we see as common characteristics for architectures that fit the label. As with any definition that outlines common characteristics, not all microservice architectures have all the characteristics, but we do expect that most microservice architectures exhibit most characteristics. While we authors have been active members of this rather loose community, our intention is to attempt a description of what we see in our own work and in similar efforts by teams we know of. In particular we are not laying down some definition to conform to.
マイクロサービスアーキテクチャの正式な定義はありませんが、共通する特徴をあげてみます。すべてのマイクロサービスアーキテクチャがすべての特徴を備えているわけではありませんが、ほとんどのマイクロサービスアーキテクチャがほとんどの特徴を備えていると思います。
我々著者はこのややゆるいコミュニティのアクティブなメンバーですが、私たちの意図は、我々自身や我々が知っているチームによる似たような試みについて説明することです。特に、準拠する定義は定めていません。
- サービスによるコンポーネント化
Componentization via Services
For as long as we've been involved in the software industry, there's been a desire to build systems by plugging together components, much in the way we see things are made in the physical world. During the last couple of decades we've seen considerable progress with large compendiums of common libraries that are part of most language platforms.
ソフトウェア業界に携わっている限り、物理的な世界で物が作られるのと同様に、コンポーネントをつなぎ合わせてシステムを構築したいという願望があります。過去数十年の間に、ほとんどの言語プラットフォームの一部である共通ライブラリの大幅な進歩がありました。
