For a word of greeting and an introduction of the President, the Vice President, George Bush. The nicest non-campaign meetings I've ever seen. But, and so I, one, want to thank you all for all you have done. And I also now have the great pleasure of introducing the President of the United States. Thank you very much, thank you, thank you very much. Thank you. And for all of us up here, thank you very much for a very warm welcome, and always makes you suspect there's a Republican or two in the crowd. But I'm pleased to be here and to see so many old friends. And a special greeting and no, someone is here, my press secretary, Jim Brady, and his lovely wife, Sarah. There, I want to thank all of you for giving so much of your time and labor to make this administration possible. In the end, it's not glitter and gloss, but the grit and determination from an army of supporters that makes victory possible and will make it so again in 84. Back in 1980, our administration inherited a mess, an economy with raging inflation and soaring interest rates, a dangerously weakened national defense, a foreign policy that had allowed an American influence, a force for freedom and peace in the world to shrink what the Democrats had done to our country. It reminds me of a story. Little girl said to her mother, she said, you know that beautiful jug you told me had been handed down to us in our family from generation to generation. And her mother said, yes, what about it? She said, well, this generation just dropped it. With your help, our administration was elected to put the pieces back together again. We cut the growth of federal spending. We pruned needless regulations and George Bush was in charge of the team that was doing that. And it has saved hundreds of millions of man hours of work in filling out needless government papers. We reduced personal income tax rates and we passed an historic reform called tax indexing. Now today, just two years after we set our policies in place, our nation has a one big program to help every American man, woman and child. It's called economic recovery. And you can tell it's working because, as I've said several times already, they don't call it Reaganomics anymore. You know, I've said something else before, but it needs saying again. We didn't come to Washington to raise the people's taxes. We came here to restore opportunity and to get this economy moving again.  We face those deficits because the Congress still spends too much. And I am still opposed to those who suggest that now we should raise taxes on individuals and businesses. And I am prepared to veto tax increases if they send them to my desk no matter how they arrive. Let them keep their hands off the recovery and start doing what they were elected to do, which is to get spending under control once and for all. Just as we're turning the economy around, we've strengthened our national defense and have given a new sense of purpose to American foreign policy. In the military, the number of combat-ready units has increased a third since 1980 and morale has shot up high. We're attracting better recruits and we're keeping them longer. And because we're finally giving them better pay, better equipment, and the respect they deserve. In foreign policy, we've let the world know once again that America stands for the political, religious, and economic freedom of mankind. And something else, under this administration, our nation is through wringing its hands and apologizing. Americans don't put up walls to keep people in. We don't have armies of secret police to keep them quiet. And we don't put political and religious dissidents in jail. And we would never cold-bloodily shoot a defenseless airliner out of the sky. In two places last week, Beirut and Grenada, Americans lost their lives and were wounded while protecting lives, defending freedom, and fostering peace. In Beirut, we won't be intimidated by terrorists. We will redouble our efforts to help the people of Lebanon find peace. In Grenada, the thugs who seized power in a bloody coup have already been replaced by administrators of goodwill who will prepare the country for democratic elections. We've had broad and bipartisan support for our actions in Grenada. Yes, there were some critics. Well, I'd like to suggest that those critics take a moment to listen to interviews with Grenadians rejoicing at their new freedom, or to meditate on the photo of an American medical student rescued by U.S. Rangers kissing the good earth of South Carolina after he got off the plane at Charleston Air Force Base. You know, as of last night, those in charge of that marvelous operation, which they put together in 48 hours and kept it a secret until they could land there. They last night declared hostilities at an end. And today, the engineers of the 82nd Airborne are repairing roads and bridges and damaged buildings and homes down there. And the medical corps now that are wounded, have been evacuated, are taking care of the people on Grenada, vaccinating children, doing those things that are associated with public health chores. In other words, we're doing what America has always done. And I don't know that we've ever had any better missionaries for our country abroad than GIs in uniform, over the lives of those splendid young men that were lost in Beirut and Grenada. But I just have to believe we can honor their memory best by not withdrawing from our role in the world, but by remaining the force for freedom and peace that makes America the brightest star of hope in the world today. In 1980, our nation faced a crucial choice. We could continue to decline, or we could work instead to make a new beginning. The American people chose the path of courage, and our administration was elected to make that new beginning. Everyone here, whether you stuffed envelopes or planned campaign strategy, helped to change the course of American history. In 1984, we'll have another great political battle to wage.  For the good of our country, let's wage this battle with all the determination and dedication that we have in us. I believe all of us share a dream. It's a dream of an America that offers opportunity to all her citizens. It's a dream of America as a mighty force for good will among the nations. And with faith in our God and confidence in our cause, we're making that great dream come true. So from all of us, thank you. God bless you.


