Author: shekhargulati

When to use shared libraries in Microservices architecture

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”

Useful Stuff I Read This Week

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”

Web API Design Anti-Pattern: Exposing your database model

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”

Useful Stuff I Read This Week

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”

Playing with xbar: Showing WordPress Site Page Views In Menu Bar

Today while reading a tech newsletter I discovered xbar. xbar[1] lets you put output from any script/program in your macOS menu bar. Xbar is built using Wails. Wails[2] 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”

Useful Stuff I Read This Week

Here are 9 posts I thought were worth sharing this week:

Talk: A History of Clojure – Link

Amazing talk by Rich Hickey on the History of Clojure. In this video, Rich covers how he took a two year self-funded sabbatical to build the first version of Clojure. Clojure is a dialect of Lisp, the second-oldest high-level programming language. Lisp is a functional programming language. He also covers challenges he faced to get the first customers, how he supported the community via email and IRC. I liked how he defined constraints for the languages and how he looked for practical answers to the real world questions related to performance. I have played with Common Lisp for a month or so while reading SICP. I will try Clojure soon as well.

Tips for High Availability – Link

This is a post from Netflix engineering team where they talked about how their CD practices enable high availability. Honestly, I was expecting to read more about system design stuff. Still, I enjoyed this post. They talked about things like blue/green deployment, deployment windows,canary testing, rollbacks, and few others. If you are into DevOps space for long you might already know most of them. I think the key about these practices is not knowing them but actually applying them at your scale. You really need a solid engineering culture to practice them. 

Continue reading “Useful Stuff I Read This Week”

Architecturally Significant Decisions

Once again, I stumbled upon the documenting architecture decisions post[1] by Michael Nygard. This time, a particular line from his post got me thinking and made me dig a little deeper into the subject. The line said, “ ‘architecturally significant’ decisions [are] those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques.” The reason this piece of statement is important is because most of the time architects are not clear about what they should document. 

The author suggests that we must document architecturally significant decisions. He divides them into five categories. In the post, he does not give examples against those categories, so, I am taking the liberty to add mine. 

Below is my interpretation of these categories. It could be different from the author’s intent. 

Continue reading “Architecturally Significant Decisions”

Useful Stuff I Read This Week

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.

Continue reading “Useful Stuff I Read This Week”