[SAP] ベーシス勢がSAP BTPを触りはじめてみた


#はじめに

この記事は [chillSAP 夏の自由研究2021](https://note.com/chillsap/n/n08ef5ec73b4c) の記事として執筆しています。

SAP界隈はここのところ猫も杓子もBTP。SCPをサボタージュしたところ、時代をひとつ飛び越えた感すらあります（え？名前だけ？）。しかも<b>Business Technology Platform</b>と来たものです。プラットフォームならベーシスの扱う範囲でしょう。良いのか悪いのかいったん置いといてBTPってなんじゃらほい？というところからベーシス目線で取っ付いてみたいと思います。

ホンネを言うと、デジタルコアと呼ばれているS/4HANAにデータを集めていく以上、NetWeaver ABAPというかWork Processのコンテナ化こそが全世界のベーシス勢が渇望していることだと思うし、コンテナ化できるならk8sのマネージドサービスを利用したいという発想が生まれるから、それだけでクラウド移行を強烈に後押しして「さらばオンプレ」の理由になれると思うのですが。。。いつかきっとできるようになると信じてます。

#この記事で書かれていること
ベーシス目線ですので環境です。正直なにか動くモノを作っているわけではありません。アカウント種別が２つ（グローバルアカウント、サブアカウント）と環境が４つ（Cloud Foundry、ABAP、Kyma、NEO）あるので、このあたりの受け止め方を整理しています。
すると企業にとってBTPに手を出す前の準備というか心構えというか、こういったものが見えてきます。
手を出す前に「なるほど、環境周りはこうなのね」と知っておくところまでを記載しています。

#対象読者
ターゲットは「SAP界隈もBTPとかいうマネージド・サービスっぽいこと言ってるけど、目の前のS/4マイグレーションでだいぶ食傷気味。ところでBTPってうちの会社は手を出せるんだっけ？」と考えている<b>企業内のベーシス勢の方々</b>です。

#結論：うちの会社はBTPに手を出せるんだっけ？
どこのクラウドベンダー（ハイパースケーラー）でも申請すれば利用OK（特にAWS、Azure、SAP）
　→大丈夫。手を出せます。
特定のクラウドベンダー（ハイパースケーラー）だけ利用OKで他は使わない（AWSだけOK、AzureだけOK、など）
　→Azure・GCPだけだときついっす。そこを変えないと厳しい。

#大前提の理解
サービスですから、大前提にどのように記載されているのか理解してから入りましょう。
まずは[Basic Platform Concepts](https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/73beb06e127f4e47b849aa95344aabe1.html)を見てみます。

>The services and solutions of SAP BTP are available on multiple cloud infrastructure providers. The multi-cloud foundation supports different environments, such as Cloud Foundry, ABAP, and Kyma, as well as multiple different regions, and a broad choice of programming languages.

思いっきりマルチクラウドインフラ上でサービスを提供していると記載されています。
そして次の絵です。
読み取れることは次のとおりです。
・グローバルアカウントとサブアカウントがある
・サブアカウントでリージョン・環境・クォータを管理
・環境の下に、サービス・アプリケーション・ツールが紐付いている
・ユーザーはサブアカウント内に作成されたアプリケーションにアクセスする

><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/6ae23afa-52a0-4445-5442-a543ce3fd74c.png">


ざっと読み取れる部分を列挙しましたが、ベーシス勢が大好きな環境面のポイントはサブアカウントにありそうです。
また、この時点でグローバルアカウントはおそらくSAP社がクライアント企業と契約するために発行する一意の番号なのだろうなぁくらいの印象を持てます。
リージョンという言葉もクラウドをかじっていればピンとくるあのリージョンっぽいなぁと推察できます。

確認していきましょう。

#アカウントの理解
[Account Model](https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/8ed4a705efa0431b910056c0acdbf377.html)を確認していきます。
まずはグローバルアカウントから。

>A global account is the realization of a contract you made with SAP.

あぁやっぱり契約管理ですね。これ以上でもこれ以下でもないのでグローバルアカウントはこんなところでしょう。

次はサブアカウントです。

>Subaccounts let you structure a global account according to your organization’s and project’s requirements with regard to members, authorizations, and entitlements.

会社組織やプロジェクトの要求にもとづいてグローバルアカウントを構造化する、と記載されていますね。。。
うーん、わからん。トライアルでいくつかサブアカウントを作ってみましょう。
（モザイク部分は筆者のグローバルアカウントが記載されています。）

<img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/b52e0917-b960-7eb2-be01-99857062174b.png">

はい、わかりました。
サブアカウントは、クラウドベンダー（ハイパースケーラー）とそのリージョンを管理しているものですね。
しかも同一クラウドベンダー（ハイパースケーラー）・同一リージョンの組合せとサブアカウントは1:Nの関係になれています。上図でいうAWS Frankfurtにいくつもサブアカウントを作れるということは、複数のサブアカウントが同一リージョンにあってもインフラレベルで分断されている。これが会社組織やプロジェクトの要求によってサブアカウントを作っていくことができるという意味ですね。
例えばカンパニー制を採用している大企業の中で、各カンパニーごとにBTP上でアプリケーションを作っていくとして、カンパニーの枠を超えてデータが見えたりするのは好ましくないので、サブアカウントレベルで切ってしまえばデータ閲覧や開発の統制もかけやすいですね。

サブアカウントについてまとめると、下記のとおりですね。
・クラウドベンダー（ハイパースケーラー）+リージョンの単位で区分けするために利用
・同一クラウドベンダー（ハイパースケーラー）・同一リージョンのサブアカウントを複数作ることができる
　例）Azure東日本で動くサブアカウントを複数作ることができる
・1グローバルアカウントの中で複数の組織が存在している場合はサブアカウントを切ってデータアクセスやアプリケーション開発をサブアカウント内に収めることができる


#環境の理解
続いてCloud Foundry、ABAP、Kyma、NEOの4つの環境です。
さてさて、クラウドのリージョンが既に出ているということは、きっとこの4つの環境がどこで動作可能・・・という話になりそうかなとニヤニヤしながら確認していきます。

まずはHELPの[Environments](https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/15547f7e7ecd47ee9fa052b0e18c7b0a.html)を確認してみます。

>Each environment comes equipped with specific tools, technologies, and runtimes that you need to build applications. So a multi-environment subaccount is your single address to host a variety of applications and offer diverse development options. One advantage of using different environments in one subaccount is that you only need to manage users, authorizations, and entitlements once per subaccount, and thus grant more flexibility to your developers.

なるほど、1つのサブアカウントの中に複数の環境を立てることができるんですね。イメージとしては、例えばAWS Tokyoで作った1サブアカウントの中に、Cloud Foundry、ABAPの2つの環境をつくることができる、ということですね。理解理解。
ベーシス的にはサブアカウント＝リージョンと引き摺られそうが、あくまでもリージョンの中の1区画ですね。で環境という言葉が厄介でついついリージョンに紐づけてパニックを起こしそうになりますが、区画の中で動かすことのできるランタイムパッケージくらいのざっくりイメージでいれば良さそうですね。

では個々見ていきますか。
ここからはサービスレベルの話になってくるので、[SAP Discovery Center](https://discovery-center.cloud.sap/)を参照します。

##Cloud Foundry
さて、まずはCloud Foundryサービスを見てみましょう。
Discovery Centerで各サービスのPricingタブを見ると、なんとそのサービスがどのクラウドベンダー（ハイパースケーラー）・リージョンで提供されているのか分かります。
SAPノートを見なくても良いのは嬉しいですね。

><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/86a987fc-0a4a-afe2-7c73-017d32908f03.png">

見ての通り、Cloud FoundryはAWS、Azure、GCPで提供されており、それぞれのリージョンが書いてあります。例えばGCPなんかはUS Central(IA)だけが書いてありますので、他はまだ提供されていないという意味です。IAってUS Central1のIOWAかなぁ。Azure・AWSも見てみると両方ともJapan(Tokyo)なので、西日本ではまだ提供されていないことが分かります。残念。

あ、ちなみにCloud Foundryってどの言語が動くのよ？という話もあるので[Development in the Cloud Foundry Environment](https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/40a8f8f6f1724e0ca0fd2a8777f45504.html)を読んでみました。

>Build on open standards with SAP Java, Node.js, and Python buildpacks or bring your own language with community buildpacks for PHP, Ruby, Go.

SAP Java（なぜSAP Javaと書いたのか詳しくわからないですが、一般のJavaとSAP Javaは違うのでしょうか）、Node.js、Pythonのビルドパックはオープンスタンダードとしてそのまま使えそうですね。


##ABAP
みんな大好きABAPはSaaS OEM、Standard、16GB Runtime and 64GB Persistenceの3つがあります。それぞれ展開してみますが、すべて現状はAWSのみの提供でした。

><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/07e86799-6a5e-9774-0acf-3e9f3acd6e10.png">

<b>SaaS OEM</b>
AWSだけですね。
><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/f825c7de-91e0-39df-e062-04c6adea2ccf.png">

<b>Standard</b>
AWSだけですね。。
><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/fd6c3d0b-c2b5-1226-a566-6c8dfd248220.png">

<b>16GB Runtime and 64GB Persistence</b>
AWSだけですね。。。(´・ω・｀)ｼｮﾎﾞｰﾝ
><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/95f36dc2-ad70-cd37-f9bb-1801ba9d8131.png">

BTP上でのABAPは流行っていないんですかね。。。

##Kyma
Kymaはk8sのマネージド・サービスです。歴史を紐解けばHybris as a Service（YaaS）です。HybrisはC/4HANAに統合されていき、YaaSは気づいたらKymaと呼ばれ、いつの間にかk8sマネージド・サービスとなっており驚いた記憶があります。脱線ついでに、サウンドデザイン言語で[Kyma](https://en.wikipedia.org/wiki/Kyma_(sound_design_language))があるんですね。知らなかった。
こちらも見ると、AWSとAzureで提供されていますね。

><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/8a035a7d-e175-98ca-392d-958edc20f3e7.png">

##NEO
最後にNEOです。NEO環境ではJavaとかHANAの開発ができます。
で、NEOの情報はSAP Discovery CenterからアクセスできないのでSAP HELPに立ち戻ります。
[Regions and Hosts Available for the Neo Environment](https://help.sap.com/viewer/ea72206b834e4ace9cd834feed6c0e09/Cloud/en-US/d722f7cea9ec408b85db4c3dcba07b52.html)を見てみましょう。

><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/c691b899-ccb9-aef8-2968-f6d830079b59.png">

見て分かる通り、AWS/Azure/GCPといったハイパースケーラーの言葉が出てきません。
じゃあどこよ？という疑問が出てきます。
[What Is SAP BTP, Neo Environment](https://help.sap.com/viewer/ea72206b834e4ace9cd834feed6c0e09/Cloud/en-US/34ac79024d41469a804ba9b9deeb5b1d.html)に記載されているのですが、SAP社が準備しているデータセンターです。

>You can deploy applications developed in the Neo environment to various SAP data centers around the world. For more information about regional availability of the Neo environment, see [Regions and Hosts Available for the Neo Environment](https://help.sap.com/viewer/ea72206b834e4ace9cd834feed6c0e09/Cloud/en-US/d722f7cea9ec408b85db4c3dcba07b52.html).


ここまで見てきたとおり、環境はAWSの各リージョンが他のハイパースケーラーに先行して配備されていると見受けられます。ABAPに至ってはAzure・GCPでは利用すらできない。ここでは取り上げていませんが新たなサービスはAWS先行の印象が強く、つまりAzureやGCPのみを使っている場合は、AWSを利用している企業から遅れてしまいます。ビジネス展開スピードが命の時代に、こんな理由で遅れていくのは好ましくないです。

例えば、SAP IoTはAWSのみで提供されています。
せっかく新しいことを試みようとしても、特にAzureやGCPのみを自社で利用可能なクラウドベンダーとしていると、こういうところでつまづきます。
><img width="600" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529287/1bb1fe0a-baa9-a911-2bc4-e39056c36f8c.png">

#BTPを使う前にやっておくべきこと
何も調べずいきなりBTPを契約する企業はないと思いますが、ここまで見てきたようなことがあるので、事前に少なくとも下記のことくらいは準備したほうが良いと考えられます。
・自社で利用して良いクラウドベンダー（ハイパースケーラー）はどこだったか確認
・（特にAzure・GCPのみの場合）AWSも使えるように準備
・データ保護規制の影響を受ける業務でBTPを使おうとしていないかチェック
　例えばIoTはAWS EUとUSで提供されているようなので、それら以外の地域の業務で何らかの規制に引っかかるかチェック
　せっかくSAP社がDiscovery Centerで調査できるようにしてくれていますので使わない手はありません

#おわりに
最近忙しくて、このくらいのまとまった記事を書こうとするとなかなか更新頻度が上がりません。
もう少しマイクロな文章を出していくようにすればよいのかな。反省中です。

あと、転職しました。

それでは！