This post is about the ability to use any of the SparkPost products in a cloud environment either as stand-alone implementations or together as a hybrid solution.

If you are a long time Momentum or PowerMTA customer deployed on bare metal in your own data center, you can use this guide to determine a path forward to migrating to a cloud service. If you are a new PowerMTA user wanting to deploy to one of the major cloud services, this is a good guide to a successful implementation.

For the past two decades, the Momentum MTA has been one of the fastest, most agile email engines on the planet.  Whether you know it as the original eCelerity MTA, or Message Systems Momentum, or as the core processing engine underpinning SparkPost, the world’s fastest growing cloud email service,  Momentum has had momentum for a long time. (see what I did there?)

 Alongside Momentum there lived another very similar product called PowerMTA (PMTA), which is equally capable and agile as well as being easy to install and support.  Momentum and PowerMTA were competitors for a long time, but several years ago, came together under one roof and now, along with the SparkPost cloud service, form a trio of email delivery engines that can satisfy any email transport need.

SparkPost lives natively in the cloud – it is built entirely on AWS.  Momentum and PMTA can be installed to run in a cloud platform if needed, but there are many things to consider before committing to a forklift into the cloud. There may actually be very good reasons for NOT doing it, so do your research carefully.

Look before you leap

Chris McFadden, our VP of Engineering wrote about our own journey to the cloud last year and made the very good point that many of the factors in your decision are not technology related at all.  Deploying to the cloud involves a new set of paradigms that you may not be ready for. Business processes may need to change and there may be privacy considerations that were not relevant in a bare metal infrastructure.  

Some time ago, our CTO and Co-Founder, George Schlossnagle wrote about some of the unique considerations for deploying email servers in a cloud service.  Cloud tech is designed for autoscaling and push button deployments that are ideal for stateless systems.  If you have a web service in the cloud, that is one thing, but running a stateful MTA on a cloud platform is a whole new ballgame.

When you deploy in your own data center, you control the environment and it is not unusual to see servers with no individual protection because they rely on the network firewall to protect them.  In a cloud deployment, doing that can be fatal. In the land of elastic computing, you need to be particularly diligent with security. It is extremely important to keep up to date with patches and updates.  Make sure your firewall is well maintained and close any open ports you don’t actually use. Deprecate weak ciphers, lock down ACLs, and remove any packages that are not required for the server’s purpose.

The last clear caveat we can offer is to be wary of the cloud provider’s DNS.  Remember that these systems were designed for web services and databases that only make periodic DNS lookups.  High volume email systems may perform millions of DNS lookups every hour and that has a tendency to break things.  Even running your own separate DNS for the unique needs of high volume email can lead to unforeseen problems.

Pick a cloud, any cloud…

There are many major cloud providers and even more lesser-known services to choose from when making the leap from hardware data centers to cloud services.  Even the concept of “cloud” varies between them. Here is a look at the most common ones we encounter working with our customers.

 AWS (Amazon Web Services)

  • We have the most experience here as SparkPost is built entirely in AWS fabric.
  • While you can deliver on port 25, you can only send very small volumes without attracting negative attention.  If you want to send volume mail, you will need explicit approval from AWS
  • AWS includes a marketplace of 3rd party services you can leverage

 GCP (Google Cloud Platform)

  • Google offers a development platform that enables you to build virtual servers in custom environments on the fly similar to Amazon’s EC2
  • Cannot deliver on port 25 without explicit approval
  • Marketplace of 3rd party services

 Azure (Microsoft’s cloud app platform)

  •  Azure came later to the party, but has an equally refined tool set.
  • Similar offering to AWS and GCP including a marketplace of 3rd party services
  • Cannot deliver on port 25 without explicit approval

SAP, IBM, Digital Ocean, and VMWare Vsphere round out the list of common cloud environments we hear customers using.

