Agile Cat — in the cloud

Container の調査: エンタープライズ DevOps を実現するためにも、コンテナは不可欠なテクノロジーとなる!

Posted in Container, DevOps, Enterprise Social, On Monday by on February 1, 2016
Containers: Enabling Build-Once-Run-Anywhere Applications
By Dick Weisinger – January 28th, 2016
_ formtek
Containers are stand-alone lightweight packages that provide a isolated environment for an application and its configuration complete with all needed dependencies and libraries.  Containers are easily provisioned in real-time and typically use far fewer resources than virtual machines.
Chagall_5Robert Stroud, Forrester analyst, wrote that “Containers are all the rage!… Container adoption is being driven by the promise that containers deliver the ability to build once and run anywhere, allowing increased server efficiency and scalability for technology managers.”
Forrester のアナリストである Robert Stroud は、「コンテナは、誰もが熱望するものである。そして、コンテナが約束する Build Once and Run Anywhere の能力により、その採用が促進されている。つまり、テクノロジーの管理者から見ると、サーバーを利用する際の、効率性とスケーラビリティが増大することになるのだ」と記している
The results of a survey by Robin Systems being announced today, found that:
今日 (1/28)、Robin Systems がアナウンスした調査結果の、以下の項目に注目したい:
  • Adoption of containers for running enterprise applications is growing.  More than half of enterprises are using containers in production or are experimenting with containers
  • Containers are being used for both stateless and stateful applications
  • Nearly three-quarters of respondents say that containers are the preferred method for running databases, and 40 percent say that it makes sense to use containers to run Big Data applications like Hadoop and Spark.
  • エンタープライズ・アプリケーションを実行する際の、コンテナの採用が増えきてきている。半分以上のエンタープライズが、実運用もしくは実験の環境で、コンテナを利用しているという。
  • コンテナは、ステートレスおよびステートフルのアプリケーションで利用できる。
  • 回答者の約 3/4 が、データベースを実行する際に、コンテナは好ましい手法になると述べている。また、回答者の 40% が、Hadoop や Spark といった、Big Data アプリケーションを運用する際に、コンテナの利用は理にかなっていると述べている。
Partha Seetala, chief technology officer at Robin, said that “containers are a natural platform for running performance sensitive applications such as databases, as they enable consolidation without compromising performance or predictability.  This aligns perfectly with our vision of providing enterprises a high-performance and elastic containerized platform for stateful and mission-critical applications.”
Robin の CTO である Partha Seetala は、「たとえばデータベースなどの、パフォーマンスを考慮しなければならないアプリケーションを実行する際に、コンテナは自然なプラットフォームとなる。予測の能力と性能を犠牲にすることなく、コンテナによる統合が実現されていくにつれて、このような見方が広まってきた。つまり、ステートフルでミッション・クリティカルなアプリケーションのための、高性能で弾力性のあるプラットフォームを、エンタープライズに提供することが不可欠になるという、私たちのビジョンと完全に一致しているのだ」と述べている。
On Monday別件で、5 cloud computing predictions for 2016 という長いドキュメントを訳したのですが、その中でも、エンタープライズにおけるコンテナの利用が、今年のトレンドになると解説されていました。つまり、今年はエンタープライズも、クラウド・ネイティ・ブアプリケーションに突入すると予測しているのですが、そうなるとアップデートのサイクルが、年に数回というレベルから、日に数回というレベルに加速していくと述べているのです。この Dick Weisinger さんのポストでも、コンテナの効率が指摘されていますが、大きく変化していく開発/運用の形態を前提に考えると、その重要性がさらに強く感じられます。 つまり、DevOps にとって、コンテナが不可欠なのです。 _AC Stamp
Business Disruption の調査: すべての企業を破壊していく5つの圧力とは?
Enterprise の調査: クラウド効果により、エンタープライズ・アプリが中小企業に舞い降りてきた
AI の調査: Facebook の 人工知能 について、Mark Zuckerberg は 何を考える?
IoT の調査: この時代に生まれたなら、マック・バーガーの累計表示も頓挫しなかったはずだ!
Social Media の調査: ヘルスケア・ビジネスと、ユーザー接触と、コンプライアンス

Comments Off on Container の調査: エンタープライズ DevOps を実現するためにも、コンテナは不可欠なテクノロジーとなる!

Development の調査:Google の 85TB リポジトリは、20億行のコードで満たされている!

