 I'm Divya Mehra, Principal Product Manager in the JBoss Middleware Division at Red Hat. I'm responsible for this product strategy and roadmap for Red Hat JBoss Data Grid. Red Hat JBoss Data Grid is a distributed in-memory NoSQL data store, an in-memory data platform that gives you high performance, linear scalability, and elasticity for getting superior user experience for the end user of your application. It also supports a variety of distributed compute frameworks, which makes it not just a data grid but also a compute grid for real-time distributed computing. JBoss Data Grid allows you to have highly responsive applications. So if you are designing applications which are highly data-intensive, where you want to process data in real-time, large volumes of data, and give your end consumer the best user experience, that's where JBoss Data Grid comes in. JBoss Data Grid traditionally was used as a distributed cache, but increasingly we are seeing usage of it as a primary in-memory NoSQL data store, where developers are considering it as an alternative to a traditional NoSQL data store. It can also be used as an event broker because it has the ability for your application to react to changes in the data in real-time and at scale with something a vanilla NoSQL database cannot do. And finally, it also supports a variety of distributed computing frameworks. So if you have to process large volumes of data in real-time in a matter of sub-seconds instead of minutes, then JBoss Data Grid is a solution for that. JBoss Data Grid is the leading fully open source in-memory data grid in the market. It has been rated by independent analysts as the best open source option, both on the basis of its feature set and the ability for Red Hat to support the product effectively for the needs of the enterprise. JBoss Data Grid enables a developer to develop highly responsive applications that allow the developer to process large volumes of often-changing data in real-time so that the users get the most engaging experience. For example, if you're designing, if you're developing for an e-commerce platform by storing relevant product catalog information or user behavior information or location information, you can drive real-time product recommendations while keeping the page load time to a minimum which gives the user the best user experience. JBoss Data Grid implements some of the standard user interfaces, developer interfaces. For example, in JBoss Data Grid 7, we added a distributed version of the Java 8 Stream API. So developers who are familiar with the Java 8 Stream APIs and the functional operations can use the same on a much larger scale on a distributed data set. JBoss Data Grid also provides an integration with Apache Spark and Apache Hadoop, which are the well-known analytics frameworks. So if you are familiar with Spark and Hadoop, then the same interfaces are available with JBoss Data Grid available as a high-performance, highly scalable data store for these computing frameworks. JBoss Data Grid, in addition to a Java API, also supports three remote protocols, the highly-performant Hot Rod protocol, which is a binary protocol used by most of our developers, as well as REST and Memcached. We support the Hot Rod protocol for four programming languages, Java, C++, C-sharp, and Node.js. So if you are developing in any one of these popular languages, you can use JBoss Data Grid as a high-performance, highly scalable, fault-tolerant in-memory cluster. JBoss Data Grid provides comprehensive data security options for the developer. For example, our data grid supports, JBoss Data Grid supports role-based access control to the caches so that only authenticated and authorized users can access the data in caches. Similarly, as you add and remove nodes to the cluster, there is also node authentication and authorization so that you cannot have a rogue node enter the cluster and take a portion of the data. We also support encryption between the clients and the server using transport layer security and also encryption of the communication within the cluster using any cryptographic algorithm compatible with Java cryptographic architecture. Consider a cluster with N nodes. As a developer, you have the option of storing anywhere between one to N copies of the data. So the most extreme case is if you want a fully replicated cache in which you are storing N copies of the data. That gives you the most fault-tolerance that whenever up to N-1 nodes go down, the data is still available and the user experience is not impacted. The application continues to run with access to the data at high-performance uninterrupted. To balance that with scalability, you can also specify typically between two to four copies of the data so that you are using the memory more efficiently and it's more scalable and that's called a distributed cache and in that, if you have, say, specified K copies of the data, you are fault tolerant for K-1 failures of the nodes. Moreover, you can hint to JBossDataGrid to have different copies of data on different physical servers, racks, or even data centers to give you fault-tolerance against server failure, rack failure, or even data center failure. JBossDataGrid can participate in a distributed transaction which ensures asset compliance of your data. In this regard, it differentiates itself from other no-SQL databases that can at the most support eventual consistency. Relational databases can support strong consistency, but they are not scalable. So JBossDataGrid gives you the best of both worlds, high performance and scalability that you will not get with a relational database as well as full asset compliance that you will not get with a no-SQL database. JBossDataGrid is a certified JCASH caching provider. It fully implements the API that is specified in the JSR107 spec. This allows you to migrate your applications from any other data grid or caching provider that supports JSR107 to JBossDataGrid. JBossDataGrid is a highly configurable product, and it enables you to configure both declaratively as well as programmatically. Customers or developers that choose the embedded Cache architecture can create caches very dynamically, create and destroy caches very dynamically, and manage the lifecycle of the caches directly from the application. On the other hand, customers that use the client server mode, which uses a standalone data grid cluster, delegate the management of the lifecycle to the data grid server, which can then keep it running forever as hundreds of applications can connect to it at the same time.