App Engine Standard Go 1.11へのマイグレーションの方針が大幅に変更されたので追従した

[sinmetal]

Go 1.11はベータ登場当初は2nd genとして、appengine apiを廃止する方向で動いていたが、方針転換によりGo Runtime最後の1st genとなることになったので、マイグレーションの方法が大幅に変わっている。 Go 1.11の方針転換の内容は https://qiita.com/apstndb/items/314e461aed518a4ad26f が詳しい

refs #100

[emahiro]

https://speakerdeck.com/emahiro/go-conference-2019-spring-go1-dot-9-to-go1-dot-11

5月のGo Conference 2019 Spring でGo1.9->Go1.11移行についての上記の発表したので、よろしければリンクしていただけるとmm

[sinmetal]

@emahiro 色んな人の移行してみた記事へのLinkをこいつに入れるかは悩ましいところですねー そういうのを募集するissueを新たに作成するかもしれません。

ちなみに19ページ目の やらないと決めたことの以下の2つが疑問なのですが、なぜなのでしょう？

urlfetchの廃止

Quota制限も存在するurlfetchを使い続けることにした理由はなんだろう？

cloud.google.com/loggingを移行先として検討した

cloud.google.com/logging を使うとApp EngineのInstanceが死ぬ前にFlashする必要があって、App Engineで使うには、管理がつらい印象だけど、移行先として検討したのはなぜなのでしょう？

[emahiro]

@sinmetal

Quota制限も存在するurlfetchを使い続けることにした理由はなんだろう？

x-appengine-inbound-appid を使ってマイクロサービス間の内部通信判定をしており、変更した場合の影響範囲が大きいためにスライドを作成する少し前の移行検討〜開始時期ではurlfetchの継続使用を選択しました。

cloud.google.com/loggingを移行先として検討した

構造化ログが欲しい！という一点で調査してました。ログについては一旦移行はpendしてます。

[sinmetal]

@emahiro なるほど。urlfetchを使って、別のApp Engine Serviceにリクエストを送ってる人は少数派なんじゃないかなーという気持ちがあるので、そこの部分のユースケースががっつり書いてあると嬉しいですね！ ロギングはいい感じに出力する方法が悩ましいけど、 cloud.google.com/logging は通信とかも発生するし、よほどのことがない限りは使わないかなぁぐらいの気持ちです。

[sinmetal]

https://github.com/gcpug/nouhau/issues/102 が爆誕しました

[emahiro]

102 に上記のスライドのリンクは貼らせていただきますね！ありがとうございます！

[apstndb]

そのドキュメントの目的から逸れる話は削るという思想が我々にも Google にも足りないことが多いので、何らかのトピックがあれば分割してリンクすることを検討してもよさそう。

appcfg.py, goapp からの移行と GOPATH, vendor, Go Modules あたりは包括的に書いている人が少ないし、結構重い話ですね。

[sinmetal]

appcfg.py, goapp からの移行と GOPATH, vendor, Go Modules あたりは包括的に書いている人が少ないし、結構重い話ですね。

は僕もすべてのパターンを知ってるわけではないから、よく分からんな・・・って気持ちですねぇ