【技術トレンド】Technology Radar 2015年5月版を読み解く【ThoughtWorks】

都元ダイスケ

2015.05.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

よく訓練されたアップル信者、都元です。ThoughtWorks社のTechnology Radarをご存知でしょうか。

Technology Radar

ThoughtWorks社はグローバルに展開するソフトウェア開発やコンサルティングを行っている会社です。オブジェクト指向やアジャイル開発に数多くの貢献をしている、マーティン・ファウラー氏が所属していることでも有名です。

この会社では年に1〜2回、最近の技術トレンドとなるキーワードをカテゴリ毎にいくつかピックアップし、評価した情報を発信しています。

Technology Radar（以下TR）では各キーワードを「blip」、カテゴリを「quadrant」、評価した結果の位置づけを「ring」と呼んでいます。

quadrants（カテゴリ）

quadrantsは図における上下左右の4象限で表されています。

Languages & Framework（プログラミング言語とフレームワーク）
Tools（DBやバージョン管理等、開発ツール）
Platforms（AndroidやAWS等のプラットフォーム）
Techniques（開発手法）

rings（位置づけ）

各blipは下記の何れかポジションに位置づけて評価します。図における中心からの距離で表されています。

ADOPT （採用せよ） - このトレンドに今すぐ乗るべき
TRIAL （試行せよ） - リスクの低いプロジェクトで採用してみることを推奨する
ASSESS （調査せよ） - 今すぐ採用すべきとは言わないが、注目しておくべき
HOLD （やめとけ） - まだ手をだすべきではない or 致命的な欠陥がある

Technology Radar 2015年05月版

先日、このTRの2015年5月版が発表されました。上図はその俯瞰図です。今回はその内容について、筆者視点で恐縮ですがいくつかピックアップして、簡単にご紹介したいと思います。

ハイライト

まず全体のハイライトから。

まず挙げられているのが「クラウド」の浸透です。多くの組織がクラウドを事実上の標準として受け入れ、アーキテクチャに変革をもたらしています。この変革の流れは、コンテナ仮想化やSDN等と共に、引き続き継続するでしょう。

次に、マイクロソフト社のオープン化について触れています。従来からMSはOSSに関わってはいましたが、ここにきて.NETのプラットフォームとランタイムをGitHubにおいて公開する等、オープン性に対する姿勢に変化が見られるとのことです。

もう一つ、エンプラ分野におけるセキュリティについて触れています。前回のTRでもセキュリティにフォーカスした技術に触れており、この分野に対する関心が高まっています。一方、産業内では目立った進歩が見られないとのことで、引き続き注視していきたい旨が書かれています。

Techniques

Consumer-driven contract tests (ADOPT - 採用せよ)

マイクロサービスの隆盛を受け、システムは小さなサービスコンポーネントに分割統治されていく流れがあります。が、コンポーネント分割の結果、コンポーネント間のインターフェイス（＝契約）が増えていきます。この契約に対するテストはコンシューマ（サービスの利用者側）駆動で行った方が良い、という指針です。

個人的に、テストに関しては明るくないのですが、マーティン・ファウラー氏のスライド Testing Strategies in a Microservice Architecture は面白そうです。

Generated infrastructure diagrams (ADOPT - 採用せよ)

インフラ等の構成図が欲しくなった時、通常は普通にお絵かきをしますが、クラウドを始めとする仮想インフラについては、APIを介してその構造情報を手に入れ、GraphViz等のツールを使って自動生成すべきである。

という話です。理想的ではありますが、図となると自動レイアウトの質感が結局難しいのではないか、と個人的な感覚があります。確かに自動レイアウトはできますし、数学的に調和のとれた図を描画することはできるでしょう。しかし、人間が求める感覚（恐らく図中の文脈を反映した配置）との間にはギャップがあり、見て気持ちのいい図が自動生成できる世界はまだ来ていない気がします。

