Mais conteúdo relacionado
Semelhante a 2013 デブサミ 「SIの未来ってどうなのよ?」 (20)
Mais de Serverworks Co.,Ltd. (20)
2013 デブサミ 「SIの未来ってどうなのよ?」
- 1. Developers
Summit
SIの未来ってどうなのよ?
SIer大淘汰時代に、AWS専業で!
新しいSIの形にチャレンジする企業の舞台裏
14-D-3 大石 良
#devsumiD @ooishi
株式会社サーバーワークス
代表取締役
Developers Summit 2013 Action !
- 2. おおいし クラウド の すけ
大石 蔵人之助
株式会社サーバーワークス
代表取締役
– 昭和48年7月20日 新潟市生まれ
– コンピューターとの出会いは10歳の頃
– 当時はPC-8001にベーマガのプログラムを入力する日々
– コンピューターの購入は11歳 / SHARP X1
– 中2の時に初めてプログラムが書籍に掲載
– 高校入学記念にX68000を購入
– 仙台の大学に進学・本格的なオタクライフ開始
– 大学生の時にパソコン通信開始。本格的にシェアウェアを販売
– 総合商社でインターネットサービスプロバイダー事業に携わる
– 2000年にECのASPを立ち上げるべく起業
- 18. 22001111年
AWS Solution Provider
22001122年
Amazon Partner Network最上位の
Advanced Consulting Partner
に認定
- 23. サイトダウンの理由
被災者: 非被災者:
救急医療など、支援 義援金やボランティ
が受けられる場所を ア活動など、支援で
探す目的で きる方法を探す目的
- 28. 負荷分散装置
20台の、物理的に離れた
2つのデータセンターに設置
されたウェブサーバー 1日に500万通送信できる
メールサーバー
物理的に離れたデータセンター間で
リアルタイムに同期し、かつ1時間おきに
環境構築22時間 バックアップを取るデータベース
アプリ開発4488時間
- 29. タイムチャート:
33月1144日 日本赤十字社様との打ち合わせ
33月1155日 サイト復旧
33月1177日 義援金管理システム稼働開始
- 34. SSII企業倒産件数
240
年間222211件
220
過去最悪!
200
180
160
140
120
2010年
2011年
2012年
- 38. AWSでSIオワタの図
AAWWSSでハードが要らなくなる
ソフトもAAWWSSを使えば流通がいらなくなる
ユーザー企業が自分でシステム構築できてしまう
SIオワタ\(^o^)/
- 39. 仮説からActionへ
仮説:
ユーザー企業は、自前でクラウドを
コントロールしようとするのでは無いか?
↓
Action!
ユーザー企業が、AAWWSSのコントロールを
やりやすくするツールをビジネスにしよう!
- 43. ユーザー数
900
800
700
600
500
400
300
200
100
0
- 44. ビジネス上の結果
• 有料ユーザーが全く増えず!
• 22000099年〜22001100年は
大赤字!!
- 46. 失敗11.. タイミング
• AAWWSSは、エンジニアが評価の
ために使うケースがほとんど
だった
• 投入�が早すぎた
- 47. 失敗22.. 仮説そのもの
• よく顧客が自社にへばりついているSIer
の悪口をいっているので、それを
「コントロールを取り戻したい」
という意図と勘違いした
- 53. 私たちが得た学び
• 顧客が望んでいるものはセルフサービス
ではなく、新しい技術を安全に利用する
ための 保険
• 日本赤十字社の事例が示すように、突発
的な事態(災害・ハードの故障)への
迅速な対応の方が大切だった
- 54. Pivot and Action!
顧客はセルフサービスを
望んでいない
Cloudworks自体は無料で続け、
AWSの導入�支援(SI)で収益化
- 57. わかったこと
11.. 調達モデルの変化
22.. 日本のクラウドとAAWWSSとは何が違うか
33.. クラウドの促進には何が必要か
- 62. 今までのSI
のどが
渇いた!
○×○×○×○×○ ○×○×○×○×○
×○×○×○×○× ×○×○×○×○×
○×○×○×○×
○×○×○×○×
調達チーム 品質チーム
○×○×○×○×○ ○×○×○×○×○ ○×○×○×○×○ ○×○×○×○×○
×○×○×○×○× ×○×○×○×○× ×○×○×○×○× ×○×○×○×○×
○×○×○×○×
○×○×○×○×
○×○×○×○×
○×○×○×○×
バケツを 川から 水の量を 水の品質を
調達する係 水をくむ係 計る係 調べる係
- 64. ピラミッド型
• 「人が多い」ことが前提だった
• 「コミュニケーション」が重要なスキル
だった
• 下請け企業の役割は、技術では無く
「人材バッファ」だった
- 65. クラウド型調達では
• 非常に小さいチーム
• つくらない技術≒使う技術
が重要に!
– 「組み合わせる」分子式の知識
• AWSのCDP
• Heroku と EC2+SQS
• Salesforce と S3
- 66. SIerの変化
• 分業モデル崩壊による下請けニーズの縮小
• 「コミュニケーション<技術」が鮮明に
• 人材バッファとしての役割は終了
- 74. こだわり過ぎエピソード
• 最初は三菱が開発したが、中島飛行機
もライセンス生産し、あとから改�造し
て燃料タンクを取り付けるなど勝手に
改�良。戦地の整備兵にとってはありが
た迷惑!
• 飛行機によっていちいち部品が違うの
で非能率で、空母上でネジをやすりで
削って使ったりしていた・・・!
- 75. 単体の性能が良くても
戦争には勝てない
• 航空機が戦力として機能するには、
大量生産+運用システムが必要
運用システム
• 空母
• レーダー
• 通信網
• 補給
- 77. 日本では
• 実は技術としては確立していた
• でも、実地で戦闘員がはずしてた
• レーダーがあっても、通信網と
接続されていなかったので無意味
- 78. その頃
アメリカさんは・・
• 開発者を空母に同乗させてた
• 現地で何がおきるか、一緒に把握
して改�良させていた
• 新技術のリーンスタートアップ
- 80. その頃
Amazonさんは・・
• 44兆円のEEコマースサイトをAAWWSS
に乗せて、一緒にサービスを枯れ
させていた・・・!
- 83. 現実
Amazon
Elas9c
Compute
Cloud
(EC2)
Amazon
Elas9c
MapReduce
Auto
Scaling
Amazon
CloudFront
Amazon
SimpleDB
Amazon
Rela9onal
Database
Service
(RDS)
Amazon
Elas9Cache
AWS
Elas9c
Beanstalk
AWS
CloudForma9on
Amazon
Simple
Queue
Service
(SQS)
Amazon
Simple
No9fica9on
Service
(SNS)
Amazon
Simple
Email
Service
(SES)
Amazon
CloudWatch
Amazon
Route
53
Amazon
Virtual
Private
Cloud
(VPC)
Elas9c
Load
Balancing
AWS
Direct
Connect
Amazon
Simple
Storage
Service
(S3)
Amazon
Elas9c
Block
Storage
(EBS)
AWS
Import/Export
- 84. 現実
他社クラウド
Amazon
Elas+c
Compute
Cloud
(EC2)
EC2相当のサービス
Amazon
Elas9c
MapReduce
Auto
Scaling
Amazon
CloudFront
Amazon
SimpleDB
Amazon
Rela9onal
Database
Service
(RDS)
Amazon
Elas9Cache
AWS
Elas9c
Beanstalk
AWS
CloudForma9on
Amazon
Simple
Queue
Service
(SQS)
Amazon
Simple
No9fica9on
Service
(SNS)
Amazon
Simple
Email
Service
(SES)
Amazon
CloudWatch
Amazon
Route
53
Amazon
Virtual
Private
Cloud
(VPC)
Elas9c
Load
Balancing
AWS
Direct
Connect
Amazon
Simple
Storage
Service
(S3)
Amazon
Elas9c
Block
Storage
(EBS)
AWS
Import/Export
- 86. EECC22相当のサービスを使った場合
他社クラウド
EC2相当のサービス
BIND
PosXix
インストール時間
サーバー資源
が必要! squid
MySQL
Backup
監視
- 87. AAWWSSの場合
Amazon
Elas+c
Compute
Cloud
(EC2)
Amazon
Elas9c
MapReduce
Auto
Scaling
Amazon
CloudFront
Amazon
SimpleDB
Amazon
Rela+onal
Database
Service
(RDS)
Amazon
Elas9Cache
AWS
Elas9c
Beanstalk
AWS
CloudForma9on
Amazon
Simple
Queue
Service
(SQS)
Amazon
Simple
No9fica9on
Service
(SNS)
Amazon
Simple
Email
Service
(SES)
Amazon
CloudWatch
Amazon
Route
53
Amazon
Virtual
Private
Cloud
(VPC)
Elas+c
Load
Balancing
AWS
Direct
Connect
Amazon
Simple
Storage
Service
(S3)
Amazon
Elas+c
Block
Storage
(EBS)
AWS
Import/Export
- 88. AAWWSSの場合
Amazon
Elas+c
Compute
Cloud
(EC2)
Amazon
Elas9c
MapReduce
Auto
Scaling
Amazon
CloudFront
Amazon
SimpleDB
Amazon
Rela+onal
Database
Service
(RDS)
Amazon
Elas9Cache
AWS
Elas9c
Beanstalk
AWS
CloudForma9on
Amazon
Simple
Queue
Service
(SQS)
Amazon
Simple
No9fica9on
Service
(SNS)
Amazon
Simple
Email
Service
(SES)
インストール時間0
Amazon
CloudWatch
Amazon
Route
53
サーバー(EECC22)の利用量削減
Amazon
Virtual
Private
Cloud
(VPC)
Elas+c
Load
Balancing
AWS
Direct
Connect
Amazon
Simple
Storage
Service
(S3)
Amazon
Elas+c
Block
Storage
(EBS)
AWS
Import/Export
- 89. 実システムでの比較(コスト)
AWS
EC2相当
EC2
20台
仮想サーバー
45台
ELB
2
約22万円/月
RDS
2
Route53
1
CloudFront
-‐
SES
-‐
CloudWatch
-‐
S3
20GB
Total
約18万円/月
- 91. AWSでは
EECC22以外のサービスが
システマチックに連携しているから
サーバーのセットアップとメンテナンスに
かかる時間が減って
インフラにかかる時間とコストが減る!
- 92. 私が伝えたいこと
• 11点に拘る姿勢は日本人特有
• それが、クラウドの様にシステム
思考が必要なサービス開発には仇
• クラウドの構築は車輪の再発明。
それは得意な人に任せて、
使う技術の洗練に注力しよう!
- 103. よくある懸念
クラウドって、
セキュリティが不安…�
- 105. クラウド特有の脅威
仮想マシン
場所が分からなくて、
なんとなく不安・・・
仮想マシン 物理マシンを共有したら、
意図せず漏洩したりしないか
AWSのオペレーターが情報を
仮想マシン もっていったりしないか?
- 107. AAWWSSのセキュリティモデル
外部
外部 利用者
データ漏えい アタック が防御
仮想マシン
内部同士の共有も、
明示しない限り禁止
仮想マシン
物理的 AAWWSSが
内部 防御
アクセス
- 108. 第三者認証
• ISMS(ISO27001)
• PCI DSS Level 1
• FISMA-Modarate
• ISAE3402 SOC1
(formerly known as SAS70 type II)
- 109. テクノロジー
• 特許技術で、Xenを拡張
• AWS社員も顧客のデータに
アクセスできない
- 114. クラウドも、銀行と同じです
• セキュリティ
– 社内よりAAWWSSの方が堅牢な物理セキュリティを確保
• 可用性
– クラウド側で高い耐久性を維持
(SS33のファイル耐久性は9999..999999999999999999%%)
• 利便性
– ネット越しにどこからでも簡単にアクセス
- 115. NASAと、御社とでは、
どちらがIITTインフラの
セキュリティレベルを保つ
仕組みが整っていると思いますか?
- 116. AAWWSSで、われわれの組織内の
インフラよりもはるかに高い
セキュリティを保てるようになる
NASA
ジェット推進研究所(JPL)のシニア・ソリューション・アーキテクト
カワジャ・シャムズ(Khawaja
Shams)氏
hap://www.atmarkit.co.jp/ait/ar9cles/1301/24/news087.html
- 122. 〜クラウドをやって分かったこと〜
11.. 調達モデルの変化
• 小さいチーム
• 作らない技術の追求
22.. 日本のクラウドとAAWWSSとの違い
• システム思考 vs 一点豪華主義
33.. AAWWSSの導入�に必要なモノ
• 予算→社内・社外に未来を示すこと
• 伝える能力
- 128. Action!
• 変化させよう!
– 変化しない周�りをなげくのではなく、
自分で変化を起こす方法を学ぼう!
– 周�りの一人に、あなたが進めたい技術の話を
してみて下さい
• 変化を楽しんで、
SSIIは楽しい!未来がある!
というメッセージを一緒に発信しよう!