Welcome to the Options Beginner series. The Options Beginner series is your entry point to learning everything about options which is the most fascinating instrument in financial markets. We'll start with call options. Call options are the logical starting point for learning options. You may have tried to learn options before but you might have experienced a lot of jargon and that's because options are a little complex but we're going to break this down in very simple terms and explain options very clearly using a real world example. And then finally we're going to go into a trading platform and look at Apple options and compare what you've learned in theory to the actual live trading platform. Let's first look at a brief history of options. Options are a very practical instrument that humans required at various points or at various situations. The first known usage of options was in Greece around 300 BC by an olive speculator. So the way it worked was the olive speculator felt that the olive season was going to be very good. The upcoming olive season was going to be very good. On the other side the olive farmers who are always uncertain about how the season is going to be and from their perspective they'd like to have some certainty as to what money they can get for this upcoming harvest. So this speculator issued contracts to all the olive farmers that he would buy their harvest for a certain amount. And then as the months went by sure enough the olive speculator was right in his judgment and it was a spectacular season. If the olive speculator had contracts for let's say $10 and the season was so good that he could get $15 then he pocketed the balance $5. So this was an example of an option that was used by this olive speculator. Both sides were happy because the farmers were guaranteed a certain amount which would give them peace of mind for that particular season and the speculator obviously made a profit. So fundamentally an option is an instrument that was invented to manage price risk at some point in the future. There's got to be some kind of price uncertainty in the future and then you can create an instrument like an option around it. Now obviously we're going to get into all the details as we go along but there's also no usage of options in the Netherlands in the 1600s and if you've heard of the Tulip bubble it was one of the largest bubbles at that time and options were used then, options were used in England in the 18th century then in the 19th century futures markets started developing in the US and finally options as an instrument by itself started trading on the CBOE which is the Chicago Board of Options Exchange in 1973. Options are mathematical and they're based on something called the Black-Scholes model. Then put options started trading in 1977 on the CBOE and then by 1990 options started to trade on several securities mostly all the big stocks and the indices. Today options are traded on hundreds of securities, ETFs, gold, futures and they are also traded around the world. Although options are not as big as futures of forex markets options are becoming one of the most popular type of instruments and they are also one of the fastest growing. Now Black-Scholes were awarded the Nobel Prize in 1997 for their invention so what we have to take away from this is that options are an invention. They are a mathematical set of formulas that these two mathematicians came up with and so even though it's considered a financial instrument it's really a mathematical instrument and we'll be getting into this as we go along. So let's look at these mathematical underpinnings of options and what really are their implications for what we call the options market today. So first of all options are a separate instrument from the stock itself and the stock or the asset is called an underlying asset. So think of the olive farmer. The olive is the underlying asset or the olive season or the price of olives for that season is the underlying asset but the contract that was created between the speculator and the farmers is an options contract. So the options contract is separate from the underlying asset. Now in this case it was the olive harvest but it could be stocks it could be bonds it could be foreign exchange it could be anything. So options require an underlying asset. If there's no underlying asset there cannot be any options. Additionally there must be price uncertainty. So which means either prices are moving constantly prices are volatile prices are changing prices are uncertain things like that. There has to be price uncertainty around this underlying asset otherwise you cannot have an option and this is why options are called derivatives because the value of the option is derived from the uncertainty and the movement of the underlying asset. So now let's look at some details. All options must have an expiry date. So think of the olive farmers and the speculator. Could the speculator have produced this contract two years later or three years later and demanded to be executed on his contract. Obviously not the farmers are not going to honor that contract because that contract was for that specific season. So in this case the expiry of the contract was probably six months maybe whatever the expiry date of the harvest was. Similarly even in option markets in the financial markets we have an expiry date in the US one options contract is equal to 100 shares of the underlying asset and the reason they have this relationship is so that contracts can be standardized 100 shares and therefore when it comes time to settle these contracts things are very standardized there's no confusion there's no half a share or half a contract things like that. Options are what you call leveraged instruments and we'll come to this later. They have a mathematical base as we've said a couple of times and so there is a learning curve. Now you can imagine these mathematicians they want Nobel prizes for their formula. So you can imagine this is not simple stuff this is complex stuff but fortunately we don't have to worry about all that formulas. We are going to be looking at the practical side of options. So don't worry that these are complex mathematical formulas we don't have to deal with them. They're called options for a reason. They have a lot of flexibility and they have a lot of variety and you're going to find that this is the most attractive feature of options and which is what makes it the most fascinating instrument in the financial markets. So hopefully this has given you some kind of a base on options and in the next part of this course we're going to jump into some of the details we're going to compare options versus stocks and we're going to see what the differences are and so on and so forth so I look forward to seeing you then.


