Oh my left knee - You cause my problems!


Today morning it was just a normal day as always. We always have some balloons in our hall as my younger daughter likes to play it like a volleyball with me. I also enjoy entertaining her for some time.

So there were a few balloons in the hall and I casually like to kick it. As I kicked one off my right leg, my left leg kind of went out of balance and it twisted (as I have no cross ligaments anymore because of my MTB accident 2 years ago). It was such a shocking sensation and such an intense pain that I could not stand anymore and I fell down ferociously!

My wife and my elder daughter who were nearby came rushing hearing the sound of my fall and my cries against the pain. For the next 5 to 10 minutes I felt such a pounding sensation on my left leg! It felt as though I had a severe accident! This is pure agony! Nevertheless, I guess I need to fix my left knee with an artificial ligament. I will probably consider operating it the next year or probably this winter after the MTB season this year ends. Until then, I'm gearing up for the summer to be on my MTB!

GitOps - The way DevOps should have been


Some time around the summer of 2019, I came across a blog post where I read about GitOps and I was flattened by the idea itself and ever since I wanted to give it a try on some serious projects but never had the chance to do it professionally. I had a chat about this with many of my colleagues at work and my team and they seemed ro like the idea but were a bit reluctant to employ this concept in their projects. In this blog post I will attempt to explain what GitOps is all about and will probably give a reference to one of my private projects which I made GitOps ready!

GitOps - As the name would say, use git for operations tasks. Simply put, you define your desired state of your infrastructure (let's limit ourselves to cloud native) and have this desired state pushed into your beloved git repos (BitBucket or GitLab or GitHub or whatever that supports Git version control). Then on the cloud side you will have your typical orchestrator (k8s or docker swarm) that will then wait for these changes that you make in the Git and once it sees the changes in your Git repo, it immediately pulls those changes and applies it on your production environment. It is as simple as that. This is exactly how k8s works. Isn't it. Just match the desired state on your production runtime.

Ok so now we know what GitOps is, let us see how it could be beneficial! We have been over the past couple of years talking about CI & CD pipelines, but I have seen from my experience that it is not CI & CD happening right after, but there is a huge gap between a CI and a CD. You know what I mean? You do CI more often than you do CD. So this would imply that you have to have perhaps additional tools to do CD work for your applications and more importantly the developer is no longer inchagre of the CD process. It is left to some infrastructure operator (that classical ops guy or the notoriously famous site reliability guy for your cloud).

Here are some of the really tangible benefits that GitOps (Pull-Based deployments) brings to projects:

1. Credential Management - How many times did you have to distribute your prod credentials into some other tool that is not your production environment? With GitOps, it is not going to be the case anymore. Your production credentials stays where it belongs - In your prod environment. This solves a very basic, but rather very very important aspect for an organization - The Security! Yep! No more prod credentials on your developers machines or on your developer tools!

2. Revert with confidence in case of problems - Since Git is versioning every bit of your repo, it makes reverting to an old desired state painless and effortless. It is as easy as saying git revert to any desired version or state you want your production to be.

Now if you want to ship code more often to your production, this would mean that you should have a solid code base - One that is having a very good code coverage (unit testing, integration testion, e2e tests etc.,). When you employ GitOps, you commit yourself to deploy code more often and this would implicitly mean that you have to make your code base rigid with every subsequent release. I see the following implicit benefits:

1. You will improve your code quality (Given the fear factor that you might break something in prod because of poor untested code when pushing more often to prod)

2. You will have confidence in your overall application landscape as you exactly know what's in Git is what is in your production.

From my point of view GitOps is the way to go towards automising CD and keeping CD close to CI.

I tried this on one of my projects (link here and here) where I ran a Minikube cluster with the Flux operator installed on my Minikube cluster. It damn works! GitOps is the way to go!

Back Propagation in Neural Networks


Once you understand Feed Forward mechanism which isn't much useful when you do not back propagate to update the weights and refine your Neural Network, your Neural Network isn't of much use. So in this blog post, let us understand what is back propagation and how could we represent the back propagation mathematically! Back propagation generally means that you distribute the errors to the hidden layers in a proportionate manner relative to how much the weights were contributing to the actual error in the subsequent layer. so the larger the weight, the more of the output error is carried back to the hidden layer.

As always, here is a sheet of paper where I have worked out the Math (Matrix representation). I have vectorised the back propagation mechanism!

Now you might wonder from where did I arrive at my Milestone matrix notation. If you expand on that WThidden_output you will find out that this weights matrix is just a Transpose of the original weights Matrix during the forward propagation phase. This is a big step in understanding the way we distribute the errors into the subsequent hidden layers of the Neural Networks.

The hidden_output in my sheet above in the simple 2 layer, 2 node network mean that my hidden layer is also the input layer. The reason why I decided to call it as hidden_output is for the fact that a typical Neural Network will not just have an input and an output layer, but also several hidden layers. So don't be confused with the hidden_output, well I could have as well called it input_output! But nevertheless, you get the message! Don't you?

Understanding Feed Forward Neural Network Architectures


I have been reading through the architectures of Neural Networks and wanted to grasp the idea behind calculating the weights in a Neural Network and as you can see in the image below is a simple 2 node 2 layer Neural Network.

As you can see that for simplicity sake, I have just used a 2 node 2 layer network, but the same holds true for any sized Neural Network. It's just that the size of the Matrix increases proportionally to the number of inputs! The concepts outlined in the image holds gold!