Phoenix Environments (ASSESS - 調査せよ)

Phoenix serverという言葉があります。要するに、自動化による再現が可能（障害を起こしても復活できる＝不死＝Phoenix）なサーバのことです。AWSにおける、bootstrapパターンによるサーバ構築・運用はまさにこれを実現するためのものです。ChefやAnsibleによる自動化されたセットアップも同様です。

では一方、サーバからもう一段メタな視点を持って、「システム環境全体」についてはどうでしょうか。自動化によって再現可能な環境構築ができているでしょうか。というのがPhoenix Environmentsです。CloudFormationが実現しているのはまさにPhoenix Environmentsです。

筆者の最も気に入っているblipです。

Long lived branches with Gitflow (HOLD - やめとけ)

ある意味当たり前な話ですが、Gitflowモデルを適用するにあたって、feature branchは短時間でdevelopにマージしましょう、という指針です。長時間を掛けてしまうと、マージで死にます。

Platforms

今回、Platformsに関しては、Adoptとされるblipはありませんでした。

TOTP Two-Factor Authentication (TRIAL - 試行せよ)

二要素認証、他要素認証（Multi-Factor AuthN＝MFA）と呼ばれたりします。ログイン時にユーザ名とパスワードと共に、キーホルダー的なトークンや、スマホ上に表示される数字（定期的に変化する）を入力し、それを認証に用ます。

パスワードという、本当の利用者のみが「知っていること」だけではなく、本当の利用者だけが「持っているもの」を合わせて認証を行うことで、セキュリティを高める仕組みです。

TOTPというのは、RFC 6238で規定される、数字の生成のための仕様です。Google・GitHub・Facebook・Dropbox・AWS等でも、TOTPによる二要素認証を行うことができます。

簡単に原理を説明しますと、サーバ側とトークン側で同じ秘密情報を共有し、その秘密情報と現在時刻に基づいて、数字を生成します。ログイン時に入力された数字が、サーバ側で生成した数字と一致すればいい、ということですね。（つまり、時計が狂っていてはダメです）

数字の生成ロジックは、RFCに例示もあるのでそんな難しい実装ではありません。トークンとして機能するiOSやAndroidのアプリも無料で利用できます。要件に応じて、様々なアプリケーションに組み込んでみてはどうでしょうか。

OpenAM (ASSESS - 調査せよ)

その昔、Sun microsystems社が作っていたOpenSSOが基となっている、「認証の鬼」みたいな奴です。筆者は認証に詳しいわけではないのであまり語れないのですが、最近 OpenID Connect について調べる機会があったので、個人的になんとなくこれから少々関わる機会が多そうです…。

Application Servers (HOLD - やめとけ)

コンテナ仮想化やPhoenix server、継続的デリバリーの考え方の浸透にあたって、アプリケーションのデプロイの考え方が変わってきました。その結果、「アプリケーションサーバ ^*1」という考え方は、今回HOLDに位置づけられました。

古典的なアプリケーションサーバを用意するのではなく、アプリケーション内に組み込みのWebサーバを利用することにより、自動化の促進、デプロイの簡素化、管理対象のインフラを減らすことにつながります。

確かに最近のJavaフレームワークは、アプリケーションサーバレスののもが目立ちます。

Play framework
Dropwizard
Ninja framework
Spring Boot

参考: http://www.slideshare.net/daisuke_m/20150329-developersio-2015-c1-aws/49

OSGi (HOLD - やめとけ)

OSGiね…。個人的に思い出深い規格です。Eclipseのプラグインアーキテクチャを実現するためにも使われ、ダイナミックなクラスローディングや依存性解決のメカニズムが、なんだか凄そう感に満ちあふれていました。確かに凄いかもしれませんが、その代償として背負う複雑さがハンパない、ということで要注意指定されたのもよく理解できます。

OSGi 4.2の仕様書を印刷して読んでいたのは良い思い出です。。。