Cloudの課題を解決する"Local-First"という選択肢（概念編）
私たちはCloudアプリケーションによって、リアルタイムでのCollaboration（共同作業）や複数デバイスからのデータアクセスを可能にしてきました。それはあらゆるデータをサーバに集中させることによって実現していますが、同時にデータのOwnership（所有権）を失っていることを意味します。 もし使用しているサービスが停止してしまったら、そのソフトウェアは機能しなくなり、それまでに作成していたデータは失われてしまいます。 またCloudアプリケーションによって私たちはどこからでもデータにアクセスできるようになりましたが、それは全てサーバを経由する必要があり、データを取得するにはサーバの許可が必要になります。 私たちがデータを他人のコンピュータに保存している以上は、そのデータに対するOwnershipをある程度奪われてしまっていると考えることができます。 Cloudアプリケーションはデー
最近のDHH「サーバーレスをやめろ」 - laiso
(インターネットやめろジェネレーターで作成) Ruby on Rails生みの親であり最強の逆張りおじさんであるところのDHHが昨年あたりからしきりに脱パプリッククラウドの主張をしている。 これは彼らの会社が運用しているBasecampやHEYのインフラをAWSから自社保有のベアメタルサーバーへ移行しようとしているからで、実際に移行作業は進んでおり、今後5年間で700万ドルのサーバー費用を節約できるだろうという見込みがあるようだ。 world.hey.com world.hey.com あとタイトルに「サーバーレスをやめろ」と書いたけどDHHのファンボである筆者の誇張表現であり、サーバーレスというキーワードに関しての言及は正確には以下のポストを読んで欲しい。 world.hey.com この文章における「the computing cycles」とは、一台のコンピュータが持つ計算能力全体を
正しいクラウドはある意味で遅い - Software Transactional Memo
TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは
Edge Runtimeで遊んでみる
Edge Runtime が出た Vercelからいつの間にかEdge Runtimeなるものが出てたので、遊んでみた。 Web標準のAPIを使ったエッジ環境で動くアプリケーションの開発やテストを助けるツールキット。Edge環境はNode.jsじゃないし、evalが使えなかったりするので、それをシミュレートできる。 The Edge Runtime is a toolkit for developing, testing, and defining the runtime Web APIs for Edge infrastructure. 第一行目に「Vercel」とか「Next.js」の文字がないのがよい。とはいえ、一番の想定はVercelのEdge Functionsでしょう。 Edge Functionsってのは今のところ2つあるみたい。どちらもVercelもしくはNext.jsの機
Envoy Proxyに入門した | Folioscope
最近 Kubernetes 周りの技術をよく触るのですが、Envoy Proxy (Envoy)もよく耳にするので勉強しました。 Envoy Proxy Envoy とは？ Envoy はクラウドネイティブな Web サービスのために設計されたロードバランサーです。 元は Lyft が開発しており、現在は CNCF (Cloud Network Computing Foundation) によって管理されています。 Envoy には大きく２つの用途があります。 サービスメッシュの通信バス: サービスメッシュ内の各サービス間の通信を制御するプロキシ。サービスディスカバリーや流量の制御をする。 エッジプロキシ: サービス内のプライベートネットワークとサービス外をつなぐプロキシ。データセンターや Kubernetes クラスタの外からのアクセスを受け付ける。 背景 モノリスで巨大な Web シス
Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluentd Meetupのデモでは9億件を7秒程度で検索していたが、BigQueryの真の実力はこれより1〜2ケタ上だからだ。ちょっと手元で少し大きめのテーブルで試してみたら、120億行の正規表現マッチ付き集計が5秒で完了した。論より証拠で、デモビデオ（1分16秒）を作ってみた： From The Speed of Google BigQuery これは速すぎる。何かのインチキである（最初にデモを見た時そう思った）。正規表現をいろいろ変えてみてもスピードは変わらない。つまり、インデックスを事前構築できないクエリに対してこのスピードなのである。 価格も安い。さすがに120億行のクエリは1回で200円もかかって気軽に実行できなさそうであるが、1.2億
Java開発者が知らないと損するPaaSクラウド8選
Java開発者が知らないと損するPaaSクラウド8選：ユカイ、ツーカイ、カイハツ環境！（25）（1/3 ページ） 進化・激変するJavaクラウドの現状を知る、まとめ 本連載「ユカイ、ツーカイ、開発環境」では、Javaが利用できるクラウドコンピューティングのPaaS環境について、いくつか紹介してきました。最近では、レッドハットの「OpenShift」とヴイエムウェアの「Cloud Foundry」などのPaaSクラウドのβサービスが提供され始め、また、いままで紹介した各クラウドの事情も変わってきました。 本稿では、Javaで利用できる以下の8つのPaaSクラウドの最新動向をお届けします。 機能を拡充し続ける「Google App Engine」 「Stax」はCloudBeesに買収され「RUN@cloud」に Morphの「AppSpace」は「mCloud」に .NETだけじゃない「Wi
実開発で分かったGoogle App Engine for Javaの“すごさ”
ゴールデンウィークに特に予定のなかった筆者は，「ちまたで噂のGoogle App Engine for Java（GAE/J）とFlexでスケジュール共有ツールでも作ってみよう」と思い立ちました。およそ5日間かけて開発を進めたのち，2009年5月6日に「ご都合.com（画面1）」を公開しました。その後，はてなブックマークやニュースサイトなどでご紹介いただいたおかげで，公開後6日で約2000人の方にご利用いただいています。 そこで本稿では，この「ご都合.com」の開発で実際に筆者が得た経験を通じて，GAE/JによるWebアプリケーション開発の実際とそのポテンシャルについて紹介します。 米Googleが2008年4月に発表したGoogle App Engine（画面2）は，「自分が開発したWebアプリケーションをGoogleのデータセンターで運用できるクラウドコンピューティング・サービス」です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
