成長事業の代償「技術的負債」を解消する！既存ラクスルの「解体」が生んだ新たな価値 | SELECK [セレック]
変化の激しい現代におけるシステム開発では、できるだけ早くプロダクトを世の中に出してフィードバックをもらい、またプロダクトを磨く…というリーンな開発サイクルを高速で回すことが重要だ。 しかし、このトレードオフとして生まれるのが、システム開発における「技術的負債」だ。 ラクスル株式会社では、2017年に「Raksul Platform Project」を立ち上げ。「触れば誰でも怪我をする」PHP40万行、JavaScript10万行という規模の巨大なアプリケーションが抱えた技術的負債の返済に着手した。 その目的は、既存ラクスルの解体。一枚岩のシステムを機能ごとに小分けすることで、それぞれ独立したチームがアジャイル（俊敏）に顧客へと価値を届けられる状態を目指した。 結果として、技術的負債を大きく返済することに成功。創業当初から描いてきた「印刷産業を変えるプラットフォームになる」ための事業の多角化
![成長事業の代償「技術的負債」を解消する！既存ラクスルの「解体」が生んだ新たな価値 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/34fac6d04d3d2fc04278660aeae588332eece96b/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2021%2F05%2F11122652%2F97019519de0b032589501f0a6693213e.jpg)
Microservices における認証と認可の設計パターン
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
