I'd like to introduce you to James “Yes, that's my real name” Koole, our new Communications Specialist. He's  helping out with the booth and presentations at ISPCON, the premier conference for internet service providers, hosting services and VOIP providers, currently taking place in Orlando, Florida.

He's a little busy right now with the usual running around that conference-atennding involves, so he's asked me to post this entry about maintaining customer relationships in his stead.

Take it away, James!

---

As a newbie here at Tucows, I’m making the rounds at my very first ISPCON in an effort to get the lay of the land, so to speak. If there’s a theme I’ve picked up in the various sessions and keynotes I’ve taken in, and in my discussions with numerous vendors on the show floor, it’s this: building and maintaining a relationship with your customer is critical to business success.

Mike Cassidy, Marketing Manager for ISP-Market, took his audience through a rapid-fire presentation, The Hottest Value-added Services for 2007 and Beyond. In it, he threw out multiple areas and opportunities where consumers were looking for services that ISPs were ideally positioned to provide – from VoIP, to home monitoring systems, to small business IT infrastructure management. Cassidy pointed to the relationship with the customer as a critical tool in identifying potential new revenue streams. The concept was simple – engage the customer and develop a relationship, and then simply ask the customer what they want.

He also talked about how that relationship resulted in what he called a “trusted advisor” status for the ISP. Customers have problems they need to solve, and they want to be able to just hand it off to someone they trust. The customer relationship is key in building that level of trust.

Engaging the customer on a human level and building a relationship that goes beyond a faceless company providing a package of services has immense value. Happy customers become evangelists for your business, handing out that all-important word-of-mouth advertising that can’t be beat.

And now, for something completely different: a little squishycow juggling! I met this guy while attending RailsConf, O'Reilly Media's conference for Ruby on Rails developers. I'll post my report on the conference soon, but in the meantime, a little juggling for your Friday enjoyment:

For your viewing pleasure, we've posted a larger version of the screencast (it's a QuickTime video) from yesterday's article, Introducing the Next Generation of Tucows' Email Service off our new and improved Tucows Email Service. Click the image above to watch it!

