Category Archive : DevOps

The false security of Notifications

The Problem

On one of my recent projects, I just got added to a distribution list that receives alerts from vehicle-dashboard-lightsour monitoring system. first few days I tried to read some of those notifications, but then one day when I opened my email it was flooded with about 500 or so messages. Some of them were more of less the same message coming every few seconds/minutes. over the course of last few weeks, I get like 100+ messages every day and most of them when I am asleep.

The most interesting things that came to my notice are:

  • most of these alerts while are warnings, they don’t really bring any our services down anytime soon. some of these don’t even get actioned upon and they self recover.
  • the team actually actions upon a couple of these really; everything else is more of an info
  • inboxes get flooded during night when our core support team is sleeping and there is no way to know for the core support team if something is going to fail soon

it’s like jumping into my car and every time i see the dashboard every light in there is brightly lighted up – to the point that one day i stop caring. eventually, someday something will fail – i just hope it’s not the day when I am driving to someplace in an emergency

The Symptom

when I reached out to the team and articulated the issue i have with out notification strategy, the prompt response I received was to create a new DL, which i believe will be the goto list where all notifications go. Yes, i will be receiving lesser emails and maybe none. And it solves for nothing.

This is just a big symptom if you see in your organization you should think if the team in on top of knowing when something is really gonna fail. Or are you relying on a system that sends everything it sees wrong as a notification and let’s a bunch of humans decide what to act upon or maybe not. also, you cant avoid the fact that many of these notifications are going over an channel that has no way to “push” notify a user of an issue.

Think of a car dashboard with all these light sitting no in front of a driver, but in the glove box. someone would have to open the glove box to see if a light is on or not. the light maybe on for hours before someone realizes something’s gone missing.

The Solution

I don’t have a technical solution in place for my project, but something I am going to speak to my team about, but the analogy that I will leave you all with is that think of what a notification/alerting system should be like?

  • Have you car’s dashboard light up with a warn Green telling something has happened (like an indicator has been switched on and it’s blinking)
    • Green and soft clicking sounds – eventually a driver will see and will turn it off (was the case with cars in 1990s with low or no sensitivity indicators). but you don’t want to alarm the driver – it’s not detrimental
  • Have car’s dashboard light up in Yellow like a warning. I have my car light up a fuel warning as soon as the levels are dangerously low. I can still drive 80-100 KMS based on how i drive but it’s more than enough for me to eventually see it and get to a refueling station
  • Have car’s dashboard flash a Bridge RED – like Doors open. Well, you wont want to drive your cars with doors/hood open. hence a bridge red sometimes accompanied with a few sounds.
  • Or have a Sound beep every few seconds – i like how my car alerts me every few seconds when i dont have my seat belt on. Or when I drive over 120KMPH. It’s like reminding me every 10 seconds that I have something fatal going wrong and i can die from it


How will this translate for me and my project team is something i don’t know yet. But, as we go about fixing this, I will post if here. What have you done to address your strategy or is it still all dashboard lights flashing all the time?



Make Sense out of your Stack Traces

I recently came across this cool tool which allows you to make so much sense out of your stack traces. Once I have locked on a stack I want to look at, this tool makes it so much easier.

You can also read about it on their blog post –

Don’t Like Throttling?

You don’t have a choice – the underlying system (The JVM here will do it for you).

I still recall the summer of 2013 when I was running a project and it was 1 URL in my whole of application that brought the servers down. The problem was simple – a bot decided to index our site at a very high rate and the bot was creating a millions of URL combinations which bypassed all of my caching layer and they were all hitting my application servers. Well we had a very high cache rate in the application (95%) or so and the application server layer was not designed for a high load (it was Adobe AEM 5.6 and the logic to do searches and make pages was very computational heavy). Earlier that year we wanted to handle the case of Dog-Pile effect and we had spoken about having some sort of throttling in place. At the start of the conversation every one frowned about the idea of throttling the same (except 2 people).

In fall of 2012 Ravi Pal had suggested to have error handling in place such that a system should not just fall on it’s head but degrade gracefully. I only realized the gravity of his suggesting when we hit this problem in 2013.

