Live from the Fairmont Hotel in San Jose, California, it's The Cube at Big Data SV 2015. Hello, and welcome back to The Cube. We're live here in Silicon Valley. I'm John Furrier, the founder of Silicon Angle, and this is The Cube. We extract the signal from the noise, go out to the events and talk to all the folks we can talk to out there. Entrepreneurs, engineers, CEOs of big companies, and we are here at Big Data SV, our event, in conjunction with Stratoconference and Hadoop World. We're here with John Furrier, our next guest is from Google, Eric Schmidt, the product manager, not the former CEO of Google. Love the name. Big smile over there. So Eric Schmidt on the schedule, I just couldn't lie. Welcome to The Cube. Eric Schmidt, product manager, Google's cloud data flow product. Obviously in context to Big Data Week here. Welcome to The Cube. Thank you. Thanks. So obviously Google's, we're big fans of what you guys do in the cloud. Love the scale of Google. Love the developer traction. Kubernetes is awesome, hot product. Obviously in the stack is data, right? You got to do something with data. A lot of hot stuff going on in memory, streaming, all this stuff's hot. Application developers want the data. A lot of stuff being architected. Tell us what's going on with you guys with data flow and how does this all connect in with Google Cloud and what you're doing here? Sure. So I guess a little bit of history. We announced at Google I.O., the past Google I.O. that we were building a fully managed service for parallelized data processing, which was called data flow. And data flow is a synthesis of really two main efforts inside of Google. Back in 2004, we released our thoughts on this concept called MapReduce and then internally continue to build an implementation. If you had only open source MapReduce cloud era wouldn't exist. That's a whole other story. We'll go down there in a second. I was really excited to see just how much momentum and excitement from the community and innovation that's happening. It's so awesome, it's been great. We obviously helped create some of that DNA but the community at large, the open source process has really proven itself valuable in producing the broader Hadoop ecosystem.  Obviously, we're on our work than everyone else. But cloud, even before cloud era became a household name, there was a ton of work done in the open source community within Apache, so that's something that needs to be footnoted, I think. Yeah, and we spent some time in the session earlier this week basically turn it, you know, map our work in MapReduce focused on Batch and then we later released a paper on Millwill, which is a real-time stream processing system. And Dataflow as a product is really a synthesis of these two models. It's basically bridging the Batch world with the stream with the stream processing world both as a fully-managed service as well as a unified SDK. So a data processing, data engineer can sit down and not necessarily have to think about as my data at rest, as my data in flight how am I going to deal with temporal aspects of my data basically bringing to market a unified development model and a unified and fully-managed service. So, talk about that unification key. I mean, data in flight, data at rest these are all concepts that are obviously known but relative to open source one of the things that Hadoop's growing up fast is automation orchestration. It used to be, I mean, it's still kind of a hassle but just a few years ago a lot of work would have to be done just to kind of manage, stand up Hadoop and then you add in complexity of data flowing around north, south, east, west whatever you want to call it that's written critical that automation and to scale. So what are you guys doing to help that? Is that part of the piece? Yes, so the service aspects enable developers to in essence specify the type of boundaries that they would like in their cluster to manage their data. So you can kind of think of a typical on-premise Hadoop implementation where you kind of do a lot of architecture design figure out what type of node structure you want, you go buy, acquire and then rack up that cluster which is great but it's not necessarily the best solution if you have a lot of volatile usage or your business counterparts are constantly calling up the next day and saying hey we need more capacity, we need you to be able to expand. So the service aspects the elastic aspects of the service enable a developer to specify a set of boundaries, hey this is the minimum size and potentially maximum size of the cluster you deploy that cluster into or ask Dataflow to deploy that cluster on your behalf and we will modulate expand and shrink down the size of that cluster to keep up their data rates. Versus dealing with all the hassles of managing elastic things like control plane and all the other plumbing. Exactly, yeah. How do I say it, hassles. Developers just that's DevOps, that's a DevOps concept. It is, but whenever you get into talking to like hardcore and traditional MapReduce developers, they're doing that development but they're also having to put on that DevOps hat. They're operations person, persons maybe that's responsible for their NAS or their storage system. Those guys are usually pretty close buddies because they're having to figure out different sharding techniques for different data sizes, you know volatile changes and key structure and data and our goal is to really help kind of offset a lot of that work. In some cases completely remove it and the concept of auto scanning those clusters is both a benefit and a batch sense so you can in essence improve clock time. Your boss calls up tomorrow and says hey I need this answer but I need it in three hours faster we give you the ability to expand your clusters easily so that you can get questions faster. In streaming mode it's really about dealing with ingest rates of data. If you can't process fast enough then you're going to have lag. Lag then introduces either inaccuracy in data or unavailability of data. So what does data flow target to? Is it target to the developers? Is it targeted to the DevOps guy? Obviously your alpha is at alpha in terms of deploying or coding development kit. Is it for just data jockeys and wranglers? What is the focus all the above? The sweet spot right now is focus really on your data processing engineer. The guy or girl whose task it is to do traditional ETL. Getting data moved from disparates sources and temporary storage locations. Love pipeline kind of thing. Exactly. Getting that data into their data warehouse maybe they're using BigQuery as an example to do a lot of interactive analysis and they have terabytes or petabytes worth of data on GCS. How do you get that data moved? Then you get into more advanced movement like doing filtering enrichment shaping of data. So it's kind of one stack. The second stack is doing analysis either batch, spot analysis or doing continuous computation over that data. So use cases would be maybe you are doing basically classic ETL into your system but at the same time you have some in-flight data that you would like to continuously monitor. Maybe you want to push it out to a monitoring agent so your broader network operations people can kind of see. This is what's happening with my kind of inbound control plane with data and then this is what's happening in real time with user based data. So you can start correlating those two aspects. The third use case would be someone typically maybe higher above those data processing engineers who is trying to synthesize or orchestrate data processing logic across multiple flows. Like you have maybe one process that's all about ingestion of data type A, another process for data type B, data type C, etc. Being able to synthesize or fuse those flows together that represents something meaningful for the business. So it's really kind of three different personas. So talk about the open source piece. You guys have some open source component and also talk about the alpha component that's application driven. You're just submitting applications. You approve all of them. Is there a criteria? It seems like there's like a black box there. Tell us what's behind the curtain. So on the open source side, we open sourced our Java 7 implementation. We pushed that out to GitHub right before Christmas, December 17th I think was the day. That build, the build that's in GitHub is our build. It's the same build that we are building and promoting with the product. We also have a Python 2 implementation in the works that whenever we have it feature complete and stabilized, we will also open source that as well. Subsequently though, since then, several companies have produced Scala ports, which is a relatively straightforward thing to do because they can wrap on top of our Java 7 implementation. We are also seeing some interaction though on alternate runners and the idea would be you would develop in Dataflow. You'd write your code in Dataflow but instead of executing it on our managed service, you could say execute it on your own self-managed Spark cluster. So Josh Wills over at Cloudera who was the inventor of Crunch, he jumped into the mix and said hey, I like Dataflow as a programming model but I'd really like to have it run on Spark so he's contributed and the folks over at Data Artisans they're also building a Flink runner that I think will be out in the next week or two. So that's kind of where we're at in the short whatever two and a half months from an open source perspective. We'd like to see a lot more extensions, inputs, output support, different types of transforms that people are sharing. I think your other question was about how do you get in? If you go to cloud.google.com and say sign up and say apply for alpha type in a little bit of information and myself and some other folks process that on a daily, every other day basis. So is there like an algorithm you guys have in terms of our filter you looking for key words? I mean it's probably a simple vetting process or is it a complex vetting process? In the beginning in the beginning it's controlled alpha essentially it's directed availability on the alpha In the beginning whatever we released in last summer for EAP and I think this is common for most projects like this you are selective mainly because you're trying to control the pressure back on your engineering and the resources. And the team managing it you don't want to open the kimono too fast. But we're in the process now, we're pretty much onboarding everyone that comes through. We did that with our CrowdChat app for a good year. We limited who can do it just to see patterns. We didn't want to get killed by a thousand paper cuts of support. Exactly and then you also start clustering around issues and then you can solve them. I feel on the product management side we feel pretty good where we're at right now in terms of supportability we've hammered on most of the usability issues. So yeah we're actively onboarding. And what's the beta timetable? You're looking out at Google I.O. or next event timetable. Any road map there in terms of I'm going to hold you to numbers. Not like you're going to get fascinated for not making the number. I mean come on, is it like this year second half of the year, you don't know. So I don't have a time dimension in the future that I can or a time a specific time answer that I can give you. The joke that I made yesterday. You're working on it. No the joke that I made yesterday is like if you look at the timeline as we were doing MapReduce, Flume, Dremel, Millwill, etc. And then we basically have been taking lots of that technology to cloud. We released Dataflow in June of 2014 in EAP mode and then we went to Alpha December 17th. So if you want to do some estimation on historical you know I'll work on that tonight. I'll be up all night working on Google's, you know, I'll break this big store up. We are working as fast. The Compute Engine did the same thing you guys. It's the standard operating procedure. We're working as fast as possible to get the market. So what's the coolest thing that you think is going on there? In terms of where you see excited is it the spark piece, is it the pipeline, is it the unification of the programming, is it open source. And what are the people saying about what's the conversation around this? There are several cool things or things that really excite me. One of which is our sophistication or intelligence around our windowing support. Other programming models have the concept of windows basically being able to bucket data into windows. We have fixed windows, we have sliding windows. We've also implemented the concept of session based windows. So if you don't necessarily know a specific key you can ask the system to look at streams of data and attempt to infer this is a start point and an end point for a particular system. Which is great for log processing. You may not necessarily know who the user idea is, but you can look at a pattern. So there's some sophistication there about we've also implemented this concept of triggers and watermarks which enable a developer to specify custom time stamps for input data. This is something that Spark developers are challenged with a lot today in streaming mode where Spark is looking at input data and time stamping it as it arrives into the system. Which is great for a lot of systems, but if you want to do correlation back to the actual event time say on a mobile device or something like that. You potentially have some time drift there. I'm super excited that we have this ability to basically deal with arrival time and or source time and then give the developer the ability to basically control how they want to deal with late arriving data. It begins with a windowing support and we have this concept of triggers and watermarks. You wrap them all together and at the end of the day we provide a high level of tuning to dial in correctness of data. Real time streaming is hard because you never know whenever you have all of your data and sometimes you may never get all of it. So then the question is how do you deal with late arriving data? So that's something I'm really excited about. It reminds me of the old days of TCPIP and packet through networks. It's a network packet problem. You got to know the flows. It's also contextual data instrumentation you need. It's really complex. Well Eric, thanks for coming on the Cube. We really appreciate it. We've got to wrap up that segment. We're getting the hook here from the folks on the timetable. Final word. What do you think about the show here this week? What's the vibe? What have you learned? What's the big aha in terms of the vector we're on, the navigation, the path to the future? What's happening here? I see a massive shift from people moving as fast as way of possible from batch to get to real time. And then the extension of ML applied to real time. I'm extremely excited about that. I've played in the batch processing space for a long time but always wanted to be in real time. I have to ask this because you know that I hate the term data lake because I think it symbolizes slowness and like batch. That's a batch concept. The ocean like Pacific is always moving, it's always changing. And there's different currents, different ecosystems. That's really the big data world in the future. You're going to have that kind of current. It might not stick, not that I care. But in terms of data, it's complex. In real time, you're dealing with that kind of unknown at any given time, a rip current of new things could be streaming. What's your take on that? Do you see it that way? Not to say data, you don't have to agree with me, but that kind of real time complexity can arise just as fast as the benefits. Exactly. And we're seeing that from our customer base whether it's small orgs or start-ups or very large orgs they're dealing with these types of problems. One day they feel like they have some type of consistency around their data processing and boom the next day another part of their organization launches a new game that just has exponentially increased their data rates. Or they want to process new data coming from their marketing organization, etc. This isn't going to stop. In order to get the real intelligence out of their ML processes they're going to need to continue to aggregate. In an ocean which feeds hurricanes, there's tsunamis, there's currents a lot of unknown circumstances have to develop. So in your data flow vision what do we need to build from an infrastructure intelligence and software standpoint to make that predictable so that at any given time circumstances can change, hence the data has to be adaptive and reactive in real time. Yes. Is there any vision on what needs to be in place? I think what you're talking about is actually the core of our fully managed service. The faster that you can get away from having to scale to deal with the operational aspects the more time that you can spend on actually just dealing with the data you're still going to have to shape it. You're still going to have to process it. You're going to still have to run it through different algorithms to pull out the types of data that you want and then potentially train some other ML implementation. That's where I think the real magic is going to happen. That's a lot of new code ideas in there. AI, all this new stuff that people are talking about really good automation. But it's a boom for computer science. It's just going to be magical. Using an analogy, if you can't put your arms around the ocean and even if you could could you hold on to it for long enough and as more water comes into it if that's capable but this is what's happening with these entities, whether big or small if you can do that then you have control over it and you can start doing something with it. You can know what not to do. If it's a tsunami coming or a big storm you don't play in that wars or you adjust appropriately so I think to me I look at currents and streaming and the river, these kinds of concepts that have been network concepts and it's always moving. The lake is a batch. Again, I'm ranting on my data oceans. Eric Schmidt here, validating my data ocean vision. Thank you, this is the first person to support my data ocean at least in principle. I'll put it on my next slide. This is theCUBE where we're right back on the next guest. Eric Schmidt from Google, Dataflow. Great product, great company in terms of scale. Really leading the way. Again, the DNA is all over Hadoop and it's well known so congratulations and always good stuff coming out of Google, always fun. We'll be right back after this short break.