[Updated May 24th, 2007: We've included a link to a larger version of the screencast.]

Today is a big day. We’re thrilled to announce the next evolution of our Tucows Email Service.

Building on our experience providing millions and millions of mailboxes to service providers around the globe, we’ve made a number of innovations in this latest version that have resulted in a truly outstanding hosted email service.

The first is our back-end technology that has been designed to provide rock-solid reliability, the ability to grow to meet demand from our customers and their end-users, and for easy integrations.  You can read about “what’s under the hood” of our email service in an earlier post by Joey.

And of course, we’ve built our service from the ground up to meet the needs of service providers. It includes a web-based branding tool so a service provider can take our completely white-labeled service and make it his own. It also has additional tools for our Tier II Support team, meaning speedier resolutions, often at first call.

Our most significant development is in our new web mail interface (POP and IMAP are available too.) By working with Nitido, we have developed a web mail interface that competes with the leading free web mail providers.

I believe showing is better than telling, so we did a short screencast to introduce you to our new webmail. A small version appears below, and you can click here to see a larger version [QuickTime required].

You can read more about the new Tucows Email Service over on our site.

If you’re an existing customer, please log into the RRC or RWI  to gain access to our Test environment where you can evaluate the service. If you’re a new customer please contact our Sales team.

We believe service providers have a unique opportunity to offer our web mail to their customers. When matched with Tier I customer support it becomes a retention tool, not just an after-thought when bundling services.

We all know email is a highly-“sticky” service. Thinking about my own email usage, I have an ISP that I have used since university for my personal email (yes of course, they are a Tucows reseller ☺), I also have a handful of free web mail accounts that I use for personal email, subscriptions, and while traveling and away from my home and work computers.

Until the advent of next-generation AJAX-based web mail I always pop’d my email through Outlook or another local mail client. For me, regular use of web mail wasn’t an option. It was too clunky and slow and didn’t give me the features I needed to manage my personal information.

Of course that’s all changed. And I think Service Providers have an opportunity to use competitive web mail as a value-added service.

It seems like a no brainer to me. Service Providers are running email anyway, and by offering a competitive web mail experience, you can reduce your support costs by not having to explain POP or IMAP setups for every individual. You can just set them up, point them to the web and be there to support them if they have any issues.

The numbers show web mail use is on the rise. According to Charlene Li of Forrester, the number of users who use web mail once a week is up 4% from 27% to 31% in just one year. That’s a big jump, and I think we can attribute that to the increased use of the free web mail services.

As web hosting companies and ISPs look to retain customers, offering competitive value-added services like our web mail is a an opportunity to leverage leading-edge technology without making the upfront investment in development and ongoing investment in running an email system.

So, check it out, we're pretty excited, and we hope you like it!

Our HQ in Toronto will be operating with reduced staff on Monday, May 21 for Victoria Day. Tucows Support and the NOC (network operations center) will be fully-staffed. Our Payment, Sales, Compliance and all other departments are closed Monday. Our normal hours resume on Tuesday, May 22. Have a safe and happy long weekend everyone!

A New Way

One of the most important developments at Tucows in the past several months is a change in the way we develop the software behind out services. Over time, the software has become more complex, the number of users has climbed, the time-to-market has shrunk and changes to the internet have accelerated. We've had to change the way we write our software, and in the next couple of articles, I'll cover these changes.

The Waterfall Model

Let's consider a classic software methodology — one that's still in widespread use today, and one that was, until recently, the way we used to develop software here at Tucows: the waterfall model of software development.

The waterfall model takes its name from the fact that it views software developments as a set of phases that a development team goes down in a cascading fashion, like water going down a waterfall. In the waterfall model, you start at the first phase, and move on to the next one as soon as the current phase is complete.

The number of phases in a waterfall will depend on which software engineering text or site you consult, but they can be generalized to these five:

1. Requirements: In this phase, the developers communicate with the customers and users to find what they the application to do, analyze those requirements for contradictions or conflicts and resolve them, and turn the resulting requirements into requirements documents — some form of documentation on which the developers will base their design.
2. Design: Based on the requirements documents produced in the preceding phase, the developers create design documents, which act as the blueprints for the application to be built. If the requirements documents specify what the application will do, the design documents specify how the application will do it.
3. Implementation: In this phase, the developers build the application, using the design document as their guide.
4. Verification: Once the application is complete, it goes to the verification phase, where the application is tested to make sure that it meets the requirments and is free of errors. Once the application has passed the verification process, it is released.
5. Maintenance: Software that has been released is in its maintenance phase, during which time it may be modified or updated to meet new user needs, made compatible with other systems or to correct errorsnot detected during the verification phase.

Upsides and Downsides of the Waterfall Method

The waterfall model is a manager's dream. By compartmentalizing the devlopment cycle into distinct phases, it makes it easy to break a software development team into departments, which in turn makes it easier to maintain managerial control. The waterfall cascade also aligns quite nicely with Gantt chart-style planning.

It's also a developer's nightmare. It fails to account for certain realities of software development, one of which is that things change. As the application is being built, there can be all sorts of reasons for making changes to it, including:

• Unforeseen requirements that could not have been anticipated early in the development lifecycle
• Changes in the customer's business or the regulatory environment in which the customer works
• Changes or limitations in technology that take place or are discovered during the project
• It's often hard to specify every last requirement before seeing any working code (hence the customer dilemma most developers have face: “It's what I asked for, but not what I wanted!”)
• Often, an initial design will is not adequate to the task that the application is supposed to perform

The waterfall model is a poor fit for software development because it's no good at solving wicked problems.

Software is a “Wicked Problem”

The term “wicked problem” was coined in 1973 by Horst Rittel and Melvin Webber; they used the term in a paper on social policy planning.

A wicked problem is one that cannot be solved by planning; rather, it must be solved by actually going through the process of trying out solutions. This is because wicked problems have the following characteristics:

• They're not truly understood until you try and come up with a solution.
• They have requirements that are often incomplete, contradict each other, and are subject to change.
• Wicked problems contain all sorts of complex interactions that may not be well-understood or seen at the beginning.
• The solution of one of the aspects of a wicked problem may reveal or create another, even more complex problem.
• Stakeholders have radically different world views and different frames for understanding the problem.
• Constraints and resources to solve the problem change over time.
• The problem is never solved.

Although Rittel and Weber were working in the field of sociology, wicked problems are encountered in many other areas of study, including software development. The process of developing software has the same characteristics as a wicked problem, and because of this, many developers feel that the waterfall model addresses only the management issues of software development and not its “wicked problem” characteristics.

Luckily, there are other ways to develop software, and we've adopted them. I'll cover them in the next article.

