「OpenStack」を含む日記

はてなキーワード:OpenStackとは

2025-05-28

■anond:20250528222518

Kubernetes＋マネージドクラウドという“上位互換”の普及で陰るOpenStack（および旧来型プライベートクラウド）が、増田の嘆く「死にゆく技術」と読むのが最も整合的です。

■anond:20250528222518

この文章が指しているのは、おそらく「AWS」や「クラウドインフラ」関連の技術ではなく、もう少し狭い領域の技術、特に「コンテナオーケストレーション技術（Kubernetesではない方）」、あるいは「仮想化技術（VMwareなど）」、さらに絞ると「OpenStack」や「オンプレミスのプライベートクラウド技術」を指している可能性が高いです。

理由は以下の通りです：

• 「数年前までは結構勢いがあった」という記述は、例えばOpenStack などが一時的に注目されていた時期（2010年代前半〜中盤）を示唆しているように読めます。

• 「上位互換の技術の台頭」は、Kubernetesやパブリッククラウド（AWS、Azure、GCP）の進化を指している可能性が高いです。

• 「プロジェクト終了」という流れは、企業がオンプレや自社構築のクラウドから、よりコスト効率が良く運用負担が少ないパブリッククラウドに移行していく傾向を表しています。

• 「小手先の技やTipsばかりがうまくなった」という言葉は、例えばOpenStackや特定のミドルウェアの細かい設定やトラブルシューティングに強かったが、根本的なOSやネットワークの理解が浅かったことを示唆しています。

もしこの仮説が正しければ、この技術は「OpenStack」や「VMware vSphere」といった、かつて企業のデータセンターやプライベートクラウド構築の主役だったものの、クラウドの台頭により徐々にシェアを失っている領域を指していると考えられます。

さらに深読みすると、この「上位互換の技術」とはKubernetes であり、より広く言えばパブリッククラウドサービス（AWS,Azure,GCP）のことを指しているのでしょう。

この技術の死に直面している筆者の無念さや、自らのキャリアの喪失感、そして基礎的なCS（Computer Science）の重要性を痛感する気持ちは非常に共感できますね。

Permalink |記事への反応(0) | 22:40

ツイートシェア

2024-06-14

■

IIJの業績見通し、VMware 製品の値上げによって「変動幅30億円」
　実際、IIJは2024年 5月10日に開示した2025年 3月期の業績見通しにおいて、VMware 製品ライセンスの値上げをユーザー企業に転嫁できるかどうかによって、売上高に当たる売上収益と営業利益が最大30億円は変動する可能性があるとした。
IIJは2025年 3月期の決算見通しに30億円の幅を持たせる異例の開示をした
（撮影：日経クロステック）
[画像のクリックで拡大表示]
　IIJは2024年 4月からクラウドサービスの利用料金の値上げを実施したが、全てのサービスの値上げが完了したわけではない。ユーザー企業への価格転嫁が遅れるほど、IIJの損失が膨らむ。その損失額が最大30億円になると見込んでいる。
　IIJの2025年 3月期における営業利益の見通しは300億～330億円である。VMware 製品ライセンスの値上げによって、全社営業利益の1割が吹き飛ぶ恐れがあるわけだ。同社が決算の見通しに幅を持たせたのは初めてという。

そんなにVMWare 依存してたんか・・・・

てっきりOpenStack？とかいう独自の基盤で運用してるのかとオモタ

VMWare しか使えないレガシーアラフォーアラフィフおじの雇用も代替が利かないわけで、

いまから別の仮想化経験者とか探すの無理やし地獄やな・・・

Permalink |記事への反応(2) | 19:24

ツイートシェア

すまん、それはそうだ。さて、オンプレで作るとして、どうする？国内でサービスをするとして、全国津々浦々にCDN エッジサーバーを置いて、東京大阪にアプリケーションサーバーをおいて互いにレプリケーションをさせて、コールドデータは石狩におく。ソフトウエアはOpenStack なんかを使いつつ、費用を抑える。各リージョンに 1Tbps の帯域保証をつけた専用線をひき、不足するぶんは共有線でなんとかする ... って感じですかね？

Permalink |記事への反応(0) | 20:24

ツイートシェア

2018-09-19

■とある 会社で機械学習 環境を整備しているんだが心が折れそうだ

昨今流行りの機械学習でプロジェクトがぽこぽこ立ち上がっている状況なのだが、一部の人を除き、apt-getで躓いているのは会社にとって損失だと考え、オンプレクラウドのようなものを構築することにした。

グループ全体の規模はそこそこ大きいが、将来単なるアッセンブリー屋になることが目に見えている事もあり（今後20年以内には喰われてしまうという憶測もあり）ネットワーク、Linux、コンテナ、プログラミングが出来る自分が社内の機械学習、引いてはIT インフラの民主化、なんだったら外販できるくらいのもの作ってやろうと鼻息巻いて無理やり一人プロジェクトを興すことにした。

まずは既存 DHCP サーバ、名前解決ができないDNS サーバからゲートウェイ PCを用いてネットワーク的に分離、社内の物理的な設置スペースの問題でデスクトップ PCとサーバ PCが離れた所にあるため、WireGuardでVPN構築、ゲートウェイ PCはそれぞれKeaDHCP サーバ、PowerDNS サーバを稼働させ、OpenStack導入検討時に悩んだ鶏が先か卵か先か問題を解決することにした。

上述の通り、システム構築にあたってOpenStackやMAAS,RancherOSなどを検討したが、社内のニーズを「100%」汲みとった上で、次世代のオンプレクラウド（個人的にはエッジクラスタがゆるく繋がるアメーバクラウド？のような呼称があっている気がするが）を構築するにはどれも痛し痒しで何かしら制限がついて回るのは許容できなかった。これは今後5年、特に海外事業所の開発者の事を考えた時には外せない要件だった。

とはいえmiekg/dnsを用いてCoreDNS 進化版を作るにはリソースが足りず、BINDを用いるにはSA 対応がしんどすぎるため、APIを備えており、今後も進化が見込めるであろうOSS、また必要であれば商用製品や保守サービスが受けられる事から上記2つを選択した。

PowerDNSはさておき、ISC KeaはナウでYANGなLinux YANGに対応しようとしているなど（言いたかっただけ）、世の中のオンプレ環境を塗り替えるためには兎にも角にもAPI ゲートウェイが重要だと考えたため、双方が提供しているAPIをうまく吸収するミドルウェア（とちょっとしたAPI サーバ）をGo 言語で作成した。

次に世の中のパブリッククラウドやOpenStackなどを触ったことのある開発者はCloud-initに慣れているはずという前提の元、対応コスト勘案の結果、NoCloudで対応しつつ、上記のAPI サーバと連携し、ベアメタルマシン管理した事のある人はわかる、ベアメタルマシン特有の諸問題を解決することにした。

まぁなんだかんだ大企業なのでお金で解決する手段もあるが、そもそも高集積ラック搭載GPU サーバ購入の稟議が通るような会社だったら既にKubernetes導入しているだろうし、俺もこんなことしてない。

脱線したが、上記以外にも検証やバックアッププランとしてAnsible記述などの作業はありつつも、3ヶ月かけてようやく基礎となるインフラ基盤が構築できたため、nuxt.js+goで簡単なフロントエンドサーバを構築し、一人情シスの様相を呈している部下のリソース開放、Calico 対応+Kubernetes導入、不安がっている上席が安心できるように、分かりやすい餅を用意しようとしている、というのが現状。