読者です 読者をやめる 読者になる 読者になる

InnovationEGG第7回「クラウドネイティブ化する世界」に登壇してきました(とその感想)

その他

@Keisuke69です。

3月の19日(土)に大阪で開催された、InnovationEGG第7回「クラウドネイティブ化する世界」でお話をしてきました。

今回の話の内容としてはデブサミで話した内容をベースにスケーラブルなアプリケーションをクラウド上でどう作るか、といった観点でお話をしてきました。まあTwelve Factor AppとかMicroservicesとかの文脈ですね。

資料はこちらです。

イベントの内容とか他の登壇者の話の概要やスライドは同じくこのイベントに登壇・参加されたハンズラボさんのブログでまとめられているのでこちらをどうぞ。

www.hands-lab.com

 

今回のイベント、プラットフォームとしてどこか特定サービスに限定しているわけではなかったので各登壇者の話の幅も広く興味深かったです。また、イベントタイトルにもなっている「クラウドネイティブ」というキーワードについてみなさん最初に定義付けをしたあと話をしている辺り、やはりこのキーワードを取り回す難しさがあるのかなーと感じたり。

加えて、全体的にイベント前に想定していたよりもプラットフォーム側の話が多く、あまりそういった話をする予定のなかった自分としては時間が進むにつれてドキドキしていました。ふと思ったのですがクラウドネイティブというキーワードのイベントにおける参加者のエンジニア属性がどういったものなのかは非常に興味のあるところです。個人的な感覚ではインフラエンジニアのうほうが多いかなとは思ってるんですが実際のところはどうなんでしょう。本来的にはクラウドネイティブって特定サービスの使い方の話ではなくアプリケーションアーキテクチャの話だと思うのですが将来的に逆転したりするんでしょうか?それともやはり「クラウドネイティブ(を支えるプラットフォーム)」的な感じでやはりプラットフォーム側の人のほうがこの界隈では中心になるのかといったところも興味深いです。

 

さて、個人的に印象に残ったこととしては、クラウドネイティブというよりはサーバレスアーキテクチャの話になるのですが、ハンズラボ加藤さんの発表で言及されていた

  • 運用コストを下げたくてサーバレスアーキテクチャにしたものの開発はLAMPの3倍かかった
  • ただし、そのほとんどは学習コストであり2回目以降は爆速開発できそう

というのがどうしてもコンセプトが先行しているところのあるサーバレスアーキテクチャに対する実体験からの貴重な意見ということで参考になりました。このシステム自体は大人の事情でお蔵入りになったとのことで非常に残念ですが、リリースしてしばらく運用してみた上でのサーバレスアーキテクチャに関する評価というのもお聞きしてみたかったところです。そういった話はあと1年もすればもっと聞けるようになるかと思っています。その上でやはりむやみに高まった期待感を裏切られることによる揺り戻しというのも発生しつつ一つの潮流になっていくのではないかと考えています。

 

というわけでお話の機会を頂きありがとうございました。

しばらくパブリックな場での登壇予定はないのでのんびり過ごします。

クラウドネイティブとサーバレスアーキテクチャ

その他

こんにちは、@Keisuke69 です。

ポエムです。

クラウドネイティブとサーバレスアーキテクチャと言うものに関してなんとなく整理がてら書きたいなーと思って。

ま、この2つを一緒に話すのはどうなんだって気もするがポエムなので気にしない。あと文章長い割りに大して中身はない。

クラウドネイティブ

そもそもクラウドネイティブとはなんなのか。クラウドネイティブって言葉が先行していて実際のところなんなのか分からない人も多いはず。何かきちんとした単語の定義があるかっていうともちろんそんなのあるわけない。人それぞれモヤっとしたイメージがきっとあってそれを一言で表現するのにクラウドネイティブってキーワードが使われてるのかなと。ラベリング重要。
 
とはいえ、クラウドネイティブというお題で僕が話をするときに毎回最初に定義をしていて、その定義は以下の通りだ。
  • クラウドで提供されるサービス利用を前提に構築するシステムおよびアプリケーション
  • クラウドの特性を踏まえ、利点を最大限に活かす形で構築されたアプリケーション
  • クラウドで提供されるサービスを利用して効率的にアプリケーションを実装
