In Intercom, we believe that shipping is our company\u2019s heartbeat. Our product engineers are empowered to build great features, fast.<\/p>\n
A large part of making this belief a reality is the idea of running less software.<\/a>\u00a0 Every product team is burdened by the effort required to evolve and maintain complex infrastructure that powers their features. For this reason, we chose to run exclusively on AWS and wherever possible, we make use of battle-tested AWS services, be it RDS Aurora for our relational databases, the Simple Queue Service (SQS) for our async workers or ElastiCache for our caching layer.<\/p>\n However, as with any rule, there comes an exception, a case that cannot fit neatly into the principles we’ve outlined as a company. So how do we handle these exceptions? In Intercom, we were forced to answer these questions as we built out our search functionalities and embraced Elasticsearch<\/a>.<\/p>\n This post is a version of a talk I gave at Elastic Community Conference<\/a> recently. You can watch a video of that talk below, or read on to learn how we built our Elasticsearch cloud on AWS.<\/em><\/p>\n