Posted in AI ML, DevOps, Google, On Monday by on November 2, 2015
Software Development: Google’s Code Base Spans More than 2 Billion Lines
By Dick Weisinger – October 30th, 2015
_ formtek
Google online services are powered by more than two billion lines of code, says Rachel Potvin, Google executive.  The services include things like search, maps, Google+, calendar, Gmail and YouTube.  All that code is stored in a single repository and available to all of Google’s 25,000 engineers.
Google のオンライン・サービスは、20億行以上のコードからパワーを供給されていると、Google の幹部である Rachel Potvin は発言している。ここで言うサービスとは、Search/Maps/Google+/Calendar/Gmail/YouTube などを含むものとなる。それらすべてのコードは、シングル・リポジトリにストアされ、Google の 25,000人というエンジニアが、利用できる状態になっている。
Escher_2The source repository used by Google is proprietary, but there are similarities between it and how GitHub works.  The version control system is called Piper.  Unlike repositories like GitHub which house many many individual projects, the Google repository is structured like one massive project.  It’s possible to share code across any number of projects.  Piper also heavily uses automation to monitor consistency and ‘code health’.
この、Google が用いるソース・リポジトリは、プロプライエタリなものであるが、どのように機能するのかという点では、GitHub に類似している。そのための、バージョン・コントロール・システムは、Piper と呼ばれている。 多様で独立しているプロジェクトを収容する、GitHub のようなリポジトリとは異なり、Google のリポジトリは、大規模なシングル・プロジェクトのように構成されている。つまり、あらゆるプロジェクトで、それらのコードを共有できるようになっているのだ。さらに、Piper は、コードの一貫性と健康状態をモニタリングするために、あらゆる側面を自動化している。
Sam Lambert, the director of systems at GitHub, commented on Wired that, “having 25,000 developers, as Google does, means it’s sharing code with a diverse set of people with diverse set of skills.  But, as a small company, you can get some of that same advantage using GitHub and open source. There’s that saying: ‘A rising tide raises all boats.’”
GitHub の Director of Systems である Sam Lambert は、「 Google の 25,000人というような、数多くの開発者を持つということは、多様なスキルセットを持つ、多様な人々の間で、コード・セットを共有することを意味する。しかし、小規模な企業の場合であっても、GitHub とオープンソースを用いることで、同じようなアドバンテージを得られる。つまり、上げ潮は、すべてのボートを浮かべることができるという話だ」と、Wired でコメントしている。
How much storage space do you need to store and version control two billion lines of code.  Google uses about 85 terabytes of storage space and the 25,000 engineers make about 45,000 commits to the repository every day.
20億行のコードをストアし、そのバージョンをコントロールするために、どのくらいのストレージ・スペースが必要になると、あなたは想像するだろうか。Google が使用している、ストレージ・スペースは約 85 T Byte になる。 そして、25,000人のエンジニアが毎日のように、そのリポジトリ向けて、45,000回もコミットしているという。
It’s interesting to compare the size of Google’s repository to other code bases, like Linux or the Windows OS.  Linux is only 15 million lines and Windows is about 50 million.  15 million lines of code is about how much code is touched by Google engineers every week.
この、Google リポジトリの規模を、Linux や Windows OS などのコードベースと比較することは、とても興味深いことである。Linux は、わずか 1,500 万行であり、Windows は約 5,000万行である。 1500 万行のコードというと、Google のエンジニアたちが、一週間でが更新するコードの量に等しいのだ。
On Monday20億行のコードと、85 TB のリポジトリと言われても、あまりにも大きすぎて、ピンときませんね。このリポジトリについて検索してみたら、RankBrain という検索のための人工知能/機械学習システムは分離されているとか、Android と Chrome は別のバージョン・コントロールになるとか、、、そんな話が Wired に掲載されていました。それと、25,000人のエンジニアというのも、かなりの規模だと思います。 従業員数は 50,000人弱なので、半数以上がエンジニアという計算になります。ちなみに、Microsoft の従業員数は 99,000人とのことですが、どれくらいのエンジニアが、その中に含まれるのでしょうかね? また、Apple は 80,000人とのことですが、半数以上がショップの店員だそうです(Wired)。それぞれの業態が反映されていて、なかなか面白いですね。_AC Stamp
Innovation の調査: ビジネスとテクノロジーを破壊/再生していく四大要因とは?
Cloud の調査: クラウド・ポリシーの運用に関して、適切な戦略をもつ企業は1%にすぎない
Quanta の コンバージド・インフラが登場:OpenStack/VMware/Microsoft に対応!
CloudFlare は ”Cisco as a Service” :Google/Microsoft/Baidu/Qualcomm が支援!
Cisco が Piston を買収:OpenStack は Intercloud を構成する重要なパートだ!

Comments Off on Development の調査:Google の 85TB リポジトリは、20億行のコードで満たされている!

Enterprise Mobile App の調査:情シスのキャパに対して、モバイル開発は5倍のスピードで突っ走る!

Posted in DevOps, Enterprise Social, Mobile, On Monday by on August 10, 2015
Enterprise Mobile App Development: Growing 5x Faster Than IT Can Respond
By Dick Weisinger – August 6th, 2015
_ formtek
Demand for enterprise mobile applications is expected to grow five times faster than the ability of IT organizations to respond between now and the end of 2017, according to Gartner.  The growth is being fueled by the rapid increase in number of mobile phone devices which is expected to reach 2.1 billion units by 2019.
エンタープライズ・モバイル・アプリに関する需要だが、これから 2017年末までの間において、IT 組織の許容力と比べて、5倍というスピードで成長していくと、Gartner は予測している。この成長は、2019年まで 21億台に達すると予想される、モバイル・フォンの急激な増加により加速していく。
Dali_5Today employees typically use three different devices on a daily basis, but trends like Internet of Things (IoT) and wearable devices are expected to increase the number of devices used daily to five or six devices.
今日において、一般的な企業などに属する従業員たちは、日常的に 3種類のデバイスを使用している。しかし、IoT および Wearable デバイスといったトレンドにより、前述のデバイス数は5種類〜6種類ほどに増加すると予想される。
Adrian Leow, principal research analyst at Gartner, said that “organisations increasingly find it difficult to be proactive against competitive pressures, which is resulting in their mobile apps becoming tactical, rather than strategic.  We’re seeing demand for mobile apps outstrip available development capacity, making quick creation of apps even more challenging. Mobile strategists must use tools and techniques that match the increase in mobile app needs within their organizations.”
Gartner の Principal Research Analyst である Adrian Leow は、「 競合のプレッシャーに対して、先回りして戦っていくことの困難さに、直面する企業が増加していくだろう。言い換えれば、モバイル・アプリに求めるものが、戦略的というより、戦術的なものになってきているのだ。つまり、モバイル・アプリに対する需要が、調達できる開発能力を上回るという現実に、私たちは直面しているのだ。その結果として、短時間でアプリを開発することが、ますます困難になってきている。モバイル戦略家たちは、組織内で必要とされるモバイル・アプリの増加に適合するように、ツールやテクニックを活用していかなければならない」と述べている
In order to be able to keep up with mobile app demand within organizations, Gartner recommends:
組織内で増大していくモバイル・アプリの需要に対応していくために、以下の能力を獲得すべきと、Gartner は推奨している:
  • Make Application Development a high priority for the business
  • Adopt a bimodal approach
  • Use rapid development app development tools
  • Supplement in-house development skills with outsourcing
  • モバイル・アプリ開発の優先順位を、ユーザー企業内で高めていく
  • 多様性のあるアプローチを適用する
  • 迅速なアプリ作成を可能にする、適切な開発ツールを採用する
  • 社内開発のスキルを高めながら、アウトソースも活用する
