Here are 10 posts I thought were worth sharing this week:
Mono-Repo vs One-Per-Service – Link
I prefer Monorepo over Polyrepo(one repo per service) approach. The author made a good point on the cost of monorepo rising steeply once your team size reaches 100~150 developers. Author suggests that you can start with a monorepo and if your development team velocity starts to take a hit because of code organization then you can split the monorepo into multiple repositories.
I work in an IT service organization where the biggest project that we do has 50-70 developers. After deliberating a lot I have started using the following structure. So, in my setup I have 4 git repos. Consider a team of 50 developers, none of the repos cross more than 25 developers working on a single repo. I have shared my thoughts on Monorepo here.
How To Rapidly Improve At Any Programming Language – Link
This makes sense. Reading closed PRs of an open source project can be a valuable source of knowledge. I might give it a try as well. I tried doing code reading earlier when I went over code of popular open source library Retrofit and blogged about lessons I learnt.
Rethinking Task Size in SRE – Link
This post makes the point that bigger tasks could significantly improve our efficiency (by 25% for the example described in this article), which prompted us to explore and employ vertical scaling to improve the efficiency of our fleet of computing infrastructure. I have read similar experience reports in the context of Serverless as well. Using bigger(more CPU and RAM) AWS lambda instances are both efficient and cheap.
Are you ready for production? – Link
This is a good talk on things you should keep in mind before deploying your service in production. It covers how Google does production readiness review. It covers various checklists related to security, observability, release management, code readiness, etc.
3 Domain-Centric Architectures Every Software Architect Should Know – Link
This post covers three architecture styles that we can use to structure our code. It covers hexagonal architecture, onion, and clean architecture.
Scalability concepts: zero-downtime deployments – Link
This post covers how Blue-Green and rolling update deployment strategies work under the hood. It will help you build the mental model on how different tools implement them and when to use which strategy.
Uber’s Fulfillment Platform: Ground-up Re-architecture to Accelerate Uber’s Go/Get Strategy – Link
This is an amazing read from Uber engineering team. They talk in depth on architectural shortcomings of the existing fullfilment platform, how they evaluated technologies, requirements from the new architecture, and how Spanner, a NewSQL database helped them realized their requirements. An amazing read. You will have to read it multiple times. There is so much to learn from this post.
Reading Code is a Skill – Link
Trisha Gee talks about why we should focus on building code reading skills rather than just blaming the authors of the original code for poor code. You will read code more than you write code. I agree with her in entirety. In an ideal world everybody should real clean and maintainable code but under time pressure, changing requirements, new languages/frameworks, or sheer in-experience of the tream lead us to writing code that is not clean. I have worked with customers that discouraged refactoring and automated testing. This does happen in the real world whether we like it or not.
React Native’s Many Platform Vision – Link
I enjoy reading posts like these. They help you understand the vision creators have for their tools/platforms. One of the vision statements mentioned in the post is that React Native team has plans to expand React Native beyond mobile and support desktop and VR apps.
Software Deploys and Cognitive Biases – Link
This is a nice short post by Charity Majors on cognitive biases that drive statements around software deployed like “No Friday deploys!”
Shekhar Gulati 