こうやって見ると1つ目はクラウドネイティブというよりも、この用語が出てくるちょっと前に使われていた(今も使われている?)クラウドファーストの定義に近いかも知れない。うん、これは今後は外そう。で、一番大事なのは2番めのやつだと思っている。
 
まず、最近誤解されている気がするのであえて言っておくとクラウドネイティブそのものはAWSネイティヴとは違う。混同されがちだし、あえて同じコンテキストで話がされていることもあるが本来はそもそものコンテキストが違うのだ。そんなのわかってるよって人は読み飛ばしてくれて構わない。
AWSネイティブはその言葉通りAWSの各サービスをフル活用してアプリケーション開発することでスピードとスケールを手に入れようという話である。一方クラウドネイティブはサービスとして提供されている機能群を有効活用するのというのもあるが、根本的にはクラウドだからこそのスケーラビリティや俊敏性を活かして分散的にシステム構築することでレジリエンシ高くスケーラビリティの高いシステムを作ろうということだと思っている*1*2
広義のクラウドネイティブにはAWSネイティブも含まれるかも知れないが先述のとおり本来はコンテキストレベルの違う話だと思っている。したがってAPI GatewayとLambdaを使ってサーバレスアーキテクチャにすることがクラウドネイティブなのではない。クラウドネイティブの本質はレジリエンシとスケーラビリティをいかに高めるかだと思っていて、そのためのシステムおよびアプリケーションのアーキテクチャの話なのだ。このシステム、アーキテクチャ面での考え方自体はクラウド以前からあったと思うし、考え方そのものはサーバが物理だろうが仮想だろうが関係ない。ましてやそこにサーバがあるかないかなんて大事な話ではない。ただ、それがクラウドの登場により実現に現実味が増したと言えるということだ。ようやく誰でも実現可能になったと言ってもいい。従って旧世代のシステムをそのままの構成で単にクラウド上にマイグレーションすることはクラウドネイティブとは呼びがたい*3
 