Aloe's new DAC is remarkable in several ways. It is a stack of three printed circuit boards and the price in Europe is about €260. The US price is $249. As far as I know, a new price record. That's no problem, provided it sounds accordingly. Aloe products have impressed me before. Yes, they cost more than other popular products but they perform better too. The Katana is even more costly than the previous Aloe DACs. At $329 you get a Katana set of boards, a Raspberry Pi 3B, a microSD card, a switching mode power supply in a clear or black acrylic case. But you can also buy the three Katana boards as a set if you already have a Raspberry Pi and want to arrange the housing and power supply yourself. As said, the Katana DAC is spread over three boards. The one mounted on the Raspberry Pi is the board that houses the ESS Sabre 9038 Q2M DAC chip, well shielded just as the very good NDK NZ2520 SDA crystal oscillator. It also holds a print connector for an external 5 volt power supply. It is at a very inconvenient place and the solution Aloe came up with is a matching connector with wires sticking through a hole in the optional acrylic housing. The jumper on the left might have to be removed then, depending on the power option you choose. The connector here is to connect to the up and board and is part of the GPIO bus. The connector further down feeds the analog outputs of the DAC chip to the up and board above. There also is a power LED. On the flip side we find the full GPIO connector for connecting with the Raspberry Pi and two super capacitors. The analog part of the DAC Aloe partnered with Sparx Labs that is specialized in discrete op-amps, which is short for operational amplifiers. Usually integrated circuits are used in this class of products. Building discrete amplifiers, meaning build using discrete transistors instead of transistors integrated in a chip, has always been a better way to go but had relatively high building costs. Using contemporary surface mount technology, building time is clearly reduced. The designer has chosen to set the DC offset manually, more precise but labor intensive way to go. Aloe warns against changing the setting of these trim pots. The up and board outputs both single ended audio on RCA and balanced audio to soldering islands to which wires to XLR connectors can be soldered. The standard housing does not have the space to mount XLRs. The next board, the microcontroller board, is connected to this bus and the microcontroller feeds the op-amp board plus and minus 15 volts DC for proper headroom and slew rate. When we look at the bottom side we see the GPIO bus and the connector that receives the analog audio from the Katana DAC board. Most modern DACs have a microcontroller. It is where for instance the digital filters are executed. Most DAC chips offer their own in-chip filtering but external processors are more powerful, enabling better sounding filters. The microcontroller board also contains the electronics that transforms the single 5 volt DC into plus and minus 15 volts DC, used to power the op-amp board. The 5 volt DC input is a USB-C connector. If you have an audio grade plus and minus 15 volts DC power supply, you can change these jumper settings and connect that power supply here. The DIP switches let you choose a fixed setting to 1 of 7 reconstruction filters or enable filter change by the player software. If we flip the board we see the GPIO bus and the connector that feeds the plus and minus 15 volts DC to the op-amp board. Some people thought that soldering a printer header to a DAC board and so powering the DAC board directly was over the top. Well, these people better brace themselves for there are six ways to power the Katana using one to three power supplies. You can use a single power supply and connect it to either the microprocessor board or the Katana. When you want to use two power supplies you can either power the Katana and Raspberry Pi or the microprocessor and the Raspberry Pi. But wait, there is more. Use three power supplies and connect them to the Katana, the microprocessor and the Raspberry Pi. And then you can choose to power the op-amp using the plus and minus 15 volt power supply. Funny enough, each power connection has its own connector. The Raspberry Pi uses the micro-USB connector, the Katana uses the print connector with attached to it the two non-terminated wires and the microprocessor board uses USB-C and a print connector for the plus and minus 15 volt power supply. Allo advises a nice way of installing all kinds of software, DietPi. This is an image that you write to the microSD card using a program like Etcher. You then stick the microSD card in the Raspberry Pi, connect a monitor keyboard and network to the Pi and start it up. Setting up will take considerable time but then you are prompted to log in and you simply type the indicated username, enter the indicated password and enter again. Once more some alphabet soup raises the screen until it turns blue with a classic looking menu in the middle. The possibilities here are titanic so if you want to explore, please feel free. I will only show you how to install a music player of the Likings. Use the arrow down key on the keyboard to go to the player you want and press the spacebar to select and when you have chosen the player or players you want, hit the tap key and go to OK and enter. This will bring you back to the software menu. Scroll down to install and confirm the installation. After again flashy instructions flying over the screen you will return to the menu again. If you don't need to use DietPi you could also install Volumio Direct since it already has the drivers for the Katana. The same goes for Max2Play, PiCorePlayer, Mood and others as soon as drivers for those are finalised, which should be by the end of July 2018. I have used the Katana with Volumio and as a rune endpoint both installed using DietPi. I have reviewed Volumio 2 not so long ago so for details see that review. I will put a link in the comments. What you don't find in that review is that you can select the reconstruction filter by going to playback options in the setup menu. There is also a DSD Direct mode, all rather nice for a free software player on an affordable Katana kit. As is the enormous amount of languages that are supported and available plugins that can be installed by simply clicking the install button. Volumio works like a charm on the Katana. Using the Katana as a rune endpoint is rather uneventful. Use DietPi to install the rune endpoint software and you're done. The implementation is proper and the volume control from within rune works perfectly. An alternative might be RopeA, my favourite rune endpoint software for the Raspberry Pi for it also supports the Raspberry Pi LCD touchscreen. The Katana is not yet in the list of supported hardware but since all other LO products are supported I get that this is only a matter of time. Again, LO sets the standard for Raspberry Pi or to be safe, it's the best I know. Now let me put this in perspective. The Katana, when used with one SBooster SOtM power supply connected to the microcontroller board, fits my setup too and scales in between the LO bus and the cord mojo. Using three power supplies not only is a hassle, you need to connect the power supplies in a given order to have the Katana startup properly. It's also expensive. I don't stock a shipload of 5V SBooster BOTWs so I use the initial smaller model SBooster connected to the microprocessor, the SBooster BOTW, the big one, first generation, to the Katana and the i5 power 5V to the Raspberry Pi. I actually found the sound a tad less. Using two SBoosters and having the Raspberry Pi powered from the microprocessor sounded perhaps slightly more relaxed but I wasn't even sure. What you shouldn't do is use one or more standard 10 euro switching mode power supplies for that will immediately lead to a degraded sound, like harshness or voices and lesser resolution. Just use one audiophile power supply, see my review on those. I will put a link in the comments. Then you have a streamer that costs the same as ready to use streamers by consumer electronics brands but you end up with a better sound, more detailed and spacious. Let me start with a serious warning. Raspberry Pi is often used Linux as operating system, as in this case. And to keep the processor load as low as possible a graphical user interface is left out. This means that if all goes right you have a very fine player at an attractive price. But if something goes wrong you read your own. Of course you might try to find a solution in user groups but if you are not tech savvy you might not speak their language. Plus not all user groups are audio focused, computer cracks might be satisfied when they just hear the music. Don't get me wrong and if you are reactive in a good user group don't feel offended. But I see the casualties, people that never should have started with the Raspberry Pi and want me to give them personal support. I count people, too many requests, too little time. But if you are able to master the secrets of the Raspberry Pi, or just want to try your luck, you get an enormous versatile device that works for many free players, can work as DLNA or UP and PAV renderer, can emulate a squeezebox or be a rune endpoint. The only thing it doesn't support is MQA. By the way, the rune endpoint software is free, the server isn't. Depending on where you live, you can have a complete Cantana player for around 400 euros or less, slightly over 700 euros with a good power supply. And I know of no other system that offers all that for this money. I keep looking for new products and developments. So if you want to follow my quest, subscribe to this channel or follow me on Twitter, Facebook or Google+. If you like this video, please consider supporting the channel through Patreon or PayPal. Any financial support is much appreciated. The links are in the comments. Help me to help even more people enjoy music at home by telling your friends on the web about this channel. I am Hans Beekhuyzen, thank you for watching and see you in the next show or on theHBproject.com. And whatever you do, enjoy the music.


