AWS」カテゴリーアーカイブ

AWS INNOVATE で改めて確認

昨日、AWSのイベントであるAWS INNOVATEが開催されました

https://innovate-modernapps-apj.virtual.awsevents.com/home

しばらくはアーカイブが有効なので、ちょこちょこと見直しておきたい。

カンファレンスでは、実際のところそこまで細かい内容には触れないので、良し悪しだとは思うんだけど、
ざっくりと全体像をつかむという意味ではわかりやすい。

特にAWSみたいに多くのサービスを提供していると、自分が触ったことがあるところ以外に関しての知識がSAA取得時に勉強したところから止まっている・・・・と言うより忘れているんですよね。

オープニング、コンテナ、サーバレス

このあたりはざっくりと確認して復習してます

そろそろ、止まっているDAの勉強再開とSAPの勉強を始めないといけないな。

LINE-BOTで遊んでみた

先日あった、技術書店13で購入した「HANDS-on LINEBOT」に従う形ではあるんだけど、一通りのLINE-BOTを作る工程を学んだ

HANDS-on LINEBOT
https://techbookfest.org/product/3EUnJ5WbexvCDyMgSJS1qb?productVariantID=1bFbTUsxUPrDGXzGCQQNUF

BOTというと、LINEだけでなくTwitterやSlackなど、様々なところで昔からあるんだけど、恥ずかしながらこれまで作ったことはなかったんですよね。

興味自体はあったといえばあったんだけど、あくまでなんとなくであって、特にそれを使って何かをしたいかな?とも思わなかったというのが理由ではあります。

じゃ、今回なにかそういう新しいきっかけがあったのか?と言われると、特にはないんだけど、LINEの公式アカウントだったりミニアプリは結構面白いかな、と思っているんですよね。
iOSなりAndroidなりにアプリを提供しようとすると、AppleやGoogleに対して審査を通す必要が出てきてしまいますし、何より手間がかかる。
そこをLINEに乗っかることが出来るのであれば、結構楽にいいコミュニケーションチャネルを構築できるのでは?と前々から思っていました。

そういう事をしようと考えると、LINE-BOTは抑えておきたい内容です

学んだこと

当然のようにLINE-BOTの本なので、LINEメッセージの受け答えや、メッセージの種類。それぞれの表現などに関して学ぶことが出来たのは言うまでもないですが、他にもいくつか収穫はあったかな、と思います。

AWSサービス(Lambda+DynamoDB)とその開発の仕方

今回の最終形は、バックエンドをAWSのLambdaとDynamoDBで構築するというもの。
ただ、開発としてはローカルで行っていきます。

Lambdaに関してはnodeで動かすわけですが、DynamoDBに関してはDockerで提供されているものを使う形でした

amazon/dynamodb-local
https://hub.docker.com/r/amazon/dynamodb-local/

aaronshaf/dynamodb-admin
https://hub.docker.com/r/aaronshaf/dynamodb-admin

こんなのがあったんですね~。
クラウドネイティブなサービスを開発するうえで、ローカルでの開発をどうするのか?は正直わかっていませんでしたが、こういうものを利用することで、ローカルとプロダクションを同じように出来るんだな、と。

さらに、Serverless用の環境構築ツールとしてServerless Frameworkを使っていました

Serverless framework
https://www.serverless.com/framework

正直これに関しては、例えば AWS であれば Cloud Formation だったり、CDK ( Cloud Development Kit ) を使うのに比べてのメリットってなんだろう?がそこまでよくわかっていません。
マルチクラウド環境で使える・・・?でも定義に思いっきりAWSとか描いたりしているもんなぁ。。。と。

CDKとの比較で考えると、YAMLかコードか?というところが大きい気もする。
ただ、このあたりのCaIは私は経験値が少なすぎます。
積極的に、こういう場合はどうなるんだろう?をやっていくべきなんでしょうね

Express実装例

もう一つは、それなりに対応が可能なLINE-BOTの実装例としてのサンプルコードですね。
今回の実装はExpressを使っているので、あくまでその一つのサンプルにはなりますが。

