Here are 10 posts I thought were worth sharing this week.
#1. How eBPF will solve Service Mesh – Goodbye Sidecars – Link
Service Mesh has evolved over the years. We started from a library based approach, then moved on to the sidecar containers, and finally service mesh capabilities will become part of Linux via eBPF. We use Istio at work. I was aware that there is some overhead of Istio as you have a proxy with each workload. As per this post, sidecar container based service meshes add 3-4 times of latency. This is a huge cost. For a 500 node cluster where each node runs 30 pods this adds up to 1TB of memory used by all sidecar proxies. This assumes each proxy adds 70MB of overhead. eBPF is a technology to watch. It looks like it is the technology that will make service mesh efficient and performant. It is still in early days so we will have to wait before it becomes mainstream.
#2. Your Teams Don’t Need To Set Their Own Goals – Link
I have also seen this working. Most of the time teams don’t know and understand how they should go about achieving a large goal. Then, you as a leader have to break a large goal down to small, manageable goals that the team can aim to achieve. I prefer goals to be realistic. They don’t have to be easy but they don’t have to be too difficult as well. You have to build the team’s confidence and that is built when they achieve realistic goals. It requires a leader to have clarity and they should be good at decomposing problems.
#3. Why our team cancelled our move to microservices – Link
There are only three reasons why I select Microservices architecture:
- Scale engineering team. Microservices help you divide the work better among small teams and these teams can take complete ownership
- Organisation already has DevOps maturity or is willing to invest in building a platform
- I clearly know that different components will have different NFRs
Also, you don’t have to go full mode on Microservices. Find the component that has problems that can be fixed by Microservices and then extract that components out only. Then, if you get perceived benefits then only start applying it aggressively.
Microservices done wrong are worse than monolithic systems. You get all the pain with no benefits.
#4. Postgres Indexes for Newbies – Link
Nice and easy ready on Postgres indexes. I am working on a use case where we have to query on timestamp range. Postgres BRIN indexes look like a right fit for that.
#5. Stop paying tech debts, start maintaining code – Link
I agree with the author. We have to schedule regular maintenance cycles to do the required code maintenance. This includes version upgrades, automation, build time improvements, fixing flaky tests, etc. I have done one week maintenance window every 3 months. It worked pretty well for us. There is a lot of actionable advice in the post.
#6. Every Simple Language Will Eventually End Up Turing Complete – Link
It is difficult to keep things simple. This is especially true when people start using it. They want more and more features and soon the simple thing becomes complex.
In this post, the author talks about how a simple markup language like YAML becomes complex to use when we start to use Turing complete Go templates to meet our Kubernetes needs.
This is what happens with every simple thing – 1) you release something simple 2) people like it and start to use it because of its simplicity 3) then people wants to do X, Y, Z from the simple thing 4) we make our simple thing configurable, extensible, feature rich to meet needs of its consumers 5) Now, we end up with a complex thing. This cycle keeps on repeating. Simplicity is a journey it never ends. You have to keep saying no and remain true to its ethos. Easier said than done.
#7. Amazon’s DynamoDB — 10 years later – Link
DynamoDB is an amazing piece of technology. I am yet to use it in a real world project. We are thinking of using it an application that has a chat requirement. Its feature set is impressive and it is fully serverless.
#8. Architecting Distributed Systems: Increasing Availability Using Client Libraries – Link
I have also come to the same realization that for the core services service owners should provide HTTP clients as well. They know their APIs best and can write an efficient HTTP client by using sane defaults and adding retries to idempotent operations.
#9. Tech predictions for 2022 and beyond – Link
Amazon.com’s CTO, Werner Vogels, offers his five predictions of what might be in store for us this year and beyond. For me the first item in his list is the most important and it is something that I am following as well. I also think “AI-supported software development” will get big in 2022.
#10. Uncomfortable Truths in Software Engineering – Link
I can’t agree more with this list. I can add a couple more to the list:
- 90% of the work will be done by 10% of the people
- It does not matter whether you practice Agile or Waterfall or Scrumfall software development methodology customers are still going to ask for fixed time and cost proposals
- Whatever way you employ to measure software delivery quality it will eventually get gamed
- Most of us are trying to build the way FAANG does with people that have less than 10% of the capability of the people employed at FAANG
Shekhar Gulati 