Servicesを操作するプログラムを作ることになりました。PythonでAWSを操作するにはbotoがよさそうです。S3でbotoの使い方を学習してみました。botoについてbotoはAWSの公式SDKではありませんが、以下のAWSのAPIに対応したライブラリです。(route53)公式SDKに迫るような対応サービスの多さですね。Storageにも対応しています。PythonとGoogle関連サービスとの相性がよいからでしょうか...。単純にS3とインタフェースが近しいからというのもありそうですが。AWSプログラミングができそうなライブラリです。Xなどではeasy_installがあれば以下のような感じで簡単インストールです。botoあるいは、ここからダウンロードして、展開して以下のような感じでインストールでもよいかと。S3への接続とアクセスキー、秘密キーについて環境変数としてAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYをあらかじめセットしておけばプログラム中にアクセスキー、秘密キーを記述する必要はありません。以下のような感じで接続できます。プログラム中にキー情報は書かないもし、プログラム中に記述する場合は以下のようにAWSとのAWSAuthConnectionを継承したクラス(この場合S3Connection)のインスタンスを作成するのですが、そこで引数にキー情報を入れます。バケット情報取得とバケット作成すべてのバケット情報を取得して、バケット名を出力すると以下のような感じになります。すべてのバケットを取得する。bucket.name続いて、バケットの有無を判定して、あればバケットオブジェクト取得、なければバケットオブジェクトを作成する、というのは以下のようにすれば動きます。ちなみにバケットのリージョンは東京リージョンを指定しています。バケットがあるかどうかを調べる、なければ作成する。補足ですが、リージョン情報を取得するのは以下のように書けばできます。続いて、先ほど作成したバケットにオブジェクトを出し入れしてみます。以下のように出し入れできます。保存したオブジェクトのテキスト取得また、ファイルとしてアップロード/ダウンロードも簡単です。以下はローカルの画像ファイルをアップし、別名でダウンロードする例です。内容が著しく浅い、という感はぬぐえないですが、今回はPythonでAWSを触る感触を学習してみたかった、ということでS3を操作するプログラムを通してbotoの使い方になじんでみました。SESなどほかに動かしたいサービスのウォーミングアップなので次回以降いろいろなサービスを動かしてみたいと思います。Servicesを操作するプログラムを作ることになりました。PythonでAWSを操作するにはbotoがよさそうです。S3でbotoの使い方を学習してみました。botoについてbotoはAWSの公式SDKではありませんが、以下のAWSのAPIに対応したライブラリです。(route53)公式SDKに迫るような対応サービスの多さですね。Storageにも対応しています。PythonとGoogle関連サービスとの相性がよいからでしょうか...。単純にS3とインタフェースが近しいからというのもありそうですが。AWSプログラミングができそうなライブラリです。Xなどではeasy_installがあれば以下のような感じで簡単インストールです。botoあるいは、ここからダウンロードして、展開して以下のような感じでインストールでもよいかと。S3への接続とアクセスキー、秘密キーについて環境変数としてAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYをあらかじめセットしておけばプログラム中にアクセスキー、秘密キーを記述する必要はありません。以下のような感じで接続できます。プログラム中にキー情報は書かないもし、プログラム中に記述する場合は以下のようにAWSとのAWSAuthConnectionを継承したクラス(この場合S3Connection)のインスタンスを作成するのですが、そこで引数にキー情報を入れます。バケット情報取得とバケット作成すべてのバケット情報を取得して、バケット名を出力すると以下のような感じになります。すべてのバケットを取得する。bucket.name続いて、バケットの有無を判定して、あればバケットオブジェクト取得、なければバケットオブジェクトを作成する、というのは以下のようにすれば動きます。ちなみにバケットのリージョンは東京リージョンを指定しています。バケットがあるかどうかを調べる、なければ作成する。補足ですが、リージョン情報を取得するのは以下のように書けばできます。続いて、先ほど作成したバケットにオブジェクトを出し入れしてみます。以下のように出し入れできます。保存したオブジェクトのテキスト取得また、ファイルとしてアップロード/ダウンロードも簡単です。以下はローカルの画像ファイルをアップし、別名でダウンロードする例です。内容が著しく浅い、という感はぬぐえないですが、今回はPythonでAWSを触る感触を学習してみたかった、ということでS3を操作するプログラムを通してbotoの使い方になじんでみました。SESなどほかに動かしたいサービスのウォーミングアップなので次回以降いろいろなサービスを動かしてみたいと思います。Beanstalkが発表されて、PaaS領域が一段と盛り上がってきました。Engineあたりが有名でしたが、最近は選択肢がかなり増えました。この記事を書いている最中にもちょうど以下のような記事がでていて、PaaSに対する注目度が高いことがうかがえます。Engine、Force.com、AWSのサービス、それぞれ実サービスの運用や受託開発で使った経験や、SIerでマネージャをする立場から、自分なりの比較と印象を書いてみようと思います。セールスフォース、Google、Amazonが提供、あるいは関連が強いPaaSについて言語、利用するDB、インフラ運営元、そしてサービス提供会社を一覧にしてみました。Yard(いずれAmazon?)注目すべきはGAEはDBが独自であること、Force.comはApex、VisualForceという独自の言語でアプリケーション構築をする必要があることでしょう。(Force.comのDBは独自といえば独自ですが、RDBの考え方でだいたい操作できます)それに対して、Amazon上で動くPaaSは言語、DBともに、オンプレミス環境からの差分はかなり少ないと思ってよさそうです。いった特徴を踏まえたうえで、「よいところ」と「気をつけるべきところ、気になるところ」を私の所感でまとめてみました。・アプリケーションサーバだけでなく、データベースまで自動スケールするところ。・Java/Pythonといった汎用性の高い言語で開発できること・非常に安い。1日あたりのQuota制限があるが、ある程度のボリュームまでは無料と考えてもよい。・個人で勉強しやすい。・物理的にどこにデータが置かれているかなどブラックボックス(悪いこととは限らない)で、どう動いているか見通しがきかないことがあること・BigTableという、RDBとは違う考え方が求められるデータベースを使うため、使いこなすにはかなりの学習コストが発生すること。Railsなど、オンプレミスの環境で培われた技術を用いてアプリケーションが構築できること。・開発者が確保しやすい。EC2、RDS、S3、CloudFrontなどPaaSの構成要素となるコンポーネントが独立したサービスとなっており、自由自在に組み合わせられる。・GUI操作(Point&Click)だけで、かなりのカスタム機能が作成でき、型にはまると生産性がかなり高いこと。・認証系の機能、ユーザの権限制御、ワークフローなどスクラッチ実装をするとけっこう面倒な機能が既に存在すること。・国内、海外問わずたくさんの大手企業が業務システムに使っており、セキュリティ含め、実績面では信頼しやすい・Apexなど独自技術の学習コストがかかる・ストレージ容量やレコード件数、外部からのAPI呼び出しの最大数の制限など、「容量の大きいデータ」、「件数の多いデータ」への制限は強いこと・ライセンス費用がユーザ単位であり、GAEやAmazon系の課金と違うのは注意が必要なこと上の色をつけているところが、もっともメリットとして特色があるところです。用途に合うと高い効果を出すGAEとForce.comGAEとForce.comは「制約は強いが、型にはまると高い効果を出す」と考えるとよいと思います。GAEはデータベースが独自なので「Joinをさける」「集合関数は使わないで、レコードに持つ」などRDBとは違う考え方で開発が必要です。独自技術を習得するコストを払ってもメリットを得られる可能性があります。Force.comについては、GAEに比べると書籍等少なく、個人で勉強する人も少なそうなので、知らない人も多そうですが、GAEと同じく型にはまると強いPaaSと考えています。GAEやAmazon系のPaaSが提供している機能はデータストアやストレージのAPIなど、どんなアプリケーションでも共通で使いそうなものが中心です。それに対して、Force.comは会社などの組織で使うアプリケーション構築に必要な機能が最初から揃っています。ユーザの発行、権限管理、ワークフローなど。認証処理とか権限制御など、受託案件では「毎度おなじみ」の機能ですが、けっこう作るのは毎度面倒、な機能です。いったものが最初からそろっていて、しかも簡単にカスタマイズできるというのは、はまるとすごい生産性です。いくつかの業務アプリをバンバン作っていった実績があります。セールスフォースが得意とするCRMだけでなく、多くの業務系アプリの開発が高い生産性でできる実感を持っています。一方でForce.comはユーザごとにライセンス費用がかかったり、CPUやストレージをちょっと使うと意外と早く制限がくるなど、特有の制約事項があり、注意しながらの開発が必要です。両方とも制約が強く、はまると効果テキメンっといった感じですが、学習コストがかかるので開発者のアサインが意外と難しい、といったデメリットがあります。Rails、Java(Tomcat)、PostgreSQL、MySQLなどのオンプレミス環境でも存在しているオープンな技術をベースとしていて、それらを使ったシステムをすばやく作れるというメリットがあります。アプリケーションサーバ、RDB、ストレージなどはAWSや各PaaSが提供してくれているサービスをそのまま使えばいいので、インフラ、ミドルの心配をせずに、Web開発のスタンダードな技術であるJava、Ruby、MySQLなどを使って開発できるというのがGoodです。オンプレミス環境と同じで、なおかつオープンな技術をベースにしているものが多いので学習コストも低く、開発者のアサインも容易です。コンシューマが使うWeb系のシステム構築で、とにかく早くリリースしたい、早く作りたい、という場合には、Amazon系のPaaSが有力な選択肢になります。EC2、S3などを使ってモバイルサイト(http://bhmb.jp/)を開発、運用しており、開発時のプラットフォーム選択の決め手はクラウドの恩恵をうけつつ、既存技術をベースにすばやく開発したい、というものでした。SIer視点からの認知度、信頼度の印象SIerである私たちにとって、多く接するお客様はユーザ企業の情報システム部門の方々です。いった企業の方々からも選択肢として認知されているのはセールスフォースがやはり一番という印象です。多くの企業で導入されたということはコンプライアンス観点などからもクリアした案件が多いということで、この辺はお客様に提案するプラットフォームとしてはSIer的にはGoodです。Engineもまったく認知されていないというわけではないのですが、積極的に選択肢にあがってくるケースが多いかというと必ずしもそうではなさそうな気もします。Amazon系やGAEの事例もサービス企業が内製でそのメリットを活かして作っているケースが多く見受けられます。企業の情報システム部門からの認知度、信頼度という点は、今後の向上に期待というところです。私が知る範囲でもお客様によってはAmazon系やGAEなどの技術に長けていて、すごく活用されているというケースもあります。全体で見るとまだ低い割合なのかな、と思います。今後の気になるところはPHPのPaaSSI案件というとJava系が多いと思いますが、Web絡みになるとPHPの比重が高くなります。いう点ではPHP系のPaaSは有名なものは見当たらないですね。Fog(http://www.phpfog.com/)が、Heroku的立ち位置を目指しているようなので今後どうなるか気になるところです。AzureでPHPできるとご指摘いただきました。まとめと中途採用募集のお知らせVMForceなどリストアップしていながら、あまり言及していないものがあり、すみません。最後に、フレクトはセールスフォースのプラットフォームやAWSを使ったインテグレーション事業を拡大中です。最新のPaaSを使った開発に興味のある人はぜひご連絡いただければと思います。採用エントリーは以下からです。Beanstalkが発表されて、PaaS領域が一段と盛り上がってきました。Engineあたりが有名でしたが、最近は選択肢がかなり増えました。この記事を書いている最中にもちょうど以下のような記事がでていて、PaaSに対する注目度が高いことがうかがえます。Engine、Force.com、AWSのサービス、それぞれ実サービスの運用や受託開発で使った経験や、SIerでマネージャをする立場から、自分なりの比較と印象を書いてみようと思います。セールスフォース、Google、Amazonが提供、あるいは関連が強いPaaSについて言語、利用するDB、インフラ運営元、そしてサービス提供会社を一覧にしてみました。Yard(いずれAmazon?)注目すべきはGAEはDBが独自であること、Force.comはApex、VisualForceという独自の言語でアプリケーション構築をする必要があることでしょう。(Force.comのDBは独自といえば独自ですが、RDBの考え方でだいたい操作できます)それに対して、Amazon上で動くPaaSは言語、DBともに、オンプレミス環境からの差分はかなり少ないと思ってよさそうです。いった特徴を踏まえたうえで、「よいところ」と「気をつけるべきところ、気になるところ」を私の所感でまとめてみました。・アプリケーションサーバだけでなく、データベースまで自動スケールするところ。・Java/Pythonといった汎用性の高い言語で開発できること・非常に安い。1日あたりのQuota制限があるが、ある程度のボリュームまでは無料と考えてもよい。・個人で勉強しやすい。・物理的にどこにデータが置かれているかなどブラックボックス(悪いこととは限らない)で、どう動いているか見通しがきかないことがあること・BigTableという、RDBとは違う考え方が求められるデータベースを使うため、使いこなすにはかなりの学習コストが発生すること。Railsなど、オンプレミスの環境で培われた技術を用いてアプリケーションが構築できること。・開発者が確保しやすい。EC2、RDS、S3、CloudFrontなどPaaSの構成要素となるコンポーネントが独立したサービスとなっており、自由自在に組み合わせられる。・GUI操作(Point&Click)だけで、かなりのカスタム機能が作成でき、型にはまると生産性がかなり高いこと。・認証系の機能、ユーザの権限制御、ワークフローなどスクラッチ実装をするとけっこう面倒な機能が既に存在すること。・国内、海外問わずたくさんの大手企業が業務システムに使っており、セキュリティ含め、実績面では信頼しやすい・Apexなど独自技術の学習コストがかかる・ストレージ容量やレコード件数、外部からのAPI呼び出しの最大数の制限など、「容量の大きいデータ」、「件数の多いデータ」への制限は強いこと・ライセンス費用がユーザ単位であり、GAEやAmazon系の課金と違うのは注意が必要なこと上の色をつけているところが、もっともメリットとして特色があるところです。用途に合うと高い効果を出すGAEとForce.comGAEとForce.comは「制約は強いが、型にはまると高い効果を出す」と考えるとよいと思います。GAEはデータベースが独自なので「Joinをさける」「集合関数は使わないで、レコードに持つ」などRDBとは違う考え方で開発が必要です。独自技術を習得するコストを払ってもメリットを得られる可能性があります。Force.comについては、GAEに比べると書籍等少なく、個人で勉強する人も少なそうなので、知らない人も多そうですが、GAEと同じく型にはまると強いPaaSと考えています。GAEやAmazon系のPaaSが提供している機能はデータストアやストレージのAPIなど、どんなアプリケーションでも共通で使いそうなものが中心です。それに対して、Force.comは会社などの組織で使うアプリケーション構築に必要な機能が最初から揃っています。ユーザの発行、権限管理、ワークフローなど。認証処理とか権限制御など、受託案件では「毎度おなじみ」の機能ですが、けっこう作るのは毎度面倒、な機能です。いったものが最初からそろっていて、しかも簡単にカスタマイズできるというのは、はまるとすごい生産性です。いくつかの業務アプリをバンバン作っていった実績があります。セールスフォースが得意とするCRMだけでなく、多くの業務系アプリの開発が高い生産性でできる実感を持っています。一方でForce.comはユーザごとにライセンス費用がかかったり、CPUやストレージをちょっと使うと意外と早く制限がくるなど、特有の制約事項があり、注意しながらの開発が必要です。両方とも制約が強く、はまると効果テキメンっといった感じですが、学習コストがかかるので開発者のアサインが意外と難しい、といったデメリットがあります。Rails、Java(Tomcat)、PostgreSQL、MySQLなどのオンプレミス環境でも存在しているオープンな技術をベースとしていて、それらを使ったシステムをすばやく作れるというメリットがあります。アプリケーションサーバ、RDB、ストレージなどはAWSや各PaaSが提供してくれているサービスをそのまま使えばいいので、インフラ、ミドルの心配をせずに、Web開発のスタンダードな技術であるJava、Ruby、MySQLなどを使って開発できるというのがGoodです。オンプレミス環境と同じで、なおかつオープンな技術をベースにしているものが多いので学習コストも低く、開発者のアサインも容易です。コンシューマが使うWeb系のシステム構築で、とにかく早くリリースしたい、早く作りたい、という場合には、Amazon系のPaaSが有力な選択肢になります。EC2、S3などを使ってモバイルサイト(http://bhmb.jp/)を開発、運用しており、開発時のプラットフォーム選択の決め手はクラウドの恩恵をうけつつ、既存技術をベースにすばやく開発したい、というものでした。SIer視点からの認知度、信頼度の印象SIerである私たちにとって、多く接するお客様はユーザ企業の情報システム部門の方々です。いった企業の方々からも選択肢として認知されているのはセールスフォースがやはり一番という印象です。多くの企業で導入されたということはコンプライアンス観点などからもクリアした案件が多いということで、この辺はお客様に提案するプラットフォームとしてはSIer的にはGoodです。Engineもまったく認知されていないというわけではないのですが、積極的に選択肢にあがってくるケースが多いかというと必ずしもそうではなさそうな気もします。Amazon系やGAEの事例もサービス企業が内製でそのメリットを活かして作っているケースが多く見受けられます。企業の情報システム部門からの認知度、信頼度という点は、今後の向上に期待というところです。私が知る範囲でもお客様によってはAmazon系やGAEなどの技術に長けていて、すごく活用されているというケースもあります。全体で見るとまだ低い割合なのかな、と思います。今後の気になるところはPHPのPaaSSI案件というとJava系が多いと思いますが、Web絡みになるとPHPの比重が高くなります。いう点ではPHP系のPaaSは有名なものは見当たらないですね。Fog(http://www.phpfog.com/)が、Heroku的立ち位置を目指しているようなので今後どうなるか気になるところです。AzureでPHPできるとご指摘いただきました。まとめと中途採用募集のお知らせVMForceなどリストアップしていながら、あまり言及していないものがあり、すみません。最後に、フレクトはセールスフォースのプラットフォームやAWSを使ったインテグレーション事業を拡大中です。最新のPaaSを使った開発に興味のある人はぜひご連絡いただければと思います。採用エントリーは以下からです。SQSに入門してみましたこんにちは。