そもそもの話として、LINEで出来るのは基本的にはメッセージのやり取りではあるので、今回の構成はそれほど大きく変えることなく使い回せるのでは?と思います。

もちろん、今回の実装例をもとに、別のフレームワークなどで実装してみて練習するというのもいいな、と思いました。

LINE-BOT関係でいうと、次はこのあたりを使って見ると、よりいろいろなサービスを使う形ができて面白そうだ

試験日まで毎日励ますサーバーレスLINE Botを作ろう(マネジメントコンソール編)
https://blog.usize-tech.com/encourages-serverless-linebot/

手元で動くと面白いんですよね

もちろん、何かしらのチュートリアルみたいなものをやって、それをブラウザで見るというのは一つの経験ではあるんだけど、LINEのような普段使っているプラットフォームで、自分が組んだプログラムが応答を返してくれるというのは、素直に面白いと思うのです。

先日、友人から子供に対してレゴのプログラミング教室か、Unityのプログラミング教室とか、そういうところに通わせようかと思っているんだけど、どう?って聞かれたのです。

その時には、何がしたいのか次第だよな・・・とか、実際にオフラインで教わることが出来るのであればレゴとかがいいけど、オンラインであれば物理的な部品が絡んでくるレゴはやめたほうがいいんじゃない?と返したのですが、こういう、リアクションが返ってくるようなプログラムから、プログラミングの世界に入っていくのも結構ありなんだろうな、と思ってしまいました。

SmartMirror妄想

先日、AWS のオンラインセミナーシリーズであるBlack Beltを見ていたら、こんなものが

見る限りでは、まだまだ改良の余地がありそうな顧客体験に感じるけれど、ちょっと未来的ですよね、SmartMirror。

そこで、SmartMirrorに関してちょっと調べてみた

SmartMirrorの仕組み

そもそもの話、鏡とは?ということに関してもちゃんと知らないことに気がつく。
そもそも鏡とガラスってどう作られるのか?ガラスはなんか砂を溶かしてやるって漫画で見たぞ?

こちらのサイトを見る限りでは、鏡=ガラス+銀 or アルミニウム背面のようだ。

SmartMirrorでは、背面としてディスプレイを使うし、鏡自体もマジックミラーを使うらしい。

ラズパイを用いる

作り上げるにはRaspberryPiを使うと、すでに世の中にはノウハウが溜まっていて楽そうだ。特にOSSでMagicMirrorを作るためのプラットフォームが用意されている

MagicMirror²
https://magicmirror.builders/

調べてみるとYouTubeにもDIY動画などが上がっていて、意外と簡単に作ることができそうだ。

何に使うのか

実装そのものは、技術的には別に問題なくできそうだ。
とは言え、作ったとして何にどう使うのか?を考えてみたい。

事例としてよく挙げられている内容としては、鏡に天気予報やニュース、メッセージなどを出すということなんだけど・・・

スマホでいいよね?

という結論に至ってしまう。もしくはスマートウォッチ。

鏡に文字が浮かび上がるのは、未来感もあるし、言ってしまうとSF的な感じもする。
ロマンだ

だけどせっかくなら有用な利用用途を考え出したい。

スマホなどと違って、鏡であること。
それであって、RaspberryPiで出来るレベルの表現

思いつかないな。。。

とりあえず、いつの日かロマンを追い求めて作り出すかもしれないので、見つけたサイトを備忘録に載せておくことにする

今週はイベントが重なっている

GWが終わってからちょっと忙しい日々が続いてしまった。忙しくなると色々なものが手につかず、本来であれば進めたいはずだったものが止まってしまうのが非常に悪いところ

「忙しい=時間がない」という図式は成り立つことが多いのは当たり前だけど、「忙しい→疲れる→やる気が削がれる→時間を無駄に過ごす=時間がない」となることのほうが多いと感じる

詰まるところの結論は変わらないが、中間を効率化もしくは、やる気を出す工夫によって結論を変えられるとは思っている

