Last week some of you noticed that the integration solution you’re using didn’t synchronize data as timely as it used to do, or sometimes even didn’t synchronize at all. Some other sporadic issues have been reported as well, e.g. some integration solutions couldn’t be even activated.
As you might have seen, we’ve announced about that on Twitter, saying that GitHub being under DDoS attack has caused these issues.
You can find more details about this attack, called by GitHub “the largest DDoS attack in its history”, in this beautiful article.
GitHub actually did a very good job in mitigating the attack, and our integration solutions were up and running again quite smoothly. But we’d like to cast a retrospective glance on what actually happened to our integration solutions (we call them recipes) and what lessons we learned out of it.
What is GitHub to us?
GitHub is a very cool and useful Git repository hosting service that comes with a bunch of nice features: it has a Wiki, a light bug-tracker, you can upload your code directly from the browser.
But what’s even more important, it has an API. This is why we found GitHub for project management especially appealing to store our ready-to-use integration solutions, or recipes, on it. There is, of course, a number of other reason why using GitHub has been so convenient for us.
First of all, with GitHub, it’s possible for us, non-developers, to make certain small changes without having to distract our developers. For example, I use it to change the description or the title of a recipe or add a picture to it.
Secondly, we can make a copy of a recipe repository and give access to it to external developers if they want to add new features to it or try out combinations with other connectors of their own.
Thirdly, we can use GitHub in case external developers would like to share with us an already built connector for a future recipe. They can just upload their code, give us a URL of this connector’s repository on GitHub, and we will clone it onto our platform.
All this makes GitHub for project management a perfect collaboration tool for us.
So, what happened when the attack started?
When the DDoS attack started, the GitHub guys began “switching off” their API to repel the attack, and so, we couldn’t access it as well. And since all our recipes lying on GitHub are, so to speak, activated through their API, the recipe apps didn’t start at all.
And this is basically it, there is not much to add to this. Some other issues emerged together with the recipe apps lying dead, but all in all, the main problem was that we lost the control over our recipes due to an external “force” and we had no chance of influencing this.
Lessons learned
The most obvious lesson learned is that we need to review our ways of using GitHub. Basically, this means that we will pay more attention to the decentralization of Git and use this feature more, in order to become less dependant on GitHub itself.
Probably, this will make the usage of GitHub for project management not so convenient and elegant for us as before. But it will still be one of our favourite collaborative tool – which is something that GitHub is absolutely great in.