There are some things to remember when moving (forklifting) from a hardware data center to cloud services. As you design your platform deployment, keep these in mind. Tackling these issues during your planning phase will save you a ton of stress and frustration in the long run.  For instance, you may find that your chosen cloud provider denies you access to port 25 under any circumstance.  In that case you need to change providers or consider a SaaS solution like SparkPost instead.

  1. Delivery over port 25 is limited or non-existent,
  2. 1 physical CPU != to 1 virtual CPU.
  3. IPs and MACs tend to change periodically; for instance, with AWS EC2, you have to allocate “elastic IPs” to be bound to your instances (or load balancers) to get stable addresses.
  4. Inter-node communication is not the same in the cloud

Before you decide on a cloud host, make sure you can actually deliver email from it.  Apply for any exception you need in advance because you may be denied – no matter how big a deal you think you are, Amazon, Google, and Microsoft are probably bigger.

Get full cost details on not only the compute instance that matches your needs, but also any additional charges for vCPUs, RAM, storage, in-bound bandwidth, outbound bandwidth, static IPs, and billing frameworks.  Each provider calls these something slightly different, but they exist and are often hidden costs unless you do the research.

 A case study

When building out a basic* Momentum server, we recommend 8 cores, 32 GB RAM, and 600 GB of storage. Keep in mind that 1 physical CPU is NOT equal to 1 vCPU. When calculating virtual server sizes, each vCPU = 1 core.  We specifically quote our requirements in CORES for this reason. If you are building a cluster, you will want to enclose the instances inside virtual private cluster (vpc) with an attached elastic IP so you can control the public-facing IP without concern over whether the compute instance IPs change.  In the AWS universe, an M3 medium instance or larger is typically required.

 One interesting thing that the cloud host providers do not highlight, but has been our experience is that you can expect to see 20 to 30% less throughput in the cloud than with bare metal.  For instance, the Momentum deployment mentioned above should operate at ~1 million messages per hour on a physical server, but you should only expect 700,000/hour in a cloud host. This means you need to “supersize” your server deployment plan and overcompensate in the design.

 One last factor to consider is bandwidth cost.  Cloud host providers charge for outbound bandwidth just like most physical data centers do, but the cost calculations may differ from your expectation.  In addition, you may find that some bandwidth is exempt from billing. With Amazon, much of the bandwidth used within a region is not billed, though inter-AZ and inter-VPC is, and that can add up. If your message generation and delivery nodes are in the same region and you are running out of a single VPC, then you may see significant savings.  However, if your message generation is in the Ohio region and your delivery engines are in Oregon, you may find yourself paying bandwidth fees between those systems adding potentially unexpected costs.

 The above has been particularly important to our customers who use both our on-premises and SaaS solutions in a hybrid.  A customer moving their PowerMTA or Momentum cluster to the cloud and also wanting to use SparkPost SaaS delivery as a failover or alternate channel should be deployed in the same region as our SparkPost deployment for that part of the world.  The cost savings can be significant.

 We recently produced a webinar discussing this and also have blogged about our own journey to the cloud.  Here are some interesting links to those resources for some further reading.

https://www.sparkpost.com/blog/hidden-challenge-building-cloud-mta/

https://www.sparkpost.com/blog/cloud-migration/

https://www.sparkpost.com/blog/this-is-my-architecture/

https://www.sparkpost.com/blog/dns-aws-network-lessons/

https://www.sparkpost.com/blog/configuration-management-and-provisioning/

https://www.sparkpost.com/blog/devops-journey-deployment-automation/

https://www.sparkpost.com/blog/undocumented-limit-dns-aws/

https://www.usenix.org/conference/srecon18americas/presentation/blosser

https://www.sparkpost.com/blog/build-scalable-email-infrastructure/

A “basic” Momentum install is designed to delivery 1Million message per hour from a bare metal server assuming a 50k payload and 10Gb NIC.  A full hardware recommendation guide is available on request.

~ Tom