Cachin What's up guys must be here welcome to another video, so and this one I'm gonna do a quick review or some of my traits But before we actually get into the trade guys, I want to apologize The past we haven't been able to like post consistently some of my traits because I do trade in the morning and I try to trade a little bit in the afternoon, but Most recently it's been the weather has been so nice here in Minnesota and When I trade in the morning afternoon, I take my kids outside We go places and I end up not getting the time to do that trade review So what I'm gonna try to do is trade in the morning or record the video Of the trades that I do even if it's just one or two traits. I'm gonna record that video And then post that even if I do some other traits in the afternoon. I'm not gonna have to post those so Just so I'm consistent with that. So I do apologize. So but I wanted to do the Post this one for the trades that I did On this Thursday. So again, we traded W H L M. We treated I had no EB T E N A N Y as you can see I made some profit and I gave back some with a N Y So I'm just gonna take a quick look at the trades that I did and I'll give you guys My reasoning behind it. So let's jump right in here And so the first one that I did I think the first three I did was I know And you had this one on our watch list if you are watching and you're not part of our Discord server links in the description. Definitely go check that can join where you can get that watch list every single day when we trade so Again, this one came out of the gate. There was news about I and no because of their vaccine Testing and P. You know, there's news that the vaccine was pretty good It passed or it worked as I as expected the efficacy was good And so I knew this was gonna pop out of the gate so I had in the watch list but Coming out of the gate it was kind of flat and I felt a little bit disappointed because I I thought this thing was Just come out.  So pre market high was about 10 82 So I in my humble opinion looking at it I was hoping that we can at least get to that 10 82 or even test 11 That was my anticipation for the day But I mean, that's the market.  So came out of the gate. I'm watching this one Pull back. I'm like, oh, this is gonna just flush Then it's gonna squeeze back crosses V-wap right here and and I'm looking like hey, I'm looking at the trade I didn't want to get in here because this is the first one me kind of to make a new high I didn't want to get in here because look at my Stochastic so right here if I had gotten in it's already Showing me a downward trend. So if you look at this candle right here, this doji right here Compare straight down to my storage Indicator it doesn't match. So right here show me this is a downward trend already So I didn't want to get into the trade right there. I like it when it's crossing. So I helped myself back I didn't want to force the trade it came back and then right here This is what you call kind of like a force breakout so crosses act like it was gonna pop and then Kind of fell back again, and I'm like, okay, you try getting me there. You're not gonna get me So I gave it time to develop. So now again it crosses V-wap Held for a little bit and I'm still waiting. I really wanted the confirmation on this one And then right here, this is where I got in so it crosses V-wap holes And then right here pull back a little bit then crosses V-wap again But if you see right here, look at where it's crossing K is crossing on the offside So that tells me this thing is gonna pop. So that's where so many around here around ten bucks This is where I got into the trade So I took the trade right here and then see what happens volume comes in and if things squeeze all the way up to about 1025 but I still held the trade it got up to 10 Around the words really like 10 30 and I'm still holding the trade and then it got up here to about 10 34 35 and then I see volume set to decrease and then I sold at 10 32 I got around 10 32. So that's where I got out of the straight and then a Pull back again here and then kind of squeeze up all the way to 10 37 I didn't want to have to sit in the trade because this right here when I got when I got out It could have flushed back, but I didn't want to take that chance So I just took some profit there and walk away. So and then it tried again Flush and never look back so you can see the rest of the day It just went down and down and down and down So I'm happy that I was able to take the trade when I did because otherwise I never would have had any opportunity to take the trade guys, I again, I am so Fixed on my strategy. I don't like trading below the V-wap So if for those of you guys that thinking like a you want to buy the dip and then ride it up That's cool. There's there's other people that trade like that You can watch the videos and learn that strategy. I don't treat below the V-wap. I treat with momentum I treat when there's an opportunity for me to at least make some make some profit So that's my strategy. So that's the first trade that I did second trade was these WHLM and so this one Got on my my scanner because we can see a pre-market. It was pretty much nothing So it didn't appear on the gap scanner and then market opened To me around 10 o'clock my time. I saw it started gapping. It was like, whoa, what's going on here? So you can see here thing went from like $8 and squeezed to a hive about $12 I'm like shoot. So the first time I saw it It was I think it was right here at about $10 and some change where it was hot It and then came out of the heart squeeze all the way to 11 and some change And I'm like, I'm not gonna chase and then it got up to I think 1287 and then flush So I still like held my ground. I don't want to chase some of these stocks So I just kept watching it. It came on the new V-wap here tested V-wap again that didn't hold so Breakback came down on the V-wap and then right here. This is where I said watching It kind of crosses V-wap again right here and I see volume coming in. So I Think let's see this one. I got in about 12 or some change. I gotta look at the exact number But I got a little bit over 12 right here and then a little bit of volume came in, right? This is I almost got out of the trade right here I thought this thing was gonna fail because if you see right here My indicators are telling me that this thing is gonna cross at some point But huge volume came in just at the tip right here. We can see this volume candle right here That's massive volume on over 650,000 Shares came in at that particular point So I Stating the trade is squeeze up a little bit and I got out about 13 and some change I didn't write it all the way to 14. So I got around 13 and then When I got out just to watch it go all the way to 14 before pulling back It's like, okay, I might have missed on that one But see right after that it flushes. So I even though I complained I didn't I didn't write it all the way to 14 But I'm still happy that I got out early because look at that after that it just flushes And then never give me any opportunity to trade again from there and pull back But I think it came back again cross Vwap later in the day But still no trading opportunity if you can see right here it crosses Vwap But very very choppy and I didn't want to take the chance here and give back in of the profit I made already and then it just kind of flushed down and that was it for that particular trade And then the other trade that I did that was profitable Was this eb Et and so this one came out I treated this one after hours for a quick profit so After hours and I really I really got to this one a little bit late Which it really annoys me because if I had gotten into this one early I probably would have made some good money. So I got this into this one late. So this one. I was looking here I think this is I said looking here. It got to this tip right here $46 and some change and then pull back. So I'm looking my indicators right here. Look at that cross right there So I'm like this is a good spot. So I look at my cross I got in somewhere around 43 20 or 43 21 and then Squeeze up right here. I almost got out of the trade, but I had my stop loss at 40 $50 so I had my stop loss of my tick profit or My sell order. Sorry because it's after hours or it's on the sell order So I had my sell order at 50 so it crosses right here I'm like, oh, I'm gonna bring myself other down and get out of the straight because it looks like it's gonna flush But nope it bounces right back and squeeze all the way up here and I kept I stayed in the trade Finally, I got out about $48 and some change right here. I didn't get all the way to 49 But I got about $48 and that's where I stopped trading a particular stack But then I left went out again Took my kids out and came back Notice that it went underneath V web squeeze and then made some other moves I didn't really care at that particular point So those are the three stocks that I treated that were profitable for me. And then you did all this talk that I took that was a NY I took that one and lost some money in that on that particular trade A lot of you guys are always asking like when when is a good time to get in guys This thing is you as you trade more you're gonna see that no two stocks are the same Yes, you follow your strategy There's certain things that you have to take into account. Yes, you want volume. Yes You want to see your indicators align the way you want them to align so all those things you have to put them Into perspective, but me personally. I don't like trading below the V web So I like trading an upward trend So like right here if I was looking at this stock Somewhere around here that would have been somewhere you start looking at getting into the stock Even though there wasn't that much of a spike in volume, but at least you're trading the upward trend You're not trading down here when you buy below the V web in my personal opinion You don't know what the bottom is at that point. So let's let's just take a step back here and just take a look I'd say right here.  So if you have a stop loss, it would probably kick you out Somewhere here and so I don't want you to buy and sit there and hope that it would go up I want you to buy when it's trending up Again, is it is it going to trend up continuously all the time? No, it could trend up and then pull back at least at that point You are going in with a strategy that you know that this is trending up based on the indicators that you have The market reacts in so many different ways It could be trending up and then some crazy news come out about a stock and then you watch it crumble So you have to be aware of all those different things when you're trading a stock like this So that's what I wanted you guys to be aware of and so Before you go into a trade make sure that you have your exit Your entry and your exit in mind and in most cases if you don't have them As a bracket order if you're doing like using hotkeys You have to be quick to react So as you go in if the trade is not going in your direction you can easily get out in most cases guys You can go in the trade and if you feel confident you can do a bracket order and give yourself some leeway So let's say you you get in a trade Right here and you can say okay I'm going to put my stop loss at say 36 like down here and then my tech profit would be somewhere up here So you give yourself that room to move stuff around But again, you have to once you put your stop loss you have to stick with it Even if it comes and kicks you out you have to follow that trade through and not just Move it around and keep giving yourself an opportunity to lose money So that's what I want to make sure that you guys understand. So there you go guys Those are some of the trades that I did again Um, it was a very choppy day the market this week has been um insanely choppy So once you're trading make sure you're trading with caution Don't get into a trade if you don't have to so wait and give yourself a better opportunity to trade and make some money so Again, um, let me know in the comment section if we do have any questions If you're new to the channel we talk about how to earn money how to save money how to invest and build wealth If there's something that interests you go ahead and hit that subscribe button and the notification bell to you Don't miss out on new content. Also if you're looking to get started with investing We will have their promotion where if you sign up and deposit a hundred dollars You get free stocks links in the description below and as always guys Do you do diligence? Don't be greedy savage. Stay motivated