My name is Baladat. I am a principal engineer at Intuit. And I'm going to talk about JavaScript plug-in architecture for single-page applications. Before I start, how many of you have a situation where you have to integrate your application with a third-party application in browser? OK. So good number of you. It's good. You guys can share your experiences also. I would love to hear that. And feel free to ask me questions anytime in between. So I work on an application called as QuickBooks Online. It is for small business management. So if you have a small business, you have to generate invoices to your clients. You go and buy something from your vendors. You generate purchase orders. At the end, you want to see your profit and loss account, balance sheets. And you also want to file taxes to the government. All that is handled by this application. It has 175 K log JavaScript code. It's pretty big. And it's increasing. So as we add more and more functionality, it's getting bigger and bigger. It's a single-page application. It has very active uses. So it's not like a website where people come once in a day and go back. It's an application that businesses use throughout the day. And they are almost always into that application. It can be accessed from multiple devices. It has 1 million users, as of now. It is accessed across the world. So it's global. We have launched it formally in five countries, but it is accessed by many more countries. And it's a little different from other applications where going global basically means you change strings and you take care of localization. Here, it means that you take care of the laws of the land, the country that you go in. They demand very different treatment of accounting and very different treatment of taxes. So we do all that. So just to tell you that this is a very complex piece of functionality. We deal with compliance. So anything wrong we do, government or the tax departments would run after businesses. So for all this, we can't build a whole of the application ourselves. We have to rely on third parties who build part of it and we integrate with them. We could build a good amount of functionality for US, but if we have to go global into different countries, we can't build everything of it. So that's where we need some capability for third party applications to integrate into our application. And even internally, we have multiple teams. We have multiple divisions that build different parts of the application. There is a team which takes care of accounting. There is a team which takes care of payroll and payments, et cetera. All those things have to come together and we need modularity there. So this is the motivation. This is the problem, the solution to which I'm going to explain now. So it's all about creating an ecosystem. You know, you can't build everything.  What are some of the approaches at a very high level? There is, you can have a service-based integration where one part of your app has a separate endpoint. People go to that place. And only through services, the data is exchanged between the two applications. The other approach is you have browser-based integration where people go to only one app. People only get to see. Your customers only get to see one app. And everything is inside that. So this is the second approach. And this is what we are going to talk today about. In that, you know, there are two approaches. One is an iframe-based approach where you get the content of other application and integrate into your application using iframes. And another is a very lightweight way where you can get JavaScript modules directly into the application and let them behave as part of the application. So what do we do? We talked about plug-in. What is a plug-in? A software component that adds a specific feature to an existing application. It's a very simple and generic definition. And you know, we have a lot of examples in industry about plug-ins. People build a core application that does one thing well, and then they let plug-ins to come in and enhance it and make it really rich. The same approach we have done. Why would you do that? It's basically about enabling developers outside the core product to add features. It's about making it easy for those features to be added. It's about keeping the core very small. And it's about enabling independent releases. So let me tell you what I mean by independent releases. If you have 10 teams building a good piece of functionality in your application, and all of that has to come together as one application, as one release cycle, you are bound to get very slow. It is a good idea for all these 10 teams to build and release separately, and all of that to come together to the user as one application. So release independence is a very important criteria for you to be agile, even when you are building such a large-scale big application. So question for you. Which one of these do you think has a plug-in? All of them. Which one of these do you think has a third-party plug-in? OK. Cool. We'll come back to this. But just keep in mind this picture as we talk. So I tried to look for some examples of what integration are there. And there is this site, which has very bad integration, I would say. It gets worse. Ads is OK. But when you search for hotels, you are suddenly taken to a very different site. And both of these are from railway. So I think there are some lessons to learn before you even start thinking about integration. Let me tell you a little bit about this. So first thing, if you are integrating into a third-party application, you have to take care of identity. So identity has to be shared. That means that I should not be asked to log in again into that third-party application. Design an interaction. You have to make sure that the plug-in and the main application, they look and feel the same. They have same colors, fonts, et cetera. So what do we do at Intuit? We have actually given our style guide and a style language and some set of tools for third-party plug-in developers to build plug-ins and integrate into the application. Second piece is consistency. There are some certain paradigms that we have built. I'll talk about them like trousers, global creates, knabs, and all that, which your third-party plug-in should also honor for a user to have a seamless experience. Plug-in should be first-class citizens. So a lot of you said that everything is a plug-in. We try to make internally every feature as a plug-in. And that's what gives plug-in a first-class citizenship. So it's not that you create a certain piece of API and give it to your third-party developers, and that API is fairly restrictive and only meant for third-party.  You have to take care of roots. So people would bookmark different states of the application at different places. Your third-party plug-in might be actually saving data. It might be having different states. It might be storing preferences of the user. All that you have to take care of while you are building so that you give a seamless experience. If somebody goes to a plug-in and navigates out, you better save half-filled form data somewhere and retrieve it back when needed. So this is a basic iframe plug-in. Most of it, there is nothing but hello world, and that's the content area in which it shows up.  This index.html will be loaded and placed at the point. Now let me tell you a little bit about access points and app routes. So on the left side, we have what we call a left nav. And on the top, when you saw that fly out coming, it's called global create. And on the right side, there is a settings fly out. All these are part of shell, what we call a shell. Shell is something that always exists, and it's where plug-ins come in, hook themselves, and are accessible from shell. All these places have something called as access points. So we have got, let's say, in the settings, we have QuickBooks lab written there. We have an access point there. We would have an access point on the left nav, and we would have access point right in the content frame itself. And you have app routes also. So actually, you can do two things. You can go and say that, hey, my plug-in, I need to be shown from this access point, or I want to even capture the route. And both of these clubs together are called as attach points. So as a plug-in, you basically write attach points and you get hooked into the application. So let me show you a quick demo of a simple, very simple plug-in. This is QuickBooks application, and OK. So this is where I am running my node server. This is a small plug-in that I am running from where it's on my local host, and the plug-in will be delivered from here. So what does plug-in do? It shows up inside the setting. This is cool plug-in. It also shows up here. And it actually takes on the route that is represented by this menu item. So let me show you this. This whole thing was taken over by the plug-in. And what does this plug-in do? It basically demonstrates few things. So let me click on this show page message. Once you do that, this small toast that comes, it is actually coming from the main application. Every plug-in will not have their own toast coming. And you know, very different kind of experience. So it basically has to request the main application to get to show the toast. Even the dialog box is shown by main app. You can actually request main app to show a video. OK, maybe the network is slow. So a video can be shown inside the application. Now let me show you that this is really working. So what I will do is I told you about the link that appeared there. I'll change the name, call it jsfoolplugin. And I will reload this application. OK, so you see the text there that has changed. This was a small demo. I'll take you through the details of it. I'll refer to the code here as I discuss more. So what just happened? First thing is the plug-in has to be loaded. Remember that the plug-in is per user. And it is per even locale. So some plug-ins are only available in India and not available for US customers and all that. So there is a list of plug-ins that are applicable to the current user. First thing plug-in loader does, it goes and fetches the configuration from the server. It merges that configuration from a local storage server. So this second piece is for developers. As a developer, I just enabled a plug-in. This plug-in is not available to all customers. It's just for my testing, my usage. All that information is stored right in my local storage in my browser. And the app basically makes use of it and shows that plug-in also, as if it was available to everybody. And the main app router, whenever that particular route that you're acquired, that route is triggered. It basically passes the control to iframe controller, which executes your application. Now I talked about attach points.  And access point is one of those attach points. Route is another attach point. And we actually changed the text of this just now. This is how you override the app route. So you say that, hey, customers or employees, et cetera, all these routes are override and you get control. Your application gets control whenever these routes are triggered. Now there is an important piece to this, which is how does the parent application communicate with the child application, which is basically a plug-in, when the plug-in is running inside iframe. We know that same origin policy and iframe controls prohibit easy communication between these two applications. For that, we use a library called as EZXTM. It makes cross-domain communication easy. What does it do? It basically allows you to create certain channels between two frames and use JSRPC to communicate between them. So you can basically, the child application can call well-published interface of QBO core application and get things done. So for example, when we called, when we said show message, show page message, we actually called into core application and said, show this message. So all this is possible using EZXTM. And it's completely JavaScript library. It depends, depending on the browser, it uses the right protocol. Most of the time it is post-message. Now, what happens? Let's, so the first thing, if you look at this application, it basically has just index.html. And it starts executing here. This basically says that whenever the plug-in starts, the core application would actually fire a post-message with some set of data, initial data, that this plug-in has to hold on to. And from there on, the communication channel is established. What does it do? It basically takes this piece of data that has come as a, into this message and hooks it into its own DOM. Now, from there on, there is a object called as QBO-XDM that is available to the client application. And QBO-XDM is a EZXTM-rapped object containing QBO interfaces. And plug-in can use this object whenever it wants. So, this is about getting the initial QBO-XDM object. If you want to basically hook on to the ready message, so whenever your plug-in is loaded, you want to have a ready message and you want to hook on to that time, you use this QBO-XDM ready object and this will get called at the right moment. So, this is how you basically call the parent for showing a page message. This is how you call parent for showing simple local dialogue and you can actually ask you to show a video too. It is many times, it is not just the menu item, but you would like your plug-in to show up inside a particular form also. And that's where, you know, this comes in. So, what do you do after you've created a plug-in? We have a feature inside our application called as QuickBooks Customer Labs. It's a place where all the applications are published and customers also get to see that and they basically can choose applications from here. They can switch it on and use them. So, this is where your plug-in will show up. This is one plug-in that my team worked on and this is part, so this is just to show you that, you know, many times some of the core features are plug-ins that we expose as in QuickBooks Lab and let customers opt-in. It's a good way to do beta testing. Okay, so, what I'm, before I wrap, let me quickly take you through the code once again. So, what have we done? We basically defined a configuration that the plug-in manager inside QBO understands and most important part is this source path. Where we specify the HTML file that will be loaded by the plug-in manager, whenever all these things are triggered. So, whenever this route is triggered, that index.html will be loaded. When the links inside settings is triggered, that same thing would happen. When you basically, let's say, want to show, so let me tell you a little bit about browser, what it is. When you show up forms here, part of, good part of area is taken by this left nav and, you know, all these elements outside. Sometimes, we want the whole screen to be available to the form, like this. So, this is what we call as trouser. It basically comes down and it takes the whole screen. Now, what if the plug-in wants to access this? Plug-in has a way to do that. You know, it can also show up inside a trouser. It basically requests the parent window to show up a trouser and render the plug-in inside it. So, this is how you show inside the trouser and, you know, you can also show inside form. So, we actually saw the sales tax thing. So, when we clicked on invoice, we saw this. This is basically the plug-in showing up. So, this is how you define your plug-in and this is how you write the code. You get, you can make controls. You can make calls to QBO to do a lot of stuff. You can make data calls to get data and you can integrate into different parts of the application. So, to conclude, you know, this is a way to build plug-in mechanism for your apps. And it's to encourage you to build such mechanisms into your app because you will realize at some point that you would like third-party applications to also plug-in into your application. It allows others to build stuff into your app. Make sure that you eat your own dog food because only that can ensure that you have a rich and meaningful API available. Always try to allow a developer into your ecosystem without having to talk to you. There is one principle that we try to adhere to and into it. What's the future? What are we doing after this? This was basically V1. We have been working on V2 of this plug-in. So, we are thinking of, you know, AMD loading of plug-ins so that plug-ins can live right inside the parent application and to make sure that these plug-ins are isolated from each other. So, you know, we have a notion of sandbox where it is in a container for plug-ins and it provides, plug-ins use that sandbox to access different services. You know, for example, passing event, there is an event bus, they can pass event back and forth. They can access models, data, et cetera. And they have fair isolation, so they don't have to depend on presence or absence of any other plug-in. If you need more details on the future, feel free to come to our booth and talk to the engineers there and we can explain you in detail. These are some of the links. QuickBooks, you can actually get a free QuickBooks trial if you go to google.com and say QuickBooks online test drive. developer.intuit.com is our third party developer portal where you can get a lot of information and a lot of tools. The code that I showed you is here. It's called starter plug-in. This is all about what I wanted to talk. Thank you. If you have any questions, I'd be happy to take. Hi, so one of the major issues when you open your application to third party developers is security. So how do you guys handle that? So, good question. First thing is, you know, you have to, you cannot open it to anybody. You have to have a process to verify and vet out an application. So somebody has to submit and there has to be a review process. People can't build in wrong stuff, viruses, or, you know, bad code into it, crash your application, or steal data, et cetera. So you have to have a review process. That's first thing. Second thing is, you have to, you get to limit the amount of things that people can do. Clients are generally always assumed to be in untrusted zone. So your services basically take care of dealing with any calls that are coming your way. So you have to treat this third party plugin also with the same untrust, distrust, that you treat any call coming from internet. So that's basically making sure that nothing bad happens to your customers. On the other side is that you have to make it easy for your customers to use it. So I talked about shared identity where you have to allow easy ID federation. Other third party applications do not have to use your ID systems. They can have their own ID systems. They maintain their own identity, but there is some kind of federation and some kind of close control around that ID federation. Now, it's also true that, you know, when you have, you ultimately want to give good features and good experience to your end user. So sometimes you cannot be too paranoid about data. I mean, for example, you know, you might say that somebody can take data and steal it away, but it's a trade off between how much forceful, how much flexible and powerful you want those third party applications to be to deliver a rich and good experience. So it's a trade off and, you know, it's, there has to be some manual process also. So any more questions? Question? No. So we'll be breaking for tea, I guess. So see you guys in half an hour. All right, thank you.


