There are many ways you can easily implement an SMS service today, each with its own pros, cons, and idiosyncrasies. Some implementations are more suited to certain types of services than others.
In this final section we'll consider six ways you might implement an SMS service: aggregator, smartphone, email, Twitter, 411Synch, and Windows Live. There are, of course, many other options. Table 6-1 lists the six implementations we discuss, the type of service for which each is suited, and their relative cost, complexity, and scalability.
Cost | Service types | Complexity | Scalability | |
---|---|---|---|---|
Aggregator | High | All | Moderate | High |
Smartphone | Moderate | All | Moderate | Low |
Windows Live | Free | Notification | Simple | High |
Email to SMS | Free | Notification messaging | Moderate | Low |
411Sync | Free | Lookup | Simple | High |
Free | All w/quirks | Moderate | Moderate |
Let's look more closely at the four factors that determine the best use of each implementation type: cost, service type, complexity, and scalability.
Cost
There are several free options (or at least no incremental cost beyond hosting a web service). The two options that involve money are smartphone, which can cost as little as $200 or $300 at start-up and a $40 or $50 monthly fee for the phone service, and an SMS aggregator, where you will end up paying anywhere from 1.5 cents to 8 cents per message, inbound and outbound.
If you are experimenting and prototyping, you may wish to design your service so that you can take advantage of a free service in the early stages, then swap it out for a more robust but costly service at the appropriate time.
Service type
Some implementations come with inherent constraints that may make them unsuitable for certain services. For example, it is difficult to initiate an email service from a mobile phone (although replies are generally simple). This makes it a poor choice for a look-up service. The Windows Live service only supports MT messaging, making it inappropriate for anything but notification services.
Complexity
Don't discount the value of simplicity. None of the implementations we describe here are highly complex, but some are certainly simpler to implement than others. However, what's easy to one person may be complex to another, depending on your existing knowledge and skills. For example, one of the authors of this guide had a background in C# and Windows applications, while the other was more familiar with Python and Linux/Apache-based solutions, meaning what was simple to one was complex to the other.
Scalability
There are two low rankings in the scalability column in Table 6-1: smartphone and email. The bottleneck for a smartphone implementation is that it can only handle approximately 30 messages per minute. For email, the bottleneck will be set by the carriers, which will attempt to detect services running against their gateways and may block messaging temporarily in an attempt to limit spam.