加えて、クラウドネイティブなシステム作りをドライブするためには(開発における)ユーザ体験も非常に大事だと思っている。クラウドネイティブだかなんだか知らないけど開発する上ではやっぱり楽なほうがいいよね、と。ローカルで開発してクラウド上にアップするというのが今の多くのスタイルだと思う。もちろん実際にはCI/CDなりのプロセスや自動化なんかが間にはあって、各個人が直接ローカルから都度アップロードしているわけではないと思うが、そういった自動化だとかがアプリ開発者に意識させずに使えるようになると真のクラウドネイティブな気がするな。あとはレジリエンシを高めるためにはモニタリング必須になってくるのでその辺りとかも組み込まれてるといいね。そういう意味ではアプリケーションフレームワークとの密接な関連性、透過的なクラウド利用なんかが求められてくるのかも知れない(適当

サーバレスアーキテクチャ

この言葉自体はそれまでにもあったとは思うけど僕がこのキーワードを使いだしたのはそう、あれはAPI Gatewayがローンチされてからだ。それまで僕は2 Tier Architectureというものをいろんなところで語っていた。2 Tier Architecture自体はここでは触れないが、それ自体はいいと思っているが採用できる局面は限定的と言える。なぜなら2 Tier Architectureを採用した場合、ロジックをクライアント側に持ってくる必要があるからだ。クライアント側にロジックを持ってくると何が問題か。問題の1つとしてマルチプラットフォーム対応があげられる。これが面倒なのだ。各プラットフォームごとにUIに関する部分以外のロジックを実装しなくてはならなくなる。同じ内容を違う言語で、だ。当然、テストコードもそれぞれ必要になるからそれがどれだけ大変なことかは想像に難くない。そこでロジックはサーバサイドに持って行って共通化しよう、そしてその処理はアプリからAPI経由で呼び出そう、となる。そうすると今度はサーバサイドのロジックを書くだけでなくAPIとして公開するためのインフラの構築・運用が必要になってくる。そんなわけでこの辺りから2 Tier Architectureじゃなくなる、というか限界が見えてくる。採用できる局面が限定的としたのはこういう理由からである。ハマれば絶大的な効果があると思うが、そうでない場合は従来どおり3 Tier*4なシステムを、と言っていた。
 
この時点で元来チームにフロントエンド系のエンジニアしかいない場合には絶望的だ。そもそもクライアントにロジックを持っていく判断をしたチームにインフラエンジニアがいるとも思えない。そこで出てくるのがサーバレスアーキテクチャである。AWSで言うと、Amazon API GatewayAWS LambdaおよびDynamoDBとかを組み合わせたものをよく例として挙げているがこれはサーバレスアーキテクチャの一例に過ぎない。別にLambdaを使うからサーバレスだとは思わない。平たく言うとマネージドサービスを使うことで(ある一定範囲までは)楽をするモデルなのだ。これまで自分で構築して運用してきたサーバ群の代わりにサービスとして提供されるマネージドサービスを必要に応じて、必要な分だけ、必要なときに使うのがサーバレスアーキテクチャだと考えている。従ってフルサーバレスなアーキテクチャにできる場合もあれば一部がサーバレスな場合もあるかも知れない(というかそのほうが多いだろう)。あちこちでサーバレスアーキテクチャの考察的なものも見受けられるが、そんな大層なものではなくってぶっちゃけた話、ユーザの視点から見てユーザが自分でお守りをしなければいけないサーバ(インフラ)があるかないかってだけじゃないかな。少なくとも僕はそう思って話をしている。だからインフラの構築・運用にかかるコスト(これには当然それらを担当するエンジニアを抱えるコストも含まれる)や仕様面を比較した上で任せられるなら任せてしまえばいい。マネージドサービスを有効活用することはとてもいいことだと思うがそれに縛られるのは本末顛倒だ。本来あなたがやりたいことは何なのか思い出して欲しい。とはいえ、サーバレスアーキテクチャとはそうではないと思う人がいたらぜひディスカッションしたいです。
 
最後にクラウドネイティブとサーバレスアーキテクチャってタイトルなので両者の関係について言うと、サーバレスアーキテクチャを実現するクラウド側のサービス群はクラウドネイティブに作られてるだろうけどユーザが作るクラウドネイティブなシステム=サーバレスアーキテクチャではないかなっと。
 
あ、一応免責つけておこうw
本ブログは個人としての意見であり所属する企業や団体を代表するものでも見解を示すものでもありません。

*1:従ってLambdaを単に使うことがクラウドネイティブなのではない。Docker使うことがMicroserviceじゃないってのと一緒だ。

*2:以前は「マネージドサービスを上手く使って〜」みたいな話もしていたがそれが故にクラウドネイティブとAWSネイティヴを混同させてしまったのならばそこは謝りたい。

*3:単純移行そのものを否定しているわけではない。クラウド活用のファーストステップとしては現実的な選択肢だ

*4:従来型のWeb/アプリケーションサーバとDBサーバからなるやつ

JAWS DAYS 2016で登壇してきました

その他

3/12(土)に開催されたJAWS DAYS 2016でAWS Lambda / Amazon API Gatewayについて話をしてきました。

JAWS DAYSは6月に開催されるAWS Summitとは異なり、AWSのユーザグループであるJAWS(Japan AWS User Group)が主体となって年に一度開催されるイベントなんだけど、参加者の数が1000名を越えるというすごいイベントなんです。今年は1100名超えでかつ参加者も初参加の人が多かったという話を聞いていて改めて関係者の皆さんすごいなーと頭がさがるばかりです。

 

この日、自分は先のエントリでも報告したABC2016からの連投だったんだけど、ABC2016とは異なり担当している2つのサービスをより掘り下げる感じの内容で話をしました。

資料はこちら。

 
今回は時間も25分程度と限られていたので概要とか基本的な部分を一切省いて、実装上のアレコレについて掘り下げるような感じにしています。中でもスライドのP22、P23にあるイベントソースごとの実行タイプやリトライの違いのまとめや同時実行数に関する考え方はドキュメントを読んでもわかりにくいことも多いので参考になるのでは?
特に同時実行数に関してAmazon KinesisおよびAmazon DynamoDBをイベントソースにしている場合の挙動を正しく理解されていない方が多いなーと最近感じていたのでこういう場でお伝えできたのは良かったかと。なお、これに関しては改めて別途Qiitaか何かで解説したいと考えている。
とはいえこういった話をまとめたには少しだけ理由があって、日本でもLambdaの利用が増えてはいるんだけど、いざLambdaを使ってシステムを作ろうとしたときにそのコンセプトや性質からうまく使い切れていないケースとかハマってしまうケースを最近よく目にしていて。
なのでその辺りに躓くことなくビジネスをドライブする手助けになれば、と思ったのとそろそろLambdaのできることを紹介するだけのフェーズから実際に利用するにあたってのノウハウを伝えていくフェーズになりつつあることを感じているため今回はこういう話にしました。
それはともかく、内容的にもかなりてんこ盛りにしたので25分という短時間で伝えきるために結構早口でまくし立てる感じになったので、あらかじめそのつもりだったとは言えそこは少し残念なところなので機会があればどっか別のところで再度やりたい。オファー待ってます
 
※余談だけど、もともと時間の短さからタイトルにあるDeepDiveは難しいと思っていて、せいぜい浅瀬でバチャバチャやる程度かなと思って皮肉った結果がこのスライドの表紙というのは内緒
 
あとはQ&Aの時間も取れず、イベント自体にも連投の関係で自分のセッション時間からしかいなかったためMeet the SAのコーナーにもいれず全く参加者の方とお話できなかったのは反省だし、他の方のセッションもほとんど聞けずじまいだったのも残念。ABC2016もそっちはそっちで人のセッション聞けずこっちも全然だったので疲労感の割に自分自身が得たものはあまりないという…
 
というわけでまた機会があればお話をしたいと思うのでご連絡ください。
あと、制限緩和の際もぜひ事前にご相談をmm(ってなんか宣伝みたくなってしまったな)

ABC 2016 Springで登壇してきました

その他

3/12(土)に特定非営利活動法人である日本Androidの会が主催するABC 2016 Springで講演の機会を頂いたので登壇してきました。

abc.android-group.jp

 

今回は「AndroidとIoT」というテーマでオファー頂いたのでいつもとは違った話をしてきました。

内容的には

  • AmazonにおけるIoTの取り組み
  • AndroidをIoTに活用する際の利用パターンの説明
  • AWSのモバイルサービス紹介
  • IoTにおけるデータ収集パターンの説明、使いどころの説明
  • 各パターンにおけるキーとなるAWSのサービスを紹介

という感じの話を。

当日の資料はこちら。

 

なお、AmazonにおけるIoTって部分でAWSのSimple Beer Serviceっていうサービスを紹介。これはオフィスとかSan FranciscoやNew YorkにあるPopup Loft(主にスタートアップ向けの常設スペースで、コワーキングスペース的なものや自分と同じロールであるSolutions Architectが常駐してていつでも技術相談が可能、しかも無料)においてあるビールサーバでビールを注いだ量がリアルタイムでモニタリングできるっていうバカバカしいものなんだけど、これも立派なIoTってことで紹介しておいた。
ちなみに興味のある方はこちらのブログに概要とかアーキテクチャ(ソフトウェア面、ハードウェア面の両方)とかについて詳しく書いてあるので是非見てみるといい。
また、こちらのサイトでは実際のリアルタイム状況が誰でも見れるようになっている。

Simple Beer Service | Beer = Good, Streaming Beer = Better

これを書いている今もVirginia Officeのビール流量がそこそこあるので誰かしらがビールを飲んでいるんだと思われる(でも向こうって今は日曜日の午前なんじゃないかな?)。

ちなみにこれが実際に昨年夏にSanFranciscoのPopup Loftに行ったときに設置されていたものを写真に撮ってきたもの。

f:id:Keisuke69:20150806173001j:plain

あとは自分で作るようにってことでソースコードオープンソース化されていたりするのでこちらも興味あればぜひ。日本で作ったらぜひ連絡ください。
 
さて、そんな話はともかく今回のイベントでは100名くらいが参加してくれたのがとても嬉しかったかな。ぶっちゃけアウェイだと思っていたので。
あとは当たり前と言えば当たり前なんだが挙手によるアンケートを取ったところモバイルのデベロッパーの人が多くてそのあたりも良かった。
というのも普段、モバイル開発やアーキテクチャの話をすることが多いんだけどやはりAWSというイメージからか話を聞きに来る人がインフラエンジニアのほうが多いことも多々ある。だから何か問題かって言うとそんなことは全くなくて、それはそれでいいことなんだけどやはり自分の担当領域的にももっとソフトウェア開発者、主にWeb系・モバイル系の人に話を伝えたいってのがあるのですよ。なので今回こういう機会を頂けたのは非常に有りがたかったです。
 
ちなみに今後は登壇の機会を頂いた際にはもっとGeneralな話を増やしていこうかなって思ってて、それが今の自分的なテーマ。基本的にはソフトウェアアーキテクチャの話にはなると思うんだけど、それに(AWSに限らない)クラウド的なテーマを絡めていけたらな、と。もちろん聞きに来る人達がどういう話を期待しているかってのは考慮した上でにはなるけど。AWSのサービスに関して紹介する場でそんな話ばっかしても、「お前の話を聞きにきたんじゃねーよ、サービスについて知りたくて来たんだよ」ってなるので。
 
話はそれたけど、イベントの話に戻ると実は資料の作成に直前までかかっていて午前中の他の方のセッションも聞けなかったし、自分のセッションの後は同日に行われたJAWS DAYSでの出番があったのですぐに会場を出なければいけなくって全然セッションを聞いたりできなかったのがとても残念だし悔やまれる。自分で行くものってバイアスがかかった状態でアンテナに引っかかったイベントに行く形になるのでこういう場では自分の守備範囲外の話が聞けておもしろかったりするものなのだ。
なので講演者の資料のまとめとかあると嬉しいです(事務局の方ぜひお願いします)。
 
とにもかくにも登壇の機会を頂きありがとうございました。

RESTful#とは勉強会で公開レビューしてきました

その他

2/22にヴァル研究所さんのオフィスで開催された「RESTful#とは勉強会13回」に公開レビュー企画のゲストとしてお呼ばれしてきましたー。

この勉強会自体は今回で13回目とそこそこ回を重ねた勉強会で、RESTful APIについてみんなで学び考える会となっているそうで。すみません、こういう勉強会があることは知ってたけど参加は初めてでした。
 
で、公開レビューとは何かというとヴァル研究所さんと言えば「駅すぱあと」なわけですがこの駅すぱあとのWeb版である「駅すぱあとWeb」の公開APIをRESTの観点でみんなの前でレビューするというチャレンジングな企画でした。
 
RESTful APIが何かについては以前に発表に使ったこのスライドを参照してもらえれば。

 
さて、今回のそもそものキッカケは、この勉強会の運営にヴァル研究所の総務(!)の方が関わっているんですが、以前とある勉強会のスピーカーとして喋った際、話の中で自分がRESTおじさんだと言う話をしたところ、
「RESTの勉強会やってるんでそっちにも来てくださいよー」
「ただ行くだけじゃつまらないので公開レビューとかしますか(適当」
「じゃ駅すぱあとAPIでやっちゃいましょー(悪ノリ」
という経緯です。
 
それをまさにそのAPIを作ってる部隊のマネージャーであるヴァル研究所の見川さんに快諾頂けたので実現した感じです。
 
当日は、前半がワークショップ形式で参加者が複数のテーブルに分かれた上で、駅すぱあとのWebAPIを実際にみんなで叩きつつAPIデザインとしていいと思うところ、改善したほうがいいと思うところをディスカッション。後半が公開レビューという形。
 
実際のレビューについては、思っていたより(失礼)綺麗にAPIが設計されていたのと、サービスの性質上ほぼリソースの取得(CRUDのR)のみだったこともありそれほど言うことがなかったのが正直なところ。
というわけで一般的なRESTfulなAPIデザインにおけるベストプラクティス的なものを駅すぱあとAPIの改善点として紹介する形にした。一例として、
  • リソースの相関がURIパスとして表現されるのが良い
  • URIパスとして表現されるリソースはコレクションになるのでリソース名は複数形を使うことが多い
  • バージョンの指定方法について(パス/クエリ/ヘッダのどれを使うか)
  • 似たようなリソース名があってわかりにくい、もしくは分かれている必要がない

など。

駅すぱあとAPIをお題にこういう話をしていたんだけど、素晴らしいなと思ったのはどうしてこういうデザインになっているのですか?と聞くと見川さんからその全てに対して回答が返ってくること。パッと見ではおかしいのでは?良くないのでは?と思うようなデザインのものに対してもなぜ、どういう経緯でこの形になっているのかがちゃんと説明されるのである。これはただただ感心すると同時に見川さんのこのサービスに対する愛のようなものを感じたw と同時に駅すぱあとの裏側みたいなものも垣間見えてそれはそれで単純に面白かったと言える。

 

とまあ、それなりにいい感じで終了したんだけど、当日参加者からもあがったRESTfulである必要性や、RESTの一般的なルールをどこまで守る必要があるかについて個人的な見解を述べておく。これには異論もあると思うが。

 

まず、RESTfulであることの必要性について。RESTfulでなければいけない必要性は全くないと考えている。RESTなんてのは所詮実装指針アーキテクチャのスタイルであり原則にしか過ぎない。一方でメリットとしても語られることが多いがRESTfulなAPIはリソース指向であるが故にWebの世界と親和性が高く、URIによってリソースを特定するという概念そのものは非常にわかりやすいと言える。例えば/booksにGETリクエストをすると本のリストが返ってきて、その中の特定のアイテム、例えばbookidが1のものを取得する場合は/books/1にGETリクエストをするというのは非常にわかりやすくないか?こういったリソース名によるURIとそれに対するCRUD操作をHTTPメソッドで表現すること、そしてリクエストの応答となるステータスコードに意味があるということがRESTの最大の特徴であると同時にそういったシンプルな分かりやすさがRESTfulなAPIの最大のメリットである。単に404が返ってくるというのはページが存在しないという意味ではなく、URIで指定されたリソースが存在しないということなのである。そういう綺麗さがRESTの魅力ではあるものの、別にRESTfulでなくてもURIとして表現されるものが何らかの一定のルールに則って利用者に分かりやすければそれはそれでいいのではないかと思う。ただし、いわゆるRESTfulなAPIでないものをRESTful APIと呼んで公開されているのは個人的にはdisりの対象である。

 

そして、次にいわゆるRESTfulであるAPIとしてのルールについてだが、先にも言ったとおりRESTなんてものは標準仕様でもなんでもなく実装指針アーキテクチャスタイルでしかない。数ある解説において、共通する基本的なルールはあるものの細かいところは正直なところ人によって主義主張が違うと言っていい。例えば先のバージョンの表現方法もそうだ。/v1/booksと/v2/booksという形の場合、v1のリソースセットとv2のリソースセットは別物であるという考えからだ。一方であくまでもリソースはリソースとして同一のものでありバージョンは属性情報の一つという考え方の場合、/books?version=2といったクエリによる指定になる。加えて、リソース名の設計指針としてよく言われるリソース名は複数形で表現すべき、や複数の単語で構成されるリソース名は"-"で区切るべき、とか小文字が望ましいとかそういったのは瑣末なことであり別にどうでもいいと思ってる。勉強会での川村さんの発言にもあったが「全体で揃っていればいい」と思う。もちろん新たに設計する場合、基本的にそういったルールには則る形にはするが。

 とまあ、何が言いたいかというとRESTは綺麗なAPIデザインをする上ではとてもいい考え方だがそれに引っ張られすぎるのは本末転倒であるなのでそこそこにしてもっと本質的なことに時間割こうよ、ということである。
 
そうは言っても僕はRESTオジサンだし、REST原理主義者とも言えるのでREST的に美しくないAPIデザインは認めないんだがw 矛盾していると言われてもいい。
 
とにもかくにも関係者の皆様、こういう機会を頂きありがとうございました。
 
* 当初、実装指針と言った部分が誤解を生む表現だったので修正しました
 
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

 

 

RESTful Webサービス

RESTful Webサービス

 

 

RESTful Web APIs

RESTful Web APIs

 

 

 

Developers Summit 2016で登壇しました(チラ裏)

その他

今年も縁あってDevelopers Summit、いわゆるデブサミでの登壇機会を頂いたのでお話してきました。

内容的にはクラウドネイティブなアーキテクチャな話だったんだけど、発表が終わった今、少し思うところがあるので反省というか自戒も込めて。
完全にチラ裏エントリです。
 
ちなみに発表内容はこちら。
 
内容的には、
 
という感じでそれぞれを浅く広くという感じで話したんですが、まあぶっちゃけウケなかった。
 
元々はもっとGeneralな内容にするつもりだったんだけどついつい要らぬ欲が出て前半殆どがサービス紹介みたいになってしまった。
その結果、後半は時間が足らずかなり駆け足な内容に。
 
そういう意味ではクラウド(というかマイクロサービス)な開発の話をもう少し詳しくした上で前半に持ってきて、後半にそれをAWS上で動かす場合の話をすれば良かった。今さら言っても仕方がないが僕の伝えたかったことは「AWSを使ってマイクロサービス」ではなくて「マイクロサービスってどういうもので実装上気をつけるのはココだよ」であってそれを下支えするツールとしてのAWSだったのだ。これはこれでAWSのソリューションアーキテクトとしては正しかったのかもしれないが。なお誤解のないよう言っておくと、別に会社からこういう体裁でやれと言われたわけではないし、そのあたり割りと自由な会社だと思っていてそれはすごく感謝している。
 
話を戻すと後半のDevOpsなんてあのレベルならバッサリと削ってしまってよかったと思ってる。
 
さて、そういった話とは別にもう一点ある。それは本セッションのタイトルにもある「クラウドネイティブ」について。
この用語自体がとても実体のないフワフワした用語である。自分もこれまで使ってきたのだが、今回改めて考えたところ「クラウドネイティブ」とは何なのかわからなくなってしまった。いや、自分なりに腹落ちのする説明をつけれなくなったというか。その結果が苦しまぎれ(と言ってもいいと思う)なスライド中のあの自分なりの定義なのだ。というわけでこの用語に関しては答えを見つけるまで使うことを控えようと思う。
ただし、この言葉自体を否定しているわけではないので他の方がその方の文脈で使う分にはとやかく言うつもりは全くない。
 
※唯一良かったと思えるのは後半飛ばし気味だったとはいえ時間ピッタリに最後まで終わらせたくらいか。
 
と、まあこういう辺りを踏まえて次回大阪でお呼ばれしているInnovation Eggではお話をしたいと思います。
次回はこちらでお話をさせて頂きます。
 

innovationegg.doorkeeper.jp

Innovation EGG 第7回 『クラウドネィティブ化する世界』
2016-03-19(土)12:00 - 18:30
会場 エムオーテックス 新大阪ビル 大阪市淀川区西中島5-12-12

 
タイトルに思いっきりクラウドネイティブって入ってるけどwww
 
 
 

gitignoreで指定する前にaddしてしまった場合のメモ

Tips

慣れない言語とかフレームワークIDE使っていて後からgitignoreしたい場合にどうやればいいか忘れてしまったので備忘録がてらのメモ

インデックスから削除すると同時にファイルも削除する場合

$ git rm -f hogehoge~


インデックスからだけ削除する場合
※つまりファイルはそのまま

$ git rm --cached -f hogehoge~

こちらもどうぞ

[初心者向け]こんなときどうする⁉︎ GitのTips25選! - Sweet Escape

Gitポケットリファレンス

Gitポケットリファレンス