ServerlessConf Tokyo 2017に参加してきたので今考えていることと発表資料まとめ

昨年のServerless Conf Tokyo #1 に引き続き参加してきた。 いま考えていることを記録しておきたかったのでブログ。


昨年は海沿いにある秘密基地みたいな会場での開催で、アンダーグラウンドみたいな雰囲気で好きだったけど、今回は飯田橋ベルサールというしっかりした会場だった。

1日目はDMM.comラボでServerless Tech Challengeに参加。見事に同期的なものを作ってしまった。他のチームがやっていたAWS IoTを使ってブラウザとWeb Socket的なセッションを張っているのは初めて見たし、おもしろいと思った。


サーバーレスっていう技術についてわかっていないことばっかり。なんか掴みきれない感じというか、もやっとした感じはまだある。 どうすればより良いものができるかここ最近ずっと考えている。

そもそも開発の基礎がない。 サーバー有り、の開発をやってきていない。なので「サーバーがあればこうできる、こうする」みたいな考えがあんまりない。それは先入観がなくていい部分もあるし、悪い部分もあると思っている。 そういう人が過渡期にあるサーバーレスをやってるんだからそらわからないことだらけ。 開発全般に言えることなのか、サーバーレスだからそうするのかみたいなこと。

わかっていないこと

  • ポーリングしまくるのってどうなの?
    • 自分的には発火させたい気持ちのほうが強い
    • SQS < SNSな気持ち
  • イベントドリブンにするべき
    • 自分の中で、もやっとしている部分
    • イベントドリブンではないものを作ったことがないので比較できる経験がない
    • 密結合なものをつくったときのテストの大変さとか?どこかでエラーが出たときの何かとか?
    • この辺の言葉がキーワードなんだと思う
      • マイクロサービス
      • 疎結合
      • イベントドリブン
      • サーバーレス
      • データは一方向

なんとなくわかってきたこと

  • 既存システムの場合、そのまままるっとサーバーレス化するだけじゃ、サーバーレスのうまみを得たとは全然言えないと思う
    • し、つまらない
    • 業務フローを変えるくらいの気持ちでいかないと
  • サーバーがないことがサーバーレスの本質ではない
  • シンプルにすること
  • リアルタイムに応答が必要なのは向いていない

アーキテクチャを考えるときのポイント

  • ファンクションごとにテスタブルなの?
  • 処理がコケたときのことは?
    • 再実行は?
    • データの冪等性は?
  • 新しい機能を追加するときに他に影響は?

まだまだあると思うんだけど。。

発表資料まとめ

聞いたやつと、聞いてないけど今後参考になりそうなやつ、今後何回も見ることになると思うからまとめとく。

サーバーレスについて語るときに僕の語ること』 by @toricls

  • 受注管理システムの例はわかりやすかった
    • 口頭で説明していた、 在庫がなかったら?を考えると・・
  • クラウドベンダーとしては建前上、サーバー運用コストが下がるよ、ハッピー!の文脈で語るけど、本質はそこじゃないことは忘れないこと

The mind of Serverless as a Software』 by @marcy-terui

Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤』 by @nii_yan

  • シンプルな構成
  • CloudWatch LogsからSlackは真似したい

真のサーバレスアーキテクトとサーバレス時代のゲーム開発・運用』 by Kazutomo Niwa 『サーバレスアーキテクチャによる時系列データベースの構築と監視』 by Ken Hamada 『Continous Delivery Strategy for Serverless world』 by Tsuyoshi Ushio

転職してから半年たったので振り返り

8月いっぱいで半年になったのでここ最近の心境とかを忘れないように書いておきます。

現職

現在は小売系のシステム開発会社でエンジニアとして

  • サービス開発
  • 自社インフラ運用
  • 企業のクラウド移行支援

などを主にやっています。

前職でのお仕事

前職は下請けのSIerで、1年10ヶ月在籍しました。新人研修後はインフラ部門に配属され、AWS上にWebサービスや企業の基幹システムのネットワーク・サーバー構築などを任された僕はまず「サーバーとは」とググるところから始まりました。

2年目からは大手SIerに出向し、そこでも同じくAWSWebサービスの基盤設計・構築や企業基幹システムのクラウド移行支援や、その後の運用などをやっていました。

当時は次々と新しい構築案件が来ていて、それのインフラ設計をしたり、お客様やチームメンバーと構成やフィージビリティについて話し合ったり検証したりしているのが正直、チョー楽しかったです。

大手SIerによくあるドキュメント作成地獄と往復3時間の通勤を除いては。

転職を考え始める

2年目の初めの頃から、勉強会やユーザーグループなどに顔を出すようになりました。

そしてこの世界には、「infrastructure as code」とか「サーバーレス」というものがあることを知り、またあるところでは「インフラエンジニアレス」とか聞こえてきて、あ、これコード書けないと死ぬやつだ、と思い始めてきました。 僕としても、Webアプリのインフラ設計・構築とかやってる時とか、AWS使えばWebアプリのインフラなんて超カンタンに作れるんだからそんなのアプリエンジニアが自分でやっちゃえばいいんじゃん、って思ってました。

とにかく、インフラはAWSにおまかせして、もっとコード書けるようになってサービス開発とかにパワーを注ぎたいという思いが強くなってきました。

きっかけ

弊社の社長が色んな所で話をする結構有名な方だったので、転職とか考え始める前から知っていました。

転職を考える前から何回か前で話しているのを見ていて、転職を考え始めてからもある勉強会で発表を聞く機会がありました。その時に話していた内容にめちゃくちゃ共感できて、勉強会が終わったあとに

「ここで働かせてください!!ここで働きたいんです!!」

と言おうとしたものの、そんな度胸など無く、そのまま帰ったのは内緒。

後々、ちゃんと業務内容とかを調べてみたり、採用イベントで話を聞いてみて、改めてやりたいことができる会社だと再認識。今の会社に決めました。

転職してから

生き生きとエンジニアしてるように感じてます。

やりたいことやらせてもらっているし、会社員なのでやりたくないこともやる覚悟はしているのですが、ほぼストレスなく仕事しています。

新しいものをどんどん取り入れる気風だったり、自分以外の社員も積極的にインプット/アウトプットしているところがいい。

あと転職の目的だったサービス開発もサーバーレスでチャレンジしてます。いまいまサーバーサイドをPythonで書いていますが、なんだかんだいってJavascript最強だなって思っているのでそっちも書いていきたいです。LambdaにGoが対応したらGoもやってみようかな。

これから

  • 技術を使うことがメインになってくるとつらい。
    • 何を達成したいのか?
    • 使う技術はなんだっていい。
    • 達成したいことに対して一番スピード感を持って楽にアプローチできる技術を使うべき。
  • 当分はコードをばしばし書いて人の役に立つものを作っていきたい。
    • プロのすげえエンジニアになりたい。
  • 言うは易し行うは難し

みたいな信念を持って、ぶれずにやっていきます。

まとめ

新卒で入って1年10ヶ月で転職という周りと比べるとやや早めの判断でしたが、今楽しくエンジニアできているので後悔していません。

前職で関わった方たちとは今でも多くの方と関わりがあって飲み会とか情報交換とかしてるので、後腐れなくよい転職ができたと思っています。転職に際して相談に乗ってくださった方々ありがとうございました。

これから何があるかはわからないですが、エンジニアとしてやっているうちは、死んだエンジニアにならないようにインプット/アウトプットを続け成長していく所存です。