Managing Tech

Today, I heard that Google is most likely working on a new version of their Google TV product.  This evokes mixed feeling in me.  First and foremost, I’m glad that Google is sticking to its guns and working to improve the product.  Internet Television has great potential to turn a static one-way broadcast model into a rich interactive and social experience.  But the 1^st Google TV was a piece of crap and should not have been released. The first release was so far off the mark that I worry Google doesn’t really understand what people are looking for when they sit down to watch TV. At best, it was a technology preview with very few compelling end-user experiences. Apple TV, on the other hand, is much closer to getting it right, even though it’s currently crippled by being limited to one-way media streaming.

So let’s look at what Google needs to do to have a chance with this next release.  Google needs to start with the basics and realize that when we sit down on the couch to watch TV, we don’t want to use a browser and google for stuff.  We’ve just come back from work were we did that all day long.  I have this image of a google engineer coming back from the Googleplex and sitting down and thinking about how fun and informative it would be if the TV had a search bar. Unfortunately for Google, that experience, while not invalid, is not typical for the average TV viewer.  Most of us have a very different goal when we sit down with the TV.  Usually its after a hard or busy day and we want to be entertained. That’s a bit of a simplistic definition but clarifies things for this discussion.  Hint to Google, think about how we use our mobile phones.  Just look at the top app downloads and a lot of it is about entertainment and social. The 1^st Google TV was clearly a product designed by a bunch of computer engineers (that’s my background as well so no slight intended), who were brilliant but could have used some input from usability experts.

When you are trying to create a new product category, like internet TVs, there are a couple of critical things that have to happen to give the product a chance.  First, the benefit has to be clear.  Second, the benefit needs to be simple and tangible.  The reason that Apple was able to have such a success with the iPad while all those before them failed, was that they understood these requirements.  I’ve had and used a number of tablets before the iPad and hated them all. So what specifically does Google need to do in this next version to get the average person to consider or better yet, dream of buying a Google TV?

1. Have a very simple user interface. When we sit down to relax and turn on the TV, no one wants to invest in learning a complicated system.  In fact, it needs to be simple enough where I could hand the remote to my mother and she could use the core functions.  And let’s talk about the remote.  Its design is really important.  Every Google TV I’ve seen had a big clunky keyboard.  Who wants that on their couch or coffee table?  The Sony version of Google TV had pretty much the worst remote every made by mankind.  It was that bad.  There is no doubt that’s it’s a difficult design task to add a ton of functionality and figure out how to have a simple interface.  Experience has shown that in cases like this, it’s better to error on the side of simplicity rather than complexity.  Apple TV’s remote is much better than Google’s even though it can’t do much because people can figure out how to use it. What Google TV needs is a simple touch screen handheld like an iPod Touch.  Or for those with a smartphone, let them use that.  Google, please do not even consider shipping the new version of Google TV if it’s going to come with a full size keyboard.
2. Google TV must have TV shows and movies on demand built-in and front and centre.  If it came with Netflix support rather than your own streaming solution, that would be a big plus as many people already have a membership.  While this feature is core and needs to be perfect, I don’t believe it’s enough to make Google TV a success.  Adding Netflix to your TV through an add-on is pretty easy and doesn’t require something as expensive as Google TV.
3. Here is where we get to the good stuff.  Google TV needs at least one killer app.  At this stage, no one care or needs 100K apps.  What we need is a few clear killer apps that show people how Google TV can rock our world… or at least how it’s is better than a plain TV.  People need to see something that makes perfect sense to them and helps them wrap their head around the potential.   You know, like Halo was for the 1^st Xbox.  What we do know for sure is that the killer app is not a browser with a search bar.  It may be hard for Google to hear or accept this but it’s the truth.  People generally don’t want to search or browse while watching TV.  TV is supposed to be immersive and a search bar would just get in the way.  Instead, Google needs to think about what it means to watch TV from a users’s point of view.  And then think about how an internet or app-enabled TV could enhance that experience.   Lets look at the top shows and what might be possible:
   • News.  Now that I have an iPad, TV news does not work for me anymore.  First of all, my life is not structured enough to be in front of the TV at the right time.  Google should have key TV news available on demand.  Also, I love that on an iPad, I can pick and choose the stories to focus on.  The result is that I’m able to drill down on the news I care about and skip the stuff I don’t have any interest in.  Google TV needs to bring these elements to television.  With a touch-screen remote, it should be easy for a user to navigate through stories.  For news junkies, this might be enough to consider a google TV.
   • Game Shows.  How many of us watch a game show and play along.  Well, with an Internet TV, it would be possible to actually do that.  As the game is played on the TV, you should be able to enter your answers on the touch-screen remote and have the TV show you your score.  TV is inherently a social thing and rather than the whole family passively watching, with Google TV, it would be like the old days of board games where we all play along and against each other.  For families that watch TV together, this probably would be the killer feature.
   • Talent Shows.  There seem to be a ton of talent shows on right now where the viewers are asked to vote.  It started with American Idol but now there is Dancing with the Star and many more. Each of these ask viewer to vote using SMS.  In this age of real-time, it would be much more satisfying and interactive if viewers could vote during the show.  And since we’re not limited to clunky SMS, lets have some fun with it.  Let viewers vote on all sorts of things: personality, skill, best costume, etc.  And I can think about all sorts of infographics that could be shown about how viewers voted.  Was the singer popular everywhere or was it just young girls or was their fan base mainly in one part of the country.
