Posts By :

    Rajesh Chande

    web push notification

    How adgebra uses web push notification as native advertising inventory

    538 310 Rajesh Chande

    A constant requirement of innovative inventory has become the need of an hour for any native adtech company. Publisher acquisition team is continuously under pressure from sales and delivery departments to increase the ad inventory supply simultaneously improve on quality. Increasing inventory vertically by signing huge MGs with publishers is not a viable solution where margins are always on fire.

    At Inuxu, the adgebra platform story is no different. Rohit (CEO) and Shashikant (Head of Inventory) were always at loggerheads for the very same reason.

    A part of the problem was solved when we launched a self-serve platform for long tail publishers. We started onboarding a lot of publishers and a new inventory supply was growing at a steady pace but the exponentiality and quality were not as expected.

    Rohit envisioned ‘Web Push Notification’ could be an interesting addition to native advertising. Push notification is a subscribed-only inventory and it displays on the user’s machine, promising 100% visibility. Such inventory quality would do wonders for advertisers on adgebra. Immediately the idea was discussed internally with me (Rajesh – CTO).

    India’s largest Web Notification tech company is iZooto and coincidently Neel the Cofounder of iZooto got in touch with Rohit via LinkedIn and conversation of cross leveraging each other’s needs and strengths started. However, it was not as simple as it sounds and the whole challenge of making this merger work came to me, my tech team, and the tech team at iZooto.

    What is web push Notification and how it started: A push notification is a message that is “pushed” from a backend server or application to user interface, e.g. (But not limited to) mobile applications and desktop applications. Apple was the first to introduce we push notification in 2009 and in 2010 Google released its own service, Google Cloud to Device Messaging.
    How is it different: The beauty in web push notification, unlike traditional ways, is, the user need not be subscribed & active on his device, meaning there is no need for a user to be reading his favourite article on any website for an ad to be shown to him. This was kind of a gold mine and iZooto cracked it quite early by tying up with publishers and having a fantastic platform quick and ready for use of publishers.

    Here are a few technical details on the marvellous Integration between iZooto and adgebra. The integration is a pure HTTPs request and the response is in JSON format that contains all the components needed to form a native ad and make one impression of Push Notification on a client’s device.

    adgebra needs a lot of User details (PII excluded) for intelligent decisions in showing a relevant ad to a user based on his Geo, Site, Device, language, etc. iZooto passes on all the user and site-related parameters to adgebra and this forms targeting input to adgebra. These inputs are fed to adgebra algorithms and provide the most relevant native ads based on the input targeting parameters.

    There were other challenges of security, requests through multiple servers, native image size difference, impression and click tracking, fraud clicks, etc. Each case had its own challenges and solutions were custom designed and implemented.

    Currently, adgebra is serving 1mn+ requests daily from iZooto that translates to around 4K to 5K clicks.

    Integration wouldn’t have been a cake walk without a great tech team at iZooto – hats off to Neel, Rohit and Sachin – Kudos guys, let’s reap the benefits!

    Disaster Recovery

    Disaster recovery and Idle Infra

    599 400 Rajesh Chande

    How to master disaster recovery in a DevOps world by Jonathan Hassell raised a point about the idle capacity of DR infrastructure. He set me thinking over the weekend and my thoughts have been shaped out in this article.

    DR (Disaster Recovery) and BCP (Business Continuity Plan) are a reality for almost all sized companies and should be handled with priority. Small and mid-sized companies can avoid getting into the trap of not utilizing their disaster recovery infrastructure thereby minimizing Capex and Opex at the same time providing 24X7 uptime.

    A typical disaster recovery  setup on test and prod environments are hosted onto a primary site. Disaster recovery environment is on a secondary site. The code-base and DB are synced up with DR site at regular intervals with delta to meet the Disaster Recovery agreements for RPO, RTO and RCO. DR Drills are scheduled frequently, so we typically have at least 3 environments in all with one environment being non-operational while the Prod is operational. A good start to know more about DR is here.

    CXO’s more often than not, feel cost pinched with a non-operational disaster recovery site hoping that when DR happens, routinely non-operational disaster recovery  environment works fine as expected. Such an expectation is warranted with enormous efforts that goes in performing so many successful DR Drills round the year. But does a routinely non-operational DR always do the wonders for you? At least the state non-operational makes me uncomfortable and here is a proposition.

    If you feel familiar with the above situation read on for a solution that can possibly help you.

    Just keeping a parallel (non-operational) DR environment ready on a DR site and having frequent DR Drills may not ensure a successful DR and BC. Hoping it operates “expectedly” on D-day is far from real, most of the teams involved remain behind the curve in catching up with the delta changes that keep happening on the production LIVE site all the time. Only when DR (Drill) happens these delta changes surface and then the changes are done on the DR site but this could be too late or costly. The below strategy will reduce delta and make the DR environment closer to prod. Again going into the Disaster Recovery  nitty-gritty is out of the scope of this article.

    One way of handling this situation is to follow ToDR aka “Test on DR”. Move your test environments on DR site. The primary site shall host only the production environment. Test and DR environments remain on the DR or secondary site.

    The benefits of this are:

    1. The DR site remains always operational – not “only” during the drills.
    2. All infrastructure components in DR site remain tested “all” the time.
    3. Issues on DR site will start surfacing routinely rather than last minute surprises rather shocks!
    4. Scaling of infrastructure can happen in seconds using DevOps depending on the load as needed.

    Whenever disaster strikes, test environment can go down and the DR environment will be made “up and running” by applying needful network / DNS changes (I love this concept of using DNS names – helps a lot, but again out of scope of this article) and making the last copy of Prod DB available. No customer would object having their test environments down during a DR. Moreover RPO, RTO and RCO do not apply to test environments so this fact can be capitalized as well during the DR.

    Many small and mid-sized companies with SaaS-based offering can utilize this proposition for internal but critical or even customer facing products or services successfully and benefit a lot with saved Opex.

    As correctly mentioned by Jonathan, DR & BCP should benefit a lot by spinning new environments in no time using DevOps, but let’s have idle DR infrastructure to a minimum, giving the folks at finance team a reason to smile and cheers! Happy DaRing!!

    “Wishing Won’t Keep You Safe, Safety Will”

    embrace-devops-lifestyle

    Embrace DevOps as a lifestyle

    599 400 Rajesh Chande

    For me year 2015 started with a list of resolutions that included shedding few kilos (both personally and professionally) and this time I was keener than ever before. I wanted to be lighter (leaner), faster & reliable (sounds like Agile and DevOps guy) I was very clear of one thing that I will never resort to any short term solutions of hanky-panky “diet-plans” to show off as a fad but rather change my lifestyle to ensure a definite and long term success to my initial resolution. I followed this strategy strictly and here I am with a permanent loss of 9 kilos since more than a year and continue to be leaner, faster and reliable.

    Almost same time, similar strategy applied to Software Engineering lifestyle @ Inuxu. Developers, testers, and Ops need to change their mindset and not resort to using ad-hoc latest tools in fad to shed the SDLC weight. In order to be more agile and embrace DevOps, one needs to understand the broader scope and breathe it every moment. You might lose some process weight by using ad-hoc tools, but unless DevOps becomes your lifestyle permanent long-term benefits won’t start flowing in.  Click here to understand more about what DevOps is.

    Roles for both developers, testers and Ops have never been so challenging with overlapping responsibilities in a DevOps culture:

    • A Developer should be fully aware and be able to ensure the code is production ready all the time delivering more frequent but stable releases.
    • QA team is no longer just testing the code but coding test cases ensuring all the STLC is adhered to.
    • Ops is now more application centric.

    Thanks to the cultural change, we have a more collaborative team!

    The famous Venn diagram for DevOps should show the fourth circle, highlighting management’s commitment as well, that will ensure the DevOps is part of the overall culture for any Engineering team.

    devops a lifestyle

    The above diagram (Image Source: Wikipedia) at times appears flawed in the perspective of involving only 3 teams and missing out on other teams like compliance and security.

    Thankfully we did not have any legacy systems that still remains a challenge for many. Frequent, repeatable and stable deployments are a reality and are being done seamlessly with almost no manual intervention, giving Inuxu a sustainable competitive advantage.

    One of the biggest questions is who owns it? Let me try and answer one of the challenges posed in DZone last year. Certainly onus has to be on the engineering head to drive it. Engineering head is the one rightly placed to differentiate between fat and muscle weight from the SD(T)LC cycle and make those critical and right decisions.

    We @ Inuxu are “DevOps’ed” and have embraced this cultural shift. We are already seeing the benefits of critical thinking, creativity and innovation. Now we have an integrated, collaborative team as against to teams working in silos – Wow!!! – Thanks DevOps for helping to shed my weight @ Inuxu. As a startup if you need any help to get DevOps culture at your organization, get in touch for tips.

    Who says New Year resolutions don’t work!!!