On Mondayサービス/プロダクトの供給という側から見て、この5年の間に、最も大きく変化してきたのがモバイル開発なら、最も保守的に進んできたのが情シスなのかもしれません。 それぞれの社会における役割が異なるため、このような比較自体に意味はありませんが、モバイルを取り込まざるを得ないという現実が、エンタープライズに対して大きな変化を要求しています。 そうなると、情シスにとっても、モバイル対策が欠かせなくなってきます。 どのようにしたら、両者を隔てる深い溝が埋まるのでしょうか? 考えるべきことが、たくさん有りそうですね。_AC Stamp
IT as a Service の調査:クラウドと情シスの、新しいコンペのスタイルになるのか?
Hardware の調査:IoT によるイノベーションは、新たなハードウェアが具現化していく
Future Growth の調査: 大半の CEO たちが、テクノロジーを最重要視している
IoT の調査: 各種デバイスが生成するデータの、90% 以上が廃棄されているという現実
Data Warehousing の調査: Snowflake が、Azure と AWS にガチンコ勝負を挑む

Comments Off on Enterprise Mobile App の調査:情シスのキャパに対して、モバイル開発は5倍のスピードで突っ走る!

Microservices の調査 におけるマイクロサービス・アーキテクチャとは?

Posted in Amazon, DevOps, On Monday by on May 11, 2015
Microservices: The Rise of the Minimal Component Architecture
By Dick Weisinger – May 8th, 2015
_ formtek
Microservices are lightweight fine-grained services that can be deployed with middleware or brokers.  The idea behind the approach has been around for some time, but a convergence of technologies, like the cloud, containers and REST/JSON services is making the approach more possible to achieve.
Microservices とは、ミドルウェアやブローカーを用いてデプロイすることが可能な、軽量で粒度の細かなサービスのことである。このアプローチの背景となる発想は、ときおり目にすることができるが、クラウドおよびコンテナや REST/JSON といった集約型テクノロジー (convergence of technologies) を、より現実的なものにするための方式だと言える。
Rather than build monolithic applications using “big balls of mud with tangled spaghetti code“, a microservice architecture builds many small and focused components that can easily communicate with each other.
Dali_11つまり、「もつれたスパゲッティ・コードによる大きな固まり」を用いて、モノリシックなアプリケーションを構築するのではなく、コンポーネントにフォーカスした Microservice アーキテクチャにより、小規模なコードを構築することで、簡潔に相互通信させていこうという考え方に基づいている。
Owen Garrett, head of product for Nginx, recently described how Amazon is using microservices.  ”When you go to and type in Nike shoe, over 170 individual applications get triggered potentially from that search — everything from pricing to images of the shoes to reviews of the shoes to recommendations of other products you may want to purchase. Each of those were individual services or subfeatures, if you like, of an application or an overarching experience, and all those were connected via HTTP. Each might be built in different languages. Each of those may have different requirements in terms of the data store, in terms of scaling and automation. Those were the attributes that we saw that were the fundamental anatomy of microservices architecture.”
最近のことだが、Nginx の Head of Product である Owen Garrett が、Amazon も Microservices を活用していると記している。具体的に言うと、「 で Nike shoe とタイプすると、170 種類以上のアプリケーションが、起こりうる検索のためにトリガーされる。それにより、探しているクツの価格や画像といった情報から、購入する可能性のあるプロダクトに関するレビューやリコメンデーションに至るまでの、あらゆる可能性がカバーされることになる。 つまり、それぞれのトリガーされたコンポーネントは、あなたの好みのものを探すための、アプリケーションもしくは包括的なエクスペリエンスにおける、個々のサービスやサブ機能といったものであり、そのすべてが HTTP を介して接続される。また、それらが、同一の言語で構築されているとは限らない。さらに言えば、データストアの観点や、スケーリングと自動化の観点において、それぞれの要件を有する可能性もある。それらは、私たちが確認できる特性であり、また、Microservices アーキテクチャの基本的な解剖学だ」と述べている。
Benefits of the microservices approach include scalability, agility, and greater resilience.  More specifically, microservice benefits include:
Microservices アプローチのメリットそしては、スケーラビリティとアジリティに加えて、高度な弾力性が挙げられる。 それらを具体化すると、以下のようになる。
  • Individual components have simpler architecture and design
  • Each component can be built using the right tools and language for the task
  • The design promotes loose coupling and easier maintenance
  • Promoted distributed independent parallel product development
  • Works well alongside new technologies, like Docker
  • それぞれのコンポーネントは、シンプルなアーキテクチャとデザインを有する。
  • それぞれのコンポーネントは、そのタスクに応じた適切なツールと言語で構築できる。
  • そのデザインにより、疎結合の考え方と、容易なメンテナンスが促進される。
  • さらに言えば、自律分散型の開発が、平行していて進められるようになる。
  • そして、たとえば Docker のような、新たなテクノロジーとの協調が実現される。
