SDC#4 - This Pattern Saves a Gazillion Hours
SDC#4 - This Pattern Saves a Gazillion Hours
Stupidity & Learning + Time Management Problem
“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.
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.