Now I am here working on yet another platform and the minute I bring up the idea of throttling, it’s being frowned upon again. One guy actually laughed at me in a meeting. One other person suggested that we want to handle the scenario by “Auto-scale” instead of throttling the same. We have our infrastructure on AWS Cloud and I am not expert but the experts tell me a server can be replicated as-is in around 10 minutes (we will be proving benchmarking this out very soon).

I was an ambitious architect who though I controlled the traffic coming to my site. I no longer live in that illusion.

This may be a series of posts, but today here I start off with showcasing that you do not have a choice and whether you like it not, the system will throttle your traffic for you.

The Benchmark Overview

  • A simple Web application built using Spring Boot
  • A Spring MVC REST controller that will accept some HTTP Requests and send back a OK response after a induced delay
  • jMeter to simulate a load
  • custom plugin (a big shoutout to these guys for the plugin) to generate stepped load and capture custom enhanced graphs
  • Tomcat 8.x to host the web site – launched in memory using Spring Boot. No customizations done

First Groups – The Good One

Test Plan

This Thread Group is going to simulate a consistent stream of requests to our application server. A typical scenario that happens very often.

Throttling - thread group - the good one

Server Performance

As Expected? Yes.

As you see below, the chart shows that the application server is behaving normally. All the requests over a time period of 15 minutes is consistent with a “single user model” aka 1 second request response time.

throttle - the good one - TPS - Scenario 1

Second Group – The Sudden High Traffic

Test Plan

This test plan is a stepped approach and it’s trying to simulate a scenario where a campaign will start hitting a certain page (or set of pages) for a short duration. This is a use case we see most often in the industry where our websites are open to the whole world to hit.

this thread group is not OOTB and I downloaded a plugin

throttle - the high traffic one - test plan

Server Performance

So what do we expect to happen? Depending on how much juice my server has (threads, cpu cycles, etc.), my server may or may not be able to handle the requests. Given I am running everything on my local laptop, it will be interesting if my local box can handle 600 threads on .

throttle - the high traffic one - TPS - Scenario 1

And we see that my laptop cant really handle 600 thread. So what does tomcat do?

It Throttles

How the Good One changes behave

Test Plan

I run the 1st test plan and follow it up with the high traffic plan (introducing a 30 second delay).


The following image shows how the Good One has been impacted. While the traffic for The Good One has not changed a bit, it has still been impacted because something else introduced a spike.

Please go and tell the JVM that you do not like throttling

throttle - the good one - TPS - Scenario 2

So What’s Next

You have really 3 choices (we will look into details of each of the following in separate posts)

  1. Auto-scale the application servers and hope that the new servers are ready in time to handle the load or;
  2. Do something about throttling and control your destiny – what if the high traffic is not a revenue generation resource and the Good One was?
  3. Continue to frown upon Throttling

High availability design

If you have ever travelled in an Indian Railways you would have noticed that the capacity for which the train is supposed is handle holds no meaning because the number of people it will be carrying is just going to be way over. That’s how the passenger load and platforms all across the country are managed. The method mostly works fine, but from time to time there are breakdown and trains are delayed, sometime cancelled but the life goes on as people expect that this will happen with Indian Railways. 

When we design and write those big platforms/software something similar happens but the biggest difference is that customers/clients who have paid for the software don’t like those downtimes (cancellations) and slowness (delays). Last 2 years or so I have had so many conversations where 2 key NFRs intersect – Performance and Availability. I have noticed and started to realize that while these two end up being joint at the hip and need to work closely together they still mean a world of difference and what it means when we speak about performance and availability and each of these need to be addressed differently. 

Of course, eventually with all many fixes you will eradicate a lot of cases that led to failures but it would have taken you so long and the reputation that the brand holds do dear is already damaged.


The Start 

Most project (almost all) in today’s world have some Non Functional Requirements and the 3 that take the top most priority are Performance, Availability and Security. Some numbers that get most often thrown around are:

  • Pages should open in under 1 second and so forth
  • There should be an uptime of 99.99% – which is actually 1.01 minutes per week 

