You Don't Need AWS ~お前にAWSは必要ない~
はじめに タイトルはこちらから拝借しました。この記事は他のパブリッククラウド(Azure, GCP)を薦める記事でもなければ、プライベートクラウドを薦める記事でもありません。また私自身、エンジニアキャリアの中でAWSはたくさん使ってきましたし、今でもソフトウェア開発のわがままに答えてくれる素晴らしいサービスだと思っているので、AWSを貶めるような記事でもありません。むしろ以下に紹介するサービスはAWS上に構築されていることが多く、間接的にもますます世界中の基盤として発展していくはずです。 PaaSアーキテクチャ 前提条件 前提として、現在でも主流なSPAを中心としたフロントエンド、バックエンド、データベースサービスからなるアプリケーションを想定します。 この場合、 フロントエンド → CDN + Static Hosting バックエンド → Container Deploy(Auto S
マイクロソフト、アプリを自動的にDockerコンテナ化してKubernetesへデプロイしてくれる「Draft」をオープンソースで公開
マイクロソフト、アプリを自動的にDockerコンテナ化してKubernetesへデプロイしてくれる「Draft」をオープンソースで公開 マイクロソフトは、アプリケーションを自動的にDockerコンテナとしてパッケージ化し、Kubernetesのクラスタへデプロイしてくれるツール「Draft」をオープンソースとして公開しました。 これは同社が先月買収したばかりのDeis社のエンジニアが開発しているもので、これまで複雑とされていたKubernetesクラスタへのアプリケーションのデプロイの手順を、わずか2つのコマンドで自動化しています。 1つ目のコマンドは「draft create」。このコマンドは、アプリケーションの開発言語を自動的に判別し、それに合わせてDockerファイルを作成、Kubernetes用のパッケージマネージャであるHelmに対応したパッケージングを行います。 現在のところプ
Docker Compose を使った オープンソース PaaS: Paus のご紹介 | Wantedly Engineer Blog
Wantedly インフラチームエンジニアの藤田 (@dtan4) です。今回は、社内で運用している PaaS である Paus の紹介をします。 社内 PaaS の必要性Wantedly ではデプロイ環境として本番環境とステージング環境が用意されていました。ここで、エンジニアが増えるに連れステージング環境の順番待ちが起こるようになってきました。原則として、フィーチャブランチはステージング環境で動作確認をした後本番環境にデプロイすることになっています。そのため、ステージング環境での確認が遅れることは新機能 / 修正のリリース速度低下につながっていました。 また、新サービスを開発する際の動作基盤構築にかかる工数も問題になってきました。従来だと新しいサービス向けの動作基盤を構築するのに丸1日費やしていました。これはリリース前の検証環境においても同様です。このため、メインサービスの www.wa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kubero-dev/kubero: A free and self-hosted Heroku / Netlify / Vercel alternative for Kubernetes
