2017年11月10日(金)に開催されたDevelopers Festa Sapporo 2017を聴講してきました。
JavaOne 2017 フィードバック～今後のJava開発・運用のために知っておくべき事総まとめ～
伊藤 敬(日本オラクル株式会社)
2017/10/1～2017/10/5までサンフランシスコで開催されたJavaOne 2017の内容についてのお話し。
こういうクラスができてとかいう技術的な話しはほとんどなく、リリースサイクルとかオープン化な話が多かった。
Javaから離れて結構久しいので、何か軽量化されるぐらいしか知らなかったんですが、半年後にはJava10がリリースされるとかいう話しは結構衝撃的。
Java SE 9
▼過去最多の機能追加
20(Java7)→55(Java8)→91(Java9)
リリースが延びたのも要因の1つだそう...
▼リリースモデルの転換
従来
・OpenJDKとOracleJDKに機能差分がある
私、これ聞くまでOpenJDK自体知りませんでした...
・機能リリースは2年に1度(ただし目標)
・それぞれの機能リリースごとの長期サポート
Java8まではおおむね8年サポートしてるんだそう
・更新リリースは3か月ごと
セキュリティパッチに加えて限定的機能更新も含まれていたそう
これから
・OpenJDKとOracleJDKに機能差分をなくしていく
すぐにではなく徐々に的な雰囲気
・機能リリースは6か月に1度(固定)
リリース日は決めて、そこに間に合った機能を載せていくイメージ
次出るバージョンはJava10→11→12のナンバリング
18.3→18.9→19.3と西暦年+月の組み合わせにしてたのが最近方針転換されるらしい
・長期サポートはOracleJDKのみ
ここの話が、最近Javaから離れている自分にはよく理解できなかった。
長期サポート(LTS:Long Time Support)は、6か月ごとの機能リリースではなく、その中の特定のリリース(おおむね3年ごと)が対象となると認識しました。
それのスタートが2018年9月で、次の長期サポートターゲットが2021年9月ということらしい。
商用利用で頻繁にバージョンアップをしたくない企業向けなんですかね...
・更新リリースは3か月ごと
セキュリティパッチのみで機能更新は含まない
▼転換期故の弊害
公式アップデート終了はJava10より9の方が早い
Java8：2018.9
Java9：2018.3
Java10：2018.9
今Java8を使っている場合は、次のターゲットは10にした方が良い
▼その他
Java8から後継バージョンへの自動更新は行われない
Java SE9の32bit版バイナリの提供予定はない
官公庁への影響は大きいだろうとのこと(実際説明に行って叱責を受けることが多いそう...)
jlinkを利用したパッケージングとデプロイ
クライアントに入っているJREに依存しないアプリを作れるんだそう
(Developers Festaなんだから、こういう話しをもっと聞きたかったですね...)
Java EE 8
▼JavaEEが抱える問題点
・軽量でない
・業界トレンドとのギャップ
▼Eclipse Foundationへの移管
Oracleはもう関わらないというわけではなく、仕様策定の主管をEclipse Foundationへということ。
Eclipseでの開発プロジェクト名はEE4J(Eclipse Enterprise for Java)
Other
▼fn.project.io
Java対応のFaaS(Function as a Service)
いわゆる、Oracleのサーバレスプラットフォームのようです
蛇足
じゃんけんでTシャツいただきましたw
Mサイズで自分には若干小さかったので妻へのプレゼントとなりました。
The State of Serverless Computing
西谷 圭介(アマゾン ウェブ サービス ジャパン株式会社)
昨年に続いての聴講。
序盤でサーバレスとは？に簡単に触れ、後はアーキテクチャパターンについての実用的なお話しでした。
西谷さんが使っていた、スライドが暗くなって、指し示した一部分だけが明るくなるアイテムが気になって途中から話半分でしたｗ
サーバレスとは？
コンピューティングの進化の中、未だ残る制限
物理サーバー
↓
仮想サーバー(オンプレ)
↓
仮想サーバー(クラウド)
と進化していく中で、サーバーの管理業務からは解放されていない
サーバーは管理しない方が簡単
ファンクションは短命
なので
・サーバレスはよりセキュア
・コストを抑えられる
アイドル時の支払いなし
ただし、実行回数の分は掛かる(コスト効率はいいが、何でもかんでも安くなるわけではない)
サーバレスは管理業務からの解放
アーキテクチャーパターン
・Web Application
・Backends
・Data Processing
→一番使われるパターン(RealTime、MapReduce、Batch)
・Chatbots、Amazon Alexa
・IT Automation
→一番ハードルが低い(CIなど)
ベストプラクティス
この中からいくつか出てきましたが、印象に残ったのは
・ステートレス
・開発/本番で一致した状態
この話の流れでLambdaについての技術的なお話し
・FUnctionのコンピューティングリソース設定
メモリ設定の見極めが肝心
・コールドスタートとウォームスタート
安定的にリクエストが来ていれば最初しかコールドスタートは発生しない
コールドスタートのスピードを許容できないのであれば、Lambdaは正解ではない(使うな)
アンチパターン
▼AWS Lambda + RDBMS
・コネクション数の問題
・VPCコールドスタートの問題
・DynamoDBを使うべし
▼IP固定したがり問題
▼Serverless != Monitorless
・監視はちゃんとしよう
IoT 時代を生き抜くエンジニアに必要な技術とは
松下 享平(株式会社ソラコム)
こちらは別記事にまとめました。
以上