I’ve spent many years implementing traditional enterprise IT operations management tools. Integrations among various tools are often the Achilles’ heel of management systems. Integrating various applications is often a high-risk endeavor for customers. Enterprise vendors typically charge tens of thousands of dollars for integration “plugins”, and the implementation requires highly skilled (and expensive) engineers. To make matters worse, enterprise vendors are often not keen on collaborating with their competitors, let alone collaborating to help their customers. Vendors sometimes even block these integration efforts. I’ve witnessed a vendor not selling their product to prevent them from integrating with it (how is that for putting the customer first).
One throat to choke fallacy
Due to potential problems, enterprise customers typically attempt to work with a single vendor in order to establish a “one throat to choke” scenario. Working with a single vendor is not only an elusive goal achieved by almost no one, but also doesn’t do much to alleviate integration issues. Most enterprise vendors have grown through acquisitions, and integrations among their products often don't go beyond markitecture. As a direct result for most organizations, not only are management tools poorly integrated, but the quality of the integration degrades over time. There are a couple of reasons for this; product updates break the integrations, vendor supported organizations are either not willing to or are capable of supporting the integrations, and even sometimes blame the “other” product for unrelated problems.
I was reminded how drastically different things are in SaaS world when having lunch with an old colleague that works mostly with traditional enterprise IT management products, at least in the IT operations management market that OpsGenie operates in. We held a multifaceted discussion around on-premise vs. SaaS. The thesis of this blog post is to make the case that in the SaaS world, integrations are far superior to what’s available in the traditional enterprise software world (again, based on IT management products/services). To help support this theory, I’ll illustrate successful examples of OpsGenie integrations with other SaaS providers.
High quality integrations
We integrated OpsGenie with Datadog, one of the leading monitoring services in the market. “Integration” can mean many things in our field. Most products or services can be integrated with OpsGenie within minutes, as long as it can send email alert notifications or can execute a script. And the integrations can be implemented by OpsGenie customers without our help. In this particular case, the Datadog/OpsGenie integration goes well beyond a basic integration. To fully enable our mutual customers to use both tools seamlessly, Datadog alerts are forwarded to OpsGenie to notify the right people via SMS, phone and push notifications, using on-call schedules, escalations, etc. In the same vein, alerts from any monitoring tool that is integrated into OpsGenie can be passed to Datadog. Alerts can be acknowledged in either service. Bi-directional integration keeps the alert state in sync and allows users to choose the appropriate tool to do their work.
Collaboration among vendors
We at OpsGenie collaborated with the Datadog team to build this integration. We held several discussions with them to understand how each service worked, how customers may want to use it, and ultimately determined what we each needed to make the integration as easy as possible to configure, and make the combined solution as useful as possible for our customers. I can tell you based on experience, that this type of collaboration almost never happens in the traditional enterprise software world; unless of course the customer has millions of dollars worth of business to dangle to motivate the vendors into collaboration. The result is an integration that can be configured in minutes and available to all customers big or small.
The differences do not end with the implementation of the integration. The integration is monitored and supported by both providers. Customers should have the confidence that if a problem occurs, it will be addressed by knowledgeable people. Enterprise software products are often integrated by third parties, and some integrations are not always supported after the project is approved by the customer.
Upgrades don’t have to break integrations
A major issue in the traditional software world is with upgrades. Customers are pushed to upgrade in order to fix one issue, then to find out that the upgrade broke the integration with other products. Yikes! API’s are often undocumented and can change without any notice to the partners or the customers. Yikes again! Contrast that to SaaS world where New Relic has been working on a major upgrade to their alerting capabilities (which is great to see!). Weeks before rolling out the update, they advised their customers that it’s coming, and weeks before that communication they reached out to us, OpsGenie. We found out what was coming; we were then able to determine what the impending impact on our mutual customer base might be, and finally what we needed to do to ensure that there wasn’t a negative impact. As a shining result, customers were able to successfully take advantage of New Relic’s new powerful alerting capabilities from day one. Again, compared to the enterprise software world, where an upgrade can break everything (often without notice), New Relic’s collaborative posture was a breath of fresh air. Now it must be noted that not every SaaS provider is as proactive as New Relic. Unfortunately, we’ve had quite the opposite experience as well, but the overall mindset in the SaaS industry so far is making it work for the customers, providing open, published APIs, and collaborating as much as possible. Even involving providers that may have overlapping capabilities. I hope that this mindset will survive as the market matures.
Customize the integrations to your heart’s content
One potential obstacle with the integration of SaaS products has been the limited flexibility to customize since the integration is shared by all customers. SaaS providers typically overcome this by providing UI driven “configurable” integrations. In addition, number of vendors now support defining the webhook payload, making it possible to construct the requests in a format required by the destination.
Which leaves us with the question: how can we interject business logic into the integration? Until recently, implementing the business logic in the integration required customers to manage a server to run the custom integration code. Naturally, this is not an ideal solution for SaaS customers.
Thanks to AWS Lambda, it’s no longer necessary to maintain a server to run the integration code. AWS Lambda lets customers run code without provisioning or managing servers which is an ideal solution to integrate SaaS solutions. For example: When integrating OpsGenie with JIRA using AWS Lambda, the code executed by Lambda has full access to both alert data and JIRA issues via APIs. This format grants customers the opportunity to have full control over how the integration works. Read more about the how AWS Lambda can be leveraged to create JIRA issues from OpsGenie alerts.
To be clear, I’m not suggesting that enterprise software vendors are evil, or that they mean to do harm. Rather, it’s the nature of SaaS that makes it easier to make this all happen. The integration has to be done once; there is one version of the code, and the SaaS business model does not require us to do everything ourselves, as it is often the case for enterprise vendors. Integrations are one of many criteria when comparing on-premise vs. SaaS solutions (or at least it should be one). Based on our experience, SaaS offers happier times :)