Eric Knorr, writer at InfoWorld, wrote that “the payoff [of microservices] is manifold: Services can be updated individually, new applications can be built quickly from existing services, and management actually has greater visibility into who is responsible for what.”
InfoWorld のライターである Eric Knorr は、「 Microservices から得られるものは多様である。 つまり、それぞれのサービスを個別にアップデートすることが可能であり、また、既存サービスから新しいアプリケーションを迅速に構築することが可能であり、誰が何に対して責任を負うかという意味で、可視性の高い管理が可能になる」と記している
On Mondayたしかに、Amazon で探しものをしていると、かなり昔の探しものとの関連性や、ちゃんとカテゴライズされた関連性が生きているという感じで、レビューやリコメンデーションが登場してくるので、ちょっと驚くことがありますが、それが Microservices の威力なのでしょう。 もちろん、それは以前から言われてきた考え方であり、理屈の上で優位性が論じられてきたものなのですが、このように説明してもらえると、とても分かり易いですね。_AC Stamp
Cloud Developer の調査: あなたは DevOp 派? Coder 派? それとも RAD 派?

Comments Off on Microservices の調査 におけるマイクロサービス・アーキテクチャとは?

Cloud Developer の調査: あなたは DevOp 派? Coder 派? それとも RAD 派?

Posted in .Selected, DevOps, On Monday by on April 27, 2015
Cloud Developer Profiles: Are you a DevOp, Coder, or RAD?
Dick Weisinger – April 22nd, 2015
_ formtek
So, you’re a developer, but which cloud platform is best for you?
Forrester says that depends.  They’ve developed three different developer profiles of different developer types and the types of cloud environments that work best for each type.
Forrester の言い方を真似するなら、そこには三種類のデベロッパーがいて、それぞれが異なるプロファイルを有している。つまり、彼らが働きやすい、三種類のクラウド環境が存在することになる。
Chagall_1Some developers are heavy into Java, Ruby or C# code, while others might prefer quick-and-dirty scripting.  Some developers love working with lots of configuration, others want point and click environments.  Forrester profiles, based on developer methodologies, recommend cloud platforms based on your development style.  Forrester identified three different developer classifications.
一部のデベロッパーたちは、Java/Ruby/C# といったコードに没頭するが、安かろう悪かろうのスクリプトを好む人もいる。 一部のデベロッパーたちは、大量のコンフィグレーションも苦にしないが、お手軽な環境を望む人もいる。 Forrester は、こうしたデベロッパーたちの方法論をベースにして、あなたの開発スタイルに合ったお勧めクラウド・プラットフォームをプロファイル化している。Forrester は、デベロッパーたちを、三種類に区分している。
  • Coders don’t want to muck with mucking with infrastructure configurations and would prefer an environment where those details were pre-configured.
  • Corder は、インフラスのコンフィグレーションで手を煩わすのを嫌い、それらの詳細が、プリ・コンフィグレーションされた環境を好むだろう。
  • DevOp pros tend to use the command line heavily, write scripts, and work with server, database, network, and storage configurations.
  • DevOp pros は、コマンド・ラインを駆使してスクリプトを書き、サーバー/データベース/ネットワーク/ストレージをコンフィグレーションしていく傾向がある。
  • RAD developers love point and click and every chance they get to auto-generate some code.  They’re into doing things fast, with an emphasis on not only high velocity and quantity, but also quality.
  • RAD developers は手軽さを好み、あらゆるチャンスを見つけては、コードを自動生成していく。 彼らは、迅速さと量的な観点からだけではなく、品質を維持しながら、素早く開発することに興味を持つ。