4. Add an app store.  I really struggled with whether to add this or not.  I really don’t think that Google TV needs an app store to succeed at this point.  I’m sure this is a contentious point that not everyone will agree with but Apple TV has sold over a million devices without an app store.  That’s way more than Google has sold.  I guessing that Apple decided it was better to ease people into an internet-enabled TV rather than throw too much at users and have their eye glaze over. That and they belief that consumers won’t pay more than $100 for such a device. Given that the iPad is $500, it really shows that they have not figured out what the killer app is yet (which surprises me).  Anyways, its been almost a year since Apple TV was launched and I’m guessing that the next version of Apple TV will finally get an App Store so Google, for competitive reasons, you need to add an app store. In the end, what an app store adds is games.  And that’s something people will want and enjoy.  Now what would really be cool is if the games could multi-player.  If the family is sitting down together, a one player game is not a great experience.

And that’s it.  At this point there is enough for people to wrap their heads around and get what Internet TV is all about.  Don’t add anything else for this release.  All those other great ideas you have should be saved for another release.  Don’t create a propeller head product that only a genius could use.

I for one believe that an Internet enabled TV will be a valuable addition to the home.  I was a Tivo user ages ago and my family loves the Windows Media Center we have today.  But neither product went beyond simple TV functions like on-screen TV guide or programmed recording of shows.  There is so much more than an Internet enabled TV can do for us.  I’m keeping my fingers crossed that Google has been working hard to improve the usability in a meaningful way.  If they don’t, I fully expect that it wont be long before Apple has the time to get serious about Apple TV and let it spread its wings.  I mean now that the iPad has shipped, they must have some extra time to work on this, shouldn’t they?

Google, the opportunity is yours to show us a compelling reason to want an Internet-enabled TV. Please don’t blow it!

What is it?

Today Amazon announced a new service, Elastic Beanstalk. What it is, is a combination of a complete Java stack (other languages supposedly coming later) along with a management wrapper around some of the existing EC2 tools such as load balancing, auto-scaling and monitoring.  This definitely touches a pain point that developers are facing when they deploy their apps to the cloud.  In fact, it’s part of the reason that Heroku and Engine Yard have done so well.   While its pretty easy to setup a server in the cloud and load up your software, a setup that basic normally won’t scale and will not be  easy to manage over time.  As a result, developers either spend a lot of time rolling their own solutions or they pay for a Platform-as-a-Service (PaaS) like the ones mentioned earlier.  What Elastic Beanstalk does is provide developers some of the advantages of a PaaS without the costs and without given up total control of the server.

So let’s dig into Elastic Beanstalk a bit more.  There are several pieces to the service.

• A Java stack that Amazon has put together that is comprised of Linux, Apache, Tomcat and Java. There is even an Eclipse plug-in to integrate Elastic Beanstalk into the IDE.  The stack is pretty standard.  It does not include things like Spring or any other popular variations of the Java stack.  Note, Amazon has indicated there will be other stacks in the future.  In fact, Engine Yard is supposed to be helping to create a Rails stack.
• A Management GUI built into the AWS console that allows developers to setup and configure their application.
• Use of some the AWS services.  That includes: the load-balancer, auto-scaling and cloud-watch.  S3 is also used to store version of your app and for log consolidation. Normally, you would need to setup these up yourself if you wanted to use them.  Elastic Beanstalk will automatically setup all these services when it deploys your app.
• Support for application versioning.  Elastic Beanstalk uses S3 to store each of the versions of your application which it can use to either deploy the lastest release or rollback to the previous version.
• An API to allow developers to build Elastic Beanstalk into their development process.  I can see teams using Hudson or another continuous integration using the API to push new releases/versions to Elastic Beanstalk.