Thanks Santiago. Thanks everyone, welcome. My name as he mentioned is Andrew Block. I'm a senior principal consultant with Red Hat. I travel to customers throughout the globe. These are small customers who are just looking to get into containerization to large enterprise customers. I'm not going to lie, Exxon Mobil, who I'm going to be bringing up in a moment is one of the larger customers. So there are typically two customer user bases that I work with when working with all these customers. One, it's going to be from an application development side, they're looking to take advantage of containerization, application portability, being able to scale as they need to. Or from an infrastructure side, they want to be able to manage the platform. They want to be able to get away from managing old virtual machines. They want to go ahead and start taking advantage of a shared environment for them to provide to their customers.  They're not application focused at heart. They're infrastructure. And some of the use cases that they have developed has not only transformed their team, but has transformed how the organization manages their own infrastructure. So I'm excited to be able to introduce to you the Exxon Mobil team. Guys, come on up here. I'm Lucas Paglia, I'm an electronic engineer and I work on the automation of infrastructure. Before starting with the topic that we came to present, I wanted to tell you a little about the company. Although it's not very open to the public, and many of you don't know what it is, Exxon Mobil is the number one oil in the private sector. It's also in the petrochemical energy industry. Its initials are about 135 years. It started as a retailer of Kerosene in the United States, a small region, and it's currently the main company in the sector, and it's recognized in almost all aspects by the rest of the competitors. We have presence all over the world. They're not just offices, refineries, franchises and service stations, and platforms in the ocean. They're sites of different types. What they have in common with these types is that they require connectivity services, which is fundamental and also accessible to applications. In total, around the world we're more than 71,000 employees, particularly in Buenos Aires, we're around 1,000. These points that have been marked are the service centers, the main offices which we provide services to the rest of the sites in the world. They require us to operate. Another particularity, perhaps Exxon Mobil is better known in the country for its brands like that, the service stations or Mobile, the lubricant brand. We continue. To support this infrastructure, we have around 30,000 devices. These are network or servers, mainly. The problem with this is that being so big and constantly changing, the issue of scalability and maintenance of all our corporate networks and services is very difficult. What forced us to look for an automation, a solution to all this problem, has already been going on in our hands. This is a huge number of devices and with the amount we are in all these sites, everything is already being complicated to handle. Many of the operations that are currently being done are manual. It is being focused in the last three years, as I am going to show you now, to automate as much as possible. As they were saying before, we are not an application team. Our focus and our core business is infrastructure. I am particularly involved in the network area. Mauro also, Lucas is more on the hosting side of servers. This is a bit of the evolution of Exxon Mobil, particularly the infrastructure area. It has been a more DevOps culture, to give a little context to this. Initially, as I said before, it refers to three years ago. We were doing simple operations, like legacy, as you will think, to enter the team, configure it, all by hand, all by hand. There were perhaps good practices or things prepared that were calculations. There were few applications or scripts that were isolated. They were owners of the same teams, complicated things for the style. And if there was a small application, it was in virtual machines, which were not within our reach, but it was already the area of knowledge. It should be noted that there was no developer knowledge, there was no developer within the teams. They were all engineers specialized in that particular area of infrastructure, security, networking and so on. The first change that arises from this was in 2017, with the introduction of Docker. When containers first arrived at our company, what made this easier was the process we had to get access to hosting solutions, as in the BIMS case, and made this easier. It gave us a lot more flexibility to start creating. At that time, maybe there were people who had no developer knowledge, but it was more curious, so they started creating things. That is, this emerged within the employees that came up and down. We started experimenting with this to try to simplify the operations that we realized were always the same and that they could even be shared. We also began to consume a lot of the tools developed to be totally common, like surcom management, Git, in our case. There are all those things that were not common at all for us. Although there was an impulse at this time, we continued to contribute a lot of value, because it was difficult to translate it to a script that was the complete configuration or everything that we wanted to automate. For the year 2018 there was another big leap, which was the introduction of OpenShift in our environment. I did not mention it, but I did not have much knowledge in containers at that time, and what OpenShift came to solve was a lot of that work on maintaining the cycle of life of containers. It was very difficult to explain, for example, how an engineer in the web had to maintain containers, it was something totally new for them, added to the fact that he had to develop applications for that. So OpenShift made it very easy for us to get a platform on which to host our applications. That year was a great progress, we included CAC Pipelines. This was, unfortunately, a lot of repeated efforts in different areas. It was complicated to collaborate, because different steps were made in all the teams, also because of the location, how we are distributed around the world. It was also complicated, the issue of collaboration. So there was a lot of reuse and more. The good thing about this was the creation of many applications. At this time it was more common in the infrastructure teams to see people with a developer background. So that's how many applications began to appear, but many compared to the ones that used to come before. But that connector was still missing, it's like we automated, maybe in a more formal and professional way, certain operational tasks, but the whole process that we actually carried out was not in line, so we continued to see manual tasks. And this also changed a lot when we introduced Ancior as a framework of automation, among others that we used to all the teams. We had Ancior as a center of orchestration of all our processes, all our tasks, this already reaching the end. There was when we began to consolidate teams that were closer to an OBS culture, although they are not 100% OBS, there are already people with infrastructure that understand what they have to do, or at least understand how to consume their services, how to try to translate their infrastructure, their definition in code through Ancior, execute it. This seems to be an idea, for example, I want to kill a router and make the definition of the whole team, configuration and more, that Mauro is going to give you in more detail, but to make it an idea of the work that we do. Now what the guys are going to present, Mauro from the network side and Lucas from the server side, there are two real cases here at Buenos Aires. The case of Mauro is closer to the final stage where several teams are integrated to perform a task in common, to give a service to the real client, and it is not just a team function. In the case of Lucas, it is how they expose their services to their clients, it is the most internal group, but perhaps it is in a previous stage, they do not have an orchestration with many other teams to perform a much more provocative task. Well, one of the problems we found or the challenges we found when we wanted to start automating it was a bit what Seguiel said, the difference in background between people of traditional infrastructure and developers or people who wanted to start putting a little more with the code. This was a very big barrier and what we decided to do to facilitate all this progress and also consolidate all the services we wanted to try was develop a framework that easily allows you to start automating simple tasks and then also more complicated tasks. That is why we started developing this framework and we had to decide with what application or what part of all this process of configuration of network teams and maintenance of the network and we were going to start. At that time, the standard configurations of the network teams were saved in Excel, like many companies perhaps, and it was very difficult to consume those configurations. A network analyst to configure a team had to find the Excel, open it, fill certain variables depending on the team, copy all of that and paste it in the team as a copy paste. What was very cumbersome could cause many problems and it was not optimal. That is why we developed what would be the first application that we call standard configurations, which is basically an IPI that by providing certain information such as the hostname of the device, the operating system, the version, etc. returns the standard configuration for that device. This also allowed the collaboration of the infrastructure network teams since they were in charge of writing standard configurations. What we developed was mostly the application itself that did this interaction. With this we got many advantages. First, we started to version the configurations in Git, which was very easy to determine what changes they made, who made them, much simpler than in an Excel. Then there was what we call Single Source of Truth of standard configurations, and we also reduced time and errors. And we allowed, a very important factor, the integration with other applications. This application could be consumed by other applications like Ansible or by a user, since it also had a frontend. But after this, what we wanted to do was finally start to put these configurations in the network teams automatically. We realized that this was going to cause certain changes in the network and there could be, perhaps, errors, there could be problems. And we decided to continue with another application that was to verify that after a change, the team was working correctly. This is why we built our next tool. We call it Change Testing based on Jenkins, what it basically does is take a snapshot or a photo of the device before making a change, then the change is made automatically and then another snapshot of the state is taken afterwards. With this, a set of tests is carried out and it is verified if the state of the device is correct, is it desired or not. If it is not desired, the configuration can be reversed quickly. This was the first tool that we noticed that collaborated a lot with the infrastructure team and automation teams that had more background, more developers, since we also developed the tool itself, but all the tests were developed by experts on the network since they knew what they had to try and it allows them to extend these tests whenever they want without going through the automation team itself. So it was a very important tool. At the same time, we were building the tool to automate these configuration deployments. After some researches, we decided to go for Anciol since it had a lot of network modules and it was very useful in the industry for the network area. We started to create certain scripts in Anciol to check the configuration of the teams, to measure the teams, etc. We realized that to scale, we needed to run these scripts in a platform. We decided to start with AWS as a quick start for those of you who don't know, Frontend is a platform to run Anciol playbooks that allow you to do key management, schedules, dashboards, a lot of things that are super interesting and that are useful when you need to scale and have a report or an inventory. It's an Open Source project and it's sponsored by Red Hat, the Enterprise version called Anciol Tower. This was one of the platforms where the engineers started to put playbooks and we're still on this day that they start developing more for themselves, but any infrastructure team can start developing in Anciol and run with that platform. Finally, to finish the framework, as we call it, what we have are the sources of truth or database, which in general are many database that we have to provide different information to other applications, like the inventory, we also save reports, etc. That's how we built this framework that was advancing a lot since it started and now we're in a stadium where a lot of Red analysts collaborate and put new features in this framework that the automation team developed. It was a great change. All of this is deployed in OpenShift. This allowed us to scale much more easily. We went through the stadiums that Sequiel said, the Standard Configuration was first in a Docker container in a virtual machine, then we moved it to OpenShift and it allowed us to scale all of the attributes that we have. The same with WX and the Change Testing tool is all in OpenShift and it also facilitates with the Pipelines the deployment of new versions. It was a big change. And to finish, I wanted to share in a very brief way two cases that we are about which we made them about the automation framework. One is the automatic media of Red teams. Basically, what this does is that every certain time it scans all Red teams, verifies that the configuration that it currently has is the same as the standard that it takes from the other tool and if it is different, it puts the standard configuration on the device to maintain reliability in all Red teams. This is all in automatic form and the other is in the case of a cyberattack to Red, we have the possibility to isolate Red by means of ANSIOL to protect us. So that would be all, Lucas. Thank you. Well, on the side of servers, many of the 30,000 devices that SQL mentioned are obviously servers and the usual requests that we have are obviously the high and low servers and the access control. What we realized was that the way our clients had to take requests was directly contacting members of our team or through a generic system where the user, in this case our client, had to type what he needed and in a way not standard. What resulted was that there was usually incomplete information because we had to put it or we forgot to put something or we were in disorder and also the format was not standard which did not allow us to automate what would take that request. We had to see by hand all the requests, see what information there was, what information there was, talk to the client and that generated an idea back that in the end what it ended up generating were many delays in the execution time of that task of typical operations that today could be much simpler. Our approach to solve this problem was to do a web self-service portal that is to say an interface between the user and us where the user could enter all the information he needed and it was always complete so as not to let them submit a ticket or enter a request without giving all the necessary information and also we could control the format of that information which then allowed us to know the format, to automate that is, a client from now would be able to enter a web form, complete all the data, if he did not have all the data he could not complete that form once completed the data, send us the request and instead of seeing it manually we could send that to a computerized script that processed access controls. Finally, what we added was a database of data to save statistics to be able to see how this helps us improve the time of response, how many requests are accepted, how many are rejected and be able to control all that and have a feedback of everything that is happening and how this definitely improves the standard process we had before. Well, here what I wanted to tell you a little bit was the story of how this was evolving within the team. The first thing we did was an environment without containers, a Linux and what we realized with that was that every time we entered a new member of the team it was impossible to replicate that environment. It was like, there was to be a way to install all the packages again and something was always missing and the worst thing we thought was what would happen if we have this one day in production and we have to replicate the production environment how long would it take? The time that took that to generate the environment again made us think of alternatives like containers. So the first thing we thought was to move everything to Docker. At the end of that time, besides the optimization of resources it was the power to generate all the environment again for a new member of the team in this transition to the DevOps team that we were having. When more people from operations wanted to move to development there had to be new environments and obviously to generate production when we want and in the way we want. Finally, we moved to OpenShift because in a DevOps world there were many things that we didn't have that were, for example, the fact that we could scale many environments to have high availability and as we were working mainly with web formers we needed security on the web pages. And in OpenShift, for example, adding security to SSL is as easy as building a checkbox. And already in an open and close of eyes we had a lot of tools that we didn't have in a separate container. Here we had an orchestration tool that I said before. All this code, a practice that we started to take into account was to use version control but also to use version control that allowed us to work collaboratively take all the previous versions that we had in our code in case something bad happened and we had to cover an earlier version. We implemented a model of what the branch of the repository was. So that we could separate what was production, what was development and also this transition of the box that when I knew a member of the team we could work in two functionalities at the same time without stepping on us then being able to merge it all together and what gave us control of the version was that. We were already working on other initiatives like, for example, Ansible but here we added, for example, the branch model for this project. And finally, what I wanted to show you was more or less a diagram in blocks of what would be the application. We have on the one hand the user but with the front-end web that would be the interface for the user all of that is supported by a Python backend all of that code is under version control as in the previous disk and now that we had the format of the standardized requests we could automate the whole process. So all those services would also have to interact with our legacy ticket system and everything that was working before. So there we have a communication between the legacy ticket system that should send the data to what would be another microservice of Python that is blocked up there that is in charge of recouping the data. We are starting to use non-relational database and data visualization models that consume the data that are in the non-relational database so that we can have everything visually and easily to access all the data and see how this is progressing in time and how what we are doing will be the response that we have to the users. Before we go to the final conclusion what I just showed you guys is the lowest level that we can really show what the company allows us I would like to talk much more about that but we can't put it here unfortunately To conclude this I really wanted to highlight our perhaps the biggest challenge as I was saying before we are infrastructure people we work with people very focused on that and perhaps different to a developer applications whose work or uses this only for the hostages and other applications our work doesn't end once the application is created but together with that we test the service to automate all the infrastructure and have the service available and make it continue to grow really the knowledge to distribute the knowledge between networks and developers even server people is a mix of the three to generate all this it is very difficult at global scales too as I said before to share all this and avoid to generate more effort all creating the same once and again we are still in that process we are still exploring a lot of teams that come to the last stage that I mentioned several that are already integrating new technologies like cloud others thinking things related to artificial intelligence and more all for infrastructure really that is our goal and we wanted to share with you all our evolution in this process thank you very much


