フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
![Immutable Infrastructure / これからのWeb, クラウドシステム](https://cdn-ak-scissors.b.st-hatena.com/image/square/344b56510394fe662c6f72e7acc0f226b76dd9b9/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fbb1b90e01c8201324610222c32eaed08%2Fslide_0.jpg%3F3507516)
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
KAIZEN platform Inc. Senior Technology Advisor 伊藤直也氏(@naoya_ito) 2002年に新卒入社したニフティでブログサービス『ココログ』の開発担当となり、一躍有名になる。その後、はてなで『はてなブックマーク』など各種サービスを立ち上げ、2010年にグリーへ入社。2012年に同社を退職して以降は、フリーランスとしてベンチャーの技術顧問などを請け負う。自身のブログ『naoyaのはてなダイアリー』が人気 「Webアプリの実装で差別化は無理」という考えが変わった 現在、KAIZEN platform Inc.をはじめ複数社の技術顧問を務めている伊藤直也氏。「普段から、アウトプットの目的なく技術の勉強をすることはほとんどない」という性分から、今年上半期は「顧問としてベストプラクティスを提供するために知っておくべき領域」にフォーカスして情報収集を
このエントリは前後編に分かれています。前編は主に運用フローやそこでの工夫点、後編は実際の運用から得た知見や今後の課題といった内容です。 ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) 最近はインフラ運用・DevOPS関連のトピックとして目にしないことはないくらい、「イミュータブルインフラストラクチャー」について様々な議論がなされています。私たちも昨年、継続的デリバリという文脈で、@IT の連載にてその基本的な考え方について紹介させていただきました。 さて、今年の二月にローンチをしたばかりのヌーラボのシングルサインオンサービス「ヌーラボアカウント」では、イミュータブルインフラストラクチャの一歩手前として、特定の変更を加える場合のみ、ごっそり環境ごと入れ替えるというやり方にてその運用をスタートしました。
こんにちは。最近社内で「実践F#」読書会を始めた@edvakfです。関数型言語というだけで特に理由なくF#を選んだのですが、弊社のウェブエンジニアの方々がF#にまったく興味が無いことを痛感しました。目下少数精鋭で進行中です。 さて、F#読書会とは別の曜日になりますが、pixivというアプリケーションを開発する上でのプロダクティビティを上げることを目指した「エンジニアリングプロダクティビティ向上ハッカソン」を2013年の後半から始動し、かれこれ半年近く続けています。 昨日 Immutable Infrastructure Conference #1 に参加してきたので、今日はpixivの開発環境やデプロイ環境がこの1年でどう変わったかを振り返ってみたいと思います。 2012年まで 僕が入社した2012年はちょうどsvnからgitへの移行期でした。pixivにはPC版ウェブサイトであるwww.
Immutable Infrastructure Conference #1 : ATND 2014/03/25 Immutable Infrastructure Conference #1 #immutableinfra - Togetterまとめ 最近は最早バズワード化した感も充分ある『Immutable Infrastructure』。この長〜いフレーズを発音する際に途中発音を噛む人が後を絶たない今日この頃、皆様いかがお過ごしでしょうか。(発音に悩んでいる、何とか噛まないようにしたい!という方は以下のエントリを参考にしてみる事をお勧めします) [小ネタ]噛まずにImmutable Infrastructureと言うために | Developers.IO さて、本題です。こちらの『Immutable Infrastructure Conference #1』、発表と同時に参加応募者が殺
Immutable Infrastructure Conference #1 : ATND でLTしてきた。 内容はきれいにゴミを捨てましょうという話以上のものは特にない。 背景の説明が少し雑だったので補足すると、Jenkins のジョブスクリプトで、git push する度に docker run していたら ゴミがどんどんたまっていったという感じ。 1 push あたり、アプリコンテナ、DBコンテナとか合わせて3コンテナぐらい起動してるから開発が活発だと、どんどんゴミがたまる。 さらに補足すると、Device mapper がらみのゴミは、aufs 使うとかなり解決できそうな感じはしてる。 (Device mapper だとブロックデバイスレベルでイメージ差分を表現するので、デバイス毎(差分)毎に mount が走るみたいな実装になってるけど、aufs だとファイルシステム単位で複数の
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド
何もかも投げ棄てて Dark Souls II をやりたい気持ち抑えながら JAWS DAYS 2014 で Immutable Infrastructure について話してきました。以下、資料です。(Embed できないのでリンクです) https://speakerdeck.com/naoya/immutable-infrastructure-number-jawsdays Immutable Infrastructure トラックのトップバッターだったので、そもそも Immutable Infrastructure とは何か、どのような背景でこのような概念が提唱されるに至ったのか、そして現在は。またこれから何が変わるのかみたいな、大枠の話にフォーカスして話しました。会場は Immutable Infrastructure トラックは立ち見が出てるくらい盛況で、やはりこの分野に注目が集
昨年からImmutable Infrastructureという言葉が出始めて、サーバーを簡単に作って壊すという潮流が出始めました。また、サーバー管理を簡単にするツールとしてDockerというものが脚光を浴びており、いまどきのサーバー管理者に受け入れられてきました。 今回は、そのDockerをインストールしてLAMP環境を構築するステップを見ていきたいと思います。 Immutable Infrastructureとは? IaaS型のクラウドやVPSの台頭によって、簡単に仮想サーバーが立ち上げられる環境が整ってきました。 とはいえ、サーバーの立ち上げをするのはシステム構築時と、システム規模を大きくする時に限られ、サーバーの動作を変えたり、アプリケーションのアップデートをするときは、稼働しているサーバーの中身を修正するというのが従来のやり方でした。 しかしImmutable Infrastruc
継続的デリバリ/デプロイを実現する手法・ツールまとめ:DevOps時代の開発者のための構成管理入門(終)(1/2 ページ) バージョン管理や継続的インテグレーションとも密接に関わる継続的デリバリ/デプロイメントの概要や主なツール、経緯、実践事例を紹介。実践手法として「ブルーグリーン・デプロイメント」「Immutable Infrastructure」が注目だ。 完全に自動化されたリリースプロセスが必要となる「継続的デリバリ」とは いよいよ本連載「DevOps時代の開発者のための構成管理入門」も最終回となりました。今回のトピックは「継続的デリバリ」です。 継続的デリバリは、本連載で扱ってきたバージョン管理や継続的インテグレーションなどの単一のプラクティスではなく、それら一連のプラクティスを包含した、ソフトウェアデリバリ全体に対しての「考え方」「アプローチ」といえるものです。 「継続的デリバリ
年末にDocker触ってて、これをうまく活かせば、副作用を無視した使い捨てのテスト環境が作れるんじゃねーかな、という意識が高まったのですが、手を付けられずにうにゃうにゃしてました。 そうこうする内に yahooのデベロッパーの方からJenkins with Dockerというタイトルの発表があり、ほぼ僕のやりたい事のベースができていたので、これをforkして、travis.yml parserや若干のバグフィックスを入れてもう少しだけTravisに近づけてみました。 ちなみにこれは 社内 Immutable Infrastructure ハッカソンした時の成果物です。 Immutable Infrastructure Hackathon at :D を開催したら、configspec の敷居が高いのでコミッタになっていました - sonots:blog 今回の成果物に関して、詳しくはここを
あけましておめでとうございます。バズワード評論家 横田でございます。(恐らく)皆様1月6日から出社ですね。お仕事がんばりましょう。 というわけで今年のインフラ業界のバズワードトレンドをまとめてみました。年始の仕事前にどうぞ 《Blue-Green DeploymentとImmutable Infrastructure》今年のインフラ業界の一番のトレンドは「Blue-Green Deployment」と「Immutable Infrastructure」となる気がしています。今までは、サーバの設定を変更する時は、運用中のサーバを変更していましたが、「Blue-Green Deployment」と「Immutable Infrastructure」の考え方は、運用中のサーバの変更するのではなく、新しくサーバ群を用意し、本番環境をそちらに切り替えるという手法を取っております。 手法自体は「Blu
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
本稿では、"Immutable Infrastructure"時代におけるconfiguration management tool(以下、CMT)の要件およびそれを満たすツールについて議論する。 背景の整理 "Immutable Infrastructure"とは、2013年6月、Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowlerにより提唱された概念だ。ある種のプログラミング言語における不変性がプログラムにおける厄介な問題を解決するように、サーバの状態を不変な(正確には、状態を変更しない)ものとすることで、成長し続けるソフトウェアにとって避けられない、時間の経過によりもたらされる種々の問題が、解決可能であるとする。 そもそもどのような
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
Immutable (不変な) Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く