フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
![Infrastructure as Code](https://cdn-ak-scissors.b.st-hatena.com/image/square/b902b87c9a0c35ef7be4c39419013b289418459f/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F12df6cac4d514ff8bb9b7e3762be6e2c%2Fslide_0.jpg%3F6556638)
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
ブログからの引用です。ブログはこちら 今回はアーキテクチャパターンとかリファクタリングで有名なMartin Fowler氏のブログであげられていた "InfrastructureAsCode"(原文はこちらを勝手に解釈して意訳してみましたという内容です。 意訳 感想 さっそくいきましょう。 インフラストラクチャーアズコードというのはコンピューティングやネットワークをソフトウェアシステム同じように扱えるようにソースコードを通じて定義するアプローチである。こうしたコードは可監査性やビルドの再現可能性を実現するために管理され、テストの方法や、継続的デリバリーの実現のやり方に依存する。これはクラウドコンピューティングプラットフォームを扱う方法としてここ数十年行われてきた方法だし、これからのコンピューティングインフラストラクチャーを扱う主要な方法である。 私(Fowler氏)は、鉄器時代に育って、当
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す(現在 Early Relase 版や Free Chapters が入手できる)ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く