【AWS DevDay Tokyo 2019 セッションレポート】フロントエンドエンジニアがK8sエンジニアになるまでの10年間を振り返る #awsdevday

【AWS DevDay Tokyo 2019 セッションレポート】フロントエンドエンジニアがK8sエンジニアになるまでの10年間を振り返る #awsdevday

Clock Icon2019.10.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS DevDay Tokyo 2019のセッション、「フロントエンドエンジニアがK8sエンジニアになるまでの10年間を振り返る」をレポートします。

セッション概要

AWS使ってますか?気になるけどまだインフラエンジニアにおまかせでしょうか?それとも「私は一生アプリエンジニアだ」と心に決めてますか? このセッションでは、エンジニアとしてのキャリア開始時点ではIaaSやコンテナどころかVMすら関わる予定もなかった人が、10年を経て今ホットなK8s界隈でどんな仕事やOSS活動をするに至ったか(または「AWSコンテナヒーロー」になったか)を紹介します。 セッション中では、いくつかのターニングポイント別のどんなシチュエーションにおいてどんな考えと決断でポジションを変えて、どんな結果を出すことができたかを説明して、最後にこれからどこへ向かおうとしているか、とうこともお話します。 このセッションを通して、アプリエンジニアをバックグランドにIaaSやコンテナ、AWSを操れることがどんな価値を生み出し、どう当人の利益にもなるのかをお伝えして、皆さんのキャリアの一助になれば幸いです

スピーカー

ゼットラボ株式会社

九岡 佑介 (@mumoshu)さん

セッション内容

Day0 〜2008

  • 小学生
    • スーパーファミコン、PC9821、Windows3.1、Visual Basic 2.0
  • 中学生高校生
    • ネトゲ三昧
  • 大学生時代
    • 情報工学系
    • 英語とプログラミングには興味があった
  • 院生時代
    • Googleが流行り始めた時期
    • 自然言語処理に興味

イベントで振り返る10年

  • 2008〜
    • 某電機機メーカー系ISP開発かんりフロントエンドエンジニア
    • 興味 RoR/MVC/OOP/jQuery
    • イベント GitHub/jsdoit
  • 2010〜
    • 某プリ機で有名なエンタメ企業アプリエンジニア
  • 2013〜
    • GREE インフラ
  • 2014〜
    • CrowdWorksインフラ
  • 2015〜
    • ChatWork
    • 興味 IaC/DevOps/SaaS/Container
    • イベント kube-awsのメンテナになる
  • 2017〜
    • freee
  • 2019〜
    • Z Lab Corpopration
  • 2008年にRailsに出会う

  • 2010年にjsdo.itで修行
  • 2011年ドキュメント翻訳
    • scalaに興味があった
    • 業務で使うために外堀を埋めるためにやった
  • 2016年 kube-aws
    • プライマリメンテナになった

考察

  • トレンドに乗るタイミングが良い
    • Scala
    • K8s
    • 日本ではプロダクション利用が一般的になる直前からやり始めた
    • 世界的に見れば枯れてた
  • OSS活動が本格化したのが2015
  • インフラエンジニアに転向したのは2013
  • AWSを本格的に使うようになったのは2014

興味と要請のギャップ

  • 2013年GREEくらいからやりたいこととやることが合ってきた

振り返り

  • 興味は二、三年で変わる
  • 要請は職場チームで異なる
  • 後半に行くほど要請と興味のズレが小さい
  • 実はソフトウェアエンジニア
    • インフラエンジニアになった後も、実はAWSやコンテナを活用するソフトウェアを主に作っている

前提

  • 今の所、アウトプットの質と量がダイレクトにキャリアの満足度に直結

再現性のなさそうなこと

  • ネトゲにハマる
    • 英語のテキストコミュニケーション力はついた
  • ただ転職を繰り返す
    • どこで何をやりたいか、何が求められているかから逆算すべき
  • 良き同僚との巡り合わせ
    • 一人でやるわけでない
    • 完璧じゃなくても乗ってくれる、使ってくれる同僚が大事
  • 良き上司との巡り合わせ
    • 上司の理解がなければ全てできなかった

