Designing Distributed Systems

Designing Distributed Systems

Patterns and Paradigms for Scalable, Reliable Services
By Brendan Burns
Publisher: O'Reilly Media
Release Date: February 2018
Pages: 166

Without established design patterns to guide them, developers have had to build distributed systems from scratch, and most of these systems are very unique indeed. Today, the increasing use of containers has paved the way for core distributed system patterns and reusable containerized components. This practical guide presents a collection of repeatable, generic patterns to help make the development of reliable distributed systems far more approachable and efficient.What the book is for?
The book describes about example of architecture which is assumed to be built on kubernetes. Yaml files for kuberenetes are also included with explanation as well as the codes.

Designing Distributed Systems

Free book from Microsoft is also available.

Who should read the book?

Anyone who would like to know design and architecture patterns for kubernetes.

Impression

It's good as a recipe book. Some basic and easy to apply architecture patterns are described with use cases. It should be one to be recommended to every kubernetes application developers.

SCRUM BOOT CAMP THE BOOKを読んでみた

SCRUM BOOT CAMP THE BOOK

スクラムについて一通り学べる。基礎編と実践編の二部構成になっている。
基礎編で用語や概念が説明され、実践編ではそれをどのように適用していけばよいかが説明されている。

座学で得られる限りの情報はこの本で学べるのではなかろうか。

特に実践編ではスクラムを現場にどのように導入していく様子が漫画のストーリで描かれており、イメージが付きやすい。

スクラム導入のための本としては良本。

「エンジニアのためのマネジメントキャリアパス」を読んで管理職について考えてみた

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

を読んでみた。

入社されたばかりの被管理者であるSoftware Engineerから始まり、チームを束ねるTech Lead(TL)、管理職や管理職の管理職、そしてVP of Engineering(VPoE)やCTOなどの役職について、期待される役割や課題などを説明している。ざっくりと昨今のTech界隈の役職を俯瞰するのには最適の一冊であろう。

よくまとまってて読みやすい書籍ではある。ただ、ちょっと身も蓋もない言い方になるのだが、会社の役職なんて同じ名前でも役割が違うので、これを読んでどう活用するかは若干難しい。原著は米国の書籍であるので、当然のこととして、日米の文化的・法律的な差異もあるはずである。技術書のように、これを教科書として絶対視しても意味がないので、著者の界隈ではこういう共通認識で回ってるのだろう、といった参考程度に勉強するのが好ましいのであろう。


一点だけ大きく興味をそそられた箇所があった。
5.1節の「ITスキルの維持」の記述のところである。

管理職に転向した後の技術的知識のアップデートに関する主張であり、これ以上コードを書いても技術力が頭打ちになるラインまでは管理職になってもコードを書き続けよう、ということであった。技術力がしっかりと身につくまでは、管理職としても大成できない。そして上級の管理職になってからも何らかの技術的コミットメントを続けるべきだ、と。この意見はとても正しく思える。

私もソフトウェアエンジニアとしてのキャリアの中で、エンジニアから管理職に転向した方を多く知っている。ほとんどの方は、Mangerに転向したのを機にコーディングを行わなくなる。その結果、例えば20世紀にWindowsアプリの開発を行っていた人が、Windowsアプリのパラダイムのままネットの技術を語ったり、クラウド以前のInternet上でWebアプリを開発していた人が、その価値観のまま、クラウドの技術を捉える、といった状況に多く遭遇した。表面的な知識は間違ってないのだが、「それは根本的に考え方が違うんだよなあ」、と突っ込みたくなる状況である。

もちろん、管理職という立場で時間の許す限りキャッチアップは続けているのだろうが、Webの前後、あるいはクラウドの前後、そしてマイクロサービスの前後といったような大きなパラダイムの変換があるときには、業務を前提に深くコードを書いていない限り自分の中の技術的パラダイムはアップデートできない。プライベートな時間で自分しか見ないレベルのコードを書いたとしても、当然のこととして仕事で向き合うのと理解の度合いは違う。業務外でコミットしているオープンソースがあったり、副業としてエンジニアを続けているのでない限り、どの立場になってもコードを書き続けない限りいずれその人の技術的価値観は時代遅れのものになるのだろう。


ただ、言うのは簡単だが、マネージャ業務をしながら開発業務にもコミットし続けるのはとても厳しい。解決策としては、マネージャとエンジニアを数年おきに、すっぱりとJob Changeするくらいしかないかもしれない。米国ではよく(たまに？)あるとは聞くが、少なくとも日本ではあまり聞いたことがない。もしかしたら今後はこのようなJob Rotationが必要とされるかもしれない。