「Microservices Meetup vol.6」に行ってきた

2017/1/19のデイリーストックランキングにランクインしました。

【毎日自動更新】Qiitaのデイリーストックランキング!ウィークリーもあるよ_-_Qiita.png


いままでの。
「Microservices Meetup vol.2」行ってきたメモ。
「Microservices Meetup vol.4」に行ってきた

図らずして1回おきに参加してますね。

Connpassのイベントページ

少し間が空いてしまったがまた定期的に開催していきたいです。
登壇したいよーって人は直接リプ投げてください
by @qsona さん

Microservices on AWS by @Keisuke69 さん

Keisuke Nishitani @ AWS

Specialist Solutions Architect

サーバーレスアプリケーション開発ガイド 2月発売

マイクロサービスのポイント

  • 管理運用まで含めて分散型
  • 各コンポーネントが独立している
    • 単独で実行できないのは適切に設計されていない

独立して分散していると負荷の高い機能の単位でスケールさせられる=コスト効率が良い

  • 一つのことをうまくやる

    • 複雑化したら分割する
  • 多言語

    • チーム(機能)にはそれぞれの問題に対して適切なツールを選択する自由がある
    • OS、言語、各種ツールに至るまで最適なアプローチを目指せる
  • 検索:Elasticsearch / Solr

  • ソーシャル:グラフDB

  • ログデータ:Cassandra

  • セッション:Redis

†AWSでは:AWSには100ちょいのサービスがあって、その中で更にチームが分かれている。
各チームに社内標準の開発プロセスは存在しない。

  • ブラックボックス

    • 詳細は外部のコンポーネントに公開されない
  • DevOps
    • マイクロサービスにおける組織原理

†AWSでは:運用のみのチームはない。オンコールも開発チームが請け負う

  • 俊敏性

    • 狭い範囲のコンテキストで活動=サイクルタイムが短い
    • システムもシンプル
    • パラレルな開発とデプロイが可能
  • イノベーション

    • 選択に対する権限と責任を持つのでイノベーションを起こしやすい
    • DevとOpsの対立がないため、効率化やイノベーションが起こしやすい
  • 拡張性

    • 適切に非干渉化されてていることで水平方向に単独にスケールできる
  • 可用性

    • ヘルスチェック、キャッシング、隔壁、サーキットブレーカーと言った仕組みは全体の可用性を向上させる

課題

  • 分散型であることは難しい

    • システム数が増える
    • 協調動作の難しさ
    • コンポーネント間のコミュニケーションメッセージ増によるレイテンシ低下
    • ネットワークの信頼性は無限ではない、帯域も無限ではない
  • 移行が大変
    • モノリシックなシステムの分割は難しい
  • 組織
    • 組織体制の変更が必要になるが、それは大変なこと
  • アーキテクチャの難易度
    • 非同期通信
    • データ整合性
    • やっぱりココが一番の課題
    • サービスディスカバリ
    • 認証
  • 運用の複雑さ

アーキテクチャ

一番シンプルなパターン

CloudFront – ALB – ECS – datastore(ElastiCache, Dynamo, )
|
S3

  • バックエンドをRESTfulなAPIにしたSPA
  • 静的なコンテンツはS3とCloudFront
    • CDN通すことでレイテンシが上がることもある
    • キャッシュとの併用を検討
  • ECSとAutoScalingをALBとともに使うことが多い
    • ALB(L7LB)でアプリレベルの情報をルーティング
    • コンテナインスタンスにリクエストを分散
    • ECSのコンテナを負荷に応じてスケールアウト/インする

コンテナのメリット

  • Portable
  • Flexible
  • Fast
    • 軽量で早い
    • ポータビリティと関連して開発サイクルも早く
  • Efficient

  • 一貫性のある環境

  • バージョン管理出来る

Dockerの特徴

  • Package
  • Ship
  • Run

ECS

  • 複数のコンテナをEC2のクラスタ上で一元管理

    • まだTokyoにきてないけど、FargateでEC2の管理もいらなくなるよ
    • EKS(Kubernetes)も発表されています

データストア

  • インメモリ

    • Memcached, Redis
    • ElastiCache
    • DB負荷の軽減
  • RDBMS
    • 無限のスケーリングには向いていない
    • Amazon RDS
  • NoSQL
    • 水平スケーリングをサポートするものが多い
    • テーブル結合ができないのでロジックの実装が必要になる場合も
    • Amazon DynamoDb, KynamoDB Accelarator(DAX)

