Convox
Convox will help your development team ship more features and have happier customers by automating your application deployment and management. Uptime Application downtime hurts your customers and stresses your team. Convox helps your team keep your application up without all the work and time normally required to build resilient infrastructure.
2013年版! SonicGardenにおけるherokuでのサービス運用構成 | mah365
ちょうど去年の今頃、SonicGardenにおけるherokuでのサービス運用構成をご紹介しました。去年の比較して、今ではherokuで本番運用されているサービスも増えているかと思いますが、実際の構成例はあまり紹介されていないようです。去年ご紹介した内容も少し古くなっていますので、2013年バージョンとして、再度ご紹介したいと思います! 去年からの変更点 去年と比較して大きく変わっている点は、以下の3点ですねー。 バックアップ取得方法の見直し & 監視の導入 Route53愛してる! ログ取得のアドオンをPapertrailに変更 バックアップ取得方法の見直し & 監視の導入 @interuが去年のJAWS-UG in Nagoyaで講演したように、「本当にバックアップ取れてるの？」というのは重要な視点ですね! なので、バックアップを取得するところと、監視するところ、セットで構成するように
第11回 Herokuでファイルアップロードを実装しよう | gihyo.jp
はじめに 前回は、Herokuのコマンドの拡張pluginについて解説しました。ちょっとマニアックだったかと思いますが、Herokuのオープンであるというビジョンが見える非常に面白い仕組みだと思います。今回は、マンガ共有サービスの機能を追加したいと思います。Webサービスでは必須の機能のファイルアップロードの仕組みをHerokuを利用する場合どのように実現するかを紹介します。 Herokuでのファイルの扱い Heroku上では、ファイルをサーバ上に保存するということができません。これは、以下の理由からそのようになっていると思います。 Webサーバのインスタンスがどのサーバで動くかが特定できない 複数インスタンスが動いた場合に、同じファイルシステムを共有できない Herokuでは、マルチインスタンスのプラットホームであるためこのような課題が出てきます。この問題をおそらく解決することはできるか
SaaSのインフラをHerokuからAWSへ移行したのは何故か | Social Change!
youRoomは、SonicGardenとして創業した後に企画・開発したサービスです。かなり実験的な要素の濃い事業として開始したのを憶えています。元々はSonicGardenのプログラマたちとのフリーディスカッションの中で、こういうツールがあると良いよねという話をしていて、その話をしていたのが@mat_akiの夏休み前で、その休み明けには、なんとプロトタイプが出来ていたので、じゃぁそのままローンチしようといって始まったのでした。ただローンチするだけでは自分たちがやる意義がないので、幾つかの仮説をもって事業を始めています。このように事業の内容そのものを実験だと考えて、仮説と検証をやっていたのは、今でいえばリーンスタートアップでした。つまり、どんな新規事業も実験みたいなものなんです。 現在はそこそこ多くのユーザにも使って頂いているyouRoomですが、youRoomをローンチする際に立てたコン
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、... - Sooey
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、である」調にしたため多少偉そうに見えるかもしれませんが、原文はとても誠実な表現で書かれていますので、その点は誤解なきよう。 一部、文意が汲めなかった部分は原文を併記していますので、ご意見・ご指摘などがありましたら@junyaまでお願いします（@irohirokiさん、アドバイスありがとうございます）。 Resolved: Widespread Application Outage Herokuを4年間運用してきて最大の障害 専用データベースを利用している大規模アプリケーションでは最大16時間のダウンタイム 共有データベースを利用している小規模アプリケーションでは最大60時間のダウンタイム アプリケーションのデプロイについてはプラットフォームの広範囲にわ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