また、忙しさの質をもう少し上げることができればとは思う。
忙しいけれど退屈だなと言う状態からエキサイティングな忙しさに変えることができないかということ

まぁ、言うは易く行うは難しということではあるけれど、何かしら行動を変えてみて、自分に揺さぶりをかけてみることにして、新卒入社時の同期を20年ぶりくらいに飯に誘ってみた。

そんな話もありつつ、今週は大規模イベントが目白押しでございます。
自分の備忘録も兼ねて、気になったセッションをざっと洗い出してみた

Microsoft Build 2022

Microsoft Build

今年もオンライン開催となったMSのBuild。
正直、少しAzure案件に関わったことはあるけどそこまで触ってはいないし、仕事で関わる頻度としてはないんだよね。
というわけで、ローコードやTeams周りをチョイスしてみようかと考えている

結構時間被っている&深夜すぎる。。。

なんてのも面白そうだ。
いずれにしてもLiveで見るのは仕事に支障をきたしそうなので、後で見るという形になるだろう

と、ここで気づいた。日本語での日本時間帯セッションがある

Spotlight on Japanの中からいくつか

うーん、日本語なのは魅力的なのだが、セッション内容としては、聞いてみないとなところはありそう。

AWS Summit Online 2022

AWS Summit Online 2022

さて困ったことに完全にBuildと日程がかぶっているが基本的に日本時間なのがありがたい。いや、結局録画見るんだろうけど。
ちなみに、セッションのURLはまだないっぽい?気になったのをいくつか。

  • SaaS の認証認可について改めて考える〜 アーキテクチャーパターンと実装例 〜(AWS-33)(5月 26日 | 3:30pm – 4:00pm)
  • AWS Lambda Performance Tuning Deep Dive〜本当に知りたいのは”ここ”だった 〜(AWS-46)(5月 26日 | 1:15pm – 1:45pm)
  • マルチリージョンでディザスタリカバリ(DR) 戦略を検討するためのポイント(AWS-50)(5月26日 4:15 午後 – 4:45 午後)
  • アーキテクチャ道場!(AWS-51)(5月26日 5:00 午後 – 5:30 午後)
  • AWS CDK で CI/CD つきの Web アプリを作ろう!開発風景を Live Coding でお届けします(DEV-04)(5月25日 3:30 午後 – 4:15 午後)
  • 最小限のコーディングでフルスタックアプリ開発を!Amplify Studioを活用したアプリ開発Live(DEV-06)(5月26日 12:30 午後 – 1:15 午後)

先にも書いたように、最近夜になかなか勉強なり頭を動かすことができていないんだけど、どこかで転換点を作って動き出さないとですね。

今週も頑張ろう

API Gateway を用いたHTTPメソッド呼び出し

AWSのAPI Gatewayを触っていて、若干混乱してきたので、簡単ではあるけれどまとめる

API Gateway が対応しているAPIのタイプとしては下記の4種類
  ・HTTP API
  ・WebScoket API
  ・REST API
  ・REST API (プライベート)

GCPで提供しているAPI GatewayプロダクトであるApigeeでは、WebScoketに対しての対応が正直いまいちなので、そういう意味ではWebScoketを試してみたいが、WebScoketクライアント用意したりするのも面倒なので、ここでは通常のREST APIを題材とする

まずは、APIの集合体に対しての名前付けとプロトコルの選択をする。
REST APIを選択したはずなのに、WebScoketが選択肢として残っているのは意味があるのだろうかと疑問を感じるが、気にしない。
ちなみにエンドポイントタイプのデフォルトは”リージョン”。エッジ最適化を選択すると、CloudFrontが用いられる形のグローバル利用を想定したAPIになる。

ここでは、GithubAPIを例にして作ってみることにする

初期状態ではAPIのRootが存在するだけ。ここからリソースやメソッドを追加していく。まずはGistのAPIを作ってみようと思うので、リソースの追加でGist。メソッドとしてGetを追加してみる。