Hey everyone, Drew with GeoArm and I am back to talk to you about the Honeywell Home Pro Series, Pro A7 and Pro A7 Plus Panels. Now what we're going to do in this video is we are going to be changing the master code and adding a user code. So this is super easy to do. What you're going to do is go ahead and click on the menu button at the very bottom. Now this one is a little bit different because you're not actually going to be getting into tools to do the change on this one. It's going to actually be in settings and then user management. Once you get in there you're going to enter whatever the master code is currently. In my case it is the factory code of one, two, three, four. At this point it'll take me into user programming.  That's the most common code there is whoever you know breaks in. That'll be the first thing that they try. So we're going to go ahead and update this master code. So if you go ahead and press on master you'll see a new set of menus appear here. There's a little pencil over next to where it says pen. You can press that and then that's where you're going to change and update this pen. So it was one, two, three, four before so I'm just going to change it real quick. We'll just go five, six, seven, eight. All right and it's going to ask you to confirm that so I do it again five, six, seven, eight. Now I have changed the pen. It's going to want you to save it to confirm it but we'll just go ahead and take a look at the other options that are in here. It wants to know if this code has the ability to disarm using the Bluetooth disarm function and I believe that this is only going to be on you pro a7 plus people that are watching this video but Bluetooth disarming we want that enabled and z-wave lock control if you have a lock or something like that that you want to set up you can definitely do that. I don't have one so I'm not going to enable it in this case but you can do that. So I'm going to go ahead and click save. Now it wants to know the master pin. You must enter the current master pin when saving the new one so the current master pin was one, two, three, four and that'll lock it in. So now we have changed our master code and if you go ahead and go in there you should be able to change it again if need be but the code has been changed so what we're going to do to verify that is when we get out of this programming menu we'll test them. What I want to do also here is I'm going to go ahead and show you guys how to add a new user so you're just going to press the plus sign up in the top right name your user so I'm just going to call it user two in this case okay save it. Now we'll go with the pin for the pin here I'll just put four three two one okay it's going to have to be verified four three two one all right partition one access it wants to it you have to to enable them to be able to control this system so if you have a partition system you have to enable them in each partition so that they can control each different one that is if you are using a partitionable type in this case I am not it's going to be only one partition so I'll go ahead and I will set this code as a a regular user so it's a user now I can go ahead and click add and it wants to know the the pin to add the user your actual master pin so minus five six seven eight and at that point it will lock it in so now I have added a user and I've also updated my master code so we'll go back to the main screen and we'll verify that this works so we will try the master code first so we'll go arm away five six seven eight okay there's our arm now we'll go ahead and we'll disarm it using the five six seven eight code disarm it is disarmed all right so now we'll try our secondary code go ahead and hit arm we'll arm it stay in this case and then we'll enter four three two one and there's our arming we'll go ahead and disarm it to verify that it works disarm and there it is ladies and gentlemen that is how you update your master code and add an additional user if need be ladies and gentlemen if you have any questions or you need any assistance with anything please leave a comment below take care and have a great day make sure to subscribe to our youtube page and click the show more tab underneath the video where you can view valuable links pertaining to this product similar how-to videos and our low-cost no-contract alarm monitoring services


