Level Up Your Ops Game: Unleashing the Power of Unified Observability In the ever-evolving landscape of cloud-native architectures and complex distributed systems, keeping a watchful eye on your infrastructure and applications is no longer a "nice-to-have," but a mission-critical imperative. We're talking about observability – not just monitoring, but true, deep, insightful observability. But let's face it: traditional monitoring approaches are like trying to understand the ocean with only a weather report from the beach. They give you a limited, surface-level view. That's where Unified Observability swoops in to save the day (and your sanity!). Why the Hype? Because Complexity is the New Normal. Modern applications are behemoths. They're spread across multiple microservices, databases, message queues, and cloud providers. Pinpointing the root cause of an issue can feel like finding a needle in a haystack. Traditional monitoring tools often create silos o...

So the story goes like this: You have container workloads running in production (nomad). You are on a bare metal environment. Multiple container networking software solutions are in use in different data-centers - contiv and flannel. The perimeter is secured for the cluster (firewalls, WAF). Service to service communication within the cluster is non-secure (the journey started before service mesh concepts was in place). Customer insists that service to service communication is over https within the cluster when it crosses machine boundaries within the perimeter too. Incremental approach for migration service by service is mandatory. Options Introduce a full-fledged service mesh A complete networking and software stack upgrade is impossible without a downtime. Replace the existing container networking with one that supports encryption Do we have one such solution which is usable in production? Solution “Introduce a light weight sidecar proxy that can do this job” Details Nginx as a side...

Atheism, a term often misunderstood, simply denotes the absence of belief in deities. For me, this concept unfolded gradually, shaped by a unique tapestry of experiences and influences. Growing up Hindu in Kerala, I was immersed in a world where faith was often intertwined with tradition. My father, a seeker of deeper meaning, explored the intricacies of Hinduism beyond ritual. Conversely, my mother, a woman of immense strength, approached life with pragmatic realism, her religious practices more a matter of family custom than fervent belief. Kerala's diverse religious landscape fostered an environment of tolerance and acceptance. My closest friends throughout life have been Muslim, Christian, and even fellow atheists. These bonds, forged across religious lines, deepened my understanding of humanity and challenged any preconceived notions. It wasn't until I returned to Bangalore in 2013 that my spiritual journey took a decisive turn. Living amidst a community deeply rooted in P...

These are a set of guidelines that helps everyone to play nice and fair while communicating especially on mediums like Slack, Teams or Mattermost be it at your workplace or other online communities. Remember, while we are communicating over these mediums, neither our body language nor our voice is heard by other individuals who are reading our messages. This requires us to put in an effort while writing replies or initiating new conversations. Direct vs Indirect Messages Always try to avoid direct usage of english. They might find your directness rude and possibly offensive. By adjusting your tone, you are more likely to get a positive response from your reader. Consider these: Direct – You are doing it wrong. Indirect and polite – The way it is being done might not be the right way. Do you mind checking it once? Direct – You are using a non standard practice. You need to follow the steps as documented. Indirect – I’m afraid that what is being followed might not be the standard practic...

Why is that many leaders still don’t get what is story point based estimation? An attempt to explain the basics. What Are Story Points? Story point is a relative value of the size of a story in comparison with another story. For a team we can have multiple such base stories to ease estimation as every team member might not be aware of every type of work. The absolute values we assign are unimportant and what matters is only the relative values. What Values To Use For Story Points? In practice, we can use the fibonacci series (pronounced as fibi-no-chi), which takes these values - 0, 1, 2, 3, 5, 8, 13 What If The Story Point is Higher Than 13? That indicates that the story is actually too big to be handled as a single item. Discuss and work with the product owner and split into multiple stories as functional slices. Do not split into pieces like "Write Code" and "Testing" as two different stories. That introduces waterfall into Scrum. Who Does Story Point Estimates? ...

Many times we get greeted by just Hi or Hey messages from our colleagues and friends in our various messaging systems. Be it Slack, Mattermost, Teams, Hangouts or whatever messaging systems that you use. This is one of the most irritating (sorry to use that word, couldn’t find a subtle one), messages that you can ever receive. Messaging systems are meant for asynchronous messages. Expecting that the person at the other end of the conversation is always available to answer the hi/hey messages is too much of an expectation. Remember messaging someone is NOT like making a phone call. You cannot expect an immediate response there. Follow these simple etiquettes next time you message your friend or colleague. Write the complete content that you are planning to ask the person in a single message (as much as possible) May be you can start with a Hi, but make sure it is a multi-line message with the actual content. There is nothing more irritating than receiving 10 notifications in the mobile ...

I am not the original author of this post’s contents. I recently found this email reply from John Mitchell while discussing the testing aspects of micro services in our project. It is so informative that I didn't want this to get lost in emails. Adding this here. (Names have been changed to keep the focus on the topic under discussion) Hi PersonA, I think our discussions about the Quality Criteria were pretty clear… And to be even more precise, they must be able to be automatically run as part of the appropriate phases in the pipeline. APIs Message / file formats, etc. UI’s which they provide Telemetry which they generate for business/application/operation/etc. monitoring/alerting/tracking/etc. Martin’s slide that you point ed is no excuse to get out of any of the above. He’s pointing out, as I did, that false metrics such as “code coverage” percentages are misleading and inefficient ways to measure actual quality of the software (as opposed to trying to force the team to spend t...