DevOps

Docusign

Docusign’s development has always been Agile. But taking the next step into DevOps processes was not so easy. Due to the nature of their business (contracts and signatures), things like continuous integration and delivery are undoubtedly a serious challenge. They live and die by transactions, not the money kind, but the exchange of signatures and approvals. If anything were to go wrong and an approval was misattributed, for example, this would be a serious problem. So to support modern development speed, they leverage a very cool tool called an application mock — in this case, a mock for their internal API. The tool offers a mock endpoint and delivers mock responses. They are able to combine this with incident management, and before release, test the application with simulations that are very close to real-life exchanges.

Forter

Similar to Docusign, Forter’s application is dependent on fast-paced and sensitive transactions. Forter put a large emphasis on self-healing issues driven by strong incident management. They’ve built a nice architecture for handling all issues. They have a filtering process to identify common issues to attempt to resolve them automatically, or for later reference to address and incorporate into their system. This focus on not just addressing issues but preventing them in the future is what will allow them to advance their delivery chain.

Turnitin

Turnitin is a platform to help improve students’ writing. (I could have used that while in school.) I learned a lot from Samantha, a Database Manager at Turnitin, during her presentation on how monitoring is used to help with database performance in their application. I’m no DBA, but being able to identify normal and abnormal spikes, monitor backend response time, and react to abnormal spikes as quickly as possible is important for any application.