GETメソッドを追加すると上記のセットアップ画面に。
「統合タイプ」という日本語がどうなのか?という気がするが、呼び出しとして何を利用するのかを選択することができる。
多くのAPI GatewayチュートリアルではLambdaを呼び出すつくりになっている。
既存のAPIをEC2や別途提供しており、それを呼び出す形であればHTTPになる。

試しに、GithubAPIを直接呼び出してみる
  ・統合タイプを「HTTP」
  ・HTTPメソッドを「GET」
  ・エンドポイントURLを「https://api.github.com/gists」
にする

メソッドを作成するとこのような画面になる

ブロックが大きく分けて4つ。

メソッドリクエストクライアントから見た時のこのAPIの呼び出し仕様の定義
統合リクエスト統合先(最終的な呼び先、ターゲット)をどう呼ぶのか
統合レスポンス統合先からのレスポンスをどう処理するかを定義。
基本的にはそのままだと思う
メソッドレスポンスクライアントに返すレスポンスの定義

“テスト”をクリックし、実際にメソッドを走らせてみると、レスポンスとしてGithub.comから結果を受け取れていることが確認できる。

これでメソッドとしては作ることができたのだが、本家のAPIではいくつかのQueryParameterを受け取ることができる。せっかくなのでこれも実装する

「メソッドリクエスト」にて「URLクエリ文字列パラメータ」を追加する。本来はどれも任意のパラメータだが、試しにpageとper_pageを必須にしてみる

見ると、統合リクエスト側にも自動的に追加されていた

クエリパラメータを指定せずにテストをしてみると、エラーに・・・ならない。
よく見ると、メソッドリクエストに黄色△マークが出ている。

結論からいうと、デフォルトでは値の検証機能はなぜかOFFになっていて、明示的に指定する必要があった。
「設定」欄にある「リクエストの検証」を選択する

それにしても、UIが鉛筆マークがついているとはいえ、何が設定値なのかの判別が難しすぎる。非常にわかりづらいと思うのは私だけであろうか。

これで実行すると、期待通り400エラーとなってくれ、パラメータを指定することで結果が正しい形で取得出来ていることが確認できる。

次にsinceパラメータを試してみる。
ちょっと意地悪で、日付書式不足を設定してみると

書式のバリデータに引っかかったようで、レスポンス本文にエラーが出ている。
ただ、ステータスコードは200となってしまっている。
ログを見ているとわかるのだが、実際のところGithubからは422が返却されている。

これは、API Gatewayの設定で「メソッドレスポンス」と「統合レスポンス」を正しく設定していないことに起因する。
デフォルトでは、すべてのレスポンスがステータスコード200で返却するようになっているのだ。

とりあえず、ありえそうなメソッドレスポンスを定義して

統合から何が返ってきたときにどのメソッドレスポンスを関連付けるかを設定します

そもそも、デフォルトが200というのがおかしいのであって、統合から200が返ってきたときだけ200を返却し、定義にない返却値の場合は500にしておいた。
デフォルトのマッピングは、項目でいうと「HTTPステータスの正規表現」を空にするとよい

これで、クエリパラメータの書式エラーは500となった。

未定義のステータスコードがデフォルトになってしまうというのはどうなんだろう?
そのまま返してくれればいいのになってことで、デフォルトをなくしてみると

結局500エラーで、しかもInternal Server Errorときたものだ。

ままならぬ。
本当はバージョン管理周りをまとめたかったのだが、そこまで行きつかなかったので次回に。。

SAA取得!

以前、書いたように AWS 認定資格である Solution Architect Associate 試験を昨日受けてきて、無事に合格しました

SAAは問題の難易度というか深さでいえば、それほど深くはないんでしょうけれど、出題範囲がとても広いので覚えるのが大変。
出題範囲の中心は主要サービスとはいえ、実際に自分で使ったことがないサービスが多いので、様々なケースにおいて何を選択すればよいのか?ということに関しては、合格した今でも不安が残ります。
だからこそAssociateレベルなんでしょうけれど。

実際のところ、これを取得したところでAWSに関して詳しくなったという実感はなく、こういうケースはどうなんだろう?という問いに、実際に実施できるのか?に関しては難しい。
いわゆる、「全然わからん」という状態になっている気分です。