Using Elastic Beanstalk is pretty straightforward.  First you load your application on to S3.  Then you use the AWS Console to create a new application.  The configuration options allow you to specify a variety of options including the S3 bucker where to find your application and the rules for when Amazon should scale your application. At that point, you are able to launch the application.  Elastic Beanstalk will setup the load-balancer, create a EC2 instance, install your application, setup auto-scaling and cloud-watch.  The final thing you need to do is point the domain for your app to the CNAME that Elastic Beanstalk provides.  At this point, your app is live and setup in a configuration that should be pretty easy to monitor and manage.

What’s Missing?

Clearly there is a lot to like about Elastic Beanstalk.   Is there anything that got missed?

First, as previously mentioned, right now the service only supports a Java stack.  For a lot of people using some of the other popular languages (like Ruby, Python and PHP), that is a non-starter.  Hopefully, it won’t be long until Amazon has stacks for the key popular languages.

But the other important area where Beanstalk falls short is in that it is oblivious to databases. I can’t image there are very many applications that don’t depend on some sort of database.  That means that you need to take care of setting up your database yourself.  And since Elastic Beanstalk does not know about your DB, it is not able to monitor it or scale it either.   This means that even though Elastic Beanstalk takes care of your application, you need to find another solution for the database.  To be fair to Amazon, there are a lot different databases that people are using today (like MongoDB, CouchDB, Cassandra, etc).  But I think they should have been able to support MySQL, especially since they already have the Relational Database Service (RDS).

You should also think about is whether you application needs another other than the basic stack.  Does it use Memcached, Redis, or some other piece of software that is not part of the standard stack.  If so, you still need to handle that yourself.  Either you need to put it on another service or figure out some way to automate the installation when your app comes up on a server.   If you look at Heroku, they now have an add-on program that is quickly building a robust list of options.  Amazon needs to consider something similar.

And finally, if you move to using Elastic Beanstalk, you are pretty well committing yourself to keep your app on Amazon.  I don’t see that a big issue but it’s something that you need to keep in mind.

So is it Worth Using?

In short, this is still an important step forward for Amazon.  For developers that have been building their own software stacks and manually deploying it to EC2, this has the potential to take several things off their plate.  Clearly, Elastic Beanstalk will not be 100% of the solution but having the things that Elastic Beanstalk handles taken off a develoepers plate will make things simpler, even if they still need to handle some things themselves.  One thing i forgot to mention is that Elastic Beanstalk is free (although you still pay for the underlying services).  That in itself should get a lot EC2 developers to give it a look.

A HTML5 mobile app that I was working needed to get the city and province (ie state for you non-Canadians) that the user was in. Using the HTML5 geolocation method made it easy to get the latitude and longitude. But the missing piece was how to translate that into city, county (if applicable) and province/state.

Google maps is the defacto solution in the geolocation space. But their API include a term that requires you to display their map as one of the conditions of using their API (see terms of service). This works for some apps but not always (and not in my case).

SimpleGeo is another popular option. What it has going for it is that there are very few restrictions and the API is very easy to implement. I was able to have code working in less than 30 minutes. The problem is that the data is really only good for locations in the US. If that works for your app, definitely take a look at this. When I tried it with some Canadian locations, there were gaps in the results and some were just wrong. Now to be fair, SimpleGeo is still in beta and maybe somewhere down the line, they will have better support for data outside the USA. Note, when using simplegeo, remember to allow either ‘*’ or localhost in the admin panel if you will be testing from your own machine or a mobile phone. The default is just ‘simplegeo.com’ which will cause your API calls to be rejected.

The only other reasonable option left was Yahoo’s Placefinder API. Now, at first I didn’t expect Yahoo to have something that would be of use. They has been getting getting a trashing over the last year in the press. But as I started to look at the API, I realized that’s actually pretty powerful. And it seems to have good support for outside the United States. Definitely the data that I’ve tried for Canada has been very good. One thing to note is that Yahoo only allows 10K requests per day per app. If you need more than this, you need to contact them and work out an agreement.