APIの実装

  • APIの設計、改善、デプロイ、モニタリング、保守派手間がかかる
  • 異なるバージョンが混在すると大変

Amazon API Gateway

  • 複数バージョンとステージ
  • Cognite User Poolsと連携して認証を追加
  • スロットリング、モニタリング
  • バックエンドとしてLamdbaが使える

サーバーレス

  • サーバーはないに越したことはない
  • スケーリングと高可用性の担保が大変
CloudFront - API Gateway - Lamdba - datastore
   |                            (ElastiCache, Dynamo)
   |
  S3

課題をAWSでどうするか

サービスディスカバリ

  • お互いの死活確認や発見
  • ハードコードするとスケールできない

    • メタデータをどこに置くか
  • ALBを利用したサービスディスカバリ

  • DNS(Route53)のサービスディスカバリ

    • VPC単位の振り分け
  • ECSイベントストリームを使用したサービスディスカバリ

    • CloudWatchイベントで拾ってキック
    • LamdbaでRoute53に登録
    • これが一番多いかも
  • DynamoDBを使用したサービスディスカバリ

    • DNSキャッシュの問題がない
    • 自由度が高い
    • 実装が大変
    • DynamoDBストリームを活用して他のサービスへステータス変更を反映
  • イベントベースのアーキテクチャ

    • イベントで処理する
    • いわゆる結果整合性とも関連
    • Dual Write Problem
    • Event Sourcing
      • 状態の記録ではなく状態の変更「イベント」を記録
      • Amazon Kinesis
      • kinesisにpublishして他サービスはsubscribe
      • S3にログを残す
      • トランザクションログの仕組み

モニタリング

  • CloudWatch

    • ログファイルの一元化
    • CloudWatch LogsかS3に保存可能
    • ECSはCloudWatch Logsに一元化できる

分散トレース

  • AWS X-Ray
  • 複数サービスに分散したリクエスト処理を透過的に追える

LogWatchの先に Kinesis FireHorse – ほにゃほにゃ

スロットリング

  • 大事だよ

リトライ

  • 多くのエラーはリトライでカバーできるものが多い
  • リトライ多発で過負荷になることがある
    • Exponential back offもしくはフィボナッチ数列を利用したリトライ感覚の調整
    • 更に乱数でゆらぎを付けて重ならないように

LT:クラウド型医療系業務システムと Microservices への歩み by @hashedhyphen さん

https://speakerdeck.com/hashedhyphen/kuraudoxing-dian-zi-karutesisutemuto-microservices-hefalsebu-mi

クラウド型電子カルテシステムの話

  • メインロジックをRails
  • 常時接続をNode.js
  • バックエンドをScala
  • 基盤はAWS

ここに至る道のり

ファーストリリース前

  • レコメンドは大量のデータが必要

  • メインロジックで実現させようとすると厳しかった

    • Threadとか試したけど……
    • 別アプリケーションとして分離
    • JVM上でScala + Skinnyでスレッドアプリケーションンを実装
    • Microservicesちっくな構成へ
  • 障害検知時

    • メインロジック内のプロトタイプ版が動く!

会計機能リリース前

  • お金を扱う機能は安定性が欲しい
  • Scala + Cats による実装を別エンドポイントとして実装
  • マイクロサービスっぽい作りになっていたから自由度のある技術選択が出来た

まとめ

  • ちょっとマイクロサービス化したことで自由度が上がった
  • 原理主義的にならなくても恩恵がある
  • エンジニアの伸びしろ!

FrontEndからみるmicroserviceとBackendからみるmicroservice by @taka_ft さん

Takahiro Fujii @ Rakuten Travel

楽天内でも採用アーキテクチャはサービスによって異なる。

サービスとしては

  • コンシューマ向け
  • Extranet
  • In-house
  • other
    • ここまではWEBとモバイルがあって、100以上のAPIを利用する
  • API(内部APIを直接利用)

Phase 1

  • 大きなモノリシックなアプリだった
  • 機能がどんどん増えていく
    • 機能別で複数のモノリシックなアプリに分割
    • その後フロントエンドとバックエンドに分割

Phase 2

  • ドメインモデルを整理
  • なるべくRESTfulで作るようになっていった
  • 大きなAPIから小さなAPIに分離
  • I/Fの決定に時間がかかるようになった
  • API呼び出しが大変になった
  • Microservicesっぽくなってきた 2014年くらい

  • 国内予約、海外予約で多言語化だけではない商習慣に根ざしたドメインの差異による重複ロジックの増殖が起きた

  • Microservicesっぽくなってきたが、どんどん品質が下がっていった