And that’s about it. Of course there are more, but 95% of the conversations revolve around the two here. then we go about designing solutions to meet those numbers. 


Just before GO Live

Things are al good when we are under implementation and we do everything to make sure we meet those 2 or so numbers met with out design. We do performance modeling and then we execute those performance models and prove out that the trafic model/simulation as to what we understand as client use cases work fine. So that is not we say with confidence that our system will meet the performance needs. In this model, we do take a capacity increase of 40% or so; again based on anayltic and some future growth and we incubate those numbers into our calculations and then we are even sure that our system will be able to handle a bit more if that happens at times. 

Now that we are so sure that performance is all good for the traffic we expect to get we believe that our software should continue to work fine because everything will work in the same constraints in which we have tested it. And because those constraints are well defined there should really be no problem with us meeting our availability numbers. 


We are in flight Houston

Then the next cool thing happens – we go live and our system that we have build with so much pride and caution and we have tested so much is Live and so many people start to use it. It certainly is an exhilarating feeling seeing your sweat and hard work go live and people are seeing and interacting with what you have build. 

Until a time comes when the system goes down. You would be sleeping in middle of the night and you will get a call and someone will be telling you to get up, switch on your laptop and get ready to debug as to why the system went down and get it up and running quick. It takes you a while to think – what the hell just happened. We did everything we had to do. There were even reviews that we did and everything was looking good. How can it go down.

Well there is something called Universe that has a different set of plans for you and those plans just went into motion.

So what happens?

Indian Railways happens 🙂 You realize that there is a traffic pattern that has suddenly come and hit your servers which you did not know. A Chinese search engine has started to crawl all over your site and the site is not even in china. Well it’s a free ride this internet and anyone can get on. Why can some people sitting in a country not see a website that is not supposed to be targeted at them – but we did not have those specifications. We put in all checks but we never anticipated for all those search engines and bots and the crawling they will do. 

What do we do?

We fix the problem and put in either a block to stop that traffic pattern or we throttle it or we add servers to handle it. And then we go about thinking okay now i am good; this is done and dusted and wont happen again.

Universe has other plans

Next time someone will add some bad servers into WIP and cluster will fail. and the next time someone will delete the database and it will crash again and the next and the next and the next…

In the whole software development process we miss this key step – to design for this game and how we will be setup to get the system back up and running in that time frame. 


Fixing begins

Of course we have to do something but what we do is to start looking at our solution and check why performance is bad. Performance – really? We do everything we can do to fix the performance problem but we spend no time on availability aspect.

Going back to the India Railways analogy I drew upfront; a train – engine and bogeys are built to handle certain load and they was agreed. It cant be more precise as there are seats and there are tickets that need to be bought to get into that train. As long as the number of people that get in there are within those constraints our problems will be much less. Everything around our software (our train) needs to work in tandem. But, it is difficult to control. Internet is much more wider than an Indian Railways and who comes, when they come and how many come is just not predictable. It becomes important to acknowledge that no matter how you do there will always be a model of traffic that will come and visit you that will take your system outside of the known boundaries and more often than not once our system is operating outside of those boundaries it’s bound to fail some point. This is where the Availability and Resilience perspectives need to be brought into the picture. 


Next Time do something else too

Availability and Resilience

At their core this perspective asks you to set some designs, practice and most importantly an expectation with your clients as to what you are dealing with. We all know that in the last decade how we run our business and how we deal with internet hosted sites is very different than how we used to make systems in past. I paraphrase from article – “If your site is down, your business will suffer” and yet everyone will want a 24×7 uptime but yet we sold what NFRs – 99.99 (1.06 minutes) or maybe 99.9999 (0.605 seconds) thinking it’s okay. If the expectation is 24×7 why would we even start with something less?