The API is pretty straightforward to implement as its a simple HTTP GET. You can give it a latitude and longitude that you got from the HTML5 geolocation method and Yahoo will return all sorts of useful data about the location.

If you want to give the API a quick try, take a look at GeoPlanet Explorer web interface created by one of their ex-Developer Evangelists. In the ‘drilldown’ mode, locations are organized as a tree and the UI lets you see things like a locations parents (ie province & country) and it neighbours.

Have geocoding!

When I tried to add Admob to my mobile site a few days ago, I discovered that Google/Admob’s ruby gem only works with Ruby 1.8.7 and Rails 2. Considering that Rails3 is was released earlier this year, it was surprising that the gem had not been updated. Anyways, as its open-source, I was able to get the code from rubyforge and make the required changes.

The new gem is called ‘admod19′ and can be installed easily by typing gem install admob19. If you would like to get the source, its on github at https://github.com/anuaimi/admob19

For those that wand the technical details of the changes that I made, here is a list of what was updated.

1. how session ID was accessed. session.session_id was changed to session[:session_id]
2. updated MD5 calls to use new module name. MD5 is now Digest::MD5
3. strip off any rack or rails headers in the request that is sent to Admob

Final note, follow the instruction in the gem’s README.txt file rather than what’s up on Admob’s site and you should be up and running quickly. Oh, and Admob is not returning ads, it’s possible they have no inventory. Easiest way to test that is to add an in-house add and have Admob use that whenever they don’t have an ad to server.

Ubuntu has had a great way to automate the building of your Amazon EC2 server through something called ClouldInit. What this allows for is that during the creation of a new instance, you can also pass in a variety of data needed to setup your server & application. Normally what is passed is a script but there are several other options. The script can be created in bash, perl, python or awk. The script normally installed any packages needed by your app, configures the various services, loads any startup data and finally installs your application. By scripting the setup, you are ensured that your server is 100% built the same way each time you create a new server. As of yesterday, CloudInit can be used by those of you more comfortable with Redhat/Centos as Amazon has announced their own CentOS-based linux AMI image that includes CloudInit. So now, there is a standard way to automate the building of your server, no matter what flavour of Linux you use.

I’ll talk more about CloudInit in a minute but first I wanted to review some of the other options that people have to setup their server instance and why automating using CloudInit is most likely the right tool to use.

• manual setup. This involves SSH’ing into the instance once it is up and running and manually entering the commands to install your application and its requirements. While this is acceptable as a starting point while you are in development, no application should be deployed into production on a server built this way. If your server ever goes down, you are in for a lot of pain (and stress) when you have to recreate your server on a moments notice during an outage. I’ve seen a fair number of startups using servers built this way. They start with a ‘dev’ server that was hand built and somehow that ends up being the production box. It’s really important teams take the time to rebuilt the production server cleanly before launching.
• using a pre-built AMI. this is where you manually setup your server and then create a new AMI image from it. Or more likely you are using someone else’s AMI. Ec2onrails is a perfect example of this. The advantage of using pre-built AMIs is that the server always comes up in a known (good) state. This is a big step forward from manually setting up the server. The downside is that if you want to make any changes to the setup, you need to save a new AMI, which is a slow process. And if you are using someone else’s AMI, you may not be able to do so. In this age of agile development, this can be a handicap.
• capistrano. This is a build tool from the Ruby world. It can be used to deploy non-Ruby apps as well but the scripts must be in Ruby (this may or may not be an issue for you). Overall, there is a lot to recommend about capistrano in that it is also a scripted solution.Only normally Everything is done through your Capfile. This is where you script the setup of your application.
  The way that capistrano works is by SSH’ing into the server instance and running commands. This happens after the server is up and running. Normally, you start the server instance manually and then plugin the IP address or server hostname into your Capfile. The only downside to capistrano is that is runs from the developer’s desktop. Which may be fine for smaller teams. The minute you have a NetOps team, you probably want something that is not tied to a singled developer station.

Instead of the above, you should take a look at using CloudInit. What that lets you do is pass a script to the server instance that is run during the boot process. So how does CloudInit work and what are the key options. CloudInit allows you to use the ‘user-data’ field of the ec2-run-instance command to pass in a variety of information that CloudInit will use to setup your new server instance. The options include:

