Spring in Summer ~ 夏なのにSpring で発表してきました #jsug_sis
こういう大きいイベントでセッション発表するのは初めてだったのでかなり緊張しましたが、無事発表を終えることができました。やればできるもんですねw*1
www.slideshare.net
時間が多少オーバーしてしまい、質疑応答の時間が取れなかったのは申し訳なかったです。ただセッション終了後には数人の方に質問しにきていただいたりもして、多少なりとも興味持って聞いていただけたのかなぁと勝手ながら思っています。
発表の機会を下さった @making さんはじめ、 JSUG スタッフの方々、その他関係者の方々、本当にありがとうございました。
補遺
私と同僚の山田の2人でのセッションで、前半が私のレガシーシステムへの導入事例、後半が山田の Spring Boot を使った運用 Tips といった構成でした。最初は私も技術的なことを掘り下げたセッションにしようかとも思っていたのですが、メリハリがないと聞く側も疲れてしまうだろうという気持ちもあってこのような構成にしました。結果的にはバランスが取れて良かったかなと思っています。
私のパートはセッション中にも何度か言いましたが、BtoC でよく話題に上がるような以下の様な問題
- 高トラフィック
- 低レイテンシ
- 大量データ
はあつかわず、どちらかというとどこにでもありそうな話題をテーマにしました。目新しい話題を期待されていた方には申し訳なかったです。
Spring のカンファレンスで私たちのような事業者が冠に付いたセッションに対して期待されるのは、どちらかというと上記のようなテーマではないかと思ったりもしました。ただ、私自身が Spring に絡めた話でその文脈を語れるほど経験がなかったことと、私が Spring(特に Boot)に対して魅力に感じていたのは、今回のセッションで話したような生産性の高さと柔軟性、そして簡単さだった*2ので、そこをお話したかったということが大きいです。
そういう意味でも、もし導入を検討されている方や悩まれている方がいるなら、背中を押してあげたい気持ちですw*3
質問されたこと
犠牲的アーキテクチャの話で、今あるものを捨ててしまうのが価値、とは?
この辺りの話はちょっと前提をすっ飛ばしすぎて、普段 Web 上の議論を追っていない方にとってはなんのこっちゃという話でした。すみません。
大元は、マーティン・ファウラーが書いたこのエントリが発端の話です。(日本語訳はこちら)
端的に言うと、今作っているものも数年後には捨てざるを得ないくらい、世の中が変わったり技術が進んだりして、要件が実態と合わなくなることがあるかもしれない。ビジネスが成長して、システムのスケーラビリティが追いつかないこともあるかもしれない。それならば、作る時に最初から捨てることを意識してアーキテクチャを選ぼう、という考え方です。ただし、捨てるからといって、それまで作ってきたものに価値はない、ということではなく、
比較的短時間で捨ててしまうソフトウェアだって多くの価値を生み出しうると認めること
ともある通り、それはそれで開発チームが得てきた問題領域に対する経験や知識が無駄になるわけではないし、また品質を置いてけぼりにしていいわけではなく、極力モジュール性を高めておくことで新しいアーキテクチャにも交換できるようにしておくことが重要だとも言っています。この辺は、今流行りの Microservices Architecture にも通じる話かなと。
兎にも角にも、これをそもそもやるべきかどうか、いつやるべきか、というのに答えがあるわけでもなく、
多くの場合、これは技術というより事業の決断なのだ。
ということなんだと思います。
この話題に関しては、犠牲的アーキテクチャという言葉ともに、神宮式年遷宮に絡めて語られたり、式年遷宮アーキテクチャなどと言われて一時議論されていました。以下に、Web 上の有用な議論のリンクを示しておきますので、興味ある方はどうぞ。特に、Rebuild.fm の Aftershow 67 を聞いてみるといいと思います。
その他参考になるリンク
- Martin Fowler氏の語る“犠牲的アーキテクチャ"
- Rebuild: Aftershow 67: Sacrifice Your Code (Naoya Ito)
- 確率的に犠牲的 - steps to phantasien
- 神宮式年遷宮と犠牲的アーキテクチャ
- 犠牲的アーキテクチャ~リプレースを正当化するアーキテクチャ: プログラマの思索
チーム状況として1人と言っていたが、障害時のオペレーションはどうしているのか?
- 基本的に自分が対処できる状況にあればするが、休みやいない場合はもちろんローテーションするようにしている
- 一次対応は他メンバーでもできるようになっている
- 手順は Wiki にまとめるなど、明確化している
開発が1人だったということだが、インフラのキッティングやらネットワークやらまで1人でやったのか?
- インフラはオンプレミスの仮想環境に乗る形なので、アプリケーションエンジニアは基本的にはミドルウェアまで見られればとりあえず回る
蛇足
1人でやってることに関して、「私も1人でやってるんで、どういう風に上手くやってるのか教えて欲しいですー」みたいな話をちらほら聞きました。意外と世の中ソロプレイを強いられている方々多いのでは…?w
また、セッション中どちらも諸事情でリソースない、みたいな話をしていたので、いつもそのような状況に思われたかもしれませんが、潤沢なプロジェクトは潤沢ですよw
きっとどこの会社もそういう状況はあるはず…と信じたいw
LT
飛び入り参加 LT も募集していたので、調子に乗って jOOQ の話(渋谷 Java で話したやつそのまま)をしました。こっちは大分気楽に話せたのでよかったかなw
www.slideshare.net
Spring Boot 1.3 で jOOQ もサポートされるので、興味ある方はぜひ触ってみてください。
Java で O/R マッパーどれにするかは尽きない話題だと思いますが、今回も会場に質問してみたところ見事に割れてました。ただ、懇親会でお話させてもらう中で Hibernate で困ってるんですー、って人はちらほらお聞きしました。ちゃんと使えば大丈夫、という話もありますが、そのちゃんとまで行くのが大変というのもまた然りなのかなーと思ったりしました。
全体を通して
途中準備が追い込みかかってそれなりにスケジュールがタイトになってしまい心身ともに疲れもあったのですが、とても貴重な経験となりました。重ねて関係各位と当日聞いていただいた方々に感謝申し上げます。ありがとうございました!