新着情報
-
-
2019/12/12(木) 15:30 更新
ワークショップに参加予定で、
ワークショップのフォーム入力をお忘れの方がいましたら、
以下のリンクより、参加登録頂けますように宜しくお願い致します。
https://t.co/YErfMT5Lol
※カンファレンスのみご参加される方は入力の必要ございません。
ワークショップは12月13日(金)、Engineer Cafeで無料開催されます。
所在地
福岡市中央区天神1丁目15番30号 赤煉瓦文化館 Engineer Cafe
交通
地下鉄天神駅 徒歩5分 / 西鉄バス「天神4丁目」下車すぐ
-
-
2019/12/02(月) 20:55 更新
参加される方は、以下のFormより情報を入力の上、ご参加ください。
https://t.co/YErfMT5Lol
所在地
〒106-6224
福岡市中央区天神1丁目15番30号 赤煉瓦文化館 Engineer Cafe
交通
地下鉄天神駅 徒歩5分 / 西鉄バス「天神4丁目」下車すぐ
イベント概要
ServerlessDays Fukuoka is coming!!
ServerlessDays Fukuoka 2019を開催します!
ServerlessDaysは、サーバーレスアーキテクチャを用いたシステムの構築・運用における経験の共有を目的とした、コミュニティ主導でベンダーニュートラルな技術カンファレンスです。
サーバーレスアーキテクチャは、開発者の創造性を素早くWebやモバイルアプリケーションとして実現し、スケーラビリティやセキュリティ、インフラの保守といった多数の力仕事から解放されるための新たなパラダイムシフトです。
ServerlessDays Fukuokaに参加して、サーバーレスアーキテクチャでアイデアを素早く形にする方法を学びましょう。
「業界をリードする最新の事例や技術動向などのセッションを盛り込んだカンファレンス」でみなさまをお迎えします。
未来は必ずサーバーレスになります。
Serverlessconf → ServerlessDays への変更について
今年からイベントの名称をServerlessconfからServerlessDaysに変更し、
4回目の東京にくわえ、福岡での開催が決定しました!! ぜひお楽しみに!
日程
- 2019/12/13(金) ワークショップ @ エンジニアカフェ
- ワークショップは別フォームにて無料にてお申し込みいただきます。以下のFormをご利用ください。
- 2019/12/14(土) カンファレンス @ LINE Fukuoka株式会社(博多)
- 本チケット対象のカンファレンスデイです。
協賛(順不同)
- Amazon Web Services
- 株式会社Fusic
- 合同会社Serverless Operations
- 株式会社キャラウェブ
- LINE Fukuoka株式会社
- イジゲン株式会社
- 株式会社セキュアスカイ・テクノロジー
- 株式会社ヤマップ
- 株式会社セクションナイン
ワークショップについて
ワークショップは本チケットとは別に以下のFormにて申込頂きます。
無料で参加出来ますので是非ご参加ください。
https://forms.gle/6Wo2NF9AXDLPpg4C7
ワークショップは12月13日(金)、Engineer Cafeで無料開催されます。
- 日時
- 12月13日(金) 9:30開場予定
- 所在地
- 〒106-6224 福岡市中央区天神1丁目15番30号 赤煉瓦文化館 Engineer Cafe
- 交通
- 地下鉄天神駅 徒歩5分 / 西鉄バス「天神4丁目」下車すぐ
タイムテーブル
Timeline | Title | Speaker |
8:00 | Registration | |
9:00 | はじめに | |
9:10 |
3日間で使い捨て!イベント用有料ライブ配信サービスの構築
|
三浦 一樹
|
10:00 | Keynote | Keisuke Nishitani |
10:45 |
B2B企業がCloudFunctionsでC2Cサービスを立ち上げた話
|
西 武史
|
11:10
|
キャッシュレスカフェのバックエンドを支えるサーバーレスアーキテクチャ
|
岡春奈
|
11:40 |
グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例
|
Yuya Urayama
Eiichiro Uchiumi Masashi shibata |
12:20
|
Lunch & Lunch Session
|
|
13:20 |
Serverlessで最初につまずくポイントすべて解説!
|
Kensuke Shimokawa
|
13:50
|
ぼうけんにでかけよう kubernetes KEDA
|
加藤 司
|
14:40
|
IoTデバイスの疑似データ送信システムにおけるサーバーレスなログ処理機構の試行錯誤
|
毛利 啓太
|
15:10
|
TBD
|
-
|
16:00 |
TypeScriptとJestではじめる AWS製サーバーレス REST API のユニットテスト/E2Eテスト
|
和田祐介
|
16:25 |
サーバーレスでAPIを提供する際のアプリケーション"以外"の話
|
Shimpei Takamatsu
|
16:50 |
Cloud Runでサービスを作るためのアーキテクチャのTipsとコストの話
|
Keisuke Yamashita
|
17:20
|
フルサーバレスで構築した電子書籍ストアを1年運用してみた
|
Keiichi Nakayama
|
17:50
|
Lightning Talks x 4
|
Keisuke Mori
たいがー 木村 幸介 松田 丈司 |
18:40
|
Closing Remarks
|
|
19:00
|
Community Social / 懇親会 |
※タイムテーブルは変更される可能性がございます。
アンチハラスメントポリシーについて
当コミュニティではすべての参加者(スピーカー、スタッフ、参加者、その他サポートしてくれるすべての関係者)は以下の規範に同意する必要があります。われわれはかかわるすべての人に安全な環境が提供されるように参加者全員がこれに協力することを期待します。アンチハラスメントポリシー(短縮版)
性別、性の同一性や表現、年齢、性的指向、身体障害、体型、体格、人種、または宗教(または逆に信仰を持たないこと)にかかわらず、誰に対しても嫌がらせのない参加体験を提供することに努めます。参加者への嫌がらせはいかなる行為も容認しません。性的な表現や画像などは、講演、ワークショップ、パーティー、TwitterやFacebookおよびその他すべてのオンラインメディアを含む、あらゆる場において不適切とみなします。これらの規則に違反した参加者は、たとえ有料イベントであっても開催者の裁量で返金することなく、これらの場所から追放され今後の参加の一切を断る可能性があります。アンチハラスメントポリシー(完全版)
「嫌がらせ」には、性別、年齢、性的指向、身体障害、体格、人種、宗教に関する不快な発言や、性的な画像の使用、意図的な脅迫、ストーキング行為、望まない写真撮影や録音・録画、議論の中断を招く不快な発言、不適切な身体的接触、歓迎すべきでない性的関心を引く行為が含まれます。嫌がらせ行為を中止するように求められた参加者は、直ちに遵守することが求められます。
参加者が嫌がらせ行為に関与している場合、主催者は、違反者への警告や(たとえ有料イベントであっても)返金なしでの即時退場など、適切と思われる行動を取ることができます。
あなたが嫌がらせを受けている、あるいは他の誰かが嫌がらせを受けていたり、その懸念がある場合には、すぐにスタッフに連絡してください。
スタッフは、参加者が会場のセキュリティまたは警察機関に連絡して護衛を提供したり、またはその他の方法でイベントの開催中に当該参加者の安全が担保されることを支援します。つまりわれわれはあなたの参加を心から歓迎しています。
われわれは、すべての参加者が勉強会、カンファレンス、ワークショップといったイベントの会場やイベント関連のミートアップにおいてこれらの規則に従うことを期待します。
サーバーレス、最近のトピック
Co-Chair(共同主催者)のブログより引用TL;DR
- Strategy (Cloud 2.0, Serverless Doctorine, NoOps, Declarative vs Imperative, Microservices-oriented etc…)
- Serverless Containers (like AKS, Fargate, GKE)
- Architecture (Web Apps, Streams, Machine Learning, Glue-codes, API backend, VUI backend, GraphQL backend, Mobile backend)
- Observability (like Datadog, X-Ray, Azure Monitor, Application Insights)
- Zero-Scale Functional Containers (like Cloud Run, Knative on xxx)
- ID(AuthN and AuthZ across inter-resources)
- Developer Experiences (How to build, How to test, and CI/CD pipeline)
- No(Umconfortable)Ops
- JAMStack (SPA, REST API)
- Security
- and your own Story!!
真のクラウドのスケーラビリティ (Zero to Infinity)
「マシンとしてのサーバー」の多くがクラウド上に仮想化されましたが、ワークロードが少ないにも関わらず立ち上げっぱなしで課金されているものや、スパイクしても柔軟にスケール変更ができないため、ちょっと高度なレンサバ程度としてしか利用していないアプリケーションもいまだに多く存在します。われわれがクラウドに求めているのは、ゼロから無限にスケールする「アプリケーションのスケーラビリティ」と、プラットフォームによってアプリケーションの実行結果にムラのない「ロバスト性」です。サーバーレスこそ真のクラウドであると私が信じるゆえんです。
コンテナ・エコシステムとのグラデーション
ゼロからスピンアップして無限にスケールすることがサーバーレスの特徴(おもにFaaSの特徴)ですが、コンテナの仕組みでゼロからスケールできるサービスが出てきたり、FaaSにおいても下回りのコンテナをあらかじめカスタマイズできるような制限緩和が進んでグラデーション状態にあります。Cloud Runが東京リージョンで展開されましたが、コンテナのオーケストレーターとして地球征服を完了したKubernetesの上で、それよりも簡単にコンテナイメージのビルドからワークロードの実行まで管理できることで、この先注目度の上がりそうなサービスです。
Best-of-BreedなツールチェーンやDevOpsの話
サーバーレスのエコシステムはFaaSとイベントデータのルーティングという非常にコンセプチュアルなモデルを中心にアーキテクチャパターンを模索するというアプローチで発展してきました。ゆえに、Developer Experienceの観点から見ると、従来のDevOpsのツールチェーンなどがそのまま流用しにくく、アーキテクチャパターンに応じてベストプラクティスなツールチェーンを模索しなくてはいけない時期が長く続いています。ゆえにプラットフォーマーごとにサーバーレスでも便利なサービスが発展するに合わせ、われわれユーザーはそこから「この構成について、今ならこの組み合わせがこういう理由で良さげだ」という知見を積極的に交換していく意義があります。これもわれわれが単にベンダーの提案の追認ではなく、コミュニティで知識の交流を促すべきと考える強い動機になっています。
宣言的記述(化)されていく Cloud 2.0 な世界
よくできたサーバーレスシステムは「リソースのオーケストレーション定義」と「ビジネスロジックの配備」だけでシステムがゼロから稼働状態になるべきなのですが、オーケストレーション定義とFaaS上のコードは今後より補完関係であることが明確になってくると考えています。たとえば、"アプリケーションログを分析基盤に積み上げる仕組み"をサーバーレスで構築するとして、ストリームと分析基盤までのETL処理のパイプラインがオーケストレーション定義のみで完結するのであればコードを書く必要はなくなります。ETL部分にどのような要件があるか次第ですが、たとえばKinesis Firehoseのみで済む要件であれば、それまでLambdaでやっていた処理を排除し、コードのない世界のほうがエンジニアに求められる保守性も小さくなって望ましいでしょう。まだまだ先の話にはなりそうですが、世の中のほとんどのユースケースにおいて、サーバーレスはおそらくコードすら必要のない、ビジネスモデルをオーケストレーションする時代になっていくでしょう。これが真のクラウドコンピューティングの世界観でしょう。(Cloud 2.0)
また、この定義の「形式」がYAMLによるものか、はたまたコードを不要にするための定義をコードで記述できる世界になっていくのかというのも今日現在では楽しみなトレンドです。(PulumiやAWS CDKなど)
サーバーレスなユースケースの発見、アップデート
毎年、クラウドベンダーの提供サービスが充実するにつれ、明らかに今までサーバーレスでは難しかったユースケースを簡単に運用できるようになったパターンというのがあります。Webアプリケーション、ストリーム処理、機械学習とそのパイプライン、システム間でのデータ連携、認証と統合されたREST APIやGraphQLのバックエンド, モバイルアプリのバックエンドなどなど。
知っていると知っていないだけで労力に大きな差が生まれるというのであれば、これらの知見も積極的にコミュニティを通じて共有されていくべきです。
Best of Breedなサービス連携を実現するIDaaS(AuthN/AuthZ)の話
汎用的なサーバー群の上に、必要なすべての機能を配置する従来型のモノリシックから、インターネット上の複数のドメインをまたいでリソースにアクセスする認可情報の引き回しが必要になります。ロックインしやすい部分でもあり、またおざなりな実装ではすぐにシステム全体の体験を壊し、ひいては大事故になりかねない部分であることもたしかです。統合的な運用性、あるいはObservabilityの話
フルサーバーレスの構成でリリースしたアプリケーションにおいて、あるいはリリース前から悩まされることが、システム全体のデバッグのしづらさです。当然局地的にはX-RayでトレースすればOK、Datadogでログを見ればOK、あるいは俺はCW Logsを手探りで探し当てるからOKというツワモノもいるかもしれませんが、現実的ではないことは、システムを構成するFunctionが増え始めたときに必ず直面するはずです。単なるデバッグにとどまらず、システムの健全性、パフォーマンスの測定や劣化検知、レート制限、さまざまな目的すべてを満たす、どんなアーキテクチャにおいてもとりいそぎこれ入れておけばなんでも大丈夫なベストなソリューションはいまだに揃ってないと考えています。ゆえに、これも実行環境のBest-of-Breedと同様に、アーキテクチャに合わせたBest-of-BreedなObservability設計の模索が必要になるはずです。
開発者個人の強化、あるいは生存戦略について
それでは上記のような模索をすることで、開発者個人が得たいものは具体的に何でしょうか。毎晩ページャーに起こされるようなロバスト性の低いアプリケーションの運用から脱却したいとか、経営を悩ませる使用率の低い基盤やそれらを保守する人員コストからの解放なのか、ビジネスが要求する無限のスケーラビリティへの対応なのか、あなたのサーバーレスジャーニーはどうだったでしょうか。