Platform EngineerとしてのPractice（2020年）
Platform EngineerとしてのPractice（2020年） 少し前にキャリアに関してインタビューを受けたが，振り返ってみると前職のCloud Foundryによる社内PaaSから現職におけるKubernetesによるMicroservices platformまでかれこれ5年にわたってPlatformの開発と運用に携わってきたことになる． 5年もやってるとPlatform engineer（Platfomer）として，特定の技術とはある程度中立的なところで習慣として当たり前にやっていることや日々の意思決定の基礎になる考え方みたいなものが出てくる．見ればわかるようにこれは何か特別な考え方とかではなくてどっかで見たことや聞いたことがあるものがほとんどだと思う．自分の中でゼロから生まれたものではなくて現在のチームと働いた経験や日々のインプット，これまでの失敗の総体でしかない． 現在
メルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ - Findy Engineer Lab
IT技術は進歩のスピードが速い領域です。だからこそ過去から現在、そして将来に向けた変化を理解することは、ITエンジニアとしてキャリアを構築していく上で必要な考察となるでしょう。ときには、こうあるべきという将来像を描くこともあるかもしれません。 株式会社メルカリでプラットフォームチームのテックリードを務める中島大一（@deeeet）さんは現在、メルカリが2年ほど前から進めているマイクロサービスへのアーキテクチャ移行において、そのインフラ自体や、そこで開発するエンジニアに向けたツールセットの提供などを行っています。 エンジニアとしてキャリア7年になる中島さんですが、2年目の2015年には同じような当時の若手インフラエンジニア（@ryot_a_raiさん、@rrreeeyyyさん、@yuuk1tさん、@hfmさん、@catatsuyさん）との集まりで、「ある若手インフラエンジニアの現状確認」と題
Team Topologiesを読んだ
https://teamtopologies.com/ DevOps consultantとして技術と組織の両面からDevOpsの支援を行なってるMatthew SkeltonとManuel Paisによる本．Consultant本は大体中身が薄く感じることが多くなり手に取ることは少なくなってきたが，各所で見かけたり，2人によるDevOpsにおけるチームのあり方のパターンをまとめたWhat Team Structure is Right for DevOps to Flourish?が良かったので読んでみた． 本書はDevOpsの視点から高速なDeliveryを実現するためにどのようなチームや組織を作るべきかについてまとめている．個人ではなくチームをDeliveryの最も重要な単位と考え（Team first-thinking），チームが最大限にパフォーマンスを発揮するために，チームの人数
Mercari Microservices Platformの進捗（2019年） | メルカリエンジニアリング
Microservices Platform TeamでTech leadをしている@deeeeeeetです． 昨年のMTC2018ではMicroservices Platformチームの立ち上げから1年で僕らが取り組んできたことを紹介しました． speakerdeck.com 具体的にはStranglerパターンによるMonolithからMicroservicesへの段階的なリクエスト移行を行うためのAPI gatewayの開発や，Microservicesのインフラのセットアップを簡単にしサービス開発チームのSelf-service化を進めるためのStarter-kitの開発，GoでのMicroservicesの開発を高速で始めるためのTemplateプロジェクトの開発，Spinnakerの導入などについて紹介しました． これらはPlatformとして最低限の機能を整備したにすぎず，さ
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
エンジニアと立ち話。Vol.8 ＠deeeet（SRE） ちょっとお話いいですか？ | mercan (メルカン)
ソフトウェアエンジニアの@kajikenがメルカリで働くエンジニアたちを捕まえて、ちょこっとお話を聞いていく本シリーズ。第8回はメルカリ SRE（Site Reliability Engineering）チームメンバーの中島大一さん（@deeeet）です。 @kajiken：@deeeetさん、ちょっといいですか。 @deeeet：ちょっと待ってください今goroutineをcancelします。はい。どうぞ。 @kajiken：入社日と職種を教えてください。 @deeeet：2017年の1月に入社しました。SRE（Site Reliability Engineering）チームメンバーとして働いています。 @kajiken：これまでの経歴を教えてください。 @deeeet：大学の研究室ではNLPを、大学院に入ってからはロボットや音声対話の研究をしていました。新卒で楽天に入社して、最初はko
SREとしてMercariに入社した | SOTA
1月16日よりMercariにてSRE/BSE（Backend System Engineer）として働いてる． これまではとある会社で社内向けのPaaSエンジニアとして働いてきた（ref. PaaSエンジニアになった）．PaaSの目標である「アプリケーション開発者の効率を最大化」を突き詰めながら少人数のチームでいかにScalableなプラットフォームを構築するかに注力してきた．Cloud FoundryやDockerといったインフラの最前線とも言える技術やアーキテクチャに触れ，かつその中で自分の技術的な柱である自動化に取り組むことができたのは非常に刺激的で自分に大きなプラスになった． その一方でPaaSというプラットフォームはその性質上サービスそのものからは中立的になることが避けられない（だからこそScalabilityを実現できるのだが）．よりサービスに近い部分，サービスの成長に直結す
2016年振り返り
最初に今年やったことなどをつらつらと書いてみる． 2月．Dave Cheneyが中心となりGo1.6のRelease Partyが世界各地で開催されることになった（Go 1.6 release party）．東京でもやりたかったのでOrganizerとなりHatenaのオフィスを借りて開催した．8月のGo1.7のリリース時は特に世界規模でやる流れはなかったがフォーマットだけは借りて再びHatenaのオフィスで開催した．この時リリースの概要をまとめたスライドを作ったが@bradfitzがそれを改変して別のMeetupの発表資料に使ってくれた嬉しかった．2017年2月にリリース予定のGo1.8のリリース時は再び世界規模でやるかってのをDaveと話したのでぜひ参加してください． 5月．みんなのGo言語の執筆を主に行っていた．自分はコマンドラインツールに関する章を担当した．今まで発表やブログ記事の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