Sport and action photography is all about speed and accuracy. When every split second counts, you want to lens with a good zoom capability to get you up close to fast and potentially dangerous subjects. If shooting from a distance, you'll need a powerful zoom lens to be able to focus in on the detail. A 55-250mm or a 70-300mm are ideal for these types of shots. When photographing something that is travelling at speed, good autofocus is important to ensure the camera always stays in focus. The more autofocus or AF points the camera has, the better it will be at tracking moving subjects. To ensure your focus stays on the subject, make sure your camera is an AI servo or continuous autofocus. To ensure you get the shot, make sure your camera is in high-speed continuous burst mode. Setting up for lighting and focus beforehand will help in achieving the perfect shot. You can then track the subject as they come into view. Following them into the position, you have chosen to capture the shot. This is called a classic panning shot. Panning is a great skill to learn for sports photography. This is where you move the camera from one side to the other in a horizontal or vertical plane following your subject. This will result in the subject looking sharp whilst the background has the illusion of movement. Another key factor is shutter speed. You can either slow the shutter speed down, creating a slight blur and motion to the image, or if you want to freeze the subject with no movement, use a fast shutter speed. Also think about whether video capture is important to you. Most digital cameras have video capability. For great results, you'll need at least full HD video quality, allowing you to capture high quality film at the click of a button. It's important to remember that sports and action photography is not just about having the right equipment. It's also about thinking and preparing for the shot beforehand. You often only get one chance to capture that willing shot, so make it a good one.


