Hello All,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 195 minutes. This week newsletter has stories on bullshit web, CAP theorem, slow thinking, productivity, faster JSON parsing with Stanford Sparser, Serverless, Shopify tech stack and few more.
It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away. – Antoine de Saint Exupéry
Most of us are building distributed systems. This is a fact. According to Wikipedia, a distributed system is a system whose components are located on different networked computers, which then communicate and coordinate their actions by passing messages to each other. A distributed system could either be a standard three-tier web application or it could be a massive multiplayer online game.
The goal of a distributed system is to solve a problem that can’t be solved on a single machine. A single machine can’t provide enough compute or storage resources required to solve the problem. The user of a distributed system perceives the collection of autonomous machines as a single unit.
The distributed systems are complex as there are several moving parts. You can scale out components to finish the workloads in a reasonable time. Because of numerous moving parts and their different scaling needs it becomes difficult to reason out the characteristics of a distributed applications. CAP theorem can help us.
For every complex problem there is an answer that is clear, simple, and wrong — H. L. Mencken
I am starting a new blog series (with no end date) from today. In this series, I will pick a topic and go in-depth so that I don’t just scratch the surface of the topic. The goal is to build a habit of learning each week and share it with the community. For the next few months, I will write on different aspects of building distributed systems. Each Wednesday, you may expect a new post.
I am sure we all have built applications where one application uses another application to do its job. Most of the time, applications communicate with each other using HTTP REST API but it can be other communication mechanisms like gRPC, Thrift, Message Queues as well. For example, if you are building an application that needs Twitter service for fetching tweets. To call Twitter API, you will need the API URL and access keys to make a successful API call. Most often we rely on static configuration either in the form of a configuration file or environment variable to get the API URL. This approach works fine when you are working with third party APIs like Twitter as their API URLs do not change often. The static configuration approach fails when we build a Microservices architecture based application. The definition of Microservices that I like is by Martin Fowler as described in his blog,
Microservice architecture style is an approach to developing a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms, often an HTTP resource API.
Hello All,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 148 minutes. This week newsletter has stories on JOMO, How Netflix works, Amazon RDS, Amazon Aurora, Deep work, and few more interesting topics.
Make your peace with the fact that saying ‘no’ often requires trading popularity for respect. — Greg McKeown
Since last couple of years, writing has fascinated me. I became interested in writing as I started spending more time reading books. I have read more books in last couple of years than I have read in my entire life. Good books make you think, question, and become more self-aware.
Stephen King, an American author of horror, supernatural fiction, suspense, science fiction and fantasy once said
If you don’t have time to read, you don’t have time to write. Simple as that.
I think writing is the natural side effect of reading.
