本番システム構成

サービス本体
Webサーバ：Nginx
APサーバ：Puma
DB:PostgreSQL
プログラム：Ruby on Rails
OS:CentOS7
を
さくらのクラウドで動かす。

バッチ処理
C#.NET
他省略。たいしたことやってない。

を
さくらのクラウドで動かす。

DBをサービス本体と共有して、やり取りしてる。今の時代はマイクロサービス的なAPI経由なんでしょうけど、
まあいつか・・・

検証環境
社内のそこらへんにあったWindowsPCにVMWareを入れて、その上に上記環境入れて動いています。
WMwareめっちゃいいですよ。壊れても消せばいいし、ファイルコピーすれば他のPC
もっていってもすぐに復元するし。バックアップもファイルコピーしておけばよいし。重いけど。
（ほんとはどっかーとかでやるのが一番いいって分かってる。分かってるんよ！まあいつか・・・）
社内SEの人はWindowsオンリーの人ばかりだと思います。ただ、Webサービス作るにあたっては
どうしてもLinux系のOSに慣れる必要がどうしてもあります。

なぜか。

本番環境は結局CentOS7を想定していたので、Windowsだとわけわからないエラーが出ます。
（実際にありました。Windowsではちゃんと動くのに検証環境持っていったら、動かないやつ。
　この時の原因はWindowsでしか動作しないPing系のGemを入れていたためでした。分からんて。
　そんなん。2日間かかりました。原因調べるの。）
まあ、でも開発はWindowsでしてますがね。てへ。

話は戻して、ちなみに本番は
今どきのクラウドサーバにおいて動かしてます。
でも、
AWSじゃないよさくらだよ。

なぜか。

日本のサービスだから、とっても分かりやすい。マニュアルも全部日本語やし、
初めてだったが、かなりスムーズに構築できた。
みんなクラウドと言えばAWSみたいな感じですが、取っつきやすさ、課金の
分かりやすさ（従量課金ではない）はさくらがダントツ。
※ちなみにうちの経営者はAWSで！ってミーハーな感じで言ってきてたので、
　従量課金で24時間動かしてたら、かなりコストいっちゃいますよ～
　想定よりかなりいっちゃう可能性ありますよ～。にやにや。とやんわり伝えたら、
　さくらで了承してくれました。

ちょっと言いたいこと（AWSに物申す。AWS信者にも。）

はっきり言って小規模の会社で、社内運用並み＋αくらいのものであれば、
オンプレミス環境でもあまり問題にならないと思います。
（電源管理、インターネットの帯域管理、Windowsなら勝手に再起動しないでがある程度
求められますが、まあ稼働率90％あればええやん的な。ゆるい感じ。
かけるコストと内容と運用する時間とのバランスを考えると上記のような考えは全然ありです。
今までもこうしてきて、クレームほぼないし。お金を追加で払わなくてよいし。
ほんとに24時間絶対動かさないかんっていうやつであれば、じゃあクラウド考えましょうで良い。）
まあでも経営者はやたらとクラウドでって言うので、これも時代の流れでしょうか。
最初オンプレでも全然ＯＫだと私は思います。なんかやばくなってきてからクラウドに移せばいいし。
オンプレミスからクラウドに移すっていう経験もとても良いものですよ♪

また、Webサービス作って、AWSに上げて、いい感じに構成してって、一般ピーポーからしたら
ものすごいハードル高い。
ローカルでもぎりぎり動いているのに、CentOSの理解に一苦労、AWSのドキュメント読みこんで、
AWSの理解に二苦労、ぐぐっても英語ばかりで三苦労ってなると、ほぼ挫折するはず。一般ぴーぽーは。
だから、ほぼ日本語で押し通せて、一番挫折しなさそうな　Ruby　→　さくら　という選択になりました。
ただ、さくらもしっかりしたクラウドで他のも似たようなもんだと考えると、
今ならたぶんAWSでも大丈夫な自信が無駄にあります。

ということで、一般ぴーぽー社内SEがWebサービス作るなら・・・

Ruby(on Rails)　と　さくら　で決まり！一番挫折しない組み合わせですよ。ほんとにお勧め。
DBは何でもいいよ。好きなの。お勧めはPostgreSQL
エディタはVSCodeを使いましょう。
Teraterm(SSHでCentOSに入るためのツール。コピペが簡単にできるからとっても重宝する。)
WinSCP(ファイル転送ソフトだが、CentOSのファイルも見れる。ディレクトリ構成が一目瞭然

最後に

昨今の日本は生産性の向上が叫ばれていますが、ポイントとなるのは開発側の人間ではないです。
導入する側のITリテラシーにかかっています。そして導入側をリードするのが我々社内SEです。
実は生産性の向上に一番寄与するのが我々社内SEのはずなんです。業務フローも分かっていて、
ITの知識もあり、間に入って仕様の調整、工数調整できるのは我々です。
逆に社内SEがしっかりしていないところは、いわゆるベンダーの言いなり価格、言いなり仕様に
なります。自分もベンダー側の人間だったことがあるので・・・
結果、現場で使われない、意味不明な仕様の実装、無駄なお金が飛びます。

ただ、上記のしっかりしている社内SEになるには
レガシーな知識にとらわれず、最新のIT知識・その知識を持って簡単なサービスの実装
ができるほどの力は持っていないといけません。と私は思います。と私は思ったからこそ
今更Webサービス作ったりしています。
色々やっていると、実はフルスタックF/W（RubyだとRails）で全て作るような時代は
とうの昔に過ぎ去っており、サーバーサイドとクライアントサイドに明確に分けて
サーバーサイドはAPI実装が基本、クライアントサイドはSPAでの実装が基本というのが今の時代だそうです。
いわゆるマイクロサービス的な～♪　PayPayも3か月で組んだそうですよ。マイクロサービス的な
開発で。昔は考えられなかったのですが、インターネットの速度が劇的に向上したからこそ、こういうのが
できる時代になったんでしょうね。

まだまだ私はレガシー社内SEだったということで、今回のお話の締めにしたいと思います。
ああ、書いてすっきりした。