過去10年間のうちに主要なプログラミング言語を用いて書かれたカスタム開発のアプリケーションは、ほぼすべてリプラットフォームが可能です。ソースコードの責任者として、開発者はクラウド環境でのアプリケーションの正常な動作を阻むようなアンチパターンをコードから見つけ、変更できます。
状況が最低限の労力を求めていようと、または完全なクラウドネイティブを求めていようと、リプラットフォームへの理解は、下記の2つの事柄を理解するところから始まります。
|
1
|
下の成熟度モデルで示す通り、クラウドには様々なレベルと、目指すべき12の要素に基づくアプリケーション設計があります。 | |
|
2
|
各アプリケーション、または類似のアプリケーションのグループに対して適切な戦略を選択することが、成功のために重要です。 |
リプラットフォームとは
リプラットフォームとは、最低限の12の要素に準拠しながら、既存のプラットフォームからアプリケーションをアップグレードして、既存の機能を残しながら、クラウド上で実行できるようにすることを含みます。また、アプリケーションサーバーやリレーショナルデータベース管理システム（RDBMS）のような縦に拡張された技術から、水平方向に拡張可能なサービスとしてのデータストア、軽量オープンソースソフトウェア（OSS）サーバー、およびオンプレミスに対する他のクラウドサービスへと最新化することが含まれることもよくあります。このレベルの取り組みは、クラウドコンピューティングの基本的なメリットしか提供しませんが、すべてのアプリケーションがクラウドネイティブのすべての機能を必要としているわけではないので、一部のアプリケーションにとってはこのレベルで十分です。
「（Tanzu）は、当社のデリバリ能力をすばやく向上させてくれました。以前はChefを通じてすべてを構成していました。我々はサーバーを複数構築しましたが、ビルドシステムも怪しいものでした。機能を実稼働化させるのに、まさに数週間かかっていました。今では、CI/CD機能を搭載したTanzuのおかげで、作業が大幅に加速しました。今では5分もあればプッシュできます。我々にとって劇的な改善です。」
Philip Glebow
ITアーキテクチャ担当ディレクター, プロダクトアーキテクト Gap Inc/GapTech
リプラットフォームが重要である理由
| ◼ |
設備投資額と運用費の低減ライセンス、運用、管理にお金がかかる本格的なアプリケーションサーバーからの離脱は、2004年以来、一貫した市場トレンドであり続けています。今や、特にJavaではクラウド内でコンテナ化できる軽量サーバーが一般的で、何年にもわたってApache Tomcatが優勢を誇ってきました。 |
|
| ◼ |
拡張性とプロバイダ可搬性の向上クラウドプラットフォームの場合、垂直的な拡張性は本質的に限定されていますが、水平方向には数秒で動的に規模を拡大縮小できます。自動的な拡大縮小も可能です。Cloud Foundryのようなオープンソースプラットフォームは、1つのクラスタで25万個のコンテナを実行できます。1つのIaaS（サービスとしてのインフラストラクチャ）プロバイダにこだわる必要なく、最新プラットフォーム上のアプリケーションは、ファイアウォールをまたいで、さまざまなIaaSプロバイダ間で移動させることが可能です。 |
|
| ◼ |
ハードウェアリソースの利用率とコストの最適化アプリケーションをコンテナ化および仮想化することで、ハードウェアまたはIaaS上でのデプロイ密度が向上し、システムリソースの利用率の最大化と、待機時におけるリソースの解放または再割り当てが保証されます。 |
|
| ◼ |
ソフトウェアのライセンスモデルとデリバリモデルの改善ほぼすべての業界大手、主要財団法人、数多くの企業のユーザーが、クラウドプラットフォームを研究開発投資の主要分野としています。これらのプラットフォームは、ユーティリティと契約料金決定機能により、従来のソフトウェアライセンスモデルを革新するものです。また、クラウドプラットフォームはクラウドの実行に必要な個別ソリューションの数を減らします。 |
|
| ◼ |
運用上の制御能力を失うことなく、開発者の生産性を向上させるあらゆるプログラム言語に対応した、非常にシンプルで一貫性のある開発者用ツールに加え、多くのクラウドプラットフォームは、拡張モデルとともに、中核的なプラットフォーム要素として、すぐに使える基本サービスを提供します。開発者がセルフサービス可能な場合、プラットフォーム全体でのアクセス制御や追跡記録を用いる環境を瞬時にプロビジョニングできます。このことは、リソースパラメータを設定できる運用担当チームにとって望ましいことです。その後、アプリストアを使用して、開発者による利用に向けてクラウドサービスを集約できます。 |
|
| ◼ |
一般的な管理および監視ツールを使用したDevOpsの実現最新のクラウドは、主要なアプリケーション、サービス、プラットフォームの指標をほぼリアルタイムで総合的に表示する、人の介入がいらない健全性管理機能を提供します。開発者と運用担当者は、クラウド環境における同じシステムの健全性と可用性に関するデータへの理解を共有することができます。 |
|
リプラットフォームを検討する際の 考慮事項
過去10年間の商用パッケージソフトウェアは、元々クラウド向けに設計されていないため、元のベンダー以外による再フォーマット化は不可能でした。現在開発されているほとんどのアプリケーションにとっての最終的な目的地がクラウドであることは明らかですが、すべてのアプリケーションが初めからクラウドネイティブアーキテクチャを必要とするわけではありません。アプリケーションがビジネスクリティカルで大規模になればなるほど、クラウドネイティブアーキテクチャが意味を持ちます。逆に言うと、世の中にはビジネスクリティカルではないながらも価値を提供しているアプリケーションが数多くあり、それらはリプラットフォームだけでメリットを得ることができます。正しい戦略をどう選択しますか？
自動化中心で継続的にデリバリされるソフトウェアを推進するには、組織はソフトウェアの構築とデリバリの方法を変える必要があります。下記の質問への答えを見つけておくと、クラウドのリプラットフォームに向けた説得に役立つことでしょう。
| ◼ |
ビジネス上の推進力カスタムアプリケーションは、ビジネスにとってどれほど重要か？アプリケーションでどれくらいのレベルのリスクを負うことができるか。変更の頻度はどれくらいか？その分野の専門家を確保できるか？ |
|
| ◼ |
経済的推進力そのアプリケーションは、ハードウェアやソフトウェアにどれほどの投資をするに値するか？予想される結果を考慮すると、リプラットフォームの取り組みに対して、どれほどの時間枠が適当か？収益やコスト削減に関して、どれほどのメリットまたは影響が予想されるか？ |
|
| ◼ |
技術的推進力コードベースは適切か？12の要素への違反だらけになっていないか？適切なフレームワークやランタイムを用いているか？作業負荷はどのようなタイプか？ |
|
| ◼ |
組織的変更組織は、職務的サイロを排除し、サービスの構築と運用の両方を行う自己充足的なチームをつくる準備ができているか？変更管理プロセスは、人的介入が最小限または皆無でも、デプロイパイプラインに耐えられるか？ |
|
リプラットフォームされたアプリケーション
|
従来のエンタープライズアプリケーション
|
|---|---|
| オートスケール。 大規模なインフラストラクチャ自動化により、人的エラーによるダウンタイムがない。コンピュータの自動化にも人的エラーが発生せず、どの規模のシステムにも一貫して同じルールセットが適用される。 | 手動によるスケーリング。 運用担当者がサーバー、ネットワーク、およびストレージ構成を手動で作り上げ、管理するなどといった、手動インフラストラクチャである。 |
| 適正サイズの容量。 リプラットフォームされたアプリケーションでは、デプロイ時にアプリケーションの現行のニーズに基づいて、リソースが動的に割り当ておよび再割り当てされるといったメリットがある。 | オーバーサイズの容量。 従来のIT設計は、あるアプリケーション専用の、カスタムインフラストラクチャソリューション（「雪の結晶」）型の設計で、そのことがアプリケーションのデプロイの遅れにつながっていた。ソリューションの容量はしばしば、最悪のケースの容量予測に基づいて過剰に大きく設けられており、需要に合わせて規模をさらに拡大する余地が少ない。 |
| セキュリティの向上。 リプラットフォームされたアプリケーションは、アプリケーション、アプリのランタイム、ファイルシステム、および埋め込み型OSレベルのダウンタイムなしにパッチの適用が可能。ロールバックはシンプルかつ迅速。 | スケジュールされたダウンタイム。 CVEに対応し、パッチを適用するには、営業時間後の調整と定期的なダウンタイムが頻繁に必要になる場合がある。変更をすると、たいていの場合、ロールバックが難しくなる。 |
| 不変のインフラストラクチャ。 さまざまな環境が、毎回同じ方法で確実に構築されており、変更不可であることを保証することで、環境の不一致は大幅に低減されている。 | 固有の環境。 大規模になると複雑度が上がるので、運用担当者は問題の診断に時間がかかり、正しい実装に失敗しやすくなる。手動で作成された自動化レシピは、インフラストラクチャの中に人的エラーをハードコーディングさせる恐れがある。 |
| コンテナマネージド。 Docker、RunC、およびGarden Linuxコンテナ内のアプリは、GoogleからインスパイアされたBOSHや、250000以上のコンテナ/インスタンスに対応できるTanzu Elastic Runtimeによって完全に管理されている。不具合は、アプリケーションインスタンス、プロセス、仮想マシン、可用性ゾーン層で自己回復される。 | ローカルOS。 アプリケーションは、ハードウェアのOS上で直接実行されるか、仮想化される。サーバーはステートフルであること、それぞれの構成を保守することが期待される。高可用性は、通常、アプリケーションランタイムレベルである。 |
| 自動DNS、ポート、ルーティング、スケーリング。 クラウドの場合、チームはマイクロマネジメントを避け、クラウドプロバイダがルーティング、スケーリングなどとともに、ポートの割り当てを管理する。 | 手動での構成。 すべての構成（DNS、ルーティング、スケーリング、ポートの割り当てなど）は、手動である。 |
VMwareは、組織によるアプリケーションのリプラットフォームの評価と実行を支援し、さらに結果として得られたプラットフォーム上のアプリケーションをお客様に代わって運用します。業界を問わず、あらゆる規模の企業（大企業から新興企業まで）から信頼を寄せられている当社のソフトウェア、サービス、経験が、デプロイの前、途中、そしてデプロイ後まで、お客様のクラウドへの道のりを導きます。
| ◼ |
VMwareと協働で、かかる労力とビジネス上必要なメリットとの間を天秤にかけながら、リプラットフォームの対象となるアプリケーションを特定します。 |
|
| ◼ |
Tanzu Labsのアプローチを活用します。このアプローチでは、価値をデリバリするまでに何か月もかけてポートフォリオ分析を行う方法と異なり、アジャイル方法論を用いて、1週×10回のスプリントで反復的に結果を得ることができます。 |
|
| ◼ |
アプリケーションをクラウドで実行する前に、12の要素のうち、最低限対応する必要がある項目をすばやく確認します。 |
|
| ◼ |
VMwareと協働で、モノリシックアプローチ内の抽出可能な継ぎ目を特定し、段階的に移行して、ビジネスへと流れる価値を維持しながら、クラウドネイティブ設計の恩恵を十分に受ける必要があるアプリがリプラットフォームされるようにします。 |
|
| ◼ |
当社のクラウドネイティブプラットフォームであるTanzuを使用してお客様のアプリケーションをデプロイし、管理します。これにより時間効率が高まります。 |