The Forrester report found that “Public cloud platforms take several forms, including those providing basic infrastructure-as-a-service up through those providing full or partial platform services and tools. Each of these types of platforms is best suited to a distinct type of application development and delivery (AD&D) pro within your ranks… AWS, Microsoft, and Salesforce are each leaders in meeting CIO requirements.  Each of these vendors started its cloud-platform journey in a distinct position serving a specific developer type and has expanded its offerings to provide greater breadth to a wider range of developers and support for a larger catalog of application types. Across all four Forrester Wave comparisons, two vendors stood out as consistent and clear leaders, while another, AWS was a leader across three of the four segments.”
こちらの方の Forrester レポートは、「パブリック・クラウド・プラットフォームには、いくつかの形態がある。その中には、全体的あるいは部分的な、プラットフォームのサービスやツールの提供を介して、基本的な IaaS を提供するものも含まれる。それぞれのプラットフォームが、あなたが位置づける AD&D (application development and delivery) に応じて、最適なタイプとなる。そして、こうした要件を満たす CIO にとって、AWS/Microsoft/Salesforce がリーダーとなっている。それらのベンダーは、こうしたデベロッパーのタイプに応じて、それぞれのサービスを提供するというポジションから、クラウド·プラットフォームへと旅立っていった。そして、自身を拡張することで、デベロッパーたちを幅広く支援し、大規模なアプリケーション・タイプをサポートしてきた。この Forrester Wave における 4つの区分で比較すると、2つのベンダーは、一貫性と明確性を備えたリーダーとして際立っていた。その一方で、AWS はというと、4つのセグメントにおける、3つの区分でリーダーとなっていた」と指摘している。
Further, the report notes that “the popular wisdom that cloud computing comes in three flavors — Software-as-a-Service (SaaS), IaaS and PaaS — no longer describes reality. We find that vendors are blurring the lines between the three cloud-computing categories.”
そして、このレポートは「クラウド・コンピューティングを、3つのフレーバーである IaaS/PaaS/SaaS で分類するという考え方は、もはや、現実味を伴っていない。つまり、この 3つのカテゴリーを区分する境界線を、ベンダーたちが曖昧にしている点に、私たちは気づくべきだと」と述べている。
Forrester WaveOn Monday訳す前は、3つの分類と 4つの分類で混乱してしまい、全体の意味がつかめなかったのですが、4つの分類の方は、この図のことを指しているようです(クリックで拡大)。文中の、2つ目のリンクから無償で DL できるレポートなので、お時間のある方は、ぜひ、ご参照ください。そして、この記事ですが、「デベロッパーのタイプに応じて、クラウドのタイプを再編しても良いだろう」と、Weisinger さんは言いたいのでしょうかね? 関連性を説明しない、まったく異なる 2つの文脈が並んでいると、そうとしか受け取れませんよね 🙂 それぞれのベンダーが、クラウドに取り組み始めた時点と比べて、デベロッパーのタイプも大きく変化しているわけですし、ここらで再編した方が、スッキリするようにも思えます。この世で最も強いのは、プラットフォームでもなく、ベンダーでもなく、エコシステムなのですから ・・・ _AC Stamp
Security の調査:CFO と CIO が協力しなければ、サイバー・アタックを迎撃できない!

Comments Off on Cloud Developer の調査: あなたは DevOp 派? Coder 派? それとも RAD 派?

Windows の OSS 化:ChefCon で Mark Russinovich が爆弾発言

Posted in .Chronicle, .Selected, DevOps, Microsoft, Strategy by on April 8, 2015
Microsoft mulls an open source Windows
Senior engineer spills the beans at ChefCon.
Russell Brownon – Apr 7, 2015,xxxxx.aspx
_ it news
A senior engineer from Microsoft has hinted that the company could one day open source the entire Windows operating system.
Microsoft のシニア・エンジニアが、Windows オペレーティング・システム全体に関するオープンソース化について、いずれは実現するかもしれないと示唆している。
Mark Russinovich, a Microsoft technical fellow and senior engineer, dropped the bombshell in front of several hundred people during a panel discussion at the ChefCon DevOps conference in the United States.
Microsoft の Technical Fellow and Senior Engineer である Mark Russinovich が、United States で開催された ChefCon DevOps カンファレンスのパネル・ディスカッションで、数百人の聴衆を前にして、この爆弾を落とした。
Russinovich told the crowd it was “definitely possible” that Microsoft could, in the future, choose to open up the Windows source code.
Microsoft が将来的に、Windows ソースコードのオープン化を選択することは、「可能性として間違いなく有り得る」と、Russinovich は聴衆に語っている。
“It’s a new Microsoft,” he said.
そして、「それが、新しい Microsoft だ」と、彼は付け加えている。
ChefConThe prospect is not as surprising as it might once have been. Last November, the company announced plans to open source the full server-side .NET core stack and bring the open-sourced .NET core to Linux and Mac OS X – with everything happening in plain view on code repository GitHub.
こうした見通しは、これまでの経緯をみれば、それほど驚くべきことではない。 昨年の 11月に同社は、サーバー・サイドの .NET Core Stack を完全にオープン・ソース化し、その .NET Core を Linux および Mac OS X 上に提供するという、計画を発表している。さらに言えば、コード・リポジトリである GitHub 上で、すべての計画は進められるようだ。
The company now has more than 1000 software repositories on GitHub, but until now Windows, a US$4 billion (A$5.27 billion) a quarter cash cow, has looked untouchable.
現時点において同社は、GitHub 上に 1000 以上のソフトウェア・リポジトリを有している。しかし、四半期で US$4 billion ものキャッシュを稼ぎだす Windows は、そうならないだろうと、これまでは推測されてきた。
Russinovich asked for a show of hands from the audience on how many attending solely ran Windows. One single hand was raised from a crowd of hundreds.
Russinovich は、Windows の利用率を確認するために、聴衆に挙手を求めたが、数百の手が挙がるという結果が示された。
Russinovich – Microsoft’s chief technical officer of Azure – said in the company’s cloud computing service, almost 20 percent of virtual machines are Linux already.
Microsoft PDC
Microsoft Azure の CTO でもある Russinovich は、同社のクラウド・コンピューティング・サービスに関して、ほぼ 20% の仮想マシンが、すでに Linux で動いていると述べている。
He acknowledged that in the past it “would have freaked people out to think about Microsoft running Linux in our cloud”.
これまでも、「私たちのクラウドで、Microsoft が Linux を走らせることに、とても熱狂する人々がいる」と、彼は認めていた。
“Every conversation you can imagine about what should we do with our software — open versus not-open versus services — has happened,” he said. “It’s really a matter of choice. We’re going to continue to innovate and deliver cool stuff in Windows [while] we see customers that are making other choices.”
「 みなさんがイメージする、すべてのディスカッションにおいて、Open 対 Not-Open 対 Services という議論が生じている。それは、まさに選択の問題だ。 私たちは、さらにクールな Windows を目指して、イノベーションを継続していくが、他の選択肢を望むカスタマーがいることも知っている」と彼は発言している。
While developers were absorbing the news, Microsoft’s founder Bill Gates sent an open letter to the company’s staff as part of its 40th anniversary celebrations urging them to focus not on Microsoft’s legacy, but on its future.
このニュースに、デベロッパーたちは夢中になっている。その一方で、Microsoft の Founder である Bill Gates は、40周年の祝辞の一環として、全社員に公開書簡を送っている。そして、その内容はというと、Microsoft の歴史にではなく将来に対して、集中を促すものになっている。
Amid the birthday celebrations, the company confirmed the last few hundred of the 18,000 layoffs it began making last year.
こうした、お祝いムードの中で、昨年から進められている 18,000人 のレイオフの、最後の数百人が確定するという現実もある。
Copyright © . All rights reserved.
MS昨年の 11月3日に、「Microsoft の決断:フル .NET サーバー・コア・スタックをオープンソース化する!」という抄訳をポストしていますが、それもオーストラリアの iT News でした。そして、今回の Open Windows というニュースですが、、、Microsoft は Office 365 などにより、本質はサービスに有りという路線へ、すでに転換していると推測できます。 もちろん、手元のデバイスに価値が無いという話ではありませんが、Apple が主張する価値というより、Google の考え方に近いところへと、移行を完了しているように思えます。 それにしても、Mark Russinovich さんは、いつも歯切れがよくて、ナイスですね! これからが、とても楽しみです。 _AC Stamp
Microsoft と IBM が、きわめて広範囲におよぶ、クラウドの提携を発表!

