The time to read this newsletter is 150 minutes.
Curiosity is, in great and generous minds, the first passion and the last – Samuel Johnson
- Monorepos: Please don’t!: 20 mins read. In this post, Matt Klein gives reasons to why monorepo approach does not provide benefits most often cited by monorepo proponents. His recommendation is to go with polyrepo structure. The post makes four valid arguments:
- Organizations that use monorepo spend considerable engineering resources on building tools to work with monorepos. Most organisations don’t have such luxury.
- Monorepo makes it difficult to open source internal projects as you have single commit history
- Most VCS are not meant to be used for large monolithic repositories. There is some work done by Microsoft as part of its git VFS project but it has some rough edges.
- The last interesting point that post makes is The frank reality is that, at scale, how well an organization does with code sharing, collaboration, tight coupling, etc. is a direct result of engineering culture and leadership, and has nothing to do with whether a monorepo or a polyrepo is used.
The main drawback of polyrepo approach is that it creates a culture where different teams own different parts of the code. There are few people in organization aware of the big picture. This point is beautifully put by Adam Jacob in his post – Monorepo: please do!.
My take on this is somewhere in between. For example, if you are building a web application then I like to keep all backend Microservices in one repository and front-end application in another repo. I think the best is somewhere in between the both approaches. Taking either too far does not work.
- Learn how to use JSON Web Tokens (JWT) for Authentication: 15 mins read. This is a good tutorial for anyone wanting to learn about JWT. JWT are mostly used as API tokens. This tutorial will give you a good idea about what is JWT and how to use them. It also covers an important point about JWT tokens that they can’t be invalidated as they are immutable in nature. This means you have to build a mechanism using a database to invalidate them. The post covers how you can use Redis or LevelDB to do that.
-
Rethinking how we interview in Microsoft’s Developer Division: 10 mins read. Great to see organisations like Microsoft thinking about moving away from traditional technical interviews. Technical interviews in most technical startups and tech giants are exhausting and tiring. Most of the time they end up demotivating a candidate. Most of the software developers end up building CRUD apps and plumbing APIs. But in the interview we expect candidate to answer difficult algorithmic problems. Most of us don’t perform well if we know we are being judged in open. With Microsoft moving towards an interviewee focussed interview I expect many organisations will rethink about their interview process.
-
Stamping on event-stream: 30 mins read. This is the best post-mortem analysis I have read. This post covers event-stream incident in detail. In case you are not aware of the event-stream issues, in November 2018 it was discovered that the npm package event-stream was stealing people’s bitcoin wallets. On investigation, they found the original maintainer had passed it over to an anonymous person because “he said he wanted to maintain it”. Read this amazing post to learn how to author did this incident analysis using STAMP(SystemsTheoretic Accident Modeling and Processes) model.
-
How Battlehouse saved $60,000 a year on AWS: 10 mins read. This post covers how Battlehouse cut cloud cost by 50%, saving about $60,000 a year. This is how they saved dollars:
- Ensure all ongoing EC2 and RDS capacity was covered by reserved instances. Amazon’s reservation system allows you to pre-pay for 12 or 36 months of usage in advance, and in return receive a discount of about 50% compared to hourly pricing.
- Switching from Amazon CloudFront to CloudFare for CDN
- Identifying cold and host storage and using appropriate technology for them. For hot storage they used MongoDB and RDS and for cold storage they used S3.
- How Facebook Keeps Messenger From Crashing on New Year’s Eve: 10 mins read. This article gives lists a couple of interesting approaches to tackle high load using queues. For me the key takeaway points are:
- Architect your system for graceful degradation
- Your application should distinguish between high and low priority messages. In case of high load, application should delay processing of low priority messages
- Use batching to process requests with similar characteristics. The example of affinity cited in the post Two messages may have higher affinity if they are travelling to the same recipient of require similar resources from back-end.
- How Azure SQL DB Hyperscale Works: 20 mins read. This article covers in good detail how cloud native relational database like Azure SQL DB Hyperscale or Amazon Aurora works. The author writes, Both AWS Aurora and Microsoft Azure SQL DB Hyperscale take the same approach here, offloading deletes/updates/inserts to a log service, and then letting the log service change the data file directly.
-
Microservices Architecture: Advantages and Drawbacks: 15 mins read. This post covers advantages and drawbacks of Microservices. Apart from the advantages mentioned in the post, one more advantage of Microservices is that it can help scale an organization. If you end up using Microservices, you should know that there are many challenges of this approach. The advantages in your scenario should outweigh the drawbacks. To build Microservices you need a mature team. Also, you need few people in the organization that can keep the bigger picture in mind and can think abstractly.
-
What Deep Breathing Does to Your Body: 10 mins read. I am going to start doing this from now. To make it a consistent habit, I am going to stack it with my habit of using pomodoro technique. After every 50 mins of work, I take 10 mins of break. I will use that 10 mins for drinking water, small walk, and deep breathing.
-
What’s Microproductivity? The Small Habit That Will Lead You To Big Wins: 10 mins read. I apply this at work and in my personal life. This is great read for everyone who is feeling overwhelmed by the work they have to do. In software development, Agile methodology is one way we ensure we get quick feedback, divide work into manageable chunks, and keep delivering value.
The video that you can watch this week – The computer revolution hasn’t happened yet