Hello, and welcome to the session in which you would look at consignment arrangement as part of the revenue recognition process. In a consignment arrangement, we have two parties. We have a consignor and a consignee. For the purpose of this illustration, we're going to assume that PepsiCo is the consignor and Walmart is the consignee. Who is the consignor? It's the party that transferred the goods, not the title to the consignee. Simply put, PepsiCo will transfer, physically transfer their product and replace their product in Walmart's store for resale. Although they place their product in Walmart's store where Walmart has physical possession, the titles never did not change. PepsiCo still have the title for its own product. So the consignor PepsiCo will retain its title. PepsiCo places the goods for resale. Simply put, all what's happening here, you can look at it as an arrangement to rent the shelf. So all what Walmart providing is the space, giving PepsiCo the space shelves to place their product. Once goods are sold, Walmart will submit the proceeds from the sale minus a commission as their avenue for Walmart. So nothing will happen, really. No sale will take place until Walmart sells the product to a third party, to a customer. Walmart will take a small commission and will submit the proceeds remaining to PepsiCo. So PepsiCo will only recognize the revenue when the goods are sold to a third party. And what we mean by third party here is someone other than Walmart because Walmart did not buy the product from PepsiCo. Because if the product are not sold, simply put, Walmart will return the product to PepsiCo and there is no sale for PepsiCo. So PepsiCo will have to wait until a customer walks into Walmart, buys the product and walks out. Now, who's the consignee? Well, we said the consignee is Walmart. The consignee accept the transfer of the goods but not the title. Although they possess the physical inventory, that inventory cannot be counted as part of Walmart's inventory. So simply put, when Walmart counts their inventory, they cannot count PepsiCo product as part of their inventory. And Walmart's will make a commission, which is this is when they recognize the revenue, when they make the sale. And when they make the sale, also PepsiCo will make the sale as well. So in a sense, Walmart will take title for a few seconds when the person walks with the product, give it to the cashier, the cashier scan it. In that split second, Walmart takes title, sells it, then give the proceeds back to PepsiCo. It doesn't happen automatically. I mean, it does, it could happen automatically in a software system, but we're not going to assume it's going to happen automatically. Actually, we're going to look at an example to see how this process worked by using journal entries. But before we look at journal entries and an example, I would like to remind you whether you are a student or a CPA candidate to take a look at my website farhatlectures.com. I don't replace your CPA review course. I don't replace your accounting courses. My motto is saving accounting students and CPA candidates one at a time by providing new resources, lectures, multiple choice, true false questions that's going to help you understand the material better and do better on your exam. This is a list, a partial list of my accounting courses. My CPA material is aligned with your Becker, Roger, Gleam, Wiley, Miles, or any other CPA review course. I give you access to 1500. Previously, AI-CPA released questions with detailed solution. If you have not connected with me on LinkedIn, please do so. Take a look at my LinkedIn recommendation. Like this recording, share it with others. It helps me tremendously connect with me on Instagram, Facebook, Twitter, Reddit, and I just started a CPA exam support group on GroupMe. Please join us. Let's take a look at this example to illustrate sales on consignment or consignment arrangement. Let's assume PepsiCo ship product costing $360,000 on consignment to Walmart. Well, that's what happened first. PepsiCo pays $20,000 of freight sales, so they pay $20,000 to get the product to Walmart. Walmart, from their part, they're going to pay $5,000 in advertising costs to promote PepsiCo product. However, the advertisement cost will be reimbursed by PepsiCo. By the end of the period, Walmart sold two-third of the consigned merchandise, two-third of $360,000 for $320,000 in cash. Then Walmart notifies PepsiCo of the sales, retired 10% commission, and sends the cash proceeds to PepsiCo. So let's take a look at the journal entries step by step. From the shipment of goods from PepsiCo to Walmart. When we ship the goods, PepsiCo will debit an account called inventory consignment, and they will credit finished goods. They're basically both inventory, all what they're indicating here, that the inventory left PepsiCo warehouse, and now it's part of our inventory of PepsiCo inventory, but it's on consignment in Walmart. What would Walmart do under those circumstances? Basically no entry. What will Walmart do is basically make a note, a memo, knowing that make sure don't count PepsiCo inventory as part of our inventory. Then PepsiCo paid $20,000 for freight cost. Remember freight in, it's part of the inventory cost. Therefore Walmart, sorry PepsiCo will debit inventory. We're going to make it $30,000. PepsiCo paid $30,000. We're going to debit inventory $30,000. Credit cash $30,000. What will Walmart do? Practically nothing yet. They have nothing to do with anything. Now payment of advertisement costs. Now Walmart did incur $5,000. So what they did when they send a weekly offers, they just had a special offer for PepsiCo, and they had to pay $5,000 for that advertisement. That's fine. And that $5,000 PepsiCo will reimburse them for it. Simply put, PepsiCo told them, you have $5,000 budget advertised as you see fit and will reimburse you. What will PepsiCo do under those circumstances for the $5,000? Nothing yet. On the other hand, Walmart paid the $5,000. They will credit cash and they will debit a receivable from PepsiCo. Why? Because PepsiCo is going to reimburse them for that money. Now the sale took place. Now the customers bought the product. Well as of right now, there's no entry for PepsiCo. For Walmart, they will debit cash. They sold them for $320. They will debit cash $320. And they will debit cash and they will credit payable to PepsiCo $320. So this money belongs to PepsiCo as far as Walmart is concerned. They're going to take a cut of it, but part of it, the majority will be for Walmart, for PepsiCo. Now we're going to see how much money we are going, we're going to be sending to PepsiCo. PepsiCo. Okay. So we received $320,000. Here's what's going to happen. First, we're going to keep, we means Walmart will keep $5,000 for the advertisement. Then they will keep 10% of $320,000 times 10%. They will keep another $32,000 as a commission cost. So what's going to happen is this. So we're going to be, let's take a look at the calculator. And so $320, that's how much they received in cash, minus $5,000, they're going to be reimbursed, minus $32,000 is basically their commission. They're going to give, they're going to send to PepsiCo $283,000. So PepsiCo will do the following. They will debit cash $283,000. They will debit advertising expense, which is that's when they expensive. They will debit commission expense because they had to pay commission to to Walmart $32,000. And they will credit revenue, the total revenue is $320. So although the total revenue is $320, really they had, they had two additional expenses, the $5,000 and the $32,000. So now their net, net sales $283,000, although they sold $320,000, but their net sales for now is $283,000. Walmart, when they submit the $283,000, I showed you how to complete this. When they submit this money, they will debit this payable to get rid of this payable. They will debit payable to PepsiCo because now they submitted the money. They will, they will credit the $5,000 of receivable because PepsiCo now told them to keep the money. So they will credit this receivable to remove it. And they will credit commission revenue to recognize $32,000 of commission revenue. So this is the entry that Walmart will make. So at this point, Walmart would record. So notice what's happening. This revenue for Walmart, the $32,000 is an expense for PepsiCo. And the $5,000 that, that, that Walmart pay on behalf of PepsiCo, it's recorded as $5,000 expense on, on, on PepsiCo books. So simply put Walmart made $32,000, which is 10%. Now, now we have to also record cost of goods sold for PepsiCo because PepsiCo, they only sold, not only sold, they sold two-third, two-third of the goods. They still have one-third. Simply put, we have to remove two-third of, two-third of what? So we have to remove two-third of $360,000 times two-third is $240,000. Then one, then PepsiCo also incurred $30,000 in, in, in freight in, two-third of $30,000 is $20,000. Hopefully we know this. So our cost of goods sold is $260,000. And now I remember why I changed this number from $20,000 to $30,000 because we assumed we sold, we sold two-thirds. So it's easier to do two-thirds for $30,000. Okay. So now with that cost of goods sold to $60,000, credit inventory consignment would reduce our inventory consignment account by $260,000. Now we can say, well, after we deduct the cost of goods sold, so let's, let's make cost of goods sold in a different color, $260,000. All in all, PepsiCo made gross profit, gross profit of $23,000 on this, on this arrangement, made $23,000. If we take $23,000 divided by $320, it's approximately, we made approximately 7% net profit, 7%. Well, we can say, we can call it net profit, assuming we have no other, no other operating expenses. Okay. So this is basically the arrangement. And, and Walmart doesn't do anything for adjusting inventory and cost of goods sold because it's not their inventory. So all in all, this is how you, this, those are the journal entries that you are expected to know for arrangement, goods on consignment. What should you do now? Go to farhatlectures.com, register, subscribe, work MCQs, and look at other resources to reinforce those concepts. Invest in your accounting career, invest in your CPA education. Don't shortchange yourself. It's worth it.  Good luck, study hard, and of course, stay safe.