We then need to look at the next 2 most important metrics which we miss all along and we never plan, design or test for. It’s like we take them for granted. It’s the Recovery Time Objective (RTO) and RPO (Recovery Point Objective). As we speak about uptime and outages, whenever we have an unplanned outage and we have promised a certain uptime, we need to have the Operational Ability to be do whatever is needed to get the system up and running. If we designed for 99.99% we need to have methods in place to get system back in 1.06 seconds – it feels like Minute to Win It. In the whole software development process we miss this key step – to design for this game and how we will be setup to get the system back up and running in that time frame. 

The Operational ViewPoint

Operation Viewpoint is a key architectural principle that we omit to design for when we are building software systems and platform. How we run software now has been completely changed in the last decade with the cloud hosting. As cloud makes things so easy to provision and host (AWS) we believe that everything should be easy. So where in the past when we used to focus on Availability design a lot more we almost take it for granted. This Viewpoint is something that should become our bread ad butter during the implementation phase with a dedicated team who is going to look at operational processes and tools and provide methods to make the recovery possible in the time it’s expected to be. 

Categorize and Prioritize

This is where it becomes critical to have a conversation with out clients and understand how various parts of the systems can be identified and broken down into services. A classification of sorts like “Platinum”, “Gold”, “Bronze” starts to make sense to get the business to prioritize as to what services should get the top most priority incase of an unplanned outage. The focus of the operational design and implementation team then needs to focus on how to look at the system and how to make those services up and running quickly. This is a key inputs for the implementation phase because unless those services are not known there won’t be a way those services are coded such. 

Recover and not debug

When these unplanned outages happen, the team which is responsible for managing the system more often than not start with a different mind set. They are like Cops who have reached a crime scene after a crime has happened. They start by looking around for evidence and analyze the crime scene as to what happened. The idea is to look for evidence and then solve the crime and hopefully then find the criminal and put them behind bars. Well we all know it takes so long to get there. With cops, i can see the point – you can’t have cameras in all the home and everywhere, so you will have do post-mortems. But this is a software system and we need to be fire fighters. The idea has to be to put the fire out and do it quickly before it takes the block away. The idea has to be to realize some damage has been done – thats a lost cause; let’s see how we can save what’s left of it. 

In softwares that we write and platforms that we host we need to have a something I refer to as “Last know good state” and when an outage happens what we need to do it so just ourselves back to that state. But, when do we do when the state or behavior is not under your control. Going to back to Indian Railways, what do you do when you can’t control the number of people who are coming in on the platform and onto your train – they just keep coming in; no matter if you find a way to replace the train, they will keep coming in. The other way is to of course start adding more trains on the platform. With cloud you can do that and keep adding servers until all the traffic is dealt with. This is where we move seamlessly into Performance and Scalability perspective

This is where we lose sight of the problem and we try to fix something else in modern software.

 So what should do if we can not control traffic. We need an effective mechanism on our train that wont allow everyone to get in. We need to have the ability to know who can get in. We have these ID cards and Turnstil on platform. So if our platforms do not give us those why can we not put those in in our trains. It may not stop all malicious traffic, but it will certainly stop a lot of it. Most importantly you can go back and authorize your Platinum users to get in while you block everyone else.

So in software world, you need to have a cutover switch that will stop all traffic and only allow what is key for business. Unless everything that is coming in is Platinum which is not the case most times, you will be able to recover your most important services easy. Of course there is a degradation of other services but that is something you would already set expectations with your clients and the business. They will be mad but less mad. 

The 300

If you have not seen 300, you have got to see this and learn what it can do to your systems and ability to recover if you handle your enemy (the traffic) though a funnel. You will longer and you will get a lot more time to fight the enemy. On top of it, the pressure and stress that the business creates when their platinum services are not available will also be reduced. You can then go about debugging once you have contained. 


Nothing is for Free

Of course we do so much more, but the more we do the more it will cost. Back to indian railways, we can either chose to save some money on building my train by not installing those ID cards turnstiles or we can invest that money and ensure we have continuity. The Turnstiles will be more and more complex and will need a lot more fine tuning to handle all scenarios. So if you need to also handle for use cases where you don’t want your turnstile to fail, then you need to install 2 of them on all bogeys which will cost more and the setup goes on. 

