from you guys. So thanks for coming. Let's get started. My name is Matt Griffin. I'm a director of product management for Precona. If you are not familiar with Precona, we're a database services and software company focused on MySQL MongoDB. We drive a lot of our services innovation and learning into our open source software like Precona server, which is a MySQL alternative, and our clustered version of Precona server, Precona extra DB cluster. So we also participate in the Trove project and help that team along as well as the docs team and the HA guide is what we're currently working on. And we'll be in the demo theater today, so come visit us over by, or in the Explore area, so come visit us by the demo theater. So I'm presenting with Amrith Kumar from Tessora, and he's this guy, and he'll tell you a little bit about himself sometime in this presentation. If you want to tweet about this presentation, please use these Twitter accounts, and this is the agenda we're going to cover today. We're going to cover some of the introduction to the Trove architecture, where we are with replication in the Trove project, leading up to Kilo, and then Amrith's going to talk you through a demo of how it all works, step by step in replication, and then we'll talk about the future in Liberty and Beyond. And if we have time, hopefully some Q&A. So let's first begin to understand where do we stand right now with Trove. This is the user survey, and the bottom left are stats from the November 2014 results showing where Trove is, in terms of the top bar is production, then dev test, and then POC. So 9% production, 9% dev test, and 16% of reporting clouds are using Trove, and 16% in POC. This is great because when you look at the current results that were just released a few days ago, just above the six months ago area, you can see that there's definite growth in production clouds running Trove, but it's 12% if you can't read it. Then 13% in dev test, which is actually a really, really component or part of the cloud experience in using clouds. Amherst colleague, Ken Rugg, had an awesome article in SuperUser about it a few months ago about the importance of dev test. And then I think what's really, really promising is the rise in POCs, and so this is at 19%, I believe, which is really, really great, and I'm anxious to see what the results of this survey are at the next time. So I think that's here, yeah. So these are the stats. Next, we will talk about why do you want to replicate? Why use replication with basic replication? So these are just a few use cases of when you'd use replication. First, you want to have a scale-out strategy. And so you might use a master-slave topology or you might use a master-master topology. There's trade-offs with each, like master-slave, you have to deal with the slave lag and promoting slaves to masters, and then master-master, it can be really complex. We won't go into all that because it's not really why you're here. High availability might be another way where you can use MySQL replication to support a high availability strategy and an offline copy. There are other use cases around how to do upgrades and how to set up really good backup strategies using MySQL replication, but these are just a few of the other reasons why you might use MySQL replication. So next up, Amrith is going to talk about the architecture of Trove. Thank you, sir. Don't kick my beer over. Thanks, Matt. I'm Amrith, I'm with Tesora, we're a company which is focused on Trove. We're also in the exhibition center or the exhibit hall. Come over if you're interested in learning more about Trove. So what does Trove do? What is the Trove architecture? How many of you here are familiar with Trove? Show of hands. How many of you have used it? Neat. How many of you have used Trove with MySQL? How many of you have used it with a NoSQL database only? DB, Cassandra, anybody? No. All right. So you're probably all familiar with some of the names on this picture. I'm going to talk to this picture very quickly as you're probably familiar with everything on the right of this picture. That's your traditional open stack. You've got Keystone, you've got Neutron. Keystone does authentication and identity management. Neutron does networking. Starting from the top, you've got NovaCynder, Swift and Glance. Nova being compute. Cynder and Swift being storage. Glance being image service. Okay. The stuff you're here to talk about is on the left of the picture and that's Trove. Trove has primarily three components like most of their open stack services. There's Trove API. It exposes the Trove RESTful API. The Task Manager, which does most of the heavy lifting. And Conductor, which we'll talk about a little bit, does some very important offline out of banned things which are useful for databases. The objective of Trove is to give you a database as a service. You need to be able to provision and use a database without having to bother about all the minutiae which goes on in provisioning, managing, replication or clustering or all of those things. The way in which all of this works is requests go to the Trove API. I can't quite point, oh I can't. Request go to the Trove API. You get your responses from the Trove API. Behind the scenes all the work gets done by the Task Manager. Some of the work by the Trove API as well. And they communicate internally over a message bus. By the way, if you have questions at any point, raise your hand, stop, ask. Very important thing to remember about Trove is that Trove provides you frameworks with which to build a database as a service. Trove is not a database. With Trove you get databases you already know and hate. MySQL, Oracle, Mongo, whatever. Trove is not that database. Trove helps you orchestrate databases. So you can provision an instance with Trove. Trove takes care of the provisioning for you. At the end of the day what you get is a MySQL database for example. If you want replication with MySQL for all the reasons Matt mentioned, Trove will help you provision a replicated pair of databases. Trove does not itself do the replication. MySQL does replication just fine. Thank you very much. We just give you a replicated pair of databases which you can use. And the last thing is when you need to do a failover, when you need to manage your replicated pair, Trove gives you an API bill which you can do this. On the other side, what does the database do? At the end of the day your data is stored by MySQL. Queries are processed by MySQL. You get answers from MySQL. The actual movement of bytes for replication is done by MySQL. So there's a very clear contract here. What does Trove do? What does the database do? All right. So Trove provides a framework. The first version of this framework came out in Juneau. For those of you who are familiar with other OpenStack projects, we use the standard strategies mechanism. In Juneau we supported asynchronous replication with what MySQL talks about as binlog replication. Quick show of hands. How many of people here know what binlog replication is as opposed to gtids? Great. Okay. This is going to be a short presentation, guys. So in Juneau, version one of replication was built for MySQL 5.5 and was built around binlog replication. Okay. For those of you who are really interested in going back and looking this up in the sorcery, Trove guest agent strategy is replication. MySQL binlog is the actual implementation of we1ofreplication. In Kilo, we added a new capability here. I say we. I didn't write any of this code. There's other people sprinkled all over this room. All right. Quick show of hands. How many of you here are Trove contributors? Just raise your hands, please. All right. There's a whole bunch of people here. Blame them on one guy over there if there's any bugs. All right. In Kilo, we came up with the gtid-based replication. We extended the exact same framework to support gtids. All right. We're going to talk a little bit about gtids and MySQL binlog replication and so on. The focus is going to be on Trove and the framework which it provides. Okay. So let's get into the real stuff here. The first thing, how do you provision your master instance? Trove create. The underlying restful call is just the create API call. Trove create m1, 2, dash, dash, size 10. Okay. That basically says create me a single instance. Call it m1. The 2 there is the flavor. Flavor 2 is small with a 10 gig database. So what that command is going to do is it's going to create a singleton nova instance. It's going to hang a 10 gig volume off of that. That instance is going to be of type small. And it will have on it, and let's assume here for the purpose of this illustration that we're talking a Kilo-based system, the default you will have a MySQL 5.6 instance booted up on it. Okay. All right. Then you go and do your usual stuff.  Here's the interesting part with replication. All you do is this one command here. Trove create, give it a name. Flavor 2, size 10. And all you specify is make that new one a replica of m1.  And what? Yes, go ahead. You have to do what? Nope. You'd literally do exactly these commands. It will all be taken care of for you. Now, we'll see why you don't have to do that. And you can do this as many times as you want. At the end of the day, you get a picture which looks like this. This would be m1, and this would be, you know, all the replicas. And for those who are going to be watching this video later, the question was do you have to put the master in read-only mode before you do the replicas? The answer is no. Okay. So what exactly does Trove do? This is really the guts of replication. You gave it this simple sounding command. So what Trove does, and this is GTID-based replication, MySQL 5.6, first it's going to create a snapshot of the master. MySQL knows how to create a transactionally consistent snapshot. I don't need to put the database in read-only mode for that. Database runs along just fine. But we also store MySQL stores the master log position in GTID form. Then Trove goes and creates a new instance, and it launches it. It hangs a flavor 2, 10 giga storage off of it. It loads that backup, that snapshot which it created. And then it identifies m1 as a replication source, and then starts up replication. Now, these are exactly the same thing. Okay, so let me ask, let me say this the other way. How many of you here have set up replication manually? How many of you have done the exact same things? Well, at least a couple of you. Okay, that's good. You had a question, sir? No, it does not. Oh, the question is, does it pause the VM to take the snapshot? Nope, it's a MySQL snapshot. It's going to send it straight to Swift. Okay, so it's effectively going to take a snapshot from MySQL's perspective. The VM is going to transition for a short while into, quote, backup state. Let me look to the guy who wrote this. It goes for a second to the backup state, correct? Okay, and then it'll come back out. But no, it doesn't... It uses Percona X or DB backup. Gentlemen of the red shirt, Nikhil Ptl. Good point. While it's in backup state, other Trove commands will fail because it'll say in backup state you can't execute other commands, but your data plane access still goes on fine. You do exactly these same steps if you set up replication manually. So in Juneau, again, in Juneau, we did this with traditional bin log replication. Only master slave topologies, any number of slaves you wanted. None of the other fans here topologies possible. And all Trove would do was orchestrate the creation of the slave, load the backup and all of that stuff. Okay? All right. If you actually go and look at that implementation, which I told you, you will find these exact lines of code. And the lines of code there in red are exactly what you would do if you were setting MySQL bin log base replication. Nothing fancy. Trove orchestrates this for you, so you execute one command and this is done for you. That's the value that Trove brings.  Master log file, master log position. Those are the two commands which identify this as being bin log replication based. Okay. In Kilo, we do just one slightly different thing. Master auto position is one. So for those of you who are familiar with bin log replication as opposed to G2 replication, that's fundamentally the difference from an administrator perspective of what you have to do different. Okay? So for the entire duration of time that this whole operation is going on, you're not sitting and waiting. You came along, you issued up here top left Trove create replica of something or the other. The Trove API service is going to give you a response immediately. The gentleman who's taking photograph, there's seven pictures which are going to look very similar, so get ready. The next thing which happens, the API service does just the light stuff. Oh, you want to create a new instance which is a replica of something else? Sure. Here's the idea of the instance. Have a nice day. Come back later and check. The API service tells the task manager, somebody wants a new instance which is replica, go do the heavy lifting. So the message shows up here. The task manager then goes and says, okay, I'm one, go take a snapshot of yourself. Snapshot lands on Swift. Okay. Task manager then says, snapshot is done. Nova, can I have a new instance, please? I have a new instance. It talks to the guest agent on the new instance and says, there's a backup there. Go load it. When it's done with all of that, it says, okay, establish replication. Now you have yourself a replicated pair of databases. Under the cover, Stroves is doing all of this for you. One command word. Okay. We talked a little bit about bin log and gtid replication. We're not really going to talk in a great lot of detail about it. If you really want to know more about it, go to Percona Live. No, just kidding.  By the way, you should really go to Percona Live. It's a good show. Yeah. Join us in Amsterdam coming up in October, I think. Yeah. Anyway, I don't know. So I'll be brief. Just going to give a quick overview of, here we go. Bin log replication. So bin log base replication, it can sometimes introduce problems. And that's kind of the key reason why we're moving to, or the move was made to gtids. And it's really essentially because the slave knows very little about what's happening with replication. And so in master master setups, there can be problems with where should the slave, what's the most recent version of the data, unless you really know what you're doing. But even in master slave scenarios, whenever you want to recover that slave, there's typically a lot of manual effort involved to make sure that you are recovering all of the data available. In the case of gtids, it solves a lot of those problems.  It's a unique identifier created and associated with every single transaction committed on the master, essentially. So now the slave has a lot of rich information on what is the most recent piece of data. And you can do things like automatic failover from the master and bring up a slave, or do more advanced things with Trove. These were introduced in MySQL 5.6. So I just want to give you all a brief thing. If you want to know more, yeah, go to Pokémon Live. So I mentioned failover, and I'm going to talk about failover. Thanks, Matt. All right. So if you were using Trove with Juno, and you can take my word for it if you didn't, everything was built with 5.5 in mind. And 5.5 did not have gtids. Therefore, if you attempted to do a failover, it was possible. Again, let me stress, it was possible in some circumstances that you could lose data. Therefore, there were some restrictions on the kinds of things you could do with Juno and 5.5. Again, now in Kilo, we have support for failover. So we'll talk about that. So now that if you have a replicated pair, let's talk about some of the commands you can use to manage these. When you have a replicated pair of databases, you have a master. Again, 5.5 or 5.6, Juno or Kilo, one master, many slaves. All right? This is not multi-master. This is not Galera cluster. This is just master-slave replication. Okay. There are three things you can do if you have a replicated pair of databases or a replicated group of databases. The one is to actually do a failover. And a failover is an operation where the node which was the master is no longer the master. Okay? And the other thing which you can do is you can take a slave and say you have no master anymore. Those are effectively the three things you could do if you have a replicated set of databases. So let's talk about failover first. I have a master. I have some number of slaves. The master is reachable.  Okay? That instance is, you know, I want to retire the physical machine on which that instance is. I need a new master. Okay? The other situation is your master is failed. In a situation where you have a failed master, you need to elect a new master. So that's the second case where you need to do a failover. And the third we talked about is take a slave and make it not associated with the master. I've given you the commands here or at least the name of the command. If you have a existing replica and you want to make it the master, you should promote to replica command... promote to master... promote to replica source command. If you have a failed master, you eject the master. And the last one is you detach a replica. Everybody clear what these three operations are? When you would use each one? Sounded like, yes. Okay. Go ahead. If you detach, how far can you... Okay, so I'm going to go out on a limb here and we'll find out if I'm right, okay? I'll detach it again. Am I correct? Yeah, I win a prize. All right. Okay. You'll see that actually. There's a slide later which shows that. You rip it off and then it's totally done. Sorry, somebody here had a question? No. All right. So I'm going to start with this illustration here. This was that instance M1. It has three replicas. A master, three replicas. It's running 5.6. This is, by the way, annotated output from Trove Show. Trove Show is actually a whole lot more information which I just ripped out from here. So this is what it looks like as a picture. I have a master. It has three slaves, 12, 13, 14. So the first thing which I'm going to do is I want to take 14 and make it the master. So what I want to do is go from this picture here to this picture here. All right. So question, anybody can answer this. Raise your hand. What's the command you'd execute? What are you going to target? Anyone, not an ATC on Trove. OK. And which one would you target? M14. OK. Promote to replica source M14. That's exactly what you do. And when you're done with that, so I issue the command Trove API, says yes, you're done. Task manager goes, does all this stuff. At the end of this, if you run Trove Show M1, it now says it is a replica. M1 is now the replica of M14 because if you say Trove Show M14, it now has three replicas.  That set of things is long, interesting, sometimes error prone, all done for you one command worth or one API call if you choose to use the RESTful API. OK, so far? All right. So now I'm going to detach a replica. So I start with, now M14 is the master. M1, M12, and M13 are the replicas. And I want to go to this situation and this answers your, this is part of the answer to your question. I just want to take M1 and detach it. And the command you'd use, of course, is detach replica M1. And when you're done with it, notice there's no mention of replica of anything. It's now a free-running instance all by itself.  But at this point, it is no longer related to the other three in any way. And you cannot ever reattach them, not through Trove at least. OK. And the last command, which, oh, and by the way, if you go look at M14, which is the master, it only has two replicas left. The third one's gone. OK. All right. And the last example we have here is a simple failover. Now I'm left with M14 with two replicas and I want to, and I want to eject this, this one as being the master. OK. M14's the master. For some reason, it's non-responsive. I want to kill it. I want Trove to pick a new master for me. OK. So a couple of things to keep in mind. If a instance is a master and it is not really failed, you can't eject it. OK. So Trove maintains a heartbeat. And I mentioned earlier that there's a conductor, a conductor service. The purpose of a conductor service is every so many seconds is to pull the database and say, is the instance really up and running? If the instance is running, you can't kill it as the master. So a little safeguard here. The second, if I try and eject M13, recall, M13 is not the failed master. M13 is a replica. If you try and eject something which is not a master, it says, I'm sorry, it's not a replica source. You cannot eject it. OK. You finally pick the right one and you eject it. It's a failed instance. And when you're done with this, sorry, go ahead. What type of a heartbeat is the heartbeat? OK. So give me a second. Let me go back a couple of slides. OK. So when you create a Trove instance, a Trove instance master replica, whatever you have, it's one of these things up here. It's a nova instance which has MySQL and a guest agent. Guest agent is a piece of software which exposes a Trove-specific API and an implementation which is specific, in this case, to MySQL. So if you had replication for some other database, for example, the mechanism for doing replication would be a difference out of commands. This guest agent generates a heartbeat every, I think it's every minute. And that message is sent by it over the message bus to the conductor. The conductor stores that in a persistent database here. So it's basically doing a MySQL ping under the covers. If you require a different heartbeat mechanism where a different command is executed, you can definitely modify the guest agent to do that. But it does some best effort check for, is this MySQL database here good or dead? That's what it does. And there's a measure for how long it should have not had a heartbeat before it'll be considered to be dead. I think that number is one minute. So we're here. And I want to eject this guy. When I'm done with it, if I looked at M12, it would say M12 has exactly one replica. Remember, you just shot M14. M12 and 13 are now the two databases left. One is a master, one's a replica. Yes? Yes. No, it comes back up properly. And here's one of the reasons why. Sorry, the question was if you had a network partition and the guest was not able to talk to Trove for a while and then you shot it and then something happens and the network comes back up, will everything be happy or not? Paraphrase, that's your question. The guys at MySQL have spent a long time figuring out how to do replications and masters and slaves. All we're doing is we're telling one guy he's the master. If you tell a person he's a master and another one comes up and says he's a master, there's a quorum election process which says, I'm sorry, your GT is not as new as mine.  So Trove does not get in that process at all. Trove just leaves the database to do what the database can do just fine. Oops, I lost my mouse. Okay, so we're now down to two instances. One's a master, one's a replica. And looking to the... Yeah. Okay, so the question was is there any automation built into Trove where if a instance fails, Trove automatically does fail-overs? At this point there is not, but this slide says, coming soon there will be. So yeah, this is... So think of the progression. We started with, in Ice House, we started with single instance MySQL. In Gino, we had replication with Binlog. In Kilo, now we actually have the ability to do fail-overs. Next step, build a mechanism to do automated fail-overs. Now part of automated fail-overs is a policy which says, how long do you wait? You might want to wait a minute. Somebody else might want to wait 30 seconds. So coming up with those, how do you actually do that is what we're going to be talking about for the next couple of days. And that is definitely something on the roadmap. Other questions? Yes, sir. How does guest agent talk to rabbit... Oh, okay. So I keep losing this mouse. The question is how does the guest agent talk to rabbit MQ? So this instance, this compute instance, which is actually your trove instance, you will have two interfaces. One interface will be the customer interface, the customer network. You come in on that to do your queries. The other is a private management network. The private management network is used to talk to a, typically a trove-specific rabbit MQ server. Therefore, that is something which is entirely off the customer's network. Is there any security issues? So the question is, are there any security issues with the guest agent talking over the message bus? The only thing which it can communicate to is to the conductor. The only thing which it sends messages to at this point is to the conductor. And the only messages which it sends are the heartbeat message and in some cases it sends other information. When you create an instance, there's some specific message which goes over that. So there are things which you have to do in order to harden it. We're going to be talking about several of those. There's been discussions on the mailing list about some of these over the next couple of days. We're going to be talking about some of those things. So one of the things which we are looking for over the next couple of days is input. And the question was, we talked about automated failovers. Is there any talk about introducing load balancing or load balancing as a service? Integration is there. I have not seen a blueprint for that at this point in time. We've had some conversations about how far we need to go in this release. Over time, I assume people are going to want all of these capabilities. There is, of course, the question of does that fall within the purview of databases of service or is there something else which you would want to do? So I'm not saying the answer is no. I'm also not saying the answer is yes. The answer is it's a good question. So we'll start at the back, gentlemen in the back. So the question is, is there a way to find the replication status of the slave through the Trove API? The answer is no. You connect directly to the slave and find out its lag.  The question is, have you integrated Trove with Heat as yet? The answer is this question came up this morning. It depends on whether you want Trove to orchestrate instances with Heat or Heat to orchestrate Trove instances. Heat to orchestrate Trove instances. I don't know the answer to that. Sorry, go ahead. The answer is yes, it does. The gentleman behind you said so. Somebody here had a question. Yes, sir. Can you use replication without Swift? So the reason we use Swift is as a place to put backups. If you don't have Swift and you have some other storage mechanism which supports the Swift API, I believe the answer is yes. And I'm going to look over in that direction and say, was I right or wrong? You need Swift. OK, I was wrong. Happens once in a while. OK, what is the question? The question here is, what exactly do you need from Swift? Is it keystone authentication? What more do you need from Swift? Or is this a question which we should hold for the next two days? OK, other questions? Sorry, it does work with who? That doesn't sound like a question. You're saying it does work with the Rados gateway, but we're not just backing up a volume. OK, other questions? There was one other hand there. Thank you. Trope didn't get into that business. Databases figure that out just fine. Trope, no, if you issue the command which says, I want to do a failover, we'll try as immediately as possible to get that command down to whichever database instant. If the database decides to say, oh, there's a long-line transaction for some reason I can't do the failover, the task manager is going to have to wait for a while to get a response. But Trope itself does not know anything about what's going on on the database under the covers, what transactions are going on under the covers. Yes, sir? So I will give you the same. So the question was, something happened, and somebody figured out that replication was the problem, and the DBA went in and did something and fixed it. Will Trope be smart enough to figure everything out? To recon... OK. So there's a little warranty on the back of my phone which says, if you open it, all bets are off. If you SSH in into an instance which is running Trope, all bets are off. Same story. Because at that point, I've given you... Choose your metaphor. I've given you a gun with a whole lot of bullets and I've said, do whatever you want with it. I have no idea at the end of that what's going to happen. You can do a whole bunch of things which Trope just has no way of ever discovering. So all bets are off. I missed the first part of that. Where in the roadmap do you... So the question is, where in the roadmap do you have integration with the Oracle database? OK, so with Trope, currently you can get Oracle with Trope from my company to Sora. I'm a Oracle 12C guest agent. You can use it. We're doing 11G guest agent. We're also talking to the community about doing Oracle pretty soon. I would give you a more definite answer in four days. We are very, very interested in... We are very interested in doing Galera cluster and we'll be talking about it with you and with the rest of the community in the next couple of days. There is a very significant interest in demand for replication. Not everybody is comfortable with just having a synchronous replication. So yes, there's a demand for Galera cluster. And we're going to do something with it. Yes, TBD at this point. Do you have ideas? Well, no. So there's different ways in which you can do it. So the question is, if you're doing replication, if you're doing clustering with Postgres, you have a number of options. I've done clustering with Postgres many years ago. I don't know what the current state of the art is. But if you do, we're going to be talking about it over the next couple of days. So come on over. You're not allowed to ask questions. I'm sorry. Oh, you're saying I'm out of time. Oh, okay. One last question. Sorry. I'd suggest we talk about that outside of this presentation. It doesn't have really much to do with replication. It has to do with whether we want to use config drive or something else. How about you combine, and there's a bunch of us who are interested in that question for other reasons. Other questions? If not, Matt and I are available for the next several days. Come on over. Ask us any questions you want. They're going to kick us out of the room. So we should probably get out of here. I'll just leave this slide up here if anyone wants to grab information. Thanks for coming.


