SaaS -- Software as a service is a model of software deployment whereby a provider licenses an application to customers for use as a service on demand. SaaS software vendors may host the application on their own web servers or upload the application to the consumer device, disabling it after use or after the on-demand contract expires.

Think of this as the traditional ASP model from the Dot-Com boom. This is merely the act of offering a software solution such over the internet and charging fees for users per month (eg. salesforce.com).

PaaS -- Platform as a service is a runtime-system and application framework that presents itself as an execution environment and computing platform available over the Internet with the sole purpose of acting as a host to application software.

Think of this as the actual application framework that would run a SaaS platform that provides the technology stack (eg. Google AppEngine).

IaaS -- Infrastructure as a service is the delivery of computer infrastructure (typically a platform virtualization environment) as a service. The big push of virtualization technologies such as Xen, VMware, Hyper-V, KVM and others have really helped this category flourish.

Think of this at its most basic element of providing the actual physical (however in this case its virtual) resources like RAM, CPU, storage to run the application and platform (Amazon's EC2/S3, Rackspace Cloud, Terremark Vcloud, etc).

Now how do all these things fit together (or do they)? First these can all be used independently or together. For instance we have salesforce.com here at StrongMail to help run sales and support. We also use The Rackspace Cloud to fulfill the infrastructure for our Cloud offering. They are mutually exclusive to each other. These can however be used together and here is a simple diagram on how they interact and who would be interested in each layer. I hope this has been helpful.

Thanks to saasblogs.com for the picture.

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.

PS...The video was filmed a bit choppy so don't think it's your ISP. :)

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).

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.

The original email and Internet systems that we know today weren't invented by Al Gore, but by our own government missile defense system group called the Advanced Research Projects Agency (ARPA), whose primary job was to handle research for all space and strategic missile research. NASA was then formed, and the activities of ARPA moved away from aeronautics and focused mainly on computer science and information processing.

One of ARPA's goals was to connect mainframe computers at different universities around the country so that they would be able to communicate using a common language and a common protocol. Thus the ARPAnet -- the world's first multiple-site computer network -- was created in 1969. In order to have an account on these systems you simply asked for one and they just gave it to you almost without ANY questions, completely overlooking security and accountability.

Well, obviously, as time went by and the systems got larger and more interconnected, some people figured out the vulnerabilities and started to send out the first of many billions of unsolicited messages now known as SPAM. The question now comes down to how we can possibly patch a hole this big. Email authentication technologies like DKIM (DomainKeys Identified Mail) are a start.

DKIM is a signature/cryptography-based sender authentication protocol developed in order to address the problem of forged email messages (missing security and accountability) and to allow an organization or individual to take reasonability for the message it sends, which has given rise to the concept of email reputation. Now, I won't bore you with the details of email reputation and authentication, but I do want to focus on why we got involved in this early on.

Email is now about as mainstream as any technology can be, yet the viability of email is continually being threatened by viruses, spam, spoofing, and phishing. All of these threats are shaking the confidence in email as a viable tool for communications and conducting business, and StrongMail is committed to help protect it. We have been participating in the DKIM standard since day-one, and we are proud to have our own employees acknowledged for their hard work in the standard.

StrongMail was the first technology provider to integrate support for all emerging authentication protocols into its outbound email products to simplify compliance with whatever standards are mandated. DKIM has since gained a lot of traction, and AOL, GMAIL, and Yahoo! now use it successfully in production.

Unless you're a member of the CIA, a Matrix super fan, or a cryptographic expert, signature-based authentication can be difficult to understand. In StrongMail, you don't have to think about any of that stuff, since we make it as easy as 1-2-3 with our step-by-step interface, which will either create, upload, or use the existing keys needed to properly sign and verify any email.

In fact, StrongMail is specifically designed to make it easy to work in the complex and ever-changing world of email standards. You even have the ability to apply authentication to certain email streams or campaigns based on your needs. Our offering is so simple that anybody with a mouse, keyboard, and monitor can institute email authentication.

Overall, DKIM brings accountability to the sender, establishes a reputation and confirms whether they should be sending email from a certain domain. By doing this, receivers can better separate mail streams from those who are good and those who are bad, which enables better anti-spam technologies and reduces false positives.

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.

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

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.

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.