Hello, everyone. My name is Eva Gasperovic, and I'm a developer programs engineer here at Google. And this is Jeff Posnick. Hi, everybody. I'm also on the Developer Relations team at Google. Jeff is one of the creators and main contributors to the Workbox library. Today, we are going to share with you our story about transforming the women techmakers.com website into a progressive website. But before I get to it, let me tell you what brought the two of us together on that project. Some time ago, I was talking with a friend of mine, Megan, at work. And I knew she was involved with the Women Techmakers program. So I asked her, how was it going? And she told me with a lot of enthusiasm in her voice, Eva, it's going great. The program is growing. And it's amazing because it's so community-based. There is so much going on. But actually, sometimes it's also challenging. It's hard to keep everyone in the loop. Given that everyone is going mobile these days, we're thinking whether we should have an app for it. And it made me think, if an app was the way to go, how about a progressive web app? It also made me personally curious. I knew quite well by then how to write a progressive web app from scratch. But transforming an existing life site is entirely different story. And I know some of you are bothered about it as well, because you approached me during this conference already and asked about it. So I'm very happy that I'll be able today to share this story with you. Luckily for me, this is also where Jeff comes into the picture. Around that time, he was working on a workbox library. When he learned about my migration plans, he approached me. And he said, listen, Eva, me and my team are working on a set of tools that would make your migration a bliss. Would you like to use it? And of course, I said yes. And that's how me and women techmakers became a guinea pig for the workbox project. So that's what we settled on. We settled that women techmakers will get a progressive web app that Jeff will provide us with tools. And I will get my discovery process about how it feels to migrate a website that I can share with all of you today. And this is exactly what we're going to do today. Our intention is to give you some insight and some tooling so that you can attempt migrations in your own projects in future with confidence. OK, let's start. First, I would like us to look into the decision process behind how we decided to go for a progressive web app. But in order for you to understand our decisions, you need to know more about women techmakers. Women Techmakers is a Google Global Program for Women Technology. It is actually a great pleasure to talk about it here at IO because this is where all of this started. Six years ago, here at IO, the first women techmaker event took place. It was an event to bring support and community to women who attended the conference. And I'm very happy to say that this support yielded the results and our number grew. In the old times, around 2013, there were only 8% women attending the conference. And this year, we aim to have 25% of us attending. And I'm happy to say that we made it. Since then, the women techmaker have grown from a humble once per year event to now hosting hundreds of events for over 70,000 women worldwide. There is Women Techmakers Scholars Program for college students, a membership to help women get the career support they need, and many more initiatives. It is now part of the global movement for women in technology. It's not focused in Silicon Valley only or even US only. It supports women in 160 countries. That's a lot of diverse environments. Because of that, women techmakers had to get creative at how they can support such growth at scale. When Women Techmakers was entering new markets, it also started targeting new audiences. And these new audiences often meant more users on mobile devices and on less-reliable internet connections. The program leaders wanted to make sure they have the infrastructure that supports this diverse environment. And it seemed that a progressive web app might be just what they need. A progressive web app is a web application that uses modern network capabilities to deliver app-like experience to the users. It should be in particular, reliable, which means it should load instantly even in uncertain network conditions. It should be fast, which means it should react to users' actions on all kinds of devices. And it should be engaging, which means it should feel like a natural app on the device, providing an immersive user experience. You can see how those features corresponded with the Women Techmakers goals. By making the site reliable and fast, we would improve experience for users on mobile and on slow internet connections. And by making the app always just one click away for the user on their mobile phones, it would help to keep users engaged and involved even more in the community. It would allow us to improve user experience and stay frugal at the same time. We could keep current infrastructure, have a single code base, and support only one platform going forward. So that was the decision. We will migrate this site to a progressive web app. So how did we do it? How did we approach our migration? Well, this is the process we roughly followed. First of all, we needed to understand, deep in detail, the current state of our site. In order to do that, we use Lighthouse. How many of you know what Lighthouse is or use it? Yeah, you've been to the mobile web tent, hopefully. OK, so Lighthouse is a Chrome extension that all of you can install in your browser that allows you to measure how close your web app is to a progressive web app. When you run your website to Lighthouse, it gives you back a report and a score that summarizes the state of the app for you. When we started the process, our score was about 45. And our goal was to get as close to 100 as possible without changing how the site looked or worked in general. That's why we called it migration. We didn't want to alter the site too much. We just wanted to make it smoother in different environments. If you're curious about your own site scores, you can try out the Lighthouse in the web tent. And if it goes green, it means you have an amazing, amazing website. So here's how our Lighthouse report looked like. You see the score there. But apart from that, you also see a list of feature or traits that the website should have in order to be considered progressive. The green ones means we're doing well on those. And the red ones mean there is a rear for improvement. And one cool thing about this list is that actually each of those is an expandable section. So you can click on it and see more information about the particular feature. And also find links that lead you to resources that tell you how to actually implement that feature or get better on it. And this makes it super cool tool for people that are less experienced with progressive web apps. Because as a matter of fact, you don't even need to know what features you should implement in order to get progressive. Lighthouse will simply tell you. As you can see, our Lighthouse was 45. And we were presented with a list of options. So what do we do next? Well, we needed to prioritize. Because we didn't have all the resources in the world, and we didn't have all the time in the world, we needed to make sure we focus on the most important things first. And this is why I put the Women Techmakers logo there. Because that's the moment where you take the technology you have, like a Lighthouse report, and bring it back to organization or to business people. Because those are folks that know best what's good for the users. And important thing to remember about the progressive web is that it's not a monolithic technology that you just drop on your site. It's actually a set of modular solutions that you can usually implement independently on each other. So you can take that list and just pick and choose and decide what would make the biggest difference first, and then iterate on it. So you don't need to be scared that you need to do everything in one go. You can start with smaller changes and take it from there. In our case, we decided to focus on two areas, on offline and on app-like experience. Offline, obviously, would improve the performance on low internet connections. And that would improve how the app works not only for the users in the countries where the connection is scarce, but also in environment like some big conferences. You've probably encountered this problem where you can't really access the website conference. And Women TechMaker is a lot of driven initiative, so it was important to add that. Secondly, we decided to add app-like experience, which means you can now install the app to the home screen of your mobile device. We've hoped that this will drive engagement with the users over time, that it will be easier to keep everyone in the loop. Once we have our priorities, we needed to get to know our tools. In just a moment, Jeff will take you through all the instant outs of the Workbox library, and he will show how easy with this library our migration became. Once Jeff is done, I will tell you a little bit about how we actually implemented the whole process. I'm going to share some challenges we tackled during the implementation phase and share some lessons learned. So I hope you will find that part really interesting. Finally, at the end of the process, it is important to measure what you achieved. Of course, first of all, we wanted to know our Lighthouse score if it's 100. This is a measurement you do for yourself to know how well you did on the migration, but it's also important for your stakeholders, because it gives a nice, concise, and numerical way of presenting the progress you made on your app. While this number can bring a lot of satisfaction, especially if it turns green and it lights Lighthouse out there, the second type of measurement I put out there, the Google Analytics, is even more important to me, because I think it's very important to check afterwards how your users reacted to the changes you introduced. After all, it's the users that are the ultimate judge of your changes. And this also gives you a nice base to start this process again. Once more, Progressive Web App can be developed gradually and iteratively over time. So you can just start the whole process again, follow this path, and iterate as many times as needed to achieve the optimal user experience. Now, you know more about the business case we wanted to solve, and about the process we followed. So how about we get a little bit more technical? Jeff, are you ready? Thanks, Eva. So before we detail the specific tools that we used, I wanted to provide some background on a web platform technology called Service Workers.  They could intercept network requests, and they could return a response from some cache that they choose or from the network, or they could implement custom logic that mixes and matches where they get the response from. Now, with the right Service Worker in place, we could create a web app that loads in almost instantly and works even when you're offline. But if you're not familiar with Service Workers, it could be kind of hard to picture exactly what's going on, so an analogy might help. You can imagine that a Service Worker is like an air traffic controller. And think about your web app's requests and response as airplanes that are taking off and landing. So let's see how that analogy plays out when your web app makes an HTTP request. So all right, we have this airplane representing request that's taken off. We're making a get request for this image, and now the Service Worker is in control. It gets to decide the route while your request is in flight. And for a URL that we've never seen before, it ends up just going against the network. It'll receive a response just like it normally does. That response will go back to your page. But the really cool thing is that the Service Worker could decide, hey, I actually want to save a copy of that response for use later in a cache. And that's great. So our web app gets a response, and we have a cache copy. That's good to go. So next time a request takes off, same URL that we saw before, the Service Worker's like, hey, I know this URL. I could go straight to the cache. I could give the page a response from that cache, bypass the network completely, and everything looks the same from the perspective of the page. So that's really cool. And that's really what the Service Worker's doing in a nutshell. It's routing where your request will go and having some intelligent logic there. But many people would be reluctant to write code for an air traffic control system from scratch. And I don't blame you. But while the Service Worker API isn't quite as complex as that, there are some subtle issues that you could easily run into. And problematic service worker code could lead to things like delayed updates or missing content in your web app. Just like buggy air traffic control code could lead to flight delays or even worse. So the Women Techmakers Service Worker Implementation uses a brand new set of tools that we're happy to announce today. And it's called Workbox. And you can find out all about it at workboxjs.org. Happy to see people taking pictures. I'll give you a chance for that. So I'd like to walk you all through some of the common Service Worker use cases and show how Workbox helps you avoid subtle problems that you might bump into if you build everything from scratch. All right, so first up, most Service Worker implementations start by adding all the critical assets that they need to a cache, making sure that they'll be available for later reuse. And this is referred to as pre-caching. So here's some basic Service Worker code that waits for a given version of a Service Worker to be installed, and then pre-caches a list of URLs. And this is the sort of thing you might just find is some sample on the internet and copy and paste and maybe even deploy right away. But there's some pitfalls that become apparent as you release newer versions of your web app or add in additional assets. So one thing is you need to remember to manually bump that version variable each time you change anything, or else new assets might not get pre-cached. And you also need to keep updating that array of URLs that reflect your asset's current file names. And that's particularly tricky when your URLs contain version assets, like you see there, sorry, version hasages, like you see there with the JavaScript and the CSS files. And if your site could be accessed via slash or via index.html, you need to have cache entries for both. Forgetting to do any of that could lead to a Service Worker that continues serving still content or just doesn't have a fully populated cache. So instead of going it alone, you could sidestep those pitfalls by using Workbox. It integrates into your existing build process, whether using Webpack, MPM scripts, Gulp, or in the Women Techmakers case, Grunt. So let's take a quick look at how Workbox implements pre-caching. There's a single method, pre-cache, that takes in a list of files and all of their revision information. We call this information the pre-cache manifest. You can see our source Service Worker file here, which is just a pretty empty pre-cache manifest, not doing very much. The nice thing is, though, in this source file, we don't have to hard code a really hard to maintain list of URLs or anything like that. We could keep it empty. And the goal of the build process is to figure out what should go into that manifest. So our final Service Worker file will have that empty manifest replaced with a list of URLs, along with versioning information about each URL. Workbox ensures that all of your pre-cache files are available offline using the revision info in that manifest to keep them all up to date. All right, let's take a closer look at the build process that we're using to get that final Service Worker file. And here we're using a method called Inject Manifest, which is part of the Workbox build module. We pass in the source Service Worker file, and that's the one that has that empty manifest. And we tell it where to write the destination file, and that will have the fully populated manifest ready for use. The nice thing is, we could use wildcard patterns to tell Workbox which files we want to be pre-cached. So whenever we add or rename one of our files, we don't have to remember to manually update the list of URLs. And there's also no longer a need to increment a version variable. Workbox handles versioning for us via the revision details in the manifest. We also tell Workbox that our site responds to requests for the forward slash for the contents of index.html, so we don't end up having to pre-cache two separate entries. OK, so that's only one part of the picture. In addition to pre-caching, it's really common to use runtime caching strategies for resources that are either used infrequently or just too large to pre-cache. You might, for instance, use runtime caching to handle requests for images that aren't needed for every section of your site. Here's some boilerplate code that implements a runtime caching strategy. It fetches a response from the network, but first it saves a copy of the response in the cache. It's the sort of thing, again, you might copy and paste from a sample on the internet. And it's very similar to what we saw illustrated earlier in that air traffic controller example. But the subtlety here is that while your code will add entries to the cache, there's actually no code that's going to clean up those entries when they're no longer needed. So think back to those airplanes delivering the image files to the cache. So they're going to keep landing in the cache with more and more images. And our air traffic controller isn't going to do anything to stop them from piling up. In practice, this is a sort of code that will lead to cache responses that build up over time, which waste storage space in your user's devices. And that's only one half of the picture that with runtime caching. Once you defined your caching strategy, you need to tell your service worker when to use that strategy. That's called routing. And here's some boilerplate code that checks whether it's a request for a URL ending in PNG. And if so, it uses that runtime caching strategy that we just described. And for a very basic web app, that might be fine. But things get out of hand pretty quickly if you need to implement different runtime caching strategies for different type of resources. You end up chaining them all together in a big if else block. And that just really doesn't scale very well. All right, so let's see how we're using Workbox on the women tech makers site to handle runtime caching. So there's a number of features that lead to clearer, more concise runtime caching code, as you could see there. First, we have a built-in router. And this takes care of responding to requests when certain criteria are met. And here, we're using a regular expression as a criteria for what triggers our routes. Workbox has built-in support for common caching strategies. So we don't have to write or more likely copy our own response logic. They're ready to use right out of the box. But Workbox goes beyond the basics, allowing us to customize the built-in strategies with powerful options like specifying exploration policy for a given cache. Workbox will take care of cleaning up old entries automatically instead of them being saved indefinitely on your users' devices. So going back to our airplane analogy, our air traffic controller knows how to clear out the previous planes to make room for new ones. And so let's just take a look at the impact of adding Workbox to the site. So as you can see in the screenshot in the DevTools network panel, even if a user's device is completely offline, all the responses we need come from the service worker, giving us a progressive web app that loads in under a second. You no longer have to build a native app to get this kind of speed, reliability, and network independence. So that's great, but we don't have to stop there. Workbox also offers a number of built-in features that go beyond caching. And I'd like to highlight a couple of them that the Women Techmakers site is using. First, Workbox makes it easy to add and support for offline Google Analytics. All it takes to turn it on is a single line of code. Once enabled, Google Analytics requests that are made when the network is unavailable will be automatically queued up on your users' devices and replayed when the network comes back. This means that the Women Techmakers team won't lose out on valuable insights when users access their PWA while they're offline. Workbox also helps you follow user experience best practices. So using a cache-first strategy means that your PWA could load almost instantly, but it also means that your users will see previously cached content on their next visit, even if you've deployed an update to your site. So a really common UX pattern to follow is displaying a little toast message, like you see at the bottom of the screen there, letting your users know that if they refresh the page, they'll see the latest content. And Workbox makes it easy to follow this UX pattern by broadcasting a message to your page when there's an update made to one of the caches that it maintains. And this message includes important context, like the URL of the resource that was updated. And this gives you the flexibility of ignoring updates of less important assets, like some random CSS file, while prompting the user to refresh when something critical is updated, like the site's main HTML. So that's just a small overview of what Workbox can do. We hope that you find Workbox equally useful when you're building your own progressive web apps. It's available for use today. We're 1.0. And examples can be found at workboxjs.org. I really want to offer a special thanks to Eva and the Women Techmakers team for being an early adopter of the library and for offering tons of valuable feedback along the way. Thank you for that. All right, back to implementation. But first of all, thank you, Jeff, for walking us through the library. And thanks for implementing it in the first place. It saved me a ton of time. I actually think it made me delete more code than I added in the first place. OK, implementation. The first takeaway I wanted to share with you from the implementation process is that going for a progressive web app is a great audit opportunity. And not only because Lighthouse will list all of your performance since anyways, but because when you're planning to implement offline, especially if it involves caching some part of the website on users' device, you really need to be respectful of users' resources, like bandwidth or storage space. And you don't want to push to users' cash a bloated website, unnecessary assets because it's a waste. Making the site lean and resource-friendly should be a priority. And it makes it more usable to all users, not only the ones using the offline mode. And often, it's really not very hard. Usually, you can find some easy fixes and pick the lower-hanging fruit to start with. That's what we did with women tech makers. Let's look at the example. This is the network panel for women tech maker site. What I did here, I just sorted all the assets the old page was using by size. And only by looking at the very top of that list, you can easily spot easy targets for optimization. The bigger the file, the higher chance you can optimize. Here you can see the two biggest files by far are the base.js, which was part of the YouTube API JavaScript file, and the header, which is this nice big hero image on the home page. So can we optimize those? Let's start with the image. It covers the full header area of the page, so it should be as big as the viewport, at least. But it doesn't need to be bigger than that. So if the viewport is smaller, you can make the image smaller. What I did here, I just created two more versions of that image, a medium-sized one and a small one. I added a few breakpoints in my CSS so that it uses the appropriate image for the appropriate viewport. And look at the stats. It allowed me to save 21% on overall image load on that page, with how many nine lines of code if you count brackets, right? So imagine this was the game just from one image. Imagine what would happen if you do it for more of your images on the page. It's a really easy fix. Now, YouTube API. Over the lifespan of your page, the libraries and the resources you're using might change. The new ones come up, some become obsolete, and so on. In this case, everything that we were achieving through the YouTube API now is possible to do with an iFrame when it's configured properly. So by embedding YouTube videos on the page with iFrame instead of YouTube API, we could just delete that file. And suddenly we gained 400 kilobytes of the overall page weight. And if we didn't make this decision to go for a progressive web app, probably we wouldn't even spot that there is this opportunity. So it's a good moment when you go for a progressive web app to stop and think again about resources you're using. Similar thing, the Lowdash library. We were using only some basic functionality of the library, so we were able to replace Lowdash with Lowdash Core. And this brought us from 24 kilobytes to 4 kilobytes. You might say that 20 kilobytes is not that big, but this really adds up in your whole page. And again, here I changed only five characters in my old code. And that's the game, right? So it's really easy to get that. Now, once we ensure that we're not pushing to big resources to the user, it would be good to also make sure we don't push things twice if we don't need to. For that, we need to leverage browser caching. And this is different caching from service worker caching. It's just regular browser cache. Every browser has it these days. So in the old site, what was happening, with every build of the site, we would version files, or cache bust, if you will, by the build number or by timestamp in some cases. And this is kind of uncool, because every time we made a new build of the site, the file would get a new name, even though the file itself might not have changed. That would prevent the browser from caching it, because the browser doesn't know that under different name, it's still the same content. So instead, we switched to content-based caching, as you see in the lower example. Now, we make a hash of the content, and we embed it in the file name, which means the file will get a new address only if the actual content change. So this allowed us to push less resources to the users. And remember, women techmakers is a community. A lot of people are coming over and over to the page over the lifespan of their contacts with women techmakers. OK. So a lot of this type of gains are really findable in your Lighthouse report. If you dig deep, you will find a lot of good practices and good hints embedded in that report. So just by following the red color, you can find a lot of optimizations that would make the site better for all of your users. Now, the second takeaway, and it's going to be quite a journey, so be with me on that one, is about rethinking your site resources, but not from, like, performance perspective. Let's say your site is nice and clean, and it's time to think what to cache and when so that users can use your site offline. We call it a caching strategy. And for coming up with the right caching strategy, you really need to understand your site resources, like images, media, and content. Let's look at the example. This is the Women Techmakers site as loaded online. It's a rich visual experience, lots of images, lots of graphical effects. It's really a beautiful site. What would happen if we saved all of the images from all of this site to users cache? It will just become really crowded. Imagine the user wants to, you know, browse a lot of websites on their device. If each of the websites downloaded all possible images from the whole app, that would make it really inefficient. So the question is, are they really necessary, the images? Maybe they're not at the core of the site. Well, that's how it looks like without images. It's kind of ugly. But apart from being ugly, the site is also unusable. Like, you can't even click to go to different page, which means it's entirely broken.  You need to find a middle ground somewhere. So how do you find a middle ground? Well, I started to think about images by the function they have on the website. Let's go color by color. The yellow ones are images that are for navigation and the images that allow user to perform some action. And this means they're super important. If they're not there, the user cannot really use the website, they cannot perform the action, they have absolute priority. Now, the red ones are the ones in our case that were related to branding, but in your case it might be different.  These might be images, for example, that create the connection between your app and the user, like for example something that allows your user to understand what type of app they're using. So these are your priority images. To the contrary, the blue ones are purely decorative. They're cool, they make the website look nice, but if they're missing, it's not the end of the world. Now, the green ones are kind of funky because I call them informative images. What I mean by this is that apart from adding to the visual side of the story, they also convey some message. In this case, they tell you which of the companies featured content, right? So I call them informative because apart from being visual, they also convey a message. Now, what would happen if we apply different caching strategy to different type of image? The inline ones, the navigation and action ones are super important. So what I did, I just inlined them. Because they're small, they're icons, I just encoded them in SVG and I put them directly in my HTML. This means I don't even need to think about caching strategy because if HTML is there, the images are there, and I'm done. Easy fix. Now, branding and priority, I pre-cache. And you saw that with Workbox, pre-caching is pretty straightforward. Those are images that I always put in users' cache because they're really important for my user's experience with the app. The blue ones, I cache at runtime. This means that when user enters the particular part of the site, I cache them on a kind of best effort basis. So there is no guarantee there will be in the cache when the user re-enters that site in offline mode. I also put a limit so that they don't build up forever. And this means that they might be in the cache and serve their purpose, or they might be missing. What happens if they're missing? Well, the site is slightly less visually attractive, but it's not the end of the world. Like the site is still usable, the content is there, you can check your events, and so on. Now, informative images are super cool because they show you the full power of service worker. What I wanted to do here, when the image is not in the cache, I wanted to serve some kind of a placeholder that tells user, well, there was supposed to be an image, but it's unavailable. But I also wanted to convey the message. So I was using the alt tag of the images to read what company it referred to and try to render this image in service worker. And that's the cool thing. That service worker is just a JavaScript file, so you can do all kinds of crazy rendering in there. Like here, I'm creating an SVG with the offline icon, and I attached the name of the company so that I don't really store anything. Those images were never in my cache. I just rendered them on the fly, and they still serve the purpose of the website. So those are the four caching strategies I used with the help of the Workbox Library on Women Techmaker. And the truth is, your sites, your projects might be different. And you might need different caching strategies, but it should show you the direction you should go for. With the flexibility of service worker, you can find a strategy that would be best suited for your user's needs. Now, let's say we implemented all this offline and progressiveness on our app. What I wanted to tell you from my experience with this migration is that these things really influence other parts of your app as well, and you need to remember about that, because if you forget, then you'll get in trouble in the other parts of your app. Remember the little toast message that Jeff showed you when there was new version of the app? This is the type of influence on the UX I have in mind. You really need to think how going offline influences your user's UX and respond accordingly. For example, there might be a form on your site that you actually cannot submit where you're in offline mode, so you need to remember now that, OK, it's not enough to dump everything in the user's cache. I also need to remember to implement something to tell user, oh, sorry, you can't do this while in offline mode. The second thing is to measure your impact. Some of the interaction with the user will now happen in the offline mode, so you need to add offline analytics tracking. And you saw in the work box that it's just one line of code, but it's your task to remember to put that line in your service worker and not forget about it. Finally, developing offline first can change your developer workflow, and here are some hints that I found useful during development. First of all, it is useful to have two different service workers for different environments. We separated our development service worker from the production service worker, because in development, we didn't want anything cached, like you want to be able to refresh your page and see your changes. So we just had an empty service worker, like an empty file. Because service worker is a progressive enhancement, it doesn't harm that it doesn't do anything. It's just transparent for all the requests. And then in production, we had a fully fledged service worker that does all the caching. So that's the solution we used for separating environments. Now, when you're developing offline interaction working with the service worker, you often want to see how your page would look like for a user that enters the site first time. And if you keep refreshing, that's not that easily achievable, so for that, the best solution is to use the incognito mode.  Incognito is your friend. And finally, I just wanted to reiterate that you should really use build tools to version your files. Trying to do it by hand is just asking for trouble. And because the Workbox build process is just an MPM module, you can usually integrate it with whatever workflow you have there. So really use tools in order to avoid manual fiddling with the cache entries. What happens if there is no service worker at the user's browser? What the cool thing is, there is no problem. All of the stuff we discussed here is progressive enhancement, which means users that do have service worker available will get some more features, some more robust behaviors like offline experience. But even the users that don't have it will get a lot of gain from your progressive web app because of all those other fixes you did on the way, because of the better normal caching, better performance, linear website, and so on. So I really encourage you to consider a progressive web app for your web projects, because in the end, it will increase satisfaction for all of your user base. Did we implement everything we wanted? Well, no. There's always more. And there are improvements that did not make the bar. Here is an example of a few of those that we plan to implement in the future.  And as long as Natalie, the boss of the Women Tech Merc, allows us to work on it, maybe we'll get them implemented with the next iteration. All right, so let's recap a bit. I told you today a little bit about Women Techmakers. I told you about the migration we attempted. I told you how the process looked like for us so that you know where to start on your own. Jeff walked you through the tools, the workbooks library, and we shared some lessons learned around Perf about resources prioritization and about the development workflow. I hope you enjoyed that. Now it's your turn. Go and start your own progressive migrations. Yeah, so what's next? Where are some good places to go? We put together a lot of really great PWA guidance on developers.google.com. We hope you check that out. Hopefully everybody's inspired to use Lighthouse, either in person in the sandbox, or you can just go and get the extension for yourself. You can find out more about that at developers.google.com as well. And I hope that folks try Workbox. Give us feedback. We're really looking to talk to more developers about it as well, so you can find us in the sandbox in the libraries and frameworks section. Some of us who worked on it are here as well. It wasn't just me. And Workbox.js.org is the site for that. Yeah, and remember to join the Women Techmakers movement and remember that all genders are welcome in the movement. So join us. And thank you. All right, guys. Thanks a lot.