Tucows is looking to change the way customers sell our services. Over the past few months, my team and I have been challenged to update our enabler offerings. We have focused on developing tools that can be easily integrated into existing sites while remaining upgradeable. Looking back at the enablers we have provided in the past, we have a good idea of what has worked and what hasn’t. As we look for the new direction for enablers, let’s take a look at some of the solutions we have provided in the past and discuss where we would like to go in the future.

The Past

While the Reseller Code Library (RCL) provided a quick integration method for registering, renewing and managing domains, for most of you, selling a domain is no longer the primary goal. You need to integrate the registration of domains into the sales process for web hosting, email, or ecommerce applications. Many customers have found themselves tailoring a domain registration system to bill for services that were recurring, sometimes going as far as only offering yearly hosting plans so that renewal coincided with domain renewals. As RCL evolved, upgradeability became an issue. As Tucows offered enhancements to RCL, many customers were slow to adopt new versions as it required them to reintegrate with each release.

In an effort to provide a modern interface in an upgradeable package, Tucows introduced the Client Code Suite (CCS). CCS was designed so that modules could be turned on or off via a configuration file. It provided hooks for billing applications and upgradeability that was missing in the RCL. However, CCS was too complicated in many ways. It was too difficult to install, too difficult to modify and most of all, too difficult to integrate into your existing business.

We provided an application that while may have worked out of the box, provided no more functionality than that of RCL and required a skilled developer to modify.

Both RCL and CCS suffered from “Center of the World Syndrome”. This syndrome caused us to believe it was our responsibility to define the way you would run your business. Both RCL and CCS believed that they were in charge of the domain registration process and everything that went with it from provisioning to billing. The problem was that neither provided customization without a price.

The Future

When you consider the “Center of the World Syndrome”, it is easy to see what Tucows should provide. Our customers have business models that don’t consist entirely of the sales of Tucows services. We provide just a piece of what you are offering and we feel like that is the direction for pre-built enablers as well. That is why we are looking to distribute “pluggable components” for each Tucows service.

Our Component Goals:

• Pluggable – Provision services on your existing site with just a few lines of code
• Integrated – Add the provisioning into existing processes such as the sale of hosting
• Upgradeable - Take advantage of the latest Tucows innovations without having to modify the integration.

Both RCL and CCS will be phased out. RCL hasn’t been updated in more than a year and will only remain until the new components are available. CCS will be repositioned as a Platypus only product as it has already been integrated with the Platypus web interfaces.

Your Feedback

We are excited about our new approach and will be relying upon the community for feedback once the tech preview has been created. When the tech preview is nearing completion, we will be looking for customers to participate in our labs program to provide feedback as to how the new components fit into their existing business model. We look forward to you being a part of the new direction for enablers.

We'll be at ISPCON Spring 2007, the premier conference and educational event for internet service providers and hosting services. ISPCON Spring 2007 takes place May 23 - 25 at Rosen Centre Hotel in Orlando, Florida.