The results of this study suggest that undergraduate nursing students have higher levels of study engagement when they are more confident in their abilities, have a strong sense of purpose and direction in life, and feel that their work has meaning. Furthermore, the study found that these factors are strongly correlated with each other, suggesting that having a strong sense of purpose and direction in life can help to increase confidence and motivation, which in turn leads to greater study engagement. This article was authored by Yuan Wang, Yin Zhu, Tao Li, and others.


from Seattle, Washington. It's theCUBE, covering KubeCon and CloudNativeCon North America 2018. Brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Hey, welcome back, everyone, live here in Seattle for KubeCon and CloudNativeCon. This is theCUBE's coverage. I'm John Furrier with Stu Miniman. We've got two great guests, Chris Wright, CTO of Red Hat, Scott Snedden, who's the Senior Director of Cloud at Juniper Networks, breaking down, winding down day one of three days of coverage here. Rise of Kubernetes, the ride of CloudNative is certainly impacting IT, open source communities and developers. Guys, thanks for coming on theCUBE. Appreciate it. Chris, good to see you again. Yeah, good to see you. Welcome to theCUBE. Okay, so talk about the relationship between Red Hat and Juniper. Why are we here? What are we talking about? Well, we're here to talk about a combined solution. So Red Hat's bringing kind of the software platform infrastructure piece and Juniper's bringing a networking component that ties it together. So we do have a fairly, well, in tech terms, a relatively long history working together. We've had a partnership for a little more than two years on some telco cloud initiatives around OpenStack using the Red Hat OpenStack platform with Juniper's Contrail solution as an SDN layer for these telco cloud deployments. And I've had a lot of success with that partnership. A lot of large and small to medium telcos around the world have deployed that. Earlier this year at the OpenStack Summit in Vancouver we announced an expanded partnership to start to address some enterprise use cases. And naturally, OpenShift is the lead technology that we wanted to tie in with around enterprise adoption of cloud and some alternatives to some of the legacy platforms that are out there. And we were talking earlier in theCUBE here, we always get to kind of the feel of the show. It's Kubernetes maturing, but it kind of two worlds colliding and working together, a systems kind of view, almost like operating systems, but network systems, all kinds of systems thinking, and then just apps, kind of the old app thing. So these are the old legacy worlds that we all lived in, kind of happening really in dynamic ways where the apps aren't thinking about what's below it. This is really kind of where you guys have a tailwind with Juniper, because you still got to make things dynamic, you still got latency on-premises not going away, you got IoT. So networking plays a really big thing as software starts figuring things out at Kubernetes. Let's talk about that. Where is that value? How is it expanding? Because clearly you still need to remove packets from A to B. Yeah. Be more efficient with it. Apps going to have policy. Well, yeah, I mean, you've still got to, the network has always been the foundation of technology, at least for the last 20 plus years. As cloud has been adopted, really, we've seen network scale drive in different ways. The mega scalers that have built infrastructure that we've been enabling for quite a while and have been working with those customers as well. We've been developing a lot of simplified architectures just for the physical plumbing to connect these things together. But what we've seen is more and more important is, it's all about the app. The app is the thing that's going to consume these things and the app developer doesn't necessarily want to worry about IP addresses and port numbers and firewall rules and things like that. So how can we just more simply abstract that? And so we've been developing automation aimed at the network for quite a while, but I think it's becoming more important that the application can just consume that without having to direct the automation at the app. And so groups like the Cloud Native Foundation and a lot of the work with Kubernetes around network policy lets us use Cloud Native Primitives and then we can translate into the network primitives that we need to deploy to move packets, IP addresses and subnets. Chris, talk about the multi-cloud dynamic here because again today, if things are moving around the standardization around some of those core value propositions, we just mentioned about networking and software networks, all kinds of software innovations under the covers. I'm a customer, I have multiple clouds now. This isn't going to be a core requirement. So you got to have a clean integration between it. There's really two things. If you look at a modern application, you got your traditional monolithic application as you tease it apart into components and services. There's only one thing that reconnects them and that's the network. And so ensuring that that's like as easy to use as an application developers focuses around the app and not around network engineering is fundamental to a single cluster. And then if you have multiple clusters and you're trying to take advantage of different specialties in different clouds or geo replication or things like this that also require the network to reconstitute those applications across the different multiple clouds. If you expect your application engineers to become experts in networking, you're just sort of setting everybody up with mis-set expectations. It slows things down, requires all these other tasks you got to do.  You don't want to do it. Stack a bunch of rock moving from there to there. I mean, this is what the holy grail of this infrastructure as code really is. I mean, that's the goal. Help connect the dots for us. When you look at multi-cloud, networking obviously is a very critical component. What are your customers looking for? How does this solution go to market for your companies? Absolutely ease of use is top of the list. So it can't be overly complicated because we're already building complex systems. These are big distributed systems and you're adding multiple clusters and trying to connect them together. So ease of use is important. And then something that's dynamic and reflects the current application requirements I think is also really important so that you don't over utilize resources in a cloud to maintain sort of a static connection that isn't actually needed at that moment. I'm sure you probably haven't- Yeah, I mean, this is the whole concept of SDN and network virtualization and a lot of the buzzwords that have been around for a few years now is the ability to deliver on demand network services that are turned on when the application asks for it and are turned off when the application's done with it. We can create dynamic connections as applications scale and then with a lot of the newer things that we've been doing around control and with Red Hat are the ability to extend those application environments with networking and security into various cloud platforms. So, if it's running on top of an open stack environment or in a public cloud or some other bare metal infrastructure, we're going to make sure that the network and security primitives are in place when the application needs it and then get deep provisioned or pulled out when they go away. Being at a show like this, I don't think we need to talk too much about open source because it's really core and fundamental about what we're doing here. But I guess, how does that play into customers? We've been watching the slow change in the networking world. I'm a networking guy by background. I said, you used to measure changes in networks in decades. And now it feels like we're moving a tiny bit faster. So, yeah, what are we seeing? Well, I mean, the history of openness in networking was the IETF and the IEEE and standards bodies, right? How do we interact? We're going to have our little private playground and then we'll make sure at a protocol layer we can interact with each other and we call that openness. But the new openness is open source and transparency into the platform and the ability to contribute and participate. And so Juniper's shifted a lot of our focus. I mean, we still have our own silicone and the operating system we build on our routers and switches, but we've also taken the control platform, open sourced it a few years ago. It's now called the tungsten fabric project under the Linux foundation and we're active participants in a community and our customers really demand that. The telcos are driving towards an open source model. More and more enterprises want to be able to consume open source software with support, which is where we come in, but also be able to have an understanding of what's going on into the covers to participate if that's a possibility, but really driving interoperability through a different way than just a protocol interaction and a standards body. I can see how Kubernetes would be a great fit for you guys at Juniper, clearly out of the box. You have this kind of inter-cloud, inter-networking paradigm that you're used to, right? How does the relationship with Red Hat take it to the next level? What specifically are you guys partnering on? Where's that, what's that impact for customers? Can you just give a quick explanation, take a minute to explain the Juniper. A lot of it comes down to usability and ease of use, right? I mean, what Red Hat's done with OpenShift has developed a platform leveraging Kubernetes heavily to make Kubernetes easier to use with a great support model and a lot of tooling built on top of that to make that more easily deployable, more easy for developers to develop on top of. What we're doing with Contrail is providing a supported version of our open source project and then by tying these things together with some installation tools and packaging and most importantly a support model that lets a customer have the proverbial single throat to chill. The Red Hat customers, they can run beautifully on your environment. Yeah, yeah, and the installation process is seamless. It's a knob at install time to consume Contrail or some other networking stack and they can call Red Hat for support and they'll escalate to Juniper when appropriate and vice versa and we've got all those things in place. I think one of the things that we have shared vision on is the ease of use and then if you think about two separate systems with a plug-in, there's going to be some integration that needs to happen and we're looking at how much automation can we do to keep those integrations always functional so that if we need to do upgrades, we can do those together instead of abandoning one side or the other and I think another area where we have shared vision is the multi-cloud space where we really see the importance for our customer base to get applications deployed to the right location and that could be taking advantage of different pricing structures and different clouds or it could be hardware features or functionality especially as we get into edge computing and really creating a different view of computing fabric which isn't quite so client server, cloud centralized but much more distributed. I like how you said that Chris earlier about how you decompose that monolithic app it connects with the network. That's also the other way around. Little pieces can come together and work with the network and then form in real time whether it's an IoT data coming into the data center or pushing compute out to the edge. You've got to have that network interaction. This is a real cloud native evolution. This is the core. Yeah and I think another piece that we haven't touched on as much, Scott mentioned it was the security component. So, explain that. Again, as you decompose that application in the components, you surface those components with APIs, those were internal APIs when they're now exposed externally security really matters and having simple policy that describes not just the connectivity topology but who can speak to whom. It's pretty fundamentally important so that you maintain security posture and a risk profile that's acceptable. And then I think it's really important as your traditional enterprise starts to adopt these cloud native models. You've got a security team there that might not necessarily be up to speed or on board. So you've got to have tooling and visualization and analytics to be able to present to them that policies are being enforced correctly and are compliant and all of those things. Yeah, they're tough customers too. They're not going to expect really rock solid capability.  Yeah, surface areas exposed in the IoT space. Now you've got to nail it down. Yeah, absolutely. And so, I mean that's a lot of what we're bringing to the table here is a lot of Juniper's history around developing security products. Take a minute to explain. I want to give you a time to get a plug if a Juniper, I've been following you guys a long time, Juno's back in the old days, Contrail. Juniper's had a software, big time software view. Yeah. Explain the DNA of software at Juniper. You know, the early days of Juniper were, we weren't the first network vendor on the market. There was already somebody on the market in the mid 90s that had a pretty solid stronghold on carrier and enterprise networking. We had to come in with a better model, right? Let's make the box easier to use and simpler. Let's make the interface a little more structured and understandable. Let's make it programmable. I mean, the first feature request for Juno's was to have a CLI because the first interaction to it was just an API call. And that was out of the box from day one. We had to write a user interface to it just to fit into the existing network world in the mid 90s. And so, we've always been really proud of the Juno's operating system that runs on our boxes. We've really been proud that we've had this one Juno's concept of a common operating system on every network device that we've delivered as we've started to virtualize those network devices for NFV and things like that. It's, again, that same operating system that we deliver. Control came to us through acquisition so it's not Juno's in and of itself but still leveraging a lot of those same fundamentals around model driven configuration management, understandable APIs and openness that we've always had. That's not an operating model that everyone's going to. The common operating model fits in that unification vision that you guys have had. Yeah, absolutely. And really early, by the way, that was before SDN was SDN. I think that was SDN's kind of like.  Right, I describe SDN as just a big distributed router and really we've had big distributed routers for a long time. Yeah, John, we are in Seattle. Everything we're talking about in tech is hipster. So. Chris, great stuff. Great to have you on, Scott. Good, great smart commentary. CTO, Red Hat, you guys are winning. Congratulations on the bets you made at Kubernetes early. CoreOS, great acquisition, great team there and some news there around some doing stuff back into the CNCF. So, I mean, you guys got a lot going on. A lot going on. And then I was with big news with the other things. I can't remember what it was. There was some big Red Hat news out there. Thanks for coming on. I appreciate it. Good to see you. All right, just breaking down day one coverage on John Furrier, Stu Miniman. Day two starts tomorrow. Three days of wall-to-wall coverage. You've gone there shutting down the hall. Be right back and see you tomorrow. Thanks for watching.