Windows XP のサポートが終わるが、あの緑の草原も、いまはブドウ畑に・・・

Comments Off on Windows の OSS 化:ChefCon で Mark Russinovich が爆弾発言

Facebook と Open Source:大活躍した 2014年の成果をリストアップ!

Posted in DevOps, Facebook by on March 11, 2015
Facebook’s 2014 Open-Source Highlights
David Cohen on December 23, 2014
_ Social Times
Facebook OSS2014 was a big year for open-sourcing at Facebook, and the social network presented its highlights in that sector for the year in the form of a 12 Days of Open Source blog post by head of open-source projects James Pearce.
Facebook のオープン・ソースにとって、2014年は Big Year であった。そして、このソーシャル・ネットワークは、Head of Open-Source Projects である James Pearce のブログ・ポスト 12 Days of Open Source で、この年のハイライトを発表した。
Pearce highlighted:
  • React won a photo-finish over HHVM to become the first Facebook flagship open-source project to reach 10,000 stars on GitHub, with both achieving the milestone on the same day. Next up on that list, according to Pearce: Pop.
  • React は、大接戦の末 HHVM を上回り、ついに Facebook のフラッグシップ・オープンソース・プロジェクトとなった。どちらも同じ日に、GitHub で 10,000 Star を獲得するという、マイルストーンを達成している。Pearce によると、このリストで次に続くのは Pop となる。
  • Facebook launched 107 new open-source projects in 2014, totaling 65,000 stars on GitHub and more than 6,000 forks.
  • Facebook は、2014年に 107 のオープン・ソース・プロジェクトを新たに立ち上げ、GitHub 上で 65,000 Star を獲得し、6,000 以上のフォークを生み出した。
  • The top five open-source projects in terms of stars on GitHub were: Pop (more than 9,000 in just eight months), Shimmer, immutable-js, AsyncDisplayKit and Flow, with honorable mentions going to osquery, Flux, Tweaks, Bolts, KVOController, WebScaleSQL, Proxygen, Chisel, Jest and fb-flo.
  • それまでの GitHub では、Pop (8ヶ月で 9,000+ Star を取得)、Shimmer、immutable-jsAsyncDisplayKitFlow が、Top-5 を形成していた。そして、osqueryFlux、Tweaks、Bolts、KVOController、WebScaleSQLProxygen、Chisel、Jest、fb-flo などが、あとに続いていた。
  • Pearce called out the following collaborators and users on certain projects: React (Adobe, Khan Academy, Pinterest), Rebound (Flow, Jelly, Tumblr), HHVM (Baidu, Box, Wikipedia) and Presto (Airbnb, Dropbox, Netflix).
  • Pearce が言うには、いくつかのプロジェクトでは、以下のような協力者とユーザーがいる:React (Adobe, Khan Academy, Pinterest)、Rebound (Flow, Jelly, Tumblr)、HHVM (Baidu, Box, Wikipedia)、Presto (Airbnb, Dropbox, Netflix)。
  • More than 1,000 external developers contributed to Facebook’s open-source projects in 2014, with 200 making five or more commits.
  • 2014年の Facebook オープン・ソース・プロジェクトには、1,000人以上の外部デベロッパーがコントリビュートし、200人が 5つ以上をコミットしている。
  • More than 5,500 pull requests were made on the social network’s open-source projects in 2014.
  • このソーシャル・ネットワークのオープン・ソース・プロジェクトでは、2014年に 5,500回以上のプル・リクエストが発行されている。
  • There were more than 28,000 commits on Facebook’s public projects in 2014, and more than 17 percent of those came from external developers, with projects such as PHP SDK and React seeing nearly one-half of their commits come from external contributors.
  • 2014年の Facebook パブリック・プロジェクトには、28,000以上のコミットを受け付けており、そのうちの 17% 以上は、外部デベロッパーからのものであった。PHP SDK と React などのプロジェクトを含めると、約半分のコミットが外部コントリビューターからのものとなる。
  • The top five external contributors in 2014 were: Ben Alpert (399), Tim Siebels (137), Joerg Maier (98), Ankit Gupta (87) and Cheng Lou (81).
  • 2014年における、外部コントリビューターの Top-5 は、Ben Alpert (399)、Tim Siebels (137)、Joerg Maier (98)、Ankit Gupta (87)、Cheng Lou (81) である。
  • The two security-related releases in 2014 were osquery and Conceal.
  • 2014年の、セキュリティに関するリリースは、osquery と Conceal の 2つである。
  • Developers from Facebook spoke at seven Open Source Convention (OSCON) sessions in 2014.
  • 2014年の  Open Source Convention (OSCON) では、Facebook のデベロッパーが、7つのセッションを担当した。
  • The average age of pull requests decreased by three times in 2014.
  • プル・リクエストの平均間隔は、2014年に 1/3 にまで短縮された。
