伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（後編）。QCon Tokyo 2016
10月24日に都内で開催されたイベント「QCon Tokyo 2016」の伊藤直也氏のセッション「Serverless Architecture」は、サーバーレスアーキテクチャの本質について大きな示唆をもたらす内容でした。この記事では、その内容をダイジェストで紹介します。 （本記事は前編、中編、後編に分かれています。いまお読みの記事は後編です。） あらためて「サーバーレスアーキテクチャ」とは AWS Lambdaを使っているだけなら、「サーバーレスアーキテクチャ」とおおげさに呼ばなくてもよい気がします。 Microservicesの実装手段としてのFaaSだったり、リアクティブだったりコレオグラフィに関する性質を上手く使いたい意味でこのアーキテクチャを指向するなら、それをサーバーレスアーキテクチャと呼んだらいいんじゃないの、というのが僕の勝手な意見です。 なので、最初に言っていた「サーバー
伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（前編）。QCon Tokyo 2016
クラウド上でアプリケーションを構築する新しい手法として「サーバーレスアーキテクチャ」が急速に注目を集めています。しかし一方で、サーバーレスアーキテクチャを採用することで得られる本質的なメリットはなにか、そもそもサーバーレスアーキテクチャとはなにを指すのか、などについてはまだ識者の間でも議論されていることです。 10月24日に都内で開催されたイベント「QCon Tokyo 2016」の伊藤直也氏のセッション「Serverless Architecture」は、こうしたサーバーレスアーキテクチャの本質について大きな示唆をもたらす内容でした。この記事では、その内容をダイジェストで紹介します。 （本記事は前編、中編、後編に分かれています。いまお読みの記事は前編です。） Serverless Architecture 一休 CTO 伊藤直也氏。 先に結論を言ってしまうと、サーバーレスアーキテクチャと
ソーシャルメディアにおける他人との関係性がコンテンツ価値に影響を与える - naoyaのはてなダイアリー
ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。 以前に HBFav を作ったときこんなことを書きました。 Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。 4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。 ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。 この機能についての自分の感想は以下のようなものでした。 もうすこし補足します*1。 Facebook や Twitter のような
伊藤直也氏がプロダクトマネジャーの役割を学んだ良書5選と、適材を見極めるポイント - エンジニアtype | 転職type
2015.10.29 ITニュース Kaizen Platform, Inc.など複数の企業で技術顧問を務めている伊藤直也氏。同氏が自身のブログ『naoyaのはてなダイアリー』をほぼ1年ぶりに更新したのが、界隈で話題となっている。 伊藤直也氏（From GitHub_naoya/myprofile） そのエントリテーマは「プロダクトマネジャー」について。Twitterでつぶやいていた内容をまとめられたことをきっかけに、筆を取ったという。 >> プロダクトマネージャーについて – naoyaのはてなダイアリー ここ最近、伊藤氏の下には、顧問契約を結ぶ企業以外にも相次いで相談が寄せられていた。その大半が、「良いプロダクトを作るために、開発体制を整えたい」という内容だ。 こういった問い合わせに対して伊藤氏は、「良い開発体制を作れば、それだけで良いプロダクトができるわけではない」と話し続けてきたと
プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
伊藤直也氏が語る、分散アプリケーションアーキテクチャの現在 ～Reactive SystemとMicroservices【デブサミ秋2015 基調講演レポート】
ストリームデータを即時にWebに反映する「リアルタイムWeb」は、TwitterやFacebookなどが普及したことでそう目新しい技術ではなくなった。しかしその実装は、まだまだ力業でなされていることが課題だ。「Developers Summit 2015 Autumn」のKaizen Platform 伊藤直也氏によるセッションでは、リアリタイムWebを実現する分散アプリケーションアーキテクチャの昨今について、「Reactive System」と「Microservices」という2つのキーワードから読み解かれた。 Kaizen Platform 技術顧問 伊藤直也氏 講演資料「分散アプリケーションアーキテクチャ 2015」 ストリーム処理は現状、まだまだ力業で乗り切っている まず、かつては大量トラフィックとデータを、どのように処理していただろうか。LAMP環境を作り、RDBにデータを溜め
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（後編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（後編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015 最新のITと関連技術をエンジニアの視点で掘り下げるイベント「QCon Tokyo 2015 Conference」が4月21日に都内で開催されました。 そのセッションの1つとしてKAIZEN platform Inc.の伊藤直也氏が行ったのが、「モダンWebシステム開発」と題して、最近のWebアプリケーションに関する技術に共通する傾向を探った講演です。 （本記事は「伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015」の続きです） いわゆるAjaxが登場してから、動的にWebアプリ
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015 最新のITと関連技術をエンジニアの視点で掘り下げるイベント「QCon Tokyo 2015 Conference」が4月21日に都内で開催されました。 そのセッションの1つとしてKAIZEN platform Inc.の伊藤直也氏が行ったのが、「モダンWebシステム開発」と題して、最近のWebアプリケーションに関する技術に共通する傾向を探った講演です。 ChefやPuppetなどによるInfrastructre as CodeからImmutable Infrastructureなどのインフラ周りからReactなどのフロントエンドにまで共通する考え方とは何か、示唆に富むその内容をダイジェストで紹介します。 モダ
HBFav 2.8.1 をリリース : iPhone 6 解像度対応と認証再要求問題の修正 / はてなブックマークへの要望 - naoyaのはてなダイアリー
昨日のことになりますが HBFav 2.8.1 をリリースしました。主な変更は iPhone 6 解像度対応 はてなブックマーク追加時に認証を再度要求されてしまう問題の修正 の 2 点です。 これまでは折角画面サイズが大きくなった iPhone 6 や 6 Plus で HBFav を使っても解像度は iPhone 5s のころのサイズのままで、引き延ばされて表示されていました。結果的に文字がぼやけるなどの状態でしたが、今回改めて iPhone 6 と 6 Plus 解像度に対応したことで見た目もくっきり、一画面に収まる情報量も増えました。 不具合の修正は、長らく続いていた、一度認証したのにしばらくするとまた認証を要求されてしまう問題の修正です。自分の手元ではなかなかこの問題が再現せず、原因が特定できずに困っていましたがようやくそれがわかって修正できました。いろいろとご不便おかけしましたが
「リーン」について : 「何を作るか」よりも「何を作らない」か - naoyaのはてなダイアリー
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー
「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが･･･」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメントposted with amazlet at 14.10.18エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル 日本経済新聞出版社 売り上げランキング: 19 Amazon.co.jpで詳細を見る 小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則posted with amazlet at 14.10.18ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン 早川書房 売り上げランキング: 7,579 Amazon.co.jpで詳細を見る Tea
日本語で読める IT名文書 三選 - naoyaのはてなダイアリー
pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。 伽藍、バザール、ノウアスフィア、おなべ(3) http://www.artonx.org/diary/20120411.html#p01 artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した http://anond.hatelabo.jp/20111018190933 (前編) http://anond.hatelabo.jp/20111018192953 (中編) http://a
質問: Go の変数初期化に伴う条件分岐をもっと良い感じに書きたい - naoyaのはてなダイアリー
Go にはスクリプト言語でいうところの variable = a || b のような構文や三項演算子がないようなので、 var accessKeyId, secretAccessKey string if config["aws_access_key_id"] == "" { accessKeyId = os.Getenv("AWS_ACCESS_KEY_ID") secretAccessKey = os.Getenv("AWS_SECRET_ACCESS_KEY") } else { accessKeyId = config["aws_access_key_id"] secretAccessKey = config["aws_secret_access_key"] } とか var url string var err error if len(os.Args) == 1 { url,
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
BigQuery と Google の Big Data Stack 2.0 - naoyaのはてなダイアリー
先日、有志で集まって「BigQuery Analytics」という書籍の読書会をやった。その名の通り Google BigQuery について書かれた洋書。 BigQuery を最近仕事で使い始めたのだが、BigQuery が開発された背景とかアーキテクチャーとかあまり調べもせずに使い始めたので今更ながらその辺のインプットを増やして以降と思った次第。 それで、読書会の第1回目は書籍の中でも Overview に相当するところを中心に読み合わせていった。それだけでもなかなかに面白かったので少しブログにでも書いてみようかなと思う。 BigQuery の話そのものも面白いが、個人的には Google のインフラが書籍『Google を支える技術』で解説されたものが "Big Data Stack 1.0" だとして、BigQuery は Big Data Stack 2.0 の上に構築されており
Deploy to Heroku / Webアプリケーションのポータビリティ再び - naoyaのはてなダイアリー
Heroku の新機能で Heroku Button が出た。 見るよりも、触る方が早い。以下のボタンを押すと md2inao をあなたの Heroku アカウントにデプロイして、動かすことができる。 ボタンを押すと以下のような画面が出て、Deploy to Free を押すと直ちにデプロイが始まる。 GitHub からソースコードが Heroku にデプロイされて、Web アプリケーションが動く。 ご満悦。 このボタンを README.md に置いておけば、Webアプリケーションを自分で動かしたいなと思ったユーザーが、自分自身の環境で好きな時にそれをデプロイして使うことができる。 すなわち、Heroku Button で、URI を介した Web アプリケーションの交換が可能になった。 Heroku Button Heroku Button を有効にするための前提は割とシンプルで Git
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
naoyaのはてなダイアリー
伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（中編）。QCon Tokyo 2016
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