というわけで、やはり次は開発だろうということで、Udemyにてコースを購入。勉強し始めました

Ultimate AWS Certified Developer Associate
https://www.udemy.com/course/aws-certified-developer-associate-dva-c01/

ちゃんと使えるように、SAAで勉強した内容をもとに実際に触って学んでいきたいところ。

いやはや、学びは尽きないですね。
自分のレベルが低いことはわかってはいるものの、少しずつでもマシになれるように頑張るぞっと

追記
よくよく見てみたら、スコアを発見。
720点合格で787点ということで、結構ギリギリだった。。。危ない危ない

AWS SAAへ挑戦するぞ

AWSの認定資格であるSolutions Architect Associateの試験を申し込んだ。

この認定資格は、たぶん5年位前。前職で取ろうと思って勉強したものの結局試験を受けずに放置。
昨年末、再び取ろうと思い、Udemyのコースを使って勉強を再開。一通りUdemyのコースを受講し終わったもののグダグダとしていた試験です。

ちょっと、いい加減にずるずるとしてしまっているので勉強が十分かどうかはさておき、試験の予約を取ってしまおうと。
勉強期間だけで考えると十分な期間ではあるものの、その間にAWSもどんどん変化していっており、以前は正解だった選択肢が現在においては不正解となるケースもいくつか見受けられます。

世の中にはAWSの全資格を取得するような強者がいるようですが、仕事でAWSだけやっていればいいというわけでもない場合には、その知識を更新し続ける必要があるわけで、なかなかそれは大変だなぁと、資格を一つも持っていないうちから心配しております。

SAA資格は、AWS認定資格の中でも全般的な知識を問われる資格なので、広範囲なサービスに対する知見を求められます。
実際にAWSを業務で使う際に、これらすべてが必要になるケースは稀な気がしているので、これらの知識アップデートは仮に資格を取得できたとしても、大きな課題となりそう。

さらに困ったことに、AWSだけではなくAzureやGCPも業務で使うシーンはあるんですよね。
欲を言えば全部知っているに越したことはないし、何かしら似通っているところはあるので応用も聞くとは思う。

いやはや、みなさん息してますか?って気分になってきますね。

とりあえず、まずはそんな捕らぬ狸の皮算用していないで、しっかりと目の前のSAAを取ってから考えなさいということなので、頑張りますよっと。

AWS Lambda で EC2 をスケジュール起動/停止

Lambda 、使ってますか?

まだLambdaがではじめたばかりの頃の AWS Summit で、その存在を知った時に、
結構面白そうなものが出てきたな〜と思ったものの、
当時の自分としてはそれほどAWSを使っていたわけでもないのでパッと用途が思いつかなかったんです。

S3に画像をアップロードしたのをトリガーに〜とか、Kinesisのデータを〜とか言われても、
そんなシーンが到底自分に来るなんて思えなかったし、実際のところまだ来ていない。

最近、少し期間が空いてまたAWSを触り始めた時に、EC2の起動/停止面倒だな〜、
そろそろEC2にもそういう機能が備わってないかな〜って調べていたら

LambdaのScheduleイベントでEC2を自動起動&自動停止してみた#reinvent

おおおおお。
素晴らしい。

何が素晴らしいって、ずっと心の中でくすぶっていたLambdaを触りたい欲求と、EC2のスケジュール対応が一度にできることですね。

Lambdaがスケジュール起動できるようになった話は聞いていたけど、
なんとなく又聞きで知ったような感じだったのもあって、とっさに思いつかなかったなぁ。

素直に嬉しい。
と、同時に、こういう形でLambdaが使えるようになると一気に出来ることが増やせそう。
うーん、やっぱりLambdaは楽しそうだぞ

AWS Summit 2015 TOKYO セッション資料公開

先日少しだけ参加させていただいた AWS Summit TOKYO 2015 のセッション資料が公開されました!

「AWS Summit Tokyo 2015」開催レポート動画・資料一覧http://aws.amazon.com/jp/summit2015-report/details/