Good afternoon, good evening, good morning, wherever you are. Welcome. I am Chris Short. I'm a Principal Technical Marketing Manager at Red Hat. I'm also a Cloud Native Ambassador. I'll be moderating today's webinar. A few housekeeping items before we get started. During the webinar, you're not able to talk as attendees. Sorry, but that's just how it works. There is a Q&A box though. So at the bottom of your screen, you click that Q&A box. Feel free to drop in as many questions as you feel necessary to get what you need out of this webinar. Also, friendly reminder, this is an official CNCF webinar and as such is subject to the CNCF Code of Conduct. Please do not add anything or chat about anything or put anything in your questions that would be in violation of the Code of Conduct. Basically, be respectful of all of your fellow participants and presenters. So I'd like to thank you for joining us today. Welcome to today's CNCF webinar, Distributed Transaction Processing Across Multiple Clouds with Kubernetes. I'd like to introduce Joe Leslie, Senior Product Manager at NUODB and Aaron Corelli, Principal Professional Services Solution Architect at NUODB, who will be driving today's webinar. Please take it away. Excellent. Thank you, Chris. In today's presentation, Aaron is going to control the slides for us. So we have an easier transition through the middle as we are going to tag team and both present. So thank you, Aaron. So yeah, just a few words about myself and then Aaron will get to introduce himself as well. So at NUODB, I am one of our product managers here. NUODB as a database product, as you can imagine, is made up of many components. I look after several of them, particularly our cloud native strategies, as well as our product and solution deliverables in that space and roadmap. I also, as NUODB is a distributed SQL database, I managed the, from a product standpoint, the control plane, as well as our NUODB insights visual monitoring tool, which you will get to see a little later during our demo time. Aaron, won't you say a few words as well about your role here at NUODB? Sure. Thanks, Joe. So nearly a year here now at NUODB. Based over in the UK, I work in professional services, which means I get involved day to day with the customers, helping them deploy NUODB in the best way in their environment, working through the solutions with them. And obviously, recently, we've been doing lots of cloud work with Kubernetes, and that's led to the case study we had to show you today. So, yeah, looking forward to it. Great. Thank you, Aaron. All right, let's go ahead and get started. Yeah, let's first review our agenda. So Aaron, if you could switch. Great. Excellent. Thank you. So I thought it would be good if we just started with a little setting of context and we you know, we define terms like multi-cloud. So we'll do that today. Also, you know, why customers are looking to multi-cloud as a means to deploy business critical apps. And then, as Aaron mentioned, we're going to review a case study. So actually, do a real case study of a real enterprising bank that is going to, you know, is deploying, go into market with a multi-cloud infrastructure. And Aaron's going to take us through a live demonstration. All right, we're going to actually show a Kubernetes multi-cloud environment. And then we'll talk a little bit more about NUODB and our participation in making all of this happen for this particular customer. And then we'll have some nice time for Q&A to make sure that everyone gets their questions answered. Okay. So with that, let's talk a little bit about what exactly is multi-cloud. You want to make sure as we use terms here today in the presentation that you know what we mean when we use these terms. So first off, multi-cloud is not hybrid cloud. So right in our industry, there's lots of jargon. And certainly in this new space of cloud computing, we're not short for jargon.  And that's kind of what's going on here with hybrid cloud and multi-cloud. So multi-cloud, and as we're going to use it today, we're really referring to multiple public cloud networks that clusters that are kind of networked together to make up a distributed computing environment. Now hybrid, hybrid refers really to a mix of technologies. So you have typically an on-prem or a private cloud. And it's, you know, somehow linked up to some public cloud pieces, which makes up, you know, the environment. Typically in a hybrid cloud, what you see is it's a little more rigid, and certain components are running in that segment only. Where with a multi-cloud, and as I mentioned, we're defining here as, you know, two or more public clouds. The idea is around allowing applications and their services to now move more freely between these public cloud clusters. Really, and the aim here is business continuance and the elimination of reliance on any single, either physical location or, you know, cloud vendors product, Amazon, or Azure, Google, or whichever one it might be. Now, as I mentioned, that's the definition we're using.  You will find different definitions. So that's why I thought it is important that, you know, I state in our presentation, when we use multi-cloud, we're referring to two or more public clouds. You will find some multi-cloud definitions that kind of mix that hybrid capability in. So as I said, we are kind of making a distinction here in today's presentation on these two terms, okay? Aaron, yeah, we're ready. Yeah, so why, you know, why would a company or an institution consider multi-cloud for their business critical apps, right?  It's something that many feel they might not have full control over. And there may be some risk associated with deploying into the cloud. And, you know, for some of these reasons, you know, there could be, you know, more research or more decisions that would be made before a company would actually, you know, decide to move a business critical app out to the cloud. But yeah, so what we wanted to talk about is, you know, some of the reasons that we're seeing that companies are looking to the multi-cloud environment to deploy their apps. And as mentioned just a little earlier, business continuity and extending the availability through a multi-cloud is actually something that's now available and can reduce vendor lock-in, right? If you're in a multi-public cloud environment and let's say it's made up of Amazon and Azure, you by nature will be more resilient to any failure events that would occur in any one of those cloud environments because you're not losing that entire vendor's cloud infrastructure. You would only be losing the one and the other would be able to continue to run and support your application. So for these reasons, companies are really seeking to increase their application service levels through the use of multi-cloud computing environments. And as mentioned here, kind of driving that the reality of where we're heading with true zero downtime application deployments. And next slide, Aaron. Thank you. We thought it would be a great way to kind of present the topic to talk through a case study. This is a real bank that has implemented a banking application in a multi-cloud environment. And when deploying a multi-cloud strategy, what we've kind of come across is some industries and specifically the one I'm referring to here in the banking industry, there are regulatory requirements that now mandate the use of heterogeneous or disparate public cloud platforms. So why is this? Well, major public cloud vendors regularly experience outages. Now that might sound like a surprise, but it is a reality. No, some of these outages may be short and the extent of them can vary. But the fact is they do experience regular outages. This is actually verifiable. We can all go out to the internet and Google on these terms and you'll see that there's actually even annual reports on cloud vendors products about the outages that they're reporting and annual kind of interruptions and so on. But so why is this important? Well, so what happens during these outages is organizations can lose availability or data or possibly both. Right? So that's why we start to look towards greater protections and distributing our applications across different vendor products. And with multi-cloud, there's actually some tech enablers that make this all possible. And we're going to talk about some of those today. So one is Kubernetes orchestration. Kubernetes being the leading de facto standard in open source orchestration container management. Basically, a tool that is maturing very, very quickly through open source contributors. And as I mentioned again is like the de facto standard. So Kubernetes has a lot to do with kind of making multi-cloud a reality. Also, high capacity networks. What we're really seeing now is quite amazing in that we can now stand up a multi-cloud infrastructure in two different cloud products. And from cluster to cluster we can see two to three milliseconds of delay. And with that kind of capability, yeah, we can now start to stand up critical banking apps or other critical apps within an infrastructure as we're describing. And then there's also lower costs associated. So low cost compute. And of course, any kind of cloud investment means that there's less investment in your own on-prem resources, be it CapEx or OPEX type investments that we're seeing lower costs associated with these environments. And then storage. Whenever we're moving critical apps into the cloud, we're usually talking about persistent storage and Kubernetes offers integration with lots of container native storage options that are also helping make multi-cloud deployment environments a reality. All right. So yeah, so the banking customer that we're working with is WeLab. And so WeLab is, they're a challenger bank in Hong Kong. And they've embraced multi-cluster. They believe that multi-cluster is the right environment for them to deploy their application. And we've included here several of the reasons that they've landed on. And some of them we've covered lightly already. But in order to achieve the highest level of business continuity, they believe strongly in deploying across vendor's products. And we'll see that WeLab has chosen Amazon and Azure, but you can absolutely choose other public cloud environments as well. The reduced operational costs, it's really reduced capital and operational costs of deploying these environments. And also the ease of management. Kubernetes has a more mature platform now for deploying containerized apps. There are lots of options available now for managing these environments, creating a single pane of glass or interface to managing and monitoring and controlling the environment. So as all these come together, it makes multi-cloud an environment that, yes, a company or institution, even banks, as in this example, can now choose the public cloud environments to deploy their applications. So when we look at WeLab's environment, we'll just kind of cover a few of the things I've mentioned some of them already. They have gone with a multi-cloud that is comprised of two public clouds, Amazon and Azure. Of course, they're using the Kubernetes to deploy their stateful applications with persistent storage. That also includes the NoDB component. The NoDB distributed database uses persistent storage. And we'll talk a little more about that as well. Some of the technology to glue the two multi-clusters together, we're using some VPN tunneling technology, some quality of service via a service provider on Megaport. And in this particular deployment, we've chosen to use Rancher Kubernetes management. In fact, that was WeLab's decision to go with Rancher as their Kubernetes management interface and console. Of course, the application itself, it is a SQL banking application. It's a packaged application. And then the NoDB distributed SQL database. So all these components together have allowed for this environment to be delivered. So with that, I'm going to go ahead and turn it over to you as the one who actually implemented was part of the team that implemented the system. To take us through some of the challenges faced, because I think for our listeners today, they'll be really important as they're considering deploying their own multi-cloud applications. What sort of challenges were we faced and how we resolved some of those challenges? Sure. Thanks, Joe. So Joe asked me to think about the challenges we faced. And you might recognize a theme amongst these few examples that I've given here. And a lot of them boil down to networking. I mean, if you take each individual cloud on its own and you take an application which is a container native and Kubernetes native and easily deployed, then of course, each of those is going to work pretty well on its own. When you start thinking about the issues of connecting these two clouds together, and not just the clouds we're talking here, if it was just a cloud server, a EC2 instance, for example, within Azure, a virtual machine, that would actually be pretty straightforward. But when you actually layer Kubernetes, pod-to-pod connectivity, the container networking, everything on top of each other, it actually becomes quite a difficult task to network everything together. So let's look at these challenges faced one by one. So latency between clouds. Now, NuoDB is interested in latency. We want the best possible latency to get the best possible performance. And one of the metrics we have is that we would like latencies to be a lot less than five milliseconds wherever possible. And if you look in here, two, how they resolve. So basically look at latency. Now, in the case of WeLab, we were lucky in that they are using Megaport, which is going to offer a certain level of QoS for the VPN that's operating over the VPN being the connection between the two clouds. So we can be sure of a certain level of service there rather than going over the public internet, which might be a lot more variable. Now, while we bring up this topic of VPN, it's worth pointing out that we're actually concerned here with two different layers of VPN, if you like. There's a layer of VPN which is connecting the two clouds together, which lots of different applications might run over. And then separately, we also have a VPN which is being deployed by NuoDB within the containers themselves. So if I reference to VPN, I might be talking about one or the other. I'll try and distinguish between them. So in this particular case here with VPN QoS, I'm talking about the external VPN, if you like, the connection between the clouds. The second point here, both data centers being located in Hong Kong. So while we might be using AWS and Azure, both data centers are actually in Hong Kong. Hong Kong is obviously not an enormous place. And actually the distance between them is not enormous. So the ping times latency between those two data centers is actually pretty good. And that's not to say you couldn't use it on a wider network, but you always need to be considering those latency times. And the last point here, keeping client connections local to one cluster. So this will depend a lot on the topology and what the aim of using multiple clusters is. In this particular use case, we have a DR type scenario. So the Azure cluster is a DR cluster and the AWS is our primary cluster for servicing client connections. Now that's not to say that you couldn't use them active-active. But the good thing here is that what we can do is keep client connections local to one cluster and that saves having too many hops between those clusters for both the client connections and for retrieving data from NuoDB itself. So the second challenge I really put down here is pod-to-pod connectivity between the clusters themselves. So again related to networking. And while we were looking at this, we looked at a lot of different options. There's a lot of party products out there which could do this for you. There's some examples here. Container networking, Istio service mesh, psyllium, using host networking, host ports. There definitely are options out there and in most cases getting to the point of having a networked multi-cluster is not straightforward, but definitely possible. The problem is when you start looking at trying to get existing applications working over those solutions, they might introduce problems which you then need to change your product to work with. So it really comes down to a question of perhaps how flexible are you to make it work on these solutions? Or if you're perhaps building up a solution from scratch, it might not matter so much. But certainly in our case what we found is a lot of these solutions are likely to also be predetermined by the client you're working with. Perhaps the KAS cluster has already got a CNI installed and that's the one the company has chosen to work with. So in order to get a bit of flexibility and certainly have a lot of things in our control, we decided in this particular case to run over our own internal VPN. So this is New ADB as a product establishes its own VPN connections between all the peers in its database network. And like it says here, this is pretty simple, effective. It allows the solution to be flexible. It works. It's agnostic to the CNI in use and it allows us a lot of free rein effectively to use our product how we designed it to be used. Third point here, connectivity from outside to inside the VPN. So that's another challenge. Now naturally if New ADB is working within its own VPN that produces a barrier to client applications connecting into it. The obvious answers to that is to also put that client on a VPN, but you know that might introduce other problems along the way. So fortunately, New ADB is quite flexible in that in that respect and what we can do there is allow direct connections using that in combinations with the KAS services that are available. What we are able to do and this will become a bit clearer soon when Joe talks about the New ADB architecture. But effectively what we're doing is bypassing the admin plane of New ADB and connecting directly to the transactional engines which are handling the queries. And we can do that via the Kubernetes cluster IP and headless services so that we don't have to worry about VPN IP addresses not being addressable from outside the cluster. So it's a handy flexibility there that New ADB allowed us to work around that problem. And the third one here, sorry fourth one here, domain databases stability and differences of performance between clouds. So this is a pretty big one actually. When New ADB is running on one cloud perhaps or whether it's running on bare metal you can get pretty consistent and you expect the performance to be of a certain level. When you start mixing multiple clouds what we found is especially with Kubernetes as well, the differences in times between servers being provisioned between pods being replaced between persistent volumes being allocated and can vary quite considerably. And what we found was that that was causing havoc sometimes with how New ADB handled domains coming up and databases being available in the timeouts for default timeouts that we were used to just weren't enough. So in this particular case the resolution for that was to look at how many different ways we can possibly tune New ADB. Fortunately we expose a lot of different options as to what timeouts you can change whether it's the admin layer or SEMs or TEs and we are able to change a number of different timeout settings and address them specifically to the latency of the network. So we can look at average latency, maximum latency of the network over a period of time and then we can use those figures to apply them to the New ADB settings and make sure their work has expected. So combination of different issues there mostly networking related and resolutions around making sure that we got QoS on the VPN taking some things into our control with using our own internal VPNs and the flexibility of New ADB with direct connections and lots of different options to make this work well. So I'll move on to the next slide. So this is an example of the actual client architecture at WeLab.  So in a sense here we've got a simple representation of the VPN connection. Now that represents both VPN connections, the site to site VPN between clouds and also the New ADB VPN and you can see we've actually got VPN pods here running as well which are servicing the internal VPN connection for New ADB. On the left hand side this is showing the Amazon cloud sorry in orange. On the right hand side here we've got the Azure cloud in blue. Now these are both Hong Kong based you might notice on the right hand side and in Azure we don't actually have availability zones and that's because Azure don't offer availability zones in Hong Kong region. On the left you can see we've got availability zones there. So the intent here really is to distribute the New ADB architecture of the T transaction engines, the storage managers and the admin processes ensure they're distributed over enough different resources that we are resilient to failure in a number of different ways. In this example here we could tolerate failures of multiple pods, multiple machines, multiple zones and multiple clouds and still have an operational database. One thing to point out here is I mentioned before that in this particular case it is a DR scenario so we can see at the top applications initially will be connecting to Amazon and like I said before connections from client applications within this cloud will all be directed to transaction engines within this cloud. They would never go across clouds. The connections that are made across clouds are all to do with New ADB's internal synchronization of data to ensure consistency of the data across both clouds. In a failure event the customer would look to be moving connections from the apps over to the other cloud and that would be that could be your automated or manual process of course. Another interesting thing to point out on this diagram is at the bottom here we have a tie breaker zone. Now that could actually exist anywhere, the most logical places to actually use a third cloud potentially. For example you could use Google Kubernetes engine or you could use Rancher deployed to Google. Now the idea of a tie breaker in this particular case is to avoid a network partition. So if we only had two clouds Amazon the left and as you're on the right we could end up in a scenario where the connection is lost between the two and if all processes are equal on both sides we end up with a network partition and the database shuts down. So what this tie breaker zone is effectively doing is allowing majority to be maintained should that connection be dropped and this is what's allowing us to tolerate loss of an entire cloud or a connection to that cloud. Okay Joe do you want to add anything to that before I move on to the demo? I think that was excellent thank you Aaron. Okay so if we make a short prayer to the demo gods. Okay so now I appreciate this might be appearing quite small on some people's screens. Let me just refresh down here it seems to have lost itself. Okay so what you see on screen I've got four windows open. The top right, bottom right, bottom left are all the Rancher management interface and the top left up here is the new IDB insights tool which Joe was mentioning earlier that he manages. So what I want to do first is just give you a quick overview of the Rancher management console. Some of you might be familiar, some of you might be brand new so it's a pretty nice way of looking at Kubernetes makes it very easy to manage. So first of all up here we've got a dropdown. I've named these clusters straightforward so AWS and Azure we have two separate clusters running here. And with AWS we have a default namespace and Azure we have default namespace. But interesting thing to look at first is the node. So AWS node is the page I'm on right now and Azure node is the page down here that I'm on. And we can see if I look scroll down on Azure. I have a single control plane running and I have four work nodes running. And up here on AWS I have a single control plane and four work nodes running. So next if I jump over to the default namespace and both of these we have them to load. So Azure at the bottom has loaded. So if we have a look at this we can see this is the actual new IDB deployment itself which is running. I mentioned before that we have admin processes and we can see here we have one admin process running in the Azure cloud. We have our TE processes here. And we have one of those running in Azure and we have an SM and that's also running on the Azure side. There's a few other pods here of the VPN service that is obviously the connection between the clouds for NodeDB itself. We have a YCSB load generator. So this is the Yahoo cloud servicing benchmark I think. We haven't got anything started at the moment but we'll play with that shortly. And we have a few other Damon sets. So THP we require transparent huge pages disabled for NodeDB as a job for low balance and policies. But we're most most most interesting in the admin, the SM and TE. And the demo gods are not shining on this window at the top here. Let's try refreshing just to point out these. I'm in the UK and all these servers are running in Hong Kong. So sometimes these interfaces do get a bit slow. Yeah and as you mentioned Erin, there's always the live demo Murphy's Law that will and always take effect. But I think most of our listeners appreciate whenever we try to show live demos it's very helpful. I'll just also mention while Erin's waiting for this one screen to repopulate on the demo slide that Erin launched from here, it has two links to recorded videos knowing that sometimes live demos can be a challenge. Once you receive your your link to today's presentation, you'll see that there are two videos that are available. Thanks Joe. So this this is now loaded. So you can see the configuration is very similar. The only difference being that we've got two pods running for admin, two containers running for admin and we've got two sounds. We've got two TEs. Everything else is very similar with an additional monitoring insights pod running here, which is the screen you see in the top left. So that's an overview of the domain. You can see here that these are two separate windows. They're two separate clusters running in two separate clouds. Everything is very distinct and very independent. The only key that we might have that something is linked is this VPN service down here. So in this bottom left window now, if I draw your attention down here, what I'm going to do is I'm going to go into the default namespace. In the admin, I'm going to open a shell and I'm just going to run a new cmd command. And what this does is show us what what new edb's view on the world is, if you like, if I just expand that out, I'll be a bit of shuffling of windows I have to do throughout this. So we can see here that we've we've got three of us up at the top running. And that's that's our three that we had running across both of those clouds. And you can see I've named them slightly differently. So this top one here is named admin dr in Azure and the bottom two here in AWS. And we can see in the database, we have three SMs running and three TEs running. Again, one of those SMs is in dr Azure. And one of those TEs is in dr Azure and the other two in AWS. So what this really does here is just show you that the new edb is really seeing this as one logical database and one logical new edb domain across multiple clouds. And that multiple clouds might not just be Azure and AWS, it could also be Google, it could also be on-prem. It could be it could be anywhere effectively where you've got that connectivity available. Okay, so if I just make that one smaller and this window at the top left here, let me just make this one bigger for you. So what this is doing is this is an overview page system overview. We'll check back here now and again to see what the database is doing. You can see not much is happening right now. This is showing us memory usage per node, CPU utilization, transactions per node. An interesting one here is the aggregate transaction rates in total TPS that's running and our client connection. So we'll keep coming back here and checking what's going on while we're doing the demo. So the first thing I want to do is I want to scale up a workload. So we have YCSB, AWS in the top right. I'm just going to drop that down and we have YCSB in the bottom right here. So I'm going to drop that down as well. So first of all, I'm going to scale that YCSB workload up to two. And we'll just wait a few seconds for those. Pause to allocate pretty quick. And on the top left here, we've got last five minutes showing. So we'll just have to refresh this a few times away a few seconds before we start seeing things happening. Now bear in mind what I did just here is start up YCSB only on the AWS side of things, not on the Azure side of things. And remember earlier, I mentioned about keeping those connections local to one cloud. And what we'll see on this up here is when the load starts, we'll see that those connections are only being serviced by TEs that are in Azure. So here we go. We can see the connections are jumping up there. The yellow and green are the two AWS nodes. We can see our transaction rates increasing. So again, the two AWS nodes, we've got around 1000 TPS per node for the moment. And we can see our aggregate rate is as it should be around 2000. We'll just wait a little while for that to stabilize. So while that's stabilizing, the first thing I'm going to do here as an example is to delete a TE. So this is a soft way of simulating a pod failure if you like. Let's say that one of our transaction engines dropped, whether it might be the node that it was on died, it could be the pod itself died, anything to do with causing that transaction engine to stop running. Now the client in this case is correctly configured. So the client connections to the TE that died should be re-established. And when that connection gets re-established, it will re-establish to one of the other TEs, which is still available in this particular case. We've only got one other available TE. But what we should see over here is the connection that's dropping off of one TE that died reconnecting to the other TE while it gets rescheduled by Kubernetes. And then what we should see shortly after that is the load get redistributed back to the restarted TE. And all the time we should see that the transactions continue running and we have no loss of availability in the meantime. So it's stabilizing over here now on the top left. So I want to go ahead going to our transaction engines. I'm just going to delete one. Assume that deleted. Let's just give a refresh. It decided to go slow again. So it doesn't look like that deleted when I told it to. But hopefully after this refreshes, it will work. This is what I was pointing out to Joe before we started. It seems to be slowly responding today. Yeah, that's okay. I'm sure it'll catch up. We may even actually see that it's deleted sooner in the NoDB Insights interface. As that interface is updating every 30 seconds with data, if it has deleted in the back and we may actually see it there first. Yeah, that's why I'm thinking it hasn't because I haven't seen that drop off over here. Yeah, it does look fairly stable there. This becomes one of those things when you click something five times. Does it happen quicker? Yeah, that looks like the transaction rate held steady. Yeah, indicating that probably that the delete did not occur. Yeah, we can see here we've just got an error refreshing the interface with a network request failed with the renter interface. So this does happen. See, it's such a resilience. It won't even allow you to delete a part. Funny that with the case. What we could actually do is try down here, see if this this connection is working any better. Let's go to, I don't know if it doesn't like me having multiple connections open to the same interface maybe. Well, that's okay, Aaron. Why don't we go ahead and continue because I think everyone gets the main idea around the idea of the ease of management through a containerized management console like renter to to manage a multi cloud environment, as well as how new ODB and distributed SQL databases servicing a banking application, or in this case, a sample app. But the idea is the same with the client that we have implemented in the lab. Also, I think some of the strong points that Aaron was making around our choice of the VPN tunneling, I think we want to also make clear. As you look to deploy your own multi cloud environments, we're always going to suggest that you consider and look over the best possible generally available options at that time. It is while a mature space, it is continuing to evolve and improve. So we would suggest, in our case, as we mentioned the VPN tunneling for us, it was kind of a simple, reliable way, an effective way for us, a very supportable way to deploy this multi cloud. We looked at some other technologies like, as Aaron mentioned, Istio, there's the Submariner project that was not GA at the time when we were looking to deploy for this customer. So again, just look at the different components and then evaluate them during your planning and your testing phases to determine the best and optimal tools for your own deployment. So, Jay, what I just thought I would do is just see if I could load up the interfaces, improvise here and close down my multiple windows and just see if I can get it up in the browser. We've got the initial connection okay. Sorry, Aaron. Let's go ahead and continue. We'll spend the next five minutes or so. We just want to do a little bit of an overview of how Nodev participated in the solution and then we'll open for some Q&A. We have just got it back. Up to you. I'm a wary of time. So, did you want to carry on? Yeah, why don't we go ahead and carry on because I think, you know, and as I mentioned, the video clips are going to demonstrate exactly what Aaron was going to show next. He was going to demonstrate the resiliency of the system that was built by basically inserting a failure event and deleting, in this case, a transaction engine, but you can delete it or a transaction engine, a storage manager, even an admin process within the control plane, and the Nodev database system will continue to operate. As long as there are multiple processes of each process type, the Nodev database system is going to continue to run and process SQL requests. So, it's a very strong benefit of the solution. So, Aaron, why don't we jump back to the slide deck? Yeah, sure. If you could. And yeah, again, I think on the next slide it actually shows those video links that I was referring to, and our listeners can always go and enjoy stepping through those at their own pace. They all have text labels describing what's happening as you go through those videos. But on the next few slides, and we'll move through quickly, there's just a few things that we wanted to talk about. And one is when and when not to deploy a multi-cloud environment. Now, really the suggestion here is a multi-cloud architecture, while certainly great for this particular bank and their critical app. Maybe not all applications require this level of business continuance. The bank is trying to achieve 24 by 7 by 365 availability, and they were looking to the absolute best technologies available to do that. So when not to consider, well, if your app is not requiring that type of service level, then you could likely deploy in a single cluster, or maybe it doesn't need to be across heterogeneous clouds. You can go across two particular clouds or a hybrid environment that we had talked about earlier. So all things to consider. On the next few slides, and some of this I'm going to allow for your review as well once you receive the deck for your own keeping, is just some slides that review the new ODB solution itself as a distributed SQL database. Erin, if you could flip one more slide. There was a couple of areas I wanted to point out in the architecture. You'll notice in the diagram the transaction engines are highlighted in green color, and the storage managers sort of in this yellowish color. One of the takeaways and benefits of the product is how the database is architected such that the transaction and storage layers are independent of each other. This allows the new ODB to scale either component based on a particular workload or use case. To the left we see this traditional environment where the query processing and the storage management layers are tightly coupled together and they just kind of stay together in a full database instance. New ODB is providing flexibility here that allows new ODB to service applications in a greater variety of ways. Also new ODB, if you're curious about the type of SQL, it supports anti-standard SQL. It also delivers acid transactional properties. You can trust that when you run your SQL applications that you are getting a secure and consistent atomic transaction that's being committed durably to disk. Just as if you're migrating from any legacy popular database systems, new ODB delivers that same high level of transaction security. In the next slide actually demonstrates some of how the different environments that can be supported. You can have some applications that might require scale out of the transaction layer. Erin, if you could just flip the slide that would be great. Thanks. Here we see the one at the top, maybe a logging application has many more storage copies as where maybe an HTAP hybrid transactional analytical processing app might have lots of transaction engines servicing different types of applications but less copies of the database. The choice is completely yours. Next slide, Erin. We've talked through a lot of the benefits of the active-active capability, the scale out, the distributed architecture of new ODB. I'll just make one point here about the dynamic caching capability. Each transaction engine is keeping a dynamic cache. If memory is available to it, it will effectively use its in-memory database performance capabilities but if it does need to go fetch a piece of data it doesn't have, it will look to its next nearest transaction engine neighbor and remain as efficient as it possibly can before ever going to disk to go for a data block or in our case we call them data atoms. Next slide. Yeah, so let's go ahead and wrap up and then we'll work to take some questions. So really what have we talked about today? We have talked about some rapidly maturing capabilities that have effectively allowed multi-cloud infrastructure to become a serious choice for those who would even be deploying stateful critical business apps to the cloud. We talked about Kubernetes and network resiliency. A lot of what's available today we could have only have dreamed about just even a few short years ago. Also this idea of running critical apps and a single logical distributed SQL database across a Kubernetes managed environment, it's demonstrating for us really the new possibilities. Earlier we talked about the true zero downtime capabilities and these options, they really allow our customers today and yourselves as you look to deploy multi-cloud it allows you to consider for you the best ways to deploy these applications when you want, where you want, and how you want in multi-cloud infrastructure. So with that why don't we go ahead and open for questions. We've got a few minutes left and Erin and I would be glad to answer any questions that are out there. All right so there's two questions that are open in the Q and A right now if you want to just go over those answer them live. Okay great thanks I will yeah so does the new ODB JDBC driver support the TE deployed in a multi-cloud model? Yes it does absolutely so the application that's being deployed in the cloud can certainly be a JDBC app and it would leverage the new ODB JDBC driver for that purpose. And the second question is how does new ODB differ from SAP HANA as a distributed in-memory processing database? Okay so SAP HANA kind of well known, I'll go ahead and say it's more of a you know kind of on-prem private cloud type implementation. So you know as far as you know how it's it's differing in availability would be just that we're we aim to effectively deliver on many of those same distributed in-memory capabilities but do that in the cloud okay and I touched upon some of the in-memory processing that new ODB as I said uses a kind of a quickest available algorithm to determine how to find its in-memory component. So each transaction engine could not possibly include all of the data of a database but when you look at the transaction engines together in a chorus they can start to approach you know much of a larger percentage of the database in-memory. So they do kind of work together in order to create that in-memory distributed database performance. Okay and then we also have a third question. Is this in the same competitor space as data stacks a distributed Cassandra? Yeah exactly you're answering your own question right guess not since SQL versus NoSQL yes Duane that is correct. So new ODB is pure SQL database it is not a NoSQL database. So we would not be considering data stacks kind of a competitive offering. Those who are looking to new ODB are those who have made a large investment in their SQL applications. They're typically very critical business type applications and they don't want to throw away the investment. They want to maintain an investment both in the apps as well as their you know human resources and leverage those apps in newer modern computing architectures that multicloud and Kubernetes is bringing to this space. Okay looks like we have another question coming in as well from Sujit. How is concurrency handled when multiple TE and SMs attempt to update the same underlying database records in new ODB? So new ODB also supports a distributed lock manager just like all those other you know legacy mature relational database products that you're used to. So there is for each data atom in new ODB we call it a chairman they all have effectively an owner that is its distributed lock manager. Okay so basically two different writers would not be able to write to the same data at the same time. Whoever establishes the lock first will become the owner and others will have to either wait or can at the application layer choose to not wait. Okay so really it's handled in the same way as other major relational database products. Okay great questions everyone. So Joe I spotted a question in the chat that hadn't made it into the Q&A as well and that was raising the question are there any security concerns with sending data across the clouds. I did answer that one I typed it in earlier because that came in earlier but feel free to add if you had something that you'd like to add. Yeah I was just going to say that when we set up the new ODB VPN so there's several different layers of VPN I mentioned here and we've also got a new ODB TLS encryption as well. So all the connections between all the new ODB components and clients we have TLS encryption. The new ODB VPN which we are deploying in order to operate across multiple clouds can optionally also be TLS encrypted and then thirdly if you're operating rather than over the public internet if you're operating via a site to site VPN for example between Azure and AWS or if you've got a provider like Megaport then there's options around encryption there as well. So there's you know potentially three layers of encryption you could use not saying you should or would use all of those obviously they might add latency as well but yeah certainly encryption is available. Great thank you Erin appreciate some further insights there. I think that wraps it up for us Chris so I guess so from our side myself and Erin we were delighted to present to the group today it's a fascinating topic and we were glad to share our experiences as we have deployed multi-cloud for one of our banking applications. So whenever considering a sequel application in the cloud we do hope you may call upon us as this is an area we have a lot of experience and we look forward to perhaps crossing paths again. Awesome thank you Joe and Erin for the presentation today. The webinar recording will be in slides will be available online hopefully later today at cncf.io slash webinars with an S. If you have any questions or concerns head there and wait you know feel free to look for the video and reach out if you have any other questions for the gentleman on the call today and without further ado see you at the next cncf webinar here in the future and have a great day. Thanks for hosting Chris. No problem thank you all.


