Developers – and the DevOps who support their apps – long for greater observability. That’s visibility, but with greater alacrity. That means APIs and integration into the tools and dashboards they use to keep them informed about the performance, availability, and security of their applications.

That’s particularly challenging in the cloud, where only some components of the application and its delivery stack are truly integrated with cloud consoles and services.

Consider the finding from Gitlab’s 2018 developer survey on the top three challenges faced by developers using technology to support investments for 2018.

Integration with other tools in their stack ranks pretty high at number two. More than a third (37%) consider that integration to be a top challenge.

One of the reasons tools aren’t integrated is that some of them are ‘owned’ by someone else. Someone else being NetOps or SecOps. So it’s incumbent on DevOps (and Dev) to communicate their need, yes, but it’s likely that the responsibility to do something falls on the shoulders of some other *Ops.

The urgency of providing that visibility through integration with cloud-native services is growing. A 2017 survey from SailPoint uncovered a disturbing number of respondents (73% to be exact) who, when "given the hypothetical situation of the CEO’s identity being compromised … admitted they wouldn’t immediately know how and where their data was at risk." That’s likely in part because of a lack of integration between the application services that detect and report malicious activity – like application access control and web application firewalls – and the logs and dashboards used by operations to monitor the health and security of apps.

That’s why community and open source is so important. Not just to support solutions and expand or extend software, but to share and improve on ways to enable the integration required to unlock observability. Especially in the cloud. Especially if it actually is Dev or DevOps who are responsible for making it happen.

One of the ways F5 is doing that is through iApps (templates) that do the difficult work of integration and offer NetOps and SecOps a way to support their DevOps and Dev counterparts need for observability in cloud environments.

F5 Cloud Logger iApp

The iApp configures BIG-IP to export logs via JSON to cloud services including Azure OMS, AWS S3, and AWS CloudWatch. All CloudFormation Templates (CFT) and Azure Resource Management (ARM) templates provision a BIG-IP that includes the Cloud Logger iApp pre-loaded for your convenience. Don’t forget to configure the cloud logging service to receive the stream before running the iApp, and make sure the appropriate application services on BIG-IP are logging the information you want.

Per the need for security – and to identify what’s going on – the iApp can log web application firewall policy violations and violation types, DoS-related incidents, as well as those associated with access control, right in the respective cloud management console. That’s on top of system level logs that give you all kinds of visibility into the performance and availability of applications being monitored by BIG-IP.

Pre-loaded is great, but you might want to use it as part of your deployment process (and automation toolchain) or customize the iApp for your particular needs. You can get the source for the F5 Cloud Logger iApp on Github (https://github.com/F5Networks/f5-cloud-iapps/tree/master/f5-cloud-logger) for either or both purposes. The Github project also includes a handy example CuRL command and associated JSON to deploy the iApp programmatically using F5 iControl REST for Azure OMS.

Whether you use the pre-loaded iApp or the open source version with modifications, NetOps and SecOps alike can provide a new level of visibility to Dev and DevOps (and themselves) by taking advantage of integration with the tools you use in the cloud.