 So I also like recording the things. Okay, hello everyone for those of you who arrived. Maybe the other people will come after they will hear me talking and things like that. This is session about distributed caching. So last time to check if you're in the right room, but I can tell there's more dedicated people are here. So my name is Viktor Gamoff. I work as a senior solutions architect of a company called Hazelcast. I also develop or advocate in this company. And I also Twitter junkie like Twitter. So you can follow me in Twitter. I'm very interesting person. So, and without further ado, let's go straight to the plan. All right, another thing that I also, in the conferences are building very scalable hello world applications. So, and kudos to Kenny inventing this title for everyone who on the stage and talking about things. So yeah, why cash, right? So, why you want to cash and what to cash, how it's good or bad? You can see it, you can see it, come on in. All right, so let's start with why, right? So let's start with the problem statement. So what kind of problems do we have? So typical enterprise application contains multiple layers. It contains different layers starting from UI, business logic, the data access layer, some of the middleware and integration with other systems, messaging system, et cetera. So one of these many layers we're increasing latency of the application. So from one level obstruction to another, the application might slow down usually. So then certain things need to be taken care of while optimizing things and how to deal with the slowness, et cetera. So this is like a typical business application that interacts with some of the external services. Database is no SQL or S services. And at some point, you can tweak, you can tune and you can do whatever you can. For example, optimize the fast access to your database. You can change your network so the access to database will be faster or if you're dealing with some external service you can switch to different provider of the data. However, you tried everything and you tried everything and it looks like you cannot do anything more. So what do you need to do? Another problem in this kind of architecture might came from the perspective that sometimes application is not just the one instance application. Even though we're talking about microservice, it doesn't mean the microservice doesn't need to be scalable. So in case of we have another instance, so this data maybe that starts inside the application that might need to be available on multiple layers or multiple instances of the same application. So how are we gonna deal with this? So my proposal, yeah, let's cache everything. And in this case, cache will be here in between that allows the application to first of all, scale out. If it's distributed cache, I'm gonna talk about distributed caching today. And to provide this pattern called read write and read through cache and write through cache. Meaning that you go into the cache and cache will check if data is there, it's not there, it will fetch it for you. If it's there, it will just simply retrieve it. All right, so basically cache is everywhere. And as we know, we can call any storage that has like a key value access pattern, it can be cache. This needs to be simple, simple accessing, simple access path. So the cache is the, it's basically a copy of the data. And the beauty of this, the access to this copy of the data happens very quickly or supposed to happen very quickly. Even we have some data in database, we can cache it locally in some sort of hash map or some sort of map and retrieve it from a local memory. It would be much faster. So even we're dealing with accessing with database where for example, relational database we have situation with our data is in a relational form, third normal form, multiple tables. Usually when we're accessing it from the cache or some of the key value storage, it's normalized, denormalized version. So in other, from another terms, from terms of marker sources, event sourcing, it's just another presentation or it's another read model in terms of ICQRS. So obviously if we're talking about CQRS, we can also say cache can be event source and sorry, I just couldn't resist to put this because it's, I'm run out of the good options so I'm come out with some bad option. But there are some things to consider. So basically why people using caches to improve application performance, like I already said, multiple layers of application accessing to data, accessing to multiple things from multiple layers of application that will increase total, total ladle of multiple components. Some of the expensive operations can be afforded. For example, you're dealing with some of the computation over and over again for same key or for same customer. So why don't you cache this data because it's not gonna change for 24 hours or for like a work hours or stuff like that. So some of the data can be cached easily. So another option. So even though the application itself my running on some of the hardware that has very powerful capabilities, usual application, do not try to use all these capabilities and some of the solutions, caching solutions, especially in process caches, allow you to do kind of like a scale out. You can basically increase capacity of application by bringing more hardware like this. So you have the small guy, Professor Benner who grows into this whole guy but essentially the same application, the same application just increasing capacity of this hardware. Some of the distributed caches examples allow you to scale out the, if you'd like different components of your system that different pieces or different instances might interact and they will create shared memory. So basically this thing allows to form a cluster with commodity machines that will form some sort of shared memory where the different components can interact through this. And as I already mentioned multiple times, key value pattern, very simple, simple to implement, simple to access, simple to use. All right, however, if we're returning to this scale up point, so you can actually scale one machine to one until like one particular point when you can grow the hardware. However, it's not always the case. So sometimes you need to bring, you don't have, you have so much data that it's not practically to store it in one place or data may be very important that you store it in one computer or store it in one node, but you actually have, you need to have like full tolerance, resiliency, et cetera. So in this case it may be not a good choice to store it in one place. So let's talk a little bit about the data distribution. So how the typical data distribution happens in distributed cache. And so how many of you can tell me what you see on this picture in terms of data distribution? So in this picture I have two patterns of data distribution. How many patterns of data distribution you might know? Okay, I will explain on this picture I have two data sets, absolutely identical data sets. And on the second part I have data set that represents in a different form. It's like a sliced data set. Anyone, any ideas? Okay, so it is a location, right? So we have a same data that copied on multiple nodes. So and what's the, not the opposite but in other very useful patterns that people use for data distribution? Partitioning or sharding, correct. But this picture may be not very good from a perspective of explaining how the data will return to the same form. But in general, yeah, so we have two data sets. Let me put this in another way. This is things that most developers would understand, squares and arrows. It's much easier to understand. So basically we have a replicated data set which contains copies of the data on the both nodes. And we have a partitioned or sharded data set where whole data set that the developer working with this data set will be sharded across multiple nodes. But in practice, usually these two patterns not used in a pure sense. They complement each other. Usually used the pattern called consistent hashing that allows to, based on the key, find the way where this value will be stored and also for providing some of the full tolerance capabilities, data will be replicated to another node. So, but in general, this is what the patterns. So let's talk about, like we're talking about some of the practical things, some of the theoretical things, now let's talk some practical things. So first of all, Hazelcast is the thing that provides you capabilities for building distributed caches, right? So it's in memory, meaning that data stored in operational memory of the system, it's not stored on a disk. It's stored in memory, access pattern very quick. And it's a patch of it to license. It provides many different APIs. And today we're gonna focus on some of the caching capabilities. But I will also touch base on some other features, like messaging or maybe computing, but if you'd like. So and how it's related to cloud foundry. So in memory data grid or the in memory, any type of a memory system is very, from my perspective, is very good candidate for any sorts of continuation or any sorts of abilities to run on the cloud. Because basically it's in memory, it's ephemeral, it doesn't require any storage. It requires the fast network, it requires clustered storage so you can have a data on one node that can be also stored some of the backups on the other nodes. So the clustered environment is very good fit for a memory system like Hazelcast. And today I'm gonna be using Hazelcast that deployed in the Pivotal Cloud Foundry that uses Hazelcast tile that was developed for Pivotal Cloud Foundry. So the tile itself allows to start individual node of Hazelcast cluster on individual VM. So in this demo I'm running this Pivotal Cloud Foundry in Amazon Web Services. I use Amazon to provision my cluster. So multiple availability zones supported out of the box in the tile. The Bosch user used to support a high availability of these particular nodes plus it interacts with on-demand broker. So it doesn't require any pre-provisioning of the nodes to deploy this so everything would be taken care of by tile itself. So by itself Hazelcast written in Java but we have many bindings for different languages and today we're gonna talk about Node.js particular thing. So I guess we'll already think about slides so let's talk about some of the demo, right? So what's the premise of this demo? How many of you guys here Node.js developers? Okay, okay, some of you are interesting because I expected more hands in there. Okay, so in this example I'm gonna be using Express. For those of you who don't know Node.js Express is very powerful and a very famous or very popular framework for Node.js for running web applications. And I'm writing the web application that will microservice, you can say microservice that will interact with some external system. This is external system in this particular case it's gonna be GitHub. So in my microservice I want to use some of the information that GitHub provides about organizations. So I will query GitHub API and I will store this result internally. So the way how it works, I will just issue a request for this URL based on particular organization that I will retrieve from my application parameter. And after that I will store it in the cache. Also Express allows me to, in Express they call it like middleware, so I have this special type of middleware that call cache. So before it will retrieve a result and returning to user for me. We actually will check it with the cache. If it's cached, so it will just return it. If it's not cached, it will retrieve it from same GitHub API. So let me show you how it looks like. So as you can see from the top right now I'm running this in, just how we can make it bigger. Can I make it bigger? Okay, yeah. So I'm running this in Amazon as a cloud foundry. And what you see right now on the screen is this management center console that allows me to see the status of the cluster. So what I see right now, that I provisioned cluster of three nodes and right now I don't have any data here, right? So another thing that I have is my application that deployed on this API. You can actually go there and play around a bit, but not too much. Let's see if it actually works. Yeah, so there's some things that you can see on the main screen. So basically it runs a typical Node.js, the build pack. It interacts with different components of the system interact via VCAP services environment variable. So when I start my cluster, it's actually publishes some of the information about cluster. So in this particular case, it publishes information about members like IP addresses. So my client in this case, my Node.js app will query this from VCAP services and parse it and provide this configuration parameter for my application. Now, so let's see what this application actually can do. So there are three end points. One end points will allow us to get some basic stats. So for example, if I go to here and do something like this, it will actually will query GitHub information about this particular repository. Or also I can do something like this. I can do Hazelcast also on GitHub. It retrieves repository. And I see response time is half, if you can see here, it's around roughly like half a second, right? So when the next time we'll hit this, this result will be retrieved from the cache. So my application will interact with the cache server and get this information back. So if I will switch back to this and I will show you management center console. Now in management center, what I will see there is my org map that will store the information about Hazelcast and Cloud Factory. Organizations on GitHub. So if I'll go here, I'll see Hazelcast. And I will see, I will retrieve, oops. And I will retrieve something from here. No values. Oh, yep, life course. Life demos, always typos. So 61 repositories that store the key. It's an organization name. Value is the number of repositories. Now interesting thing here is that also I'm storing the information about repositories itself and I cache them in the data structure called multi-map. So multi-map data structure allows you to store multiple values by the same key. So in this case, key is going to be organization number of repositories, it would be number of values. And I also can expose this information through the REST service. So if I will do, where's my, oops. I will go here and I will see the information that already cached. So the retrieval time is extremely fast because it retrieves it from the cache. And more important that if I will do something like this once again, this time, let me actually show you CF logs. Hopefully I will be able to, yep, connected. So the hash hit time is ridiculously small. So the reason for that is that, where is it? So let me show you some of the interesting pieces. So now my application interacts with the cache. It's all good. But if data was already, my application already used this application. So we've already used this data. So in this case, I also can leverage things called near cache. So I can basically, on the side of my Node.js application, I also store this result so I don't need to go to the cache server and retrieve it once again. So up to this point, the information about organizations will be stored in the near cache of my application. So once again, this, I start my application. It established connection to my cluster. It starts releasing the port that, by the way, needs to be retrieved this way because the environment variable, this process and port will be passed by Cloud Foundry here. And if it will not be there, it's just using this one. This is suitable for local development. Now, some of the interesting things that you can see here also. From perspective of API, capabilities that can be done. Interesting thing here is, where is it? It's a thing called the map listener. So basically, each and every time when I will interact with my data, I register a handler, some particular callback, the function that will be invoked when something happened to my data. So in this case, I can also build more like reactive application when some component of the system, to put data into cache, I can react. In this particular case, I just simply write this information into the console, but in this case, I can do something useful. And if I just need to have notification that something changed, I can include value. So in this case, when I assigned my entry listener, I'm saying here true. So in this case, value will be actually propagated inside here. And if I don't need this, well, I just need to use it for notification-wise. So in this case, I just can put it this false. Now, again, let me show you differences if I would be running this without cache. So there is the special type of URL where I can bypass caching. So in this case, you will see the difference. So if I'll go here, so once again, so creating hazelcast, 99 milliseconds. If I do bypass, it has like half a second. So the difference you probably can see. And if it's numbers going to be even bigger for Cloud Foundry because Cloud Foundry repository is enormous, or organization in GitHub is enormous. It's 100, but I think it's just the limit of the GitHub that limits of number repositories per page. So if I do bypass, so it takes even longer. So two to three disinformation. So the caching can be applied very quickly. So this is also open source component. It's interesting thing that actually this component is written in TypeScript and it can be used in JavaScript projects. I will post the URL where you can find some of the interesting information. So from perspective of the features, I don't want to talk a lot about what kind of features are available and what can be done, et cetera, et cetera. So there's a website for that. There's plenty of the charts and the different features available. Map, cache, integration with the listeners, entry processors. Entry processors are cool. So in this case, if you need to change some value, you don't need to retrieve it, change it locally and put it back. So in this case, you can actually send a small task like a stored procedure in your database that will change the value in place. Or you can do some more custom logic. For example, you need to increase salary for all your employees. So in this case, you don't need to go through the, or iterate through the all elements of this distributed map. You can send a small piece of computation. It's basically just a small function that will be executed on the server side that will do it once and you don't need to move data around. Also, I wrote this ref card. I don't know if you've seen those before. It's like some of the things that you can actually print and have it on your desktop. Or you can just simply print and put it on the restroom in your work when your colleagues will be in the restroom. So you will learn something rather than just checking the social network feeds. And the NPM package is there. So if you're looking for some interesting caching solution to play around, I would suggest to use this. So a couple of things about this demo. So what I did this CF summit 2017 Wednesday is on GitHub. So it includes Java component that will deploy that uses all configuration. Oh, I didn't show this cool part. So while I'm talking and taking some questions, I can actually show you how I can... Let me scale this. So now I almost forgot the most fun part. So now I have three notes. I can go ahead and say CF update service. That will increase my cluster by four notes. And hopefully it will be executed. Now, in the second link, slides and the video will be posted there here. So you can go here. This is, by the way, a bright slide to take pictures. If you have any questions, like I said, I'm always on Twitter and ready to talk to anyone. How many of you guys have a Twitter here? Okay, good, because sometimes people don't have a Twitter. That's why I have an email here. So for those people who don't have a Twitter, I have an email and this is my website. So now I can take some questions and talk about some of the use cases. Thank you for this 30 minutes. Yes, in this room. So how is the synchronization done between the notes of the hazard cast? If there is distance between the notes. Yes. So synchronization happened in the following way. So basically hazard casts interact between nodes through TCP. So it is socket connection and nodes constantly chatting. So when I talk about the data distribution pattern, hazard casts use a similar concept called consistent hashing. So basically data stored in one place and there would be some replicas of the data. I can actually, it's better to actually show it in management center. In the management center. Oh, it already started doing something. So in this case, I have two entries in this map and one entry stored in one node and another entry stored in another node. So using this hashing algorithm, hazard casts will place them in one node or another node and also it will create a backup. So basically the things when you're shutting down some nodes and restarting some other nodes, as you can see, even though I already lost one node, now the node comes back. I'm not losing the data because first of all, my data is partitioned. So data is distributed across all nodes of the cluster. Plus it has, we call it backup count, but some people in their products are called replica count. The partition that holds particular data has a backup. We actually have very extensive documentation explaining how this process is done and it's far beyond on five minutes of explaining. So, but the most important thing here is that you don't, now you see it, I'm running four nodes, it's scaled up and actually it happens without voltage. So Hazelcast is designed to be a system that works in an environment where you're expecting some failures. So what we like to see in distributed systems, we cannot print failures, we just need to embrace them and deal with the situation that we're operating in a very hostile environment, I would say. So that's why killing node or killing two nodes will not basically affect the data. About the distance. So usually because it's TCP and because it's data consistency is an important part, we recommend to deploy Hazelcast nodes close to each other, preferably local type of network. However, if you need to have a distributed system across multiple availability zones, it's possible. We're not recommend to deploy Hazelcast across multiple regions because in this case latency will affect the performance of the cluster and consistency of the data. For that purpose we have the WAN replication or basically it's called WAN replication that allows you to synchronize cluster across multiple regions. Okay, any other questions? One here. I have a quick question on the architecture of Hazelcast grid. So in terms of cap theorem, are you like CA or CP? Okay, so the question was how I can tell about Hazelcast from perspective of cap theorem. So it's actually a good question because it depends. It depends how you would, what kind of guarantees you want to have. So Hazelcast is very explicit and very configurable tool. For some cases, for some data structure, you can say, okay, I want to have strong consistency. In this case, you can assign things like, you can use synchronous APIs that will provide you, you know, synchronous response. Or for some cases you won't have availability. So in this case you will decide about consistency after. So if your cluster will fall apart using splitbrain, you can decide after if this data was modified in multiple places. If you want to have a consistency, you can assign a quorum saying that if cluster size will go down for less than like three nodes, so in this case I will not accept any modifications, but I will be able to serve reads. In this case my data will be consistent in a situation where cluster formation is not full and maybe I will not be able to, you know, hold all this data. These things are very relative to the CAP theory because it's more like a theory in practice will allow you to control as a developer you can decide. And it's actually per data structure. You can say one cache, I don't care about consistency, I just care about availability. In another cache on another map you can configure say no. For this one I want to have a quorum and in this case I cannot go smaller than three nodes in my cluster. No, I have four nodes. Okay, last question. So I got a question on the feature you have on the UI, the VAN replication or the VAN piece. So does the PCF, or the Hazel Castile on PCF support VAN? So right now it does support, but we don't have a running demo right now, but my colleague, so the thing is right now with VAN is that you need to know explicit addresses to establish VAN connection. So what we're doing right now, and it's going to be released in a couple of weeks, it's the discovery in VAN. So you can use any discovery service or you will be able to use also like a VCAP to pass this information to different data, to different data sensors on to different regions so they will be able to discover each other. So yes, the tile itself supports, but we don't have like a demo that I can demonstrate this to you today. You can give me your contact if you need this demo, I will be able to show it to you. Okay, we need to wrap up for the next speaker, but I'm sure if you'd like to talk to Victor. Yeah, I will be hanging out around so we'll, let's talk about it. Thank you guys. Thank you, Victor. Thanks for your time.