Author

I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)

Meta

Entries in reliability (3)

Tuesday
Jul172007

Migrating to a DNS hosting provider

I have recently migrated all the DNS data of Lokad.com toward DnsMadeEasy, a provider specialized with DNS hosting. For a long time, it did not even crossed my mind that such low cost independent service would actually exists.

DNS stands for Domain Name System. In simply words, the DNS converts the domain name address into a IP address. Look for the DNS wikipedia, if you want to know more.

Why do I need to know anything about DNS?


As a webmaster, DNS are most usually completely handled by your hosting provider. If your web requirements are simple, you might not even cross DNS settings, everything being completely handled by the hosting provider.

Yet, if you start to rely on 3rd party hosted services such as blog hosting and forums hosting, you may have to update your DNS settings so that the URL is blog.mycompany.com instead of mycompany.myblogprovider.com. With those 3rd party hosted service, your internet domain becomes a patchwork that includes machines owned by various hosting providers. For example, both blog.lokad.com and forums.lokad.com are hosted by 3rd party companies.

Why should I bother about DNS?


At present time, there are many dirty cheap hosted services. Lokad is still a uISV but relies already on almost a dozen of various hosted services providers. And, in very center of this small network lies the DNS. If the DNS go wrong, then the whole network is going to be in deep trouble.

Until very recently, Lokad was relying on the DNS management provided by a low cost regular hosting provider. The DNS hosting was really reliable, we never encountered any issue at that level. Yet, I was a bit concerned by the fact that the "Lokad network" was dependent on a regular hosting provider to manage all the information related to the other hosting providers. This situation was making this particular hosting provider much more critical to the whole network than it ought to be.

Thus, I have decided to migrate everything to DnsMadeEasy. As a result, I am gaining flexibility for potential further hosting migrations. One might argue that I have simply moved for critical node for my previous hosting provider to DnsMadeEasy. That's true. But DnsMadeEasy is completely dedicated to DNS management. Thus, they are not competing with other providers that are referred by the DNS.

Sunday
Mar252007

VPS for continuous integration

Continuous integration is a cornerstone of our development processes at Lokad. We are currently relying on CruiseControl.Net to support continuous integration.

Several months ago, I did ask on various web forums if any company would sell hosting packages that would natively include CruiseControl.Net. The only answer that I did get was Get yourself a $300 PC and use it as your continuous integration server. I was totally unsatisfied with such answers because the maintenance costs associated with the management of an additional machine are terrible. Indeed, if you assume that your time is worth $50/hour (which is already quite a low estimate if you are a moderately skilled developer); then, this additional machine will cost you more than $200/month assuming only 1h of maintenance per week (which is also a very low estimate).

At this level, it becomes clearly profitable to go for a rented cheap dedicated server ($100/month). Yet, the idea of paying that much for a server that would be used at 5% of its capacity was not entirely satisfying. Thus, we have finally chosen to go for a Virtual Private Server (VPS) that are available at much cheaper rates ($30/month).

Bottom line: VPS is really the way to go for continuous integration involving small to midsize software projects.

Monday
Jan292007

Weird consequences of full transaction logs

Let say that you have an ASP.Net 2.0 web application running on top of MSSQL Server 2005. Guess what happen if you database transaction log get full? Well, you will get a large amount of weird side effects, most of them seeming totally unrelated to the saturation of the transaction log.

Among the problems that I have encountered

  • The web services of your website start to send totally misleading error messages like authentication failed.

  • You can not login through web form into your ASP.Net application any more. You will not get any error message, but the login control just tells you that your password is wrong.

  • You look at your error logs (like ELMAH), but nothing gets recorded.

  • You decide to go through the "recover password" (because you're still no suspecting the transaction logs), but actually it fails and no email is sent.

For the note, the following SQL question clears your transaction logs
DUMP TRANSACTION mydatabase WITH NO_LOG