AWS をどう使わずにおくか - portal shit!

ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back

[morygonzalez]

タイトルと URL 変えました。/ AWS をどう使わずにおくか https://portalshit.net/2018/09/29/should-avoid-depending-on-aws-proprietaries-as-much-as-we-can

[sshingo]

オープンソースしか使わないって思想は会社としてプロダクトの趣旨とかを踏まえた上で持ってるならいいけど、個人で持つのは技術選択を狭めるだけで害悪だと思うけどねぇ。

[deokisikun]

そもそもこういう議論ができる場が羨ましいし別業界のように感じている

[tzt]

IaaSの移行なんてそうそうあるもんではないのでリスクを過大評価し過ぎではという気もするがそこはプロジェクト依存か。ただ、エミュが嫌なら別にローカルでも本物のSQSだろうがDynamoDBだろうが好きに使えばいいのでは？

[knjname]

CIはローカルビルドの延長というのは大事な観点だよね

[micolash]

それこそソフトウェアエンジニアの仕事なような。境界を抽象化しておく

[kai_kou]

「AWS 独自のプロプライエタリな技術に依存してアプリケーションを作りたい訳ではない。」 技術にフォーカスすれば、そらそうだけど、スケールにフォーカス当てたらまた違う議論と結論になるやろね

[ackintosh]

SQSの件はリスクの過大評価なようにも感じましたが参考にさせていただきます/CircleCIの例、勉強になりました

[aanrii]

“ The Twelve-Factor App （日本語訳） A methodology for building modern, scalable, maintainable software-as-a-service apps. 12factor.net”

[maru2tech]

実際のところ、ロックインしまくって作っても問題にならないケースが大半だと思う。問題になる頃にはプロジェクト自体が死ぬか、逆に儲かってて移行の予算がたくさん出る。比較検討するのに時間かけるのは無駄。

[yumainaura]

良い記事！

[tmatsuu]

いいね。この考え方をつい忘れてしまう。Twelve-Factor App、読み直す。

[snowlong]

“AWS の技術がどんなに優れていたとしても、自分はオープンソースではない AWS 独自のプロプライエタリな技術に依存してアプリケーションを作りたい訳ではない。”

[braitom]

技術選定のプロセスの一例としてよい。色々考えさせられた

[t1mvverr]

POSIX標準コマンド+シェルスクリプトの組み合わせで自動化したら無難ってことだろうか。

[soy-curd]

知見

[daaaaaai]

技術選定のプロセスとしてよい

[joker1007]

規模と要求される可用性に依るので、この議論内容そのものが微妙に筋違い感がある。スケールしてかつロバストなキューが如何にハードか、という実感に依る。

[naka-06_18]

RabbitMQ かあ。突然出てきて目が点になった。/ ここまで来ると OpenStack とかの HCI を使ってるんでしょう、多分。

[stk132]

SQSはキューの中身確認したいときに、ポーリングでいったん中身取り出すところが微妙なのよね。観測行為が事象に影響を及ぼす的な。自分はロックインは気にしないかな。ローカル開発用にもキュー作ればいいじゃん派

[yamitzky]

わからないでもないし真の要件知らないけど、ローカル版使えばだいたいTFA満たしてるし、開発/本番一致は程度問題では。開発環境は1台構成だろうし、差がないことはない。コードレベルでは SQS は抽象化するだろうし

[delphinus35]

わからんでもないがやりたいプロジェクトによるかなあ。マイナーなクラウドベンダーにロックインすると困るのはわかるけど AWS なら別にね……

[side_tana]

わかる...わかるが...しかし...

[okzk]

単純なJobQueueは(DBやストレージに比較して)他のモノへの移行は簡単なので、ロックインを避けるよりも初期コストと当面の運用コストに比重をおいて判断することのほうが、自分の場合は多いかも？

[luccafort]

SQS採用したところここで反対されている内容でやっぱりうーむみたいな気持ちになったので正しい判断だったんじゃないかなぁと思う。言語に依存したくなかったのでSQSにしたけどちょっと微妙だった。

[tak4hir0]

AWS の使いどころと Twelve-Factor App

[yo_aibou]

sidekiq(redis, elasticache)だろうがSQSだろうが、キューイングする役者が特に意識せずにキューイングできるようにブラックボックス化することのほうが重要なのでは？ sidekiq/SQS前提で開発するからそういった食い違いが起きる

[inductor]

拙者、わかり侍

[yuma_0211]

“RabbitMQ” ”Sidekiq”

[umai_bow]

よく言語化されてる気がする

[cl-gaku]

よい

[masaru_f]

「AWS 独自のプロプライエタリな技術に依存してアプリケーションを作りたい訳ではない。運用の煩雑さ・手間から解放されたい、スケーラビリティを提供してほしい。」

[dsl]

わ

[mukimi]

未だにロックイン嫌う輩がおるんか

[kyuns]

良い

[magnoliak]

"SQS はアプリケーションのソースコードの中に入り込んでくる。"