Phase 3

(ちょうど前日にプレスリリース)サイト前面刷新に向けての取り組み

  • FrontendsはJavaScriptに刷新
  • API GatewayにKong

組織

  • フロントエンドチームが2人から始まって半年でReactエンジニアを集めて20人以上に

    • 日本人は2, 3人

UI Component

  • SpringからJavaScriptでSPAに変更
  • zeplinのデザインモックからUI Componentを実装するようになった
  • Storyboardを使ってUI Coponentを管理
  • ドメインを含むUI Componentはドメインと結び付きが強いことが多い=専用のオーケストレーションAPIを用意してUI Componentないで処理を閉じることが出来る
  • レスポンシビリティを明示的に定義

    • どこまでフロントエンドでやるか、どこからAPIからもらうか
  • フロントエンドの「使いやすいレスポンス」の要求

  • バックエンドの「汎用的でシンプルなレスポンス」の希望

    • これらのバランスを取る
  • API Gatewayはフロントエンド(UI)チームの管轄

    • ただし状況によってはバックエンド側に持っていくことも検討するつもり

LT: “マイクロサービスはもう十分”か? by @qsona さん

https://speakerdeck.com/qsona/enough-with-the-microservices

POSTDに投稿していた翻訳記事。

スタートアップ企業のほとんどはマイクロサービスをさいようすべきではない

銀の弾丸はない。

「チーム間の依存性」の解決にマイクロサービスというアプローチは違う。疎結合と分散は別。

組織が大きくなると、複数チームが1つのコードベースを触るようになる。そしてマイクロサービス化したくなる。

しかし、モノリスの分割で十分。

チームとは何か

  • 自律的に動けるべき

    • チームが増えるとコミュニケーションコストや、しがらみ
  • チームの分割は目的にそった分割を行う

  • 悪い分割の例: Dev / Ops

  • 依存度が低いほど自律的に動ける

  • High Output という本

  • 使命型組織/技術型組織

    • Micorservicesは使命型組織
    • 組織間が密ならサービス間も密になる

話戻して

  • スタートアップは組織をキレイに分割することが難しい
  • 分割しても密になってしまう

  • 大きなモノリスになるとやはり分割は難しい

    • ドメインの意識は必要
  • マイクロサービス設計しなくても「マイクロサービス精神」で開発すると効果的なのではないか

FiNCが初期からマイクロサービスでやってた理由

  • 単独の事業にできるような一つ一つのサービスを組み合わせて提供してきたから

あとで読み返して修正します。
資料パスの追加とかも。

続きを読む

【AWS】サーバーレスで問い合わせフォーム (s3,Lambda,SES)

はじめに

AWSome Day(awsのセミナー)に参加しまして、
学習意欲が湧いたので、早速、サーバーレスで
お問い合わせフォーム有りのウェブサイト製作をしてみました。

Amazon Web Service初めて使ってみました。
備忘録としてまとめます。

やりたいこと洗い出し

  • 静的なWebサイトホスティング
  • お問い合わせ機能
  • 問い合わせの通知 ⇨ 私 & 担当者
  • SSL化

使ったサービス

  • Route53
  • Cloudfront
  • ACM (AWS Certificate Manager)
  • s3 (Simple Strage Service)
  • Cognito
  • Lambda
  • SES (Simple Email Service)

それぞれのサービスの説明は、
こちらの記事が簡潔で分かりやすいです!
「AWS is 何」を3行でまとめてみるよ

構成図

aws_Diagram_.png

進め方

正直、初めてAWSを触るということもあり、
どこから手をつければ良いのか分かりませんでした..
なんとなく機能を分割して手をつけていきました。

  • 0. 静的サイト制作
  • 1. s3からs3にput、Cognito認証
  • 2. Lambda、SES
  • 3. Route 53
  • 4. CloudFront,ACMの設定

こちらの記事、大変参考にさせて頂きました。
初心者にも分かりやすく、助かりました。

詳細

メモレベルですが、やったことを残しておきます。

① s3 / Cognito

aws_Diagram (3) (2).png

上記サイトのjsを参照し、s3からs3にputできるようにしました。