Please welcome to the stage Executive Director of the Linux Foundation, Jim Zimlin. Hello, good afternoon. For those of you in the back, we've got a few seats over here, and I think we have some over here. We're kind of tight on seating here. So if you have someone trying to get in, please allow them to get in. Welcome to the Open Networking Summit 2017. We've got a great lineup this week, an amazing set of speakers and content and hackathons and all sorts of good stuff, and it's a tremendous year. I'd like to first start by thanking our sponsors, Intel as our Diamond sponsor, Platinum sponsors, Amdox and Huawei, and our Gold sponsors, Dell, EMC, and Ericsson. Another quick announcement, if you need any assistance, please contact the registration desk. We have lots of different tracks going on. If you get a little bit confused, go ahead and ask them for help. So I thought I would spend a few minutes at the opening here, talking a little bit about where we are as an industry and about some of the things that have been going on in 2017 in open source and networking. And I want to start by saying, and tipping the hat to John Gage of Sun Microsystems a long time ago, that after 25 years, this is now actually true. The network really is the computer, and my favorite story about this is one that was relayed to me actually last week by a gentleman named Min Jun, who's at Facebook. He works on their telecom infrastructure project, which is a really cool open source project around telecom infrastructure. He said that at Facebook, you have this six month boot camp, where all the engineers who work there come in, they take this six week boot camp, and they learn all about Facebook's infrastructure. And then after that six weeks, they go and sort of find a home in the different groups within Facebook, on the application side or whatever. And a few years ago, nobody wanted to go over to the network engineering side. But that now, that really the network is where all the action is happening. It's programmable. It really is this incredibly dynamic, software-driven piece of their infrastructure that tons of engineers now want to go there. And I think the same thing is happening across the industry, that the network now is this rich, managed, programmable orchestration tool that's driving so much of cloud computing. And open source is certainly a huge part of that. Just at the Linux Foundation, we've seen an explosion in the last five years, the number of open source projects around the networking sector. Our most recent project, the Open Network Automation Platform, is a management and orchestration platform that is in production at companies like AT&T. In fact, the Open Network Automation Platform, this MANO project that we have, it's even bigger than MANO, has representatives from China Mobile, China Telecom, China U-Com, Bel-Canada, AT&T, and others, essentially representing 40% of the world's mobile subscribers. This is open source code, production grade, and I can kind of keep on going. And it's not just at the Linux Foundation. Open source is all over the place, whether it's at the open compute project, at the hardware level, I already mentioned the telecom infrastructure project, things like the open source MANO project, the open networking foundation, you name it, there is lots and lots of code out there for everyone to play with and build really interesting solutions around. And today we're welcoming another project to our roster. The DPDK project is now housed at the Linux Foundation. We have a big set of supporters who are backing that project that we're announcing today. And you can see and you will see even more work going on here to allow for data plane service acceleration through this important critical project now at a neutral home at the Linux Foundation. We're also announcing free range router, an IP routing protocol suite for Linux and Unix platforms is home now at the Linux Foundation. And you can go to our website to find out more about this exciting project and all of the investment that will help there too. So all of this is good. We've got a lot of code out there, but it does create a problem. Lots of code, but not a lot of time. You see, there are millions of open source projects out there, right? I mean, it's not just even in networking, it's at every layer of the stack. GitHub alone hosts 54 million open source projects. The real question for all of you is there are all these projects, there's all this code. The real question is which ones really matter? Which ones should I invest my time in? Which one should I invest my career in? Which one should I take a meaningful commercial dependency upon? That is the real question that we want to talk about this week at ONS in particular around networking. And at the Linux Foundation, we think that projects that you can bank on, whether it's in networking or anywhere else, are projects that have sustainable ecosystems. This is the thing that you should be looking for. An ecosystem where you have a really good developer community from a diverse set of stakeholders who create great code, provide true value, which creates profit. If you're a company and you use that code, it could be cost savings. If you're a government, it could be transparency. And then that value creation is then reinvested back into the project. It looks like this. This is what all of the networking projects, whether it's ONOS, CORD, Open Daylight, OPNFV, you name it at the Linux Foundation, are all looking to achieve this same thing, working with the industry and developers to create sustainable projects that will endure for a very, very long time. And so the big theme for this week is how do we overcome the remaining challenges in the networking ecosystem to create these sustainable ecosystems? Well, the number one thing is it's the code. Without good code, you're not going to have any outcome at all. We still need to keep our eyes on building developer communities around all these projects that will solve really tough problems with really well-written code. But in addition to that, we need to harmonize these projects. That's one of the big themes this week at ONS, is how do we harmonize up and down the stack if we have three or four different projects at every, whether it's at data plane services or all the way up to mono, how do we harmonize those? How do we create a set of common APIs, configuration language and so forth so that this code works more effectively as a broad solution as opposed to an individual piece part? And it's not just that. The industry is going through a big cultural change. This is most predominant in the networking sector. You know, I was just at Mobile World Congress and I met with over 50 organizations. It was an incredible week. And none of those organizations, whether it was a global operator or a product vendor or a cloud service provider, wanted to talk about specific technology. They all wanted to talk about change management. How do I retrain the 20,000 network admins that I employ today to be software-defined networking DevOps professionals? How do I teach them how to code? How do I teach them about this new technology? How do I retrain, restructure my workforce to do that? This is going to be a critical challenge for in particular the networking sector because it's sort of over-invested in a way that will be challenging to convert to this new SDN world. So that's one of the things we really want to focus on and we're going to talk a lot about at this event. In addition, we need to continue to teach organizations how to manage open source, how to participate in these communities, both from a technical perspective but also from a legal and a business process perspective. How do you pull code in, share what you want to share, keep what you want to keep, how do you make that process work? This is something that we really want to focus on and will help us build this great shared technology asset together. And then finally, the last thing we need to do in networking that we're going to be talking about a bunch this week is harmonizing the process of standard setting and open source development. Open source development is now one of the leading ways where we create code that interoperates across a wide variety of networks but standards will still be critically important and you're going to hear from the folks at the Linux Foundation about efforts we are working on with the Metro Ethernet forum with IEEE, with other standard setting bodies to make sure that standards in code can exist harmoniously. These are big things that if we do them we can build an incredibly strong shared technology asset for networking. And so I hope you enjoy this event this week. I hope you learn a lot and we hope to see you back again next year. I want to thank you for attending and introduce our next speaker, who is a very special person. Many of you know him. Come on up, the executive director of ONF GuruPolicar. Good to see you. Guru, before you get started, before you get started we actually have a surprise for Guru. That's right. Come on out. So Guru, many of you probably know this if you've been attending ONS for a while, but this is the guy who started the Open Networking Summit years ago. But more than that, Guru has really been one of the people who has driven the concept of SDN throughout the industry. A tireless engineer, supporter, architect, leader. It can be said that he's one of the founders of this movement and in recognition of years of work, we wanted to give you this small token of our gratitude. Please give a hand to Guru Policar. Thank you. Thank you so much. Very nice of you. Really appreciate it. I didn't expect, I didn't know this, so I'm really touched and really appreciate what you've done. All right, you have to hold that your entire talk. Thank you. Thank you, Guru. Thanks. Again, thanks, Linux Foundation and Jim. So again, good afternoon and welcome to 2017 Open Networking Summit. As Jim mentioned that we have a very exciting program for you for the next three, three and a half days where we will try to showcase all the progress we have been making as a community in open networking, open source, SDN and NFV and so on. What I want to do is to take a few minutes to talk about the ONS journey and the SDN journey so far and what to expect going forward. So as Jim mentioned, actually Nick McEwen, Dan Pitt and myself started Open Networking Summit in 2011 at Stanford University and then last year we agreed to make Open Networking Summit a part of Linux Foundation as Open Networking was becoming more and more about open source and so that was the right thing to do and this year we completed the transition and you can see that this year it is completely a Linux Foundation event. During all these years, ONS has remained as the premier SDN open networking, open source networking event for all this time and I want to take this opportunity to thank you all for all your support as well as participation in Open Networking Summit for all these years. Also, more importantly, I want to both congratulate you and thank you for all the progress we have been making as a community about open networking, open source, SDN, NFV and so on as Jim mentioned. I also want to of course thank Jim and Linux Foundation for taking over ONS and taking it forward in a significant way. There is one more person that I want to especially acknowledge, her name is Sadef Askan, I don't know whether she is here in the audience so she has been my partner in Open Networking Summit for all these years and responsible for ONS operations and I could not have done ONS without her and maybe part of this whatever award I got from Linux Foundation belongs to her as well. So with that, let me turn my attention to the SDN journey. So until a few years ago, our industry can be best described or defined by what can be thought of as closed, proprietary and vertically integrated systems that inhibits innovation and that made that contributed to network operators high CAPEX and OPEX and network operators inability to create new services and create new revenue streams for them. As Jim already mentioned, we have made tremendous progress during the past several years and that progress can be best described or defined by disaggregation, disaggregation of networking devices, softwareization and virtualization that is programmable control planes, programmable forwarding planes as well as network virtualization and network function virtualization. And finally, of course, open source, emergence of many, many open source components and open source platforms and another way to look at this and I think Jim already covered this very well but at the bottom most, we have merchant silicon which can give you very high performance but as well as can give you programmability then we have these white boxes with open source component that can be used in production networks then you know SDN controllers then network orchestration and management and then all kinds of virtual network functions and services some open some closed. Now, so far when we think about disaggregation and open source, we think of it in terms of data centers and cloud providers. It is true that that is where disaggregation and open source started and have the biggest adoption so far but to me, the most exciting and most interesting thing about open source and open networking is this particular trend of disaggregation and open source is taking hold in all these markets that you see and that is together is pretty big and very significant and offers a lot of opportunities as well but as Jim also mentioned when you look at all this disaggregation when you look at all these open source platforms and you think about yourself as a network operator or even a vendor if you want to build integrated solutions and deploy them in the production setting doing that with all these building blocks and all these open source components represents a significant challenge and I will say that is our grand challenge for our industry today. So what we need more than anything today Jim already mentioned about harmonization and that is definitely very, very important. Another thing that we need to do is to now think about how we can build integrated solutions that can leverage network device disaggregation and many open source platform and deliver an integrated solution that is easy to consume and easy to deploy and finally, again as Jim also mentioned we need software defined standards that make it easier to plug and play as well as provide interoperability among all these different open source building blocks. Now if you don't mind I want to quickly tell you about what this open networking a new open networking foundation is doing which is a combination of ONF and the open networking lab. What we are trying to do with our mission is to help network operators and service providers transform their infrastructure into a platform for service innovation because that's what they are wanting to do that's what we want to make it happen but by leveraging this network disaggregation open source platforms as well as software defined standards and what we want to do is to help build integrated solutions that are easy to consume and deploy and then drive them through lab trials to field trials to production deployment. And as we do that we have an opportunity to build what we are calling software defined standards because once we have operational software and we are putting together in solutions and we are putting together with other open source building blocks we have an opportunity to define these standards that specify either APIs data models information models about how you can plug these open source components together and that's what the opportunity is and what we are trying to do and finally the idea is that if you are a vendor or a company we want to make it easier for you to plug your innovation into this end to end open innovation pipeline and make it easier to move that innovation all the way into customers production network with significantly reduced R&D investment as well as significantly lower time to market and that is the kind of value proposition we want to bring to the vendors. Now I want to give you a few examples the good news is that at open networking lab and open networking foundation there are few open innovation pipeline that are already in place for few big markets like broadband residential access mobile access enterprise wide area network and packet optical networks so if you look at the work we have been doing with onus and cod and some of the use cases and solutions that we have been building it turns out that we have created multiple open innovation pipeline as an example if you look at residential cod in residential cod if you look at the hardware infrastructure we bring white boxes for OLT devices for G-Pon we use white boxes for leaf spine fabric we use of course servers those are white boxes we build the coherent hardware infrastructure on top of that if you look at the software stack that software stack is built with many open source building blocks all the way from open stack Docker onus as an SDN controller then XOS and then many virtual network functions that are implemented as services that are managed and orchestrated by this XOS platform so and we are already putting this all together in a solutions form and some of this is going through lab trial and field trial and hopefully in a production deployment in multiple service providers before end of the year we are doing the same thing for mobile cod applying that to radio access network mobile packet core as well as the mobile edge computing and then we are doing something similar for enterprise card and the packet optical networks as well so we have this multiple innovation pipeline that are creating solutions that are easier to deploy now clearly ONF is not doing this in isolation we have brought two large ecosystems ecosystems of ONF and open networking lab there are like 200 companies with number of leading service providers software vendors, system integrators that are all coming together and working together on this particular thing and the idea is that we want to help service providers create platform turn their network into platform for service innovation and we want to help vendors take their innovation and move it into production network of their customers very quickly by reducing R&D cost as well as time to market ok now all of this is well and good but there are couple of challenges that we are still experiencing the first thing is when you talk about taking something to production readiness and deploying something all the way into the production network there is a significant amount of investment and skills that are required and when you look at many open source projects including open source project that are going on at for example ONF or other places we are able to create enough proof of concept lab trials maybe couple of deployment but that is it if you really want to do this for production you need significantly more investment and you need significant resources and you can see there is a resource gap and the question is who is going to make this investment where is how are we going to plug this resource gap specially given that there seems to be a major misalignment of incentives if you look at network operators yes they want to build open source SD and NFE networks obviously leveraging network disaggregation open source and all of that however they don't necessarily have enough development resources and they don't have investments to make to be able to do it on their own now if you look at vendors yes they have established products they have processes they have revenue stream they have large pools of developers but this whole network disaggregation and open source is quite disruptive to their business model now system integrators they see lot of opportunity with network disaggregation and open source but again they don't have necessarily the expertise, resources and investment to be able to make this work so what that means is that if the incentives are not aligned that leads to insufficient investment that means we cannot take some of this to real production deployment and really bring about the change we want to make so that is something to think about because as much as we are excited about all the progress we have made this is something to be thinking about so my last slide so what you have is yes we have made tremendous progress with disaggregation, softwareization and virtualization open source and we have lot of exciting work ahead of us in terms of harmonizing integrated solutions and all that but what we have to keep in mind is we have to find a way to align incentives create sufficient investment and that will lead to production deployment and that is the only way we are going to really bring about the kind of change we all are here for and what we hope for and again at open networking summit over the next three three and a half days hopefully you will see some of this in action so come and check out and then of course you will get to talk about some of these as well so again thank you so much really appreciate your participation our next speaker is Arpit Joshipura who is new to Linux foundation he will introduce himself alright excited to be at the Linux foundation and your host for this ONS let me tell you what we did when we joined or when I joined the Linux foundation you know I have been in your position I have been you know that right where Michael said I have been an attendee I have been a participant an exhibitor a sponsor a keynote speaker so I understand what we need as an audience and so we went back and looked at all your feedback and so of all the six years and so this ONS is designed based on that and let me tell you why we believe networking is cool again let's go and first tell you who is here and my goal today is just to tell you how you can make your time efficient that's it I am not giving any pitches there is an equal representation from service providers also known as carriers, cloud and enterprise we have about half and half technical as well as business architecture in terms of the attendee power in the audience we have a third that work and the other two thirds that make decisions not quite but that's kind of just the breakdown let me tell you a little bit more all of the major enterprise verticals are represented in this ONS where we have proactively requested a lot of enterprise presence and you can see why there is a lot of convergence between cloud, enterprise, carriers the boundaries are blurring so we have the top enterprise verticals whether it's financial, manufacturing, healthcare business etc of course all the vendors who supply to the enterprises are here we have keynote speeches from the top we have carrier infrastructure vendors in fact all of them we have the top five service providers here and most importantly as Jim alluded to in the audience if we don't align properly half of the global mobile subs will be impacted that's the power of this room so the quality of people we have today is just outstanding so take advantage of that in the hallway conversation and make sure you at least ping your neighbor on what they do let me give you a sneak peek at some of the keynotes they are insightful and visionary if you need to understand the role of networking and how 129 billion transactions are carried out just wait for 30 minutes Justin will be here and then we have all the buzzwords containers 5G, IoT so let me tell you one progress as a community we should all be proud of is in the next two years all our acronyms have moved from three letters to two letters AI, BI, CI, VR, AR you name it 5G so that you should all give yourself a round of applause for that just kidding we have another very interesting vertical represented here what does network do to transport all these passengers we all travel but how do you what's the data center networking's role listen to that this is a very different perspective and it's not just VLANs and IP addresses and port numbers we've done that before we've all been geeks there's another one networking is used and this is open source networking to solve cancer this is very interesting how do you do that get the behind the stories from how did two of the largest world operators come together AT&T and China Mobile Jim mentioned the own app project one thing is the architecture but the other thing is the culture how do you bring those communities together and of course you'll hear a lot about 5G one key takeaway if you remember nothing else 5G mandates network automation you can't have a smart meter on a call with an operator trying to register on a network it's not going to happen just remember that and there's a lot of that over the course of the session as far as the tracks are concerned it's a very simple algorithm there are five tracks for your inclination you can either go to a general track these are hardware and A6 and security in a basic common building blocks or you can take a carrier track or an enterprise cloud track and within that you're either a developer or you are a product management CTO architecture or you can take a carrier track so feel free to again you can cross boundaries but we have adjusted it so that it doesn't compete with itself and of course morning and evening we'll have keynotes beyond that we already started with the hackathon that's going to go through the day so do visit that educational tracks I saw most of them it's the most visited thing, the awards reception you name it last slide I want to show is there's a lot of announcements that'll go on but from a networking perspective and an open source networking which is what I own we're really proud to announce today one of our leading operators Reliance Geo from India this is the fastest growing over 100 million subscribers they just joined ONAP and just stay tuned I know I've gotten a lot of questions on when ONAP is going to be open to the community we're just doing a rebranding naming change just stay tuned it's happening the other piece of announcement for those of you working on OP NFV and the Danube release let me tell you it's flowing quite well this week and then Jim already covered the free range routing so with that what I wanted to do was bring up two keynotes this afternoon and while I introduce my first keynote I wanted to tell you that true to the tradition of ONS this is the only conference I've been to and I support where you can ask questions in keynotes so if nobody stands up we'll cancel that privilege so I'm hoping that people would have there are mics in the middle just line up and ask the questions to the presenters anything goes just don't pitch a product but otherwise anything goes and so with that said let me introduce our first keynote speaker we all know him so no introduction required CVP from Microsoft Azure networking, Albert Greenberg