In addition to our regular booth (we'll be at booth 509), we'll be hosting a vendor session: “In Conversation with Tucows”, where you're invited to join us for an informal presentation and chat with these Tucows movers and shakers:

• Elliot Noss, President and CEO
• Ken Schafer, VP Product Management and Marketing
• Kim Phelan, Product Management

As I mentioned in the title, these folks are the top brass here at Tucows. If you've got any questions about the company, its services or its strategy for facing the evolution of today's internet, these are the people to ask, and our vendor session will be your chance to ask them.

Back in March, we reported that .mobi domain names had hit the 400K mark. The dotMobi registry announced this week that they've now crossed the 500K mark:

dotMobi, the registry for .mobi domains, today announced that 500,000 .mobi domains have been registered in 104 countries since the domain's commercial launch in October 2006.

…

Many auto brands, such as bmw.mobi, ferrari.mobi and rolls-royce.mobi, news and entertainment players such as espn.mobi, maxim.mobi, foxnews.mobi, businessweek.mobi and cnnmoney.mobi and mobile operators including Telecom Itali mobile division TIM and Bulgaria's Vivatel, have all registered .mobi domains, says the company.

“The results demonstrate the strong role dotMobi is playing in driving the creation of mobile content on the Internet,” says Neil Edwards, CEO of dotMobi. “Most importantly, the mobile industry's consumer focus around creating .mobi sites is bearing strong results in a short period of time. Consumers finally have easy-to-use and affordable made-for-mobile content.”

In a few weeks, the new and improved Tucows Email Service will be promoted to the “Horizon” test environment, which will allow our partners to provision and manage test email accounts on this new system, either manually using the Reseller Web Interface (RWI) or programmatically using our API.

In anticipation of this promotion, I had an informal chat with two people who understand the new email system inside and out:

• Our Director Technical Operations and Planning, Rick Yazwinski
• Senior Systems Administrator Andrew Chasse

We spent an hour talking about the new email system, its underlying technology and the processes they used in its development. I've distilled our conversation into a series of articles in which I'll cover different aspects of the new Tucows Email Service.

Executive Summary

For the benefit of those of you who are pressed for time, here's the Executive Summary:

• The new Email Service was built from the ground up with the goals of being scalable, reliable and capable of handing a large number of mailboxes.
• It runs on Xen virtual machines — software constructs that emulate computers, complete with their own processor, RAM and disk space.
• If you look at only one diagram in this article, look at the one titled The Layers of Tucows' Email Service.
• Our use of virtual machine technology gives us three big advantages:   
         
  1. Faster development time
         
  2. Scalability
         
  3. Reliability
     

A Little Background

As our CEO Elliot Noss stated in our most recent podcast, email has become orders of magnitude more important than it used to be:

What has been clear to me is that the reliance that people, both individuals and businesses, now place on email in so many aspects of their lives has just taken it to a whole new level in terms of importance. So, just when you thought it couldn't get bigger, it did!

It was decided that our email service needed a complete overhaul — a from-the-ground up re-engineering in order to create a system that would allow us to provide superior service to our existing customer base and also scale to meet future needs. In order to do this, we created a “tiger team” whose sole objective was to build this new system — and under a very agressive timeline. The team would be given its own working space separate from our main offices complete with freedom for everyday office interruptions and free reign to make their own choice of technologies and working methodologies. In exchange, the team would have to deliver results in a span of time that many companies spend just generating a requirements document.

Among the goals set for out tiger team were:

• First and most importantly, the new email system had to be scalable and reliable
• It would have be capable of handling a large number of mailboxes (on the order of at least several hundred thousand, at the very least)
• It must work with our Email Defense service (Tucows' anti-spam and anti-virus system for email)
• It must support the provisioning and management of email accounts, both programmatically (via the API) and through a web-based interface (the RWI)
• It must be extensible to incorporate features that we'd like to integrate into our mail service, such as our Kiko calendaring system
• It must offer a webmail interface
• Migrations to the new system should be relatively fast and easy

I'm pleased to report that the tiger team succeeded: not only did they meet the specified goals, but they did so in the very little time they were given. Their success gave us not only the email system that you'll see in a few weeks, but also a blueprint for the future of software and services development here at Tucows.

Virtual Machines

One of the interesting things about Tucows' new Email Service is its use of virtual machines. If you're not familiar with the term, don't worry; I'm going to spend a little time explaining what they are.

You've probably encountered virtual machines before without realizing it. Virtual machine technology is what makes Java applications “write once, run anywhere”.

Without virtual machines, a programmer would write a program for a specific platform, such as Windows, Mac OS or one of the many variants of Unix. Such a program would be written for that platform's specific APIs, using the preferred programming language for that platform. These days, any platform's APIs are quite complex and take a while to master, which is why writing software for more than one platform is difficult and time-consuming.

From a programmer's point of view, a virtual machine offers the ability to write cross-platform software while requiring the programming knowledge for a single platform. That's because the virtual machine is the platform that the programmer targets. The virtual machine itself is written for several platforms, and as long as a virtual machine is written for a specific platform, the developer can target that platform without having to know anything about programming for it. The virtual machine acts as an interpreter between the programmer and the platform. Virtualization allows a programmer to write a single application that will run on a number of different platforms.

Tucows Email's Virtual Machines

Tucows Email Service makes use of virtual machines. Like the Java Virtual machine, they are pieces of software that emulate a platform. However, rather than being a facility to allow “write once, run anywhere” programming, the virtual machines we use are a way of allowing us to quickly and efficiently deploy email servers.

We make use of Xen, virtualization software that makes it possible to simultaneously run a number of operating systems on a single machine, each one having the appearance of running on its own computer, complete with its own processor, RAM and disk space. Ideally, you'd want to run such a system on a powerful server-grade machine, as its resources would be divided among the virtual machines running on it.

When you connect to the new Email Service — either via your favorite email software or through the webmail interface — you're connecting to one of the virtual machines. As far as your computer is concerned, it “thinks” it's connecting to an actual physical machine that's providing email service. In fact, it's connecting to software that emulates a machine that's being used as an email server.

Xen virtual machines are managed by the Xen Hypervisor software, which runs on the physical server machine and divides its resources among the virtual machines running on it. The physical machines on which we run Xen are Sun X4600 servers with 4 dual-core AMD Opteron processors, 16GB of RAM and high-bandwidth network interfaces, which provde plenty of computing power to be distributed to the various virtual machines.

Advantages Gained from Using Virtual Machines

At this point, you might be wondering why we're making use of virtual machine technology in our Email Service. It boils down to three important points:

1. Faster development time
2. Scalability
3. Reliability

Let's look at each of these points.

Faster Development Time

Consider the typical development cycle, which can be thought of as being divided into four phases:

1. Development: In this phase, programmers write the application.
2. QA: Quality assurance staff take the code from the developers and subject it to a battery of tests.
3. Staging: Once the application has passed its quality assurance tests, it’s placed on a staging server, which is meant to approximate the actual conditions (such as the hardware platform andthe demands made on it) under which it will run.
4. Production: After the application passes the stagingtests, its placed on the production server and is on active duty.

One problem frequently encountered when moving application from one phase to another in the cycle is that it often “breaks”. It may have worked on the developers' machines, but once installed on the QA machines, it starts coughing up error messages. The same can happen when the application is moved from QA to Staging, or from staging to production.

The reason this happens is that the computers used in each phase are different. Even if they all have the same version of the same operating system installed on all of them, differences creep in over time as different software packages are installed on them, or as they undergo regualr maintenance and updating. In a software development and production environment, it's hard to keep different machines “in sync”.

The ideal situation would be to use the same machine in all phases of the cycle. The developers could write the program, then pass their machine to the QA team, who'd run their tests on it. Then QA could pass the machine to the staging server phase, where the technicians would plug the machine into the staging server network connection and the staging tests could be performed. Finally, the machine would be passed to the production phase, where technicians would plug the machine into the production server network connection.

The ideal situation is impractical, but virtual machines give us the next best thing. The developers, rather than working directly on their machines, would do their programming within a virtual machine environment running on their own computers. When it's time to pass the application to QA, they would not just save their application, but the entire virtual machine and pass it to QA.

QA would then take the virtual machine and run it, then run their tests on the developer's application within that virtual machine. Once the application has passed QA testing, its virtual machine would be saved and then passed to the staging phase, and after that, the production machine. Passing a virtual machine from phase to phase is the next best thing to using the same machine in all phases of development, and it's also more practical.

By using virtual machine technology in the development cycle, we eliminate the problems involved in moving between phases, which shortens development time and means that we can deliver updates more quickly.

Scalability

As demand on a service increases, more processing power is required. Typically, you add processing power by adding more servers.

The problem with adding more servers is that it's more than just plugging in new machines. There's a lot of setup involved, from installing the operating system to the applications to the run-time software and libraries required by the applications, and then there's a matter of testing the setup itself.

Since we're running our email service on virtual machines, and since the virtual machines are software, this means that adding new servers is considerably quicker and simpler. We simply copy our existing virtual machines — which have already had the software set up on them — onto new server hardware and run them.

This sort of setup also allows us not only to set up new server quickly, but to also make arrangements for short periods of extra server demand. It would be possible for us to deploy additional email server power for a few hours or a few days when needed by leasing additional server power and installing our virtual machines on it.

Reliability

An unavoidable reality in our line of work is that sooner or later, we're going to experience some kind of hardware failure. Perhaps a server machine will fail, or perhaps a server farm will be rendered offline by a network or power failure.

Xen virtualization technology lets us work around these problems because as software, it's easy to copy a virtual machine from one physical machine to another. Since our server machines can notify us that they're beginning to fail, we can copy a virtual machine from a failing server to a working machine.

Better still, the users shouldn't notice any downtime while this is happening. Xen can keep a virtual machine up and running even as it is being copied. A virtual machine in the process of being copied keeps running on the source machine until the last moment, when control is transferred to the destination machine.

Conclusion

It's not just a new email service, but it's running on a whole new platform. Our use of Xen virtualization technology allows us to deliver new services and upgrades faster, and allows our services to scale better and operate more reliably. We're looking forward to the launch of the new Tucows Email Service, and we think you'll be pleased.