再現性のありそうな事

  • 軸を見つける

    • 例:実はソフトウェアエンジニア
  • アウトプットを続ける
    • ありそうでなかった領域が望ましい
    • 書いてみて作ってみてわかるを積み上げる
    • 同志と一緒に続ける
  • 興味と仕事を結びつける
    • 例;Scala、Kubernetes on AWS
  • 価値を高める
    • 例:プロダクトとしてのOSSの開発、登壇などによるプレゼンス向上、英語による発信
      • OSSについてはもっと使われるための工夫をしてほしい
    • ソフトウェアの強み=コピーコスト低を最大限に活かす
  • ギャップを見つける
    • できそうだけどできない、痒いところに手が届かないことを見つける
  • とりあえずやってみる
    • 問題提起
    • POC公開
    • POCフィードバック
    • 書籍や記事を書く
    • →実用化を加速
    • →発信・公開するまでは何も始まらない

最近のアウトプット例

  • Envoy x DS Server envoy-xds-configmap-loader
    • 課題 gRPCサーバー用のk8sクラスタやコンテナのカナリアリリースをしたい
    • ギャップ サービスメッシュは大げさ、ALBはgRPC/HTTPS2バックエンド非対応、、
    • 解決策 績のあるリバースプロキシEnvoyとk8sの標準機能を掛け合わせ

一拍

  • やるぞという気になりましたか?
  • やる気をAWSに向けるのおすすめ

自分にとってのAWS

  • Universalである
    • ベンチャーでも大企業でも使える
      • カバレッジ
      • カスタマイズ性
      • そこそこの価格
  • あくまでBuilding Blockの提供者
    • AWS APIによるプログラム性が合わさると、AWSが普及すればするほど、AWSを操るソフトウェアエンジニアの需要が生まれる
  • AWSあるところに課題あり
    • AWSはプログラマブルなのでソフトウェアで解決できる
    • Developerの出番!

今後の展望

  • サーバーレスに向けて
    • コードをプロダクション環境で動かすまでにはまだ様々な課題があります
    • サーバレス が目指すべき方向と考えています。サーバレスな体験を提供するPaaSをDeveloper自身が作れるようなフレームワークが必要ではないか?
    • フレームワーク開発ならソフトウェアエンジニアの領分
    • 課題の例
      • Lambda Function、コンテナ、VMどこにのせる
      • コンテナ使うならECS、EKSどっち?
      • それぞれどんなツールを選択すれば?
      • どんなCI/CDパイプラインを組めば良い?
      • デプロイ失敗時に、デプロイ後にエラーが発生した時に何をどこで確認するか?できるか?
      • ECS/EKSをどうやってキャッチアップする?
      • 監視は?
      • アップグレードは?

まとめ

  • フロントエンジニアがk8sエンジニアになるまでの10年
    • 興味に任せてたらAWS使ってた
    • AWS使ってたからこそk8s on AWSをやることになった
    • 過程で得られたこと
  • Developerのキャリアを支えるAWS
    • AWS APIによるプログラム性が合わさると、AWSが普及すればするほど、AWSを操るソフトウェアエンジニアの需要が生まれる
    • AWSはプログラマブルなので、身近な課題をAWSとソフトウェアの力で解決してください

感想

「AWS APIによるプログラム性が合わさると、AWSが普及すればするほど、AWSを操るソフトウェアエンジニアの需要が生まれる」にすごい腹落ち感がありました。ソフトウェアエンジニアの需要が増すという点については、ゼネラルセッションの倉貫さんのお話しで出てきた「Software is eating the World」あたりともリンクします。デベロッパーがやれることはたくさんある、と勇気のもらえるセッションでした。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.