Did you feel like this year when you were at home sitting on your couch that you would be in this position, winning the division with the Titans? No, ma'am. I definitely didn't. I was just very... I don't know. I'm really at a loss of words right now. I'm just so thankful and blessed to be in this position. God is so good. You know, just being at home, it just used to... I guess I would be at home and I would just think to myself like, I just want an opportunity. Somebody give me an opportunity and trust in me and just give me the opportunity. I just felt like I could go out there and just play my game and play well. Like I said before, unfortunately certain situations happen that led me here, but I'm very thankful to be here. Every time I step on that field, I just want to go out there and just give it my all and just show that I deserve to be here. I deserve to be in the league somewhere and just do what I can do. You know what I mean? So, it was a lot of music going. Everybody jumping around excited, happy. Just a great feeling. Definitely. I've been feeling it through the last past weeks, just getting more comfortable and just getting back into the floor of everything.  So, it takes time and build chemistry with the other guys, but I'm just so thankful for everything that's been given to me at this point. I'm just trying to capitalize on every opportunity that I'm given. I mean, when I was here last year, man, I just felt it. Just felt the energy of the team, the coaches and guys that wanted. You know what I mean? Just people that come to work every day and just give it their all and work hard day in and day out. And when I got my opportunity to come back, I just wanted to fit in with those guys. I already knew what the coach was, so I just wanted to come in here and just do what I could do to help. You know what I mean? And I think I'm doing that. A lot of guys come up to me during the game and after the game and just tell me, you know, great game, way to run the ball, keep running it. You know, and that's great to hear. You know what I mean? Just being back playing football and just all the little things that I was missing while being at home. I mean, I just take every moment and cherish it. You know what I mean? From the fans, to my teammates, to the coaches, and even sometimes when I'm running back home Coach Duzzi is getting on me. I don't take anything personal. I mean, at the end of the day, it's a job and I'm here to try to help this team any way I can. So I don't ever take it lightly, never. No day that I'm here, I'll never take it lightly. I think my approach was not to try to feel big shoes. You know what I mean? I think the approach was just go out there and play my game and do what I could do and do what I could do to help the team.  You know what I mean? He's a great running back. I think the best in the league. You know what I mean? So to be able to come in and, you know, just try to help this team and, you know, fill in what he left off. I mean, it was a challenge for sure because I'm a competitor. So, you know, I never wanted nobody to look at me like I couldn't do it or I couldn't get the job done. So, but I never tried to compare myself to him or do anything that he was doing. I just want to go out there and be as effective as I could be and help this team win games. I'm not sure what the plan is, but whatever my role would be, I'm going to fit in my role and I'm going to do everything I can to help the team win. I mean, at the end of the day, you know, the Titans giving me this opportunity, I'm just so thankful. So it's never anything that I would do to, you know, not be excited, you know, even if I'm on the bench or even if I'm whatever my role would be. Like, you know what I mean? I'm just here to do my job, do my part and help this team win games, man.