やったこと
  • s3 バケット作成、html,css,img,js配置
  • Cognito IAM独自のポリシーを作成を作成し、アタッチ。Acctionでputを追加し、s3バケット名を指定するだけで大丈夫です。
  • ACLのデフォルトは”public-read”なので、明示的に”authenticated-read”とかに設定する必要があります。
  • CROS設定で、alloworiginを設定する必要があったのですが、Route53の設定をまだしてなかったので、後回しにしました。

② SES / Lambda

aws_Diagram (_3).png

まず、SESのメール認証を行います。

  • SES ⇨ Email Addresses ⇨ Verify a New Email Address
    自分のメールアドレスを入力し、申請するとメールが届くのでリンクを押せば完了です。

  • ①でs3からs3にput出来るようになったので、そのイベントをトリガーにLambdaの設定を行います。
    こちらのサイトのjsをほぼそのまま使わせて頂きました。

  • IAMロールは、AmazonSESFullAccessを付与します。

③ Route53

お名前.comで既にドメイン購入済みでした。
AWSで発行したNSレコードを、お名前.comの方に追加する必要がありました。手順をこちらにまとめたので参考にして頂ければ幸いです。
【Route 53】【お名前.com】【Amazon S3】Webサイト作成

④ CloudFront / ACM

大変参考にさせて頂きました。

ACM

  • 2017年10月より、DNS認証が追加され、設定が簡単になりました。またワイルドカード証明書も無料で発行できるので、CloudFront使う際は使っておきたいですね。
  • 適応されたらCloudFront側で、http to https設定を行います。

  • 設定完了後、s3のCROS設定に、下記を追加します。
    <alloworigin>https://www.ドメイン.com</alloworigin>

まとめ / 反省点

設定項目が多すぎて、何をどこまで設定するべきなのか難しい。使った分だけ課金されてしまうこともあり、ちゃんと把握しておきたい。

続きを読む

Amazon AWS-DevOps-Engineer-Professional 日本語版サンプル認定試験を通して自分を向上させる

TopExamのAmazonのAWS-DevOps-Engineer-Professional 日本語版サンプル試験トレーニング資料はほかのサイトでの資料よりもっと正確的で、もっと理解やすくて、もっと権威性が高いです。TopExamを選ぶなら、きっと君に後悔させません。もし君はいささかな心配することがある. 続きを読む

AWS-DevOps-Engineer-Professionalが受験可能になりました

KilltestのAWS-DevOps-Engineer-Professional試験対策はIT講師と豊富な経験を持つ技術専門家を共に真実なC9020-661試験環境を構成されて、AWS-DevOps-Engineer-Professional試験問題集を合格できるのを保障します。AWS-DevOps-Engineer-Professional試験概要試験名:AWS Certified DevOp. 続きを読む

カテゴリー 未分類 | タグ

AWS re:Invent 2017 DevOps関連セッションまとめ

まとめについて

re:Invent 2017 で行われたBreak Out Session から DevOps に関するオススメセッションを独断と偏見でピックアップしました。AWSだけに限った内容ではありませんので、DevOps開発プロセス、マネジメント、アーキテクチャ一般の勉強にもどうぞ。
なお、本投稿は個人の見解であり、所属企業とは関係がありません。

セッション動画(英語)のリンクをつけました。Slideshareもできるだけ拾いましたが資料が公開されていないものもあります。
できるだけYouTubeの動画を見ることをおすすめします。米国のカンファレンスは資料より話がメインです。多くは資料なんか見ないで話します。デモも多くあります。
英語が苦手な方はYouTubeの各種機能(英語字幕、自動翻訳による日本語字幕、文字起こし、スピード調整など)を使ってご覧になってください。英語字幕を見ながら聞くのはリスニングの勉強にもなります。

カテゴリは以下のとおり:

  • DevOps全般
  • Chaos Engineering
  • DevOpsを実現するためのアーキテクチャ
  • CI/CDパイプライン
  • CloudFormation
  • CLI
  • Management & Governance & Monitoring
  • DevOps ワークショップ

DevOps全般

Life of a Code Change to a Tier 1 Service (DEV206)

Launch Applications the Amazon Way (DEV203)

  • Amazonにおけるアプリケーション開発スタイルを紹介した後、Code Starのデモを中心にCode*サービス、プロビジョン、デプロイ系サービスの全体像を解説。
  • https://www.youtube.com/watch?v=ITNorHA9m6Q

Tools Won’t Fix Your Broken DevOps (DEV345) by DevOps Research and Assessment

