The Zengineer Issue #2

Must-Read Platform Engineering Insights: Shopify's Iterative Approach to React Native, SRE vs Platform Engineering and The Developer Comfort Zone

Hope you all had a lovely weekend. It was *very* windy and cold in NYC so I spent most of this weekend on the couch catching up movies I’ve been meaning to watch like Jane Campion’s The Power of the Dog and Park Chan-Wook’s The Handmaiden. And making some homemade ramen (which is way harder than it sounds, okay?) Alright–on to today’s issue with 3 pieces of must-read Platform Engineering content!

Shopify: Migrating our largest mobile app to React Native

Why it’s important: Last week we saw a piece from Spotify which argued that “migrations of this nature and magnitude [i.e. large and across many teams] might become a new normal”. We’re starting to discover the design patterns for these types of migrations. Shopify introduces one called “iterative porting” (visualized by yours truly below). Iterative porting in this case means they started building all new features in React Native while migrating existing features in parallel.

TL;DR / Sneak peek: “We wanted to identify all the surfaces that need to be migrated to React Native so that we could use them to plan our work and measure our progress. To do this, we wrote a custom script that looked at our iOS and Android code and identified all the source files that would have to be migrated.

We then populated these files into a spreadsheet and categorized them by feature and sub-teams. We also added columns to indicate complexity and status. Each sub-team had a clear, well-defined scope for the migration. There were a few surfaces that were no longer owned by any teams, so we identified new owners for them.”

SRE vs. Platform Engineering: What's The Difference?

Why it’s important: As engineers, we know that precise language is important. We can’t productively discuss a concept without knowing if we’re even talking about the same thing. Much has been said about difference between SRE and Platform Engineering–some of it good, most of it confusing and devoid of context. This piece breaks down the differences without overgeneralizing.

SREs are first and foremost are first and foremost focused on reliability. They come alive in incident response and as the Google SRE Book puts it, “SRE is what happens when you ask a software engineer to design an operations team”. I’d argue that Platform Engineering is what happens when you ask a software engineer to build a product that optimizes for developer productivity. One point I disagree on is that Platform Engineering feels broader in scope than SRE because it’s also focused on increasing developer velocity / software delivery with the understanding that with increased speed comes increased quality (faster iterations = more learning = higher quality), while reliability still needs to be baked in.

A strong platform team should have equally deep grounding in operations, software development, and product thinking. You can pull together a strong, well-rounded team by assembling a mix of SWEs, SREs, and PMs.

TL;DR: “Thus, both SREs and platform engineers play a role in managing the software delivery process and finding ways to make it as smooth and efficient as possible. They also share a common enemy—toil—in the sense that both groups seek to avoid manual, inefficient processes by automating as much as possible. SREs automate complex incident response operations using tools, for example, while platform engineers might deploy methods like GitOps to automate some aspects of software delivery … The main job of SREs is maximizing reliability, which is different from optimizing the speed and efficiency of software delivery operations. Theoretically, you could have a highly reliable system even if your software delivery chain is manual and slow.”

Twitter Thread: The Developer Comfort Zone

Why it’s important: I like this thread because I think the mental model of moving the more complex elements of your infrastructure into the “developer comfort zone” is a helpful north star. It’s also refreshing to hear examples of what IDPs might look like at companies of different stages (“At a small company, it could be a set of helm charts that prescribe best practices for deploying services. At a large company, it might be a fully automated Infrastructure as Code solution.”)

TL;DR: “Platform engineers build the tooling and abstractions around the complex infrastructure configurations such that most software engineers don't need to worry about those aspects as much. The resulting system is what is known as an Internal Developer Platform (IDP)”.

Thanks for reading! See ya next week.

David

P.S. Have a piece of content that you would like to see featured? Let me know here.