Recall what we have done so far is record the processing and the production of our inventory. Most of that happening in the account called work in process. That work in process account, this one number in work in process being supported by jobs. So this one number needs to be supported in a similar way as the accounts receivable. The accounts receivable having a GL account by date, but also needing a subsidiary account by customer to know who owes us money. The work in process also has a GL account by date, but we also need to know this work in process by job. So as we recorded costs that are going to be applied to inventory, we either applied them to the work in process directly if we knew which job it was going to, such as the direct materials and the direct labor, or we had to allocate it to the jobs after first recording it into the bucket of overhead, then using a predetermined overhead rate to allocate the overhead to the actual jobs. What we're showing here is going to be a bit of a condensed job cost sheet. So we have like these are condensed job cost sheets job B15, B16, the 17s up here, B18 and B19. They all have the three major components that we've got the direct materials, direct labor and factory overhead. And if we add those up, these three components for each job, we will get to the totals here, the total for each job. So this is the cost of each job as we've go that this is the cost so far. Now when all those jobs are open then as they have been so far, we're going to say that they're all in work in process. We don't have anything in finished goods so far. And so all of these jobs at the start of here were open jobs, they're all going to be comprised of or put together to come up to this 13150. In other words, if we add up these jobs, we're going to say the total job cost is 3820 plus 2790, which is this item plus 2024 plus job B17, which is 2126 and job B18, which is 2390. That's going to give us our 13150. So that's the case when they're all open. Now there's three basic ways a job can be. It could be open and we're still working on it, which means it's going to be in work in process, or it can be closed because we're done with it. So I'm going to call that a closed job, a finished job, a completed job, however, we want to phrase that we're going to say it's completed. And therefore it needs to move from the open job to the completed jobs. And we're going to say that these three in blue here are those that have moved. We're going to say they still have a job cost sheet. The job cost sheet looks much the same, but it's done. We're no longer working on it. We're no longer adding more material, labor and overhead costs to it because it has been completed, whereas these two jobs B18 and B19 are still open. So what we need to do then is make a journal entry for that transaction to move this to here. The journal entry is pretty straightforward because these are two inventory accounts. We just need to move this to here, but we need to be able to support that by the job sheets. And that's what that's what gets a little bit tricky because we're going to be using these job sheets to back up and support both the work in process and the finished goods. So the journal entry, according to the numbers we have here, we're going to say, okay, these three blue jobs, we're going to move. So that's going to be the 3820 plus the 2126 plus the 2790. So that's going to be these three items here. And we're going to move those out and we're going to put those into finished goods. So let's do that now with a journal entry. Before we do, however, just want to remind us of what the full job cost sheets that we've been looking at have looked like. So we're kind of simplifying these job cost sheets here to give us a simple worksheet to work with job cost sheet that we have been looking at might be more detailed depending on what types of job cost systems we're running. But they have the three components, direct materials, direct labor and overhead. And again, we might be applying that direct labor out with the requisition forms and the time tickets and tying that information out. But in essence, of course, we're going to end up with total direct materials, total direct


