When the power goes off in a device in a linux based system, one can think of ways in which this event can be handled in the applications running on it. One thing to note is that, when you plug the power cable off, the power doesn’t really go off immediately. But this needs to be notified to processes so that they can handle such an event and save the state of the application (if any). ...

While you might have read posts about docker being dead, but given its adoption. That’s not really the case. While we have other container runtimes like runc, containerd, rkt and some others. Docker is still something which a lot of folks running containers use as their container runtime. What this post will describe is one of the many approaches of structuring your container images, keeping in mind reusability, security and best practices in mind and keeping them as lightweight as possible. At the time of writing this, this is something which is still used to run production container workloads in my last company. ...

kubernetes has been around for some time now. At the time of writing this article, v1.14.0 is the latest release and with each new release, they have a bunch of new features. This post is about the initial setup for getting the kubernetes cluster up and running and assumes that you are already familiar with what kubernetes is and a rough idea on what the control plane components are and what do they do. I gave a talk on the same subject of self-hosting kubernetes in DevOpsDays India, 2018 ...

It was a cold Friday night, had just come back home after wrapping up the farewell party which was thrown by my colleagues from my last company. I was feeling worn out of all the activities from the day, but I kept reminding myself that I had to start packing for the impromptu solo backpacking trip which I had planned before I joined my next gig in the coming 10 days. ...

When do you say two objects are equal? Taking example of the below two and having ruby as the language, Comparing primitive objects irb(main):001:0> 1 == 1 => true irb(main):002:0> 'tasdik' == 'tasdik' => true irb(main):003:0> Comparing custom objects But what if you are having a custom class defined which has attributes for itself, you can’t really compare them using == default. For example. irb(main):001:0> module Money irb(main):002:1> class Wallet irb(main):003:2> attr_accessor :rupee, :paise irb(main):004:2> irb(main):005:2> def initialize(rupee: 0, paise: 0) irb(main):006:3> @rupee = rupee irb(main):007:3> @paise = paise irb(main):008:3> end irb(main):009:2> end irb(main):010:1> end => :initialize irb(main):011:0> irb(main):012:0> office_wallet = Money::Wallet.new => #<Money::Wallet:0x00007fb4328889c8 @rupee=0, @paise=0> irb(main):013:0> personal_wallet = Money::Wallet.new => #<Money::Wallet:0x00007fb430991290 @rupee=0, @paise=0> irb(main):014:0> irb(main):015:0> office_wallet == personal_wallet => false irb(main):016:0> But as we can see that the two objects have the same attributes, which would be rupee and paise having the same values. They should, logically be the same thing and they should have returned true as a result of the == comparison ...

First principles of testing stand for Fast Isolated/Independent Repeatable Self-validating thorough Bugs are introduced in the parts of code, which we usually don’t pay attention to, or places which are too hard to understand. Fast The developer shouldn’t hesitate to run the run the unit tests at any point of their development cycle, even if there are thousands of unit tests. They should run and show you the desired output in a matter of seconds ...

I have written about F.I.R.S.T principles of testing and TDD as a school of thought Probably an extreme opinion, but this is how Jeff Atwood puts it I Pity The Fool Who Doesn’t Write Unit Tests But what should you test? This I generally try to follow Test the common case of everything you can. This will tell you when that code breaks after you make some change (which is, in my opinion, the single greatest benefit of automated unit testing). Test the edge cases of a few unusually complex code that you think will probably have errors. Whenever you find a bug, write a test case to cover it before fixing it Add edge-case tests to less critical code whenever someone has time to kill. This will not only help you deliver and release faster, but will also make you more confident about your own codebase. ...

Software is eating the world, and so is the world of software development constantly changing. One way of developing a project would involve analysts figuring out the business requirements and sit for a few weeks if not months these requirements would be given out to the architects who would in case break the problem down into manageable chunks the chunks themselves would be then given out to the teams which would be the delivering the specific modules. Nothing, but a typical waterfall model scenario, coming with it’s obvious pros and cons. ...

Canary deployment pattern is very similar to Blue green deployments, where you are deploying a certain version of your application to a subset of your application servers. If everything is alright and you have tested out that everything is working fine, you route a certain percentage of your users to those application servers and gradually keep increasing the traffic till a full rollout is achieved. One of the many reasons to do this can be to test a certain feature out with a percentage of users who use your service. This can be further extended to enabling a service to users of a particular demographic. ...

A lot of great material has already been written out there around what microservices are and what they are not. What I would try putting down here is what I saw as we grew from a monolith to a microservices architecture over the period of time back here at Razorpay. Please take it with a grain of salt when you read this as this is going to be opinionated. Microservices are something which you grow into, not something you start with ...