When designing large scale systems, it's very easy to get caught up in details that will result in massive complexity. The most important thing is to remember is to focus on the problem you are trying to solve and keep things as simple as possible. Design your system in such a way that allows easy growth so that when your platform need to scale and adoption takes off you can easily build.

Think about this like Legos or building blocks. Create a system that is modular in design that will allow you to add capacity where you need without adding complexity and tons of iron. If you take the time to design it properly, it will provide the flexibility you need without breaking the bank.

Many different things come to mind when I hear the word “Cloud.” To be honest, the first thing that I think of is this classic Homer Simpson audio clip. My co-founder Frank Addante often said I should write a book and base every milestone or event in my life on some clip from The Simpsons (I guess that is why the show it still going strong after all these years).

In any case, back to reality. Don’t get me wrong, I think the cloud idea is fantastic. Utility computing, capacity on demand, real-time scalability are all great ideas that allow maximum flexibility, provide massive cost savings and allow companies to maximize the computing power amassed over time. The one thing I don’t like about the cloud is that it seems a lot of people are very confused about the concept. I think this is quickly being pushed into the same category as “Web 2.0” and other classics.

My opinion is that simply offering your solution as a SaaS (or Software as a Service) does not constitute “being in the cloud.” While this is an important component to this relatively new way to offer software products today and adoption rates are very high, this is not the sole concept of the cloud. I think the company rPath does a good job at laying out the base components needed for adoption of the cloud computing model.

Here's the moral to my post. Whether we have the terminology right or wrong, the goal of the cloud is extremely promising. Being an infrastructure guy, I salivate at the opportunity to architect, deploy and manage such systems. I love scale, high capacity, on-demand access and repeatability/reusability. It is also exciting to keep pushing our own technology to allow our customers more flexibility when they deploy (whether software, hardware or virtual appliance).

I read an article today about how email addiction can be a sign of mental illness. This was certainly an interesting article that I enjoyed for several reasons:

1. It shows that people are relying more on email communications than ever before as a means of keeping in touch
2. It showcases the importance of the right message at the right time (quality of the message not quantity of messages)
3. I think Frank and I picked the right business to be in!

In all seriousness, mental illness of any kind is tragic. However, the article does demonstrate the impact the email has on our everyday lives. I can tell you first hand that email is addictive. While I don’t personally experience withdrawal symptoms when I'm away from email, I am usually glued to my mobile device, and I am always online. Mental illness aside, the article reinforced my belief that email is never a game of “more is better.” Content is king, but it has to be meaningful and sent to the right audience. Otherwise, it’s just a bunch of data moving from one hard drive to another.

I read an article the other day that referenced StrongMail, and the topic was around sending speed. While it is true that you can send over 1 million messages per hour with StrongMail, you also have to realize that with great speed comes great responsibility. I’ll get to this last point in a second.

First, I agree with many of the points in the article. It is very important to have an email platform in place that is capable of not only sending but generating millions of dynamic and personalized messages for rapid-response situations such as alerts, quotes, notifications, reminders, ecommerce, etc. For those applications, you need to have a system that will allow rapid and dynamic scale when needed without having to add a lot of extra iron in the data center.

On the other hand, if you’re sending millions of messages really fast, you need to understand that your delivery is largely (if not solely) based on your sender reputation and how the ISPs view you at the time of send. This is why it is critical to have a Message Transfer Agent (or MTA) that gives you the ability to adhere to the sending rules the ISP’s have in place at any given moment in time.

When we built the StrongMail platform, we knew that in addition to speed, we needed to build in the control to follow best practices and send email in the way ISPs like to receive it. Offering both together allowed us to provide companies with the flexibility, control and visibility they need to see in real-time what is happening to their email streams and act accordingly.

Let’s face it; the reason companies send email is because, when done properly, it is a very effective and immediate communications medium that can create valuable customer relationships. However, when done improperly, email can cause brand degradation and reduce customer loyalty.

That’s why when it comes to email, it’s important to act responsibly. Just because you can send a million messages an hour, doesn’t mean you should.

In terms of technology, it's amazing how much progress we've seen in such a short period of time. With all the wonderful technology that exists today, I can now plug an IP phone into any decent broadband connection and conduct business like I am in HQ, when, in fact, I might be thousands of miles away. It's also amazing how important email has become to life and business. Whether it’s corp-to-corp email servers like Microsoft Exchange or world-class, on-premise outbound email servers like StrongMail (shameless plug), most modern businesses would be hard-pressed to live without it.

As I write this blog, I am also dealing with an internal Microsoft Exchange issue, and, even though my IP phone is handy, it can't compensate for the utility and effectiveness of email. Fortunately, we have email continuity in place, DR plans and full backups, because my preferred way to get and process information is email. The days of a simple phone call seem long forgotten (if not even preposterous for me to suggest). When Exchange went down and the back-up system was coming online, I actually heard people say “you mean I have to call someone to setup up a meeting?” as if to say that is the craziest idea they have ever heard.