当日は、見に行く事のできなかったセッションが多数あったので、ぜひチェックしたいところです。
一部のセッションは資料のみですが、結構多くのセッション動画も公開されています。
時間はかかりますが、目を通していきたいと思います。

Tech Deep Dive by Amazon

特に、AWSに関する事をAWS側で検証した「Tech Deep Dive by Amazon」は一通り目を通したいです。
まずはEBSのパフォーマンスに関してのセッションである「TA-06:Amazon EBS パフォーマンスベンチマーク 2015」を。
なーんとなく知っていた事もありましたが、それぞれの使い方を再確認するとともに、インスタンスストアの使い方とかちょっとはっとさせられる内容でした。
使い方次第では面白い使い方ができそうで、考えてみたい内容です。

 

KEY-03:DevCon Day1 クロージングキーノート2035 年、その時デベロッパーはどう生きるか

セッションの途中で退席してしまった大前さん親子のセッションも動画で拝見しました。

序盤はどういう流れになるのか怪しいな〜と思って別セッションへ移動してしまいましたが、
最後まで見るとなかなかどうして。考えさせられる内容でした。
価値を生み出すというキーワードはこれまでも多くの書籍で語られてきている内容ではありますが、
今一度思い起こす必要があります。

エンタープライズでの活用事例もいくつか見受けられるので、それも見ていきたいところですが。。。
ちょっと全部見るのは大変そうですね。。。

何かオススメがあれば教えてください。。。

AWS Summit Tokyo 2015 へ行ってみたよ(Day1のみ)

AWS Summit Tokyo が6/2-3の日程で品川プリンスにて開催されていました。

AWS Summit Tokyo 2015
AWS Summit Tokyo 2015 クラウドで、未来を「今」に。
http://www.awssummit.tokyo/

仕事の関係で、Day1の午後のみの参加となってしまいましたが感じたこと・考えたことのメモをば。

前提

AWS自体を私が触り始めたのはつい最近で、まだ1年程度。
しかも、触り始めたといってもずーっと何かをしているわけではなく、EC2とRDSを少し触りながら既存システムのAWS環境での動作確認等を行った程度のレベルなのでたかが知れます。

AWS Summit は初参戦で、申し込みが遅れてしまったのでほとんどのセッションが満席><
実際には事前のセッション申し込みはチェックされなかったので意味がなかったっぽいけれど・・・。

 [Dev-01]デベロッパー視点で見たAWS

AWSの各種サービスに関してのお話。
CodeZineで連載された、アプリ制作に関する話も交えながら、数あるサービスの中でどういったものを使っているのか?など。
ちなみに連載は見ていなかったけれど、こちらが初回。

【制作1日目】 池澤あやかさん、イベント会場がヒートアップ間違いなしのアプリを制作、まずはクライアント側処理です ~ Amazon S3 / Cognito / Kinesis / DynamoDB 登場
http://codezine.jp/article/detail/8642

S3の使い方や、Cognito。それにLambdaの話などが目につきました。
また、私の現在の業務からはちょっと考えづらいですが、AWSを前提としたアプリケーションを作る場合に、
ローカルでの開発(オフライン状態)が難しいという話は少し新鮮に感じました。

開発環境をそもそもクラウド等に構築するようなこともあると思う。
今後の開発のあり方というものは少し見守っていく必要がありそうだなぁ。

[Dev-02]デベロッパーが切り拓く、次の時代

タイトルからもわかるように、AWSと結局全然関係ないような内容だった。
パネリストはみんな大好きnaoyaさんと大場さん。

開発者はどういうスタンスで次の時代を乗り切っていくのかという話。
ともすると、どうしても技術オタクになってしまいがちな人が多いけれど、
技術が先にあるのではなく、課題が先にあって、その解決の手段として技術がある。

何かの技術に対して掘り下げていくことは悪いことではないんだけど、それをキャリアとして計画するのはどうなのか。
出来ないことを解決するためにいろいろな試行錯誤があるわけで、その前提条件として何らかの技術をおいてしまうと
出来ることや成長にブレーキがかかってしまう。

