わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ.タイトルの通り,コンテナのデザインパターンがまとまっていて,これからコンテナ設計をする人も,既にコンテナを運用している人も,デザインパターンを学べるのは価値があると思う.一部ミスリードをしているかもしれない. Design patterns for container-based distributed systems 論文も公開されている. https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern
In the weeks since I started talking about the need to clean up our architecture, I’ve noticed a surprising resistance to the idea. Apparently the notion that it’s a good idea to hide the framework, UI, or database from the application code is not universally accepted. I first blogged about this topic here , I did a whole cleancoders.com episode on the topic. I’ve also done several keynotes on the
UPDATE: I’ve started the Serverless Reference Architectures Project that provides additional context and interactive architectures for some of theses patterns along with code examples to deploy them to AWS. Check it out. I’m a huge fan of building microservices with serverless systems. Serverless gives us the power to focus on just the code and our data without worrying about the maintenance and c
https://starttoday-tech.connpass.com/event/96477/ オウチーノではもともとサービスごとに異なる言語やFWを用いてシステムが分かれており、担当者もそれぞれ別々でした。そのため各サービスに精通した担当者が少なく、担当者は日々の運用で手一杯という状況下で、リプレイスもうまく進んではいませんでした。 そこでリプレイスよりも、分かれているシステムをひとつのモノリシックアプリケーションに集約することで、チームとしてよりワークすることをまずは目指しました。 一方で数多くのサービス機能を集約することは、そのモノリシックアプリケーションが急激に肥大化することも意味します。そこでモノリスにすることでの弊害をなるべく抑えつつ集約していく事例についてご紹介します。
本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ!」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
Go で Network Programming するためのよもやま話 / Network Programming with Go
Have you ever wondered why you are deploying your multi-platform applications using containers? Is it just a matter of “following the hype”? In this article, I'm going to ask some provocative questions to make my case for Why Kubernetes is the new application server. You might have noticed that the majority of languages are interpreted and use “runtimes” to execute your source code. In theory, mos
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
こんにちは。「Neco」の @ueokande です。 サイボウズでは、cybozu.comのアーキテクチャ刷新プロジェクト「Neco」を実施してます。 その思いについては以下の記事からどうぞ。 アーキテクチャ刷新プロジェクト「Neco」の紹介 運用本部長を退任して Neco プロジェクトに専念します 今回は、Necoにおけるネットワーク設計についてお話します。 ネットワークの方針 ネットワークの耐障害性は必須の条件です。 Necoでも同様で、ネットワーク機材の単一障害点が無いネットワーク構成にする必要があります。 具体的には以下のような要件です。 ホストマシンのNICを二重化して、片方のNICが故障しても通信が行えること ネットワークスイッチを冗長化して、スイッチが故障してもスイッチ下のホストが停止しないこと スイッチを冗長化する方法は、以下のような選択肢があります。 STP (Span
AWS Summit Tokyo 2018 で実施されたセッション資料・動画をダウンロードすることができます。(順次公開) ※AWS Summit 2018 へお申し込みいただいていない場合、別途ダウンロード申し込みが必要となります。… 【任天堂様ご登壇事例】Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」AWS はよくわからないので Erlang/OTP 視点のみです。 ejabberdejabberd はフランスの ProcessOne という会社が開発している XMPP サーバです。XMPP が何かはここでは説明しません。 ejabberd は TLS や XML 周りの性能を出すため C で書かれている以外、他はすべて Erlang/OTP で書かれています。 ejabberd の歴史はとても古く、自分が Erlang を学び始めた頃にはすでにありまし
UpdateThis article was published in 2018 and reflects the state of React Native at the end of 2017. When using these articles to make decisions about your business, please use discretion. Any technical points should be revalidated because the maturity and size of the ecosystem was significantly different back then. Any organizational points should also be considered within the context, size, and c
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
Time to “Hello, World”: VMs vs. containers vs. PaaS vs. FaaS Do you want to build applications on Google Cloud Platform (GCP) but have no idea where to start? That was me, just a few months ago, before I joined the Google Cloud compute team. To prepare for my interview, I watched a bunch of GCP Next 2017 talks, to get up to speed with application development on GCP. And since there is no better wa
All slide content and descriptions are owned by their creators.
こんにちは、開発基盤の Taiki です。今回は、マイクロサービスで必須のコンポーネントとなりつつあるサービスメッシュについて、クックパッドで構築・運用して得られた知見についてご紹介できればと思います。 サービスメッシュそのものについては以下の記事や発表、チュートリアルで全体感をつかめると思います: https://speakerdeck.com/taiki45/observability-service-mesh-and-microservices https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc https://istio.io/
2018/04/19 JAPAN CONTAINER DAYS V18.04 (https://containerdays.jp/) にて発表したものを加筆修正しました。 Abstract: Kubernetes は豊富な機能とその高い拡張性により、現実における様々なユースケースに対応できる一方、その多機能さゆえにどう使えば良いか迷っている方もいると思います。Kubernetes の基本を学んだ人や本番運用を始めた人を対象に、私がメルカリでの Kubernetes 本番運用経験を元に考えた、アプリケーション運用、インフラ運用、組織の 3 つの観点での設計の指針を紹介します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く