Hey guys, we are recording. So we will discuss today about a variety of other architectures like we did before with Netflix. And the examples we would like to cover today include e-commerce, that's one. We have other things also to include. For example, we already discussed this media sharing thing, which is about what we talked about last time. Here is more of e-commerce. This is about e-commerce as to how, I think this e-commerce thing is split into three parts. This is the part number one. Then we have it in a couple of different parts, which is the part number two, which is the checkout service. And then there's part number three, I think, which is this, no, not this. Yeah, where is it? It'll pop up, it'll pop up eventually. There is a, I think the ordering is wrong. I have to change the way it is sorted. And by name, that should do it. And so the sorting by name should fix the sorting issue. So we have the examples on disaster recovery of local applications. We have examples on e-commerce, like I mentioned. This is also e-commerce. This is about how does a company like Dropbox operate. This is a Dropbox scenario or box.com scenario or file sharing, OneDrive scenario. That's the file synchronization service. We have this idea behind how banks operate in grid computing in financial services sector. We have this idea about ensuring far-tolerant and high availability of any kind of design that you can apply this to the Boeing company if you like. If you have, this is a online gaming architecture. This you can apply to any kind of online games which people play online, that you probably play games online also. We'll discuss case studies about this thing called Nintendo. What is it called? Pokemon Go. That game, we'll have a case study for that to discuss in this picture illustration. We have other large scale data sets like big data analytics. How does that work out in the cloud? It is log analysis. That is another idea. We have media and content serving. This is something that we are doing right now with a live stream source. This is our Zoom conference. And how does the Zoom conference allow you to see my desktop from my desktop to your desktop? So you're streaming this direction and it shows you a live movie. How does that work out in terms of a design and a layout of an architecture? You will understand those aspects. This time series processing, which is concept of sensor data, like Internet of Things, IoT. That collection of statistics, collection of data from variety of sources of sensors that you collect and aggregate and then eventually find out intelligent useful information that this person will grab and analyze and then make use of. That's another idea. We have one more which is about simple web hosting. So you run sites like the Cloud Genius site, for example, or other variety of websites like CNN.com, New York Times, all the other big traditional web hosting sites. This is what Amazon recommends as the architecture design. And there are more probably. So we will cover these things depending on how much time we have. So my question to you is where do you want us to begin? I want to begin with e-commerce. That's the thing that I think I want to do. But of course, I'll let you pick and choose. You saw a list, a quick list. So my question to you is where do you want us to begin? Yeah, e-commerce sounds good and also the web hosting that thing also because it might help for us. Yeah, fair enough. So web hosting, let's go understand some of the ideas here. In simple terms, let's understand what this picture is trying to tell us from an Amazon reference architecture perspective. As you remember and recall, this is an Amazon specific implementation example, meaning it has all the things here that are specific to the Amazon company. And I would like you to remember that this doesn't mean that this can be implemented only in the Amazon cloud. It can be applied to any cloud of any nature, anywhere else apart from just Amazon. Amazon has prepared this piece of paper. So they have their name all over it and they are basically using their own service names. For example, the elastic load balancing service or the relational database service from Amazon or S3 buckets from Amazon. So it is branded according to what they think is the right direction. But that doesn't mean that this diagram is right or wrong. It just means that it is an Amazon recommendation. But the recommendations itself are pretty darn good. That's the reason why I cover it. Now, let us look at from the user's perspective. What is a typical web hosting application? A typical web hosting application involves a user who's basically visiting and sometimes just reading, sometimes browsing, sometimes logging in, and then making a session, establish a session, and then getting custom data out and then log out from that session. So they're doing some transaction, some sessions, some transactions that might happen. And as a consequence, they will log out of that. So that's the entire flow of data. Most of the idea that you will see in a classic web hosting is read operations. And then some data is actually log in and log out and in between that is this idea about transaction and data handling between the user, the client and server. So that's the classic web application. Now from a web deployment perspective, a typical application will have your web servers, and they will interface with some kind of application server. And these guys will then interface with some kind of a database layer. And these guys will then interface with other things that may be necessary. Like for example, you might have, actually the way they interface with is another database slave, for example. And so they will basically involve a failover scenario. These application servers may be scaling out and scaling back in depending on whatever the load is from these users. Similarly, these web servers will also scale out and scale back in depending on what is needed. So what you're looking at right now is a very simple three tier architecture. Now let us see what Amazon is trying to describe from their pictures perspective in our discussion about where did that go? Okay. I thought I had it right here. Media sharing, time series, there it is. So now if you look at this illustration, this is the end user customer. And what they're doing is the first thing, doing a query on the DNS records. This DNS query is basically similar to what you will see in any example where you have a state of a user. Let's say if I want to go to cnn.com, what do I do? The first thing I do is I will go do a dig query. Now I don't do this manually every time I want to go to cnn.com, but that's exactly what happens behind the scenes when you visit cnn.com on any website. The first thing to do is to find out which are the A records, the answer records or the DNS entry for that name. And so here the response comes back with four different IP addresses. So that query that we did happened with the help of a server that I have running in my office, which is this IP address, which is the server is my DNS server. And so the same thing happens with you or anybody else as a user is that it requests information from DNS in form of where exactly do you want me to go when I go to cnn.com is a query that you have to ask the DNS answer as an A record response. A record response will come back. And this A record will basically point you back to some kind of a load balancer. This is the front end where that company will be hosting your one, two, three and four different IP addresses corresponding to this name and the corresponding A record. Now that big query will actually go and dig the cnn.com name server, which happens to be Amazon Web Services DNS. So Amazon has a service called Route 53. That is what they are using here. And so CNN happens to be using Route 53 DNS service. And they have these four A record IP addresses. So there's IP address one, two, three, like that one, two, three, and four. Four IP addresses, they all map to these endpoints here. This is the load balancer endpoint that they have in multiple places, multiple locations worldwide for CNN audience to be able to access a load balancer behind the scenes where they have these web servers. And these web servers are in two different regions. One of them is this side of the line and the other one is that side of the line. And these two segments are basically dividing how your regions are split into different availability zones. Somebody just showed up. Let's see who's there. Kenny. Hi, Kenny. And so you have in this region, there is this availability zone and this another availability zone. What you have done in this illustration is that if you happen to have a load balancer, you will have web servers like these in AZ and another AZ. If you create a auto-scaling group like this and another auto-scaling group like this, input them into different availability zones to improve high availability and you have your load balancer, which is, in this example, elastic load balancing happening through Amazon Web Services ELV solution. But it doesn't have to be that exact load balancer. It can be any load balancer that you want to use. That will come into play and it will primarily what you do is help your users interface with this user, allow it to connect through the load balancer to any one of these web servers that you have. So we have right now in the picture, one, two, three, and four web servers showing up. And they are in a auto-scaling fault tolerant group with multiple availability zones. Now, these web servers will typically be either NGINX or Apache servers. And they will be handling traffic coming from a second internal load balancer. Now, this picture translates to something like our diagram here, let me just draw that piece for you. And so in our, let's go back to sorting this modified bit. And we look at our illustration that I was drawing here. And so if you now compare this picture with the picture that I'm going to draw right now on the sheet of paper, you have this user who is trying to access, say, cnn.com. And then it reaches a load balancer of some sorts. It can be Elastic Load Balancer from Amazon. It can be Google Load Balancer in Google Analytics cluster. It can be your own load balancer you create using F5 networks. Or it can be HAProxy. It can be any other load balancing product that you run. And you will basically allow this load balancer to connect to a multiple different number of web servers. These web servers that you're looking at in the picture that you saw here are these four units, one, two, three, four that I mentioned. And they will run something like NGINX. The purpose of this web server is to speed up response. Speed up the response. So if a person asks for something, that's a request. And you want to speed up the response. So the idea is that if you have a person asking for a request, the quicker you respond back with a response, the faster that website is perceived to be. So you request something and immediately get a response back. That's the whole point of fast websites is to give you a response quickly. And so the fact that you have a web server fronting your requests and don't actually hit the application server directly, what you're really doing is reusing and not putting load here, not put load at the application server. Instead, serve the traffic right here from the web servers itself. And that speeds up quite a bit because you're not bothering your application servers at all. If you can do without the application server and just send a response as quickly as you can, that's a great thing to be able to accomplish. And that is exactly the purpose in putting together a set of web servers right here in this segment is that you don't have to bother your application servers at all. And application servers will run some code of some sorts. And they will process the application that you need to run here in these application servers. And accordingly, they will generate some HTML, CSS, or other responses. And that response will be then eventually handed off to the web servers. And then web servers will be effectively delivering it to the customer. That's the typical design. However, what happens is roughly about anywhere between 50% to 80%, quite a bit of a traffic that you see coming to the user from application server is repeated responses. Same response coming over and over again for most of the time. Most of the time, if you open up, say, a website like CNN.com, and I open it and you open it, most of us are seeing this exact same picture for this moment. Most of us. Sometimes in different countries, you'll have a different view. But that's what you see. And so if you look at this HTML, CSS, JavaScript combination, that doesn't need the application server over and over and over again. In fact, if you have this application server create a response one time and store it right here in the web server as stored HTML, this is generated HTML at the application server. And you store it right here in a web server as a cache. And now this person is asking you for the CNN's response. So you don't have to ask the application server to create that response again and again. Instead, you reply back with the cached that you have stored in your web server and say, hey, here is the response. Now sometimes, the person who is going to go there might change the edition to another edition, like Arabic or Espanol or some other location. In that case, you have to, again, construct a different language interface and a different set of output comes out. So here, you see that once I switch the language to Espanol, you see the result coming back as different. That can be a different set of stored HTML generated by the application server for Spanish language. And so you will see that caching has a tremendously big role to play in any kind of web deployments. And I just forgot to put my microphone back. So I'll put that back in place. So the idea behind here is that you notice that caching is actively happening. And this is one of the dominant reasons how websites speed up. And the architectural diagram here basically points to that same idea, is you have these web servers that are responsible for caching up and not loading up your application servers too much, unless necessary. And at that time, when it is necessary, you have your code will generate fresh HTML and then respond back with the actual answer. So if this guy says, I want to log in, then that log in session may be something unique to that user. In that case, this web server will have no idea what that user expects to see when it needs to be generated by depending on the application logic. And in that scenario, that generated output has to be created by the application server, as opposed to when there is no login at all. In that case, the application server does not need to be bothered at all. Now, when you have a user logging in, the response is typically slow. You will see in any website which enables login, you'll go to, say, this website, for example. And I will now, first of all, log out. And so here is me logging out right now from the log out button right there. Log out. And now here, if I go to the website on the front page, what you see is this page loads up very, very quickly, very efficiently. But the moment I sign in, the application server is going to kick in right there. And this process of logging in is actually a little bit slow. Now, you see that it is slow because of a specific reason. The reason is that this machine is kicking in, and it is processing my login. Therefore, it needs a little bit more time than a ready server of the web server. That's why when you log in and you get to the dashboard, it is a customized page with my name showing up right there, like that. And that is not cached. But this page that you see logged out is cached. So it loads up very quickly. If I go to the front page, this one loads up very, very quickly because this page, which doesn't have a login state, is cached already by the web server. So you are served that page very, very efficiently and effortlessly. Excuse me, give me a second, I'll grab water and come back. OK. Sorry, guys. So the point that I was discussing was about speeding up when you have a web server in front. You may have seen this kind of behavior in almost every single site that supports login and has at least two layers in terms of application generation that generates the application base's specific code, and then a set of web servers that just dumps the output back to the user. That's the performance boost that you will see caching happening at the level of web servers to some extent will help you offload some of the work that these application servers have to do. And that's the whole reason why we have one more tier. If you go back to this same idea and extend it to multiple levels of caching, you will see some interesting examples. And that's what I want to show you and highlight those aspects to you. Now further, if you go deeper in from a request coming after a login or a request for login, you will see that this user who attempts to log in will go through the load balancer, gets assigned to one of the web servers. The web server will find that it requires a login. So it cannot handle login. It has to go to the application. So then it hands off that logic to a load balancer, which is an external load balancer. This one is an internal load balancer, internal to the application itself. And the customer for this load balancer are these web servers. They will interface with this load balancer and then get allocated to one of these application servers that you might have, one, two, three, four, or any number of them on a scalable platform like that. And one of them will actually respond to the inbound request. The request was, in this example, a login request. And so the transfer of traffic hands off from the web server straight to something like from here, goes through and through, through this route, maybe through to this server. And so that's the route you will take. And if that's the route you happen to be taking, then this user will have its login session generated by this application server. It will have the session stored in the user's browser in a cookie. And then that information regarding the presentation of that particular user's page, like you see when I log in here, that presentation here, when I log in, let me log in. And it's taking time, because it does take time to go to the application server to interact. It'll come back and show me the dashboard that I expect to see, which is on the dashboard button. It has my name, and this custom generated page is actually calculated based on a data store. So this data store that you have is typically a database of some sorts. Could be MySQL database, could be Postgres database, could be Oracle database, could be any other type of databases that get deployed in a deployment like that, will actually store an entry for me as a user. The user level details are stored in the database. And that detail has to be pulled up from the database. So there is a query involved here in order for a login session to complete and a cookie to be placed in the user's browser. That requires another added level of interaction with another set of database servers. They can be more. Here is one database server which replicates itself to another database server in a standby mode. And that is what this illustration is trying to communicate. Now, from an actual implementation perspective, this is the Amazon's web hosting example. From modern container-based application deployment, the picture will look somewhat different. And I will draw that picture, which is not this picture, but conceptually implement the same picture in case of containers and deployments like Kubernetes or scalable deployment like Kubernetes that you saw before in multiple sessions. You will see now the same idea implemented in case of how would you do this with containers. So from a user's perspective, the user will interface with some kind of a DNS query that lands to a load balancer. And this load balancer is typically your what is called in a Kubernetes environment. It will be called an ingress. And that ingress maps to a service. That service will map to a set of deployment which will have a bunch of web containers as opposed to actual machines running web servers, it will be containers running NGINX. And that deployment will be any number of them. These are your web containers. Now, subsequent to that, it can then interface further with another service. And this service could be your application itself. Let's call it the application service. And here, again, this will interface with another deployment. And that deployment will actually contain containers that will run your application. It can be any number of them. It's a scalable setup. And this is your application containers. So, conceptually, it is very similar, as you see in the other picture versus this picture. In here, we don't have actual physical machines or virtual machines, but we are dealing with a container-based deployment running in a pod across multiple number of pods, any number of them, depending on how much you want to scale. And they interface with the user through a load balancer. They interface with the user through a load balancing ingress that maps to a service that connects to a deployment running your web containers, that in turn connects to an application service, that in turn connects to a deployment running your application containers. And this goes on. You can further extend this illustration to another level, which is this application containers will then interface with a service running your database containers. And these database containers can be one or replicated or depending on whatever other service that you might be using, an external service you could use, external service, such as every cloud provides some kind of a database as a service. You can use those services that are less of a hassle to run containers with a database service inside. It is quite a bit of a hassle because it requires very delicate management and administration in making sure that things work out. So most people that I know actually avoid that hassle and don't deal with running databases in containers, but you can technically run, there's nothing wrong with it. So from the same conceptual picture, as long as you're looking at this illustration, from a concept standpoint, you don't look at these as boxes of VMs, but instead look at them as containers and parts in a Kubernetes, you will have the same idea implemented effortlessly without having to worry about all this complexity of dealing with web servers and application servers. If you can just create a deployment here for web deployment and a deployment here for application deployment, you can accomplish similar setup deployment. You can accomplish similar setups effortlessly if you happen to use Kubernetes and put these in a YAML file and just say K apply this, K apply that, and your infrastructure gets up and running effortlessly and you don't even have to worry about other things like making sure that your infrastructure is ready, your VPC and all those things are just handled for you in case of, and if you have an orchestrated deployment of a container architecture like we discussed in Kubernetes example. So that's this idea about web hosting as a set of applications that you want to run in some kind of a cloud environment. And I would prefer that you run it in containers, not VMs anymore. People don't use VMs these days, newer companies are not using it. Modern technology companies are not using VMs directly, they are using containers and I want you to remember that is to just go away from VMs and containerize everything and run it in Kubernetes. That's how it is recommended. That is also open source and it is the best way to run containers today and run any application by the way today. So remember that and make sure that you do it that way. Now having discussed this bit of a piece, I would like to now, why are the notifications coming in? Do not disturb, okay. So the example that I want to now show you in an actual live implementation of this exact story, I have it ready. In fact, the cloud genius site runs pretty much like this, except it does not use VMs, no VMs here, it uses containers and I'll just quickly show you what we have running in as an example. So this site that you're looking at actually runs in live containers and I'll just show you, I think I've scaled it down considerably right now because there are not many people hitting the website so it has shrunk automatically, but let's go see what we have. So if you look at kget all, that should bring us some answers. So let's see what do we get. So if I'm going to connect to my cluster and say, get me all the things that I have and more it, I mean, show it on a page by page basis, you will see what I have. It should come back with every response that you will see. So here we have the very first page. You have a bunch of parts. So let's go focus on the interesting parts. There is a part called, that's the part I think we are having called part slash BEACG, that's the cloud genius website. And that part is running only one container running and only one part running right now for last 16 days. That's the actual part running that site that you're looking at, which is this site, the cloud genius site. In addition to that part, this part, we have a service to go with and that service is this service, BEACG CG WordPress. That service has a static IP, internal static IP assigned like that. And it is exposing itself on port number 80. And it has been in active state for last 51 days. In addition to that service, we have a deployment that is related to the same set of site. So this site has the service name. Correspondingly, we have a deployment that manages these set of parts. Right now it is only one part and that is this part. So only one necessary to handle the load that we have. It's very light load right now these days. And so we don't have enough traffic going, only a handful, maybe 20 people or so are hitting the website right now, it's very low. And that's what you're looking at. The people who are actively using is like 20 or so right now. So very low number. So this container can effortlessly handle, only one of it effortlessly handling it. We have the corresponding service that I mentioned here and the deployment that controls the size of the cluster or rather cluster of parts is this deployment, which currently says the desired is one and the available is one and available for last 51 days. And it has been going like that, no problem, effortlessly. And let's go see further missing elements. So I'll go now press the enter button and maybe a space bar button to get to the next page. We have some replica sets defined here for the cloud DNS WordPress website, which is basically creating only one replica right now, only one available, because that's the necessary need we have. We have a replica set that I already talked about. We have a job running here that is doing a backup. And it was one backup desired, one successfully done two days ago. It ran a backup and it is doing that backup service on the live site. Let's see some other things that may be available here. We have a couple more backup jobs. The three backup jobs, one was two days ago, one was one day ago and it's a 20 hour ago. So these are basically daily backups happening. And then we have a cron job running. This cron job runs every eight o'clock in the morning. Is it eight o'clock in the morning? I don't know. I have to check this cron tab as to what it means, but I think it is eight o'clock, but I have to confirm whether it's actually eight or not. So we have to read that cron syntax to understand when it runs. But apart from that, that the extent of parts and services and deployment that I have running in my cluster, for that one site. And there are like these, there are several sites running in the same cluster. Now let us see in a picture form what minimal design I have implemented right now for this web application called b.a.cloudgd.us, that website. In effect, what we saw is a user hits only one ingress endpoint, which is where this endpoint reaches the service internal. The service is called b.e.a.c.g. And that service interfaces with only one part, which is also called b.e.a.c.g. And that part interfaces internally to a database. Now I'll show you the database piece also. This is the part that you interface and an ingress that you have with that name associated. So that this person can actually reach the part running the application right there. Now this database is externally hosted. It is not inside Kubernetes. You will see that the database that I am running is actually in a third party service. And you will see that right now in live, which is in my production account. So I should go to the production login right there, production account. And this should take us to a third party service hosted at Google. And that service is database as a service. And that is this database SQL. And that service is running one instance of a MySQL database second generation. And that is this database running here. It has some number of users, some number of databases, some authorizations, SSL enabled and some backups and replica. And the total number of usage that I have here, I think is about, yeah, that's the usage number. For the last 30 days, the usage has been going up and down a little bit. You can see that the usage patterns have been reasonably below about 4 GB or so. This thing is running only one CPU, roughly about four GB memory, 31 GB SSD allocated. And it has been running like this forever. Literally forever. Ever since I started using Kubernetes, this service database service is running and I just store my databases here and let them handle it. So that I don't have to worry about it. And what I do is have my pod interface directly with a service. This is externally hosted by Google, hosted by Google. And that, if you compare this illustration, it's a very simple illustration, but the key thing to remember this idea is actually scalable. So as soon as you put some load here in terms of lots of people like that, this will grow automatically and handle the load for our users. And right now the load is low. So this part is only one part right now. That's the picture illustration. If you compare that with the idea here, it's conceptually the same, except they are actually using virtual machines. So that's the overall concept of a web application deployed in three tier architecture as shown in this illustration reference architecture as recommended by Amazon. If you want to access all these PDF illustrations, they are available by Amazon on Amazon's website, I think somewhere in a location called AWS Architecture Center. And that location will have these pictures already for you. You can just browse through. There are a ton of information available for a variety of things that I have captured only 14 or 15 of them that I find interesting to talk about. So I bring them up in this notability sheet, which where I describe these things. And so before I switch topic away from web applications, I would like to ask you if you have any questions on this idea before we switch to, there are so many of items that I want to actually cover. So my question to you is, are there any questions specifically that you want to ask on web server application or web hosting architecture before we switch over to another topic? Did we use the load balancing thing? Yes, in AWS, Amazon thing? Yeah, in Amazon. You mean, did you and I did an exercise? In a practical lab? Yeah, we did that. Okay, okay. I'll show you where we did that. Hold on, hold on. So we did it multiple times. One of them by hand in the cloud technology section here. Yeah, okay. In there, we did it one time, we did it by hand. The second time we did it through automation. That automation exercise in the architecture section is available in, let me pull it up, in the architecture section. If you go search for N-tier, you will find it is this architecture called, sorry, in this exercise called blueprint for N-tier architecture. That is where you will find a Terraform code that has a video walkthrough right there. Okay. And the code is available in this location and that code is available from here. You can pull it up and you can see that this Terraform actually creates a load balancer right there. Yeah. So this is the load balancer we used and we were able to actually show you a scenario where we had a load balancer in a public subnet and a private subnet has two application servers, app zero, app one, and these guys were running Docker containers. This also running Docker and we ran Nginx here as a Docker containerized application. And then I was able to modify this Nginx something different from the other Nginx and we were able to ensure that cookies are persisted and cookies are not persisted and round robin and handling cookies in Firefox browser, cleaning up cookies and see the transition from A to B happens. We also did this ELB thing was a key thing to discuss at that time when a user hits, the user hits actually the ELB. We also had a NAT device set up here. We had a VPN server sitting right in the net box. That was the exercise that you recall is this one. So that's where we used a load balancer. Yeah. Okay. Any other questions on the web illustration that Amazon has it here? Good, good. Okay. Okay. So if you want to set up a web service architecture of some sorts, you should consider using a Dockerized container. Don't go to a VM. I know you like VM. I know you use VMs, but don't. And the idea is to containerize. And I have actually, I was working on a simple idea to containerize applications and I think I might have it ready here. I'll just show it to you quickly. Let's see if I can find it quickly. Yeah. It's called holy cow. I think I found it. So let's see, get remote. And I have this repository. I'll grab it and give it to you. So you can actually run it. It's a very simple exercise to help you understand how do you containerize some application. And the idea is to give you in Slack. So what I will do now is paste a link for you in Slack or you can just go to this location in cloud genius website and grab that source code, which I have here. And that is coming up. It is a very simple Docker file, basically. And what I'm doing is I have an application called Cowsay and Fortunes. Fortunes is the fortune cookie application, which is just, you know, gives you the response is it reads out random fortune cookie messages. That's what fortune application is in Unix. And Cowsay is a funny way of showing you the output. Nothing more than that. So if you have these two applications and you want to containerize it, how would you do that? It's a quick example, quick and dirty example. So that is what we have in this illustration. I have the code in Slack chat for you. So you can see it like right there. And I will now see if I can run it. So in that folder, I have only two files in there. It's a very, very simple application to understand how do you containerize anything that you like. And so a simple example is this. We have a Docker file. And what we will do is containerize the fortune cookie example that says, whatever it says, you know, let's go run it to see and understand what it's going to do. So here's the readme file. And what I want to do is build the Holy Cow application. How do I build it? I just run this command like right here. Docker build Holy Cow or other dash T Holy Cow with a dot, dot indicating, look at the Docker file stored in this machine right here. And I need to run Docker. So I first start Docker and then I can run the Docker command and my Docker was not running. So on your web browser, you should be able to see that this Docker file is actually going to be used to create a new container image that I will be then running to create a runtime container that runs fortune and cowsay. And that's the command I'm executing to generate a fortune cookie message and pipe it through cowsay. And you will see what it means. If you're not familiar with fortune and cowsay, it's kind of hard to understand. But once you see it, it's really easy. So let's go see if it actually builds. So it's going to grab the Ubuntu base image. It's downloading it. And then it will do exactly what you expect to do is update app cache and then install fortune and cowsay. And then create an image. Image will be called holy cow. That's the name of the image. It should be ready any moment soon. And once the image gets ready, I will need to run it. How do you run it? You basically run it like here, Docker run, holy cow. I will run it right now. So let's see if the machine image is ready or the container image is ready. And I think it is ready. So we should be able to use it and let's go run it now. So here we go. Docker run, holy cow. So it says something like here is the fortune cookie message. And these are fortune cookie messages, meaning it's the fortune program that Unix has that runs. And it has a cow at the bottom, this holy cow. There's nothing much to it. It's kind of silly, you know, and here's another one. Your computer account is overdrawn. Please reauthorize. That's a silly fortune cookie message. You run it again. It will come up with another one. Finality is death. Perfection is finality. Nothing is perfect. There are lumps in it. So basically silly things. And this is how you containerize any application, practically speaking, from just put that in form of a Docker file. Now that is a simple way of saying these things. But in reality, there are quite a lot of things to worry about, and those things are to understand where these things will actually need any input from a user or some data store, and then generate an output for the user or put that in another data store. So that's the key challenges that you really worry about in case when you're Dockerizing an application. But remember, when you are running any new application that you run it, I would rather you run it in a container. That's the reason why I showed you this quick example, is that you want to run a web server, you run it in a container. You want to run NGINX, you go ahead and run NGINX, but run that in a container. So Docker run NGINX. That's how you run. Don't run it directly by installing NGINX on a machine, because it is very resource intensive and expensive. And I'll tell you how and why it is resource intensive, because if you run what you saw in this example, in the other example that I showed you, which was this kget all example. And if you want to grep it with V-E-A-C-G, you will see that it actually narrows down and gives you the only line that are necessary to run the cloud genius WordPress site. So you have only one part, and you have one service, one ingress. Having understood that, let us see how many machines that are currently running in my cluster right now. So kget nodes, and you will be surprised that it is currently running only one box, for I think seven or eight different website, right here. Only one box. And that is this box right there. And it is running for the last 51 days. And that's the version of GKE, the Google Kubernetes Engine. And one machine is able to handle like seven or eight websites effortlessly, because there is not much load. The moment you put load on it, it automatically grows big. And you'll see machines starting up, and you will see that it handles the traffic effortlessly. By running it like this, you're not wasting too much money on machines like these, for every little application that you want. So if you run it in a separate machine, and a new application here, and a new application here, and you have one, two, three, four, five, six, seven, eight, for no reason, eight machines. And what are you doing? Nothing much. So don't go that direction. Instead, put these things in a container. You can probably put all this design, excluding the database, leave the database alone, put all this design in one box. Not have to have eight or so many boxes. And it will still automatically scale for you, depending on the workload that you put on, provided you use structure like Kubernetes in place. So that is the reason why you save money. The whole reason why I run in a Kubernetes cluster is because it saves me money. I don't want to spend eight VMs. Eight VMs will mean eight times of one VM. Simply speaking, it's about three to $400 more on every month basis, for me, at a small company. For a large company, it is quite a bit of money, huge amount of savings by just cutting down on unnecessary load on VMs. Just put things in a container and run it in a cluster. You are much better off in your company. That is the key thing to remember and do, not just remember. Okay, having said this, any other questions on this topic before we switch? You're saving a lot more money, seven times savings. Out of the eight to seven, seven to eight times easily, when you put applications in a container versus a VM. Tremendous savings and faster performance for one eighth of the price. Typically, that's what you will observe initially at least. Questions? Okay. Nilesh, when would a company not use containers? Is it just because lack of knowledge? That is one of the main reasons, yes. Parties, I guess. Yeah, so lack of knowledge, lack of awareness, lack of practice is the biggest dominating factor as to why people don't use containers. There are actually technically no drawbacks to not using containers. Okay, absolutely none. The thing that runs in a container, the thing that runs in a VM will run in a container just fine, no problem, unless, and I'll give you the idea that you need to really worry about. If you're dealing with multiple operating systems at the same time, and you need to have an infrastructure which has like Windows and Linux, then there is no easy, clean container solution. If it is all Linux, you are in a, it's a big treat right there, beautiful treat. Similarly, if you are all Windows these days, even that is a treat because they now have Windows containers, starting I think late last year, maybe a little bit before that. Windows containers are a thing. They exist, they are slow, they're fat. I mean, they're like five gigs, as opposed to a Linux container like 110, you can have a 10 MB container, like a really tiny container. So there's order of magnitude difference, it is slow and fat, but still a container. It will give you the benefits that you will typically see of a containerized system. And so that is also a possibility. I just want you to be aware of that. It is not just for Linux guys, not just for, you know, Unixy, Linuxy people, but for Windows people also. That is available. The only challenge is you cannot mix and match like this. That is not possible. If you want to do that, you have to go use VMs. Very less likely is the state in which one application needs both Linux and Windows. Very, very less likely. And therefore, if you're a Windows company, or rather I should not say company, the way I should describe this is like this. I know your company has both Linux and Windows. Good. Use containers for Windows when it is a Windows application. And use containers for Linux, wherever it's not a Windows application, because Linux will run almost every, most of your applications are probably Linux. I don't know, but you can tell me. Quite a bit of your internal applications are actually Linux based in your backend deployments are mostly Linux. Some of them probably are Windows. So just because you have been long time Microsoft customers, maybe that's where quite a bit of your effort is actually there in Windows. I don't know. I don't know these things, but you know. And so what I'm suggesting you to use is containers for individual applications and bifurcate like these things. So if it's an application that runs on Windows, you go the Windows container route. If it is an application that runs Linux, you go this route. And Microsoft Azure will give you a ready-made setup to run Windows containers, even in Kubernetes, even with Kubernetes. In fact, Microsoft has tremendous amount of energy spent in running Windows Kubernetes. Let's go see that. And what does it say? November 2017, there we go. And so see what it reads from Microsoft is a documentation Kubernetes. Yeah, I should tell you one more thing, which I did not. And that is something that is unique and that may find people who use Windows find it very, very interesting that I forgot to tell you is that the version of Windows Server, which is going to come out, I think in 2019 or maybe earlier, includes Kubernetes. That's a major, major thing. I want you to be aware of that. I just heard of it like a couple of months ago. Let's go confirm that news. So Windows Server, Kubernetes. I think the roadmap says, there it is, March 2018 news, couple of months ago, Windows Server 2019 will feature Linux and Kubernetes support right there in the OS itself for you. It's a major, major thing for Microsoft to incorporate Kubernetes right in Windows. So just like you may have seen in Windows 10, there is Linux bash prompt. I'm not sure if you know this or not, but you should know if you do not know. Linux bash, there's a Windows subsystem for Linux that looks like, where is that picture? Maybe this. So if you do not know, let me tell you that you can install Windows subsystem for Linux and it comes with the OS in your Windows 10, you have Linux. This is how you do in a PowerShell script to install Linux on Windows. If you don't want to use command line, you can probably use something like, go to the app store and say Ubuntu and get, and that will get you Ubuntu. Have you seen such a thing before in your Windows 10 laptops? Any of you? Haven't tried it. No. Haven't tried it. So go ahead and give it a try, give it a shot. This was a big thing like a couple of years ago, maybe two years ago, when this first came out. And that is Linux and the bash shell and all the scripting that you expect to see, it is there as a part of Windows 10, optional features but included in the DVD that Microsoft gives you or the actual ISO file that Microsoft ships you. They have it built into the operating system itself. That's a major thing, two years ago it happened and it's there. Similarly, the next major thing that will happen, it will happen soon and it will happen with your news about this, Kubernetes support 2019. That's a major thing. It's a major win for Microsoft and also for Kubernetes open source is incorporating this thing inside Windows because when it goes to Windows, the entire Boeing company will have it. I'm just saying, because you have a big Microsoft license and so you get it for free. I mean, not free, but because you have enterprise assurance agreement with Microsoft, they give it to you for free. And I know it's not free, but this is going to be tremendous. So it is going to help you run containers inside your existing setup with Windows containers running in Kubernetes on Windows platform. That is something that is a major thing. It is coming and you can probably give this a try right now in beta. I don't know if it beta is available or not, but check with Microsoft. They might give it to you early access or maybe there's a link here for the beta or not. Let's go find out what does Microsoft say. It says, now available in preview. Okay, so you can use it. And so preview you should grab if you are interested in Windows as a platform and just go to the Insiders program and they tell you right here, security aspects you have, you have application platform, Kubernetes support is currently in beta. And in 2019, we are introducing significant improvements to compute storage and networking components of a Kubernetes cluster. Previously extended Windows subsystem on Linux into Insider builds in Windows server. The customers can run Linux containers side by side with Windows containers. That is a new thing that you will see coming up in 2019. That is, I want you to understand that will change the statement I just made. When I said, you have a Windows container, go this route and you have a Linux container, go that route, that answer that I just made a statement like that, that will change eventually when this thing comes out. Then I can say that yes, and if you have a Windows machine or Windows setup in your cloud, you can run both Windows and Linux containers on the same operating platform that you have, which is going to be this one, according to this news. This is not news by the way, this is a Microsoft website. So it's not news, but Linux containers side by side with Windows containers. That will happen in Windows server 2019. And yes, Windows has open SSH and curl and tar and all the Linuxy tools that you would expect. And this is a picture of your Kubernetes dashboard running inside a Windows machine. It tells you right there Kubernetes managing in a container host running Windows server 2019 preview. And there are more things, you can of course keep reading about what Microsoft is doing, but that is just a digression on what Microsoft is doing. We'll skip that portion. But I want you to be aware of the fact that world is already moved on. I want you to move with it. Don't lag behind, go to containers, use it. It is actually useful. Now, gotchas, couple more gotchas. The gotcha, one of the main gotchas, if you're doing device driver development or lower, which I don't think your company does, so not a gotcha. But if you're doing low level device driver and kernel level implementation, then Docker containers may not be the ideal solution. And I'll tell you why. What happens is if you're doing, or rather, let's put it this way. If you know containers, and you have multiple of them, you know that these containers use underlying common kernel. And if you are modifying or writing a device driver, which is a device driver will be something like, I hope you understand what a device driver is. I'll give you an example of this device drivers. Let's say you have this Wacom tablet, where I'm using my pen and my tablet to write on this device that I carry in my hand right here. Now, that is a device and requires a custom driver that is loaded into my Macintosh that has this user interface available to me and I can just manage it, map it, things of that nature. I'll play with the device itself. Now, that requires development at the kernel level sometimes. So this interfaces directly with the kernel. So when you're dealing with a device driver development scenario, you're dealing with the kernel source code, which means containers will be a trouble spot. If you're dealing with and doing the device driver development at the kernel level and using the same setup and running other containers, they will also get dirty because they are using the same kernel. That's the gotcha, I want you to remember that. But apart from such things, you can run any application as long as it is not a kernel level application, as long as it is user space. Kernel space, avoid that. If it is user space applications, which most of your applications already are, you can use containers, no problem there. A couple of other things that are kind of different, it's not a gotcha, not a tricky situation, just a difference in how you will see containers are used versus VMs are used. In a VM, you will have to have a disk. And so you will map that disk like slash dev slash SDV, or if it's a Windows VM, then it will be mapped like slash, rather, X colon, I should write it differently. It will be like what? How do they write in Windows? G drive, G colon slash, F drive, F colon slash, X drive, like that, you will mount these drive letters and you will mount the disk to any of these points in Linux versus Windows. Now the mounting of a volume happens slightly differently in a container. So you have a container setup, and what you will see is a setup like Kubernetes. A setup like Kubernetes or Docker swarm or any other orchestration tools will give you a method of mounting a volume, which is what this thing is, volume, and you can mount a volume, external volume directly inside Kubernetes cluster and map it to a container using volume mount. And so here is how you would do that in an example. So there are types of volumes available. You can use AWS Elastic Doc Store, which is a disk. You can use Azure disk. You can use Azure file, which is a CIFS, or also known as SMB Samba disk. You can use Ceph file system. You can use config maps. You can use CSI, Downward API, a bunch of other solutions. You can use Google Compute Engine persistent disk. You can use a Git repository as a disk storage, as a volume storage. You can use GlusterFS and a bunch of other solutions available. If you happen to have a disk from a company that gets you the actual disk itself, that is a local disk connected to a computer, you can mount like a local disk. If you have an NFS server in your company, you can mount it like NFS. So all these mounting choices are available to you. That is just how a container will mount a volume. It is different than a traditional disk mounting to a path or a disk mounting to a drive letter in Windows. These mountings happen in a much more elaborate fashion like you see in these examples. That's your Kubernetes volume types. And you can basically mount anything inside a container and use it just like that, just like you would expect to use anything in a Unix system. Same methods apply. I don't know exactly how to mount a disk in a container in Windows because I've never used Windows containers. So I cannot tell you more about what Windows containers would do because I've never actually experimented with it because I never bothered. But I think it is a growing thing that you will see eventually Windows is also incorporating Docker and Kubernetes and all these things. So that will happen. And at that time, one day I will learn. I don't know, honestly. I don't know Windows much. Even though I did work at Microsoft for a decade, but I did not actually study Windows as a system. I was focused on Linux or rather Ling and Skype for business. That has been my focus attention. Not so much into Windows containers as such. Windows containers has been a thing for quite some time, but I did not spend my time there. So I do not know. I spend most of my energy in open source and that's what I teach and preach and use and consult and bunch of other things I do, but not Windows yet. One day I will actually take Windows also because they are these days doing good things, which I like, which is accepting and incorporating open source. I have seen this happening with.NET getting open source. You may have heard of it. This is the official repository of.NET open source. You may have heard of PowerShell open source. PowerShell itself is also on GitHub now, right here. And you will eventually, in maybe a couple of years down the road, you will see Windows open source. That might happen. I don't know. I'm not predicting with a gut. There's no basis to my projection, but I'm saying that Windows might become open source at some point. The way things are going at Microsoft, it will happen because they're incorporating open source technologies. They're adopting open source. They're contributing to open source and incorporating Kubernetes right in Windows. One day Windows becomes open. That might happen and that would be a good thing, but we'll see. I'm just speculating right now. I have no basis to make a claim of any sorts. Just by my gut tells me that this will eventually happen. That's the reason why I like Microsoft these days. I never thought that I would say these things, but I actually like the fact that they are changing themselves, which is a good thing. Okay. Having done, having discussed this concept of where you can use containers basically everywhere or most everywhere unless you're dealing with a kernel. Device handling is a different game. Don't develop device drivers. It will hurt you for no good reason. Just use a regular full-fledged machine. Don't even bother a VM. Just use a full computer and handle a real device. That's how you develop device drivers with a real computer and a real operating system without a VM. That's the right direction to go to develop device drivers. But most of the cases when you're not dealing directly with a kernel, you're using a user space. Containers are a great way to solve that problem. Containers are not new, by the way. I just want you to remember this. Containers are 50 plus years old technology. 50 plus years is older than me. Here is an example of a container that you may have not heard of because you are much younger. But let me show you something on Wikipedia that might give you some clues to read about. And that is a jail, BSD jail. And this idea is one of the oldest implementations of containers in BSD Linux. And where is that? Where is that? History, right there. So BSD Unix is the Berkeley Systems Division Unix. It has the same conceptual concept of containers. And like jails, you have another concept in Solaris OS, which is also old. It's not relatively recent. But Docker is really the driver that actually led containers into mainstream adoption, and that everybody today is actually using containers, even though the underlying technology is ancient. It is not new, but the fact that Docker came along, it made things easy. And when things become easy, it has led to adoption. And that is the reason why you see containers so much so popular these days in every company. Okay, questions further on the idea behind a web hosting application architecture before we switch to another topic? We have about 14 or so things to cover. I don't know how much we can actually cover, but keep going. Questions or no questions? Okay, I will now switch over since there are no questions. I will switch over to e-commerce. And so in e-commerce, we have this three picture set from one, or rather, this is the number two. This is number one, which is retail front end. And I think there's a third picture also somewhere here. E-commerce, this is the number three, part three. So let's go see these three pictures in one after the other, beginning with the first picture, which is part one. Now, all these three pictures that we have are Amazon's recommendation on how a retail e-commerce website should be constructed. An e-commerce website will be something like amazon.com, for example, right? That's a retail website. And so that is what they are really trying to illustrate as to what is needed to make such a site go functional, live and scale and go a global audience and solve that need for the customers that they have. That's e-commerce, that's a classic e-commerce example, amazon.com. So it has been drawn in three different parts, and let's go understand the components under the hood to make a comprehensive e-commerce website according to what Amazon wants you to believe. This is actually a good design, I'm not saying it is bad, all I'm saying is that just remember that these are Amazon specific references, meaning they are trying to make sure that you somehow believe that things are possible only in the Amazon cloud, but that's not the case. You can run it anywhere you like. So don't read too much into the AWS references, just call it reference architecture, that will help you. And so wherever you see any AWS reference, just strike it out and think more open in terms of how you can accomplish that idea in any setup yet you might have, it doesn't have to be Amazon. Okay, having said, these are good pictures by the way, good illustrations and good concepts described. So I will begin. From a user's perspective, this user, the first thing they do is go do a dig query of the DNS and find out what's the IP address for a service that they want to go visit. The first thing that they want to visit is the DNS. So you will go something like here and terminal and go dig and say, Amazon, where are you? So give me the name server. And so it finds that the amazon.com, it is actually funny to notice, I just noticed something, is that Amazon itself doesn't use the Amazon DNS. That is funny. I didn't believe, they couldn't believe this. But you see, if you go look at cnn.com, they actually use the amazon.53 name server, like right there, AWS DNS. But amazon.com itself doesn't. Nothing wrong with that idea, but it's just funny to notice that Amazon doesn't use Amazon. It uses Dyn, Dyn is a third party DNS server, which is dyn.com, which is a well-known East Coast based service for DNS. That's what amazon.com seems to be using. Nothing wrong technically with that, but just the fact that Amazon is a big cloud company and they have their own name service. They should use that one, but apparently they don't. I don't know what the reason is, probably history. Historically, they have been using this, they never bothered to change. That may be the likely reason. Having said, this name server has the first interaction between a browser looking for amazon.com and it will tell you that these are the name servers. And then it will go to the next big buddy, which is, okay, where are you then? If you are here at the name server, where are the actual machines sitting and that machine IP address reference will come back with three IP addresses, one, two, three. And these are the three addresses that you have, which correspond to the A record for amazon.com. So these addresses actually map to this endpoint. There could be more. So the three IP addresses, these are globally distributed and the user is typically sent to the closest in geographical proximity. So depending on the application's logic, the user will likely hit this endpoint or maybe this endpoint, depending on what the user is actually trying to accomplish. As you will see, there are two elastic Beanstalk references here. And what is Beanstalk? If you recall our first cloud technologies segment, you may have seen that AWS Beanstalk is actually a platform as a service in which what you can do is just quickly create a stack, a stack containing a ready-made application that you want to just deploy, it is like Heroku, except it is not actually Heroku, but it is heroku.com like, where you get a platform ready and you can just start your Beanstalk. So you will find that Beanstalk is quick and ready application deployment platform. So you want to create a new Beanstalk, what do you do is you select, and then you say that I want to choose an operating system and a language. So I choose Node.js or PHP or Python. So whatever your application is going to be written in whatever language, you just select that language. And so say, for example, I'm running my application in Ruby language, because it's a Node.js application. So I just select a pre-configured Ruby platform and then upload my code. And then I upload my zip file, containing my source code and create the environment and my application goes live. That's what the platform as a service, Elastic Beanstalk will do. So if you write your application, e-commerce application in a Rails application, you will create a Rails Beanstalk and then get your application to run in this location. Now this being Beanstalk, it will also automatically scale your platform, which means configure more options. The scalability doesn't show me that for some reason, but it is conceptually Elastic Load Balancer under the hood, in which you have a scaling set at the backend. So we have multiple VMs scaling your Rails application. And on the front end, there's a load balancer. All of that encompassed inside this Elastic Beanstalk running in our example, Rails application. And that is going to be your e-commerce application. What this e-commerce application typically does is gives you a catalog of items that it wants to sell. So catalog of things to sell. What do I want to sell? I have to sell these things. I have my departments and my video and music and books and movies and electronics and this and that. That's what I want to sell to you. And so here is the catalog. That's the front end to any e-commerce store. In a simple example, you will see another catalog here. Very, very simple example. You can actually go to the store somewhere here. I don't know if you have been there, but here is the e-commerce interface. And that is the store that I have. In here, you will find that there are three items to buy. One of them is a $0 item. The other one are the bootcamps, the cloud bootcamp and the machine learning bootcamp. Now this is the catalog that you're looking at in my website. Only three products to sell. Two of them are actually bootcamps and the third one is just a free login method. Now that compared to this website, is it dramatically different game? This is like, I don't know, billions of products here on this amazon.com. It's a gigantic application. And that is what runs your catalog and lets this user see what they have. That's the primary purpose of this e-commerce front end elastic application. Now that the view that you see right now when a user goes to this website, amazon.com, what they see is a fairly comprehensive website. It has a variety of components built in that actually makes this look and feel ready for us. And you will see that there are a variety of things that goes under the hood that makes this particular page visible to me. And it looks like that. So now let's go understand what are the components of this page and how does that actually get constructed by this e-commerce application. So let's go see that, some of the details. By the way, you will see that there is this e-commerce elastic Beanstalk. There is elastic Beanstalk here and there's one more Beanstalk here. There are three parts, part one, this is part one, this is part two, and this is part three. So there are part two and part three, we'll deal with them later. So we'll deal with them in a different sheet of paper. We'll ignore that. We'll ignore this one also, not for right now. There are two different sheets of paper that describes these things in separate. We'll just focus primarily on the e-commerce application itself. The primary logic behind the e-commerce application is to just show this user the catalog. The catalog itself is sitting in a transient session store, catalog cache and transient session store, which is a memory-based cache. This cache is a service available here from Amazon, called Elastic Cache, which is actually implemented using two open source products. Let's go see what those open source products are in this example. They have this thing called Elastic Cache. What this cache is doing is storing the catalog and transient session store. That's what we're doing here. We have Elastic Cache and transient session store. That's what this cache is actually caching, but let's see what that cache is built up out of. If you look at Amazon's example, Amazon Web Services example, I should say. Here you will find that there is this thing called, where is cache? Elastic Cache. It actually comprises of two different types of solutions, both of them open source. One of them is Redis Cache, and that is this product, open source here, and the other product is Memcached. That is also open source. And these are basically free and open, high performance, distributed memory object caching systems. That's one. And here your Redis is open source, BSD license, in memory, data structure, store, used as a database, and a cache, and a message broker. So there are three functions here. Message broker function, database function, and cache function. In this example, in Elastic Cache, they're going to use Redis as a cache, and also Memcached as a cache. So let's go see Elastic Cache, get started, and once you start to configure, it will get you two choices, the Redis cache and Memcached cache. Those two choices are available. That's the backend of this product called Elastic Cache, which means in our picture, we don't have to have Elastic Cache. We can just use a Redis container. What does that mean? It means here, you say docker run Redis, and it will run Redis. If you don't find the image, it will pull it and run it. And Redis image is like 30 MB, really small, and it is running right now. There we go. We have a Redis container running, and it is accepting connections, ready to accept connections. And so that's how easy it is to run a Redis container. So I'll break it right now. And so Redis is now ready to exit, bye-bye. And that's what we're doing here in this Elastic Cache, is running a Redis container. And you can have a name, description, version number, engine compatibility, port number, and other details, and you will mount it in a VPC, connect it to a subnet, like that, and create a big cluster or multiple containers running a Redis Cache cluster, which will become a Redis service for you to consume called Elastic Cache Cluster. You can go that route, or you can just run like this. Simply. And that's what I would recommend, is just run your own cluster, like that. Elastic Cache Cluster in your own machines, wherever you have, in your container cluster, in Kubernetes or Docker Swarm, whatever you have, just say, run the Redis image. It will create this setup for you. Now the purpose of this thing is to actually cache the catalog. Catalog is what you see when you go here. The catalog of this thing, whatever that thing is, is cumin seed. So that's the item that I'm looking at, and I like it. Maybe I'll buy it. So I'll add to cart, but as soon as I add to cart, it's a different website. It is the checkout application. So I'm not adding to the cart yet. I will go there later on. Right now I'm focused on the e-commerce application. The primary purpose of this application is to show me the catalog in its cached form. That's the look that I'm getting from this picture showing up, and I'll go maybe browse something else, and maybe I'll look at this toolset. That looks interesting to me, so I just look at that toolset. But where is this coming from? It is coming from the cache, which is stored in a Redis cache or Memcached cache inside, and it is serving me the catalog. And this elastic cache is actually an in-memory cache. It is sitting in the RAM. There is no disk access. That is why it is very fast. It is directly in your memory already. Both these products, Redis and Memcached, are running in memory, and that is why you need very large memory machines to run these type of clusters. So large memory machines are typically a good candidate to run your Redis clusters or Memcached clusters or elastic cache as a ready-made solution, and they will store your catalog in cache. That's the primary idea here in this segment. Okay, let's go see where the cache actually gets created from. The catalog comes from a data store. So this is where the actual data is stored about every product in a persistent session store. Now, this thing is a database, specifically in the Amazon's illustration, they call it the DynamoDB database. In open source, I would suggest that you use MongoDB database. If you have a similar application, that's what I would suggest that you use, because Mongo, you can run it in a container like this, Docker run Mongo, and it will run it. And there it is finishing up, 100 MB or so. And your Mongo should be running by three, two, one. There we go, Mongo started. And so that's how you should run MongoDB. Or you can, of course, use the DynamoDB solution from Amazon or use Cosmos DB solution from Azure or use Bigtable from Google or use your own database, Mongo. That's where you actually store the data about the item that you want to sell in an e-commerce situation. So that the product catalog is stored right here in the data store. Now, to search the data store, you have a search engine, which is this product that they're trying to illustrate to you, Cloud Search. Now, what is Cloud Search? Let's go see that. It is also an open source product. Let's go see that one first. It is, I think, Elasticsearch. Elasticsearch is the product under the hood, which is this open source product called Elastic.co. And the actual source code is available in the download section. And you can get a ready-made Docker container for this already. If you can just say Elastic, it should bring up. Or I'll just search for it, Docker Elasticsearch should bring it up right there. And this is your Docker run Elasticsearch, like that. So I'll just say Docker run Elasticsearch. And you will have your Elasticsearch server running. I just break my Mongo, and I'll say Docker run. And here we go, Elasticsearch. That container should immediately start in a matter of a minute or so. And it's not available in my machine, certainly bring down and run it. But in the meanwhile, we'll go see what this search is doing, this Cloud Search feature that Amazon has. Go to Amazon, console, awsamazon.com, and there you will find and look for Cloud Search. So here we have Search, searching for Search. And there it is. And we'll incorporate that search to operate on a database. So you have to create a search domain. And this thing conceptually functions just like Elasticsearch, like this thing. And it is open, which means you can go and read the Docker file as to how it is built. So this is how the open source Elasticsearch Docker file is constructed using the source code available right in this location where you have the Debian artifacts for that right here. And you can install it from sources like here. Install no recommends, Elasticsearch, version number, and then you run it. That's the Docker file for Elasticsearch. So when you run this search, or when you run the Amazon-provided solution called, what is it called? It's called Amazon Cloud Search, conceptually very similar. What it is doing is enabling you to search this database and thereby generating a response that you can store it in the cache, in the Elastic cache, or Redis cache, or Memcached cache, thereby enabling your users of the e-commerce application to quickly see what they see. What do they see? They see, where is that? They see this. So I want to go by Echo Dot. I look at this picture, all these site representation is coming straight from the cache, this cache, which is generated from the search engine searching the data store. And somebody has to actually populate the data about Echo Dot, about cumin seeds, about this new kids edition of Echo Dot, and things of that nature. So you have daily deals and gift cards. There are millions and millions of products here. Somebody has done the work already, and they keep on doing that work of creating items in the data store that will get searched and indexed and put in cache so that the users who just visit this amazon.com are presented with a catalog of things that they may be interested in. And of course, it will further extend and enhance with, I want to buy some gourmet coffee, so I say, give me some coffee, and I find this coffee, and that I just did is a quick search. What did I search for? The coffee. And it presented to me this coffee that I may want to buy. And so that is what is going on here in this illustration with the help of the search engine. It's searching on the data store and caching the results in this cache, which is what I see when I visit that e-commerce website. That is what we have in this particular sheet of paper. Again, of course, when I am browsing this site, it is collecting logs of what am I doing. And as a consequence, this e-commerce application is generating a bunch of logs every time I do something on the website. It is keeping track of what is this person doing. And it is keeping track of everybody who is doing something, and that logs are stored in a bucket. And that will be processed subsequently in a segment here. The third segment is where it will actually take these logs and make some processing, and then actually give you a response back to me based on what I have been doing for the last so many years. I've been using Amazon since 1998. Ever since then, they know what I have been buying. They know what I've been browsing. They know where I've been living and things of that nature. So ever since then, when I first bought a book with Amazon, they know about every single thing I did, and they have logged it, and they store it in a bucket. And they are going to generate marketing and recommendations for me. And you can see some of that already here. For example, at the bottom, you will see a recommendation for me as to buy this instead of that. Or people who bought this frequently bought together. And maybe your search history or your browsing history, like that. They already know what I've been browsing, and they already know that I need to buy a Wacom Cintiq Pro and a smart plug and some coffee and things of that nature. They already understand what I do. And so they have been just keeping track of what I'm interested in and just showing it to me as if I want to go back and buy, maybe I want to buy this shoe. And so they know already what I have been doing, and they keep track of this. And this marketing and recommendations portion of the website is actually presenting to me my history right here on the same page. That's the third thing we'll discuss. But before we switch over from this picture to another one, which is I want to now go to an item where I will check something out. And I'll walk you through as to how the e-commerce flow is happening in that segment in the second piece of the puzzle, which is when I decide to buy this pair of sandals. So I say, OK, add to cart. Now, as soon as I add to cart, it goes to a different site. And specifically, when I click on this button, the cart button, this is the checkout process. It's a completely different website handled by a different system. It looks kind of sort of the same family, but it's actually a different service. Let's go see what that second service is from a picture perspective. So here is the second picture, I think. No, it's part three. Here is the second picture. So we will look at the part two picture. And in that part, we have the first part here. And the rest of the picture actually describes the second part. Let's go see how it is implemented in this illustration from Amazon about how it should be implemented. Of course, you have a choice of implementing however you like. And this is the Amazon's picture, so they have Amazon references. But let's go see that this person, which is me, adds the sandal into the shopping cart. So add to cart. Added. Once that thing is added to cart, it's handed off to a different service for cart management. So this is your checkout service. That's what you're running in a separate elastic beanstalk. And in that location, you already know what the item is in your cart. So now let's go see, compare this with here. In my cart, I have what? I have one item. The cart is this pair of shoes, that one. And it's $109. And so I may want to adjust my size. So it is, again, going back to my catalog and correctly picking up the right quantity and showing me whether it's available or not, also showing me the size chart that you know already. And I now add this one to cart as opposed to the other one. And so now my cart is expanded. I will maybe delete this other item that I don't need because I need the size number nine. And now I proceed to checkout. So this action is happening in a different direction. As you know, what is going to happen right now is this application, the checkout application, will keep track of who the customer is because they already know that I logged in. And as soon as they complete the checkout process, which is to provide a credit card and shipping address and destination and all that, shipping method, they will then create a bunch of things simultaneously. And you will see what it does. You probably are very familiar with these actions. But on the back end, let's see what it actually is doing. The first thing it does is it sends you a message that, yeah, I got the order. So as soon as you actually complete the checkout process, it creates an entry in the database. Saying that there is a customer and orders database. So there is a new order that has come in. That's the order entry into the system. At the very same time, when you complete a checkout and order is into the system, it sends out a message to a workflow service right here, which is, as soon as this is marked as a new order, the second item that it goes out is a new workflow item as an action item that something needs to now happen to fulfill the order. This fulfillment is a major operation in Amazon. As you can understand, they have to actually fulfill the order. Just because somebody paid doesn't mean that the transaction is over. You have to actually have to ship the item to the user, fulfill the order. So this fulfillment is order fulfillment has to happen in a separate segment. You and I don't see this because this is not a external facing thing, but it's an internal service that is going to handle a bunch of actions. Beginning with, one of the first ones is to notify a mobile worker that may be in the warehouse. And these days it is increasingly not a worker, but a robot that will handle the item. So somehow you notify the robot to pick up the item and get ready for shipment. There may be other people sometimes that supervise these machines and the robots in their warehouse, which will get also notifications on their devices, in their hands, that there is a new order to be fulfilled, waiting to be fulfilled. Next one is this idea where you have a set of worker machines and these machines are in an auto scaling group and what they're primarily doing is making sure that they are creating emails and sending out those emails through an email service to the customer that basically notify this customer that I got your order. This is what I will now do for you and by such and such date, you will receive such and such item. So that notice that you will need to send to the customer needs to go out from an email service, which is a third party service you can use, or you can use Amazon's example, which is, it's called SES. And so the idea here is, okay, go back. The idea of SES is simple email service. And what it does is it sends email, simply. So let's go get started with it and you will see what it does and I'll sign into console and you will see some of the things that I think I have already set up a couple of things here. SES and that is simple email service. You will see that in my account, I have set it up already to unsupported region. Oh, I have to change the region from California to Oregon. And then it is supported. It only works in certain regions like Virginia, Oregon and Ireland. Only three locations have this email service functional. I think I used it in Oregon. So there I have it. And here I have my domains mounted. I have these two domains that I send emails from and then email addresses show up. Here are a couple of email addresses I use to send. And that is how an email will go out when it needs to go out. These emails are automated system generated emails. They're similar. You may have seen some of these emails when you forget a password on the Cloud Genius website. You'll probably see an email coming to you when you say, I forgot my password. So you go to the dashboard and somewhere here you will find, forgot your password or maybe after you log out. Yeah. So after you log out, there is a password, forgot, lost your password button. And then you type your email address here and then you say, reset my password. That should actually send out an email notification from a system. That system is what you will see generates an email. And so I'm going to say, reset my password. So click. So it is going to go back to the machine on the backend, the email service and send a password reset email to me. I can go check my email because I will have it. And that email will pop up because of the fact that there is a simple email service right there running. And so this email was generated by the system saying somebody called Nilesh, apparently forgot the password. And so if you want to reset the password, you can click here. I don't want to reset my passwords. I'll just delete that email, but that is where it came from, right? Is what this simple email service sends that email out is a separate action that just happens when you check out an item, put the item in the order and it needs to be fulfilled. So one of the fulfillment actions that happens is a robotic or manual process. The second action is to email out the user. Yeah, I got the order. I'm sending it to you. So standby. And people will wait for the item to arrive and then it arrives. So that's the checkout process. Now let's go look at the third item, which is the third segment, which is more interesting than these two. These two are kind of understood, well understood. So we'll go to the third one, which is marketing and recommendations. So let's go find where it is. I think it is this one. And here you will find that it has a bunch of different things to do that we see it on amazon.com. You see it, you have seen it. I want you to relate to what you see with what I'm going to describe to you. One of the things that you will typically see as you visit Amazon's website, or rather any e-commerce website mostly, is this idea where it says, or rather let me get to the return to the cart and go to the main page. So here is my shoe. And I'm looking at it. But as I see it, I find something interesting. And that is customer who viewed this also bought that. See that customers who bought this, customers who bought this also bought the other items. And that is a common recommendation technique. You can see that already here. Customers who bought this shoe also bought that shoe. And maybe this kind of shoe. And maybe something else. For example, these shoes and more shoes. And what is this? Garden hose? How is that related? I don't know. And that is something that you will find is probably a mistake in the algorithm. Or maybe there is a case of statistical purchase happening in that people who buy these sandals may be interested in buying these deluxe garden hose, pressure washer garden hose. I have no idea. But there may be some correlation in between people buying shoes and with people buying these things. And that is one of the reasons why this algorithm that is running on the backend, which is actually a algorithm that runs in Elastic Map Reduce as a separate service in Amazon. And this service is Elastic Map Reduce is actually the Hadoop service. Hadoop service. Hadoop is an open source product as you may have known already. Hadoop is this Apache Foundation project, which is basically a platform for big data analysis. And what this tool will do for you is to run map reduce operations. Now it's not Elastic Map Reduce, EMR is the name. The actual mathematical function is called map and reduce. And that is what the logic that you want to run on very large scale data sets that you have already in your log repositories that you collect from all these customers that ever visited your website. So you store your logs already. You will feed the logs into a Hadoop cluster and use that to analyze and interpret and run a bunch of machine learning algorithms and bunch of other related conceptual, what is known as market basket analysis. Market basket algorithm is what is necessary in identifying customers who bought this, also bought that scenario. So which you will see here in this example, which turns out to be kind of a weird situation where your customer buying a shoe is also buying these host whatever that thing is, brass quick connect kit. Maybe they're doing it, maybe they're not, but now you see that the sponsored recommendations and customers who viewed this also viewed that. Here you now suddenly see they're all related to gardening tools. And occasionally you will find something out of the blue, different and not related. That might happen, but I have not seen it. I've flipped like six pages already and I did not see anything that is out of the blue. But in the shoe, I did see that one pop up, which is kind of strange. It occasionally happens, but that's the recommendation that Amazon is trying to give you. So if you now go back to the front page and try to search something else like Cintiq 24, and I don't find it. Maybe the 22 model and 2027 model. But if I click on say 22 model, it might give you a recommendation of something else that may be available on Amazon that customers may have bought based on past performance or past purchase behavior of other people. And you can see what we are doing or what are you looking at with other competitive tablets compared to the Wacom Cintiq. You have this UMGE, you have Huion, you have Gaomon, you have Huion and Wacom and Huion and Turcom and other other tablets popping up. And sometimes it is not a tablet, but it is related to like this thing, for example. So you will have these recommendations coming up that most of them are pretty much in line and they are basically derived based on market basket analysis. That analysis is based on a Priori algorithm. It's a probability and statistics concept. And so you can maybe read, where is that Wikipedia page? Market basket, this should also be good, but let's go check that one. This, I think something we should read. There is a business use, the business use is significantly increased since the introduction of point of sale. Amazon uses affinity analysis for cross-selling when it recommends products to people based on their purchase history and the purchase history of other people who bought the same item. And that is what is market basket analysis in action. When you see, and that is the algorithm you will see running here in a Elastic MapReduce cluster, which will basically come out with a user persona and their past behavior, past purchase activity and similarity with other people and their purchase activity and then come up with recommendations. And those recommendations are generated in this service and is actually embedded right into your page as you visit Amazon. So this section that begins with customers also shop for this entire segment that you have is actually this portion that begins from here and ends here is constructed from the recommendations service. It is not a part of the first one, which is the actual e-commerce catalog. The recommendations engine is actually creating those HTML segments and incorporating them right in the browser. You can see a bunch of similar examples in other sites, other companies like Macy's or Amazon or Target or all the big e-commerce stores, they will all do similar things. So that's the recommendations idea. In addition to that, there are a couple of other interesting things that you may have seen Amazon does it to you. And one of them is marketing emails. I don't know if you receive those emails or not, but you can probably opt in to receive those marketing messages coming from Amazon in which customers may want to be interested. They may be interested in receiving emails about something that is going to come up in the future or some product announcement, or they just want Amazon to be able to let them know about something is going to be coming. And that is based on a customer's choice, whether they want to receive such communication from Amazon or not. So they will opt into a marketing messaging communication. And then these marketing emails need to be generated by a system. Of course, somebody has to write those messages and they will probably write it already by a human being will write it, but a system needs to be put in place that will use the email service like simple email service, like you saw me in a quick demo in the other session, or rather today's session just a few minutes ago, will generate a marketing communications message and send it to people who have opted in based on a marketing management application that runs in another Beanstalk, which is going to grab data from customer's orders and the result from analysis about Market Basket and not only showing what this analysis is showing to the user who is not this user, not this user. The user is in scene number one, which is this user, the customer user. This user, the customer user, they need to see the recommendations. The user in picture number three are not end user customers. That user is a marketing manager. And what this guy is doing is actually crafting those messages and putting that in the marketing management application. So the email that you receive in form of marketing is actually handwritten by somebody like this guy, marketing manager. He uploads that content into the web service that will generate automated emails and send it out to you. And that's actually fed through the data collected through customer orders and analysis that happens in a Hadoop cluster. That is what you will see typically in a marketing and recommendations engine that will help drive more sales for the e-commerce application that you may be running like amazon.com as one example. Amazon.com itself is probably fairly elaborate and much more bigger than these three charts. But this is just a standard e-commerce implementation as to how Amazon thinks should be implemented in the Amazon cloud. But again, as you have seen, every single element here, like this is the Hadoop cluster, is open source. Your data stores can be MySQL database or PostgreSQL or MongoDB, your marketing management app. There are a variety of open source implementations for that. For example, I use, what's the thing I use? Mautic, that is a open source marketing automation application available that I use in my company. This is probably not great for enterprise usage yet, but it's growing. For enterprise, I think commercial applications are much better. This is a small application that is evolving. So I would not recommend it for enterprise usage yet, but I think it is good. It is useful for small business, so I use it. In addition to that, you can, of course, see that this simple email service is nothing more than a glorified SMTP service. Just sends out email, nothing else. Of course, there are a variety of services already out there. SES happens to be just one of them. DynamoDB can be substituted comfortably with MongoDB. And LogStore is basically a bucket. So you can store it in any bucket. Every cloud provider will give you a bucket-based system. A scaling Beanstalk is basically a platform as a service ready for deployment. You can run this in a Kubernetes cluster if you like, or you can run a third-party platform as a service if you have to use that ready-made service, you can go that route. And more or less, you can implement an e-commerce design implementation in any setup that you have, internal or external cloud or not cloud. It's totally up to you. But it's easier to do it in the cloud, so you go that route if you like. Having discussed this idea, I would like to see if there are any specific questions on the e-commerce aspect as we discussed, or anything that we may not have discussed. So questions are welcome before we change topics. No questions? OK, no questions is scary. OK. I don't like the no-question thing, but I guess you are not in the mood of talking. So maybe I'll make it interesting. I'll ask this question. As to what do you want us to cover next? We discussed two things, right? We discussed basic web hosting and then e-commerce application. There are more things to discuss, and I'll just go through the list again. So what we want to be able to discuss are ideas around how do time series processing happen, which is basically a focus on collecting statistical data or input data collecting from various sensors in Internet of Things. These sensors will grab data and make use of that in form of some intelligent application. So that's the idea behind time series is one way that I would like to discuss. The other thing that we wanted to talk about is log analysis. How do you actually do the analysis of a log and make sense out of it? You have another large scale data sets example. We have more examples on how a gaming application will be structured. So we'd like to discuss Nintendo, Pokemon Go, if you like. Just pick a thing to discuss, and we'll go that direction. We have more here about ensuring fault tolerance and high availability that you can implement in your company. So this is availability zone B, availability zone A, and how you can ensure a scenario of tolerating a fault. If something goes wrong, what do you need to do? You also have another case of disaster recovery. Where is that? Here. Disaster recovery. If things go wrong, how can you make sure that your things keep on running in your corporate data center? Maybe this example applies to Boeing quite nicely. So maybe I'll discuss that. So let's go see how it applies. So you have a company data center in your company, right there. And here are your users, people in your company. And these people are typically interfacing this way. And they're accessing them applications in your company. They're production applications running internal to you. And these applications interface with some kind of a storage solution. This is mapped to a storage volume. Basically, there are disks inside in your company, so in your data center. There are two volumes you're showing in the picture, one and two. These disks are basically mounted in the application server. And this server is serving the application to the user. And the user is happy. This server also interfaces with a database server. In this example, they're showing you Oracle picture. You can use any database you like. So that's a design in a data center deployment. Now, a disaster strikes, which means this whole thing is down. Which one? This whole thing is down. So now this user is panicking. My application I cannot access. So the user should not panic. That's the whole point. No panic. User should not even perceive that there is something that went wrong and the data center went out. So what do you need to do to make sure that the user doesn't panic and that even though things will go bad, by the way, they will go bad, even though things go bad, they will not notice. And they will continue to do their business without panic. That's what we want. That's what we want to enable. And so we want these users to be able to continue to operate in their applications, whatever they have. And even if this whole thing goes down, you can still, the users keep on working whatever they're working on. They don't worry. They don't get impacted. Let's put it that way. There is no impact to them. They keep on doing their business as usual. So to enable that situation in this picture, what they're trying to illustrate is a way to enable applications to recover from a disaster. Let's see what each and every element in this segment is actually created in form of a replica available in the cloud so that it actually switches over so that it actually switches over when it needs to. And we'll see how the actual action happens. But let's go understand this piece by piece first. So first thing, we'll look at our database server that we have in production. And what we want to be able to do is make sure that these Oracle database is backed up and backed up to a cloud location in Amazon S3, for example. So this is Amazon diagram. So it's an S3 bucket. It can be any bucket. It doesn't have to be Amazon bucket. You put the data backups right here. So the backups are available in the cloud in a bucket. At the same time, once the backups are available, you want to periodically test the restoration action. You want to restore that database that you backed up here onto a different database server that you run in a recovery mode and test it every so often, ideally automatically. Anytime you have a backup done, you make sure that the backup is stored in the bucket. And as soon as the backup completes, you want to restore it to a recovery database server and test it. Even though you don't have a disaster, you still want to do it. The reason you want to do a restore is primarily because, let me ask you this question. What is the true test of a backup? True. What is the backup? Sorry? Actually restoring it? Yes, exactly. Whether the restore succeeds, that's the true test of backup, not whether the backup succeeds. Nobody cares about the backup. The true test of backup is actually when the restore succeeds. So when you back up, don't worry about testing that. That's not the idea. You should test whether the restoration actually succeeds. And you should see whether this database is actually functional. That is the true test of this backup. And you should understand that principle applies to every single case. Every single case of backup, that's the true test, whether you can restore or not. So that backup you're doing already, and you're storing them here, and you're testing them every so often, for every backup that gets backed up, you restore it and test it out. So your database is in a good shape. And if something goes wrong, you can potentially restart this database server and be back in business. That's the bad database part. The database part is understood and backed up and nicely kept track of in your recovery state. And you can, anytime, go back to this, using this, if you want to, if this goes down. So that's how you plan for it. The second set of actions that you need to be able to do is on the disk side, when you have these storage volumes that store the data for your files and other things for the production server that you have here, this is where the disk is actually sitting. So in this Amazon example, what they have is a storage gateway, which is an Amazon application, or other Amazon service. And what it does is it takes a snapshot of these disks and puts them here, the two snapshots of these disks, as shown in the picture. And they are every so often propagated to that destination in a bucket. And you want to keep track of these snapshots. And you want to basically track nightly snapshot. But like, for example, I'm taking in this example. You may have seen this. OK, get all backup, sorry. You will see that I backup every day. So it's a nightly backup happens at, I think, 8 o'clock or whatever, some random time of the day. It happens every so often. And that actually backs up from Google Cloud on to the Amazon Cloud. And you see that these backups have happened 22 hours ago, one day ago, two days ago. Three backups, it just keeps track of the last three backups. And it rotates every seven days. The idea here behind this setup backup, it happens without me having to do it. It also tests it on the other end. As soon as the backup completes, it will test that backup. And by restoring it, whether the backup actually succeeded. And then I don't have to do anything about actually making sure that the backup is valid. So if something goes wrong on this website for some reason, I don't have to worry about it. All I do is I say, OK, go back to how it was. And it goes back. That's how I have written the code for it. And that is exactly how you should do it, is to ensure that your disks also get snapshotted and stored in your buckets in some storage, in some cloud. In this example, it is S3. Now, this application server that you have might be using some machine image, some AMI, Amazon Machine Image. So you want to keep track of these machine images for the application server that you have in that location, which is also going to be in a bucket, in the case of Amazon. Or other companies will give you another way of storing those images. May not be in a bucket, but may be another place. But there is a place to store machine images that you want to keep track of as to what your application is actually doing. And that is what you need to do for your application server to become up and running in a recovery state. Because you have kept track of the AMI, this and this, you can then use these AMI machine images to restart a recovery server if this thing goes down. And when this thing goes down, we can restart this one. And when your storage volumes and the storage deployment goes bad, you know you have a snapshot stored here. So what you can do is restore those snapshots right here, one and two, and hook them up to your recovery application server. And when you have a database server going bad, you just restore your database from the restoration to an actual database server in the recovery mode. And then all you need to really do at that time is to change your DNS entry, like that. You say, user, please, instead of going to, or rather, the user doesn't need to worry about. So let's go say there is an app called app.boeing.com. That's the name of the app. I just made it up. That's the app. It's called app.boeing.com. Now, the address record for this A record points to this machine. And that's the current state of affairs. And you notice that this app has gone bad. Something went wrong here. We don't know exactly where it went wrong. But we know that something went wrong. And this app.boeing.com is not working anymore for this customer. So the customer is kind of sort of wondering what is going on. And in the meanwhile, you detect that there is a problem. And you understand that you know you have an alternative system. So what you can do is quickly restore your data store, quickly restore your disks to the disk volumes, and restore your machine images to your application servers. And you have a functional restore setup already. All you need to now do is point this A record not to this location, but instead point it to this location. And so the next refresh that this customer will do when they notice that there is some problem is that they will hit refresh, probably, very likely. And they will become happy because the refresh direction will then head the traffic from this user, will not go to this site. It will still be app.boeing.com, but it will go this direction. And through that, they will reach through a VPC gateway in a VPC in Amazon. They will reach your application server that you have, which interfaces the disk that you have. And it also accesses the data store that you have recovered already. And so this user that visits this website, he or she was using this set of services before. It went down for some reason. It doesn't matter too much. You can just migrate away the DNS entry, internal DNS for the app.boeing.com domain away from here to here. And then you go back and investigate what is going on while the user is happy and they're going doing their thing as usual, business as usual, on app.boeing.com pointing to the cloud as opposed to pointing to your internal machines in your company. And so the user is now interfacing with this. They are happy, or they continue to be happy. And while you can investigate what went wrong, why did it not work, why did that break, and things of that nature. So that's what you can keep on doing until your corporate data center comes back online. And then you restore the other direction. And you bring your data back to your data center because that user may have done some changes and updated and all that. So the user state has to be brought back to the local location for your local application that you run locally. So you bring it back to the local location after you identify the problem. You fix it, you bring your data back, and then you change DNS one more time. You say, hey, user, change the DNS. So look this way. And user doesn't even know that they're looking this way or that way because that look is actually transferred through app.boeing.com name server. That name server will automatically adjust the A record pointing from here to now pointing here. And user is unaware the fact that you had a data center outage. They don't care. They don't know. They don't need to know. They don't need to worry. They're doing their business like usual. And things go on. Questions? So is this architecture diagram recent one because I'm just wondering, why do we have to do the restoration? Oracle thing, can we do the, we can set up the mirroring thing? Yeah, mirroring thing will work if you have this functional and that functional. Yeah, because when we go down, we have to do restoration that takes a lot of time. So mirroring is already there. You can use mirroring. If you can use mirroring and use a faster method, you can use mirror. No need to full restore. No need to full restore. Yeah, just wondering. So this is Amazon they're using without a mirroring. Just wondering, surprising me. No, don't get surprised. This is a reference. They call it a reference architecture, meaning it's a suggestion. Yeah. You can go do this way or go do it another way. That's OK. And this is not a rule that you have to follow. Got it. Right? This is a recommendation that they gave. So we are looking at that illustrations to see how you can. You can, of course, mirror. You can do incremental backups, incremental restores, whatever is feasible and very likely to finish quickly in a reliable fashion. That's the direction you should take. Right? Yeah. OK, any other questions? OK, then we'll switch. We'll look at time series. See what time series does. If you know what time series is, please tell me. If not, we'll do a Wikipedia search, like my way of doing things. By the way, time series is basically a way to keep track of things happening over a period of time. And so it basically boils down to things like this. Where is that sheet of paper? Here. So time series will do something like we have in our area. In King County, we have a pipeline, gas pipeline. It travels in the state of Washington. Let's go see if this is the state of Washington, my rough drawing. And it travels from here all the way to British Columbia, like that. This is the state of Washington. And it traverses through King County somewhere. And this pipeline is a major pipeline in our region. It is called the Williams Communications, Williams Pipeline. I think that's the name. Now, what is going on in that pipe is gas flows. And when gas flows from one country to another, then it's a major thing. It's a major thing because there are lots of things that actually need to worry about when gasoline, or rather natural gas, liquefied natural gas, LNG, is flowing in a pipe. You need to worry about hundreds and maybe thousands of metrics. Metrics need to be measured as to what is the temperature, pressure, whether the flow characteristic flow, flow of the LNG itself. Is it laminar? Is it turbulent? Is it slushy? I should say slushy. Slushy meaning it goes left and right as it flows through. So you have to keep track of these characteristics of the gas flow in a pipe because it can cause disaster. And you have to keep track of these metrics that I'm talking about, just an example collection of metrics, over the entire length of the pipe, and also over a period of time, period of time, meaning you have to know what the particular metric was. So let's go say the temperature, so temp. Temperature now, temperature one hour ago, temperature two hours ago, temperature three hours ago. You're keeping track of these data points for temperature of the gas LNG at a given location. So the location is, say, the Sammamish location or the Redmond location or whatever that location is. And that location, you have to identify exactly which location, actually the pipeline is not at the city level, but more of a marker in the pipe itself. So at that marker level, you have to keep track of the temperature at that location, meaning the pipe at this location, what's the temperature at this location, what the temperature is. And you have to keep track of these readings over a period of time for years and years since the pipeline started. That data is typically called a time series data, because you're keeping track of one metric over a period of time, time series. That's the idea behind time series. Now, when you're dealing with time series data, it comes in handy to store that data and actually collect that data in form of Internet of Things devices, IoT, which will look something like this. You have a bunch of sensors that collect a variety of metrics along your entire chain of pipe. So these are the sensors that you have along your pipeline, for example, the Williams pipe that we have in our state. And that will gather a bunch of data and just put that in a queue, simple queuing service. This is a service from Amazon called SQS. But what is SQS under the hood? Let's go find out. And so SQS is basically a queuing service called this. So that is one of the implementations in open source that you can see. RabbitMQ is a queue. Amazon SQS is also a queue. And a queue is basically something that you already know and understand is the idea that you want to store things in a last in, first out fashion. Or you want to store things in a first in, first out fashion, meaning like that. So these are two types of queues. And you're going to have, of course, modify and create some other types of queues if you like. But that's a queue. And this queue is what is actually collecting your metrics that come from a variety of sensors that you may have in the field. And once you have that queues coming in, you need to make sure that they are processed for your application logic. So you have a auto scaling group that has worker nodes that will actually collect that data and do the necessary processing for your particular application. For example, the pipeline application as one example. And store that data in a database of some sorts. This case, MongoDB. And then you can have a supervisory control and data acquisition, which is a classic phrase that is used in any kind of metric or metering or measurement of electric supply, measuring of water supply, gas pipes. You can actually apply this to any kind of supervisory control and data acquisition, SCADA system of some sorts, that will basically gather data from sensors and give you a view to understand, analyze, and take action. So that's where you have people in your corporate data center using SCADA tools to understand the data that is coming in from a variety of sensors deployed wherever they are and store the data in a centralized depository. And just view that in a SCADA system to understand what we have in your data center that you might have in, say, the Williams gas pipe company or other companies like Fuget Sound Energy Company. They will have these things, electricity meters, energy consumption on a time basis or the entire King County or the entire Fuget Sound region. You will have such data, and the SCADA system will help you collect that and view and visualize and analyze and things of that nature. When it comes to cloud, you can actually make use of that data and apply your machine learning techniques. This is where you have Elastic MapReduce again that will consume that data and then help you analyze as to what does that data mean to you from your usage patterns or the metrics that it generates. For example, it can translate to something like you detect a hot spot in your pipe. For some reason, in the King County, as the pipe flows from A to B, you can detect some patterns in the data, the metrics that it's been sending to you that over a period of time, usually the temperature has been, say, 48 degrees. But sometimes it goes, maybe 48 is not the right number. It's a liquefied, cooled gas. So the number should be below. I don't exactly know the temperature numbers, but I'm just making up. So if the temperature numbers are at the order of 20s, and if you suddenly see a spike of 40, then you see some problem. And you can detect that anomaly by the anomaly detection algorithm that you can run. This is a very easy one to actually pick, but you can actually detect patterns of what I call abnormality. And that will help you identify issues in your actual physical location, where the sensors are gathering data from. That's one way to think about as an example. And these MapReduce applications will help your business intelligence user actually make sense of what the data was in the last year in this season and the other years in that season when the weather temperature was such and such and the gas temperature inside the pipe is such and such in that month of the year. What does it mean? Does it mean that we need to dispatch a team to actually go fix the pipe out in the field? Is that something that needs to be paid attention to and taken care of before a disaster strikes? And you can take these actions proactively on your own because you have access to the data that you now have through a systematic approach towards understanding, analyzing, and taking priority action. This concept also applies directly to the Boeing aircraft company. And I'll tell you how. Let me erase some of these things. And I think there is a tremendous amount of information that Boeing actually gathers from your planes. It is also a very critical operation. To fly a plane is no joke. I mean, not just fly, fly, but make sure that the worldwide base of airplanes made by Boeing managed by a bunch of airlines worldwide keeps on flying flight after flight after flight without problems. That is the goal. That is one of the major goals that your company has. And that also involves a tremendous amount of data collection across the board and every single plane, every single part of the plane will have a variety of sensors that are incorporated into the body of the plane and are constantly sending data down to the earth in your data centers. You know that already. That is what this thing is, remote sensing. It doesn't apply to a pipeline scenario, but it's a different example of your own company where you have planes sending data. Data that is being sent to the ground on its own without somebody asking for it. That data is collected in your central warehouse. I don't know if you access that data, but probably it's depending on need to know data. Depending on your role in the company, you may access it or not. But that data is basically available in your company to some people. And those are actually analyzing what is going on with the plane. At any given time, you have an enormous number of data points that you collect over time for every single plane that flies anywhere in the world. That plane, let's take an example. An example will be something like a plane flies from Seattle to Spokane. It's a very short flight. And it starts from here, takes off. And in the flight, as it flies, it is about to go there in like 30 minutes or so. And this is your Alaska Airlines flight. And so in the flight, somewhere in the middle, it detects that there is a problem with a particular spare part. And that part needs to be replaced. So part, some part, some number needs replacement. That's the detection that the plane did. So what it does, it sends a message to the ground, the ground control to Alaska Airlines and tells them that this part is need to be replaced for the plane to keep on flying. And what does Alaska Airline want? The Alaska Airline wants that plane to fly again as quickly as it can. You know, in 30 minutes down the road, this plane is going to land in Spokane. What does Alaska want? The plane should take off again as scheduled, maybe in 40 minutes as soon as it lands. The next flight, it should take it off and go to the next destination, wherever that is. That's what Alaska wants. They don't want that plane to be sitting on the ground waiting for the part. So what does Boeing do? Boeing will sell a service to Alaska Airlines, which is their Boeing Commercial Aviation Division service. That service will notify Alaska Airlines that your plane needs that part. And that notification goes to Alaska Airlines or maybe they outsource it to Boeing. I don't exactly know who manages what, but that's not the point. The point is somebody on the ground knows that there is this need for a replacement or a need for a part to be replaced. And they knew it already even before the plane lands, 30 minutes ahead of time. So then they can arrange for that part to become available at the Spokane Airport. And as soon as the plane lands, the first thing they do is swap it out. Swap out the broken part, put the new part back in business, test it, ready. Okay, you're ready, good to go, you fly. That is exactly what Alaska wants, is the plane to keep on flying. The more time they spend on the ground is money lost. And so they don't want to lose money. They want to keep, you know, airlines is a shitty business. I should say that, I shouldn't say that in that way. It is actually a shitty business. It's one of the worst businesses you can think of in terms of profitability. It's very hard to make money. It's the nature of the businesses like that. So most airlines suck, you know, you know that. Maybe I'm just pessimistic, but I just said that. So ignore that comment. But bottom line is they don't want to make loss. They want to make profit. So they want to keep the planes flying. And so Alaska Airlines will want the plane to fly. So they actually pay money to Boeing to get that service from the Boeing company to get them notification. And they probably buy these services directly at the time when they buy the plane itself. These are after sale service that Boeing sells. So they sell a plane and then they sell a service package along with it so that they can actually get the notifications like part needs a replacement and, you know, make sure the part is available at that time at the destination when it is needed. So make sure that the part is just in time delivered to the destination and is able to be swapped out so that the flight can take off for the next flight it needs to take. And thereby reducing the loss the company makes or increasing the profitability opportunity for Alaska Airlines. And that's the scenario. So to enable that scenario, you have sensors on the plane collecting data, putting that in a database and monitoring it in some location, either in the Boeing company or in the Alaska Airlines or the airport. I don't know exactly where it gets monitored, but you have these systems somewhere. Most likely in your company as well as the airline company, both of them will likely have it. That will monitor the data collected for the planes that its fleet of planes, the Alaska fleet or, you know, Emirates fleet or any of the airlines that you have. They will collect that data, monitor it, analyze it and make sense of what it needs to do to keep their business running all the time. And the most important thing here is to keep track of historical data. So you can understand and identify patterns in the data and make intelligent decisions on what needs to be done to the data that gets collected like that. And now the third example in the same league of things is the Tesla Motor Company. You may have seen Tesla camera, YouTube. You may have seen how Tesla sees things around it. Okay, I don't have a quick way to show you a video, but maybe an image should do it. Don't have it, don't have a ready answer. Maybe this is a good one. So look at this red color car. It is looking at the other cars around it. And around the car's body, there are I think about nine or more cameras. I think newer models have even more cameras. Around the body of the car, they're all around the perimeter. You will have cameras looking on all directions. Now that is a sensor in a sense. So you're looking at a sensor of some sorts, like a camera sensor, looking at objects outside surrounding it. And that data is analyzed right in the car itself. So that picture that you look at here may not directly apply to what Tesla does because the data that is being collected is not a sensor data, but actually videos gathered by these multiple cameras around the object, around the car itself, in a surrounding that you see from multiple viewpoints. And the data collected itself is gigantic. It's multiple gigabytes per minute. One minute of video from nine cameras, or maybe more cameras is already a big package of data. So to send the data over to a cloud location, it's kind of very expensive. You cannot just simultaneously send from the car, which is like driving on the highway, and you send nine or 10 gigs of data every minute. It's kind of not possible, technically not possible. So what they do is they actually interpret the data right in the car itself and extract useful information about what that thing is about what the car looks at, like this other car or the other car ahead of it, and then makes automatic judgments as to what needs to happen in an autopilot scenario. And that autopilot is still not perfected yet. We still see sometimes, you know, Tesla has problems. And so just yesterday, I think Tesla, Elon, Elon Musk, I think agreed to compensate people about in a class action lawsuit about the class action mentioned. Okay, there was a news yesterday or today. Yeah, there it is. May 1, Tesla agrees to partially reimburse people who bought autopilot in a $5 million settlement of class action lawsuit. So yeah, here in this picture, you will see what the left rear camera is looking at, the medium range vehicle camera looking at. And this picture actually is kind of an illustration of what the car looks like. So this is the car, this is the car, kind of an illustration of what Tesla will interpret the inbound video as. So you see the rectangle created are indicative of objects that the car's camera is seeing and looking at. And here's the medium range vehicle camera looking at other obstacles in front of it. And so it is detecting those patterns and sending that pattern information in form of an aggregate statistic to a Tesla service internally. And that's how that data it's sent to Tesla, but not the actual video itself. So the sensor thing here is kind of a very small tiny data, whereas Tesla's data is big in terms of video capture. So it cannot really travel on a very low bandwidth. Tesla does have internet in the car. There is some cars have 3G internet, some have 4G LTE, but these bandwidths are not enough to transmit like gigs of information every minute. Not possible, just not possible. So they don't do it. But concept remains the same is that that's also collecting statistical data around the perimeter, around the surroundings of the car as it travels, just like a plane board or a gas pipeline board. And they will gather these data points and store them so that they can analyze on a time series. Does that give you some flavor of what time series processing is in terms of how you can make use of these things in terms of detecting future problems, acting on them in time before a bigger problem actually happens and take corrective action within a reasonable amount of time before a disaster actually strikes. Does that get you a good perspective on what's going on? Yeah, yeah. Any questions? Okay, I guess there are no questions. So that's fine. I am assuming that I don't blame you. I think you're tired, which is reasonable. 72 hours of listening to me is not easy. Yes, it is 72 hours. And you have to bear with me 72 hours of me yapping. Literally, that's what happens. But let's go look at another picture. So I'll not bore you too much with the, but something interesting in this example. So you may have seen a variety of online games that you may have played already. You probably play even today. You have gaming devices, gaming consoles, and you have browsers that you can use to play online games. And you typically, when you use a browser, you go to some game company's website that will do a DNS resolution. And there'll be players like you and me who play. And they interact with a game server. And the game server essentially is exchanging JSON with you, with the player. A JSON is basically a file, a very lightweight structure of data that you may have seen already. But if you don't remember and recall, JSON looks like this. I'll show you. So an example JSON would be, for example, if I'm playing Pokemon Go. That's a game, right? You know that game, Pokemon Go. I hope you know this. I hope you understand what I'm talking about. And if you don't, please tell me. So I'll elaborate on that. But I'm assuming that you already know this game. Yeah. Okay. So in that, let's see whether you say Kura. Kura is sitting in some mesh and he's playing with his iPhone or Android phone. You have Android, right? So Android. And he has the Go application open and he has seen Pikachu. And he is on 228th Avenue. And now the amount of information that needs to be sent to the cloud from Sridhar's Android device need to include information about where is he and where is he. So location and some kind of structure that carries the latitude, some number here and longitude, another number here. That's your current location. So the GPS needs to report where you are. It also needs to report your orientation. Like whether you are facing East or South or West or whatever the direction, wherever you're looking at with your phone at that moment. And so that orientation, in addition to that, your accelerometer position. Accelerometer is a device built into your phone. Accelerometer, meaning it is indicative of how quickly are you moving your device. And that metric that gets collected from your accelerometer in your device is a critical ingredient to how the game actually plays. So those details in terms of metrics collected from your physical holding of the device in your hand as you play the game needs to be reported to the cloud service. You understand this, right? Please tell me that you do so I can go further. Yeah. Okay, so now what you're really doing is you hold the device in your hand. Let me grab the device. Where is the device? Oh, where's my phone? Okay, forget the phone. Forget the phone. This is the phone. So imagine that this is my phone in my hand. And so I hold my phone and I'm looking at it and I see that that's my orientation, which means I'm currently facing the West. And I turn around like this. As soon as I turn, my position and my orientation changes. So the cloud service needs to know that. So every time I'm moving, I'm basically exchanging JSON information as I walk in that direction versus walk in this direction. I am basically communicating with the cloud service that I am walking this way versus that way. And when I'm doing that, what the cloud service is actually looking at is a reference to me and other players on a map. So let's go draw a map. So here is the map. This is your sum ambition. This is 228 Avenue. And here you are walking this direction towards Safeway and you are coming from QFC. And on the highway, on the 228 Avenue, it's not a highway. On that road, you're walking that direction. So you notice that it might show you that there is Pikachu sitting right here, that way, Pikachu. And so it might notify you that on your device that Pikachu is now, I don't exactly know what the phrase that they use, but it might show you that it is like 10 meters away or 10 yards away or whatever metric is. And as you go closer to it, it might reduce the distance to nine meters away or eight meters away. So you get a sense that the Pikachu is actually that direction. So you should keep on running towards that. So you can eventually catch the Pikachu. That information exchange is happening between you and the cloud service on the backend, which by the way, runs in a Kubernetes cluster. If you do not know, Pokemon Go Kubernetes. It runs in the Google Kubernetes cluster right here. You can see that news. And you should read that actually. So let me paste that link in Slack chat. And what is happening right now is it is detecting that you are moving in that direction. So it is reducing the distance. It is actually showing you where Pikachu actually is located. And at the same time, other people who may be coming from that direction going south and they might be here away and say 20 meters away from Pikachu. So Pikachu is somewhere in here, maybe that location. And so other people hitting the same direction where Pikachu is and you're also heading the same way. It is keeping track of millions of players worldwide on a map as to what these people are, where they're heading and then strategically placing a Pikachu or some other exotic, I don't know what they're called. They're Pokemon characters. Sorry, I forgot. They're called Pokemon characters. So it will virtually place these Pikachu like Pokemon characters on the map. And this is virtual reality, meaning they don't actually exist, but it exists only when you see it through the phone so that it is there, but it's not there. So you can see it through the phone only phone. So that's the idea behind virtual reality versus actual reality. So when you understand that idea, what they are really doing strategically is placing these Pikachu like or rare Pokemon characters in spots that are of interest to their business, which means there is this Starbucks right here. And what they will typically do is place quite a bit of a number of such interesting Pokemon characters right across the proximity of Starbucks, which means people who are walking towards catching Pikachu will magnetically drive or walk towards the Starbucks location. And what happens when you reach a Starbucks? You typically very likely spend some money and that is where they are making money, by the way. Pikachu, the game itself is free, but they're driving foot traffic, people traffic towards commercial areas so that people actually get out of their home or their offices and walk towards business areas so that they can get together and spend money. That's how Pokemon's model is from business perspectives to drive people's foot traffic towards interesting areas. Now, as this process happens, when you look at this diagram illustration, what they are really implementing in a Kubernetes cluster from a Pokemon Go's examples perspective is that the interaction between the game device in your hand and the backend service that you run in a Kubernetes cluster is basically exchanging JSON information in which you are transmitting information like that, like this to be specific. You're saying my location is that location wherever you are, my orientation is facing east, I'm going that direction at a velocity or some rate of walking. So it knows exactly how you are moving around on the map. And it knows this information about every user that is interfacing with the service so that the game interaction happening. You are not actively interfacing with the cloud service, but the phone device itself is interfacing with the cloud service and actually exchanging data about your physical location as you walk towards a particular destination point that you want to go towards. So when you actually reach that destination, say for example, here's the Pikachu location and here is you and here's the other person. And you go, they go this way, you go this way and that's where Pikachu is. And so as you walk towards it, you find it. And when you notice it, you grab your Pika, what is this called, Pokeball and you throw at it. And so the first person to throw the ball and captures the Pikachu gets the Pikachu, whereas this guy may not. And so you might, or maybe the other way around. So the person who does it first will actually get the Pikachu captured. And then this guy will be feeling kind of lost that they could not catch because they could not get it. You got it, so you won. That's how the gameplay happens. Now on the backside, let's go look at what's going on here. On the backend, there is a web server that interfaces with your JSON, which keeps track of that detail in a data store. And it is basically keeping track of every single thing about every single player worldwide. And at a global scale, what has happened in the past, if I remember right from when the game was very popular those days in the Boeing factory in Everett. Say, imagine this is the factory, Boeing actually complained to Pokemon and the company called Niantic. Niantic, the company that wrote that game. They complained that, you know, there are lots of Pokemons in the factory area. And as a result, employees are not working, but they are chasing Pokemons in the factory. And that is not a good thing. So please move your Pokemons out of the factories. That's the request that Boeing had to Niantic. And this is a couple of year old story when it was actually popular. So Niantic had to do this actual action of removing, you know, Pokemons out of the factory on request from Boeing, because that is something that is a necessary thing to do because otherwise, you know, factory workers were just playing Pokemon Go in the factory as opposed to working on the planes. That has happened in many, many other places. Like, you know, the museums in Washington DC, they complained the same thing is that people who are visiting the museums are not, I think the Holocaust museum complained about it is that people are, you know, playing Pokemon in the Holocaust museum, which was obnoxious. And Niantic realized these mistakes. And so they removed those Pokemon characters from critical places like the factory and the Holocaust museum, another bunch of other places. But bottom line is what they are really doing is enabling a place, a virtual place where people are interfacing with each other based on their geo positions, their orientations, their accelerometer activity, and virtually placing Pokemon characters on a map, not real, virtual, and letting people interface with that virtual reality so that they get real engaged and they actually go walk out to a destination where the company wants them to go. And so they drive traffic towards interesting areas, which will eventually generate money for them is the business model under the hood. Under the hood, you will see the same concepts here that you will see in a typical web service. You have a data store and these web servers collect the data about what the gameplay actually is, which is a JSON file. You store that data in here. You have a classic game database builds up of all the people playing games worldwide using a variety of devices, a variety of platforms, variety of locations, variety of clusters of people playing together. And that will become a part of your database. Once you have a database, then you can go do analysis on the game itself as to who's playing what, what Pokemon characters are more popular than the other, what are rare, what are not so rare, how you can incorporate these ideas that you learn from the data to actually translate into revenue opportunities or business opportunities for the Niantic company because the application itself, the game itself is free, but they still have to make money. And so you then use that data to analyze how people are actually playing and drive that data to translate into money from partnerships with other companies like Starbucks, for example. And that's where you will strategically place logic, these Pokemon characters closer to a Starbucks or other business places are like the Bellevue Square Mall or Apple store, Microsoft store. People have actually made business relationships with the Niantic company to make sure that foot traffic reaches them. And that's where the company had made money by setting up such a structure in this example. So that does that give you some idea about what that game is, how it is implemented in some conceptual sense and how does that implement in a... It's a very conceptual discussion. It's not actually material. We don't have a live example code to run it right now for this case, because we don't have enough time for that. I think we already ran out of time. But having said, I would like to tell you a couple of things before you hang up on me. First thing, I want to thank all of you for attending the bootcamp. Thank you very much. Let me shut this video, let me open the video camera and stop the broadcast of the screen display so I can talk to tell you a couple of things for you to do as you hang up on me. Let me just stop projecting my screen. Here we go. So a couple of things, thank you. Second, I'm still here, I'm not going away. Which means that if you need something, you can always come back to me. You can ping me on Slack or call me, meet me. I'm here, I live here and I'm not going anywhere. So basically I'm here to help you. If you need something, just ping me. The next thing, you have access to this bootcamp. It will terminate pretty soon, probably tomorrow. But don't worry, I will extend it for 100 days again. And it will again expire after 100 days. But again, don't worry, you can ping me again and I'll extend it further. I have no problem extending any amount of time you need to make access to the content that we have, the past recordings, your recordings, all these things you have access to, don't worry about it. Even though programmatically, the access will go away. But don't worry, it is there. We have video recordings for you. I am here, we have exercises for you and I keep on building content, keep on building new stuff and you will have access to that also. So you don't have to worry. Most important thing that I want you to take away is to actually apply these things in your work, to do stuff and build stuff in your company for yourself, for your team and make money. I mean, money as in money for your company, they'll pay you, but do that. That's how you make money is to build stuff for your company so that your company makes money, they pay you more salary. That's what I would like you to do. And apply technology to actual practical examples in your company and if you get stuck, ping me. I'll help you. I'm here for you. And as a closing idea, I would like to ask you three things to do. One of them, I'll write them down in Slack chat. So three things, email me with these three. Email me with three things. First one, why did you join the bootcamp? Second one, what did you take away from the bootcamp? And third thing, how do you plan to apply what you took away? These are the three things I would like to receive an email from you. And so please send me an email. Three things. Will you do that? Sure. Sure. Any questions? Sounds good. Any questions? Any questions? No questions. Thank you very much for your time and this is great. Thank you. How did you like it, by the way? Just tell me, how was it? Was it good? Was it useful? Was it boring? Did I feel you asleep? It was very useful. I found it very interesting. I liked the hands, well, the actual examples you went over. They were real examples, so that was very helpful. I liked the drawings, very easy to follow. What else? And I really liked that where you went to watch the videos at a later time. Yeah, that is something that I think most people like it. And I would like you to have that ability to rewind and repeat if you like.