As painful as an Exchange outage can be, losing your enterprise transactional email capabilities could cripple your ecommerce efforts. That's why trusting the emailing of order notifications and password reminders to your shopping cart system is never a good idea. These systems are designed to process online orders, not send email.

Email is certainly here to stay. It is an extremely important and effective communications tool , and it is growing by leaps and bounds every day. It seems like nearly everyone is rushing to buy the latest and greatest smart phones to get “on-the-go” access to web-based email like Gmail, Yahoo and Hotmail and to connect to their corporate email. As the founder of an email company, this prevalence and reliance on email would seem to indicate that I'm in the right business and not just drinking the Kool-Aid.

Respectfully yours,
Tim “email is life” McQuillen

It has been great times over the past 5+ years since founding StrongMail. I found out that Frank is now an aspiring actor. I often wonder “is there anything he can’t do?” so I thought I would share this great little vignette about his new company called The Rubicon Project. Enjoy.

The major issue with email is that it has expanded far beyond personal communication. The systems needed today require a lot of functionality with little to no maintenance and resources to run them. In the beginning, it was important to focus on rapid scale, deployment and ease of use; starting first with the method at which email is delivered.

A majority of the software that existed at the time could always get you started but was traditionally very hard to scale without adding a lot of additional hardware and bodies to run it. The most important part was not only sheer speed but also the flexibility and control needed to build and deploy email applications.

When we started StrongMail, we realized that an ASP model would be impractical to deliver everything customers wanted. So rather than focus on only building a world class MTA, the decision was made to build an application server to allow rapid development and deployment (mind you, this decision was made over time and out of necessity for what we needed to support our customers).

The two main pieces consist of EAS (or the Email Application Server) and the MTA (or the Message Transfer Agent). Traditional terms are closer to a “client/server” model where each can act in unison with one another or with “n” number of systems for scale. Again, only focusing on building an MTA was not the full solution. Sure, the MTA needed to be very fast, but it also needed all the necessary dials and knobs to allow customers to control their email streams according to their business. Email goes far beyond that. It was also vital to give customers full visibility into what was happening with their email and most importantly allow businesses to make decisions in real time to take corrective action.

SPAM, viruses and phishing attempts have greatly changed the way we conduct transactions today, so it's important to have a platform that demystified the problems and allows companies to take control. Email has gone far beyond “batch and blast” methods of the past, and there are very real metrics tied to email communications and delivery. Companies can spend more time focusing on what is core to their business and not building email infrastructure. This is why StrongMail was created. To produce world-class, on-premise infrastructure to allow customers to optimize the way they do business.

It is funny how things progress in life. While attending college in Texas I was the person the IT guys hated. It never failed that whenever I entered a computer facility things usually ended up with smoke and a lot of expletives. I seemed to have the wonderful knack of breaking anything I touched that was computer related. After graduation, I moved to California and started a recruiting business with a few buddies. This is where I learned my first little bit of technology (it was out of necessity and cheapness). Plus it also helped me vet candidates before sending them on interviews. That skill led me to a company I still have a lot of respect for today and responsible for helping me grow the skill set that allowed me to co-found StrongMail. The company was called L90 and the technology we delivered was call adMonitor. This was an advertising and email platform we ran as an ASP and the company did extremely well. We had well over 3000 blue chip customers, a super team, and excellent technology. At our peak we were serving well over 8 billion transactions a month and chomping at the heels of DoubleClick.

When I started with L90 I was doing corporate recruiting to help reduce the amount of fees that they were spending on hiring talent in a very difficult market. After roughly 4 months of doing this and meeting my partner in crime (Frank Addante, who was the CTO and founder of L90, serial entrepreneur and pretty much the most driven guy I have ever met) I feel he quickly saw a skill in me that I wasn’t even sure I had. I started to run IT operations having no prior knowledge in this industry and then within a few months started building out the infrastructure that enabled our billions of transactions. The coolest thing about doing this was the challenge and scale. The entire industry used a system called Keynote to track competitors’ availability. High-scale and redundancy were a must.

So how did this all lead to founding StrongMail you might ask? It’s simple. At L90 we relied on many systems to produce results and they were a nightmare to maintain. I only had a staff of 2 people and we had a ton of gear (close to 800 systems). The challenge we had at L90 was it took many programmers to write custom code to allow our customers the flexibility to do what they desired. It also took a lot of hardware to run open source software (we used Sendmail) and that technology was really intended to run corporate email like Exchange. I love open source and we used it anywhere we could but it just was not designed to meet the needs of the outbound email and delivery. We parlayed the challenges we learned by running a very successful business and realized there was a gap in the market (at least we were hoping there was). Building this stuff is not easy, its takes a lot of time and effort and it is hard to scale. In my next entry I will discuss the problem itself and how we address it at StrongMail.