AWS OutpostsとAzure Stackの比較

AWS Outpostsの発表はずいぶん前(re:invent 2018)になされ、私もブログでも言及していました https://cloud.ebisuda.net/aws-outposts%E3%81%A8microsoft-azure-stack%E3%81%AB%E9%96%A2%E3%81%97%E3%81%A6%E6%9C%AC%E8%B3%AA%E7%9A%84%E3%81%AB%E5%A4%A7%E4%BA%8B%E3%81%A0%E3%81%A8%E6%80%9D%E3%81%86%E3%81%93%E3%81%A8/ まだOutpostsは市場には登場していませんが、Youtube上で解説動画が見られることを教えてもらいました。 https://youtu.be/Cnn3BYsE6ug?fbclid=IwAR0FbjkR0wjh3lIUMPbMm9zqeJwV1mO4RzkRIPAZH3nEZEhht1yJ-whPjm4 このような形でしっかりと解説を聞くのは初めてだったので、聞きながらTwitterで感想をつぶやいてみました。 AWS OutpostsとAzure Stack - Togetter Outpostsが予定どおり出荷されて(2019年後半を予定)、オンプレミスでも「クラウド」を利用する機運が高まってくれると良いなとあらためて思います。

May 9, 2019 · 1 min · 胡田昌彦

AWS OutpostsとMicrosoft Azure Stackに関して本質的に大事だと思うこと

AWS Outpostsが発表され、Microsoft Azure Stackとの比較論が出ていたりもします。どちらがいいか…を直接比較…とか比較するのはちょっと違う…とかいろいろ話も意見もありますが、そんなことよりもずっと本質的に大事だと私が思っていることがあります。それは「そのインフラが設計、構築、維持運用されるためにどれだけのコストが払われているのか」ということが大事なんじゃないかということです。 私はインフラエンジニアとして単一システムのための個別の環境を構築したり、統合仮想基盤を構築したりした経験があるのでよくわかっているつもりなのですが、「個別にものすごい労力を割いてシステム、プラットフォームを構築、維持管理している」状況があちこちにあります。そして個別最適化されているので知識の属人化が進み下記のような状況が当たり前のようにあります。 - XXさんじゃないとどうなっているかわからない - システムに変更加えようと思うとどこで何が起きるかわからない - 変更加えるためには徹底的なテストが必要 - でもそもそも全く同じテスト環境は構築できない - 『触らぬ神に祟りなし』なので何も更新しない - 脆弱性があっても修正しない - パッチ当てるにしても人間が一つづつ手作業で目視確認しながら作業する - プラットフォームが古いので新しいOS等に更新もできない - でも、よく考えると単に仮想基盤があって仮想マシンが動いているだけ… - 個別に最適化してしまっているので他社で培われたノウハウも展開できない 結果、あるシステム、プラットフォームにかかっている「コスト」はものすごいことになっているケースが多いです。それはハードウェアの話もありますが、むしろ人的コスト、消費されている時間の方が圧倒的に「やばい」と思っています。 一方、パブリッククラウドに目を向けると…、かなりの部分が隠蔽されているので不明な部分も大きいですが下記のような状況があります。 - 一般的なオンプレミスのシステムの規模は比較にならないような圧倒的なスケールで標準化されている(はず) - 通常のオペレーションも大規模に自動化されてなされている(はず) - セキュリティ対策も一般的なオンプレミスの環境とは比較にならないレベルで徹底、統一化されている(はず) - 世界トップのエンジニアたちのノウハウが投入され続けている - 最新のサービスを提供するように更新され続ける 例えば同じスペックの仮想マシンを1台動かすことを考えます。そのときにその基盤となる環境にかかっている人的コスト、消費されている時間はオンプレミスの方がパブリッククラウドの何倍、何百倍、何千倍、下手したら何万倍のオーダーでかかっているだろうと思います。1人のエンジニアが何台動かせる基盤の面倒を見ているか、何人が使えるシステムの面倒をみているかという尺度でも良いと思いますが、正しいデータが出せずに申し訳ないですがもう圧倒的であることは火を見るよりも明らかです。 かけたコストの分だけオンプレミスのシステムにて特別な差別要素のあることをしているなら意味もあるのでしょうけれども、結局やっているのは「サーバーを塩漬けで動かしてます」という話だとそれって単純に貴重なリソースの無駄遣い…ですよね。 その観点からすると、「差別化する必要があるものに関してはオンプレミスで自分たちで手をかけてやる」「差別化する要素がない部分はもっともコストが低いコモディティ化したもので良い」ということになります。 で、やっとAWS OutpostsやMicrosoft Azure Stackの話になるのですがこれらは究極的に「標準化」されているものなんです。個別に設計するのではなく世界規模で標準化されています。そしてパブリッククラウドのノウハウで標準化されているんです。更新だって勝手にやってくれたり、ボタン一発だったりします。テンプレートやコードだって世界で共通のものが動いちゃいます。これってインフラ構築で個別に苦労したことのあるエンジニアがみんな思う「共通化できたらみんな幸せになるのに」というシステムの1つの形だと思います。それを個別の組織レベルではなく、世界規模で行っているわけです。 そして、どのくらい時間がかかるかはわかりませんが「そういえば昔は個別に基盤構築していたよね」という時代が来ると私は確信しています。それはコンピューター製造に共通企画がなかった所から共通規格ができたように。標準的な通信プロトコルがなくて独自プロトコルが乱立していたところから共通規格ができたように。もちろんニッチな所、本質的に標準化できないところではそれはいつまでも残るのですが「全部まかせといていいよね」という話になります。これは「クラウド時代に「買って済ますべきもの」と「自分たちですべきもの」 | Microsoft Cloud Administrators」で書いたことと基本的に同じ考え方です。 結局何が言いたいのかというと、「自分たちでいちいち個別にプラットフォームを構築、維持管理する必要が本当にあるのですか?よく考えたほうが良いですよ」ということです。そうだね、って気がついた人はパブリッククラウドを利用するのでしょうし、どうしてもオンプレミスという場所にシステムを置く必要があるのであればOutpostsやAzure Stackを利用するようになっていくと思います。むしろそうならなければ行けないと思っています。 とはいえ、Outpostsが登場するのはまだ先ですし、Azure Stackも(組織サイズが大きくないと)値段が高すぎるし…ということでまだまだだと言うことには現時点では同意します。でも、きちんと先をみて、「世界標準のプラットフォームへの対応」を組織としても、エンジニアのスキルセットとしてもしておくべきだと強く思うところです。 この文脈においてOutpostsもすごく人気がでて普及してほしいですし、私が個人的に多くの時間を投資しているAzure Stackの普及も進んでほしいと思っています。「個別の無駄な苦労」はしなくて済むならそれでいいと思うのです。 #ちょっと極論を強い口調で書きすぎたかもしれません。気分を害された方ごめんなさい。