Chaos Engineering

Performing Chaos at Netflix Scale (DEV334) by Netflix

DevOpsを実現するためのアーキテクチャ

Cisco’s Journey from Monolith to Microservices (DEV329)

  • 前半はAWSのSAがマイクロサービスにおける永続的データの管理方法について解説。これはいい内容。後半はCiscoが社内の既存データをマイクロサービスとして提供するためのアーキテクチャについて解説。
  • https://www.youtube.com/watch?v=Qv7iRDbxS6A

Embracing Change without Breaking the World (DEV319)

CI/CDパイプライン

Continuous Integration Best Practices for Software Development Teams (DEV322)

  • 効果的なCI実施のための3つ施策について解説。Nighty Check, Branch Check, PullRequest Check。ツールとしてCodeBuildの活用をベースに。登壇者はWarnerのKeynoteに出てきたClare。彼女はCodeBuildの開発チームの一員。
  • https://www.youtube.com/watch?v=GEPJ7Lo346A

Deep Dive on Advanced Continuous Delivery Techniques Using AWS DevOps Tools (DEV324)

  • 昨年もあったContinuous DeliveryのDeep Diveセッション。「CDパイプラインが本番環境を壊すことが怖いですか?」怖い人はこのセッションを。
  • https://www.youtube.com/watch?v=Lrrgd0Kemhw

Use Amazon EC2 Systems Manager to Perform Automated Resilience Testing in Your CI/CD Pipeline (DEV338) by Expedia

Manage Your Applications with AWS Elastic Beanstalk (DEV305)

CloudFormation

CFn関連セッションはこちらのブログにもまとめて紹介されています
https://aws.amazon.com/jp/blogs/mt/your-aws-cloudformation-guide-to-reinvent-2017/

Deep Dive on AWS CloudFormation (DEV317)

  • CFnのプロダクトマネージャAnilによるDeep Dive Session。中ほどにStackと実環境との違いを検知するDrift Detection (commin soon) について解説があります。
  • https://www.youtube.com/watch?v=01hy48R9Kr8

Learn How Intuit Built a Frictionless Infrastructure Management System Using AWS CloudFormation (DEV318)

Build Once, Deploy Many: Architecting and Building Automate (GPSTEC319)

CLI

Introduction to the AWS CLI (DEV323)

AWS CLI: 2017 and Beyond (DEV307)

Management & Governance & Monitoring

How Amazon.com Uses AWS Management Tools (DEV340)

Using AWS Management Tools to Enable Governance, Compliance, Operational, and Risk Auditing (DEV339)

NEW LAUNCH! Gain Operational Insights and Take Action on AWS Resources with AWS Systems Manager (DEV346)

Embrace DevOps and Learn How to Automate Operations (DEV306)

Using Amazon CloudWatch for Amazon ECS Resource Monitoring at Scale (DEV333)

DevOps ワークショップ

Advanced DevOps Practices for AWS(DEV401)

DevOps Essentials An Introductory Workshop on CICD Practices

続きを読む

CircleCI 2.0とcodedeployでデプロイを自動化する

はじめに オフィスの休憩室にあるNintendo Switchのマリオカートで遊ぶのが楽しすぎて、自宅にも欲しくなってきました。佐々木です。 最近自分のプロジェクトでCircle CIとAWS CodeDeployを連携 […] 続きを読む

Amazon AWS認定SAP/SysOps/CDA/SAA/DevOps現行実試験再現問題集 返金保証付 追加料金なし …

商品名 AWS認定SAP/SysOps/CDA/SAA/DevOps現行実試験再現問題集☆【最新英語版】返金保証付【追加料金なし】☆ 商品説明 ◇概要◇当方の問題集のお客様から、多くの喜びの声を頂いており、心より感謝いたしております。お客様からのお礼や激励のお声が励みになり、自分受験の経験を活かし、現行実試験の問題 … 続きを読む

Fargateについて世間の反応を見てみる

fargate.png

はじめに

こちらはAWS Fargate Advent Calendar 2017の12/18の記事です。
本記事では北米”google.com”で検索してFargateに関する巷のブログ、ニュース記事などを適当に選んで読み漁り、所感をコメントしていきます。
※新しい記事を読み次第、2017年中は本記事を更新していきます


Choosing your container environment on AWS with ECS, EKS, and Fargate

