Googleでディレクターを務めるAstrid Atkinson氏はこの10年の経験を引き合いにして、長期にわたるエンジニアリングに関するルールを示し、アドバイスをした。サンタクレアで開催されたVelocity Conference 2015の参加者が学んだのは、幅広く成功していることをイメージすること、複雑は排除するのではなく管理すること、チームをスケールするのではなく、システムをスケールすることに注力すること、だ。
成功しつつあるのであれば、どのような理由であれ、複雑さは増大し続けるので、複雑さを管理することに注力するべきだ。氏は製品を駆動する成長は止めてはならない、という。複雑すぎるという理由で何かを止めてはならない。その一方で、非効率さを削減するための時間的人的コストに目を向けるべきだ。
Atkinson氏は良いチームや良い開発者が貴重であり、見つけにくいことを強調する。長期的に成功するには、システムは指数関数的に成長する。しかし、チームの成長はほぼ直線だ。従って、大きな投資をする。採用やトレーニングだ。チームはシステムについていってほしい。氏は"チームはあなたのサービス"だという。燃え尽きさせてはならない。邪魔をするものを管理しなければならない。重荷は解体する。開発と運用の両方が必要だ。
成長を可能にするには、個別の解決策を可能な限り安定させる必要がある。保存の構成の定義はどこでも一緒にする。命名を標準化する。個別のマシンを管理するのをやめる。氏はGoogleでのいくつかの事例を紹介する。Googleのサーバは小さなHTTPサーバを搭載し、ステータスページを返す。このページは基本的な情報を提供する。トラフィックやビルドされた日なのだ。同社のクラスタマネージャであるBorgは、個別のマシンを抽象化することで、エンジニアがサービスの運用管理をしやすくする。
長期にわたるエンジニアリングとはメンテナンス性に注意を払うということだ。開発チームが大きくなっているのなら、すべてのシステムをどのように管理し維持するのかを考えるのが重要だ。氏は2つのルールを提示した。まず、それぞれのサービスが自分自身を管理し、自分自身と外部との通信も管理する。そして、共通のインフラを使う。同じようなことをしているサービスが複数あるなら、整理統合し、余計なオーバヘッドが発生しないようにする。整理統合については、氏はDan McKinley氏のインフラ選択についてのアドバイスを評価している。つまり、もっとも安定しているものを選択すること。統合にかかる作業量も考慮しなければならない。リスクが高く、長い時間かかるかもしれないからだ。氏は顧客第一優先で進め、リスクは事前に対処することを好んでいる。
また、"雑草が庭園の高さよりも高くならないようにする"ことをアドバイスする。つまり、エンジニアリングプロセスをサポートするツールに対して投資するということだ。ビルドやテスト、監視("ユーザの視点から")などだ。また、2度以上実行するタスクは自動化する。
Astrid Atkinson氏の公園はオンラインでも視聴できる。