Sheikh Dizyan Gadio from Senegal, former foreign minister, and also, of course, now in charge of Pan-African affairs for the Council of Strategic Pan-African Affairs, let me ask you about Pan-Africanism. I mean, it's been a dream for many decades. Does it really exist? Can it exist? Actually, the tragedy of Pan-Africanism is to have been taken as a dream. And actually, it was a necessity, almost an emergency for African countries, because in the past we have known that form of governance, like federal governance, you know. The Mali Empire was huge, covered like most of West Africa today. And all the big empires, Africans have never organized themselves, like, within these tiny, small states. The French, when they were leaving Africa in terms of decolonization, they decided to balkanize Africa. That's what President Senghor, the first president of Senegal, was very mad about. He said, please, don't balkanize our continent into small, tiny, and non-viable states. And that's the problem we have today. I think we, the British, probably, to be certain. You were very much in solidarity with your... But something interesting is the only big federation we have in Africa was a former British colony was Nigeria. And then Tanzania is a federation, you know. We have somewhat helped more keep those entities together than the French. Well, there was a big war, the Biafran Civil War in Nigeria. But it came way after. And then I think it was back in 1917 or 15, I'm not quite sure about the date, that the two sides of Nigeria, northern and southern, were put together in one single country, one single entity. Today, Nigeria is the powerhouse of Africa, which is a proof that Pan-Africanism works, that we need to get together. Today you have, like, regional groupings, like ECOWAS. ECOWAS, you know, if you want to solve political problems by using economic means, you will never succeed. You know, you have to understand that this is integration, economic integration is more of a political issue than an economic issue. Economy is the area of competition. While political unity is the area of ideals, you know, people want to be together, wants to work together. Today we would have had, like, 350 million West Africans working all together in the respect of their, you know, identities, Senegalese is not a Nigerian, Nigerian is not an Ivorian, and so on. But then this diversity and this richness, and then all these resources that we have. Yes. Together we would have defended the Côte d'Ivoire café and cacao and so on. And then all the gold of Senegal, you know, the oil of Nigeria. But we are divided and we are rich. Potentially, it could be a fantastic continent. It could be. I mean, conventionally we say the 21st century is the century of Asia, but it could easily be the century of Africa. Most definitely. That's what actually people thought the 21st century would be the center of Africa. I think we may have made one major mistake, which is we did not pay enough attention to people who are saying that the 21st century will be first and foremost a spiritual century. And then all these religious contradictions and problems came back to haunt us. And then world geopolitics, you know, when the US goes to a war against Iraq, people don't see governance issues. They see a civilization going to attack another civilization, another religion, another culture. And the outcome is a disaster for all of us today. Then like you say, China, Japan, South Korea, Indonesia, India, all those Asian countries were also emerging as potential, you know, candidate to the leadership of the world. So Africa still remains the continent which has like one-third, one-third of the world natural resources. We have everything in Africa, gold, oil, young, dynamic people. The human capital is there. Most definitely. What they call, you know, the demographic dividend, you know, Europe is aging, America is aging, Asia is aging. Only Africa is becoming younger by the day. Nobody knows how this miracle came about. But these are governments capitalizing over that asset, the African youth. Today, what we see is this youth is not taken care of. They, you know, they go for migration, crossing desert, crossing oceans. That's a tragedy also. It was really unique to use the human capital at home. On that positive note, Sheikh Dijon Gadio, thank you very much and the very best of luck for Iraq. You're very welcome. Truly, Africa has to solve the issue of its leadership. I always say Africa has three problems, number one leadership, number two leadership, number three leadership. Once we take care of those three issues, then you will see Africa rising again. Indeed. Thank you so much. You're most welcome. Thank you.