The rising profitability of firms in the U.S. has financed an explosion of corporate lobbying since 1970. Given American financing of politics, it is difficult for people to stand for Congress without deep-pocketed backers, so that politicians of both stripes, left and right, are increasingly supportive of business interests. More than two-thirds of Americans believe that democracy is rigged and that they have little or no say in governance compared with business and the wealthy. The dominance of business in the rich in politics has brought an orgy of rent-seeking where firms and the rich get special protections that allow them to plunder the public. Doctors and car dealers, protected from competition by local and federal law, are well-represented among the top 1% of income. Pharmaceutical companies are allowed to addict patients for profit while their representatives in Congress block investigations and change the law in their favor. The American healthcare industry is a particularly egregious case. Hospitals have been allowed to merge and raise prices. Officially designated non-profit hospitals pay their chief executives huge sums while keeping wages low, sometimes even conspiring with other hospitals to undercut pay. And as non-profits, they avoid most taxes. Private equity is discovered that healthcare is a profitable business. Patients often have little choice and can be easily exploited. Think of ambulance services in emergency rooms where customers are unable to make alternative arrangements if only because they're unconscious. Globalization, especially the globalization of capital has helped the rich avoid paying taxes. Money flows to international tax havens and international firms play off governments against one another to keep taxes low, converting countries into tax havens. With freely mobile international capital, the countries are losing control of their tax systems. Firms and bankers, not voters, get to write the rules. Meanwhile, the people that we did not listen to are angry and frustrated. They have lost trust not only in us, but in science and in expertise. Pandemics have become harder to control as has climate change. Voters have turned to populace who promise to do better and who might well do so for them, although at terrible cost, the undermining of democracy and perhaps even the loss of our planet. Thank you very much.


At 6-year-old Annika's first time at the San Francisco Women's March, one of her mom's Caroline is marching for the third year in a row with Mom's Demand Action, a gun safety advocacy group. Well, I hope that my daughter will be a strong woman later and that's what we're trying to teach her every day. Women! Women! Caroline and her daughter are part of the wave of women marching for change across the country today. The original march follows the election of Donald Trump in 2016, a call to action to advocate for and protect women's rights. While all roads lead to City Hall where a rally in the march began, participants we spoke with had their different reasons for marching. I'm not secure because of science reasons. I am a big advocate for science. We need to trust scientists instead of ignoring them. Leading the procession was the indigenous women contingent, who brought light to the murdered and missing indigenous women worldwide. I feel like this, as any parade or protest that we have, is like showing not just San Francisco, California and the nation, but the world that, you know, what's going on is not right and there are people who are going to stand up and continue to protest. Moments of jubilance mark the progress of the movement for many. Reporting for CalTV, I'm Tommas Malongan.