Chad what's going on five-star baseball? No, I'm afraid not If it what if we did have some you can bet that it would be on the site for sure


I met Barry last night. I have not met Kai. All right, have fun boys. All right, thank you. So we're going to do a little case study on Mazda. Come on in, Barry and Kai. Barry, nice to see you again. It was great to meet you last night, hang with you a little bit. It was fun, wasn't it? I said to Callie, it's kind of hard to be in here without the kids, but we had fun at Disney anyway and at Epcot. Kai, how you doing? Dave Vellante? Dave Vellante, nice to meet you. So Barry, last night we were talking a little bit about your organization and so what I'd like to do is set it up and we're here at the Dell Storage Forum. This is DaveVellanteWikibon.org and this is our continuous coverage, Silicon Angles coverage of the Dell Storage Forum, which is why you guys are here. So Dell, Barry, why don't we start with you. Talk a little bit about what you do at Mazda and the organization, the IT organization specifically and then we'll bring Kai in and hear from him. Well, I'm the infrastructure architect. I report to Kai, he's my manager. I have a team that handles the infrastructure of four guys, me and three other guys that handle the virtual infrastructure, the storage, Active Directory, things like that. We have a networking team that handles all of the network and we have application groups, programmers, things like that. How many total in our IT department at this point? Well, the total IT is about 80 people and we support about 1100 users internal and about 15,000 users at the dealerships. So within our organization, Barry is part of my team. We are what we call the infrastructure services. So basically what we do is we actually work with the business application team in architecting the environment for any new business application projects. So you guys are across North America? Is it U.S. responsibility? Yeah, we support U.S., Canada and Mexico. U.S., Canada, Mexico, so the Americas? North America. It's Mazda North American operations. So North American operations includes Mexico? Mexico and Canada, yes. Okay, cool. So talk about a little bit about, actually Kai, I wonder if you can start with what is driving your business? When you're talking to the business heads or the application heads, what are they pushing you guys to do in IT? Zoom, zoom. Zoom, zoom, zoom. Hurry up before we go. Yeah. Faster, faster, faster. Since we are part of the global company, our parent company is Mazda Motor Corporation. So some of the business initiatives is actually driven by Mazda Japan and so those were considered global projects. And some of them are North American initiatives, how we would do business better, how we consolidate, and sort of provide the same systems and application to both Canada, US, and also Mexico. So other projects will be more US specific, as far as if there's any target market in certain area, there could be some application that drive that. And then of course, we also have our own technology projects where we have to keep up with the technology change and we have to be flexible and be nimble. We're not very big company, so the idea for us is really to be flexible enough to change with the business requirement change. Of course, in a company, we are very much aligned with the business unit, so we have an IT manager, application manager that's servicing their business partner and then from that they do through the business planning that become our projects and then they will come to us and then we put together infrastructures to support that. So it's very project driven with like a lot of IT organizations and it's business project driven, not IT project driven necessarily. Some of them are, some of them are technology project, for example, when we initiate the virtualization, those are IT projects. Okay, and we'll talk about some of those. Before we do, what's the biggest change in the automobile industry that you've seen in the past decade? Is it the globalization? Is it the move toward cost cutting? Is it energy efficiency, all of those? I mean, what is a bit of the big changes in your industry that are driving? Well, obviously in the past few years, with the gas price rising and with the downturn of economy, all the car companies going through a little bit of transformation and as a master, we know to make smaller cars and with fuel efficiency, fun to drive and we actually have technology that coming out that can help both the performance and also greater mileage, so we're really excited about that. So from the business transformation, it's really for us to actually kind of like uplift the brand image to be like, we're not like the Toyota or Honda of the world, but you know, we want it to be one of the choices that people would like to drive cars. Must just get cool cars, right? Right, fun to drive. So we, like I said, we're not as big as those big guys, so we know that and we're not competing with them in many respects, right? So the transformation was really how we strengthen the brand and we have been really focusing on the customer loyalty and as long as it's just like any other company, if we keep our customers happy, they'll come back for service and buy more cars. Right, right. Okay, Barry, let's talk about, let's get into the whole IT infrastructure, you're an architect, right? Spent a lot of time on storage, probably virtual infrastructure as well. Talk a little bit about your shop, what it looks like and paint a picture for us, if you will. Well, we've done a lot of consolidation down and into virtualization. So to get greater efficiency, greater return on investment, it's been a very good model for us as it is for a lot of people. We needed to simplify because as I said, my infrastructure team is four guys to handle it all. So we had a very complex physical environment at one point, like a lot of companies did, trying to maintain all that environment, trying to back it up, restore it during testing and stuff like that. Disaster recovery test was becoming very, very difficult. Also, all of our equipment was leased. So we had this lease return schedule. So the benefit was we always had new machines, we had new Dell servers coming in all the time. But for the business initiative, they wanted more and more applications so it meant more and more servers. So every time the lease cycle came around, it was time to replace, our team was scrambling to replace dozens of servers. And what was the storage at this time? What were we talking about, three or four years ago or five years ago? What's the time frame? 2005. 2005, so what was the storage on the servers? Was it the direct detach storage? We had iSCSI, we were an early adopter of iSCSI. A lot of our databases were on iSCSI Lens. So we tried to consolidate and that was an effort to make it easier to maintain. So we would have the centralized sand storage, iSCSI connections, we'd be able to maintain the storage that way rather than having distributed completely into all the local servers and stuff. The reason I'm asking was a lot of customers I talked to when things come off lease, it's like, oh no, we got to migrate data. It was becoming so difficult that we were not meeting those, we were leasing servers long beyond their lease expiration. Okay, so that's not really the ideal financial strategy. And obviously it's not unique to us all the other companies are going through the same thing. So as you, not only for lease replacement, but as far as how do you recover those systems, right? The backup recovery of it and how do you do DR? And so all things combined, it just makes good sense for us. And the idea of doing more with less, which has always been the key. And so we just have no choice. We couldn't handle all those physical servers. So we set the strategy to go with the virtualization and we're just moving forward. So at that time, you said, okay, we're going to go server virtualization. There's a lot of customers do as you said, Mary. But at that point, did you say, all right, we're going to go storage virtualization and synchronize that or would that come later? That came a little bit later. A lot of storage vendors were promising virtualization, but some parts were virtualized somewhat. We're here at the Dell Storage Forum to talk about compelling because we implemented compelling. We feel that is truly virtualized storage. We do too. We've written about this extensively. We use that as a poster child. Others, I mean, three-par, compelling. I mean, those are sort of the clear, built from the ground up, virtualized architectures. So when we began virtualization, we ran into a lot of the same problems that other people did as we migrated more and more machines from physical to virtual. We began to run into certain performance bottlenecks, both on storage, networking, servers, the backup window, a lot of IO going through the ESX host, stuff like that. So the compelling storage, we looked at that as a way to solve some of those storage problems. We basically re-architected our entire virtual infrastructure. Our chosen platform is being VMware. We use the compelling storage and we upgrade our network to 10G. Because of the nature of how big of our organization is, we wanted to keep it very simple so that we could manage it. So we didn't want to do anything fancy with the raw device mappings or anything like that. We wanted VMFS volumes and just VMDKs. VMware was promising that the performance for even tier one databases would be fine on VMDKs and we took them at their word and we implemented it that way and we found that the performance was actually better than our physical environment that we had before. Really? Yes, yes. Oh, that's interesting. And this is for critical application like SAP? Yes. So you guys are virtualizing SAP? That's correct. We've already virtualized it and depending on the type of transactions we're doing in our SQL servers for the SAP, we have performance gains of anywhere from 80 to 400% in our virtual environment over our physical environment that we have. Have you virtualized Oracle yet? We don't really have any Oracle. You don't have Oracle Shop? No. We have a lot of clients out there who want to virtualize Oracle but it's not necessarily the easiest thing to do because Oracle doesn't want you to. You don't have that problem. So that's cool. SAP is very supportive of VMware. Yeah, they were very supportive. We actually talked to SAP representatives who gave us a thumbs up for virtualization. So yeah, there were quite a bit of concern especially for application, critical application like SAP. So obviously we had to reach out to partner like SAP VMware and to try to get them to kind of give our management a little warm and fuzzy feeling that say yes, they will support SAP under virtualization under VMware. Yeah, so in Dell is a big part of that too because you have the hardware platform and they can, Dell can attract in in SAP or VMware and get the attention, you know, but it must have been harder at the time for a compelling to do that. Now compelling obviously wasn't part of Dell when you chose compelling. So you kind of stuck your neck out there, didn't you? The new company, small company of Minnesota, they're not in Silicon Valley or Boston. That's true. Actually, the transition hasn't been that difficult, okay? I mean, we've been on a different storage system for the past seven years. And obviously one of the concern I have for various team, because since he only has like four guys, it's really the learning curve of how you manage a new storage subsystem. But, you know, the compelling is very different. First of all, the architecture itself and the software that they have to manage their system is very user-friendly. And so, but what really kind of help us decide or sell it to our management is really their co-pilot. Okay, so. Talk about that a little bit. People, people have been talking about co-pilot this whole week. I mean, that, that what's, I can't say enough good about that. You can't say enough good things about co-pilot, because, you know, we did, we did an EBC visit their headquarter in Minnesota, and we actually met some of the co-pilot folks and we actually see how they handle the calls and the fact that it's great that when you call support, you always get a live person on the phone. But it's a 24-7 program, right? And they're not just dispatch, they're engineers that actually know our system. In some cases, more than we do. And we've noticed that even late at night, if we had to call, the graveyard shift support technician was just as knowledgeable as the daytime shift. The quality of knowledge doesn't degrade. Doesn't degrade. At midnight 3 a.m., really. And that's really, you know, it's like, I guess, bar none, number one, the best. Yeah, so. It's a unique program, isn't it? It is. I mean, you know, everybody's got, these days, some kind of support 24 by seven, but not super high quality engineers, you know, waiting for you to call. That's right. And they do stay with, you know, if you do need some help, they do stay with us from the start to the completion. I wonder if we could get some of our consumer companies to take that kind of service. You know, like when you call a bank and you get put on hold.  Well, co-pilot would be a great method. Yes, yes. Okay, so, you know, Kai, you were talking about, you were concerned about the whole learning of a new system because a decade ago, if you went from, let's say, an IBM to an EMC, it was a whole new learning experience, wasn't it? And so you didn't have that issue with Compellent. It was sort of, I mean, there had to be some learning curve, right? I mean. There was a learning curve, but it was very quick. I've heard people say that even the help desk could run it, but don't, don't call me. Fantastic. I was gonna say, it's so simple. The manager can do it, but he doesn't. Yeah, no, don't touch my sand. Now, you guys do an iSCSI, right? You're not doing any FCOE. Yeah, we were at iSCSI shop prior and in the physical world. So, as we moved into the virtual world, we were very comfortable with that technology. We decided we didn't need Fiber Channel, any of the complexities there. We decided to keep it simple and utilize our existing physical network for that. And what were you doing before? Was it, you had a, what was the storage before, a compelling? The model or the? Was it a sand? It was a sand. It was sand, yes. iSCSI sand. iSCSI sand. Okay. So we were early adopter of the iSCSI Sand Network and it's been working well for us and simplified a lot of things. There's no Fiber Channel or HBA that we need to bring in for every server and also there's no sand switch and, you know, all the management that goes with it. So simple, right? Exactly. We kept it simple. So when we went to the virtual infrastructure, we kept it simple again. We didn't use any iSCSI initiators. We just used the software-based built-in to ESX. Kept it very simple. There was a lot of people out there saying, oh, well, your performance might not be as good and we have not. Well, that's a big concern about iSCSI, right? I mean, I talked to a lot of guys in FC land and they say, hey, if you're going to put mission critical data on the storage array, it's got to be on FC. I'm not going to do anything else. What would you say to that? Well, we have not experienced any problems at all. For example, our SAP environment, very large databases, terabytes databases and a lot of transactions going on and we don't experience any, like I said, when we went from physical to virtual, we had, depending on the transaction type, we increased our performance 80 to 400%.  So that's good. They were paid on the OSI model. Now, did you quantify the impact of the move to Compellent? Did your management want to see that? Do you use like the, you know, the hero report inside the Compellent? If you use that at all, the one that shows you the allocated versus written and, you know. We use some of that. We use some of that, but the greatest impact was actually the users themselves. The user experience was better as they would do operate transactions in their SAP GUI. They would, they were reporting a much better experience themselves. Because of performance or? Because of the performance was there. Right, yeah. And then their batch job, the nightly batch that process a huge amount of transaction or the accounting process that goes through that system. They actually, you know, that's where we see the biggest performance improvement. Did it affect your backup?  I mean, both the virtualization of the storage and the servers? We re-architected the entire thing. Soup to nuts. Can we talk about that a little bit? Because backup is a real pain. Well, let's talk about what our backup was prior. In the physical environment, we were very traditional. We had the physical server. We did have the iSCSI lines. We used some certain storage technologies to back up at the storage level, but we also did agent-based backups, you know, streaming backups, things like that. So it was very, and as the data grew, the backup times increased. And pretty soon, the backup times were overlapping with production hours. And your backup window, I'm presuming, was nodding. Creasing. Yeah, so it wasn't. No, in fact, as those processes increased, we had more need for more batch jobs to occur at night. And the batch jobs were interfering with the backup schedules, so they were competing for time. So with virtualization, we decided to look from scratch and we decided, let's virtualize all of these databases, these applications. Let's look for a backup solution that is geared specifically for VMware. So we did that. So we chose Veeam as our backup solution. We wanted a backup solution that would... What software were you using before this? Was it a traditional? Just traditional agent-based backups. Yeah, right. Yeah. So it's an agent-based Veeam. And you're backing up the tape. Backing up the tape. Yeah. So we changed it. We backed up the tape. Yeah, Veeam does a good job in VMware. I've actually... I haven't talked to them. Are they at this event? I haven't seen them, but I saw them somewhere recently. I think they might be here. Maybe it was a Veeamug. We've been very busy. We haven't been able to see much. You guys go to Veeamugs? You go to the Veeamugs? I've been to a couple, yeah. Yeah, they're good. And Veeam has a good presence. Okay, so they've got... So you're using Veeam to do the backup? So, again, when we simplified our storage and our VMware, we just used Veeamuf's volumes and VMDK's, that's what Veeam requires. So that all works serendipitously together. So we back up to disk now to Dell NX3100 NAS device. And that's D-duped? Which is... Is that D-duped? Is native D-duped in the Veeam software? Is it client-side D-duped? Yes. So it's client-side D-duped, right? Yeah, Veeam does it, yeah. Client-side. Yeah, so you're... Because presumably your IOs explode when you go to server virtualization, right? Yeah, exactly. And so you're reducing the load and the network by D-duping at the client-side. Is that correct? You see that effect? Oh, we're getting performance numbers that Veeam is excited about. So with the backup with the Veeam, the way it works is it utilizes the VMware snapshot capability. It queues the IOs on the SQL database so that we have consistent database backups and that was critical for us, especially for our SAP critical data. The IOs queues very quickly, the snapshot's taken, IO resumes. The system is immediately back online to do any nightly batch processing or production or whatever. In the meantime, the snapshot is being backed up by Veeam to disk and at high compression rates and at very, very high speeds. We have stellar performance numbers. That's all local so far, or no. Yes, it's all local. So far, we're talking just local. Right, back up to disk.  That's plans for the future. We're planning on taking the NX3100 and maybe using VFS or something to replicate that to an off-site location. So just to give you some of the performance number that we were seeing, our SAP database, it's about 3.4 terabytes in size. And with the incremental backup, Veeam takes the snapshot and that takes what, 35 seconds. And then the incremental backup itself take about between, depending on how many changes that happened throughout the between cycles, the backup, the real backup actually took from between 20 to an hour and a half. And that was it. So we're here with Mazda, we're talking about a case study and we've entered the backup realm, which is always, to me, the backup is the biggest pain, right? It's always been the biggest pain point in our industry. So have you been able to dramatically change the whole backup window pain? I mean, it sounds like, but you haven't eliminated the backup window concept, right? I mean, let me ask it this way. So you're taking, are you taking continuous snapshots? No, we're still maintaining the single. So it's daily incremental and you're doing weekly full? Weekly full, yes. And do you do anything else special for your mission critical stuff? Like do you take a daily full for SAP or for instance? No, we haven't had the need to do that. No, okay, so it's daily incremental, weekly full. Are you doing any archiving of data? That's at the application level. Yeah, we do. Which might reduce the amount of data that you have to pack up on the weekly full. Now, as we move towards the co-location, then we will also use a beam replicator and the instant recovery that beam provides. Yeah, we'll be replicating our tier one applications to another VMware cluster at another location. What do you think about this notion of taking CDP, taking snapshots every 15 minutes? Is it just overkill for you guys or do you think that has potential or what do you think? I think that has potential. I think we might be implementing that in the future for our more mission critical applications. So, do you think that you can start to, because most of the customers I talk to, and you kind of fall in this category, I think, but actually, I should test that before I say this. But basically, most customers take a one-size-fits-all approach to backup. This is our backup, this is the service level that you're going to get, and we're going to apply that to all the data. Is that what you do? Currently, that's what we do. Because there's not really a better way. Right, right now we still have a mix of old technologies and new technologies, but as we move everything over to VMware, we are beginning to use the Veeam product for that. So, the one-size-fits-all, as far as that's concerned, we want to get down to a single backup solution as we virtualize 100%. But based on the application, the criticality of the application, or tiering or stuff like that, we might employ different service levels. So in theory, you could use the a compelling system to take space-efficient snap shots, if I could use that term, right? And then do some kind of CDP, whatever, 15 minutes, half hour, and then take a copy, shoot it off-site at your convenience. Am I thinking about that the right way? I think the future will include some of that. Right now, like I said, we're not using RDMs or anything like that. We're keeping it very simple. We're using just Veeam as our backup solution. We're not using the snap, the replay technology and compelling for that. Replay is what they call it, right? We do, we have used it. It was very critical for us in upgrading our SAP environment. So we had- Oh, when you're doing the migration. Right, when we did the migration, we had 4.6, and we went to ECC 6. So, or ECC- 4.7. 4.7. ECC 6, right, sorry. So, to get from one to the other, it's not just build a new one and migrate your data over. There was various stages to upgrade both the operating system, the versions of SQL and SAP. So to do that without risking our data, we used the compelling replay technology to create replays and then create views where we can mount those views in the new servers and perform the upgrade of the databases and things like that. So that was critical for us to get from SAP old version to the new version. So from an architect's perspective, to do what I'm talking about, there'd have to be some kind of integration between the Veeam and the Component, and you really want to rely on the Veeam to do that because it's sort of controlling the whole backup. Because of our simplistic model that we're trying to maintain, we're using the Veeam. We chose Veeam as a software-based backup solution as opposed to a hardware-based backup solution. It allows us the flexibility to use different hardware at different locations. However, with Compelent, we're so happy with the product, we're going to be using Compelent at our remote location as well. But the idea early on was, the Veeam would allow us to back up and replicate that data to other storage if we wanted to. So some of the thoughts there were, as when we first brought in the Compelent and when we put together the Veeam backup solution, and today we have the Colesite subscription for DR at the Colesite facility. And so what we were kind of talking through was the what-if scenario. What if they don't have Compelent on the other end? So that's why we chose to use the software-based replication so that we could, even without the Colesite facility, we could do the Veeam replicator to the hot sites. Yeah, it's going to give you more flexibility. Exactly. Regardless of what they have on the other end. Yeah, you love Compelent, but you don't want to get locked in, and it's always good to keep your options open. Our ultimate goal is to have our own Colesite facility in another one of our offices, and our plan is to put Compelent in there. Okay, so that's going to extend into your DR strategy? Yes. All right. All right, good. I've been thinking about Dell and watching their moves of bringing in the file company Compelent. Obviously they're equal logic, and backup is an area that I think is the next untapped area for these companies to really solve. I think Dell could really add some value there. I don't know, what advice would you give Michael Dell in that regard? Well, I think he's taking the right approach, and I see his acquisitions. We were very happy to find him acquiring Compelent, because we thought that was a great match. We were already at Dell's shop, we had Dell servers and stuff. Then we already had the Compelent and the marriage of the two, and officially like that was great for us. We were really pleased with that. Yeah, I mean, it's hard, right? These small companies, they come out, they innovate. We say we need more startups, but it's hard for IT to get, adopt some of these technologies sometimes, right? Right, because you know how long, in some cases when economy goes bad, I don't, these little startup could go away. So sometimes they do have the great technology, but they don't have the big company funding to support what they're planning to do as far as technology vision. Yeah, it's a real trade-off for IT, because you want to innovate, you want to simplify, and it sounds like it's had a big impact in your business, particularly in terms of the complexity of managing the systems. Absolutely. And you grow, are you growing fast?  Yes. So that means if you don't do something about it, Kyle, you were saying do more with less, you're going to have to hire people and brute force it, and that's not a good solution. That's going to make you less competitive as an organization. Right. You know, and you're in a very competitive industry. Exactly. Good. I'd like to keep ourselves lean and mean. It's all about Zoom, Zoom, and Monster, so. So yeah, Zoom's out of the blue. I've got to throw that here.  What advice would you give them from the standpoint of an architect and then from the standpoint of an executive trying to sell this concept to his organization? Well, as an architect, I try to look forward. I try to see what the future is going to be and I try to look for solutions now that will play into that future role. So moving forward, I want to keep the key thing, simplification for our environment. The complexity that we had before was very hard to manage. And as we simplified it, it becomes easier and easier to manage. So I could get sleep at night. I don't get calls in the middle of the night. My guys get sleep at night. One customer said, I got my weekends back. Yeah, exactly. So that's from an architect's perspective. Yes, keep it simple and look at your acquisitions and technology with an eye towards the future of how it's going to play down the road. Okay, we'll give you the last word. Any closing thoughts? Okay, well, from my point of view, I think the very key to our success is actually to gain the management support at the very early on in the project. Okay, so we've been very fortunate that we have our CIO that's very much in tune in what we plan to do. And he's actually attending our planning session and the strategy sessions. And he agreed with the idea and he fully supported. And that is, to me, that's like 75% of the battle, right? So because once he endorsed that and then all we have to do is just set the strategy, put the plan together and just start executing a little step toward that plan. Do your jobs, do what you're good at. That's it, that's right. And then our CIO will take care of the rest when he'll go to the executive committee and get the funding to support what we want to do. And we make it worthwhile and we can prove that we can do more with less. You guys seem very relaxed, you know. You see, all the time you see stressed out IT people. It's easy to talk about these products. Good, they're great. Kai Sukwongzi, am I saying that properly? And Barry Blakely from Mazda. Thanks very much for coming on theCUBE. It was great having you guys. Thanks for having me. Good meeting you last night and nice to meet you today, Kai. Thank you. Take care, we'll see you guys later.


