Iris Mobile: An Open Source, Mobile Interface for Incident Management


Here, we see alert details and graph images that are specific to the use cases we have at LinkedIn. Iris relies on user-defined templates to determine this layout. Layouts can and will differ for different alerting methods. This means that each application that raises incidents through Iris can define its own detailed layout to best display what is important to the end user.

Hybrid platforms

When developing this app, we evaluated a number of different approaches, such as native implementation and several different hybrid platforms. In the end, we settled on the Ionic platform, which provided a modern framework for development and allowed us to leverage our existing knowledge. To make this decision, we first needed to analyze the tradeoffs between native and hybrid app development. The Iris team is composed of only a few dedicated engineers, and none of us had very much experience working with native mobile applications. With limited resources, we didn’t want to dedicate too much time to maintain two separate applications. One of the biggest advantages of a hybrid approach is code reusability; by following this approach, we had the bonus capability of creating two apps using almost the same codebase.

Iris prides itself in its flexibility: it provides an interface to render custom templates for all applications that integrate with it. These templates allow applications to define the layout of incidents on the web interface, using Jinja and Handlebars. Since these services are already generating HTML, our template design naturally lends itself to a hybrid platform. This gives us a more seamless experience for developers working on additional application integrations and enables them to write templates for mobile in a way that is very similar to writing templates for web browsers.

Having settled on a hybrid approach, we did some analysis on two of the largest players in this space: Ionic and React Native. These platforms have differing philosophies: React Native describes theirs as “learn once, write anywhere,” while Ionic prefers “write once, run anywhere.” One of the greatest advantages of React Native is that it allows its users to leverage existing React knowledge. Our team lacked this experience, however, meaning that we would need to ramp up not only on React Native, but also React. On the other hand, the team was already comfortable with the Ionic framework and other hybrid platforms like it, greatly reducing the learning curve required. Pairing that with our small development team, Ionic’s approach of “write once, run anywhere” was very appealing, and helped us get off the ground much faster.

One of the primary advantages of React Native is performance; a React Native app is able to communicate directly with platform-specific APIs, while most other hybrid approaches must work with the overhead of a webview. However, in our experience, we’ve found that the applications generated by Ionic have been limited primarily by the speed of the network and the resulting speed of the API calls that it makes, not the framework itself. Non-native feel is another possible drawback, but we’ve found that the components provided by Ionic do a good job of reproducing native design idioms, though these occasionally need platform-specific configuration.

Managing authentication

Iris relies on external authentication mechanisms to manage user accounts—usually via an organization’s Active Directory. Exposing this internal system to the internet creates a large security risk, so we rely on single sign-on (SSO) providers for mobile app authentication. At LinkedIn, we leverage a third-party service for this purpose, setting up a SAML flow that can verify a user’s identity even off premises. This way, our threat surface is reduced to an entity that is already thoroughly analyzed. Iris is not authenticating users’ identities, and instead leaves that job to another, more focused piece of our infrastructure. This way, we are able to allow our users to authenticate away from the office in a way that upholds our high standards of security.

Iris API is hosted on an internal network, so all communication with it is handled through Iris relay, our outward-facing proxy that handles third-party integrations requiring bi-directional communication. This is again tightly controlled, with a limited surface for attack. Within the app, we leverage the in-app browser to handle the SAML flow, which redirects users to our SSO provider’s sign-in page. After successful authentication with the SSO provider, we provide users with a session key used for authenticating with Iris relay.

Providing dynamic graph content off-network

Our internal metrics visualization tools provide “graph snapshots” as images, which we can pass along to the user to provide instant visual feedback corresponding to the issue at hand. To facilitate this, we pass along an image URL with our alerting incidents that we then include along with the other incident context. However, a problem arises here: the URL where the image is hosted is only available internally, requiring a pass through the Iris relay. In addition, users often find it useful to see not only the graph at the time of the alert, but also the graph at the current time.

In order to facilitate this dynamic graph content, we’ve built a custom component that can be included in templates similar to how one might display an Ionic component. This graph block triggers a call to Iris relay to fetch image data for graph data at the original alert time, as well as the current time. The logic of handling user input while switching tabs is delegated to the backend, and the template writer only needs to include the basic markup.

To display incident data, the Iris mobile app uses a templating scheme based on Handlebars, similar to the Iris UI. For example, this is the template we use for our internal alerting platform:



Source link