本AdventCalendarを立てたriywoさんにご紹介頂きました!ありがとうございますm(_ _)m。Mediumより元(?)AWSエバンジェリストのNATHAN PECKさんの記事です。ECS,EKS,Fargateそれぞれの特徴を紹介しており、最後のまとめ(summary)で3サービスの選択のポイントについて言及されています。

ざっくりなまとめ

  • ECSはツールも充実していて、CloudFormationはもちろんOSSのcoldbrew-cliもあるよ
  • EKSはk8s自体を管理するリソースのない小規模の企業にも向いている
  • ECSはAWSの他サービスと連携する最高のコンテナ運用を提供する
  • EKSは既にオンプレやAWS上でk8sを運用している場合に共通の運用体験を提供できる
  • Fargateは管理不要な簡単なコンテナ運用を提供できる(EC2を使うのが最も柔軟にコンテナを運用できるけど)

ECS, Fargate and EKS (Kubernetes on AWS) compared and explained in a nutshell

“sysdig”というコンテナモニタリングツール&サービスのブログより、Jorge Salamero Sanzさんの記事です。11/29のサービス発表直後に書かれています。自前k8s運用との比較や、コスト面、運用者・開発者目線での評価といった幅広い内容になっており、読み応えがありました。またsysdig monitorというコンテナ監視のsaasも気になります。

ざっくりなまとめ

  • コストについて、ECSやk8sの運用負荷がなくなるメリットと、Fargateのようなマネージドサービスの利用コストは各社で天秤にかける必要がある
  • 運用者目線からみて、ECSや自前のk8s on AWSに対し、EKSやFargateのカスタマイズ性には疑問がある
  • 開発者目線からみて、ECSを使っている現在のFargateはあまり変化が無いはず
  • Lambdaとの比較で、似ているがLambda特有の制限が無くなる(ただしコストはかかる)

Azure Container Instances vs. AWS Fargate

Hackernoonからvamp.ioのファウンダーTim Noletさんの記事です。
Azure Container Instances(ACI)とAWS Fargateを比較しているのですが、全体を通して「ACI上げ、Fargate下げ」な調子でFargateに対する煽りが入り、個人的には面白く読めました。

ざっくりなまとめ

  • ACIのコンテナ起動はわずか2行のコマンドでできる
  • Fargateのコンテナ起動はクラスタ作ってタスク定義してコンテナ定義してサービス…多いわ!
  • 性能測定結果はACIもFargateもそれほど違いはない
  • 価格はACIが割高(単純に1月連続利用を前提)に見えるが、AWSはLBとか他のサービスも必要になるから気をつけろ
  • ACIはシンプルでHerokuのようなサービス
  • FargateはDC/OSやk8sに位置するサービス

Say Hello to AWS Fargate & Amazon Elastic Container Service for Kubernetes (EKS)

Mediumからtiffany jerniganさんの記事です。AWSの中の方です。Fargateとk8sの基本的なサービス内容を記載されています。記事のはじめに過去のTwitterを引用して「あなたの願いは今叶いました!それがFargate、そしてEKSです!!」という流れは嫌いではないです。
「To learn more」として各種ドキュメントやre:Inventの動画へのリンクがまとめられているのは嬉しいですね。

ざっくりなまとめ

  • 詳しいことを知りたければリンク先(公式ドキュメントなど)を参照して欲しいとのこと

EKS and Fargate Announced at AWS re:Invent 2017

caylentというDevOps基盤を提供するサービス(?)のブログよりJP LA TORREさんの記事です。EKSとFargateについて機能を紹介しています。他記事にはでてこなかったContainers-as-a-Service(CaaS)という表現を使っているのが印象に残りました。

ざっくりまとめ

  • Fargateはゲームを変える可能性を持っている(欧米的な言い回し)
  • 簡単に言ってしまえばFargateはAWSにおけるHerokuである
  • FargateはCaaS市場でAmazonがより成長する鍵となりそうだ

さいごに

本記事を書き始める前に今日までのAWS Fargate Advent Calendar 2017の記事をすべて拝見しましたが、上質&興味深い情報が多く大変勉強になりました。闇雲にgoogle.comで情報を探すよりも学ぶ効率が良かったです。皆様ありがとうございます。

上で紹介した記事の中では”Azure Container Instances vs. AWS Fargate“がお気に入りです。AzureのACIとの比較という面白い切り口ですのでオススメです。

※12/19 Choosing your container environment on AWS with ECS, EKS, and Fargateを追記

続きを読む