and it works natively in browsers. And that's part of the reason it's kind of become so popular. You can do a lot of really cool client-sized stuff, which I'll script. And if you want to develop it, you can console log and do some stuff in a console like it will suit a little bit up for, because it's available natively. It's so much easier to develop for static sites using JavaScript, so you can have less storage needs and you can have less computing needs and you can find cheaper or free hosting options as well. React is a JavaScript framework, so it's used as JavaScript, and it's essentially bootstrap for CSS. It's a decent, really cool, like Gatsby, which is a great option if you want to. Gatsby's like Jekyll. Who's used Jekyll before? It spits out pages where you deploy to your server. And Gatsby's like Jekyll for React. It spits out this static site that you can put on the server and it handles a lot of things like routing. WordPress has routing built-in, so you can do a lot of dynamic linking versus hard code linking. It has comment, which is kind of like the WB, which is nice to read, React, like I mentioned. And let's see you get up and running React without any configuration, which is going to save you days when you try to do it and it can also allow you to build a production. And it's not going to be a simple exercise. We're going to create a component that pulls into a list of all the WordPress posts through the API. Let's take a look at the poll. Now, those three things, or those two things are really all we need to look at is the app.js file. And then I created a components folder with a post.js file, the apps.js. Now, it's importing a couple different models. The ES6 app on the county, let's you pull in pieces of info that you need at a time, so import React, and we're going to create a work component. We have React uses what's called JSX. It looks like HTML, but we'll go back to HTML and we have to close everything. And let's do pass and different attributes as well. So we're just going to do h1, and then we're going to throw in our post component. Let's take a look at the post. Looks like handle, so we'll kind of bridge it down. We're just pulling in React. And then I also created a JavaScript. Honestly, just, so in there I have the two endpoints I was talking about, post and pages, and we're going to use posts. And we have a single post component. Now, I could have thrown this into its own file and then called it in, but I just wanted to show you guys that you can do it in the same file. Now, this is called single post. And what single post is, it's just a div with an h2 inside of it, about a second. But this is going to popularly work at every single post that we have. And then this is our post component. So we kind of walk you through it. The first step is to construct it, which we can set up our state. And the state is really the magic behind React. This lets you kind of change, deal with interaction on the side, let's you deal with data. And then you're going to have what's called life cycle methods. It's going to be showing you where you are in rendering this. We're going to have a life cycle method and then we're going to fetch our data. And that's just calling a map through all the batch data is where we're calling our API. We're calling the data, specifically the post data. And then lower down, we're going to say for every post that we get, let's render a single post. And let's take a look at the batch data function. Now this is using ESX. You can batch that in point we created earlier and that's just going to be a URL. So you can just hardcore code a URL in there as well. And then you can tell to parse it as a JSON file so it knows how to read it correctly. And then you can do something cool with it. And then you can cache errors and font a lot of those out so you know what's going on. So let's take a look at that data and then the error function. That's where we're getting our data. So we're going to console out that out. And then we're also going to set the state of the post that we created earlier as the data that we get. So the data stored has opened that up and shows you this bit's a narrative three complex which is the three posts that I have created. This is the console out there. So to recap, we have set our 10 points at state or there's another one that I track. And I love using that file for primary and static site development because you can hook that up to your GitHub repo. So the order you want to do this is you want to host your WordPress first and once that's live, you update your endpoints in your React project to go to the live site. Make sure that's working and then close that React project. And React isn't your speed. You should just start by learning ESX because React and JavaScript is getting more and more popular and a lot of companies are calling in data so it's a good time to learn. If not, React is ESX JavaScript. And you don't have to completely move the headless if you don't want WordPress as to add this like layer of functionality that the API allows you to use. For example, you can have a load more button on your site that loads the next few log posts instead of refreshing the page or using pagination. You can have like a clock button like on medium where you just add tops and it'll reactable, set the state and use a post request to update the backup. You can have a Twitter like button on post that updates your like account or comment account in real time instead of refreshing the page every single time. So that being said, thanks for your time. There is a big form on the to have a link to the plugin and then there's a bunch of back and forth to be able to post there and find out. Yes. So you first of all made your presentation really fantastic. Do you have any tips for anyone that wants to make sure they continuously, now that they're moving to JavaScript to decouple their credentials from their code or so, you should have a PHP to guard their secrets. Any tips for decoupling that labels? What cases would you need credentials? Sure, so like for example, it's very common in many people's PHP projects to be calling other APIs with their API keys built into it. So I guess any word of advice for keeping those two concerns decoupled while they adapt to this new environment. Yeah, so in WordPress it's react itself like WordPress API itself a couple of end points you do need authorization for. So you can set a co-author, basic copy, you can set that up within function stuff you have to be able to have. A lot of the stuff I was talking about though, that stuff you can...