Good evening, thanks for coming out tonight. So yeah, like you say, I'm Brian Benz, I work at Microsoft. Been there about six years and before that I was at IBM and Deloitte and some other companies and I was hired as a evangelist slash developer advocate, developer relations person for Java. I've been working with Java since about 1999. I wrote some books and some other things and it was a long time ago. This is my third trip to Singapore, which I'm thrilled to be back actually. 30 years ago I stayed in Pearl City at Johnny's Guest House. That was a long time ago. And it was like this rooftop place with minor birds outside and stuff like that. And then the last time it was about 10 years ago I was doing some work for the Singapore Army and I was staying at the Hilton on Orchard Road and this Marina Bay Sands, this wasn't even here yet. And the thing I remember most about that trip was there were no air conditioning in the buildings I was in and I wore suits back then for working. So it was a rough 10 days or so working out in the suburbs here of Singapore. But anyway, so now I'm here. I just spoke at a conference called Ignite the Tour. Somebody, was anyone there by any chance? A couple of you, okay. So just a couple of people, but it's a tour that's going all over the world and I took the opportunity to stay on and speak here before I go off to Johannesburg, which is my next stop in South Africa. So yeah, anyway, so tonight we're gonna talk about, enough of me talking about micro profile and open tracing. How many people are familiar with micro profile? What it is, just to show hands. Okay, so it'll be new. What about open tracing and what that does? A couple, okay, okay, cool. Well, basically I'll give an intro into what micro profile does and then I'm gonna show it running on my local machine. And then I'm gonna show you how you can run it on containers on Azure, on the cloud. And then I'll talk a little bit about how you can run on Kubernetes and I'm gonna finish up with a demo on Red Hat OpenShift. So it's kind of a mix of all open source technologies. Everything I'm gonna show tonight is on open source and available publicly. So, have you guys ever seen one of these before? This is a jiggler. I was talking to someone earlier about this. So this is a jiggler from the olden days. When you had the low DVDs and CDs on your computer, you had something like this. It was usually big and you plug it into the computer and it would actually not shut the computer down while things were loading. So I use it for making sure that it doesn't shut down while I'm getting ready for a presentation and blabbing away. So, yeah, so let's talk about Micro Profile first. So Eclipse Micro Profile, it's an Eclipse project. I'm sure everyone here in the Java world is familiar with Eclipse already. It's been around for a couple of years now. It won the Duke's Choice Award in 2018. So what is Micro Profile? Basically, all these companies are adopting it and what they're saying is essentially we don't have any, you know, when you build a microservice, there's no way to sort of ensure that everything's gonna communicate with other microservices, right? So how do you actually get a microservice to talk to other microservices? There's supposed to be these loosely coupled things that actually connect through protocols. But how do you choose what protocols you're gonna use for those? So the Eclipse Micro Profile, it's not a foundation, it's just a project. They got together and they said we're gonna use three basic things. DAX-P, which is RESTful Processing for Java APIs. And then Context and Dependency Injection, which is CDI, is another project we use. And then JSON-P for managing JSON. So anytime you're gonna use RESTful Endpoints, anytime you're gonna use Context or Dependency Injection or anything you need to do to talk to different, to inherit things from one microprofile microservice to another, you should use CDI. And then for Processing of JSON, you should use JSON-P. And those are the three basic things that everybody decided that they should use. And since then, things have been built on top of that as well. Other projects have come into the fold and they said, you know, okay, we'll use those three things as well. And so basically all of these companies have agreed that if you're gonna build a microprofile microservice, it should use these to actually help build it. Those three things that I described. Let's see, what else can I show you here? So since then it's sort of evolved into all these projects. And these projects themselves have importance because they allow you to do things like add, let's see, health checks into your applications. If you wanna use metrics or let's see a REST client, they have a built-in REST client. And here's Open Tracing. That's the other thing I'm gonna talk about. So one of the main parts of microprofile is Open Tracing because when it comes to managing the performance of your microservices, it used to be very easy to track. Let's see, you've got a website and you've got an end-to-end application that basically someone logs in, they look at your website, they identify themselves through some means and then they purchase something and then you can track that purchase. When they purchase it, the inventory has to be reduced. Revenue has to be processed. So there's a financial part of the transaction. Everything has to happen. And that was fairly easy to control when you're talking about sort of a monolithic application. But what if you have one microservice to handle the website, one microservice to handle the financial transaction, one to handle inventory, et cetera, et cetera. You get the picture. One to handle identity. How do you actually trace and track your performance across all of these microservices? Okay, and so Open Tracing is a way to do that. And that's an Open Tracing, let's see, I had it here a second ago. Is it there? Yeah, the Open Tracing API. So Open Tracing is once again, so all these things are on GitHub as well, each one of the projects I was just talking about. If I go in here to Open Tracing, click here, it actually takes you to the Open Tracing project and then somewhere there it's on GitHub, but I can show it to you right here. This is actually the Open Tracing API project as well. So this is once again, open source and a bunch of vendors have got together and decided on standards that they can use for tracing things across different applications. So for Open Tracing, what they mean is a end-to-end process, like I mentioned before, someone logs in, inventory, purchasing, et cetera, et cetera. That's a span, and then there's a trace which is a specific performance of one of those microservices. So everything gets put together and the trace actually tracks each microservice and then the whole thing from end-to-end is called a span. And if I go to OpenTracing.io, you can see some of the projects they have as well. And where's the, there's a hub, GitHub. So they have a bunch of different APIs for Open Tracing as well. Oh, there's the registry. Yeah, this is a registry. It's kind of like a hub, but basically these are all the people who have built tracers. And these tracers for Python, Ruby, et cetera, et cetera. And some other ones for like LightStep is a big partner of that. They've done some things with Scala and Acca and some others. Let's see, Zipkin, Yeager, a few others. I'm actually gonna show you Yeager today, which is an implementation of the OpenTracing standard. But these are all implementations of OpenTracing. So the idea here is if you have a micro-profile microservice and it has an OpenTracing project built into it, like here's Cassandra. If you have Cassandra as part of your microservices and if you're using micro-profile, it's a bonus, but you don't have to be. You can just use Cassandra and some microservices. You can use the Cassandra provider here, the Cassandra driver to manage traces for you. It's called a tracer that actually tracks things. So that's just one example. Couchbase, Elasticsearch, Hazelcast, some of these names I'm sure you recognize. JDBC, of course, and a few others. So these are all tracers that are pre-built and you can add them to your OpenTracing implementation. And there's two main OpenTracing implementations, one's called Zipkin and the other one's called Yeager. And these are open source implementations. So these are actually, they've taken the standard and they've made it into something, a project that actually runs. The Yeager's written in Java and it runs on Docker. I'll show you an example of that in a little bit. But basically, that's the idea behind that. Same with micro-profile. So micro-profile has an implementation called Thorntail. And Thorntail is written by Red Hat. It's managed by Red Hat. But it's basically a standard implementation of the micro-profile. It's not a standard. They're not organizing this into a standard's body. But the micro-profile project, basically, that I have to be careful. If I say standard, it's not a standard. So I have to say something, but I guess micro-profile project is the implementation that I've got. So Thorntail is what I'm going to use for my demos today for this. So hopefully that gives everyone a good idea of what open tracing and micro-profile do and the implementations we're going to be using today are Thorntail and Yeager. So I'm going to run some Thorntail application that actually accesses open tracing using a Yeager implementation. So let me start with that. Let's see here. What does the code look like, Brian? Stop yammering on about all the different standards and things. OK, so the code itself is actually kind of interesting. This is Visual Studio Code, by the way. How many people are familiar with Visual Studio Code? OK, cool. It's a Microsoft project. It's open source. It's free. It's a text editor that you can use. And in this case, I'm using it to edit a markdown file, but it also handles YAML, Java, Docker, all kinds of other things as well. So what I'm going to show you today is actually, let's see. Let's go in here and let's have a look at the actual. This is what an application looks like. In Thorntail and or in MicroProfile in general, there's a big POM file and less code in general. So if I look at the POM for this particular application and I'll get into the Java code later, I'm assuming everyone's seen Java code. I've probably seen a POM too, but this is the specific one for setting up your Thorntail application, which is MicroProfile. Of course, this is just the way that Thorntail has chosen to implement the MicroProfile standard, those three things, Jaxrs, CDI, and JSONP. You could do it all with code or anything else, but they've decided to go through Maven and use a POM XML for that. So if you look here to set up Thorntail, you just set up a dependency. The first one is IO Thorntail. You use a bill of materials all, and that basically imports the Thorntail, gives you access to Thorntail functionality, basically. And then you use the Thorntail Maven plug-in to actually make sure that everything's updated. Fabric 8 is used. Now let's go down here. So this is actually where things get interesting. So because if I go back into MicroProfile real quick, the project here, each one of these projects has a base of a POM, it has a POM XML dependency that you can simply add to your application. And that will actually pull in all the code for you. So in this case, we've got the basic one, MicroProfile config, MicroProfile health, Jaxrs. We've got some data sources we're working with, JPA, H2 database, but we've actually changed this to be a different database. And I'll get to that in a little bit. And, oh, actually I'll get to it right now. So the H2 database is what you use when you're running it locally. And then we actually have Cosmos DB, which is an Azure database that's compatible with MongoDB and Cassandra and a few other things. And I'll show you what that is in a bit. And then we go and we want to add a Yeager. This is our open tracing implementation. This is all I had to add to this code to add open tracing to my application. There's a little bit of configuration you have to do. You have to open some ports to tell it what port to talk to. It talks via UDP instead of via TCP because it's a little bit more performant when you're doing this kind of work. Everything's on the local machine, so it's assumed that you're not going to lose anything through network traffic. So UDP was acceptable for this particular implementation, and so that's what they use. And then MicroProfile Open Tracing as well. So we've got the Thorntail Yeager implementation, then we've got Open Tracing, which allows us to access, basically allows us to shoot off all of our tracing information, which Yeager will then pick up. So what does this actually look like when it's running? Let's see here. Let me show you this first. This is just an application that was built with the help of some guys at Red Hat. And basically, to run this application, I just say Maven Clean Thorntail Run, and it's going to take a minute to run. And I want to show you a couple things here. For those of you, and this is one of the reasons we wanted you to say at the back, oh, what happened? Wait, wait, wait, wait. Oh, you know why? Maybe I'm using it somewhere. Hope not. Maybe here? No, try it again. Let's try the same thing again. Nope. All right, where am I using this? I'm not using it here. Oh, maybe. Now, this can't be. Let me close this. Now, let's see what happens. OK, where is it? Local Yeager CDTarget. Let's see here. Demo.war. Why is it being used? Hold on, let me check and see something here. This is live code, folks. OK, nope, Java. There it is, in task. OK, something happened, and it was, OK, fingers crossed.  So basically, a few things I want to show you here. And as this runs, it takes a while to run the first time. It's going to build the war file, and it's going to resolve a bunch of artifacts. This is always the scary part for me when I do live code, because it's using Maven, and it's pulling down a whole bunch of packages. And I don't know if something's changed. I did try it a few hours ago, so it should be OK. But sometimes it changes a few packages or something, and I have to change some code. Generally, no, though. We'll see. So once it gets past this part, we get into the interesting part. So because this is using Red Hat technology, because it was written by Red Hat, so these are all the things you see it said installed fraction here. These are all the things you saw in the Palm.xml. These are all being added automatically, including JPA, the Open Tracing, and Yeager, and stuff like that. Then if you see here, it's starting up a Wildfly. It's using actually Dayboss and Wildfly. And it's using Wildfly Swarm to actually run the application. That's the original term that they used for the micro-profile implementation. Now it's called Thorntail. So that's why it says Wildfly Swarm there. And then Wildfly, they have funny games with their branding. So their Jboss server, the open source one, is now called Wildfly. Wildfly Swarm, which used to be their Thorntail implementation, is now called Thorntail. So that's why you see in this code references to Wildfly Swarm. And you all see references to Jboss. So basically, we've got this ready now. And if I want to run this locally, I can. But I want to do one other thing first. Let's fire up that. Hopefully I didn't lose everything here. No, good. So the other thing I want to do is I want to use, and this just takes a second, I want to run Docker, and I want to fire up OpenTracing. So if you saw in the code over here, it actually read about around the bottom here. It does tell you that it's implemented Yeager, a Yeager interface, and it's also implemented OpenTracing. So OpenTracing is what's basically going to create these traces that get sent. The Yeager implementation tells us what port to send them out on and stuff like that. And then all we have to do is fire up a Yeager instance on the same machine, and it will start reading the UDP that gets produced by this application. So let's start a new command window. There we go. So basically this is going to run. Oh, okay, so maybe this just works now. Hold on. I'm fun today. Let's see here. Yeah, Yeager's already running. Okay, so I tried it a few hours ago.  But this is running now. And as you see here, it's got Yeager query is a trace that it's looking for. So Yeager query is the standard basic trace that you get with OpenTracing slash Yeager when you don't set up any environment variables. This basically handles all of the Yeager queries at the moment. So let's go in and we'll look at what the application does. How many people are familiar with this? Okay, cool. So this is a game of Minesweeper. And basically what it does is it's actually going to use on locally, it uses an H2 database. And it sets a score here. So every time it writes that score, it's actually updating Yeager. So let's try, I'll do three games. I always do well when I'm in front of a crowd. And then I heard a story about Bill Gates was addicted to this game for a while. But anyway, I don't know why. Okay, so now it's there. So if I refresh Yeager over here and I do a Yeager query, you're gonna find some traces. Okay, so the traces themselves are here. See these little dots? So the trace is, if I click on one of these little dots, this is the trace. And this is actually also the span at this point. But normally if I had more than one trace, more than one micro profile, you would see multiple spans here in a little drop down sort of cascading system. Now, graphically what this thing does, and this is just default, very basic stuff. You can also buy commercial open tracing implementations from companies called LightStep and some others. If the circle is, the bigger the circle is, the slower the trace. And if it's over here on the right, actually, so if it's up here towards the top, that's the slower the span as well. So that's the whole idea is you want everything to be kind of over here in this area. If it starts getting over here, that means that the span itself is slower. And if it's a bigger circle, that means the trace is, wait a minute, that means the span is, if it's up here, is slower. And if the circle's bigger, that's the trace. The trace is slower. So that's the idea behind this. And as you can see, everything's running on my local machine now. And it's just a really basic implementation. But I didn't really have to set a lot up. I just had to add those dependencies in my pom.xml and it runs everything for me. So because this is Docker, we're gonna move into some more interesting things with Azure now. We're gonna take this and we're gonna Dockerize the whole application and then we're gonna deploy it out to the cloud. And I'm gonna use Azure, because I worked for Microsoft, but this could actually be done as Docker. It could run on any cloud platform if you wanted it to, although I do coincidentally recommend Azure for this. And I'll show you why in a little bit. There's good reasons. So let's see here. So the first thing I wanna do, oh, actually, yeah. One of the other things I did wanna show you is if we go into the thorn tail docs, there's a few ways besides the pom.xml to actually set up your Yeager environment variables and your settings. And you can use environment variables in a local machine. You can set up the pom.xml as I see here. And then there's just writing it directly into your code as well. Could be done too. So this is all in the thorn tail docs and you can get more details on how to set that up. All right. There we go. So the next thing I wanna do is I wanna actually set up, I'm gonna set up something on Azure. And to do that for, I'm gonna use a resource group. So I'm doing awesome scratch. There's nothing on the cloud right now. Nothing pre-baked. I'm going to set this up. So first thing I do, this is as I mentioned before, Visual Studio Code, if I hit control back tick, actually get a terminal here that I can use. This is a bash shell terminal. How many people here work with Windows as their desktop? A few? Okay, about how? What about Macs? Okay. So if you work with Mac, you can actually use the script that I put together. You can find it on the cloud on GitHub. Let's see here. That's the open service broker. It's called bbends microsweeper demo. But what I've done is I've downloaded my local machine, I cloned it, and then I actually set up some environment variables. So it runs with Cosmos DB when you put it on the cloud. I'll show you how to do that in a bit. But the first thing I do, I set up a Visual Studio Code, and then I can fire up this window here, and this is a command window. It's gonna send commands to here. Now one of the interesting things I can do with this, the reason why I asked about Windows or Mac, this script I'm actually running for this is actually written as a bash shell. So I can run all of this as a bash shell. It runs on Windows Mac or Linux, and we have something called the Azure CLI that's actually already also runs on Windows Mac or Linux. So you can do all this on any platform you want. In my case, I'm using Windows and I'm actually writing to a bash shell. But there's some interesting options here. I can, I select my default shell. I can use command prompt, power shell, WSL bash, or git bash. In this case, I'm gonna use WSL bash. WSL bash for those of you that aren't using Windows is a full, or even if you are, and you may not have this, this is a full implementation of Linux, of actually Ubuntu Linux running on top of Azure inside your Windows machine. And that's how I can actually make bash commands work properly. You can also use git bash. And to do that, I just set up the shell here. So this is actually right here is the shell. I have another interesting option here, which is open bash in Cloud Shell. Now what the Cloud Shell is, is something kind of cool. If I go over here, shell.azure.com, this is actually a shell in the Cloud that you can use for this. So I could actually run this script on the Cloud as well. So what the script's gonna do actually, I'll just talk a little bit about it. It's actually gonna create some environment variables, then it's gonna set up what we call a resource group, and it's gonna set up a container registry, which is like Docker Hub, and I'll explain what that is in a bit. Then it's gonna create an instance of this thing we call Azure Container Instances, and it's gonna use the registry to deploy the containers out to Azure. And I'm gonna set that all up through the command line. But I could do this on, like I say, Windows Mac or Linux. And in this case, I'm in a browser, and I just opened a window here, which is on the Cloud. So I can access this from anywhere. I can access the Cloud. And if I do az, I get the Azure CLI, and there's all kinds of things here, basically to send commands to Azure to tell it to create things, edit things. Destroy things, all kinds of stuff. It's a powerful language. I can also, somebody was mentioning Cloud Foundry. Cloud Foundry is built in here. I didn't have to install it. It's already there, Terraform is here. Let's see, what else? I don't know. There's a whole bunch of languages here that you can use. They're all built in. So if you already have bash scripts, if you guys were already invested in bash scripts, you can run them on our cloud. Oh, this is a cool one. So Visual Studio Code, I mentioned. It's an open source.  There's a basic version of Visual Studio Code if I just type code. I'm still in the Cloud Shell. This is actually a version of it. Let's see, here's a markdown file. Does it read it? No, Terraform, here's a Terraform. So it reads Terraform. This is kind of cool. If I go to Java, I believe it does Java now. Let's see, let's find a Java file. Source, main, Java. So my point here is that it actually handles a lot of different programming languages, straight out of the box. So if I want to run an application, so it's kind of cool. If you have access to a browser, if you use that dodgy hotel lobby browser or anywhere else, I saw these little game places here where people play games here. You could use the cloud here if you get a call. You're like, yes, I'm at work. I'll work on my Cloud Shell now and do what you need me to do. Also, there's an app. There's an app on your phone that actually has access to the Cloud Shell as well. So the Azure app on your phone. You can manage things, but you can also, if you have a script, you can use it. I actually used that as a vacation last summer, and for the first time in years, I didn't take my laptop with me. So I was far away from home, and I got a call that some of the Kubernetes implementations I have, I got an email saying that they're unsafe. There was a bug discovered and they're unsafe. So I was able to go into my Cloud Shell on my phone and disable them until I got back from vacation. So that was kind of cool. But anyway, so that's enough about Cloud Shell. I'm not going to show it. I'm not going to actually use that today, but I could. And one of the cool things I could do if I'm in Visual Studio Code is I could send commands to the Cloud Shell from here. I just opened that Cloud Shell window. But in this case, I'm just going to use the Windows subsystem for Linux. So let's do this.  So the next thing we do, every time you do something in Azure, you have to create a resource group, and that resource group is, we don't have to, but you have to use a resource group. You create it or reuse one you already have. In this case, I'm going to create a totally new one. So this is what it looks like when I'm actually running things in the Cloud. Easy group create. This one takes a couple of seconds, and then I'll explain what this is doing. So whenever it's done, it sends back a response in JSON that you can use in applications or something later. You can grab things out of here, and I'll show some examples of that later. But for now, it just says that I created a new resource group called 19122 Singapore, which I'm just going to use for this. Now, this is the one that takes a while, so I'm going to set this one off, and then I'm going to tell you what it's doing afterwards. So basically, inside that resource group, it's going to create this thing called a container registry. And the container registry, how many people are familiar with the Docker Hub here? A few of you? Okay, cool. So Docker Hub is like... Let me see here. Where's my... I have too many windows open. That's a problem. Let's see. Oh, let's just... I'll open another one. So Docker Hub, hub.docker.com. This is basically an FI search for Yeager. So these are the Yeager implementations. So Docker Hub is a way to actually store containers. And anytime you're running a container locally, generally instead of creating one, most people grab a container from Docker Hub. It's a base container. They use that to build other things into a container. Sometimes they just use it as is. In the case of Yeager, you can do that. You can actually use... There is a Yeager all-in-one. Let's see. I had it here. Anyway, there's a Yeager all-in-one that you can use. And basically, that's the one I'm using when I use the Docker Hub. Oh, here it is. Actually, I can get it from my code. And I'll check back in with the command prompt. Yeah, it's taking a while. So what this thing does... Oh, actually, no. So this actually created the registry quickly. So ACR create is the one that doesn't take very long. Hold on. ACR build, this is the one that takes a while. So let me file that one up. Okay. All right. So it's actually... I created the registry, which is similar to Docker Hub, but it's a private registry. So let me go back into my code here. If I look up here, the actual name is called... Oh, it's called Yeager Tracing all-in-one. Okay. So let's go back to here. And let's say Docker Hub. Oh, there it is. Yeager Tracing. Oh. Thank you. What? Ah! Thank you. Yeager Tracing all-in-one. So this is the Docker Hub.  So that image that I used to do Yeager before on my local machine, what I was doing is I used the Docker command to go and grab it. Docker run. These are all the ports that it uses. So I tell Docker to run with these ports. These are the ports that you want to access by standard... They're standards, basically the open tracing standard. And this Yeager implementation says anything that comes in via UDP on these ports, I want to track it and I want to trace it. I want to put it in my H2 database and actually store it there as well. So that's actually what's happening when I run this Docker run. But it's running on Docker Hub. So the Docker Hub is here and there's a bunch of different images for that. The Azure Container Registry is something similar, but it's a private registry. So you can actually create your own private registry using Docker code that's open source, or you can use our service to do that. Now to use our service, you just put this command, which is this one here, azacrcreate and that creates an Azure Container Registry and you name it and then there's different SKUs for that. We charge a service feed to actually have that and keep it updated and secure. So no one else can actually access your ACR builds. So the idea here is I've got Cosmos DB and a few other things with connection strings in my application. I don't want to expose those to the world. Even if they're secure and hidden away, if you run my application, you get access to my Cosmos DB and I might get a bill for that. So you don't actually want that to happen. You want to have your own private registry, most companies do, that have things they're going to do. Now the azacrbuild, that's actually what's running right now. acacrbuild says go get some code and run it in my container registry because I have a private registry. There's a command called docker build and that's the same thing that Docker Hub does. It actually builds things not on your local machine or anything else. It'll actually build it on a container that gets generated on the registry itself. So that's kind of cool. I didn't have to use that. It's not using any of my resources. It's using the Azure Container Registry. So it's actually running, it's gone out using a docker file and it's found the files. Here's the docker file itself. It's found the files it needs to actually build this application. So it runs Maven Clean Package. The POM tells it what files to actually pull in. And it's doing a two pass build because this is docker. The two pass build is kind of handy. The first build uses all the resources of the JDK8, I believe that's from Oracle. And then the second one uses Open JDK8 Alpine, which is a much more lightweight version of Java. So it actually does the build with docker, with a docker Oracle Java image. And then it does the deploy. Any deploy that happens of that code uses the Alpine image, which is much smaller. So it takes less resources. Because you don't need as much to actually run the application as you do to build the application. So did this actually finish? Looks like it might have finished. Let's see. Yep, okay. So it took two minutes to run. And I successfully talked about that stuff for two minutes. So that's good. I didn't have to spend any time showing you guys too much of that code. But basically it's almost the same code that you had when I showed it running locally with the J Boss and the Wildfly and everything like that. It just doesn't run. It just builds it. So now we've got an application that's sitting on our Azure container registry.  It could be to Kubernetes. It could be to OpenShift, Cloud Foundry, anything that basically takes a docker file. In this case, I'm going to use something called Azure Container Instances. And let me show you what that is. So... Oh, first before I do that, I got to get the password. So there's a... and actually the container registry itself. So I go and grab that. Yep. So it actually ran that behind the scenes. So you don't actually see it. It sets it in an environment variable. So the next thing we do, I could create a single instance. So to deploy this somewhere, I've got a docker file. It's sitting there. It's got Yeager and it's got OpenTracing. And they're both sitting there waiting to be... I'm sorry. It's got a microsweeper application and the Yeager OpenTracing application sitting there, ready to be deployed. To actually deploy this somewhere, you have to create a YAML file. And for those of you who are not familiar, if you do this with Kubernetes or pretty much anything else, you have to create a YAML file. There's no getting around it. There's these cool things you've got called Helm Charts. And they actually help you build YAML files and or leverage YAML files. Microsoft bought this company called DAIS a few years ago. And they're actually building these Helm Charts. And there's two products they have, Helm and Draft. And they actually have some cool stuff for deploying this. But let me just... I'll do this first. So what I'm going to do is I'm actually going to build a YAML file. I've got a base YAML file already. And what I'm going to do is I'm going to copy it. That's what this does down here. And then I'm going to do a bunch of editing of that YAML file with some of the things that we just created. And I do not want you to have to sit through me try to type this. So we put this together to actually do that. So then I can say, let's have a cat of that. And actually, I'll just look at it here. So deploy ACI. Yeah, I'm a file open file. Did I put this? It's in GitHub. Documents. Sorry. You got to look at my messy machine here. GitHub. And then it's going to be in microsweeper application. I have too many of these running. There it is. microsweeper demo local Yager. So it created a file here. Or it should have. All right, whatever. I'll show it to you here. It's going to be easier at this point. Sorry. So this is the actual file that got created. When I do a cat, it shows it. Basically, it's got a Yager service. It's got a Yager agent host. This is the Yager all-in-one agent that I showed you on the Docker Hub.  Now, what are the interesting things? So we have this thing called Azure Container Instance. This is sort of like a Kubernetes pod by itself. So the Azure Container Instance itself, it's a single container, basically. And it allows you to put more than one Docker application, more than one container in a container. So it's basically a Kubernetes pod, but it's not scalable. So it's just an easy and quick way to test out your Docker files and your deployment yamls and all that stuff. So I'm going to do that right now. So I created this thing. This actually could be used for Kubernetes with a few small changes. Things like you have to set up load balancers and front-ends and a few other things. But basically, this is the base that you need to actually make this run. So we've got that. And then we're going to do this. We're going to set up a Azure Container Create. And this is going to be the ACI container that we actually want to use. So that should run down here. There we go. So that's going to take a couple of minutes to run. So basically what this is going to do is it's going to say go into my ACR instance that I just created and deploy the Yeager instance and the Micro Sweeper instance that I gave you instructions with the YAML file to do. So we've got the Docker file we used to create the containers. And then we've got the YAML file that says that gives it instructions on what to do to deploy this out to our Azure Container instance. And when that's all done, we'll actually have something running that you can use on the cloud to run the same application we ran locally a couple of minutes ago. So one thing I want to show you while that's running. Oh, hey, it worked. Is it working? No, I'm not surprised it worked. I'm surprised that it worked so quickly. All right. So I was going to show you something else while that was running. But let's do this then. All right. So now we can actually test out what's happening here. So let me show you this. There we go. So this is actually going to give us a log. It shows us the actual. Let's just make this a little bigger. So it created one container. It created two containers. Both of them are running. Everything's good. So then let's go down here. Let's not delete that. And then we look at the log files. And let's just make sure that the log files are up and running. Yep. Looks like Thorntail is ready. All right. And this is checking the status of Yeager. Looks like Yeager is up and running. OK. All right. So the next thing we want to do is we want to actually access these. To access them, we have to get some IP addresses. So they're in one container right now, but you can access them individually through IP addresses. So the first thing we want to do is we use this command here. Container instance IP. We're setting up environment variable, which is basically going to go into the resource group. It's going to run some bash grip that grabs the container instance.fqdn, which is actually the one for, that is the one for the micro super applications. So let's go and run that. OK. That sets an environment variable. And if this isn't clear yet, it will be in a second. So then we can curl those applications and make sure everything's working. We didn't get an error. Good. So then what we want to do is we want to echo that IP address with the 8080 port. There it is. So that's the, I believe this is the micro sweeper application. Let's just see. There we go. So we got that. All right. The next thing we've got, I can go up here. All right. This is the actual Yeager implementation. So you can see the IP address up here. This is actually a container now. And it's 10445-189-237. It was just created and it did the pinning of that. Now, a couple of other things we can do here. Let's play a couple of games. Oh, that was quick. All right. Play a couple of games. And this is actually writing the Cosmos DB. So when it tracks this this time, it's doing something slightly different with Cosmos DB. Now let's go into our Yeager. Refresh this. Now, instead of Yeager query, we have two things now. We can do Yeager query, which is the base. But I've also set some environment variables in that container called microsweeper. So we can actually track the traces for microsweeper this time. And in this case, there's several traces. And once again, the performance is pretty good except for this guy. And the circle's a good size. So if it was bigger, that means the trace is too slow. The microservice itself is too slow. If it's higher up here, like this one, that means that the overall process is too slow as well. So this one probably needs some work. But normally, you'd see the microsweeper and the span here. In this case, it's just like that. So that's actually deployed this out to ACI. And this is actually running on one container, both things. So that's kind of cool. So what can you do with this? So now that we've got the container running and we've got the container working, we could deploy this to Kubernetes. We could deploy it to... We have an Azure Kubernetes service, or you could set up your own VM and install Kubernetes open source from scratch. You could use some third-party tools to do that. Cloud Foundry just announced their pivotal Cloud Foundry Kubernetes service runs on Azure now. So you could actually set that up and do it. But my demo I'm going to show you today is actually OpenShift. So OpenShift is a partner of Microsoft and OpenShift is a Kubernetes implementation that's built by Red Hat and has thorn tail functionality built into it. And that is easy to use with Yeager as well because OpenTracy is part of the MicroProfile standard. So let's go ahead and see what that looks like. Here's the OpenShift instance that I've already created. And let me show you how we actually did this. Yeah, so there's last September some guys from Red Hat and myself got together and we put together this implementation. And like I say, we have our own Azure Kubernetes service that you can use or you can create an OpenShift service on top of an Azure virtual machine. Azure runs virtual machines, windows, and Linux. We have all the flavors of Linux you can imagine. So if I go into, this is my Azure portal, by the way.  We have all kinds of, we have Red Hat Enterprise Linux. We have Ubuntu servers. We have something called Service Fabric Web App for containers, et cetera, et cetera. But I can actually create a Ubuntu server really easily running on top of Azure. We also have SUSE, we have all the major flavors of Linux. And basically I just answer some questions here and it'll actually create a virtual machine for me based on that. And the virtual machine is sitting on Azure and you can use it just like any other Linux box. You have to manage the operating system yourself. We have multiple versions of course of this. This is Ubuntu server 1804, but you can use all kinds of versions. Of course we have Windows Server too. And basically what we did when we worked with Red Hat is, let me see if I can make this bigger, yeah. So we created the virtual machine. First we built that app. We did exactly what I just showed you. We built the app and then we used container instance and Kubernetes to test it out, make sure everything works. And then we just set up an implementation of OpenShift to run this as well. Because if it runs on Kubernetes, it will run on OpenShift. It's very similar to... The OpenShift implementation is very similar to Kubernetes with some added things like they have a built-in Jenkins server and some other things for managing code and dependencies and CICD and some other things. Including micro-profile. So we built that. We used something called OpenShift Origin as the main image, which you can find on GitHub. That's the source. It's license-free. That's the demo. Let's see. I want to show you this one part of it. The source code is here. So you can see the source code. I've actually cloned the source code and added some things to it for myself. Whoops, what happened there? Yeah, so that's James, the guy who's working with the Red Hat. That's his version of it. So the next thing that's kind of interesting, if you want to deploy OpenShift, we have a button here, a deploy to Azure button that we created for this. And basically what this is, it uses an ARM template and something called OKD, which is OpenShift Kubernetes deployment. Those things working together, it just, when I clicked on that button, it goes into my portal again and it gives me a bunch of options here for my subscription. I mentioned the resource group. You have to create one all the time. We have location, we have multiple locations you can use for this. You put an admin username, password, SSH data, you have to have an SSH key to actually run this, and then a VM size. We have dozens if not hundreds of VM sizes these days to actually create this. And then when you say purchase, it's actually going to go ahead and build a VM, or in this case a cluster of VMs, and it's going to deploy OpenShift using OKD, the OpenShift out onto that. And so we did that, and that's actually what you're looking at over here. So this is our OpenShift deployment that we used that process for. I literally hit the button, it takes about 35 minutes, and it creates a bunch of VMs, and then it creates some Kubernetes clusters on top of those VMs, and then it puts the code out there, and when you're done, you get something like this, except you don't have Micro Sweeper built into it yet. All right, I don't know. Actually, they might have added that since I looked at it last, but when we did it, we had to implement the whole thing separately. But one thing I want to show you here as well, this is kind of an interesting thing on the front page of OpenShift origin. This is an Open Service Broker implementation, so in this case we wanted to connect Cosmos DB using the MongoDB API, and to do that we used Open Service Broker implementations. It's basically what you're looking at here. And that is something that Microsoft and Red Hat and some other companies have been working with, and it's an easy way of literally just clicking and going one, two, three, four to set up your Open Service Broker connection to Cosmos DB. I didn't have to write any code for that. It actually generated the code for it behind the scenes for me, and then I could actually use that code to access the Cosmos DB server. Now, Cosmos DB server itself is, I better mention that a little bit, so Cosmos DB itself is a globally distributed database. So what does that mean? It's actually multi-model as well. Let's see. So when you create a Cosmos DB instance, it actually creates it in three different regions all over the world by default. A region. And you don't actually have control over those regions. You can actually pay for regions that you want to put it on. But we have 54 regions in 140 countries. I still get people once in a while who ask me, aren't you guys just renting space from AWS like everyone else? No. No, we have these multi- billions, literally billions of dollars we've spent on this, multi-football field size centers. Huge things.  Now as you can see, the available regions are the blue circles, the announced regions are little dots here, and availability zones are things that you can use to connect things together. So basically, where is let's do a little test. Can Brian find Singapore on this map? Australia, we have Southeast Asia. I think it's in Malaysia right now. I don't know. But yeah, we also have several other locations. As you can see, 54 regions. And a region is actually three data centers. And each one of those data centers has redundant capability to cross them. We also have these things called paired regions. Which, like North Europe can be paired with France, Central or West Europe. And those are going to be fast updates between the different regions for disaster recovery, for redundancy, all kinds of things like that. But anyway, so we created a Cosmos DB instance and it automatically created three locations of it. And like I say, you can pay for more of those if you want. And then I want to talk about the multi model. So multi model means that we have app models for several different things. We have web apps. And basically the bottom line is you can use this to access Cassandra, MongoDB. If you have, if you're using MongoDB, Cassandra, SQL, Gremlin and a few other platforms out there, we have, you just change the connection string in your application and you can use this database on the backend automatically. So that's what we've done. And we've implemented this all over the world. It was started by, for those of you who might know what the OneNote is. It's a Microsoft product that used to take notes and things as part of Office. This database was started as the backend for OneNote many years ago. And they said, wow, this is a really solid document store. It handles structured, non-structured, semi-structured data. Why don't we use it for other things? And so the first thing they did is connect it with MongoDB. So you can use it for JSON documents that MongoDB handles. And then we added Gremlin, Cassandra, NCCquel, a few other things as well. So it's kind of like a cool multi-model, multi-location database that you can use. Anyway, so back to the application that I wanted to tell you about. This is actually how it works and how it runs. So I've got these, I created, we created a Cosmos DB implementation of that. And we go into our MicroSweeper implementation. And MicroSweeper itself, here's the links, and then we've got Jenkins, which basically handles our CITD for this. And if I go into the application deployments, we have set some environment variables for this as well. So if I go in here, MicroSweeper, this is where you can actually, whoops, environment, there we go. This is where you can actually see the environment variables. So I mentioned that the way back when, you might have remembered, you can set all these up in pomm.xml application, you can set them up in code, or you can set them up using environment variables. And the environment variable, in this case, we called, we created a Jager service name, log spans, so you actually want to log spans and sample parameters, the name of the Jager agent host and the port you want to use by default. And then we've got a configuration that we set up with the object service broker to Cosmos DB, and we called the database Scores DB. Now the cool thing about this is we didn't have to set this up, it was all set up automatically inside OpenShift just by clicking those four steps to create a Cosmos DB database for that. And then we just tell it what database we want for the actual application. So easy to set up, and the nice thing about this is this is set up in the environment. So we could deploy this, this is actually the deployment, not the application itself. So I could set this up as multiple deployments and I could change the Jager service name or something else on each deployment. And each deployment gets managed separately using here's the sixth, the latest and basically it deploys things to a pod and you can track and see the different stages along the line for that pod and the events that happen each time you deploy things. So there's no events, that's good. But it's kind of cool because it allows you to do that, it uses Jenkins to actually do the deployment itself and you can manage your Jenkins set up as well. So anyway enough about OpenShift basically all I have to do now is I go back into my overview here and I can click here and once again I got my, oops I go here because we didn't use a public SSH key there we go. So this is our Jager so I can see the Jager there Micro Sweeper, here's the application it's not failed there you go, good. So I can see here and it's actually writing this the Cosmos DB now instead of the H2 database that it was doing locally and if I change this and you can see that I'll do one more. That was an easy one. So if I go back into my Jager search here search for Micro Sweeper find traces so there's a bunch of traces. Let's have a look at this one doesn't seem to be very good but the idea here is I could set all this up I didn't have to do anything extra I set up a VM then I set up OpenShift and then I deployed that dockerized, yamalized file for deploying out to any Kubernetes platform and in this case set up Cosmos DB by using those click interface and basically I was done. One last thing I want to show you if you want to use this on Kubernetes I mentioned Helm charts before so this is a very similar to the docker hub but in this case it's for Kubernetes. So anything you can imagine that you want to use for Kubernetes let's see so Jager again I did it again so there's a Jager operator and this Jager operator uses Helm I mentioned Helm before so we have draft which allows you to create these YAML files and then we have Helm that allows you to run the YAML files really easily and this to deploy this out to Kubernetes this is an actual Jager operator instead of deploying it to docker this would deploy it in a multi-stage multi-pod scalable Kubernetes environment and you can actually see the chart if you look in here where's that chart I can't remember now Jager operator there it is so the chart itself is here too anyway you can find the chart there and it's a Helm chart that allows you to run some strips it's a YAML file, a really complicated YAML file that allows you to deploy this out to any Kubernetes cluster on any cloud platform so that's basically the whole idea here so we started with an application running on my local machine using micro profile and then we added up a tracing we packaged all that up in docker we deployed that out to a Azure container instance which could actually run in Kubernetes as well and then we took that and we put it into OpenShift and we ran the same thing on an OpenShift Origin installation and all the stuff is open source it's all in GitHub and that blog I showed you by James my colleague at Red Hat and the GitHub repo that I showed you the actual microsweeper code is pretty much all you need to do to try this out on your own and there will be a recording of this as well so you can actually watch and follow along with what I did and do that yourself as well and the script that I was using to cut and paste things into the container instances is actually on the GitHub repo too so that's it and we'll take some questions any questions at all alright thanks for coming guys I'll be around if you have any questions after coming that was great