マイクロサービスとは何か、原点を求め、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.



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.


マイクロサービススタイルを説明するには、モノリシックスタイルと比較するのが有効です。モノリシックアプリケーションは単一のユニットとしてビルドされます。一般的にエンタープライズアプリケーションは3つのパーツから構成されます。クライアントサイドユーザーインターフェース(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.



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.



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.


マイクロサービススタイルは新しくも革新的でもありません、そのルーツは Unix の哲学に遡ります。 しかし、マイクロサービスアーキテクチャを検討している人は少ないですが、多くのソフトウェア開発ではマイクロサービススタイルを使ったほうがよいと考えています。


Characteristics of a Microservice Architecture
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.