latest coding buzzword "microservices". Microservices, microservices, microservices. In this video

最新コーディングの流行語「マイクロサービスマイクロサービス、マイクロサービス、マイクロサービス。この動画では

we'll go over what is a microservice, why people are moving to microservices, and finally

マイクロサービスとは何か、なぜ人々がマイクロサービスに移行するのか、そして最後に

what you need to do to make an effective microservice.

効果的なマイクロサービスを作るために必要なこと

So what is a microservice? Ask 20 developers what is a microservice, and you're likely

では、マイクロサービスとは何か？20人の開発者にマイクロサービスとは何かと聞くと、おそらく次のような答えが返ってくるでしょう。

to get 25 different answers. Here's my best answer. A microservice is basically a self

を使って25通りの答えを出してみましょう。ここに私のベストアンサーがありますマイクロサービスは基本的に自己

contained process that provides a unique business capability. Different microservices act in

に含まれるプロセスで、独自のビジネス機能を提供します。異なるマイクロサービスは

concert as one larger system, but behind the scenes, it's microservices all the way.

コンサートは1つの大きなシステムとして行われていますが、裏ではマイクロサービスになっています。

Take Amazon.com for instance. All we see is the website. Behind the scenes, Amazon has

Amazon.comを例に挙げてみましょう。私たちが目にするのはウェブサイトだけです。その裏では、アマゾンは

a service for accepting orders, a service for determining a list of recommended items

注文を受け付けるサービス、おすすめ商品リストを決めるサービス

to buy, a service to handle wish lists, a service for authenticating credit cards, and

を購入するサービス、欲しいものリストを扱うサービス、クレジットカードの認証サービス

so on. All of these services are really mini applications performing a single business

といった感じです。これらのサービスはすべて、1つのビジネスを実行するミニアプリケーションです。

capability.

能力があることを示しています。

What makes this organization interesting is, it is not organized around software layers.

この組織が面白いのは、ソフトウェア層を中心に整理されていないことです。

We don't need to create a web microservice, business logic microservice or database microservice.

Webマイクロサービス、ビジネスロジックマイクロサービス、データベースマイクロサービスを作る必要はありません。

We are creating microservices around business capabilities. So we have a wish list microservice,

ビジネス能力を中心にマイクロサービスを作っています。そこで、ウィッシュリストマイクロサービスを用意しています。

a order microservice, and a processing microservice.

注文マイクロサービス、および処理マイクロサービス。

Microservices communicate with each other through a well-defined interface, usually

マイクロサービスは、明確に定義されたインターフェイスを介して相互に通信します。

REST or a messaging queue. The communication is almost always stateless.

REST またはメッセージングキュー。通信はほぼ常にステートレスです。

The microservice data is federated as well. That means every microservice is responsible

マイクロサービスのデータも同様にフェデレートされています。つまり、すべてのマイクロサービスが

for its own data model and data. I think that statement just caused heart palpitations for

独自のデータモデルとデータのためにのために動悸がしただけだと思います。

some DBAs. There might be good business reasons to standardize the data platform for all microservices,

いくつかのDBAを利用しています。すべてのマイクロサービスに対してデータプラットフォームを標準化することには、ビジネス上の理由があるかもしれません。

but the idea is if we're on the team building the microservice, we should know best which

しかし、もし私たちがマイクロサービスを構築するチームにいるのであれば、どの

persistence model we need.

私たちが必要とする永続化モデル。

It's the latest buzzword, so why not? Seriously though, microservices make our system loosely

最近の流行語だからいいんじゃない？真面目な話、マイクロサービスは私たちのシステムを疎かにしています。

coupled. If we need to upgrade, repair, or replace a microservice, we don't need to rebuild

結合されています。マイクロサービスをアップグレード、修理、交換する必要がある場合は、再構築する必要はありません。

our entire application. Just swap out the part that needs it. Rebuilding isn't a big

私たちのアプリケーション全体を必要な部分を交換するだけです再構築は大したことではありません。

deal for a small desktop app, but it can be a killer for a whole enterprise system.

小さなデスクトップアプリのための取引ですが、エンタープライズシステム全体のキラーになる可能性があります。

Breaking our system into small parts also allows each microservice to focus on a single

システムを小さなパーツに分割することで、各マイクロサービスが単一のサービスに集中できるようになります。

business capability. One benefit of this is we can have a small team focused on a simple

ビジネス能力。そのメリットの一つは、小さなチームでシンプルな

task. Jeff Bezos from Amazon created the two pizza rule, the ideal size for a microservices

というタスクを作成しました。アマゾンのジェフ・ベゾス氏がマイクロサービスの理想的なサイズ「ピザ2枚ルール」を作成

team is one you can feed with two pizzas.

チームは2つのピザで食べさせられる1つです。

