RSA’s intelligence driven security solutions help organizations reduce the risks of operating in a digital world. Through visibility, analysis, and action, RSA solutions give customers the ability to detect, investigate, and respond to advanced threats; confirm and manage identities; and ultimately, prevent IP theft, fraud and cybercrime.
I’ve worked with different SQL databases in the past: DB2, SQL Server, but am now on Cassandra. My current position at RSA is System Architect.
Our team provides a software as a service as transparent risk based authentication. Primarily installed for banks or financial institutions that use it to protect their online banking.
When a user performs actions on the online banking site or mobile app our service analyzes the risk associated with the activity to prevent fraud. Analyzing the risk level and using different policies, we can then trigger different authentication methods to verify the user interaction.
Previously, Adaptive Authentication ran on Oracle until version 11.0. We declared a directive of availability and had a major architectural transformation in Adaptive Authentication version 12 which now runs on Microsoft Azure with Apache Cassandra.
We selected Cassandra and DataStax for the availability and scalability it provides – our service needs to be ‘always on’ and scale to securely support the billions of transactions we protect.
We’re using DataStax Enterprise 4.5 for our Apache Cassandra needs and evaluating Spark in DataStax Enterprise 4.6 for our machine-driven algorithms that today run on a SQL database. We’re evaluating Spark to avoid having to move data around to write to different resources, which is not the most effective method.
We’re using DataStax Java driver 2.1. which is very good. We are using async queries and the results speak for themselves. We are also using DataStax OpsCenter to initiate some of Cassandra’s operational tasks, while for monitoring we push JMX metrics into Zabbix.
We decided Cassandra was a good fit with Microsoft Azure. Microsoft is investing heavily in Azure; they’re adding features all the time, and it’s maturing fast. At the beginning, the difference between Amazon Web Services and Azure was really big, but as time went on and we’re using Azure they’re catching up.
We considered using different NoSQL databases such as MongoDB, but Cassandra is really the only database that was built as a distributed database. MongoDB was built as a document database and later on they added replication and availability; Cassandra was built from scratch as a distributed database allowing for high availability and partitionability. That was the key factor for us.
Most of the time when people talk about Cassandra’s performance, they talk about the write performance. Providing software as a service, we’re bound by strict response time SLAs so reading data fast is important to us, and for our use case the read/write ratio is almost one to one. Cassandra is not as fast reading data as writing and tuning that specifically can be a bit tricky.
I didn’t have any trouble learning Cassandra – the work DataStax does, creating documentation for Cassandra is really good; it’s awesome. I read all about the Cassandra internals to understand how to define our data model and match it to the Cassandra way of thinking. It’s really different from SQL because you don’t have any relations and you don’t have to normalize data, but the documentation was helpful to get through it.
I try to answer questions on the Apache Cassandra user mailing list when I get a chance; mostly about data modeling. I appreciate that Cassandra is open source. When I encounter a bug, and I want to better understand how certain features work in Cassandra, I can just open the source code and find how it works. That’s a huge plus for me.