Changes between Initial Version and Version 1 of DjangoSuccessStoryBuddyNS


Ignore:
Timestamp:
02/27/2014 08:31:06 AM (5 years ago)
Author:
michele
Comment:

Add BuddyNS success story. Thanks Django!

Legend:

Unmodified
Added
Removed
Modified
  • DjangoSuccessStoryBuddyNS

    v1 v1  
     1= Django at BuddyNS
     2
     3BuddyNS is a DNS replication service, launched in 2010. It employs custom logic for detecting and synchronising zone changes in minimal time, and serves tens of thousands of domain names for ISPs, universities, NGOs, ccTLDs and private individuals. [http://www.buddyns.com BuddyNS.com]
     4
     5== Why did you choose Django?
     6
     7We do secondary DNS only, so there's some setup involved to get the user's DNS data onto our cluster. We wanted the Web Application to go so far as feasible in helping the user perform, monitor, and troubleshoot such setup. As this involved lots of logic in there, we looked for a framework that, at the same time:
     8
     9* incorporated all the necessary WebApp parts (templating, URL routing, db access) without having to combine many external libraries
     10* was flexible enough to allow large customized parts
     11* worked decently with databases shared with external (backend) tools
     12* had enough maturity and momentum
     13* was programmed in a popular programming language
     14
     15
     16== What were the other alternatives?
     17
     18Django was pretty much the only option matching the requirements we set. Other frameworks provided more flexibility at cost of less integration. In the end, we liked Django providing all the tools while never preventing their replacement or customization.
     19
     20
     21== What benefits did you get from Django?
     22
     23An extreme speed up, especially in the initial phase. All the tools were there, well integrated, intelligible and extremely well documented. At maturity phase, we got vast choice for any necessary extension (API frameworks, debugging interfaces, advanced logging etc).
     24
     25We found impressive that, after years and growth to include so many different technologies, the framework never really put us in a position to say "crap, this can't map well in django".
     26
     27
     28== What problems did you run into?
     29
     30Some minor bugs in the framework, which is luxury problems. The community is so big and available that our reports were reviewed and incorporated very quickly in most cases. Particularly valuable is the IRC channel, where core team folks occasionally hang out. This speeds up troubleshooting and creating patches that fit in the framework efficiently.
     31
     32More recently, django's bug tracking procedures underwent more formalization and we found those procedures slower and occasionally a pain.
     33
     34
     35== Is there anything you'd like to have done differently?
     36
     37We recently started monitoring and addressing deprecations earlier our process. Django is framework with outstanding stability and feature-richness for its age, and deprecations do occur at quite a pace. We read users disliking that; we encourage it in the name of clean APIs and avoidance of code overbloat for backwards compatibility.
Back to Top