Generating Microservices Boilerplate with CookieCutter

This week at the office we started work on a big enterprise project. We decided to go with Microservices architecture for the following reasons:

  • We are working on a business domain composed of multiple subdomains
  • The application needs to scale to twice the current load. They already have an application built using legacy technologies. We have to modernize the technology stack along with scaling to twice the current load.
  • Since this is a big project we will have multiple teams working on it. Microservices architecture is well suited for a large and growing engineering team.
  • Help the organization become API first. All the business APIs will be exposed using an enterprise gateway that third parties can integrate with.
Continue reading “Generating Microservices Boilerplate with CookieCutter”

Why do we write foolish LinkedIn profile headlines?

All of us or at least those, who use their LinkedIn account are quite used to seeing profile headlines like “Investor, Thought Leader, Digital Transformation Agent, Keynote Speaker, Builder” or “Keynote Speaker, Author, Writer, Builder” or people in the Agile world, who put out to the world all their hard-earned certificates. There are so many examples like these. People seem to be creative in coming up with such bloated, larger than life headlines.

We cover our vulnerabilities and insecurities by believing in a fake image that we build for ourselves. In the age of social media and instant gratification, we fall in a loop where we constantly want to show off that we are doing something new and evolving. We don’t want to accept that we are just like other people. We want to show that we are different. We are in a different league. 

I am also guilty of doing this 8 years back when I was a technology evangelist. As far as I remember my headline used to be “Technology Evangelist | Speaker | Writer | Traveller,” something in those lines. I wanted to show off and tell the world that I have done so many things. 

I soon realized that I am playing a status game. I am driven by constant validation and there is so much pressure I am putting on myself to be first in the race where I am the only runner.  

All status games are zero sum. 

Zero-sum is a situation in game theory in which one person’s gain is equivalent to another’s loss, so the net change in wealth or benefit is zero. 

Today, while discussing this topic with a friend, I realized that we do this because most of us have not achieved much or have not accomplished a larger body of work that we can be proud of. There is so much pressure to be successful for whatever definition of success we have defined for ourselves. We cover this fear or call it insecurity by posting our larger than life image. Deep inside we know that we lack creativity and there is nothing that will outlive us.

Why OpenShift?

Last week I was writing down why enterprises should use OpenShift as the foundation for building their enterprise platform and I wrote down following points.

  1. When building an internal Microservices platform for an organization Kubernetes is just the foundation you need many more tools and workflows to build a platform. OpenShift is a Kubernetes superset combining over 200 open source projects into a fully integrated solution with strong focus on a developer experience, operational capabilities, monitoring, and management with strong and secure defaults. Some of the open source projects include Istio, Argo, Prometheus, Jaeger, ELK, Keycloak,etc. OpenShift is support Kubernetes along many other supported components.
  2. OpenShift is secure by default.
    1. CoreOS container Operating System. Reduce surface area for attacks.
    2. Project RBAC
    3. Hardened images
    4. You can define upgrade windows and schedule them
  3. OpenShift is certified with over 200+ ISVs. These include Finacle, CloudEra, MongoDB, SAS Viya, and many other.
  4. OpenShift is available as managed cloud offering on all the three clouds – Red Hat OpenShift for AWS, Azure Red Hat OpenShift, Red Hat OpenShift Container Platform on GCP.
  5. Allows you to manage multiple clusters through a single pane of glass

Minimal Technical Documentation Every Project Should Have

In the last few months I have given a lot of thought on the minimal technical documentation that all projects should have. I consider it essential to building a quick understanding of the project and quickly onboard new developers. These documents should be maintained in the version control just like the code. The technical documentation should sit in the same version control repository as your code. 

If your system is built using Microservices architecture and you use repo per service approach then it will be better to have one repository only for documentation. I prefer monorepo over repo per service. You can read more about Monorepo in a blog post I wrote earlier.

The documents that I consider essential are:

  1. README.md
  2. architecture.md
  3. api.md
Continue reading “Minimal Technical Documentation Every Project Should Have”

Software Architecture Document Template

Below is the template that I use to document software architecture. This is based on the experience I gained doing architecture and design work over the years.

If you prefer Google Docs then you can create a copy of the template. If you prefer Markdown version then you get it from the Github repository.

Continue reading “Software Architecture Document Template”

My Notes on the “A Philosophy of Software Design” Book

This week I finished reading A Philosophy of Software Design book by John Ousterhout. I found the book easy to read and moderately thought provoking. 

The book talks about two approaches to reduce complexity of software systems – 1) embracing simplicity 2) embracing modular design. 

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

We know  we are working with a complex software system when:

Continue reading “My Notes on the “A Philosophy of Software Design” Book”

Questions to ask when making Build versus Buy decision

Most software companies have to make decisions on whether to build a custom software or buy it from a vendor. Some of these decisions are mentioned below.

  • Should we build the recruitment tracking system or buy it?
  • Should we build a custom video KYC solution or buy an existing one?
  • Should we build a custom CRM or buy it?
  • Should we build a custom CMS or buy it?
  • Should we run your own CI server or use a cloud service like CircleCI?
  • Should we build our search engine using Solr or Elastic search  or use a service like Algolia?
Continue reading “Questions to ask when making Build versus Buy decision”

Questions To Ask When Choosing a Programming Language

This week I had a discussion with one of my friends on how to choose a programming language. It was triggered by multiple discussions I had with our customers on their engineering strategy in the last six months and one question that came multiple times was should we use X programming language for our new initiatives. Some customers were thinking of moving from .NET stack to Java, some banks were thinking about moving to Golang because their technical leaders have watched Monzo talks on Golang, for some it was from Java to Kotlin, and some were thinking of dumping JavaScript for Typescript.

To come up with the answer I try to find answers to following questions in context of the organization:

Continue reading “Questions To Ask When Choosing a Programming Language”

Being Chief Technology Officer: Lessons learned in my first year

Happy New Year!

2020 was a difficult year for most of us, as we fought with COVID-19 and came to terms with the remote way of working. It was a year when we had a lot more time in our hands as all of us were locked in our houses with almost no travel. The things that we took for granted were taken from us and there was a constant fear of losing the loved ones. 

I hope in 2021 we regain our freedom to live freely. But, this time with a sense of responsibility and awareness. 

It is now little over a year since I became Chief Technology Officer (CTO) in my current organization. And, I thought it will be a good time to do a quick retrospective on the lessons learned in my first year as CTO. The journey has been tough but deeply rewarding for me. There were occasions when I thought the leadership role was not for me and I should go back to being an individual contributor. But, with support from my organization and learning (books, blogs, observation), I have started to enjoy the role and its challenges.

Before I talk about the lessons I learned, let’s look at my software engineering journey.  

Continue reading “Being Chief Technology Officer: Lessons learned in my first year”

My Notes on Deep Work Book

I decided to spend year-end holiday time reading a couple of books. I like to read books that in some way help me solve problems that I face in professional and personal life. At work because of my title and circumstances I have to play three different roles – maker, manager, multiplier. 

  • Maker: Create stuff (software, powerpoint, design document, etc).
  • Manager: Talk to people about their concerns and hopefully resolve them or at least guide them in the direction that takes them on the resolution path. Keep the stuff moving.
  • Multiplier. Enabling people by helping them in software design, code reviews, estimates, hiring right people, etc.

I am fortunate that I get to work on many tasks that are cognitively demanding. At the same time, I also have to work on tasks that don’t demand such cognitive skills.

Continue reading “My Notes on Deep Work Book”