• Cloud Config Data This is the simplest use and allows the common tasks like update linux, install packages, set the hostname and load ssh keys. The full set of options are described here. Using config data will perform some core items but will not be enough to bring up your app.
• Run a script. If you can’t do what you need with the config data, you can create a script that will handle the extra items. The script can be in bash, python or any other language installed. For my servers, I use this to setup the database, load the application from git and register the server with my dynamic DNS provider. In fact, if you prefer, you don’t need to use the config data and can put everything you need in a script. Note, the script is run late in the boot process. This is normally a good thing but if you have a need to run something earlier take a look at Boothooks.
• upstart job. if you need to, you can provide a single upstart script that will be installed to /etc/init.
• a combination of the above. Finally, it is possible to combine all of the above. CloudInit supports creating a mime multi-part file that is a combination of any of the above items. There is a helper tool called write-mime-multipart that will take a set of inputs and generate the mime encoded data to pass to user-data. Note, the maximum total size that can be passed to user-data is 16K. If you are above that limit, you can gzip the data or you can move the items to files accessable through a URL and pass the URLs to user-data

As you can see CloudInit is very flexible and should allow you fully automate the building of your servers. Finally, I’ll note that CloudInit is not limited to EC2 but will also work with Ubuntu Enterprise Cloud (UEC).

Happy scripting!!

For the last while, I’ve been using Tumblr rather than WordPress for my blog. But now I’m back to using WordPress. While there is alot to like about Tumblr and it’s super easy to use, it’s a very basic blogging platform.

Amazon is clearly the right answer for most people’s cloud services. But when you are developing software and just need a small server to do some testing, their smallest instances was about 6 times more expensive than competitive offerings. As a result, a lot of developers also had a rackspace or slicehost account. Now that AWS has announced their new ‘micro’ instance, most of us can get back to the simplicity of using a single cloud.

The new ‘micro’ install actually is not that small. It has a decent amount of RAM at 613MB. That’s much more than most small VPSs from other vendors that only have 128MB or 256MB. Also, while it has one ECU (compute unit), it can burst up to two ECUs. Again, not bad compared to other vendor’s basic offering. Finally, one different is that the ‘micro’ does not include much hard disk space so you will need to add a EBS volume. If you can live with a small 10GB EBS, that will only add another $1 per month (remember we are talking about test / development servers).

So for now, I’m back to using AWS for my test servers. It will be interesting if Rackspace and others respond to Amazon’s aggressive move.

I’ve been following the foursquare and gowalla hoopla for almost a year and to be quite frank, it made no sense to me. Why wound I want to ‘checkin’ when I’m at a coffee shop? Just to get points, win a badge and maybe be the ‘mayor’. Don’t get that. Scobles blog post today hit the head on the name with what is missing and has some useful suggestions on how to make this class of app useful. The idea is that your social graph should adjust based on what you are doing. And for this to happen, we need a more sophisticated reputation system.

First of all, I do believe location based services are going to be big. And foursquare and gowalla have gotten some things very right. Specifically, the idea of a checkin process is right on the money. No one wants to have their entire movements recoded and available on the internet (Google Lattitude, I’m looking at you). The user should decide when they want to advertise that they are in a location. What I think both of these services have not gotten right is the motivation for checkin in. People are going to do that because there is a benefit to them. Maybe they’ll get some good advice or tips about the place. In a restaurant, I want to know what’s really good on the menu. And what’s bad. If it’s a store, are there coupons I can use. Now to be fair, one of the problems with being the 1st app o the block, is that without a big user-base most of this doesn’t work. Hence why foursquare and gowalla use gaming techniques to get people to checkin more. I’ve heard businessmen talk about wanting to be the ‘mayor’ of a location on foursquare. Really! To be sure, gaming has allowed foursquare and gowalla to build that initial base. But gaming is not the end goal.

The issue I have is that a badge can’t be the real reward for checking in. These apps needs to give me a real return on my investment. And here is where Scoble’s post really makes sense. He talks about the malleable social graph. What he means by that is that your social graph adjusts based on what you are doing. He gave the example of going to Napa Valley winerys. If you are looking for advice on that topic, your social graph should be adjusted to only include people that have some knowledge of that topic. Maybe they live close by, maybe they are big wine buffs, etc. The point is, you are on a quest (to enjoy fine wine) and you want you social graph to aid in that goal. Right now most social graphs don’t have the ability to make those kind of adjustments.