facebookFacebook のオープンソースというと、古いポストになりますが、2010年の「Facebook を 1.8 倍速に、WordPress を 2.7 倍速にする、HipHop とは ?」が強烈な印象として、記憶に残っています。そして、それが、HipHop Virtual Machine(HHVM)として活躍し続けているのを、このポストで知りました。 ほんと、Facebook はオープンソースの宝庫であり、素晴らしい活動を継続していると思います。 ちょうど昨夜から(3/10〜3/11)、Open Compute Project Summit 2015 も開催されています。 今年は、ちょと事情があって参加できませんでしたので(涙)、これから Web で追いかけてみたいと思っています。_AC Stamp
Facebook の 超絶 Web パフォーマンス : その秘密を解析する
Google App Engine が PHP をサポート:75% の Web をカバーしているから
Facebook が発表した Folly は、宝石のような オープンソース C++ ライブラリ
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
Facebook 第四艦隊 Iowa DC が、ネットワーク・アーキテクチャを刷新して出撃!

Comments Off on Facebook と Open Source:大活躍した 2014年の成果をリストアップ!

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC by Agile Cat on December 11, 2014

Facebook Mobile Drops Pull For Push-based Snapshot + Delta Model
Monday, October 20, 2014

We’ve learned mobile is different. In If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong we learned programming for a mobile platform is its own specialty. In How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks we learned bandwidth on mobile networks is a precious resource.

私たちは、モバイルが別の世界のものであることを学んできた。If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong では、モバイル・プラットフォームのためのプログラミングが、独特のものであることを知った。そして、How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks では、モバイル・ネットワークの帯域幅が、きわめて貴重なリソースであることを学習した。

Given all that, how do you design a protocol to sync state (think messages, comments, etc.) between mobile nodes and the global state holding servers located in a datacenter?

それら、すべてのことを考慮して、ステート(メッセージやコメントなど)をシンクさせるためのプロトコルを、どのようにデザインすべきなのだろうか? ここでは、複数のモバイル・ノードと、データセンターのサーバーに置かれたグローバル・ステートの、同期について考えていく。

Facebook recently wrote about their new solution to this problem in Building Mobile-First Infrastructure for Messenger. They were able to reduce bandwidth usage by 40% and reduced by 20% the terror of hitting send on a phone.

最近のことだが、Facebook の Building Mobile-First Infrastructure for Messenger というポストにおいて、この問題に関する彼らの新しいソリューションが紹介されている。それによると、帯域幅の使用率が 40% まで、そして、スマホでの送受信を阻害する要因が 20% まで、削減できたという。

That’s a big win…that came from a protocol change.


<関連> Facebook が語るモバイル・チューニングの極意

Facebook Messanger went from a traditional notification triggered full state pull:

The original protocol for getting data down to Messenger apps was pull-based. When receiving a message, the app first received a lightweight push notification indicating new data was available. This triggered the app to send the server a complicated HTTPS query and receive a very large JSON response with the updated conversation view.

Messenger がデータをダウンロードする際の、オリジナルのプロトコルは Pull ベースのものであった。 このアプリはメッセージを受信するとき、新しいデータがあることを示す、ライトウェイトなプッシュ通知を最初に受信する。それは、アプリに対するトリガーであり、その結果として、サーバーへ向けて複雑な HTTPS クエリーを送信し、また、アップデートされた会話を取り込んだ、きわめて大規模な JSON レスポンスを受信することになる。

To a more sophisticated push-based snapshot + delta model:

Instead of this model, we decided to move to a push-based snapshot + delta model. In this model, the client retrieves an initial snapshot of their messages (typically the only HTTPS pull ever made) and then subscribes to delta updates, which are immediately pushed to the app through MQTT (a low-power, low-bandwidth protocol) as messages are received. When the client is pushed an update, it simply applies them to its local copy of the snapshot. As a result, without ever making an HTTPS request, the app can quickly display an up-to-date view.

私たちは、前述のモデルに代えて、Push ベースの SnapShot + Delta モデルに移行することを決めた。 この新しいモデルでは、クライアントは自身のメッセージに関する、イニシャルの SnapShot を取得する(一般的には、これまでの HTTPS Pull のみとなる)。 続いて、Delta アップデートが読み込まれるが、それはメッセージを受信した直後に、MQTT(リソースと帯域において負荷の少ないプロトコル)を介してアプリに Push されるものである。また、クライアントからアップデートが Push されるときには、ローカルに保持される SnapShot に、その内容がコピーされる。その結果として、これまでのような HTTPS リクエストを必要とすることなく、アプリはアップデートされたビューを表示できるようになる。

