This post is part of a series of customer success stories that Chad Arimura is putting together highlighting key customers and how they are using Iron.io to do some pretty big things.
Mentor Graphics [NASDAQ: MENT] is a leader in electronic design and automation software. They enable companies to develop better electronic products faster and more cost-effectively. Their innovative products and solutions help engineers conquer design challenges in the increasingly complex worlds of board and chip design.
Chad Arimura recently spoke with Keith Childers, Principal Architect at Mentor Graphics, about why they chose to replace Amazon's SQS with IronMQ. Here's what he had to say.
What is your group responsible for?
Our group is responsible for all customer-facing web properties for Mentor Graphics Corporation, a leading software and solutions provider in the EDA space. Among these are mentor.com, supportnet.mentor.com, store.mentor.com, and blogs.mentor.com.
What are you doing and where does IronMQ fit in?
In our current architecture, we launch infrastructure on behalf of customers using Amazon CloudFormation. The CloudFormation service broadcasts status update messages through Amazon’s SNS message publisher service which dispatch the messages to an IronMQ push queue. The IronMQ push queue then uses the fanout pattern to our various listeners in real-time.
Why did you switch from SQS?
While Amazon SQS is generally reliable and has acceptable performance, it doesn’t support either FIFO or guaranteed once-only or once-per delivery. We had spent a couple dozen developer hours working on identifying duplicate messages, but the lack of FIFO was seriously hobbling those efforts, so we began looking for another messaging vendor. Additionally, we were polling Amazon SQS which was resulted in a lot of wasted resources. Switching to IronMQ push queues has allowed us to fan those directly out to various listeners in real time.
How did the switch from SQS benefit Mentor?
Iron.io thus far has been far less latent than SQS was. In addition we’ve been able to redirect “workaround” effort into real development, to the tune of ~30-40 developer hours, accelerating our project roadmap. We’ve also had other project teams adopt Iron.io services since we scaled up to Iron.io's Professional Tier plan, as we now have a very large allocation of API requests and extremely fast message processing with the isolated endpoints. Our initial data is showing that even traversing from us-west-2 to us-east-1 with messaging traffic, messages are getting delivered anywhere from 30 to 60% faster in IronMQ than with Amazon SQS.
Any final thoughts?
Ultimately we have a much higher degree of confidence that we are getting the shortest possible wait times for our customers, and that we are not messaging them redundantly or prematurely. In the end, our customers satisfaction is what technology choices are all about, right?
That's exactly how we feel too Keith!