We should be the change we want to see in the world. Although technology can seem like magic at times, it is actually the inquiring mind that is magical. This week, I think I'm going to get schooled. Looking forward to a great week of learning with Arizona's best. Let's take the fear out of teaching and learning math and make it fun. You are a fantastic teacher for being here and your students are going to benefit from your new expertise. No retreat, no surrender, especially with technology. Go for it. Science and technology are incredible tools with the end goal of learning about our world and ourselves. Ignite the light and be the chalk star you were meant to be. It's often the little things that make the big difference. I'm proud to be a STEM geek. I flip for photovoltaics.


Welcome to the screencast on recursively defined sequences. So we're going to be working with a particular mathematical object in this section called a sequence. So let's define what that is. In math, a sequence is just an infinite list of numbers that's written in order. So it's a very simple structure, but can have some interesting properties. For example, look at this first example here. The sequence 2, 4, 8, 16, 32, and so on forever. We use a sub n here to refer to the nth term. For example, this would be a1, the first term. That's a2, the second term, a3, a4, a5, and so on. So what we often want to do in working with sequences is describe what the nth term looks like. This one is pretty easy actually, if you think about it. The first term is 2, the second term is 4, the third term is 8, the fourth term is 16. It's pretty quick to see that the pattern here is that a sub n is 2 to the nth power. And that's a nice little closed form expression that just simply, you put in the n and it spits out what the nth term of the sequence is going to be. For example, a10 is going to be 1024. Sometimes we don't get as easily described of a sequence as we can. Like check out the second one here. a1 is 3, a2 is 3.1, a3 is 3.14, a4 is 3.141, there's a5, a6, and so on. So what is the nth term? It's kind of hard to describe that as a formula, but it's very easy to describe this in words. a n is simply the number pi taken out to n minus 1 decimal places. To n minus 1 decimal places. So that is a description of the nth term without exactly being a formula as such. And that's okay. Now let's take a look at a problem that's going to motivate a specific kind of sequence that's going to be quite easy to work with using our notions of induction. And this actually comes from every parent has gone through this before.  That's a drug that we all take for fevers and pain relief. It says on the box that a sick kid of this child's weight and age should get 320 milligrams of acetaminophen every four hours. During that four hour period, 80% of the medicine in this particular child is metabolized out of the child's body, so 20% remains. So how much medicine is left in the child's body after five four hour periods and that's pretty helpful to know. Let's suppose just to simplify things that there's only one dose given at the very beginning here and we're just going to let that sit through the child's body without giving any extra medicine. So without actually obeying the rules here, we're not going to actually give the child medicine every four hours. You're just going to give the kid one dose and see what happens. If a kid gets one dose of 320 milligrams of acetaminophen after five four hour periods is 20 hours, how much is going to be left? Well let's go off to some blank pages here and see what we have. So at the very beginning, after no four hour periods have passed, the child has 320 milligrams of acetaminophen in her system because that's the initial dose. So I'm going to keep track here. Here's the amount that's remaining and here I'm going to put after how many four hour periods have passed. After no four hour periods have passed, there has been no metabolization. I still have 320 milligrams. Now after one four hour period has passed, after one four hour period, how much is left over? Well, according to the problem statement, there's 20% that's left over. So 320 times 20%, that's 0.2, is 64 milligrams. So if we don't give any more medicine, which is the assumption that we're making here, after one four hour period, the child has metabolized out 80% of the drug but retains 20% and that's this much, 64. After another four hour period, after two four hour periods, let's abbreviate there, how much is left? Well it's going to be 20% of what was previously remaining, 20% of that 64, so 64 milligrams and 20% of that is going to remain, that's 12.8 milligrams. After three four hour periods, how much is going to be left? Well, 12.8 times 20%, 20% of whatever was there in the first place, that's 2.56 milligrams. We're almost there, after four four hour periods, how much is left? Well, again, we're going to take the amount that was left, whatever was left at the end of the previous four hour period, that's 2.56 milligrams and multiply that by 20% because that's according to her specs, according to her weight, that's what she keeps. So that's 0.512 milligrams and finally, at the end of the fifth four hour period, we're going to have 0.512 times 20% left and that's finally, the answer here is 0.1024 milligrams. So basically, virtually nothing left in her system after that point, which is why under normal conditions, you would keep giving the kid medicine every four hours because it would boost her levels of Tylenol. Sorry, acetaminophen, I think I back up into her bloodstream. But if you didn't administer any more drug during this time, that's how much would be left over. Now, what I want to point out here is not so much the answer to the question but the method by which we got it. What we were doing each time to get the new amount of drug left over, say this 12.8, we were taking the previous amount of drug left over and multiplying by 20%. And every time, we kept multiplying the previous amount left over to get the new amount and that was sort of the rule here. It wasn't so much a formula that tells me I could just plug in five and find out what the answer is. But I have a rule or process that allows me to calculate the amount left over at any current time period based on how much was left over in the previous time period. Now, if that sounds like induction to you, you're on the right track here. So I just want to bring this down to some closure. This is what's known as a recursively defined sequence. The notion of recursion and the notion of induction kind of go hand in hand. Induction we know is a proof technique that allows us to prove problems in terms of previous and simpler versions of themselves. Recursion is a similar technique, it sort of more applies to calculations. So you could say here that we've created a sequence where A0, the amount left over after zero time periods have passed is 320. And then An, the amount left over after a current time period, is defined by taking the previous time period and multiplying by 0.2. So that's what we call a recursively defined sequence. Every term in the sequence except the first one, sort of a base case. The base case is given to us straight out, but every other term in the sequence is defined in terms of the previous item in the sequence. So that's what we mean by recursively defined sequence. So let's see how well you're understanding recursively defined sequences with a quick concept check. So let's suppose that we're going to define a sequence recursively by declaring A1 to be equal to 1, and then A sub n, every other nth term, as long as for n bigger than or equal to 2, every other term in the sequence is defined by n times An minus 1. So with that, what is the value of A7? Work this out and pause the video while you're doing it. And then come back when you have a result. So the answer here is going to be the very last one, 5,040. And to see that, let's just kind of try to crank through this. Well, let's go all the way up here. We need some room. So A1 is declared to be equal to 1. A2, according to the formula here, A2, let's pretend the n is a 2. That would be 2 times A sub 2 minus 1. So that would be 2 times A1. That's 2 times the previous value. So that would be 2 times 1, which is 2. A3, according to my formula, would be 3. See, there's an n there, times A sub 2. And that would be 3 times 2, because A2 is right up here. And 3 times 2 is 6. So what is A4? That would be 4 times A3. And that would be 4 times 6. That's 24. A5 is 5 times A4. And that would be 120. I'm running out of room, so I'm going to go up here to the top. A6 would be 6 times A5. And that would be 720. And then finally, we get our final result. I'll put it down here in the white. A7 is 7 times A6. And that would be 7 times 720. That's 5,040. So according to the rule for the sequence, the first term is defined for me. But every other term from the second term on up is given by taking the subscript and multiplying it times the previous term in the sequence. So that's a recursively defined sequence. So in the next video, we're going to look at a sequence that's defined by two conditions. And that motivates a very important and famous sequence of numbers. Stay around, and thanks for watching.