December 18, 2018 · 1 min · 胡田昌彦

Networld.next 2018 DXにて登壇 - 日本のIT業界の未来について思う

今日はNetworld.next 2018 DXにて - 【Networld】3大メガクラウド構築ベンダーがガチンコ対決! - 【Networld】メガクラウド vs HCI ガチンコ頂上決戦! というセッションにて登壇させていただきました。 対決形式、ということで今まで経験のない形式でしたが、私はAzureでのシステム構築をするベンダーという立場でAzure推進の立場で楽しくやらせてもらいました。 今回はNutanixさんが投票で1位になりました。私は1つめが1位,2つめが3位でした。どれも結局そのクラウドや製品の良し悪し…というよりは、登壇している人の口の旨さ的なところと、その場で会場にいた人の感覚に依存した話にはなっているのですが。 いや、でも、私正直なところAWS, GCP, AzureとオンプレミスのHCIを比較するなんて「このクラウドファーストの時代にそもそも比較する対象としておかしい」くらいの感覚でした。そもそも比較対象ですらないでしょと。AWSとGCPとAzureのどれかが一番になって当たり前と思ってました。 なので、結果を見て結構本当に驚いてしまいました。 いや、もちろん私の力不足というのはあります。特に2つ目のセッションはQ&Aのみであり、そもそも話したいこと、伝えたいポイントについてほとんど話せなかった…というのはあります。ですが、それにしても日本のオンプレ思考の強さってのはちょっと本当にまずいんじゃないかと改めて思ってしまいました。 いや、Nutanixさんがクラウド思考だったり、パブリッククラウドとの連携を強めてたりするのはわかってるんですけどね。いや、それにしても。 私が感じている「当たり前」というのは別に私がそう感じるからとかそういう話ではなくて、ガートナーだってそう言ってます。タイミングよくレポート記事を目にしたので画像を引用しつつリンクします。 引用元:OpenStack Days Tokyo:ガートナーが予測する消えるエンタープライズデータセンターの衝撃 | Think IT(シンクイット) 様々なデータをもとに未来を予測するGartnerはもう「エンタープライズのデータセンターは消える」くらいのことを言ってるんです。ポイントは「コンテナ」「サーバーレス」だと。(※私はその先にもう一回(コンテナやサーバーレスの良いところも取り込んだ)PaaSが重要になると思ってるのですが) この世界の流れと、日本のお客さんとの会話の乖離や、このようなイベントでの結果というのはどうしてなのか、どうにかならないのか…そういう思いで「ハイブリッドクラウド研究会」をやってますので、今日のもやもやはそちらの活動にぶつけようと思ってます。 …で、まぁ、本当はなんでなのかというのはわかってるんですよね。記事にも言及があるのと、こちらもタイムリーに業界の解説記事が出ていたのでそちらもリンクしてしまいます。 - [IT業界の仕組みと偽装請負の闇を分かりやすく解説しよう (1/3):「多重下請け+客先常駐+偽装請負」のコンボで業火に包まれるな - @IT](http://www.atmarkit.co.jp/ait/articles/1809/11/news006.html) 詳しくは記事を読んでほしいのですがこういう構造の中では「クラウドを使ってビジネスに貢献するシステムづくりを!開発速度を上げて市場の変化に迅速に対応を!」…っていう発想にならないです。 - クラウドになってしまったら自分たちの仕事がなくなってしまうじゃないか - 早くシステムが作れちゃったら、もらえるお金がすくなくなってしまうじゃないか こういう発想にどうしてもなりやすい構造が業界としてあります。 エンドユーザー企業自体が優秀なエンジニアを高給で抱えて、自社のサービスを継続的に改善していく…こういう枠組みのなかでクラウドを使ったシステムづくりの良さが活きてきます。 日本は業界構造の改善が進まなければ、本当に世界からますます取り残されてしまう…という危機感を私はもう何年もずっと抱えてますが、はてさて。 でも、今日は一緒に登壇した方から、「最近はXXX系でもクラウドの話が多い」「XXX業界はIoTなどにすごく力を入れている」など日本の大手企業も変わりだしているという話を結構聞けました。それはすごく良かったです。

September 11, 2018 · 1 min · 胡田昌彦

(主にインフラ系エンジニアから見た)コーディングやスクリプティングに関しての流れ

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。 もうコーディングレスでLogic Appとかそういうところに飛び込んでもらった方がはやいのかもしれないし、仮想基盤のことやWindows, Linuxの中の事はすっ飛ばしてTerraformとかコンテナとかそこに注力するところから入って必要が出たところで仮想マシン内部の処理に入ったほうがいいのかもしれません。でも、現実的にはシェルスクリプトとかPowerShellスクリプトの基礎とかは抑えておかないとだめかもしれないし・・・。結構悩ましい所です。 - 昔はバッチファイルやシェルスクリプトで繰り返し実施する作業の効率化がありました。 - その後Windows的にはWSHの時代があり、vbscriptでスクリプトを書いたひとも多かったと思います。 - その後Microsoft的にはコマンド毎にオプションが違ったりコマンドがなかったりすることを解決し、全て統一するものとしてPowerShellを生み出しました。(私の大好きな[Jeffery Snover](https://twitter.com/jsnover)さんの仕事です。) - これでMicrosoft系はPowerShellで全てオブジェクト指向の管理となりました。(バックグラウンドにあるのは.net framework) - 一方UNIX系は当初からなんでもかんでもテキストであるという思想でした。 - MicrosoftはPowerShellを標準として様々な製品を開発しました。GUIではできないことでもPowerShellでなら操作できる。GUIで操作しても裏ではPowerShellコマンドが自動生成されてそれが実行されている…というものも多くありました。(結果、仕方がなくPowerShellを使うようになった方も多いと思います。) - Microsoftはクラウドサービスにもその流れを取り入れました。PowerShellにてクラウドサービスの管理も行うことになりました。 - Chef, Puppetなどに代表されるような冪等性を備えた仕組みが登場してきました。(Infrastructure as code, Configuration as code) 何度実行しても「記載した望むべき状態になる」ことを特徴とします。 - これ以前は「これを実行したらこうなる、やって見る前に状態を確認して、やってみて、やった結果を確認する」というような作業の流れを記述するようなイメージでした。 - MicrosoftもPowerShell DSCにて冪等性を持つフレームワークを提供しました。 - Microsoftのオープンソース指向が進む中でよりマルチプラットフォーム化を意識した取り組みがなされるようになっていきます。 - PowerShellの継続開発が打ち切られ、PowerShellCoreに舵がきられます。PowerShellCoreはWindowsだけではなく、Linux, Mac等でも動作するマルチプラットフォームなPowerShellです。(バックグラウンドにあるのは.net core) - AzureにもCloudShellの機能がつき、ポータル上でもコードで制御できるようになります。これまでのAzure PowerShellよりも先にAzure CLI(UNIX系の文化)の方が先に搭載されました。Azure管理はPowerShellよりもCLIの方が優先されるようになってきています。 - クラウドサービスも普及する中で、大規模な環境ではもう個別に1台づつターミナルで作業するなり、RDPではいってGUIで操作するなりすることが現実的に不可能な規模になりました。このような環境ではコードで全てを制御可能な環境にすることは必須条件となりました。 - WindowsもWindows Server Coreが出てGUIがなくなり、さらにNano Serverにてどんどん軽量化していきます。 - Windows Server 2016, 2019となると継続的に進化するモデルはGUIが利用できなくなりました。 - 更に軽量化を推し進める中で仮想マシンではなく、コンテナに大きくトレンドが傾きます。 - コンテナの標準であるDockerはDockerfileというコンテナをコードで定義できる機構を備えています。 - クラウドサービスも冪等性をもったテンプレートにて展開可能な構造となります。AzureであればARMテンプレート、AWSであればCloud formationなど。 - ARMテンプレート、Cloud formationによるInfrastructre as Codeと仮想マシンの内部を構成するChef, Puppet, AnsibleのようなConfiguration as Codeによって仮想マシンベースの環境構築の完全自動化が可能となりました。 - ARMテンプレート、Cloud formationによるInfrastructre as CodeとDockerによるコンテナコントロールで完全自動化が可能となりました。 - 複数のコンテナプラットフォーム自体のコントロールという観点ではKubernetesが標準化してきています。 - AWSLambda, Azure Fuctionsのようなインフラ自体を意識せずアプリケーションロジックのみを記載すればそれでおしまいとなるようなサービスも出てきました。ここではInfrastructure as CodeやConfiguration as Codeすら必要ない世界があります。(これですべてまかなえるわけでもないですが) - DevOpsという流れもありますが、NoOpsに向かう流れの方が強そうに感じています。(私の感想) ※NoOpsはインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。 ...

May 16, 2018 · 1 min · 胡田昌彦

2017/03/03 今週のトピックス

今日は桃の節句ですね。さて、今週のトピックスです。 - Announcing preview of Azure HDInsight 3.6 with Apache Spark 2.1 | Blog | Microsoft Azure 1 user Get credits that enable: 4 Windows or Linux Virtual Machines 24 x 7 for a month And much more… Learn more [azure.microsoft.com ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fazure.microsoft.com%2F) - テクノロジー - あとで読む - [![ebibibi](https://ebiwordpress.azureedge.net/windowsadmin/profile_l.gif)](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, azure ![Twitterでのツイートを閲覧](http://cdn-ak.b.st-hatena.com/images/icon-twitter.png)27 clicks 2017/03/03 - Azure Command Line 2.0 now generally available | Blog | Microsoft Azure 1 user Back in September, we announced Azure CLI 2.0 Preview . Today, we’re announcing the general availability of the vm , acs , storage an… ...

March 3, 2017 · 3 min · 胡田昌彦

パブリッククラウドではブロードキャスト/マルチキャストを使えない

最近パブリッククラウドを検証用途でちょっとずつ使うようになりました。管理者権限がないのでちょっと触る程度なのですが…。(貧乏性なので、自腹で環境を持つ勇気が出ないのです。) パブリッククラウドのIaaSにオンプレミスで作成したスクリプトをそのまま持って行っても動かずびっくりしたのが「ブロードキャスト/マルチキャストが使えない」ということです。ちょっと考えれば当たり前なんだろうなとも思うのですが、完全に考慮外でした。 ブロードキャストがつかえないんじゃぁ、arpも通らないの?そんなわけないし…と思って検索してみたらいろいろ面白い記事を見つけて読みました。 - [EC2でブロードキャスト/マルチキャスト | Techy? Geeky? Whatever!](http://kentiest.wordpress.com/2013/03/23/ec2%e3%81%a7%e3%83%96%e3%83%ad%e3%83%bc%e3%83%89%e3%82%ad%e3%83%a3%e3%82%b9%e3%83%88%e3%83%9e%e3%83%ab%e3%83%81%e3%82%ad%e3%83%a3%e3%82%b9%e3%83%88/) - [The Limits of Cloud: Gratuitous ARP and Failover | Cloud Computing Journal](http://cloudcomputing.sys-con.com/node/2469233) amazonの情報は日本語ですら見つかりますが、Azureの情報はほとんどないですね。 クラウド上ではクラウドの流儀でいろいろなことを行わなければいけないということを実感しており、やっぱりみんなでクラウド…ってわけにもいかないなぁと再認識しております。

October 30, 2013 · 1 min · 胡田昌彦