  |
はてなキーワード: AZUREとは
契約してる1つのサーバで個人ブログとか昔ながらのBBSとかブラウザゲームとか種類が違うサービスをいくつも運営しているけど、サーバの運用方法が流石にレガシーすぎるからもうちょっとモダンな感じにしたいと思ってる。
でも中々抜け出せない。
まず前提としてAWS,GCP,Azureは高いから使えない、同スペックなら適当なVPSの方が圧倒的に安い。
最近流行りのコンテナ構成みたいなのもいくらDockerが昔のVMに比べるとリソース食わないと言っても例えば
「1つのサーバで10個のサービスを相乗りで運営しなければならない」みたいな場合に1サーバ内で何十コンテナ起動みたいなの運用すると流石に相当重くなっちゃうよなぁ。。。
あとnode.jsとかginみたいに1サービスごとに常駐プロセスが増える技術スタックも多分あんまりよくない、必要ポートを管理するのも大変
結局自然と行き着くのは格安VPS借りてLAMP構成作ってVirtualHostで相乗り設定して昔ながらの方法で運用する方法になっちゃう
php+apacheの構成ならアクセスの少ないサービスを何十個運用しようとアクセスがないならそれにリソース食われることがないんだよね、何気にLAMP環境の結構な強みだと思う
もっと良い方法見つけたいし、多分お金かければあるんだろうけど
月2000円以内くらいで多くのサービスを運用したいってなった場合に結局これ以外の選択肢ってなくない？
月1～2万円みたいな額はインフラエンジニア雇う費用に比べると全然安いんだろうけど、ポケットマネー基準だとそうもいかない
https://www.sofia-inc.com/blog/7233.html
情シス（情報システム部）はもういらない？これからの情シスに求められる、あるべき姿とは？
皆さんは情シス（情報システム部）が果たす役割・機能を何だと考えますか？ 全社のIT戦略策定・システム企画、社内インフラやアプリの保守・運用、ユーザーサポートやトラブル対応といったことを思い浮かべる方が多いのではないでしょうか。
しかし昨今、情シスにそのような役割が求められていない、もしくは情シスの業務自体がなくなりつつあることをご存知でしょうか？
今回の記事では、これからの時代の情シスに求められる役割、あるべき姿について説明します。
近年Microsoft AzureやAmazon Web Serviceといったクラウドサービスの台頭により、オンプレミスからクラウドへの流れが起きています。社内に物理サーバーを置いて保守・運用するといった必要がなくなり、ソフトウェアもPaaS・SaaSといったクラウド上で提供されるサービスに代替されるようになってきています。それに伴い、膨大な設備投資費や社内SE（システムエンジニア）の人件費を削減できるようになりました。今後すべてのITリソースの保守が必要なくなるという可能性もあります。
デジタルトランスフォーメーション（DX）が多くの企業で重要課題となっている現代において、企業がIT活用で目指すべきことは、単純にITインフラ・ツールを変革させるということではありません。業務変革・組織変革を伴うような、より大きな次元での変革です。経済産業省も、ITを変えるだけがDXではないと説明しています。
「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」
このデジタルトランスフォーメーションの実現を企業が目指すにあたって、情シスの仕事も大きく転換しようとしているのです。次章では、まず従来の情シスの役割について整理・紹介していきます。
DX（デジタルトランスフォーメーション）を推進する上で押さえておきたい3つのステップ
昨今ビジネスの場において、DX（デジタルトランスフォーメーション）という概念が頻繁に取り上げられるようになりま…
これまでの情シスに求められていた役割は主に以下の４つでした。
会社の経営戦略や事業戦略に基づき、システムの企画立案・要件定義をする役割です。社外ベンダーの見積もり検討・選定、およびその後のプロジェクトマネジメントを遂行し、ユーザー部門に対して新しいシステムを開発・提供します。
社内ユーザー部門からのリクエストや業務プロセスの変更に応え、既存システムのカスタマイズなどを実施します。運用・保守によってシステムを安定稼働させ、会社の事業活動を下支えする役割を担います。
自社サーバーやネットワークの構築・運用・保守を行いつつ、セキュリティ対策やデータ保全を実施することで、万が一の事態に備えます。また新技術・製品の導入検討や評価を行って、常に社内環境のサービス向上に努める役割です。
社内ユーザーからの問い合わせ対応・トラブルシューティングを行います。ツールやシステムの導入サポートの他、新卒や転職者へ社内システムの教育を実施することで、社員１人1人の円滑な業務遂行を支援します。
以上が従来情シスに求められてきた役割ですが、現在のクラウド時代において運用・保守業務はその必要性を失っています。また業務システムについても、SaaSなどのクラウド上で提供されるアプリケーションを利用できるようになっており、企業独自でシステムを構築するということは少なくなっているのです。
このような中で、今後情シスには一体どんな役割が求められてくるのでしょうか。次章で詳しく解説していきます。
クラウドで提供される業務システムは、往々にして業務の生産性に関する考え方が先進的であり、しかも随時バージョンアップしていきます。従って「自分の行動にシステムを合わせる」のではなく「システムに自分の行動を合わせる」というのが日常的に求められるのです。
しかし事業部門をはじめとする多くの社内ユーザーは、旧来の業務のやり方に慣れ親しんでいるために、「システムに自分の行動を合わせる」ということに自力で順応するのが容易ではありません。システムを使いこなせないばかりか、新しいテクノロジーに対して抵抗感を覚えてしまうケースもあります。
そこで必要となるのが、自社の業界・事業・業務においてITツールをどうやって活用するかを考え、そのための情報を関係各所へ提供する存在です。これからの情シスには、システムの機能や技術面だけでなく現場の業務プロセスにまで入り込み、具体的なユースケースを提案・サポートすることで、全社的なIT活用を推進する役割が求められています。
また、会社としてDXを推進するうえでは、単にITツールを組織的に活用することだけでなく、同時にチェンジマネジメント（組織変革）を進めていくことが必要です。新しいワークスタイルを実現するためには、職場の文化・風土も変革していかなければなりません。次章ではDXを促進する立場としての情シスの役割について紹介します。
クラウドサービスの台頭でIT部門の仕事がなくなる 企業のIT部門の仕事、と聞いて何を思い浮かべるだろうか。自社の…
DXを促進する情シス（情報システム部）の役割と専門家との協働
デジタルトランスフォーメーションにおいて最も上手くいかないことの１つとして、先進的なITツールに対して個人個人の理解度・受容度が追い付いていけず、会社として変化を受け容れられないことが挙げられます。ツールの機能、業務プロセスへの適用法が分からないことで現場が混乱し、これまでの業務のやり方やワークスタイルから脱却できないといったことがそれにあたります。
これを解決するために必要となる活動が会社のカルチャーチェンジ、社員一人一人のマインドチェンジです。単にITツールの活用法をナビゲートするのみならず、業務プロセスや職場の文化・風土というところまで踏み込んで、ユーザー部門に対して新しいワークスタイルの実現に向けた啓蒙活動を展開していったり、全社的な意識改革に向けたコミュニケーションを展開していったりといった役割がDX推進には不可欠なのです。
しかしこの役割は、専任のDX部門が担おうとしても失敗するケースがあるほど難しいものであり、そもそも経営層が事業戦略におけるITの重要性を十分に認識していなければ到底実現できるものではありません。では、情シスがDXを推進する役割を担っていくためにはどのようなアプローチをしたら良いのでしょうか。
それは情シスが持つIT知識や社内システムへの知見を最大限利用し、経営層を巻き込んで企業を変革する旗振りをしていくことです。ただし限られたリソースの中で上層部や会社全体に働きかけるというのは非常に負担が大きく、失敗に終わる可能性も大いにありえます。そこで１つの解決策となるのが、そういった業務改革・組織改革の支援を行うITベンダーと協働することです。高い技術力と豊富な支援実績を持ったITベンダーが上層部への答申からITツールの全社展開まで幅広く支援してくれます。そして、組織風土変革や社内へのコミュケーションは、自社の人事部門や広報部門が実務として実施していきます。現場部門との協働はもちろんですが、変革を企画する部門と協働することで、より全社的なムーブメントをつながります。
まとめ
以上のように、近年情シス（情報システム部）に求められる役割は大きく転換してきています。従来担ってきたITインフラやシステムの構築・保守・運用業務は不要となり、今後はデジタルトランスフォーメーション（DX）実現へ向けた社内ユーザーへの情報提供・啓蒙活動を行っていくことがその使命となっていきます。
もしあなたが情シスのメンバーであり、従来の役割を脱却できずにいるのであれば、業務改革・組織改革支援を行うITベンダーの活用を検討してみてはいかがでしょうか。
ウクライナのニュースみて思ったんだけど、第二次世界大戦のときに比べて、私企業の制裁の破壊力って滅茶苦茶増してると思うんだがどうだろう？
具体的にいうと、MicrosoftやAppleのロシアでのビジネスストップをみて思ったんですよ。
現代社会って企業体が大きくなりすぎて、私企業による私刑みたいなことが可能ってこと？
プーチンじゃイメージわかないから、例えば岸田総理が東アジアの隣国あたりに侵攻したとするじゃん？
それにアメリカの企業がブチ切れたら、↓みたいな対応もできちゃうってこと？
Master「うちもやめるわ」
Diners, Amex「俺らもやめるわ」
Microsoft「Office売るのやめるわ。365も契約させない。OnedriveもSharepointも止めたる。日本だけWindows更新させねぇ。脆弱性放置してやる。」
Google「岸田支持の検索結果は検索に引っかからんようにするわ。そういう動画はYouTubeからもBANする」
Facebook「FacebookとインスタからもBANするわ」
Netflix「岸田をヒトラーにする作品作るわ。岸田が開成で二浪しても東大に入れなかった話とヒトラーが美大に落ちた話くっつける」
Amazon「それいいな。じゃあプライムビデオで、新しい資本主義発言とスターリンをくっつけてなんか作るわ」
↑こういうことされたら、だいたいの国が半年持たないんじゃないですかね？
巨大企業がこういうこと出来ちゃうとしたら、安全なのは企業が商圏として無視できない国、実質アメリカと中国以外は企業に屈するしかないと思うんです。
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
・機械工学は大学で学んだ。機械系４力学のさわりだけなら大体やったがもう忘れている。
・切削加工はけがき、フライス盤、ボール盤、くらいならできるが複雑な形状は作れる気がしない。そういえば旋盤は使わなかった。耐久性を考えなければ３Dプリンタでなんでも作れるらしいが、３Dプリンタは触ったことがない。
・CADは大学の演習でSolidWorksを触った程度。もうすっかり忘れている。手書きの製図とかは調べて思い出せば簡単な形状ならできるかもしれない。
・シミュレータはANSYSをマニュアル通り触った程度。動力学解析とか連成解析とか仕組みは全くわかっていない。
・電気工学はだいぶ勉強不足。簡単な回路図はチップの製品情報を睨めっこしながらINとOUTと接地をどうすればいいかくらいはわかったが、複雑なものになるとダメ。ArduinoとRasberryPiは買ってみたが埃かぶっている。論理回路の読み方はすっかり忘れているが調べれば思い出せると思う。
・化学系は全くの無知。大学受験で知識は止まっている。物性物理的なところも無知。
・数値計算はPythonやMatlabでちょっとできる程度。ライブラリを使った行列計算や簡単なニュートン法くらいなら書けるが、精度や速さが必要だったり複雑になるとダメ。解析は微分積分や常微分方程式を調べて思い出せばできる程度。測度論とか特殊な積分とかいわゆる大学数学的な道具が必要になる解析はできない。
・競技プログラミングはちょっとかじったがやめてしまった。むずかしすぎた。
・機械学習や統計はなんとなく知識はついているが、手を動かして何か作ったことはない。この前統計検定１級落ちた。
・バックエンドはSQLをそれなりに書いてとりあえず動くものなら書ける程度。可用性とかパフォーマンスとか考えられるレベルではない。JavaはJavaEEを横展開的に書いた程度。理解できている自信はない。保守性高めたりデザインパターン的に綺麗な書き方とかできない。C++は一瞬だけ触ったことがあるが、環境構築ハマった＆謎のSegmentation Faultで苦手意識を残したまま。Go？Rust？なにそれおいしそうだね。
・クラウドはAWSをマニュアル通りに使っている程度。１から設計なんてできない。なのでAWSのソリューションアーキテクトを勉強中。AzureやFirebaseは触ったこともない。
・ネットワーク系とかセキュリティ系は全く勉強不足。応用情報をギリギリ合格できる程度の知識しかない。わかるようにはなりたい。
・フロントエンドはFlutterを勉強中。Flutterむずかしい、どんな言語でもそうだけどチュートリアルから業務レベルまでの乖離がありすぎてよくわからない。javascriptはjQuery一強時代にちょっと書いた程度。VueとかReactとかなにもわからない。TypeScript？なにそれおいしそうだね。
・ハード系だったりファームウェア系だったりコンパイラ系は何もわからない。わかるようにはなりたい。
全部中途半端だな、、、
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
AWSとかAzureとかGCPは内部ネットワークはunmeted（無課金）だからつまりクラウド自体の料金も安くなるメリットがあるんだよな。
10MBのファイルを100回ダウンロードするだけで1GBに達してしまうが、VDIなら画面情報の差分を圧縮して送ってるだけなので8時間の勤務で300MBとかですむ。700MBの差で100人社員がいたら1か月の転送量は1.4TBになってクラウドの追加料金がかかる。（たいていクソ高い）
ただし、VDI先のマシンでユーチューブとかにアクセスされると画面情報の差分もふえて転送量が増えてしまうから、URLブロックとかが必要かも。それについても端末に設定するんじゃなくてVDIのマシンに一括設定すればいいだけだから、遠隔設定が不要でラクになる。
このあたりの説明、わかってくれる人はわかってくれると思う。
サーバに複数のディスクを追加してRAIDを構成することはできますか?
ソフトウェアRAIDを使用することで可能です。ただし、さくらのクラウドでは以下の理由により非推奨としています。
1サーバに接続可能な最大ディスク数は3台のため、構築可能なRAID構成パターンが限られる
ストレージ内データのバックアップはストレージサーバごとに異なり、バックアップデータからの復旧時に各追加ディスクのバックアップ取得時間が異なってしまうためリストアができなくなる場合がある
https://manual.sakura.ad.jp/cloud/support/technical/storage.html
関数型プログラミングが『銀の弾丸』であるという非常識な常識2022のなにがダメなのかわからない人が多いようなので、個人攻撃をまったくせずにダメ出しする。
まず言っておくが、私はあの記事をほとんど読んでいない。しかし、簡単にダメ出しできる。
記事内を「末尾再帰」で検索してみよう。1か所もヒットしない。「末尾」でも1か所もヒットしない。そう、あの記事はめちゃくちゃ長いのに末尾再帰に触れていないのである。では「再帰」ならどうだろう。11か所ヒットした。しかし、具体的な再帰のコードはまったくない。長い記事内にあれだけ多数のコードを書いているにも関わらずである。
「末尾再帰って何？」とか「再帰ってそんな重要なの？」と思う読者も多いだろうから、末尾再帰の重要さだけ説明しよう。
あの記事は、forやwhileを使わないプログラミング手法を前提に書かれている。記事内を「制御」とかで検索すればわかる。
末尾再帰はforやwhileの代わりになるもので、そういったプログラミング手法には欠かせない。forもwhileも末尾再帰も使わないとなると、ツリー探索などのアルゴリズムを書くことが困難になる。(こういったことが苦手な私に思いつく他の方法は、setIntervalを無理やりforループの代わりにするくらい)
そもそも、ほとんどのJavaScript実行環境は、末尾再帰をサポートしていない。つまり、JavaScriptはforやwhileを使わずに込み入ったプログラムをまともに書けるような言語ではない。あの記事に書いてあるようなことをする言語ではないのである。私は別にそれでもいいのでTypeScript使いまくってるけど。classとか好きだし。
あの記事がJavaScriptを使っている理由は、JavaScriptが人気だからだろうか？もしそうだとしてもダメである。あの記事は「JavaScriptは、ほどんどの実行環境が末尾再帰をサポートしていない、このプログラミング手法に適していない言語である」といったこと自体に触れていない。人気のある言語を使いたいなら、他の末尾再帰をサポートしている人気言語を使えばいい。
ろくに読まなくても、他にもダメ出しできる。
関数型プログラミングで気になるのは、言語にもよるが実行速度やコンパイルにかかる時間である。銀の弾丸と言うからには、C言語を使うような場面でも銀の弾丸でなければならない。(Haskellの実行速度はC並に早くできるそうだが)
記事内を「パフォーマンス」で検索したところ、実行速度に関する箇所がヒットした。
記事の実行速度関連の内容を要約すると「最近はAWS・Azure・GoolgeCloudPlatformなどを使って並列計算するので、昔ながらの命令型の順次実行は不適切である」となる。私が嘘を言っていると思うなら、記事内を「パフォーマンス」とか「AWS」で検索してヒットした箇所の前後を読んで欲しい。そんなに長くはない。
昨日見つけたいくつかのGitHubのリポジトリを面白く眺めてる
20代のフランス人だったり、40代のブラジル人だったり、色々である
ブラジル人は体力有り余ってるのか、
絵だとやりにくいなぁ、と思ったりする
みんなでブクブク浸かって楽しむみたいな世界は、
で、思ったのは、やはりプログラミングというのは、
過去のゲームがルールの発明だったこととかは古臭いものとなり、
コードも言葉と同じように無償で自然と発するものに近づいていく
ここで思うのは、スティーブ・ジョブズがこの世界をIBMの、
いわゆる、ソフトはハードのおまけ、の世界に戻したことであり、
ビル・ゲイツだったか、ソフトウェアは無償化していくという予言は当たっていたのだろう
それをマネタイズするには、ApacheでWebサービスを立ち上げるみたいな、
いわゆるGNUライセンスであれ、運用やサポートではお金が取れるが、
Node.jsを開発したら、開発者は当たり前だが一番Node.jsに精通しているわけで、
企業を顧客にNode.jsのサポートを有償ですることでマネタイズできる
ソフトウェアは無償化し、コードは会話のように無償で、ライブなものになり、
あー、そういう世相を予測して、
先に牛耳っておこうという点でMicrosoftによるGitHub買収は正しかったのである
ソフトウェアがなんでも無償に向かうのはMSとしても良くは思えない動きだったはずだが、
今はまったく反対方向にMSは向かっており、収益の基盤をAzureなどに移している
今すぐはありえないが、WindowsというOSも意味はなくなっていく
これはAppleやGoogleのような企業でも同じ考えのように思う
もちろん、そのレベルでのシェア争いや小競り合いが今すぐ消えてなくなるわけではないが、
長い目で見ればいつかはそうなっていくことは容易に予想できるわけで、
つまり、ソフトウェア産業というか、近年のバズワードでもあるテック産業というのは、
人生だって、みんな崖に向かって歩いたり、走ったりしてるだけである
その崖がどれだけ近いか遠いかとか、どれぐらいのスピードで崖に向かってるかとか、
それだけの違いであって、誰もがいつかは崖に到達して落ちる、つまり死ぬのである
しかし、そこには一発逆転や一人勝ちするチャンスも乏しくなり、
そういった金を求めるギラギラしたアブラギッシュは寧ろ嫌悪される存在となり、
しかし、そうやってった末に待っているのはコモディティ化であり、
ただの暇つぶしにさえなっていく
今は楽しい
でも、その楽しさの果てに死が待っている
はてな界隈では珍しいであろう船員という職業へ就いている35歳男性である私は小選挙区は自民、比例区は維新へ票を投じた。
我が海運業界ははてな界隈の一部の者たちが知るように、第二次世界大戦終結後の復興・高度経済成長期に時の政権による暴虐非道な対応によって自民党へ対し相当な恨みつらみを持つ業界である。
即ち、私たち海運業界は両手を挙げて自民党を支持することはなく、毎度毎度警戒心をもって自民党のやることなすことを見ているというのが海運業界の慣例的な姿勢である。
「また裏切られるのではないか？」という疑念は早々に晴れるものではない。
ただ、勘違いしてならないのは私たち船員は海事学生であった頃から本邦の物流を支える基礎土台であることを骨の髄にまで叩き込まれることが常であり、このような指導姿勢はもはや宗教と言っても良いレベルで「我々海運業界こそが島国日本の経済を支え、その滅私奉公は誇り高いものである」と船員ならば誰しもが心のどこかでこのような思想を信仰している傾向があると言える。
つまり我々はどこまでいっても「お国のため」「国民のため」「未来のため」と思って仕事をしているのだ。だからこそ今回議席数を減らしてしまった野党へ言おう、
本邦は島国であることは幼稚園保育園児でも知っている常識的な立地条件であり、経済が立ち行かなくなりモノを失った島国が行き着く先は他国から奪うしか無いのだぞ。
これを極論だと言うのは愛を知らぬ者か、愛を受けるだけしかしてこなかった者だろう。
愛する者が居る者たちに問う。愛する家族が子が友人が仲間が食えなくなったとき赤の他人のことなんぞ関係あるか？自分が食えなかったとしても愛する者へ食うものを与えるだろう？食うものが無ければ奪うだろう？自分が悪役に、人殺しになりさえすれば愛する者が食えると言うなら選択肢は1つだろう？
これに納得できない者たちは知っているか？我が海運業界は「憲法改正に反対していない」ことを。我が海運業界は「憲法改悪に反対している」ことを。
何故かわかるか？日本はいわゆる地政学上の概念でシーパワー論を重視する傾向にあり(島国だから必然的にそうなる)、日本が無謀なことにアメリカへ戦争を吹っ掛けたのはアメリカが日本の海運シーレーンを掌握しようとしたからだ。
日本のモノが無くなる危機へ対して起こったのが太平洋戦争であり、そもそも第一次世界大戦でロシアが物流の橋頭堡を作ろうとしたのがロシア南下政策なのだよ。
更に言えば日本の戦国時代が興った有力な説を知っているか？冷害による飢饉だぞ？食うものが無いから他国から奪えと内戦をやったんだよ。
何故、海運業界が憲法改正に反対せず改悪に反対するか、それはシーレーンを守るための保険をとっているからに他ならないんだ。
SDGsによって国内産業が致命的な状況へ陥るかも知れない、経済が冗談抜きで崩壊するかも知れない、島国日本がモノを失うかも知れないというときに野党キサマらは何をやっているんだ？戦争をそんなにしたいのか？島国日本で海上自衛隊員の数が足りなくなった際に誰へ、何処の業界へまず赤紙が届くかキサマら理解してないのか？
妻と子が居る船員の私に赤紙が届くようになった情勢下では私の選択肢は1つしか無いんだよ！悪役に！人殺しになるという選択肢しか無いんだよ！
目下重要なのは、EUの排ガス規制への対策。
EUの排ガス規制は製造段階から既定値以上のCO2が発生が確認されると著しく輸入を制限するというものであり、化石燃料を用いる自動車などの工業製品へクリティカルに影響してくる部分だ(CAFE規制)。
忘れちゃならないのは、EUはAppleやGoogleなどへも厳しい姿勢を取ることが有名であり、現在のCO2規制ではハードウェアのみを対象としているものの、これがソフトウェアへ規制拡大しないという保証が何処にもないことだ。
大規模なサーバー網を抱えるWebサービスの消費電力へ対しCO2規制が入った場合にどうなるかははてな界隈の者たちのほうが詳しいのではないか？
ある日いきなり「アナタのところのWebサービスはEU規制により増税・罰金対象です」と通達される日が来ないとでも本気で思うのか？
当然その対策にAWSやGoogle Cloud、Microsoft Azure、Akamai、CloudFlareなどは価格を上げるだろう。
リモートワーカーにも他人事ではなくなってくるかもな。
EUは規制によって自国産業保護をすることへ間違いなく旨味を覚えいる状況で、よく調べもせず何でもかんでも新自由主義などとレッテルを貼って無自覚にEUの自国産業保護政策を後押しする者たちの体たらくには開いた口が塞がらないし、それ以前に今回の選挙で間違いなく重要であった経済分野を主軸と捉えられず、桜を見る会やモリカケ、夫婦別姓や同性婚が最重要のような言動をしていた者たちへは「本当に労働者か？！」と疑いの目すら持ちたくなってしまう。
冗談抜きで仕事無くなる可能性のある動きが世界で行われている状況で、公文書偽造問題を精査することが第一声という党に民意が見えていると本当に思うのか？
「私たちの仕事を守る気は無いのか？！」と「コイツら何にもわかっちゃ居ねぇ！」と目を見開いてしまった多くの国民は愚かなのか？
このような状況で18歳以降の若者が自民を支持するのは当たり前だろうが！
就職氷河期世代に聞きたい、18歳・21歳の子たちは自分の就職と未来が掛かっているのに経済の話を第一声にしなかった党へ入れると思うか？自民へ恨みつらみを持つ就職氷河期世代だからこそ理解できるはずだ。
アナタたちがご丁寧にも就職氷河期の話を一杯してくれたお陰で若者は経済に無頓着な政党を支持しないという選択を取ったんだよ。アナタたちのようになりたくないから！
自民の議席数が思ったよりも減らない？むしろ維新が増えたお陰で悪化した？そりゃ維新も増えるだろうよ！
明確に経済のことを第一声として打ち出してくるこの2党へ託すしか無いんだからな・・・。
もう一度言おう、我が海運業界の命題は日本国経済を支えることにある。
野党は目を覚まして欲しい、民意へよく耳を傾けて欲しい、そして今回野党へ投じた者はその働きかけを私と共にして欲しい。
自然に溢れ、街並みが綺麗で、歴史もあって、飯は美味い、私はそんな祖国日本が大好きで、そこへ暮らす同胞を不幸にしたくはないのだ。
自民党一党独裁のような状況はよろしくないが、今の野党に日本は任せられない。
だからこそ野党を育てよう、野党が惨敗した理由を説明し、野党にこうして欲しかったと語り合い、野党へ声を届けよう。
次は自民に勝とう。
そうそう、普段はATOK切ってからazureって打ち込むか、IMEをonにしてAzureって打ち込むんだけど
たまたま切り忘れててIMEをONにしたままazureって打ち込んで、しかもazuで止まったので気付いた
昔からATOK使ってるんだけど、ついこの前「Azure」って打ち込もうとしたら
「あず」に反応して推測候補に「あずにゃんとドキドキ痴漢電車」って出てきて死ぬかと思った
遠隔会議で画面共有とかしてるときにこれ出てきたらマジ死んでた
辞書登録したわけじゃないんだけど確定履歴から勝手に推測候補に出してくれるんだよね
確定履歴から削除したけど、よく考えたらこの日記書いたことでまた推測候補に出てくるはずだからちゃんと消しておかないとダメか
てか、他にも似たような単語無いか確認したいんだけどどうすればいいんだ・・・
もちろん分けてるんだよ！
ただ、ATOK Passport使うとATOK Syncっていう便利機能があって複数のマシンで設定を共有できるんだよね。
そんで辞書も共有されてることは分かってたから辞書登録に変な単語は入れないようにしてたけど
まさか確定履歴からの推測候補まで共有されてるとは知らなかった
そして例の同人はもう10年ぐらい前だしもう見てもいないんだけどそんぐらい前の確定履歴が参照されたっぽい
なぜその同人雑誌の名前を打ち込んだのかは分からんが、お世話になったのは確かだ
Shift+Aから始めれば英単語モードになるのはもちろん知ってるし、普段はそうやって使う
そんでazureって打ち込みたいときはIMEをOFFにしてから打ち込む
不幸（？）なことにIMEをOFFにし忘れて更にazuまで打ち込んだときにタイピングを止めたから発覚した
今のうちに見つけられて良かったと思おう
某インターネット接続業者のオマケの、Webページスペース貸し出しが終了してしまうので
いよいよ自分でドメインを取得する。ページの置き場はしばらくはgithub.ioでいいかなあ。
実際にドメインを取得するのは初めてだ。中途半端な知識だけは持ってるが。
今のところ、Web上で俺のクレカ番号とか住所とか知ってる企業はMicrosoft、ビックカメラ、あと銀行系だけなので
ドメイン取得もMSがやってくれりゃ理想なんだけどな。そのついでにAzureも借りてさ（個人でかよｗ）。でもやってないんだよな。
有名どころで、お名前comでいいや。
でもなんかノートラブルというわけにもいかないようなので、GMO系列以外の業者でも
.info ドメインみたいなのを持っておこうかな。
.jp ドメインって、業者によっては公開される情報の代行はやってくれないのな。
https://news.yahoo.co.jp/articles/6ed4869fdca7cf63f81c8a3dc5870869be0debeb
いまではAWS、Azureのようなパブリッククラウド一辺倒時代だけど本当にいいの？
費用は高いし、サービスは落ちるし、設定は複雑だし、好んで使いたがるなんてただの変態だよね。
AWS使える ＝ 高度な知識？ いや、、、単なる「もはや使い方を知っているオペレーター」でしかないよね。
オンプレでも落ちるだろ？って？
→ 規模の大きさにもよるけど、サーバーラック数本程度の管理ならAWSほどガンガン障害起きないし、自分たちで手が出せない感は無いしなぁ。
→ まぁ、そうだけどさ。銀の弾丸は無いさ。
富士通がオラクルと組むのは SUN 関連だと思うけど、富岳で SPARC をやめて袂を切ろうとしていて、少しずつ距離間出てきたね。
オラクルと富士通は銀行と役所、あと巨大病院のシステムをクラウド化したいのじゃないかな？ただ、AWS はソニー銀と三菱UFJ銀行が利用しているみたいで、ソニー銀行は Oracle のサービスを AWS で動かすことで、コストダウンしたみたいで満足感あるっぽいよ。
富士通のクラウドは触ったことないけど、UX は酷いみたいね。個人的には AWS と Azure も今ひとつで、GCP のが良いと思っているけど。
単純に触るなら AWS、熱意があるのが GCP、ビジネスがわかっているのは Azure、って印象かな。僕はさくらインターネットに頑張って欲しいけど。
応答ありがとう。確かに AWS や GCP は素晴らしいテクノロジーだよ。だけど、あれだけベンダーロックインに絶望してきた我々は、なぜクラウドだけは別モン扱いするのか理解しかねる... とは言うのは嘘で S3 は本当に代替がない。S3 の互換はあるけど、オリジナルが S3 であるから仕方ないけど。絶対に AWS が S3 のオリジナルを OSS にすることないし。
AWS の次は Azure で良いのじゃない？なんか、評判良さげだし。GCP はアリババクラウドに負けている時点で、ちょっと残念。ちなみに GCP 自体は好きだよ。（さくらクラウドのカムバックまってるぜ！）
昔話をすると GAE 時代を含むのだけど、Google Cloud が AWS や Azure より使い勝手がイマイチだと思うのは、Google の作る API というかサービスが「お前ら、こういうのが欲しいのだろ？」的な雰囲気が鼻につくというか、「いやぁ、別に...」というすっとぼけたモノを持ってくるからイラつくのだよ。確かに GKE や
Pub/Sub はすごいけどさ、一芥のエンジニア的には Oracle 的なサブマリン特許みたいなライセンス形態で金をぼったくられるのにうんざりしているから、使いたくないんじゃよ。それに時代は Docker Compose で、疎結合なシステム開発をする時代においてコンテナに載せれないサービスを使うのは避けたいしね。AWS とは違って、OSS との共生を図っているのは理解できるけど、顧客が欲しているのは AWS のように OSS を運営しないで済む PaaS のようなサービスだったからね、世の中うまく行かないよね。（本当はさくらクラウドを応援したいけど）
