DynamoDBの特性に合わせてシステムを設計しろと言われればその通りなのですが、「やりたいことを最小限の手数で実現する」というのが今の自分のミッションなので、データモデルとしてシンプルなドキュメント型KVSだけでは向かない領域というのはやはりあるわけです。もうすぐTokyoにも来るらしいFirehoseやAthenaなど道具がそろってきていますが、「あともうちょっと、ならではのつらさ」というのが伝わればと思います。
DynamoDBの特性に合わせてシステムを設計しろと言われればその通りなのですが、「やりたいことを最小限の手数で実現する」というのが今の自分のミッションなので、データモデルとしてシンプルなドキュメント型KVSだけでは向かない領域というのはやはりあるわけです。もうすぐTokyoにも来るらしいFirehoseやAthenaなど道具がそろってきていますが、「あともうちょっと、ならではのつらさ」というのが伝わればと思います。
今週末4/9(日)に秋葉原UDXビルにて行われる技術書オンリーイベント「技術書典2」にて、同人誌「めもおきば TechReport」の頒布をおこないます。
秋葉原のアキバ・スクエア(UDX 2F)ですので、万障お繰り合わせの上ご参加ください。
ブースは「あ-06」です。
実装編は、現在ぎりぎりまで絶賛執筆中です。
みなさま出るのを全力で祈っていてください。
なお、勉強会 #ssmjp の有志「ssmjp同人部」(か-42)としても、「とある大手町NOCの遍歴」として弊自宅ラックの歴史を寄稿しましたので、そちらもお忘れなくお求めください。
2010年頃よりクラウド関係のコミュニティ活動などを細々と続けてきたのですが、
このたび2017年1月期にてMicrosoft MVPアワードをAzureカテゴリにて受賞いたしました!
ちなみにこのあたりでプロフィールが見られるようです。
コミュニティ活動をがっつりというわけではないのですが、勉強会等での講演やセキュリティ方面での講義などを続けていく中で、なにより本業の方のご協力・環境あっての活動でした。エクストーン、サイバーエージェント、WHEREで理解を示して頂いた皆様にこの場を借りて感謝いたします。また、主要な活動の場を提供して頂いた、qpstudy、ssmjpの両勉強会の皆様、セキュリティ・キャンプの関係者各位にも感謝いたします。そして、何よりこれまでITという科学技術を積み上げてきた先人の皆様方あっての今があります。そこに何かしら直接的・あるいは間接的にでも貢献ができていればと思います。
当初より「優れた技術こそ世に広まるべき」という想いでクラウドに限らずベンダーニュートラルを念頭に活動していますが、今後も引き続き、良い意味でマイクロソフトを贔屓にすることなく、世の中のために頑張って行きます。どうぞよろしくお願いいたします。
この記事は、SORACOM Advent Calendar 2016の18日分(だったはずのもの)です。大変遅れてクリスマス投稿になりました。すみません。。。
さて、全国2億3800万人のSORACOMファンのみなさん、SORACOM Funnelはもちろん使っていますよね?
SORACOM Funnelは、ソラコムのサービスの中では「アプリケーション連携サービス」の「クラウドリソースアダプタ」と位置付けられています。IoTと言われる技術分野の半分は、実世界のオブジェクトのデータをクラウドに送ることですが、それを実現するときに悩ましい部分をまるっとやってくれるのが、このSORACOM Funnelです。
SORACOM Funnelをまだご存じない方も、公式サイトの以下の図を見れば一目瞭然でしょう。
(出典: SORACOM Funnel)
要するに、軽めのプロトコルでFunnelエンドポイントに投げると、良い感じにパブリッククラウドのストリーム処理に投げ込んでくれるというもので、そしてそのために必要なつらい処理を全部やってくれるというものです。
重要なのはこの後半部分です。「とりあえずクラウドに投げるだけ」なら猿でもできるわけですが、じゃあクラウド側に投げるときの端末識別や認証どうするの、とかクラウド側が落ちてるときの再送処理どうするの、とか真面目に運用を考えたときに色々実装や運用が面倒くさい部分がたくさんあるわけです。そこを、SORACOM FunnelはMVNOの出口近くに、そういった面倒なことを全てやってくれるエンドポイントを出してくれているわけです。
こんな感じで投げます。
$ curl -X POST http://funnel.soracom.io -H Content-Type:application/json -d '{"foo":"bar"}'
すると、例えばKinesis Stremsであれば、以下のように届きます。
{ "operatorId": "OP9999999999", "timestamp": 1473322750825, (省略) "payloads": { "foo": "bar" }, "imsi": "440000000000000" }
IMSI(International Mobile Subscriber Identity)がSIM毎に付けられたIDですので、これを見て通信元を判断できます。
たとえばnodeであれば kinesis-stream-lambda というライブラリがあるので、そこに流し込んであげればよいです。
const es = require('event-stream'); const KSL = require('kinesis-stream-lambda'); exports.handle = function(event, context, callback) { const stream = KSL.reader(event, { isAgg: false }); stream.on('end', function() { callback(null, {}); }); stream.on('error', function(err) { context.fail(err); }); stream.pipe(KSL.parseJSON({ expandArray: false })) .pipe(es.map(function(data, cb) { console.log('processing event: %j', data); ※ なんかやる })); };
こんな感じで書いてあげるだけで、機器の識別はできていますし、lambdaが追いつかない場合の再送なども全部SORACOMとクラウドにお任せしてしまうことができ、実装したい処理内容に注力することができます。
IoTと言えばセキュリティが課題、と言われています。組み込み機器自体の脆弱性もさることながら、それらのデータを適切にクラウドに上げることもまた重要です。今年の7月には総務省・経済産業省・IoT推進コンソーシアムの方でIoTセキュリティガイドライン ver1.0が策定されました。この中でも「指針4 ネットワーク上での対策を考える」としてネットワーク接続まわりでのセキュリティ対策がまとめられています。
ましてや、そのデータから得られた分析結果によって組み込み機器にフィードバックを行い、実世界側に対して働きかけを行うCPS(サイバーフィジカルシステム)の時代が来ています。誤ったセンサーデータを送りつけるだけで、下手をすれば人間が傷付けられる可能性もあるわけです。それには、ネットワークの先にある機器をただしく識別・認証する必要があります。
単に機器をインターネットに接続する場合、「自分が誰か」ということを自分自身で相手に証明する必要があります。ここで複数の機器を個別に識別できていないと、たとえば盗難された機器を悪用されたときの被害が大きくなるわけです。そのため、一台ずつ個別の認証情報を配布、管理する必要があります。
SORACOMはMVNO事業者ですし、3G/4Gの通信路は暗号学的に適切な手法を用いて、全てのSIMを識別・認証し、その上の通信も暗号化されています。であれば、この識別の枠組みをそのまま使って、機器とクラウドの間の認証にも利用できれば嬉しいわけです。これを実現するのが、SORACOM Beamsであり、今回取り上げているSORACOM Funnelです。
機器には設置時に個別にどうせSIMを挿すわけで、機器自体には個別の情報を持たせる必要が無くなり「1を0にする」ことが実現します。製造段階での個別作業がゼロになるということは、機器ベンダにとって大きなメリットです。
IoTはその性質から、たくさんの機器からの情報をクラウド側で集約することが求められます。これを全て自前でやろうとすると、自前でMQTTサーバ等を建てたりしないといけないですし、そのMQTTサーバのサイジングや冗長化なども課題となります。というわけで、クラウド時代なのでクラウド事業者が提供してくれているメッセージキューを使うのが良いとされます。具体的には、AWSであれば Kinesis StreamsもしくはKinesis Firehose、AzureであればAzure Event Hubsです。どちらもビッグデータ向けのストリーム処理と銘打っているため、秒間数万件以上のレコードを(お金さえ払えば)処理できるようになっています。
これだけの規模になると、旧来のアプリのように「いったんデータベースに入れてから集計する」というバッチ処理だけでは間に合わない部分が出てきます。そのため、いわゆる「Lambda Architecture」のように、リアルタイムでストリーム処理のまま集計処理を行う必要があります。
KinesisもEvent Hubsも、どちらもそのための枠組みを持っています。一つはAWS LambdaやAzure FunctionsといったFaaSへの繋ぎ込み、もう一つがKinesis Analytics、Stream Analyticsといったストリーム処理エンジンです。前者は散々議論されているので割愛しますが、後者のストリーム処理は来年たくさんの事例が出てくると思われます。
ストリーム処理は、一般的にSQLっぽい感じのクエリを設定しておくとリアルタイムでそれを適用し、直近N秒(ウインドウ)やN秒ごとに集計を継続して出力できるといったものです。最近では「Amazon KinesisとAWS WAFを利用して、サーバレスでリアルタイムな侵入防止システムを作ってみた」などの記事も出ています。膨大に上がってくるデータに対して、まず一次集計を行ってからRDBMSに投入すると言ったことが容易にできます。場合によっては、ストリーム処理だけで最終データまで落とし込める場合も多々あるため、積極的に使っていきたいところです。なお、数年前にNorikraが登場したことをきっかけに、日本国内でもちらほら身近な事例が出てくるようになっています。このあたりをキーワードに検索すると情報が探しやすいです。
というわけで、SORACOM Funnelを使うと、エンドポイントにTCP/UDPやHTTPでJSONぶん投げるだけでこのようなストリーム処理に対してデータを投入できるので楽しいです。
SORACOMの真価は「開発や運用のコストをオフロードできる」点に尽きると考えています。よく言われるような通信費が安いという事だけであれば、ここまでSORACOMが注目を浴びることはなかったでしょう。このような「世界観」をうまく提示したことが、SORACOMが現状で他の追従を許していない理由です。
セキュリティにしろ、ストリーム処理にしろ、自前で全てを実装することももちろん可能です。ところが、それを運用まできっちり回そうとすると、最初に述べたように地獄の産みの苦しみがあります。ぱっと見簡単そうに見えても実際には難しく手間が掛かるという事が往々にして存在するわけです。でも、IoTデバイスを作っている人にとってはそこで勝負をしたいわけではないわけです。サーバレス界隈の方でも「餅は餅屋」と言い続けていますが、自分のビジネスにとって本丸では無い部分に手間やお金を掛けるのは無駄なことであり、でも誰もやってくれないからみんな自分でやっていたわけです。
そこに颯爽と現れたのがSORACOMです。
以前のLT「SORACOM Funnelで手抜きIoTプラットフォーム #ssmjp」でも主張したとおり、通信費の安さだとか、中身がクラウドネイティブでスケールするなんてことはぶっちゃけどうでもいいんです。
重要なことは、自分が今一番作る手間を掛けたいことに注力し、それ以外を楽に済ませるか、ということなんです。
そこに対して、SORACOMの世界観はよく考えられています。特にSORACOMの世界観の中でも、SORACOM BeamsとSORACOM Funnelは画期的です。だって、MVNOのすぐ向こう側というほとんどダウンタイムを考えないで良い場所に、全てを安心して任せられる基盤があるのです。使わなければ損というものでしょう。
というわけで、「SORACOM Funnelはいいぞ」。
この記事は、Serverless Advent Calendar 2016の16日分(だったはずのもの)です。
なんとかクリスマスまでには間に合ったのでお許しくださいorz
こんな感じでそれぞれを掘り下げて行きますです。
「サーバレスアーキテクチャ」は、2012年に単語として提案されて以来4年が経ちましたが、その「サーバの無いアーキテクチャ」という語感から、各領域の問題意識によって様々な意味を持たされてきました。
整理の方向性としては、以下の3つ、もしくは2つ(1+3と2)に分けられるようです。
FirebaseやCognitoなどの、BaaS (Backend as a Service)と呼ばれるサービスの登場が、サーバレスアーキテクチャがキーワードとして取り上げられる発端の一つです。
スマートフォンアプリケーションやブラウザ上のSPA (Single Page Application)が、高水準コンポーネント、とくにID基盤とデータストアを直接利用することによって、自分でアプリケーションを書かずそのためのサーバが不要、というものです。なお、AWSなどでは特に2-Tierアプリケーションと呼んでいます。
とくにユーザ管理と簡易データストアで十分なことも多いモバイルアプリ向けのmBaaSとして広く使われるようになりました。その一方で、最有力であったはずのParse.comのサービス終了など、ビジネスとして単独では厳しいところもあるようです。
BaaSだとサーバ不要で楽だよね、と言われてきた一方で、2014年末にAWS Lambdaが登場して以来「サーバレスアーキテクチャ」の代表的な存在とみなされているのが、このFaaS(Function as a Service)とその実行環境です。AWS自身が「Serverless」であることを積極的に推しているというのもあります。この文脈において「サーバレスアーキテクチャ」とは、全ての場面において利用者が「サーバ」という管理単位を考えずに済むアプリケーション実行環境を指します。
以前よりHeroku方面の「The Twelve-Factor App」などで、アプリケーションはステートレスに作るのが良いというベストプラクティスが広まっていましたが、ステートレス(アプリケーション自身が状態を持たない)という制約のメリットを最大限に活かすことで、クラウド側が自由にスケールさせることができます。
さらに、スケールしたときの起動時間を最小にするために、アプリケーションという単位のかわりに関数(Function)という単位を用いています。実際にはRails等が利用するミドルウェアRackのエンドポイントがcallという単一メソッドであるように、あるいはFaaSであっても一つのエンドポイント関数から複雑なシステム全体を構築することも可能ですし、アプリケーションなのか関数なのかという区別は意識的な部分が強いです。とにかく、ステートレスで軽量な関数ならば、自由にプロセスを増やしたり減らしても良いよね、というわけです。
スケールをクラウド側が勝手に行うこともあり、必然的に課金単位が、利用者の確保したサーバ台数から、実際にアプリケーションの実行に要した消費時間にシフトしました。「所有から利用へ」というクラウドの性質を一歩進め、「確保量から消費量へ」を実現しました。
この「実行時間への課金」の元祖が、2008年のGoogle App Enginenプレビューリリースがだったというのも、歴史的な経緯としては抑えておくべきでしょう。2009年の正式リリース時ではインスタンス単位の課金に変更されてしまいましたが、そこからAWS Lambdaで実効時間の課金が登場するまで5年も要してしまったわけです。
他にも、ちょっと変化球な視点として、FaaSという「Functionの実行環境」に限定せず、サーバという課金単位を持たず計算量で課金されるようなフルマネージドなデータストアもこの分類に入れることができます。たとえばBigQueryの課金形態を見ると、実際のデータ処理容量(MB単位)と処理の複雑さ係数の掛け算となっています。このような小さな処理を膨大な台数で分散して実現するような「薄く広い」元気玉のようなコンポーネントもまた、「確保量から消費量へ」を実現しているといえるでしょう。
最後に紹介するのが、「サーバレスアーキテクチャ」と言われる概念の中で最も抽象度が高いものです。
クライアントからのリクエストを受け付けた「サーバ」が処理の全体に責任を持ち様々なリソースを利用して結果をクライアントに返すのが一般的なシステムのアーキテクチャですが、複数のコンポーネントを非同期なイベント(メッセージ)で接続し、ピタゴラ装置のように全体として機能を実現するアーキテクチャが増えてきました。AWS Lambda(とAWSの各コンポーネント)のユースケースとして様々なパターンが紹介され、確かに「中央集権的なサーバが無くなる」ということからも、この考え方そのものも「サーバレスアーキテクチャ」と呼ぶことが増えています。
実はこの概念は、特に分散並行処理のために設計された言語Erlangの方面から、「アクターモデル」という数学モデルとして整理されてきた考え方に近いものです。最近では「リアクティブシステム」として再整理が行われ、リアクティブ宣言という設計原則が書かれています。
別の視点としては、ビッグデータ分野における分類としてストリームデータ処理という分野があり、バッチ処理、クエリ処理という「サーバ」型の処理モデルに対抗して、フローデータをそのまま常時処理し続ける処理モデルをさします。こちらは、2011年にオープンソースでStormが公開されたことが最初ですが、AWSがAmazon Kinesisを2013年に正式リリースしたことをきっかけに、自前で大規模なクラスタを構築せずにストリームデータ処理ができるようになりました。並行して、FluentdやNorikraのようなよりお手軽なストリーム処理の実装が登場したこともこの動きを支えています。
実装としては、クラウド事業者が提供する高水準コンポーネントが何らかのイベントを生成し、それをメッセージとして数珠つなぎして別の機能を呼び出していきます。ここでLambdaのようなFaaSが介することも多いですが、FaaSすら介さず直接他のコンポーネントの機能を呼び出せる場面も増えています。
この考え方の変化は、アプリケーション開発者であれば、フレームワークによる制御の逆転(Inversion of Control)のクラウド版と考えると分かりやすいと思います。
サーバレスアーキテクチャというキーワードを普及させたAWS Lambda自体は2のFaaSですが、実際に世の中を変えているのは、Lambdaに接続できる高水準コンポーネントを増やした結果、様々な事をメッセージ駆動で容易に実現できるようになった3の効果です。これが一緒くたに宣伝されてしまっていることが「サーバレスアーキテクチャ」の議論が迷走しやすい原因であり、まさにAWS Lambdaの功罪と言えるでしょう。
今年は、まさにFaaSの発展の一年でした。
AWS Lambdaが着実にユースケースを増やすと共に、大規模事業者によるFaaSの提供が始まっています。2016年内に駆け込むように、Azure Functionsとつい先日IBM OpenWhiskが正式リリースされていますし、元祖GoogleからもあらためてGoogle Cloud Functionsがアルファリリースされています。
Lambdaの今年最大のニュースは、CDN(CloudFront)内の制御にLambdaを利用できるLambda@Edgeと、IoTデバイス上でのエッジコンピューティングにLambdaを利用できるAWS Greengrassの登場です。
また、Lambdaでリアクティブシステムを実現するための部品も大幅に増え、ピタゴラ装置の安定稼働に必要なAWS Step Functionsやデッドレターキューなどが提供されました。分散アプリケーションのデバッグを実現するAWS X-Rayも、まだLambdaへの対応待ちですが楽しみなところです。
Lambda自身としてはC#が動くようになったぐらいですが、その一方で、Serverless Frameworkをはじめとしたフレームワークが揃ってきており、AWS自身からも「Serverless Application Model(SAM)」が登場しています。
Azure Functionsは、今年の3月に発表され、11月に正式リリースされました。
パブリッククラウド全体の「圧倒的王者AWSをビジョンで追いかけるMicrosoft」という現状の縮図そのままに、利用できる言語環境の多さや、「出力バインド」という考え方、単独でのHTTP API実行可など、AWS Lambdaよりちょっとうまく設計している感が出ています。
開発者視点に手厚いMicrosoftらしく、Azure CLIを使ったローカル開発、ローカルデバッグ・リモートデバッグをVisual Studioや最近流行りのVS Code上から直接行えるというのが、一番嬉しいところかもしれません。
こちらも2月に発表され、つい先日の12月14日に正式リリースされました。
Azure Functionsも、実行環境のランタイムエンジンはオープンソース公開されているのですが、全体がオープンソース化されているのが最大の特長でしょう。
今年の2月にアルファ版がリリースされ、惜しくも今年中の正式リリースは来ませんでした。
アルファ段階ということもあり、今後に期待ですね。
ごめんなさい、まとめます。
ニフティの富士通化、BIGLOBEのKDDI売却などを背景に、国内クラウド事業者再編の波が始まりました。
やはり「開発戦力の不足」が海外事業者に後れを取っている主原因と思いますので、再編してまだまだ頑張ってほしいところです。
FaaSを中心に拡がっているサーバレスアーキテクチャの波ですが、一つ確実に言えるのは、様々なコンピューティングの形が、FaaSにおけるFunctionという形で整理が進んでいるということです。
たとえばAWSは、IoTデバイスやIoTゲートウェイなどでコンピューティングを行うエッジコンピューティングや、CDNでの小さな制御処理を記述するためのDSLなど、そういった場面でのインターフェースとして、AWS Lambdaのものを拡げようとしています。
インターフェースを統一化してコードの可搬性を高める試みは、太古の昔よりさまざまな「透過性」として議論されてきた分野でもあります。とはいえオーバヘッドが……という部分が処理性能の底上げで解決してきたため、Functionという切り口を様々な場面で利用していこうというわけです。
実行バイナリを共通化するJavaバイトコードという抽象化で「Write once, run anywhere」を謳ったJavaが登場したのが1995年ですが、そこから20年余りがたち、「より良い抽象化されたインターフェース」を誰が握るかという抽象化競争が再び始まったと言えるでしょう。
「餅は餅屋」というわけで、高いレイヤーでの機能を数多く実装した高水準コンポーネントの拡充が、複数の領域で進んでいます。
AWSがメイン環境でも「ここだけは」と使っている事例が多いらしいBigQueryが登場したのが2010年ですが、様々なフルマネージドなデータストアが登場しています。ついにAWSからもBigQuery対抗となるAthenaがリリースされましたし、可視化のためにBIツールとの連携も重視されています。
SORACOM Harvestのように、IoTネットワーク側に近い場所で提供されるデータストアも登場しました。
ビッグデータ処理の本丸がイベントストリーム処理ですが、Amazon Kinesis AnalyticsやAzure Stream Analyticsなどパブリッククラウドでも提供されています。
BIツールへの繋ぎ込み部分というのも重視され始めています。
Kinesis AnalyticsのTokyo regionまだかなあ。
システムを分散処理として設計するには、その間でID管理をどうするかが重要となります。身近な例では、クラウド上のデータストアに直接接続するモバイルアプリが、そのID管理、権限管理を誰がどのように行うか、という領域があります。
この分野はモバイルアプリで利用できる認証基盤を核としたモバイルBaaS(mBaaS)が先行して発展しました。そのため、Amazonが提供するID基盤 Amazon Cognito User Pools がモバイル向けフレームワークの一部であったりと、若干微妙な状況になっていたりしますが、このmBaaSの流れの先で、Googleなどの一般的なID基盤のID情報を利用して、データストア側で直接認可を行う「2-tier architecture」はもはや一般化しています。
「Identity is the New Perimeter」と、セキュリティ上の境界線はもはやネットワークではなくID管理と言われ始めて数年になりますが、OpenID Connectが標準化され情報が増えてきたことで、JWT(JSON Web Token)でID情報を連携して認可を行うモデルの事例が増えてきているようです。地味ですが、サーバレスアーキテクチャをやっていくためには、きっちり抑えておきたい領域です。
Auth0使い始めましたがいいですね。公式Twitterのemoji乱舞 がかわいいです。
自然言語や画像処理など、いわゆるコグニティブ領域のコンポーネントが一気に揃ってきました。キーワードとしてはIBM Watsonが牽引していましたが、今年で一気に花開きました。
いつもSiriに穴がある問題など実用まではまだまだ課題が多い分野ですが、コグニティブ分野はとりあえずピタゴラ装置組み立てるだけでもかなり面白い事例が増えていきそうです。
先行するAWS Lambdaを主戦場に、開発やデプロイのためのフレームワークにおいて競争が始まっています。そのデカい主語の通りマルチクラウドを標榜するServerless Frameworkが1.0を迎えたのにあわせるように、AWSからもServerless Application Model(SAM)が登場しています。その一方で、REST API管理の標準であるSwaggerを中心とした仕組みも拡充してきています。
フレームワークという枠組みとしては、FaaSだけではなく様々な高水準コンポーネントの活用がサーバレスアーキテクチャの大事なところですが、クラウドコンポーネントの管理というところは、各クラウド事業者独自のCloudFormationやAzureリソーステンプレート、あるいはマルチベンダのHashicorp Terraformなどが既に十分な実績を積み立てています。これらのコンポーネント管理と、FaaSのプログラム管理をどう組み合わせていくかが重要です。
今は、FaaSにコンポーネント管理を組み込むフレームワークが主流ですが、FaaSがもはやコンポーネントを接続する「のり」でしかないとすれば、管理の方法も逆転していかなければならないのではと感じています。
旧来とくらべてデバッグしづらいメッセージ駆動アプリケーションということで、VS Code等からの直接デバッグが可能なAzure Functionsや、複数のコンポーネントにまたがった分散トレースを実現するAWS X-Ray、AWS Lambda内部のメトリクスを集めるIOpipeなど、フレームワーク以外の支援も始まっています。
また、運用が始まったあとの監視などまだまだ厳しいという感じですが、2017年に一気に市場が拡がっていくと思われます。
ロンドンで開催されたServerlessConf Londonをきっかけに、日本国内でもServerlessConf Tokyoが開かれ、日本各地でのServerless Meetupなども開かれています。開発者間のコミュニティ醸成により、来年はさらなる発展の加速とベストプラクティスへの落とし込みが進むでしょう。
各社FaaSがだいたい揃ったという事で、高水準コンポーネントを含めた世界観全体で殴り合う総力戦がよーいどんです。
あと本家PaaSの本命であるHerokuあたりも、あらためて動きがあるのではないかなーと思っていたりします。
それはそれとして、大規模アプリケーションをサーバレスに実現しようとすると、まだまだ「開発で消耗する」という部分が大きいです。この「開発しやすさ」という部分が2017年の一番の主戦場となるでしょう。個人的にはデバッガでさくさくデバッグしたいところです。console.log でのprint debugは本当につらいです。本当につらいです。
ある程度の規模までは、いろいろな実現すべき仕様を分解・整理していくと、ID管理を核に接続されたマイクロサービスでシンプルに実現することができ、その方が最終的には見通しも良く不具合の影響を閉じ込められるシステムになるはずだと考えています。そういったソフトウェア工学という視点からも、様々な分析とベストプラクティスの積み上げが進むでしょう。
来年一年はまだみんな人柱ですね、「サーバレスをやっていくというお気持ち」で頑張っていきましょう。
こんな感じの事を8月に書いた同人誌、通称「サーバレスの薄い本」を電子書籍で頒布中です。
今年の年末のコミックマーケット91にも参加します。なんとかぎりぎりまで粘って新刊出す予定です。
のおおおおおおおお!!!!!!!
タイトルが「2016年のサーバアレスアーキテクチャ総まとめ」になっていたのを修正しました……。
2年半お世話になったサイバーエージェントを先月一杯で退職し、本日からWHEREではたらくことになりました。
ざっくり三つの部署を渡り歩きました。
初めての大企業、大規模サービスでしたが、それに見あった経験を得ることができて、採用を決めて頂いたHさん、Sさん、Tさんには今でも感謝が絶えません。
担当システム外としては、社内チューニンガソンで優勝させてもらったり、某クソコラ職人氏と一緒にうるう秒反対対応などやったりしていました。
まあ割とフリーダムにやらせて頂いていただきました。
端的に言うと知人からの引き抜きです。
転職先のWHEREは、測位技術によるジオソリューションを提供する会社です。観光や防災を主要なキーワードとしておもてナビというブランドを提供しています。また、昨年末に協和エクシオさんの子会社になりまして*1、測位技術を使って世の中を変えていきます。まずは2020年の東京オリンピック・パラリンピックに向けて、全力全開、頑張ります。
転職の決め手は、日本での位置測位と言えば準天頂衛星です*2。宇宙ですね。
そんな感じです。はい。
再び開発メインに戻ってきました。早速Spring FrameworkとかMyBatisとか弄ってます。
中小企業がオンプレ持つ時代でも無くがりがりパブリッククラウドも使っていくので、各方面の皆様今後ともよろしくお願いいたします。
従業員としては離れることになりましたが、サイバーエージェントの皆様とも一緒に仕事ができる機会を作っていきたいので、そちらも末永く縁をつないでいければと思います。