この話は、今一度自分自身を思い返したいところだと思いました。
そういう意味でも、最後にnaoyaさんが話をされていましたが、自分のポジションをちゃんと把握することが大事。
そのためには、現在の周りの状況が見えている必要がある。

我々エンジニアは、結局のところ死ぬまで勉強が続くのであるのだ。

[KEY-03]DevCon Day1 クロージングキーノート:2035年、その時デベロッパーはどう生きるか

大前さん親子の会話。
大局観的なとらえ方は面白いと思いつつも、少し気になるシアターセッションもあったので途中退席。
後でセッション資料や感想を確認したいところです。

それにしても、茶の間での会話レベルが高いな~。
わが家でもそういう話をするような時代が来るのかな?
まだまだ小さいわが子を見ていると、少し想像できませんね。

ちなみに、期待していたシアターセッションはあまり面白くありませんでしたので割愛。

[TE-05]ファイヤーサイドチャット~エンタープライズ企業はいかにクラウド化の流れを進めるべきか~

Amazonのえらーい人3人を交えたトーク。
ちなみにファイヤーサイドチャットというのは、暖炉のそばで話すようにフランクな会話ということらしい。
お題としてはエンタープライズ企業におけるクラウド化に関して。

実際のところ、AWSはすごいメジャーになってきていると思っているんだけど、日本の企業のどの程度がそう思っているのだろう。
AWSのようなスモールスタートが出来る環境であれば、大企業じゃなくても活用できるはずなんだろうけれど、
たぶん多くの企業ではそういうところまで目を向けていないんじゃないかな~。

印象に残った言葉としてはこれ

問題はテクノロジー側にあるのではなく、組織の文化だったりする。 口では色々なことをいうことは出来るんだけど、実際に動くことが出来るのか。

はたして、日本の企業はそういう考えを持つことが出来るのか。
個人的には、そういう考えを持てないと今後は生き残れないくらいまで過激なことは言わないけれど、
いいものはどんどんと活用していけばいいと思うんだよね。

ベンダーロックインという考え方は確かにあって、AWSがなくなったらどうするんだ?というのはリスクとしてはわかる。
その時には作り直せばいいんだ!って軽々しく口に出してはいけないことも、まぁわかる。
ただ、その時が来るまでに生き残れるのか?ということを考えるのであればやっぱりスピード感を持ってことにあたらないといけないと思う。

やはり、最後はいつも人の問題になるんだな。

実はこのセッションはこれ以外にもすごい色々なことを考えさせられるセッションでした。
AWSを使うことによるメリットを、どうエンタープライズに伝えていくのか。
実は業務でも少しかかわっている課題でもあるので、より深堀しながら考えて進めていきたいところです。

シアターセッション

展示会場に設置されたシアターセッションも時間のあいまではありますが、少し拝見させていただきました。

各回ともに10分程度の時間なので、それほど多くの情報は得られませんでしたが。
スカイアーチネットワークスさんがchef やserverspec。Zabbix等をまとめたツールに関しての話をしていた。

DevOpsサービス (スカイアーチネットワークス)
http://www.skyarch.net/devops/

chef や serverspec に関しては、知ってはいるものの、Windows主体で私が動いている&それらのツールがWindowsではイマイチ使いづらい印象が結構前にはあって、
本格的に見ていませんでしたが、もうそろそろ見直してみようかな~と。

まとめ

見てわかる通り、申し込みが遅れたこともあって「AWSを使いこんだぜ!」っていうセッションにいけませんでした。
どちらかというと、開発者や企業が今後どういう形で進めるべきか?というような、AWSべったりではないセッションが多かったです。

個人的には、それがとても良かったように感じます。
特に、ファイヤーサイドチャットで得たことは、今後大きな糧となってくれると思っています。

セッション資料等に関してはきっとAWS公式がまとめて公開してくれると勝手に思っているので、
AWSを使い倒したぜ!みたいなものに関しても見ていきたいと思っています。

今後が楽しみです!