The point I am trying to make is that when we go from 99% to 99.99% to 99.999% we dont look at the cost drivers and what it will do to the project. We may think – it would mean a few more rounds of performance testing and we should done. We we know now what’s going to happen. 

If you fail to articulate to the clients what these numbers will mean to them in terms of cost, you wont ever get them accept the reality of internet and the universe. More often than not you will realize how business will realize that there are services they can live without. Of course, eventually with all many fixes you will eradicate a lot of cases that led to failures but it would have taken you so long and the reputation that the brand holds do dear is already damaged. If you think of this as “risk money” and how you invest in guard your reputation will justify the cost every time – that much i can assure you.

Quality has new meaning – it is shit

I do not find that title implied to me; but see it almost everyday being implied to others.

This is in a continuation to a post a while back. In that post, I talked about a project team and their view point on quality. Here is an addition to the same set of people. The conversation goes like

Project Manager: I was just checking on the defect count and noticed we have 24 open P1 and P2 in system. How are we are going to go live tomorrow. What just happened?

QA Manager 1: Nothing, it is just that my team currently does not have any work for Release 2. They had some time on their hands and hence pro-actively they started to test in R1 and logged these defects.

Project Manager 1: so what are you going to do?

QA Manager 1: Nothing, these are not R1 defects. Testing is closed. We wrapped that last week and all these have tobe logged in R2. These are not R1 defects.

Everyone else in the room which included Analyst, and Project Managers laughed about it and joked that this is funny and defects have to go away.

This was the last point of discussion in the meeting and I was shell shocked to say anything. Not that it would have mattered to these guys. I am responsible for the delivery of a different project and not the modules they were talking about. So, amongst all politics and shock I did not say anything. But, I was thinking what happened to quality here.

One of them was the QA Manager, who is responsible for quality of the project and she said “Testing is closed”. How would we feel if Toyota or Honda or any car manufacturer would say that decide to fix problems in the next batch or version of the car.

And what amuses me is that these discussions reach people who are Director IT and Vice President IT and they are in agreement of the fact that “Testing is closed”


Who the hell needs Quality?

I Do; you do; our customers do; Period

Well we all know the answer, but is it really what we believe in? The more important question is how do we choose to deliver quality when we can not measure it?

A few months back, I was sitting in a meeting where the conversation went something like

Business Person: So we need 24000 hours to deliver the scope of the release?

IT Person: Yes. But this does not include the hours needed to fix defects that we will have in the application at the end of development lifecycle.

Business Person: So how many defects we had in last release – I assume about 700?

IT Person: Yeah.

Business Person: So I can expect 2000 in this release? How much time do you need to fix one defect?

IT Person: About 16 hours per defect

I will let you do the math, but what made me fell out of my chair was the fact that everyone in the room was accepting the fact that even before we were developing the application we would have 66% of the time spent in fixing defects. Not even once did anyone asked, how can we ensure that we do not have so many defects in the application. Now even once did anyone asked if we already have Unit testing how come we still have these many number of defects.

Well, this is not the first time I heard this conversation and I am sure not the last time. But, I wonder how do people reach Architects, Project Managers, Program Managers and Directors IT if they have these discussions.

I did not say anything in the meeting, because I was supposed to sit there and listen which is another sad story. I could not even say anything to my IT team once the meeting was over; I was just not supposed to. Maybe, if someone who was in that meeting reads this and can co-relate I would be in a big shit of trouble; but I am going to risk it – do not know why.

I am someone who can not start writing a piece of code without having a unit test before it (Test Driven Development). But, then the projects I have been working lately do not even automated unit testing let along TDD. Their unit testing is done because they have to compliant with the Quality Process and at times it is done with a set of people who never coded it. The unit testing team works like a QA team but is withing the realms of the development team itself. And then there are times when Unit testing happens in parallel to System Testing.

This is a rant, where I hope I can pass a message around importance of testing.


Dilbert - Quality

Dilbert - Quality









Related Articles