PC#7 - This Pattern Saves a Gazillion Hours

“The 37 Services must support HTTPS…by next week”

This was the mandate from the org security team.

More than the need for HTTPS, it was the timeline that made things tricky.

We just had 3-4 working days to pull it off.

To make matters worse, many of those services were part of other important releases within the next few days and user testing was in full swing.

We just didn’t want to touch those services and risk creating issues that could jeopardize the other releases.

This is where the team decided to go for the Sidecar Pattern.

So - what is the Sidecar Pattern?

In this pattern, you divide application responsibilities into separate processes.

This lets you make changes to an individual process without impacting the other processes.

There are 2 containers in a bare-minimum Sidecar implementation:

• Application Container

• Sidecar Container

The Application Container has the core logic that serves the business requirement.

The Sidecar Container augments the Application Container.

But how do you implement it?

Sidecar containers are co-scheduled to the same machine by using a container group.

Example - Kubernetes Pod API.

This lets the App Container and Sidecar Container share resources such as:

• Parts of the filesystem

• Hostname & network

• Namespaces

Luckily, our services were already containerized and running on OpenShift (an enterprise-grade Kubernetes distribution)

So, we were able to add Sidecar containers to the Kubernetes pods pretty easily.

Here’s what the setup looked like:

The legacy service continued to serve exclusively on localhost.

However, we used an Nginx sidecar container to act as an SSL proxy.

The Nginx container lived in the same network namespace as the legacy service.

Therefore, it can access the legacy service running on localhost. Also, it can terminate the HTTPS traffic arriving on the external IP address of the pod.

Basically, by leveraging the Sidecar Pattern, we were able to shift the services to HTTPS within the mandated timeline.

The advantage of the Sidecar Pattern increases as the scale of the required change goes up.

For us, it was a matter of 37 services and limited time. Imagine doing this for 100s of services or even more in the case of org-wide migration projects.

Managing Configurations with Sidecar

At this point, you might wonder - is that the only use of Sidecar?

Not really!

You can use the Sidecar Pattern whenever you want to share some resource between two containers and you want to avoid changes to the main container application.

For example - managing configurations dynamically.

Most applications use some sort of config file (XML, JSON, YAML) for parameterizing the application.

Usually, applications have been written to find the config file on the file system.

But that's not how modern cloud environments work.

They use a central config server.

So, how do you support a central config server for legacy apps without modifying them?

Sidecar Pattern can help.

You set up 2 containers:

• App Container

• Config Management Container

Both share a directory between themselves.

This directory maintains the config file.

When the config manager starts, it performs a few steps:

• checks the config server in the cloud for changes

• downloads the configuration to the shared config file

• signals the legacy app to reconfigure itself

All of this without changing the legacy app.

So, to conclude things, when should you go for something like the Sidecar Pattern?

Say you get a requirement to add a feature to your existing app at scale.

In other words, multiple services or deployments.

Go for Sidecar if you can put the requirement into a separate process that can run alongside your main container.

In case you are looking for a sample implementation, here’s an article on my blog that walks you through the exact steps:

Stupidity and Learning

Why do we feel stupid whenever we are trying to learn something new?

Like a new framework or a programming language with a totally different approach. The more different a thing is from our normal worldview, the more stupid we tend to feel while studying it.

And this feeling puts off a lot of people and they stop learning that difficult thing.

However, you should embrace that feeling of stupidity.

In my experience, feeling stupid means your brain is working hard to catch up to the new concept or difficult thing that you’re trying to learn.

It's a sign that you're getting smarter.

You are at the edge of your current knowledge level and are trying to leap ahead into new territory.

It’s also the time when you are most alert to your shortcomings.

This means your chances of improvement and unlocking a higher level are the highest.

So, my advice is to continue through this phase and you’ll find yourself enlightened.

Do you have a Time Management Problem?

No, you don’t have a time management problem unless you are running the country or something like that.

For normal developers, time management problem occurs due to our obsession with winning the approval of bosses or colleagues.

Have you found yourself doing any of the below?

• Answering every email as soon as it lands in your mailbox

• Taking every call even when you’re busy with important work

• Handling every new request even when you’ve enough work for the day.

If that’s the case, you are most likely suffering from people-pleasing behavior.

And it’s only holding you back from your best contribution.

That’s it for today!

Have a great weekend and see you next week.

In case you want me to cover any specific topics in future editions, please fill out this form to suggest ideas.