One thing that Scoble didn’t talk about was the need for a much deeper reputation system on our social graphs. If I’m interested in wine (because I’m in Napa Valley), my social graph needs to know who knows about wine. If I’m struggling with a home repair, my social graph should know who is good at that kind of thing. One thing that foursqare and gowalla could easily do is make their badges meaningful. Have a badge for being a wine lover, another for being good a house repairs. While they are called badges, what they really are is the beginning of a deep reputation system. When I meet someone at a party, you spend the first few minutes getting to know each other. You are basically learning about their background, interests and skills. Wouldn’t it be great if you could immediately see a list of their interests and find out what you have in common. I’m sure I’ve met lots of people that I could have made great connections with if only I was able to find the common links. I remember telling someone I had just met how much I was enjoying watching the winter Olympics. Her response was that she didn’t like sports at all. If I had known a bit more about her, I could have talked about something that both of us would have found interesting.

Hats off to foursquare and gowalla for getting the ball rolling. They are making real inroads into location services. Buts we’re only in the early stages. As far as the technology goes, we have not crossed the chasm yet. Scoble’s thoughts provide some really good suggestions on where we should go next. I believe a deeper reputation system needs to be part of the solution. And the elephant in the room, Facebook, has yet to show its cards (I’ll be going to F8 next month to see if they have anything interesting to announce). Either way, with all the attention this area is getting, I’m sure that it won’t be too long before I start ‘checking in’ to places I visit.

Getting decent broadband internet in rural areas has always been a real challenge. And I’m one who believes that broadband internet is a required / essential service, just like roads and electricity. For all the talk that there has been about equal access to broadband for all Canadians, I’ve yet to see the government do anything meaningful to make this happen though. The good news is that today, there are finally some good options.

I’ve had my rural property for about 3 years and during that time I’ve gone through 3 different solutions. I started with satellite service. It was expensive to install and offered 512K download and 128K up. While the speed was actually almost useable, the latency was atrocious. I was seeing ping times on average of 300-400 msec and sometimes it was worse. Moving from one message to another in my email client had a noticeable lag. Still, it was all that I could get (other than dialup) and I was grateful to have something.

Then last year, I was able to switch 802.11b wireless broadband. A local ISP provider has strung up transmitters on a number of barns and was offering the service. Again, I dished out for a hefty install charge. The result was speeds that were almost the same (400K down and 400K up) but the latencies were very good at under 100 msec. This is actually a very useable service and I really don’t have much bad to say about it. Note, because it is line of sight, the coverage is fairly limited and I was just lucky that there was a barn/tower close to me. A lot of people will not be able to get this kind of service.

Recently my local mobile company (Rogers) has been pushing a 3G broadband solution. Its called the Rocket Hub and even though its a home solution, it’s based on mobile 3G technology. So it’s got a SIM card just like my mobile phone. And the speeds are very good. For the 1st time, I’m getting download speeds that someone in the city might consider calling broadband.

It’s a world of difference and something that is exactly what rural homes need. So while I’ll always be looking for faster solutions, I am now able to be productive whenever I’m at my country property. For anyone in a rural location, I recommend you check out the Roger’s Rocket Hub.

In the tech world, once you have something working, you tend stick with it for a long time. I’ve been using Zoneedit to host my various DNS domains for almost 10 years. But today, I’m switching to DnsMadeEasy.

This is being driven by Zoneedit’s Dynamic DNS limitations. Specifically, when you update the IP associate with one of your hosts, it can take a while before Zoneedit start publishing the new address. In my tests, it was taking over one hour. On top of that, you can not set the Time-To-Live (TTL) on the (A)ddress records. For DDNS, both of these are non-starters. The whole idea with DDNS is that you know your IP address will change periodically. And when it does, you want the world to have the new IP address as soon as possible.

Several months ago, for a service I was creating, I had the chance to use DnsMadeEasy. At a high level, there is not a lot of difference between DNS hosting companies. But sometimes the small differences are important. DnsMadeEasy has a much better web interface that allows you to have fine grained control of your DNS records. And equally important, changes to your zone are live almost immediately. Finally, rather than hosting your domain on just 2 DNS servers, DnsMadeEasy gives you six.

I think I would be more accommodating if I had been using ZoneEdit’s free version but I have been paying for the service. So while I have not been unhappy with ZoneEdit’s service over the years, it’s time to move to something better.