We further optimized this flow by moving away from JSON encoding for the messages and delta updates. JSON is great if you need a flexible, human-readable format for transferring data without a lot of developer overhead. However, JSON is not very efficient on the wire. Compression helps some, but it doesn’t entirely compensate for the inherent inefficiencies of JSON’s wire format. We evaluated several possibilities for replacing JSON and ultimately decided to use Thrift. Switching to Thrift from JSON allowed us to reduce our payload size on the wire by roughly 50%.

さらに、私たちは、メッセージと Delta アップデートから、JSON エンコーディングを切り離すことで、このフローを最適化した。もし、開発者のオーバーヘッドを最低限に抑えたかたちで、ヒューマン・リーダブルで柔軟なデータ転送を実現するなら、JSON は素晴らしいソリューションとなる。しかし、JSON における送受信の形式は、きわめて効率が悪い。 圧縮により、いくつかの問題は解決するが、JSON の固有の非効率性を、完全に補完することは不可能だ。私たちは、JSON を置き換えるための、いくつかの可能性について評価し、最終的には Thrift を使用することにした。JSON から Thrift へ移行することで、転送における実質的なサイズを、およそ 50% に低減できた。

On the server side Facebook also innovated:

Iris is a totally ordered queue of messaging updates (new messages, state change for messages read, etc.) with separate pointers into the queue indicating the last update sent to your Messenger app and the traditional storage tier. When successfully sending a message to disk or to your phone, the corresponding pointer is advanced. When your phone is offline, or there is a disk outage, the pointer stays in place while new messages can still be enqueued and other pointers advanced. As a result, long disk write latencies don’t hinder Messenger’s real-time communication, and we can keep Messenger and the traditional storage tier in sync at independent rates. Effectively, this queue allows a tiered storage model based on recency.

Iris は、メッセージングのアップデート(新しいメッセージやメッセージ・リードによるステートの変化など)で用いる順列キューのことであり、Massenger アプリに送信された最新のアップデートと、伝統的なストレージ階層において、別々のポインタを持つことが可能になっている。ディスクおよびスマホへのメッセージ送信が成功すると、それに対応するポインタが前進する。もし、スマホがオフラインであったり、ディスクに障害が発生した場合には、対象となるポインタを所定の位置に留めながら、新しいメッセージをキューに保持し、他のポインタを前進させることができる。その結果として、ディスクへの書き込みなどの、大きなレイテンシが発生しても、Messenger のリアルタイム通信を妨げることはない。 そして、Messenger のレベルと伝統的なストレージ階層を、それぞれの頻度で同期させることも可能だ。このキューの効率性により、新しい階層型ストレージ·モデルが実現する。

Delta based syncing strategies are very common in Network Management systems where devices keep a north bound management system in sync by sending deltas. The problem with a delta based approach is it’s easy for clients to get out of sync. What if changes happen at a rate faster than than deltas can be moved through the system? Or queues get full? Or the network drops updates? The client will get out of sync and it won’t even know it. Sequence numbers can be used to trigger a full sync pull if there’s an out of sync situation.

Delta ベースの同期ストラテジーは、ネットワーク・マネージメント・システムにおいて、きわめて一般的なものである。 そこでは、デバイスが Delta を送信することで、上位階層のマネージメント・システムとの同期を維持する。 Delta ベースのアプローチにおける問題点は、その同期のメカニズムから、クライアントが容易に逸脱してしまうことである。 何らかの変更が Delta よりも速く、対象となるシステムを介して移動することが、実際に起こり得るだろうか? また、キューが溢れると、どうなるだろうか? さらに言えば、ネットワーク上でアップデートが失われたら、何が起こるだろうか? いずれにせよ、クライアントは同期から逸脱し、起こっていることを知ることもできない。そのような場合には、シーケンス・ナンバーを用いる。 それにより、完全な同期を引き起こし、同期から逸脱している状況を解消できる。

It’s also good to see Facebook got rid of JSON. The amount of energy and bandwidth wasted on moving and parsing fat JSON packets is almost criminal.

Facebook が JSON から離れることは、別の観点でも歓迎すべきことだ。このような巨大なシステムが、重たい JSON パケットを解析して転送するために、膨大なエネルギーと帯域幅を消費することは、きわめて罪作りなことでもあるのだ。


先日にポストした「Facebook が語るモバイル・チューニングの極意」に続いて、今回も Todd Hoff さんの記事を紹介することができました。途上国におけるモバイル通信の状況を前提とした、ストレスを最小限に抑えた環境を提供したいという、Facebook の一貫したストラテジーが見えてきますね。 ただ、これは、途上国だけの問題ではなく、たとえば日本においても、モバイル・トラフィックの大幅な削減という、大きなメリットをもたらすはずです。 そして、私たちが使用している大半のサービスは、① モバイル・デバイス、② モバイル・インターネット環境、③ バックエンド・テクノロジー、④ データセンター・インフラのバランスの上に成り立っているわけですが、とりわけ途上国においては、① と ② のケアが不可欠なのでしょう。



iOS から Android へ : Facebook は優先順位を切り替えるのか?
Facebook が キャリアの協会に参加 : 狙いは だ!
Mark Zuckerberg と : コネクティビティが社会経済をバランスさせる
Facebook とモバイルの巨人たちが、 を立ち上げた!
Facebook に続け : 10億に挑む Android と iOS

Comments Off on Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

%d bloggers like this: