aws memo

AWS関連の備忘録 (※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。1年以上古いエントリは疑ってかかってください)

訳:スケーラブルなエンタープライズシステムを構築する

さわりとしてはいいかも。もはやSOAとは言わないんだろうけどw

Building Scalable Enterprise Systems - Java Code Geeks

===

成功している企業は、ビジネスの俊敏さがあることと、新製品や新サービスを市場に導入できることをみたしている。ITのオーバーヘッドを削減とビジネスの俊敏さが相まって、企業は、エンタープライズシステムを改善と変化させるよりよい方法を見つける必要がある。

クラウド、ソーシャル、モバイル、ITの大衆化という到来は、エンタープライズアプリケーションも、環境の変化に適用剃る必要があることを意味する。今日、すべての企業は、次の要求に直面している。

  • エンタープライズアプリケーションのクラウド化( プライベート、パブリック、ハイブリッドのどれを選ぶかは、優先度の一つである)
  • 自作のエンタープライズアプリケーションを、SaaSに置き換えるか、撤廃するか
  • エンタープライズデータを、サードパーティの利用に供する
  • エンタープライズアプリケーションの機能を、様々なチャネル(web, mobile)に対応させる(つまり、大衆化)
  • ビジネスの成長に伴う要求に応じて、システムを24x7稼働させる

ポータル、CMSSOA、集中DBといったアプリケーションの設計パターンは、新しいビジネスの要求にマッチできてきない。エンタープライズは、より新しいアプリケーション設計パターンの利用を必要としており、それはすでに消費者向けWebの世界に登場している。次世代消費者向けWebアプリケーションのパターンは、エンタープライズアプリケーションにも適用可能である。

  • 機能で分割する - 利用パターンや消費リソースで機能を分割する。機能はRESTfulやWebサービスとして公開できる。機能グループは、リソースレベルの最適化を実現するのに役立つ。リソースの特徴(高速CPU、大量RAM、高速I/O)に基づいた独立した機能ブループは、スケールしやすくなる。俊敏さを実現できるサービスという形で、このパターンはエンタープライズプラットフォームを最適化できる。出力がサービスであるため、並列に実行できる。市場への投入を早くできる。とても速いサービスを実現するインフラを作りやすくなる。
  • プロバイダと利用を分離する - 大きな一枚岩のアプリケーションを構築する代わりに、プロバイダと利用側を分離する。企業は、チームを分けるべきである。一つは、機能を提供するプロバイダで、もう一つは、機能を利用する。機能は、標準的なバージョンのインターフェースを備えたシンプルなAPIとして公開される。
  • パブリック・プライベートクラウドの統合- 企業は平準化された統合戦略を持つ必要がある。標準的に鳴り始めている複数のベンダーから提供される複数のアプリケーションを載せる必要がある。
    • 企業ユーザが利用しているSaaSアプリケーションのベンダーと統合を開始する必要がある。その時、特に認証/認可のAPIレベルの統合を扱う必要があるだろう。
    • ユーザに提供している企業アプリケーションは、パブリッククラウドにホスト可能である。

企業は、パブリッククラウドSaaSベンダーと、データセンターの間で行き来するデータを扱うサービスの統合を行う必要がある。