Hey everyone, welcome to another video lesson from navigationtrading.com. In this video I want to talk about what happens if I get flagged as a pattern day trader. So let's jump in and talk about what this means. To start with let's define what is considered a day trade and that would be if you buy and then sell the same security on the same day that's considered a day trade or conversely if you short that security and then buy it back on the same day that's considered a day trade. If you hold the trade overnight that would not be considered a day trade. Now when we talk about securities we're talking about stocks, ETFs and options when it pertains to day trading. So what is a pattern day trader? Well if you day trade four or more times within five business days then your broker will flag you as what's called a pattern day trader. Now even if you stop day trading for five days your account will still be coded as a pattern day trader. So basically you can trade three times up to three times per five business days and get in and out of a trade in the same security within the same day and not be flagged as a pattern day trader but once you hit that fourth or fifth or over four or more then you're automatically going to be flagged by your broker as a pattern day trader. Now this really matters if your account is under $25,000 because if your account is over $25,000 you can day trade theoretically as much as you want your account will still be flagged as a pattern day trader account but you're not restricted to just three trades within that five business days. However if your account is under $25,000 then you will be halted from trading anymore until your balance goes above $25,000. Now they will still allow you to close trades but you won't be able to open any new trades if you've gone over that three threshold within five business days you won't be able to enter any new positions if your accounts under $25,000 and you must maintain that balance on every day. If your accounts above that and then you fall below $25,000 then you won't be able to enter and open any new trades. Now the whole pattern day trading rule with the $25,000 minimum in my opinion is just completely ridiculous. This went into effect there used to be no minimum balance or I think it used to be $2,000 minimum balance until early 2000 and if you were trading or investing in early 2000 you know that was the dot-com craze and there was a lot of just all sudden new brand new genius day traders because the market was going up in just leaps and bounds and just unbelievable so all the so-called day traders came out of the woodwork and that's when the brokers and FINRA the SEC came out and set these rules that you had to have a $25,000 minimum. Again it's just for the brokers to cover themselves but the reality is anytime that they restrict you from doing what you want with your money in my opinion is ludicrous but regardless of my opinion we have to play by their rules otherwise you can't trade so that is the situation. Now the other thing that's crazy about this and it's a completely different governing body but futures and futures on options do not have these restrictions so you could literally have $5,000 in an account and get in and out of the same futures or futures options all day long and it's no big deal you can do that with futures. Now the crazy thing is futures are much larger contracts so the fact that they allow you to do that with futures but not with stocks and options and ETFs it's kind of a little bit backwards right but that is the rules but just keep in mind those rules do not apply to futures or futures options only stocks ETFs and equity options. Now in navigation trading we do not do a lot of day trading the only time that we will actually enter a position and exit it within the same day is for example if we put on a spread and the underlying symbol that we're trading explodes in our direction and we want to go ahead and close that and book in that profit. Now most of our trades take several days to several weeks and if we're rolling sometimes several months but there are times when we do get in and out of positions on the same day and so if your account balance is under 25,000 you just need to understand that that will be counted as a day trade against your three that you have in a five-day period. Now the other key thing to remember is we're trading typically multi-leg spreads so a vertical is two legs an iron condor is four legs so if you get in and out of an iron condor within the same day that's four different legs that's four different options that you entered and exit so you would be prohibited from doing any future trades and your account would be flagged as a pattern day trade account if that happens so you've got to be real cognizant of that situation especially if your accounts under 25,000 dollars or near that level if it's quite a bit over then you don't really need to worry about it because you can get in and out of trades as much as you want. So what if you do this by accident what if you accidentally trade in and out more than three times in a five-day period and your account is under 25,000 the first thing you do right away call your broker just call them let them know what happened you're not going to sneak one by them just let them know what happened let them know it happened by accident and many brokers will give you a one-time exception if it's done by accident your account will still be coded as a pattern day trader but they won't restrict you from entering new trades as long as you you know let them know hey I'm not trying to get in and out I just accidentally did it and so can you please lift that restriction this one time now typically they're not going to do it a second time so if you trade in and out more than three times in a five-day period again then your account is going to be restricted from not being able to open any new day trades until that period's up so keep that in mind so those are the basics of the pattern day trading rules if you have any questions let us know if you want to see what else we're doing here just check us out at navigationtrading.com talk to you in the next video


