User Stories

Why atmail chose OpenStack for email-as-a-service

More than 15 percent of the Australian company’s infrastructure runs on an OpenStack-powered DreamHost Cloud.

November 22, 2017
image

In a world where most companies broadcast what they’re having for lunch, atmail likes working hard in the background. For users of over 150 million email accounts in nearly 100 countries, the Australian company toils behind the scenes making sure those emails get delivered.

Working from headquarters in the small town of Peregian Beach, Queensland, atmail provides email solutions for service providers (such as internet service providers (ISPs), hosted service provider (HSPs), telecoms, global corporations and government agencies in Australia and the U.S.

OpenStack is critical to getting the job done — currently more than 15 percent of atmail infrastructure is powered by OpenStack-powered DreamHost Cloud. Its infrastructure has gradually migrated from hardware to virtualized.

In a recent talk at the OpenStack Summit Sydney, atmail senior dev ops engineer Matt Bryant talks about why the company chose OpenStack, the journey into cloud and future plans. He was joined onstage by Dreamhost’s VP of product and development, Jonathan LaCour.

atmail started looking to the cloud to replace aging hardware in multiple data centers, maximize cost efficiency and increase flexibility. They searched for the right partner, finding a good match with DreamHost. “A lot of OpenStack providers now are regional,” says LaCour. “They’re serving very specific use cases in particular markets that Amazon probably doesn’t about care that much, this is a good example of why OpenStack has a long-term future.”

The pair set out with a very high goal – to make the transition with little or no impact on our customers,” says Bryant. “What that meant in practice was we had to revisit our architecture at the software and infrastructure layer.”

Looking at their needs through a “prism” of security, performance and scalability, Bryant adds what they started with was pre-cloud, based on the idea of a mail server in a box. “There were a few decisions early on that didn’t play well with a cloud environment. We had to decide what to re-code and what to work around.” Automation was another big component — they went with Ansible’s OpenStack module as well as in-house Perl scripts — and then it came time to “test the hell out of it” Bryant says to see if it was possible to maintain the servers and level of service.

“We got to the stage where both of us were happy, and then we were on to migration.” This is where both companies learned a few important lessons. “You can’t do mail migrations completely without customer interaction,” Bryant says. “There was a whole lot of data, a massive amount of storage (a few terabytes) to pore over,” adds LaCour. They ran into a number of issues with networking and storage.

Among the other takeaways were to keep it simple (forget traditional network topologies and VLANs), the importance of reviewing architecture, dedicating enough resources, having direct access to engineers (they had an IRC channel with their DreamHost counterparts) and finally, test, test and test again.  “Know your failure scenarios and what can go wrong,” Bryant underlines.

“We went from a fairly simple architecture in bare metal to one behind load balancers and multiple nodes behind load balancers,” Bryant says. When you have an intermittent problem on a five-node cluster, it may only happen so often but can be much more complicated to fix, he adds.

What’s next? Bryant says they’re looking into a number of OpenStack projects, namely: Manila (shared file systems), Octavia (load balancer), Monasca (monitoring), Heat (orchestration) and Vitrage (Root Cause Analysis service).

“The more that we can push off into services and concentrate more on our core product, the better,” Bryant says.

You can catch the whole 27-minute talk below.

Tags: , ,

Superuser
Latest posts by Superuser (see all)