I found the below graph while reading the “So how much architecture is enough” chapter of the Making Software book. This chapter is written by Barry Bohem.Continue reading “How much time should you spend on Software Architecture?”
Little’s law states that the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system.
L = Average number of customers in a stationary system
λ = Average arrival rate in the system
W = Average time a customer spend in the system
In context of an API it means:
L = Average number of concurrent requests system can serve
λ = Average arrival rate of requests in the system
W = Average latency of each request
Here are 11 posts I thought were worth sharing this week.
To Learn a New Language, Read Its Standard Library – Link
I like the idea of learning a new language by reading its standard library. You learn the idiomatic way of writing code in a language by reading source code written by its original authors. I am planning to learn Rust. I will also give this approach a try. There are two limiting factors when you might struggle with this approach 1) Poor documentation 2) when the standard library is implemented in a lower level language.
Scripting languages of the future – Link
Author of the post shares his views on important features he expects from a future scripting language. I agree with his list. I will add a couple more:
- Better tooling support. Author talked about IDE but I think tools for formatting, packaging, scaffolding, new modules, etc should also be part of the language standard tooling.
- Simple. It should have one idiomatic way to do a task. Also, stability should be preferred over feature bloat.
Here are 8 posts I thought were worth sharing this week.
Being Nice and Effective – Link
In this post, Subbu Allamaraju shares his thoughts on how you can be both a nice and effective leader . He talks about six different leadership styles and how those leadership styles create positive and negative climates. I am in my first engineering leadership role and still figuring out my leadership style. Based on my limited leadership experience I think a leader can have multiple leadership styles depending on the situation. There are times you have to course correct and change your leadership style based on the situation and context. Also, I think leaders can be “nice” and “not nice” depending on the context. Leadership is hard.
42 things I learned from building a production database – Link
Not a deep technical post. Many useful pieces of advice by Mahesh Balakrishnan in this post. He worked on a Chubby like system at Facebook. My favorites:
- Be conservative on APIs and liberal with implementations
- When designing APIs, write code for one implementation; plan actively for the second implementation; and hope/pray that things will work for a third implementation.
- Anything that can’t be measured easily (e.g., consistency) is often forgotten; pay particular attention to attributes that are difficult to measure
- Make your project robust to re-orgs.
One of the advantages of Microservices architecture is that it enables components to have deployment independence. Based on my consulting and software development experience deployment independence is often overlooked and very few teams achieve it. Deployment independence is important since it brings true agility and reduces communication overhead between different teams and services.
Shared libraries make Microservices tightly coupled and introduce hard dependencies. Since, now a team making a change has to ensure that it does not break another service that depends on the shared library. This requires communication between multiple teams. Also, change in a shared library leads to all the services that depend on it to be redeployed. This leads to long build, release, and deployment times. We might have to consider the deployment order of services as well. All this leads to more synchronization and communication between teams. So, it is recommended that in Microservices architecture teams should avoid using shared libraries.Continue reading “When to use shared libraries in Microservices architecture”
Here are 10 posts I thought were worth sharing this week.
Who Is Driving the Great Resignation? – Link
It is hard to retain good talent in tech. I agree with the reasons on why employees are resigning in huge numbers. Shortage of good talent, better compensation, lack of purpose, burnout, career advancement are the reasons that I hear as well. One reason that I don’t see covered in the post is poor leadership skills. It might be implicit but I think it should be called out as well. Good leadership can provide a sense of belonging and purpose that can help retain good employees.Continue reading “Useful Stuff I Read This Week”
One of the common Web API design anti-patterns that I see in the field is the exposure of database model in the API contract. If you are building a Java Spring Boot JPA application then it means exposing JPA entities as Web API’s request and response objects. The primary reason this happens is because most teams are not following contract first model of API design. They start from code and database schema and then they create API contract from them.
This is not the first time I have seen this anti-pattern being applied by development teams. I have seen this often so I thought let me document it so that in future I can share this post. The advantages of document such lessons/patterns/practices are:
- I can be thorough in my explanation. Writing helps me understand if my point is valid. Writing is thinking for me.
- While explaining to a developer I might forget a key point.
- Give the development team time to reflect upon the feedback by themselves.
- Discussion after going over the post might be more productive.
- I can keep updating this post.
Following are the reasons that I think we should avoid exposing database model as an API contract.Continue reading “Web API Design Anti-Pattern: Exposing your database model”
Here are 7 posts I thought were worth sharing this week.
Google: A Collection Of Best Practices For Production Services – Link
This is an amazing read. Building resilient systems is hard. The first step to building resilient systems is to become aware of the practices that are used in the trenches. All the practices are worth reading/knowing and you should look for opportunities to apply them in your environment . Every few weeks I see teams struggling with making configuration changes safely. Article gives some practice advice on the same. Writing fail-safe and resilient HTTP clients is not easy. HTTP clients are used heavily in Microservices architecture. Most developers consider the happy path when service either succeeds or fails with expected response codes. But, we need to consider retries with jitter, timeouts, queueing, load shedding, etc while building HTTP clients. This article covers a few more practices that can help us build resilient systems.Continue reading “Useful Stuff I Read This Week”
Today while reading a tech newsletter I discovered xbar. xbar lets you put output from any script/program in your macOS menu bar. Xbar is built using Wails. Wails allows you to build desktop apps using Golang and Web technologies.
Xbar has a plugin based architecture. There are hundreds of pre-built plugins that help you view information about AWS, cryptocurrency, weather, date & time, and many others.
Continue reading “Playing with xbar: Showing WordPress Site Page Views In Menu Bar”