Alexa, what is the capital of Israel?

The status of Jerusalem has been in the news a lot in the last few weeks, since Donald Trump confirmed the US now recognize the city as capital of Israel. And the recent UN voting on rejecting the recognition.

If maps and location-based services present unexpected challenges in a disputed territory to the developer who targets an international audience, voice services are the new frontier.

While preparing a few examples for my talk at Codemotion Berlin last October,  I asked Alexa (in German) the question “Alexa, what is the capital of Israel?”

And on October 3rd, the answer was

Die Hauptstadt von Israel ist Jerusalem

that translates in a short, direct but controversial

The capital of Israel is Jerusalem

An answer that might upset a significant number of users of the Amazon service. Apparently while Mr Trump followed the advice from Alexa, Amazon rectified the answer in the meantime. Asking the very same question today, you have a longer

Israel hat Jerusalem zu seiner Hauptstadt erklaert, diese wird jedoch nicht von allen Staaten anerkannt

that translates in

Israel has declared Jerusalem to be its capital, but it is not recognized by all states

Someone might argue that actually most states do not recognize it but it is definitely a more accurate answer than the initial one and that targets a wider audience.

This is something easier to address in a voice service than a geolocation decoding challenge,  but it is still an example of the problems that a software developer has to face to target an international in a disputed territory.

 

Alexa & Grandma

The sound is not as good as a Bose speaker. I sadly had to remove a few broken valves to make space for a working audio device. But setting up Alexa and testing my Big World skill on Grandma’s radio is priceless. Next step, setting it up inside the radio.

IMG_20171128_072042097

Triggering a failover when running out of credits on db.t2

Since 3 years ago, RDS offers the option of running a MySQL database using the T2 instance type, currently from db.t2.micro to db.t2.large. These are low-cost standard instances that provide a baseline level of CPU performance – according to the size — with the ability to burst above the baseline using a credit approach.

You can find more information on the RDS Burst Capable Current Generation (db.t2) here and on CPU credits here.

What happens when you run out of credits?

There are two metrics you should monitor in CloudWatch, the CpuCreditUsage and the CpuCreditBalance. When your CpuCreditBalance approaches zero, your CPU usage is going to be capped and you will start having issues on your database.

It is usually better to have some alarms in place to prevent that, either checking for a minimum number of credits or spotting a significant drop in a time interval. But what can you do when you hit the bottom and your instance remains at the baseline performance level?

How to recover from a zero credit scenario?

The most obvious approach is to increase the instance class (for example from db.t2.medium to db.t2.large) or switch to a different instance type, for example a db.m4 or db.c3 instance. But it might not be the best approach when your end users are suffering: if you are running a Multi-AZ database in production, this is likely not the fastest option to recover, as it first requires a change of instance type on the passive master and then a failover to the new master.

imageedit_7_3403406284

You can instead try a simple reboot with failover: the credit you see on CloudWatch is based on current active host and usually your passive master has still credits available as it is usually less loaded than the master one. As for the sceenshot above, you might gain 80 credits without any cost and with a simple DNS change that minimizes the downtime.

Do I still need to change the instance class?

Yes. Performing a reboot with failover is simply a way to reduce your recovery time when having issues related to the capped CPUs and gain some time. It is not a long term solution as you will most likely run out of credits again if you do not change your instance class soon.

To summarize, triggering a failover on a Multi-AZ RDS running on T2 is usually a faster way to gain credits than modifying immediately the instance class.

Percona Live: Do Not Press That Button

PLD-17-01.pngIf I had to mention a single technical blog that I always find informative and I have followed for many years, I would say without doubts the Database Performance Blog from Percona. That is why I am so keen to attend this year the Percona Live Open Source Database Conference in Dublin and present a lighting talk Do Not Press That Button” on September 26th. You can find more about my short session on RDS here. Looking forward to Dublin!

The moment a project fails

The moment you realize a project you have been developing does not deliver can take different forms. It might even be accidental. For me the reality check was a tall de carrers sign in the streets of Barcelona.

A keen and slow runner, in the last few months I have been developing a tool to crawl and keep up to date running events for RaceBase World. The project was a mix of AWS Lambda, Scrapy and Python, able to collect over 25K races around the world and keep them up to date. Not an easy task.

The goal was simple: sometime you are lucky enough to plan your holidays around a marathon abroad, possibly one of the largest events around the world.  More often you plan your vacations or business trips and then you simply wonder if there is a running event in the area.

I have now been in Barcelona for a few weeks, I have been looking for what I believed was an unlikely road race in summer and my lovely crawler could not find any. And Runner’s World Spain could not find one too. 

Still a sign on the door of the building where I live is telling me that up to 5 thousand runners are going to run in Barcelona next Sunday for la Cursa Barça. No better way to prove that my global database is inefficient.

You can of course try to collect million races worldwide, something that is very hard to achieve and will anyway generate too much noise for the end user. But having only a few thousand events globally will include only the large races (the ones a runner can find without any help from RaceBase World or any other website) and a few local random ones.

And the moment I cannot trust my own project to find a race, I can consider it a failure. But before working on a new idea or a new (local) approach to discover new races, it is time to join la Cursa Barça and forget Python.