Single benefit capabilities also help drive the focus of what our group is trying to accomplish.

単一の利益能力は、私たちのグループが達成しようとしていることに焦点を当てるのにも役立ちます。

It becomes very easy to determine if a feature is in or out if our goal is focused.

目的が絞られていれば、機能が入っているか出ているかの判断は非常に簡単になります。

A simple interface means we can use different languages and tools. If we've got a great

シンプルなインターフェースは、異なる言語やツールを使用できることを意味します。もし私たちが素晴らしい

well-defined interface, it doesn't matter what language or architecture we use. We could

よく定義されたインターフェイスであれば、使用する言語やアーキテクチャは関係ありません。私たちは

write our service in Visual Basic if we wanted. As long as we publish how other services are

サービスをVisual Basicで書くことができます。他のサービスがどのようになっているかを公開している限り

to communicate with our service, we're good to go. That's why the most common methods

を使ってサービスとコミュニケーションを取れば問題ありません。そのため、最も一般的な方法は

for communication between mircoservices are HTTP and messaging. Everybody supports that.

ミルコサービス間の通信は HTTP とメッセージングです。誰もがそれをサポートしています。

So what makes a great microservice? We've touched upon a few things already.

では、何が優れたマイクロサービスを作るのでしょうか？すでにいくつかのことに触れています。

First, I'll say it again. It focuses on a single business capability. That isn't to

まず、もう一度言います。それは単一のビジネス能力に焦点を当てています。ということではありません。

say it does only one thing. Just one business thing. It does not mean we divide into a web

たった一つのことをするだけだと言う。ただ一つのビジネスをするだけですに分けるわけではありません。

capability, logic capability, and database capability. That's going back to what we had

ケイパビリティ、ロジックケイパビリティ、データベースケイパビリティ。これは、私たちが持っていた

before.

の前に。

Each microservice should have it's own datastore. This limits what can change under the microservice.

各マイクロサービスは、それ自身のデータストアを持つべきです。これにより、マイクロサービスの下で変更できることが制限されます。

If another group is responsible for the data model, they can also change the data model.

別のグループがデータモデルを担当している場合は、そのグループもデータモデルを変更することができます。

That can force downstream changes for many microservice teams. Changes that might not

これは、多くのマイクロサービスチームに下流の変更を強制することができます。以下のような変更は

help our team at all.

私たちのチームを少しでも助けてください。

Make communication stateless. If our communication is stateless, we can add more copies of the

通信をステートレスにする通信がステートレスであれば

microservice at will. Stateless communication gives our microservice the ability to scale

マイクロサービスを自由に利用できるようにします。ステートレスな通信により、マイクロサービスをスケーリングすることができます。

effortlessly. Each interaction with our microservice can be handled by a different instance.

を簡単に利用できます。マイクロサービスとの各インタラクションは、異なるインスタンスで処理することができます。

Since the communication is stateless, great microservices should be able to continue if

通信はステートレスなので、偉大なマイクロサービスは、もし

another microservice fails. That means if we can't communicate with another service,

別のマイクロサービスが失敗するつまり、別のサービスと通信できない場合です。

our service should be able to make due. If we're trying to get a list of suggested titles

私たちのサービスはそれに見合ったものでなければなりません。提案されたタイトルのリストを取得しようとしているのであれば

from another service, we'll have a default ready just incase. Our service should never

を他のサービスから利用している場合、万が一に備えてデフォルトを用意しておくことになります。私たちのサービスは

break, just because another service broke.

別のサービスが壊れたからといって

Finally, a good team makes a good microservice. We need all parts represented. That's a designer,

最後に、良いチームが良いマイクロサービスを作ります。すべてのパーツを表現する必要がありますそれがデザイナーです。

web developer, coder, database admin, and operations all on our microservice team. Not

Web開発者、コーダー、データベース管理者、オペレーションの全てがマイクロサービスチームに所属しています。ではありません。

representatives. On the team. It's everyone we need to make a fully functional application.

代表者です。チームで完全に機能するアプリケーションを作るために必要な全員です。

Up to two pizzas of course. And that doesn't mean find lots of developers who hate pizza.

もちろんピザは2枚まで。ピザ嫌いの開発者がたくさんいるということではありません。

Hey! Thanks for watching the video. If you like what you're seeing or have any questions,

ビデオを見てくれてありがとうもし、あなたが見ているものが好きなら、または質問があれば。

let me know in the comments or on DeegeU.com! New videos come out each week, so make sure

コメントかDeegeU.comで教えてください!新しいビデオは毎週出てくるので、確認してください。

you subscribe. You don't want to miss a video! In fact, lets go watch another DeegeU video.

あなたは購読します。動画を見逃さないようにしましょう実際には、別のDeegeUビデオを見に行くことができます。

See you there!

そこで会おう！