two on one out on Aaron. Judge stepping to the plate. Of course. You know, you know, good at that by Gio to start things. And then, you know, DJ going the other way. And then, you know, judge he got in the really good count, obviously, and really put a charge into one. So, you know, they did a good job of holding us down. We had a couple opportunities throughout the game to, you know, extend our lead. And I felt like they made some really good pitches against us. And then we're finally able to break through again there to finish it off. That was, it was huge. You went to the last after the rain delay, ran into a little trouble, settled in and then pushed him for that eighth inning. Was there any consideration of using a guy like Tommy Cainley in the eighth? No, Tommy wasn't available tonight. So, you know, we're going to go with low there and try and get it to Brit. If, if, you know, I was probably willing to go to a four outsade there, save there with Brit. If, you know, it got down to Smith, but, you know, wanted to ride low through that, through that inning. Is Cainley okay? Well, we'll have something on that tomorrow. Take the next question from Bruce Beck.  Absolutely not.   But, you know, for guys to continue to grind on, on obviously a rainy night, a long night where we know we're going back home. You know, proud of that effort where the guys really, really were able to stay locked in and, and, and finish off a victory. Kristi Acker, go ahead with the next question. Hey, Aaron. What's your concern or what's going on with labor? I know he's just has confusion, but is that something that could keep him out or? I'm not too concerned.  You know, so he's kind of day to day with that. He could be in there tomorrow. We'll see. We'll kind of see how he is when he gets to the field. So I'm not, I'm not concerned that it's a long-term thing, but, but it could be potentially a day to day situation here in the next couple.