Merce Broadside is designed to be deployed as part of the customer’s IS infrastructure. It is designed to serve large customers with multiple departments, and can operate as a shared resource with separate teams administering their parts of the system.
Setting up Merce Broadside is not a five-minute job. The product can only do its job if infrastructure is properly set up, and this infrastructure setup has many components. It would be so tempting if the customer did not need to do all this, and could enjoy the power of the product in a SaaS environment.
Well, this is certainly possible, but within limits. A small setup for relatively smaller volumes of emails per day (say, 100,000 messages) is easy to operate as a hosted service. We offer such services. For larger customers, more care needs to be taken.
The primary constraint is the connection between the back-end applications which generate the emails, and Merce Broadside which transmits them. If this data volume increases, a thick pipe is needed between the back-end data centre and the one where Merce Broadside is hosted. For time-critical applications, messages are pumped at high speed in real time from back-end application servers to Merce Broadside servers. The advantages of uploading files in compressed batches are then not available.
We are in talks with one financial institution which hosts their main business applications on servers in an IDC. This financial institution intends to deploy Merce Broadside in the same data centre, allowing for data upload as fast as any local in-house data centre. The hosting service provider, NetMagic Solutions, has suggested that we apply to APNIC for an ASN and a set of IP addresses for the Broadside installation — they appear to be hesitant to carve out a chunk of IP addresses for us from their own pool.
At the other end of the spectrum are customers who wish to use Merce Broadside hosted on Amazon EC2 instances. IaaS cloud infrastructure appears to be ideal for Merce Broadside, since the CPU load and disk I/O traffic are both bursty — they ramp up when a batch is being blasted through the system, and die down as soon as the bulk of messages have been transmitted. Merce Broadside has worked well on Amazon EC2, but for smaller customers. Amazon EC2 did not permit one installation to use more than one public IP address, and email transmission improves if the traffic is spread over multiple transmitting IP addresses (the IP spreading feature of Merce Broadside delivers exactly this). However, batches smaller than about 100,000 emails are not a problem on Amazon EC2. EC2 has decided to offer multiple public static IP addresses now for a single virtual machine, starting 7 July 2012. We will see how this works with Merce Broadside hosted instances.
We did some digging about cloud hosting adoption among enterprise-level organisations. We found that most large organisations in the US (in terms of number of servers owned and operated) appear to host in-house applications in in-house data centres. Third-party data centres host their (i) Internet facing applications and (ii) DR setups. If this trend continues for a few more years, our recommendation will be to host Merce Broadside in your in-house racks if you wish to deal with more than a million emails a day.
So, we can work with you in any model you prefer. Besides a traditional product-licensing model, we also offer Merce Broadside on Amazon EC2 with quarterly billing and zero lock-in. For large volumes, just ensure that your back-end application servers are in close (network) proximity to the Merce Broadside servers, that’s all.