And the title of will's thesis is the network and the classroom, a history of hyper media learning environments. And I'm going to hand it over to Eric to introduce. Thanks Eric. Before before I introduce will I just want to say how how excellent all the work has been but also to note how diverse it's been. And yet, the whole student of whole student community has been clearly supportive of each other and I just want to give a call out to the whole student community for their work through challenging times here. So thank you to all of you for that. And so now I'll introduce will. And so I first met will a couple of years ago at PAX East. He had applied to the program I think he had gotten into the program and I met him at PAX East to see some of his work that he was working on in games, and was thrilled that when he was announced he was coming to the program. Because he had done such great work there came here started working I'm actually I'm wearing a playful journey lab official garment here, where he's been working at MIT. He's been doing work on games and continued to work on some of the work on games and assessment there but found his thesis passion and interest around hyper media. And, and I've been, I've learned a lot through his journey through hyper media and looking at his relationship to education and learning. And noted that he takes, I don't want to give too much away but he's given sort of a historical perspective on hyper media, and that history sort of coincides with my lifetime so I've kind of lived along a lot of the thesis work that he'll be talking about today so with that I will let will take it away. Thank you so much Eric. Let me just share my screen here. Okay, you may be blessed today a little bit with some New York City traffic noises throughout my presentation. Okay, so I'm going to begin. Can everybody see this is this visible. Okay, great. So I'm going to begin with some of the personal kind of origins of this topic for me. I was one of those students growing up who immediately upon graduating high school felt like I had kind of already forgotten a significant portion of what I had learned throughout my years of education. And as I began college for the first time I had the opportunity to choose classes, not only that I was excited about, but that overlapped with each other in different ways that felt meaningful to try to document, build upon and return to. Throughout this time I felt that kind of like lingering anxiety that I would come away from these years of school, feeling like I had when I finished high school that I had had all these deeply meaningful discussions and lectures and readings which would soon kind of drift out of memory. So what I realized I was looking for was a system for organizing my own knowledge that could act like a thinking partner, not just an ever growing pile of notebooks and readings but a system for organizing ideas that could let thoughts intermingle that could accompany my learning, and that would be valuable and generative to return to and explore, and ideally a tool that I could use in collaboration with others to share ideas as we learned. In the past five years there have been actually an explosion in popularity of these types of tools for creating network systems for organizing and sharing knowledge. And while this type of tool isn't always described using one single term. I refer to this genre of tool as hyper media knowledge organization tools and I'll take a moment to kind of break that down. So at its most simple hyper media, the term hyper media comes from hyper text, which refers to text which is not constrained to be linear and where the text itself contains linkages to other text or other documents which a user can kind of follow based on their own interest. And then from there comes hyper media more broadly, which refers to systems where other media forms like images and video can be connected in similar ways. The most obvious example of hyper text and hyper media is the internet itself where you follow hyper links to navigate networks of pages and content. And then when I say knowledge organization tools. I'm referring quite broadly to tools and practices which help arrange and document ideas and concepts. So taken together hyper media knowledge organization tools refers to tools which allow users to document organize and develop ideas which employ these practices of linking and network forming to to form these like networks of interconnected thoughts. Many of these recent tools promise to positively affect how people think, learn and generate ideas. These new tools make claims for helping people create a second brain in this example here by creating and following connections between notes and ideas. They emphasize non linear note taking and knowledge organizing and typically employ imagery as well as user interfaces that incorporate these interconnected nodes of ideas, which you can see here this is a tool called Rome research. Furthermore they emphasize collaboration and connection making across contexts is another tool called arena where you can locate single ideas and multiple folders at once. And finally, many of these tools propose that thinking and learning happen in these shared organizing spaces. So, while these recent tools make pretty lofty claims about their new features to help create context for improved thinking and learning. They build upon both technology and pedagogy that has been developing since the early days of personal computers. So in this thesis I asked, how can classrooms use emerging systems for collaboratively sharing and organizing knowledge in order to benefit learners, and how can we learn from the past in order to better shape the future of this work. I argue that examining the history of hyper media oriented learning tools by looking at both successful and failed experiments and bring them to classrooms. One can more deeply understand both the conceptual origins of these recent network knowledge tools and consider where they may be able to fit into today's classrooms, as well as how to avoid challenges that have plagued them in the past. So, indeed there's a whole lineage of these types of interactive and collaborative tools for organizing knowledge as networks that have been experimented with in classrooms since the 1980s. In this thesis I look at two previous moments of intense development in this space, one in the mid 1980s and another in the mid 2000s before then turning to examine these tools in the present moment. At each of these points I look at technological shifts, as well as trends in the learning sciences which together inform both the design and application of these tools. In doing so, I examine and draw lessons from the frictions involved in using these tools in educational contexts, in order to consider and propose ways in which these new tools might be able to be used to support learning in classrooms today. As I do so, I look at emulations and technical documentation of older software. I look at advertisements, promotional material and video content of people using these tools. Then I survey a pretty wide variety of research studies describing the application of hypermedia learning tools in learning contexts from each of these points. So in this presentation today I'm going to do kind of two things. First is give sort of quick historical overview of the development of these tools and the connections between hypermedia and learning as they've developed and discuss some of the frictions between educational media hypermedia and classrooms along the way. And then I'll shift gears and describe the current generation of these tools and point to three approaches that these types of tools could be used in classrooms. One of which I implemented in a middle school classroom context in the fall. But before getting there, I want to touch on why why this area is important. Firstly, building new capacities to document organize and structure knowledge is a crucial 21st century skill, the one that becomes ever more relevant when encountering increasing information saturation that we all deal with today. Making changes to education broadly is an incredibly challenging task. And particularly in the context of educational technology, new tools with great promise come in and out of popularity quite regularly and very rarely make any significant changes in popular educational discourse. In his book, Failure to Disrupt Why Technology Alone Can't Transform Education, Justin Reich talks in depth about why so many of the technologies which have been promised will radically transform educational practices have failed. It's worth a juxtaposition between two stances, the charismatic stance in the tinkering stance. The charismatic stance typically accompanies technological innovation. It's the notion that technology itself inherently will offer wholesale transformation of existing systems and it's this stance that often fails. In comparison, the tinkering stance he says sees schools and universities as complex systems which can be improved, but they believe that major improvement is the product of many years of incremental changes to existing institutions rather than the result of one stroke of wholesale renewal. So with this thesis I hope to take a tinkerer stance on considering the possible value of these types of tools. I see this in trying to pull lessons from the earlier eras of hypermedia learning that I examine and consider how these, how these tools might be able to offer some incremental changes to classrooms. So first I'm going to talk a little bit about some of the origins of the connection between hypermedia and and learning. Any account of the history of hypertext and hypermedia tends to begin with Vannevar Bush. He was an American engineer and inventor and led the US Office of Scientific Research and Development throughout World War II. Following the war, Bush sought to imagine schools as sorry, imagine tools, which might be able to enable the human mind to more readily think and learn across disciplines. In part this stemmed from a fear that the increasing hyper specialization which he saw amongst his research organizations would lead to a mountain of inaccessible knowledge. It is 1945 piece in the Atlantic titled as we may think Bush proposed a device called the memex to deal with this challenge. The memex was a device which would hold microfilm copies of the user's personal library and allow them to make automatic connections between text, such that they could create chains of intertextual association. Users of the memex device would save and share these paths of ideas between texts as well as their notes about them. As is apparent in the title of this piece, Bush wanted to develop a device that he operates as he believed, we may think. This notion that the mind naturally operates by association carries throughout this entire text as he says, with one item in its grasp, the brain instantly snaps to the next that is suggested by the association of thoughts in accordance with some intricate web of trails carried by the cells of the brain. So embedded in his writing are few notions about learning that carry across many of the hyper media tools for organizing knowledge that developed in the following years. First is the idea that the mind naturally thinks and learns by making these associations. The second is that associations between ideas can link together from one to the next to form trails of connection as Bush describes developing tools by which one can create and save these trails will allow for deeper learning. And then third is that these trails are meaningful chunks of knowledge which can be built collaboratively where sharing and co creating networks of association between ideas will inherently lead to deeper learning. And then in the 20 in the 20 years that followed the terms hypertext and hyper media themselves were later coined by Ted Nelson in the 1960s who imagined digital systems which would use these models. He created diagrams to illustrate the idea of hypertext and hyper media one of which you can see here. And this this imagery is often repeated throughout the types of tools that we look at today. So, Okay, yes. Though this optimism in the power of hyper media to accelerate learning remained semi dormant for a few decades in terms of tools that were actually developed by the mid 1980s, multiple hyper media platforms simultaneously sprung forth that were specifically designed for the educational context. Researchers from across educational and commercial institutions promise that hyper media oriented learning tools would offer learners newer and faster ways of accessing knowledge, new modes of collaboration, and new types of interaction to enable learners to forge connections between ideas. By the mid 20th century, new theories of knowledge acquisition began to describe learning and thinking as processes using computational and diagrammatic metaphors which sounded much like Ted Nelson and Van of our bushes early descriptions of hypertext systems. These perspectives on learning were foundational and bridging the language of hypertext to the language of learning, which deeply informed the educational hyper media tools to come. So I'm going to talk about two of them briefly. The model of learning that stands out for its overlap with hypertext vocabulary is the model of schemas, a concept from psychology and cognitive science which describes patterns of thought or behavior which organize information and the relationships between them. The model of schema considers mental constructs as individual nodes which together form networks of ideas through associative structures which consist of attributes and relationships between them. Schemas focus attention on the role that old knowledge plays in acquiring new knowledge in the sense that new knowledge is filtered and interpreted through these webs of preexisting associations. Another important model to understand learning that was growing in popularity at this time was the idea of social constructivism. In the educational context, social constructivism emphasizes the deeply collaborative nature of learning, suggesting that knowledge develops through how people interact with each other, their culture and society at large. In classroom learning students rely on others to help create their own building blocks, with which they incorporate new ideas and interpret their existing assumptions about reality. So thinking about the computer as an educational tool in the context of schemas and social constructivism, it became clear that computers could be used as tools to think with. Hypertext based tools could readily act as a digital environment through which learners could model and extend the social construction of knowledge. By creating open and unstructured databases that allow for collaboration, learners can add and connect ideas and support and challenge each other's perspectives. Sometimes all this was happening, new developments in computing were simultaneously essential in creating the conditions for these these new educational hypertext experiences to develop. So, just to give a kind of overview of the like early 80s moment in 1981 IBM was releasing its first personal computer, which was the first to gain massive industry adoption. The first telecom offered the mental terminals which became the largest online service before the worldwide web in 82 land operating systems emerged which allowed network links between computers and offices in 83 Microsoft introduced for 84 CD Rom explode and popularity. In 1985 essentially computers, commercial computers have become powerful enough to store and manipulate multiple and just as networking practices were becoming increasingly possible, the business sector, both of which are crucial in developing the types of interactive platforms that come. So, I'm going to talk about one of the hyper media knowledge organization tools that was developed during this time called intermediate. Intermediate was a hyper media tool developed at Brown University between 1985 and 1991. The tool, the project was accompanied by by a team of both computer scientists and ethnographers who produced research papers about how it was received as well collected documentary footage. In this project, the team describes intermediate as a vision to create a vast multimedia information environment, or no piece of information is ever isolated, and where every word picture and idea can be linked to any other. Intermediate was not so much one tool as it was a suite of applications which explains its kind of plural name. There's a sense of this from the screenshot here, where you can see on the left of web that was created which links out to multiple documents on 19th century health records, and each of the documents themselves linked to each other. And then over on the right you can see a kind of like history of all the different kinds of edits and linkages that people were creating and building. So, in the ethnographic report students referred to working with intermediate as going to intermediate, because all the intermediate terminals were housed in one room. So to them, this experience of intermediate was not as much the software as it was the content held in the software as it was the physical space that house it was this kind of total experience. The first intermediate pilot with two was with two classes at Brown, an English survey course and a biology course. The two courses were selected as a proof of concept of the flexibility of the system. If the same tool could be used to enhance learning in the distinct cultures of the sciences and the humanities, then surely it would be useful to a broader selection of courses. The professors for the each course and the research team together built an entire corpus of reference materials for the work before the before the courses began, inputting and linking hundreds of documents together. Students could contribute their own content to their to the intermediate environment by adding their own writing by linking elements from their own or others work together were inputting other resource materials. While students and educators often had a range of experiences using intermediate over the course of the entire semester. The learning outcomes of engaging with this tool were considered largely quite successful, both in terms of students performance on exams for the biology course, as well as the kind of depth of connection making and discussion for the students in the English course. So this is one example of the types of experiments that was occurring during this time. This is I talk about two other significant hyper media knowledge organization tools from this era. One is called Cecil which later turned into a tool called knowledge forum, and another called hypercard which was not explicitly educational but was used quite a bit in educational contexts. Looking across the research studies from from throughout these three tools, and about the various ways they were used in classrooms at this time, a few kind of patterns of frictions become clear. So, many of these early experiments required so much preset up like intermediate where professors and a team of workers entered a huge amount of material before the course began. So, some of these early experiments were themselves successful and learners had positive experiences. They were typically quite unrealistic to imagine setting up at any larger scale. Furthermore, there was quite a significant number of technical challenges with using these tools as well. So, operating networks computer labs at that point was expensive and not what not yet a norm. So, loading and interacting with network systems could at times be incredibly slow and cumbersome. And this was particularly a big problem for intermediate. And then for many just becoming familiar with interacting with the computer was was a new experience and required significant onboarding time. So that's like a little picture of this mid 1980s moment. So moving forward now. I'll describe kind of a moment, a bit of the time in between and then we'll jump to the 2000s. So, despite the, the failure of the tools from the 1980s and early 90s to gain widespread traction in classrooms. By the mid 1990s, it was becoming increasingly clear that the world was rapidly changing alongside developments and mass popularizations of computers and the early Internet. In particular educational discourse, there were a plurality of descriptions of what this future computer enabled world would look like and notions of how to adapt educational practices in order to better prepare learners for this new landscape. By 2005, the broad shift toward a more highly interactive Internet, only further fueled excitement about participatory web based learning tools. The broad shift in how websites were designed was described as web 2.0, a term used for new websites that were structured to enable user generated and participatory content interactions with things like the growth of social media blogs and video sharing sites. At the same time, a broad and interdisciplinary pedagogical approach called computer supported collaborative learning or CSCL was beginning to gain significantly more traction. The approaches which build upon a combination of educational psychology, instructional technology and social psychology. Learning occurs through social interactions using shared digital spaces where learners collaboratively construct knowledge using technology as their primary means of communication or as a shared resource. Though the CSCL community had existed for a few decades, the availability of more collaborative platforms on the Internet led to a significant expansion in the CSCL community and its research. Many educational researchers across CL and other disciplines took this collaborative potential and growing popularity of the Internet and imagined how these tools could be used in concert with a broadly constructivist learning strategies to enable learners to more effectively participate in a network society. So of these new web 2.0 platforms that were rapidly growing in popularity, the wiki became a format onto which researchers began to imagine new possibilities for developing collaborative learning experiences in the classroom. So while everyone is likely familiar with Wikipedia, which is the most widely known wiki, wikis generally are wikis more broadly are a kind of general form of hypertext publication that is collaboratively edited and managed directly inside of the web browser. Wikis themselves run wiki engines, many of which are freely open source and could be readily tinkered with by researchers and educators. So, while on the kind of first section of my thesis I looked at kind of a spread of different tools and how they were used in classrooms. In this chapter I typically I focus on wikis as a kind of general model, which were and continue to be used in a wide variety of different learning contexts. So, there are a few, there are a number of aspects of how wikis are designed that are particularly appeal to this kind of constructivist approach. Like earlier hypermedia models wikis allow users to organize and present content in a way that does not prescribe a set organizational form at the outset, and can allow for kind of organic growth. These use pages as nodes which can refer to each other to form a network which does not need to be predetermined. This offers the potential for students to build out wikis as they follow self directed learning, adding or linking new pages as they potentially follow their own interests. So, beginning around 2005 educators and researchers proposed and developed a wide variety of learning experiences which brought wikis into the classroom across a variety of different maturities of learners across different subject areas and across context. So I'll talk about a few sort of like general models of wikis that were used in education. The first is a resource wiki. Resource wikis are collaborative knowledge bases where learners contribute to their contribute their knowledge to an expanding encyclopedic resource. Resource wikis are typically more outward facing, meaning that they're less intended to contain in progress documentation of learning processes, and instead are able to function as a knowledge base that could be legible and potentially useful to external readers beyond the class itself. Students might be assigned to creating specific article style entries, integrating text and images and attribution to cited articles. These types of wikis are intended to perform like Wikipedia as a resource containing reliably sourced information. One one related genre of wiki usage involves presentation wikis, which are a way of using wikis to create and document in progress learning and knowledge in a format that is less concerned with being presentable to an outsider and more focused on being useful for learners. Presentation wikis have more room for individuals to use their own writing styles and tones. And while while learners using presentation wikis will link their pages and ideas together, it's more likely to be intentionally parent who developed each page on the wiki in order to assess the contributors as well. Presentation wikis are more likely to have segmented areas where contributors are working individually or collaboratively in private spaces, where more finished work will kind of be added to the publicly accessible zone upon completion. And one third example of using wikis that I'll mention just briefly is using them for co writing as an opportunity to bring students away from the kind of traditional solitary mode of written work and toward collective writing processes which offer not only opportunities for to practice reading and writing but involve critical thinking reflection and like regular interaction. Reflecting on the years of research using wikis in classrooms, there are a number of different kinds of challenges in using them that stand out from the challenges that the tools in the mid 80s dealt with. One significant one was that evaluating both performance and individuals contributions in this context is very difficult for shared and collaborative spaces. These evaluations became increasingly crucial during the 2005 forward era of heightened standardized testing and no child left behind. Secondly, more meta research from 2009 and so onward indicated that in many cases learners didn't actually display deeply collaborative behaviors using them. So this was often the case where when students like procrastinate they vastly reduce the possibility for collaboration. Like when working against the time crunch students are like less likely to take the time to reflect on each other's work or thoughtfully cross reference between wiki pages and are much more likely to focus on just finishing their own content. Furthermore, working with limited time learners don't typically can't typically give in progress feedback to their peers. Furthermore, wikis themselves typically by default are much more stripped down than than some of the earlier tools even than the ones described in the 80s in the sense that they don't have built in modes of visualizing networks of ideas and and where content or individual nodes can only live in one place rather than a plurality of them at once. And then one final one final friction in classrooms was that discussion areas on wikis are typically separated out from the content areas and so having deeper discussions was challenging to point to specific specific notes in the wiki. All right. So now I'm going to shift gears a little bit and talks about some of the contemporary hyper media tools for knowledge organization, some of the features of them and then describe kind of three applications that I see them being used in today's classrooms. As I mentioned at the at the opening of this presentation there there have been a variety of new types of tools which draw upon this nonlinear network oriented model of documenting and organizing knowledge. The design of this recent generation of tools combines many of the important design aspects from each of the previous points that I examined earlier. So, like the mid 2000s kind of wiki moment, these recent hyper media knowledge organization tools are are are accessible and primarily browser based. They are synchronously editable meaning that users can actually see each other's changes in real time. But these tools also borrow a lot of the design decisions from the 80s as well. Many of which emphasize the importance of multi contextuality where one idea can simultaneously link out to multiple places at once rather than kind of one directional link. They prioritize creating and connecting smaller nodes of information. So, while with the wiki where the page was kind of the individual node that could connect to other pages. Many of these contemporary tools prioritize creating and connecting smaller chunks of information together like individual bullet points or individual images. And then finally, many of these emerging platforms offer multiple ways of creating and viewing the connections between information and their relationships as well. So often employing graph used to kind of visualize nodes of interconnection. So, the final section of my thesis then asks, where might these ideas and platforms fit into classrooms today and how can we learn from some of these frictions of previous tools. I identify three possible ways that I see these contemporary tools being used that avoid some of the aforementioned frictions and the each of these models are inspired by practices that I've seen people using online. The first is the concept of creating a digital garden. So, digital gardens are online spaces that look something like a combination of a notebook and a blog. Digital gardeners write essays or short form pieces and use back links at the end of each page to point to other pieces inside their garden to connect to the piece that the reader is currently reading to others. It's like a kind of personal website or a blog with the added notion that the written pieces are intentionally interlinked together. And this kind of garden metaphor implies that the connections on each page as well as the content itself will be tended to and that the posts themselves are meant to be final but can grow later on. Digital gardens are a model that could be useful in a variety of contexts. But for an example, a middle school aged learner in an English class could use a digital garden to write not only their homework assignments essays and creative work in one shared space and could be encouraged to explicitly make connections between these different forms. This model is developed by an individual rather than a group and is more focused on organizing and sharing work that a learner has themselves created rather than inputting knowledge created by others. So this has the benefit of giving teachers a space with which to evaluate the students work as they use the tool. A second approach is using these shared knowledge organization tools for creating collaborative research repositories. So using these tools learners that are part of a class or group of classes can collectively gather organize and annotate external materials that will be useful for research and writing that will be developed separately. This is a type of practice that I've seen on one of the tools called arena that I examined previously. This type of model will allow students to help each other gather materials that will be useful for their own individual work and in doing so builds a shared system that is potentially useful to the entire class as a whole. And while this model is inherently collaborative. It's in a kind of pre writing context that avoids the challenges of needing to figure out how to grade individual students on their contributions. And then the third model that I talked about, which is what I explore in a little bit more depth in a case study is using networked tools to support social emotional learning in classrooms. This model is inspired by a project that I worked on with the playful journey lab at MIT in collaboration with a seventh grade Massachusetts area public middle school classroom in the fall. We used a tool called realm research, which is one of the contemporary tools that I go over in the thesis to host an activity series format that focused on collaborative reflection in order to support students and teachers to acknowledge a kind of wide variety of experiences and types of learning that that happened throughout the pandemic. The types of prompts that we designed involved virtual making and collaborative writing that that that also incorporated like drawing simple video making and taking pictures. The intention was that students would come away from this activity series with this co created collection of shared artifacts that captured this moment in their lives that led to like deeper discussion and that helped expand their ideas of what learning is. And in doing so, they worked in this kind of shared knowledge environment over the course of a semester. Using using these tools in this context is again kind of outside of a context that requires grading, and also further further encourages collaboration and connection forming. And also using using these tools for a shared social emotional space could be a way to help learners in distance learning environments as well. Also, also developing an activity series in this using this format is a way of avoiding some of the procrastination problems that Wikipedia or the sorry that wikis often dealt with. I could talk a lot more about this specific project, but I'm going to kind of start to start to wrap up. Looking at both the history and present moment of network tools in the context of learning. My hope today is to kind of leave you with a gentle optimism about their potential. While I don't see these tools on their own as as radically or fundamentally transforming educational practices. I see that there clearly is a design space that can be continued to be explored using these types of tools to support learners in a variety of different contexts. So I think that taking a tinkerers approach to looking at the past configurations of the genre of tool and carefully examining the contexts within which they can be employed is is essential to using them to create change. And then ultimately what what is more most important is is less the tools themselves but a careful consideration of how they fit into the environments in which we use them. Thank you all so much. Thank you to Eric and Justin for for all of your help as well as everybody here and take a sip of water. All right, open for questions. Eric. Thanks well I enjoyed hearing your presentation there and of course going through this this journey with you. My question is really is a little bit of a little bit of a hypothetical situation but I'll sort of ask in the context of the sort of the tinker and the charismatic. And so you should have documented this case of of tinkering over decades in this in this space of hyper media with respect to schools. So imagine, imagine that you can take one of the tools used for mentioned on the last slide there perhaps the one they used the schools room and and bring it back to a 1980s classroom. So here you are you're the charismatic who can bring this this technology of the future to the classroom. Is it to be more effective than the things that they were using at the time. And the context of my question is like, is it is it the process of tinkering that's important, or is it the product of tinkering that's important that it would get to that place through this for these years of tinkering. Yeah, I think it I think it has to be a combination in the sense that I think just even even dropping one of these contemporary tools, even if you also brought with it, like the, you know, the computers to it to that point would still I think there would still be a lot of kinds of frictions encountered I think that like, it's this process of tinkering over the course of many years that develops a kind of like language around how to how to bring them into classrooms, and like pedagogical approaches that that like are carefully considered over over the course of years that that find their fit at a certain point. And so I think that, while while, while some of the tools at that point where it was themselves quite effective. I think that it's, it's yeah the kind of process of tinkering that that it's important. Yeah. Thanks. Well thanks that was that was terrific, a brilliant history and one I want to learn a lot more about can't wait to read it. Just to pick up on Eric's question, and the very last point you made where you said it's more about the fit. It's less about the tools and it's more about the fit in the context. I think it's just another way to read, like the, the information you've amassed is as a moment in a zeitgeist a moment in the kind of technological remapping of how consciousness works on how learning works. If you were to jump back a century and a half, you know when photography was the hot medium. There's a lot of emphasis being put on like well can we learn with slides can we learn with image how does the mind work. There's this kind of pod to do between the representation systems that are being used in the classroom, and the model of how mental processes work, like well we hold images or it's a blank slate or it's a photographic memory. That's a discourse that's really big in the, in the, in the mid 19th century. And it strikes me as just the kind of the. And this goes to Eric's point in question I guess like there is a kind of zeitgeist, a paradigm and notion of how consciousness works that we that we technologically emulate. And it's not whether the tool is good or bad it's whether that fit. It strikes me there was so apt the last thing you said it's less the tools and more the fit in the context. I'm using context in a different way than you used it, but I think it's still, it still kind of works. I don't know if you, any reactions to that or whatever but it just strikes me as a brilliant meditation on our thinking about the learning process and our thinking about the functioning of consciousness through technology as the lens. Yeah, that's a really interesting point I think that. I mean I was quite struck by the fact that like this this like associative metaphor and this like image of these like interconnected documents is like persisted now for me. And Nelson kind of was developing that that model in the 60s and like we're like you see these brand new tools that are claimed that like pretend to be entirely a historical that are like referencing this exact same diagram. So, and I and I'm, it's something that I wonder like if, if perhaps it's like through, you know, now, however many years been get deep engagement with the internet that like, maybe that this model is more ready to be used than it had been previously that like the types of maybe we're starting to see cracks in the system and that you gave me three examples that you're focusing on and one was the garden. Like if like there's not an ecological model that's starting to displace this technological computational model. Like, say another doubles advocate. It's appealing to a new metaphor, and it's a more organic, more organic one. Yeah, I mean, I've seen that's something that I know a little bit at the end of the thesis that I that I see this kind of gardening metaphor actually used quite a bit more in relation to these tools that that might even perhaps like kind of overtake the sort of network metaphor down the road. And that's something. Yeah, that's something I would love to see happen. Justin. Thanks Will. This has been really terrific. Can everybody hear me okay. Yep. I wanted to, you know, a terrific history, lots of great connections and Eric can win questions about quite a bit. One challenge I wanted to offer is that it sounded like in your final piece, you were saying something along the lines of, if we could get teachers to choose the right kind of projects to do with Rome research, then that would create some of the problems with previous generations, which just makes me think that that's an argument that it was the projects in previous generations that were wrong. I wonder if you could talk about what thoughts you have an alternative view that it's not that the projects were wrong, nor is it the case that you could pick the perfect Rome projects and have them fit. There's a series of values in schools that are orthogonal to the values of learning and participating with these tools. Right. I think that, yeah, that's a great point. So, yeah, I think that the that that it is true that often the values of schools absolutely are a fagmal to effectively using these types of tools. I guess what I'm trying to propose is that there are still ways of using them in inside of the existing kind of structures of schools that can still be effective. I don't know if that completely answers your question. Well, yeah, I think I think you just should do that as well just something like, I can't change schools. So, but there's probably like little niches where where sufficiently devoted people will make this work. So here are some great ways of doing that. And I think that's good too. Although, although I think that, you know, they're there, you know, that which is a which is a great way of continuing to develop really interesting pedagogy for the Coalition of the willing. And I'm interested whether Rome or whether you know garden metaphors or what other kinds of things might expand that coalition to the willing in interesting ways. Yeah, I mean I think that I think that expanding the coalition of the willing is I guess kind of where where I'm sort of leaving this off, I guess, in the sense that I definitely don't see like any mass proliferation of the uses of these types of tools, happening in directly inside of classrooms like happening anytime soon. But I think that the that finding these finding these kind of design language or finding these new configurations I think can like help expand who the who the willing are what that coalition is, and the type of uses for them. I have a somewhat tangential question but I as a historian and documentary and I couldn't let this pass. You mentioned that the that the project at Brown in the late 80s. It also involved documentary footage. Yes. Can you tell me a bit more about that was there a documentary made about it or is it. Yes, there was I can actually send it yeah it's a great documentary because it interestingly enough there wasn't like a ton of visual documentation of the project. So that so the documentary really helped me out a lot in trying to understand what was happening at that point. There was a lot of quite a few interviews with students at Brown about their experience working with the tool. I didn't, I didn't have time to mention it today but there was like quite a few interesting anecdotes like some students felt like using this shared network to help their studying was cheating. They would use these materials instead of textbook materials, somehow like gave them a better score on their on their tests like wasn't an authentic way of learning. And there were other, there were other little anecdotes about from the English class about students feeling like their ideas were getting less like individual creative people were getting reduced to the kind of mean creativity of the classroom, which was kind of unexpected point that I thought was interesting. It was really fascinating. I'd be happy to send it. Great. Thanks. Well, let's give Will a round of applause.


What's up everyone it's your girl Kenzie here from Layton Sports Guards and I'm repping a personal here for Brian and we've got to 2022 leaf autograph jerseys multi sport edition. All right, Brian. Here we go. Good luck. See, let's see. Let's see that my home. That would be crazy, huh? That would be something. Here we go. First box up. We have, oh, how about from Bill's Mafia, Jim Kelly. Jim Kelly, sign that nice and big. You got your Beckett sticker right there with your matching Beckett certs. Jim Kelly, Bill's legend there. Very cool. All right. There is your first jersey and jersey number two. Gotcha. Yeah, my sister had all four of her kids see section too. I guess they kind of recommend that once you have one see section, I guess. Have them all see section. All right, Brian. Second one up. How about a Charlie Sheen. Wow. That's a cool one. Charlie Sheen auto. You got your Beckett sticker with your matching Beckett certs with the Vaughn on the back. That's cool. Charlie Sheen. It's all sample one of these. It's my first one of those that I've personally pulled. Cool one there. Congrats on those jerseys, Brian. Thanks a lot. We'll get these right out to you.


Good morning, good morning, good evening, good afternoon, wherever you might be. Again, my name is Jen Gile from EngineX, where I focus on our Kubernetes and microservices solutions, specifically Ingress and Service Mesh, as well as Kubernetes platforms in general. And Mihal, will you give us a little bit more of an intro? Of course, thanks, Jen. Hey, everybody. My name is Mihal Kingston. I'm a Solutions Engineer in the EngineX product group of F5. I spend a lot of time helping companies adopt the EngineX technology from modern applications to traditional applications also. I see many environments and architectures and topologies, many patterns and modernization, microservices and service mesh, especially in Kubernetes. Thank you. So we can certainly answer questions about our tools, but we're really here to talk more agnostic about what is Kubernetes Ingress, why is it important, why is it a key component of a Kubernetes strategy. And so to kick things off, what I'd like to do is go ahead and launch a poll. So you should see it pop up on your screen. There are two questions. First, we'd love to know from the audience where you are with Kubernetes, you're not using it all, or perhaps you're just getting started with it. You're working in an organization that's a hybrid of both traditional and Kubernetes apps, or perhaps you're at a microservices first organization. And then the second question, we'd like to know what your biggest concerns are with Kubernetes. We've selected ones that we hear most frequently around training and knowledge, security, complexity, visibility. But if there's something else that's not on that list, drop it in the chat. So, Mihal, what are you seeing when you talk to customers with regard to Kubernetes adoption? Where are people? Yeah, most of the time organizations are using a traditional combined with a modern environment using Kubernetes or OpenShift or any other Kubernetes native environment. This is usually the most popular. We often speak to customers who want to modernize, move away from traditional three tier, four tier machine or three tier applications to more microservices based applications where all components are deployed in containers and Kubernetes using more lightweight protocols like APIs, for example. Yeah, and you know it's not necessarily about going from traditional to modern and completely eliminating traditional. There's still some justification for maintaining monolithic apps along with a microservices or a Kubernetes environment. Maybe you could talk a bit about where that fits into the strategy as we wait for people to respond. We're at about three quarters, but still numbers moving up so I'll give people another few seconds. Yeah, of course. Oftentimes a monolith might be perfectly fine, right? Let's say you have an application that's relatively static. It doesn't need to scale that much. Maybe it's an application where you're simply posting some photos or it's a small business.  We see more and more companies adopting containers or Kubernetes or OpenShift where we start looking at applications that tend to scale very quickly and very dramatically. This is when you might have two replicas of your application today and 10 replicas of your application tomorrow. So it does vary quite a bit depending on the nature of your organization as well as the nature of the application itself. Alright, I'm going to go ahead and close the poll and we'll see where people are with regard to this first poll that's up on the slide. And so you should see it on your own screen. So we have, let's see here, out of the 80% of people, 103 people respond to our poll here, only 7% are not using Kubernetes. The 95% are just getting started. Unsurprising to us, 43%, the majority are in that traditional to Kubernetes hybrid already, and then we do have 16% already out of microservices first organization. And then the second question, being around the biggest concern. No surprises here. The leading answer is training and knowledge that in our experience tracks pretty well with where we're seeing people adopting, you know, you're earlier in Kubernetes, you're just getting started. Of course, knowledge is usually where you want to be focusing complexity coming in second at 36%, followed by security at 15% and visibility at 5% and we do have a couple people who did choose others, we'll just take a look at the chat. And a quick reminder, we won't be answering questions that come in through the chat so if you have a question please pop it over into the Q&A. So I see a, Kate's on-prem clusters and complexity with exposing the services externally, being one of the other things that people are struggling with or encountering. So we will take a look at the Q&A throughout the session today. We'll answer them as we go if they're relevant to what we're talking about. If they're not, we'll capture them at the end, we'll do our best to get to all of them. And so let's start high level, Mihal. You know, as we go out and we talk about ingress, we find a lot of people aren't using an ingress controller yet. Perhaps they're not sure how an ingress controller is different from cluster IP or node portal mode balancer. So start us off here. Yeah, and one of the comments put in the chat there actually reflects this. People don't understand how to expose your applications from Kubernetes to the outside world. That's exactly what we're talking about here. There was often some confusion around Kubernetes networking. What I'm seeing more and more is the complexity around networking for the application teams. When you start to plug in the applications and Kubernetes interfaces, IP tables, different terminologies that are very Kubernetes specific. So let's simplify this a little bit. Let's separate these into different components that are more associated with associating the application, exposing the application, should I say. So if you wanted to, you could deploy your application and all of its dependencies inside Kubernetes. You could expose the application via node port, load balancer or cluster IP. Let's take the ingress out for just a moment. Cluster IP is essentially the default Kubernetes service. It gives you a service inside Kubernetes that other apps inside the cluster can access. It's an internal service type. So there is no external access and the only way to expose a cluster IP service is to use something like Qt proxy, which is essentially a bunch of IP tables. But there are very, very few scenarios where you would use Qt proxy to access your services. It could be to access your service on your laptop, debug a service or even just look at some monitoring and metrics. A node port service on the other hand is probably one of the most primitive ways to get traffic into your applications. Node port, as the name implies, opens a specific port on all of the Kubernetes nodes and any traffic that is sent to the node on that port is forwarded to the application. You can only have one service per node port, and you can only use ports over 30,000. So if your node IP address changes or if your virtual machine changes, for example, you need to deal with that. A load balancer service is probably one of the most popular ways to expose a service, usually in a cloud platform. For example, in Google Cloud, you can spin up a network load balancer using the load balancer service type. This will give you a public IP address that will then forward all traffic to the service. In AWS, this is ALB, but there is no filtering, no routing. It essentially gives you a public IP address and that's it. And this means you can send almost any type of traffic to this. You could be HTTP, you could be TCP, UDP, WebSockets, whatever you're using. Each service you're exposed with load balancer will get its own IP address. So oftentimes you need to pay for the load balancer service. This is kind of what where Ingress comes in, right, because we often see teams exposing their applications using one of these three methods. But as your application grows and scales or your application stack overall grows, you may have a new service for every single component. You might purchase a new cloud load balancer for each of these components. You might set up new node port services for each of these components, and each of these have different IP addresses. And what all you want to do really is bring traffic into your application using a DNS name or using a URL. You don't want multiple services exposed for a single application. And that's where an Ingress can help proxy requests to your services. On top of that, you might have TLS termination, URI routing and much, much more. So the Ingress would be a simple component that runs inside the cluster. It takes full responsibility for all traffic and routing from outside into the cluster using a symbol URI or FQDN or DNS.  Now the Kubernetes API, just to mention it, is the core of the Kubernetes server. It's what exposes everything inside Kubernetes. It allows every component to communicate with each other. And one of those API objects is called Ingress. Hence you create an Ingress resource. So, Mihal, we get asked often, you know, can I use node port in production or can I use load balancer in production? I think you summed up some scaling issues around that. Is there anything else that you would say about, you know, what you should be using in production? Absolutely. You can of course use load port or load balancer in production. It does depend on what you're trying to achieve, of course. Load balancer is probably the most popular way in cloud platforms, assigning a public IP address to an application. Node port is perfectly fine also. But the port of a node needs to be over 30,000. So you can't use 80 or 443 directly unless you have some form of load balancer in front. And therefore, if you have a load balancer in front of a node port, you have additional hops. It'll be client load balancer, node port, cluster IP. And then you have additional latency issues. Correct. Potential points of failure. All right, should we move on to some more depth about Ingress? Sure thing. Okay, so the Ingress controller is a component in a Kubernetes cluster that configures HTTP load balancing and some layer four also according to an Ingress resource. This is created by the cluster user. But let's not complicate this. The Ingress controller is essentially a load balancer or proxy with additional capabilities, brings traffic in, deals with layer seven and potentially layer four capabilities. When you deploy an Ingress controller, you create an Ingress object or an Ingress resource. The Ingress controller then uses the Kubernetes API to pull information from this Ingress resource and then configure a load balancer according to those resources. You might have multiple Ingress resources per application, application A might have Ingress A, application B might have Ingress B and so on and so forth.  This is just a public endpoint. It could be an engine X, for example, there could be a cloud load balancer or software load balancer or even a hardware load balancer. So this is what brings external traffic in using a public IP and that then points to an Ingress which then deals with all of the application traffic inside Kubernetes. Not only does the Ingress controller deal with traffic management. It has many other additional capabilities depending on what Ingress controller you're using. It could be monitoring, it could be telemetry, it could be security for that matter. So we're seeing many more Ingress controllers acting as web application firewalls. We're seeing advanced analytics and metrics get exported to additional tools like Prometheus and Grafana and Splunk. So the Ingress can be a very valuable tool in your stack to gather information to secure your applications and manage all of the traffic. So we have a very timely question in the Q&A from James. He asks, how is an Ingress controller different from a reverse proxy? Great question. There isn't a huge difference because an Ingress controller, if you look inside the container, it is a reverse proxy. It's proxying requests from the client to the application. The only real difference is that the Ingress controller is managed and configured by a Kubernetes API. So when you put together an Ingress resource in Kubernetes, the Kubernetes API accepts that Ingress resource and creates a configuration for the proxy. Nginx, for example. If you look at an Nginx Ingress controller pod, and if you look at the configuration file, it's a reverse proxy configuration inside the container. A follow up to that, Johanna is asking, so basically an Ingress resource is just a recipe for the Ingress controller. Correct. Exactly. The recipe is a good way of putting it. All right, let's go more into some of the use cases. I think one of these will answer another question we're seeing in here from Karen about how can I get the features of an API management and an Ingress controller. So let's walk through some of these many things that you can use an Ingress controller for. Right, good stuff. So we often use the term a Swiss Army knife or for Nginx itself, but the same thing could be said for the Ingress controller because it's very flexible. There's a long list of use cases that we often come across. It could be web serving, caching, load balancing and traffic management in general, but the Ingress controller can be your Swiss Army knife if you think about it. So as well as you have traffic management, which means proxying, which means load balancing, URI steering, TLS termination, session persistence, everything would use a load balancer for can be done with an Ingress controller oftentimes. If you look at visibility and telemetry and monitoring, I'm sure many of you are using tools like elk, Grafana, Prometheus, Splunk and all of these tools for monitoring and alerting. It could mean you're sending logs to external tools for logs analysis like Splunk, tools like Log Stash, Fluent D, all of these tools we see very, very often. If the Ingress controller is your entry point to your application running in Kubernetes, then then it does a lot of value for proper analysis and analytics for your applications in general. Security and identity can mean a lot of things. It doesn't simply mean firewall. It's a huge topic. We could easily spend a full hour talking about this, but we're seeing a lot more companies looking to add security to the Ingress layer in Kubernetes. This could be a web application firewall. It could be simply TLS or neutral TLS. It could be limiting the amount of requests a client could make and much, much more. You could mean authentication also, like validating JSON web tokens or offloading authentication to an identity provider using standard like OpenID Connect, for example. We're hearing a lot of, we're hearing zero trust a lot, which is essentially built around the idea that you should trust no one. All traffic should be encrypted. No IP should be exposed directly and all services require authorization. We're steering into service mesh territory here, but we won't go there. But one of the main use cases of a service mesh is securing traffic using encryption like neutral TLS, for example. API Gateway is another very broad topic. There's ongoing debate regarding using an Ingress controller as an API gateway. If you think about it, an API gateway is essentially a proxy that accepts client requests and sends those requests to an API endpoint. NGINX, for example, can be used as an API gateway. Many proxies out there can be used as an API gateway. So there is no reason why you cannot use an Ingress controller as an API gateway. Yeah. In fact, it's maybe a better choice because it's a Kubernetes native tool, right? You know, configuring it with YAML instead of whatever the config is for an external tool. Exactly. The Kubernetes platform is your management plane. It's your control plane to configure your API gateway. Most of the features we see from an API gateway perspective are things like TLS termination, GRPC support, authentication using tokens or API keys, rate limiting. All of these things can be done with an Ingress controller or many Ingress controllers out there. Actually, I should mention that this use case is so popular that I believe there is a new API, there's a new gateway API going to be added to the Kubernetes platform so that you can create gateway objects in Kubernetes. And on top of that, you can create different routes for different API endpoints. Yeah, it's going to be really interesting to see how people decide they want to use that new API. Let's see. I'm just going to take a quick gander at the Q&A to see if there's anything that we should hit now before we move on. We've got quite a lot of questions in here. Thank you, everyone. So we have a question here as per the diagram, which was on the previous slide. It looks like we can only have one Ingress resource per node in the cluster. Is that the case? You can have as many Ingress resources as you wish. An Ingress resource is created, it's cluster-wide. You can have as many as you wish, but usually an Ingress resource has its own host name, so you might have multiple hosts for each application. So application1.example.com, application2.example.com, a different Ingress resource for each. That's chosen will depend on the host header or the FQDN that you're using to access, but to answer the question, no, you can have as many Ingress resources as you wish. And a follow-up to that, can you please share in a little bit more depth the difference between the Ingress resource and the Ingress controller? Of course, the Ingress resource is a definition file. It's an object in Kubernetes that you create. And this is a YAML file, usually, and it has your routing rules, it has your host headers, and it has all of the proxy and configured in this resource. When you deploy this Ingress resource using KubeCTL create, for example, the Ingress, sorry, the Kubernetes API will accept this Ingress resource, and the Ingress controller will configure the load balancer based on that Ingress resource. So the Ingress resource, as we said before, is like a recipe. The Ingress controller will take that recipe and convert it into load balancer configuration. And so one final question on this topic, the Ingress controllers are queries like this, have queries like KubeCuttle get ingress-a. They're wanting to understand whether this is the Ingress controller or the Ingress resource. Yeah, when you run KubeCTL get ingress, this is putting an Ingress resource from the Kubernetes API. And is the Ingress controller at the pod level? Yeah, so Ingress controller acts as any other container in Kubernetes. When you deploy it, it runs as a pod, and then you expose the Ingress controller the same way you would expose anything else in Kubernetes using a service. You can actually expose the Ingress controller using node port or load balancer or cluster API. But yeah, it's a pod. And on a slightly different topic, is there any benefit to using more than one Ingress controller and is this common? Great question. Yeah, of course, you can use as many Ingress controllers as you wish in your Kubernetes environments. I don't understand the case, but we used to have Ingress classes where you could specify an Ingress class per Ingress controllers. You might have Ingress controller one for this team and Ingress controller two for another team. There are many reasons why you would have multiple Ingress controllers, but there are also other reasons why you wouldn't. It depends on the use case. If you need certain features of one Ingress controller and that other ones don't have, then that might be a reason why. You can do everything you need to do with one. You have multiple replicas of the Ingress controller running usually. It depends on the environment of course, but the whole purpose of having replicas of the Ingress controller is that you can scale and you can, you can deal with fail over if one of your containers fails as well. Okay, last question before we go talk about the landscape and the different types of Ingress controller options. How do you deal with multiple clusters? Another great question. Yeah, so when it comes to an engine X Ingress controller for example, or any other Ingress controller for that matter, this runs inside the cluster. When you have Ingress running inside the cluster, it's standalone. It's normally doesn't really communicate with other clusters directly. What we are seeing a lot more is global server load balancing in front of a Kubernetes cluster. So you might have multiple Kubernetes clusters. Each of those clusters have an Ingress controller. And you might have a global server load balancer in front that sends traffic to different data centers. Now, when you need an Ingress controller to send a request to an Ingress controller in another cluster. We call it egress, an egress route. And this is when we're looking at service mesh. When you have service to service communication or if you have an Ingress communicating with services outside communities, it can be done. And it's something we are seeing a lot more these days with global server load balancing combined with service mesh solutions. Thank you. So we do have a couple of questions in the Q&A that I think we'll address in the next section about the options of an Ingress controller, for example, versus an AWS ALB or a load balancer provided by a cloud provider. And so we're going to take a few minutes here to talk about the different categories of Ingress controllers that we see some pros and cons of each. And I guess what I would like to emphasize is there's no one best in Ingress controller.  And so we break the Ingress controller landscape down into open source default and commercial open source is pretty straightforward. Those are projects that are maintained by the community. It's possible that some may have dedicated engineering teams. So for example, at EngineX we do produce an open source Ingress controller that's maintained by our engineering team as well. And when we have the default category, we consider those to be the ones that are developed and maintained by a company that's also providing a Kubernetes platform. So that's your AWS, Azure, GCP, Red Hat, OpenShift, Router, perhaps. So in the third category, commercial, these are licensed products that are for large deployments. And so for example, EngineX also makes a commercial version of our Ingress controller that's more for the enterprise grade. So let's look at the pros of each first. Open source. A lot of people choose open source because it's free. And so that just makes it really accessible and easy to start with. They're community driven, and the feature velocity tends to be a little faster. So, Miha, let's talk a little bit about why people value a community driven Ingress controller project. Because we do see quite a lot of companies having, having that as a priority, right. Of course, yeah, community or open source in general is ideal. If you're just getting started, if you're testing, we have very low volume. And this applies to all software rather than just Ingress. With Ingress, open source is perfect for those new to Kubernetes. There's a lot of feedback from the community when you have issues or questions. The features are going growing very, very quickly. And some organizations actually prefer community developed tech. So open source is part of the culture part of the nature of the organization. And then with the default, these also tend to be either free or fairly low cost. Perhaps a bit more reliable than an open source option because you know that they do have a company behind it with the development team. And often there are some support options available. Miha, let's talk a little bit about the reliability of a default option versus perhaps an open source. What's the trade off there of, you know, moving away a little bit from open source with the trade off being reliability. So when you're using a, usually when you're using a cloud platform or if you're using a managed Kubernetes environment, you often get a default Ingress controller and this could be based on any technology. It could be a very popular open source technology, for example, but one of the benefits of this would be that you there might be full support for this ingress controller as it's part of the platform. And usually this is available to you at no extra cost. And this is usually a popular choice for teams newer to Kubernetes also. But if you're using tools like Amazon's elastic Kubernetes service or Google's Kubernetes service, they all have default ingress controllers that are supported. And then the commercial category. These tend to have the more full range of features that might not be available in open source or default that are going to enable those use cases we were just talking about around particularly security and identity, but also API gateway features. They tend to be much easier to scale and then support as well. So let's focus more narrowly on community support versus will say corporate support or support licenses. Where's the value there on having a support contract. And of course it's it does depend on the environment but there are many other production grade features of a commercial products that could just be features rather than technical ability might be certain features of a commercial product that might not be available in the community or open source version. This could be a replication firewall, for example, or the ability to integrate with a service mesh. But if you look at the support side of things. Things like CDs, for example, if an open source project has a known CDE commercial customers are using the first to get a fix for these for these security vulnerabilities. And on top of that as well it's confidentiality on top of that too when if you want to troubleshoot ingress controller for example. If you want to go to a public forum or stack overflow, for example, do you want to put your private log files up there or do you want to ask questions with sensitive data. So a lot of different factors to this, but confidentiality and full commercial support is obviously a huge feature of any commercial product, rather than on top of the features themselves of course. Okay, let's look at the flip side the cons with open source ingress controllers, we tend to hear from customers that there are three reasons that they, you know, maybe they started with it but they decided to move away. What you identified there with support is a big reason. There's a saying, I'm not sure exactly who originally said it free like a puppy. Maybe you may not have cost you any money but it's going to cost you a lot. Excuse me a lot of time. So what does it look like to be investing time because of an open source ingress controller. Yeah, so oftentimes, you end up spending more time on customizations and work around specific needs when using community software. There's always a cost to free software of course from training to actually support itself. So this could be, we see many other community versions of ingress controllers like engine X, for example, that are customized, they have advanced your code within the container. And this can be a learning curve or it could be performance issue on top of that. There is a cost, there's a cost especially when you have a team of people managing an ingress controller and all of a sudden that team leaves or any new resources managing the ingress and there's no documentation available. Yeah, and you know cost again falls under that default column as well but this time it's more about unpredictable costs. You know you get in for a low price. So what are the costs that can occur over time with these default options. So, when it comes to support options, it really means how long does it take you to get a response. I'm sure a vast majority of questions, asked in community forums are potentially unanswered, for example. On top of that, most are self solve, it's just you and the docs. So if you went into problems that you can't solve ourselves it can be difficult or impossible to get help. What's about your only choice is to post your problem on the public forums and hope that somebody responds. And then infrastructure lock in being another major drawback for the default options. I think that's one that probably doesn't get talked about a lot. We're moving to the cloud but we're seeing a fairly high number of our customers using multiple clouds. And so let's say you're using both AWS and Azure, you know, a KS and EKS. What are going to be the ramifications if you're using the default options in each of those instead of an option that's the same across both. Yeah, so you might have multiple clouds, of course, or multiple Kubernetes platforms that have different ingress controllers, and oftentimes different ingress controllers means different configuration language, maybe they're using custom resource definitions for example some ingress controllers actually have their own custom resources to configure them. And usually when you're dealing with some platforms you have to use or the first option to use is the default ingress controller that comes packaged in the platform. And if you have another cloud or another platform with a different ingress controller can be difficult to move from one to the other. You might need different ingress controllers for each deployment. It can cause tool sprawl increases the learning curve for the teams, and it just makes the ingress controller a lot more difficult to to maintain and manage. Yeah, so it's not just that you're going to have, let's say three ingress controllers for three different clouds but you're going to have to probably have three different WAFs as well.  Okay, so the commercial cons. One con is kind of again the flip side of what's great about open source projects is commercial projects develop a little bit slower, and the reality is their license so they cost money. So what's the, the, the issue that people are weighing when they're looking at slower development with a commercial product. Yes, one of the most important features of a supportive product is, is that it needs to be stable, right so it's stability is very important for commercial ingress controllers or commercial software in general. Their feature velocity might lag a little bit behind the open source counterparts, because with the open source counterparts people are forging and people are adding features continuously daily using DevOps methodologies. Whereas with commercial software or enterprise software new features are tested intricately. And sometimes community versions actually have certain features that the enterprise version don't have yet using lower code or JavaScript so yeah there's a there's a lot of differences pros and cons of course but because stability is so important it can take longer to get features in commercial software. For sure. So, over the categories where we're going to focus in right now is an area that we find there's a lot of confusion. InginX is the most popular widely used technology under the hood for ingress controllers, but that doesn't mean every InginX ingress controller is the same. So we're going to pull out two that commonly get confused or we'll say three falling under two categories. So the first, if you Google Kubernetes ingress controller, one of the top results is going to be this one under the Kubernetes project. So you can kind of identify them quickly and easily by looking at the GitHub repo so that'll be Kubernetes slash ingress dash InginX. So this is one that's based on InginX open source, it's completely free and open source, it's developed and maintained by the community. And so they're using forked InginX with Lua and open rusty to kind of achieve some of those more popular components that people are looking for. And then the other item that's going to come up if you're Googling or searching for InginX ingress controller will be the projects that are maintained by InginX ourselves. And so, again, looking at GitHub, that's InginX Inc slash Kubernetes dash ingress. So we're the source code owners for both of these based on InginX open source or based on InginX plus. And it's a combination depending on which one, whether it's developed and maintained both by InginX and the community or just by InginX for the plus based version. Rahal, when people are trying to understand these ingress controllers, you know, you have quite a bit of experience with this having worked directly with users. Where do you see confusion or difficulties? Yeah, it's a great question. So with, so yeah, the fact that there are multiple InginX ingress controllers is confusing enough as it is, right, because the most popular ingress controller out there is actually the InginX community ingress controller that was shipped with Kubernetes by default originally. The only differences between the two, but InginX open source versus InginX community is that the community version does have some additional logic, such as Lua and OpenResty as you mentioned, Jen. But on top of that, there are some performance hugs and that's things like service discovery in Kubernetes is probably one of the biggest features that we have in the plus version. So for example, if you were to scale your applications within Kubernetes, one of the features of InginX plus is to actually resolve the DNS service as it scales within Kubernetes and updates the InginX configuration immediately. I believe with the other versions that uses some newer code to continuously check the number of replicas of a pod running. So that can lead to some performance issues. What are things like health checks, for example, like we believe active health checks or something that are developed using Lua, which are available in InginX plus. But it depends on the features, right? What do you need? Do you need active health checks? Do you need session persistence? Do you need authentication using JSON web tokens? All of these things will determine what ingress controller is best for you. The open source community version is a brilliant solution for testing purposes and for practicing how to configure ingress and configure application traffic management in general. All right, we're going to go ahead and launch another poll as we start to close in on the last 10 minutes of our session. And so this final poll, I can click all the buttons. We'd like to know what ingress controller category you're using. You can select more than one. Are you using an open source option such as that community one from Kubernetes default. So something that's in a cloud provider or Kubernetes platform provider, commercial such as the InginX plus one. You don't know or you're not using one yet, or if it's something not covered somehow in those categories, let us know in the chat. Michal, when you talk with people in the field, what do you commonly see? I commonly see the community version. So ingress dash InginX is probably the most popular ingress controller out there, I would say. Even if you're learning Kubernetes, most of the training courses I've completed usually use this version also. It's like the default. It's the first one that you probably find when you Google an ingress controller. And so we have about a little over half of people have responded. We'll give just a couple more seconds to let us know what type of ingress controller you're using. And we should mention a couple months ago InginX made a commitment to actively work on the InginX or the community version, the Kubernetes version. And so we're looking to actually contribute engineering to that to really help make it stable because it is, like you said, very popular and the entry point for many people to Kubernetes. It'll be also interesting to see where things go with the API. So we'll go ahead and close this poll and show the results. So again, no surprise here. The majority of people are using an open source option, followed by default. We've got a few people using commercial, a good chunk either don't know what they're using or aren't using one yet, which is also very common. And then some people said that they're using something else using contour. And then I see a question there if you have a question, please make sure you put it in the Q&A. And that brings us to the end of our prepared content. And so there's a couple of scenarios we're going to discuss and we'll try to get to as many of these questions I see 17 in there so we definitely won't get to them all. Mihal, when you're working with people who are testing ingress controllers, you know, setting up a proof of concept, what does that look like? How do you, how do you choose one and make sure that you choose the right one? Great question. Yeah, so I would highly recommend putting together a success criteria if you are testing ingress controllers. Oftentimes, if the use case is simple, you need simple load balancing, you need some health checking, for example, then any standard ingress controller will do the job. It's other things such as, do you need load balancing for HTTP2 services? Do you need GRPC? Do you need layer four, like TCP and UDP? Do you need rate limiting, canary testing, traffic splitting, all of these advanced features are the type, the kind of thing that would lead you to test other ingress controllers that are maybe more feature rich, I would say. But I would recommend you do a POC if necessary. There's no reason to settle for a one trick pony. Most ingress controllers can do everything you need to do. But if you need additional problems to solve, let's say you need a web application firewall, you need authentication using OpenID Connect or you need JSON WebToken authentication. Those are the types of things that we see customers asked for, and then that's when the POC comes in and that's where we start to configure more of a feature rich solution. So you mentioned another tool earlier in the session. In short, how is a service mesh different from an ingress controller? Great question. So service mesh goes a little bit deeper than an ingress controller. So the ingress controller is responsible for bringing traffic into the cluster. So it supervises and controls traffic coming in, also known as north-south traffic. But when you go deeper into the cluster or deeper into the application management, ingress has no visibility or control over the traffic flowing within the application. This is known as east-west traffic. Let's say you have one application and you have multiple services and communities for that application, and they all communicate with each other. Service A communicates with service B. The ingress controller cannot see that, so it cannot do open tracing, it cannot do monitoring for those services, and it cannot encrypt traffic between service A and service B. This is where service mesh comes in. Service mesh comes in when you need more granular control of east-west or service-to-service communication within Kubernetes. One of the most popular use cases or popular features of a service mesh would be encryption, encrypting all traffic between your services within Kubernetes. Another would be better visibility, having logs, having metrics, having open tracing between your services, and others being more advanced traffic management, AP testing, circuit breaking, canary testing, all of those things, where you get more deeper into the traffic management sort of things. There's a big difference to answer the question between a service mesh and an ingress, but at the end of the day, it's proxy. You are proxying, but a service mesh allows you to have more control over proxies or sidecar proxies for your applications. Yeah, and I'll go ahead and drop another link. We do find a lot of people actually start exploring a service mesh before they've even implemented an ingress controller, which you can do, but you want to make sure that you're actually kind of checking some box to make sure you get value from that service mesh. And so I'll share that in the chat in just a moment. We do have about five minutes left and a whole host of questions in here. We have one on what is the link between IngenX and Ingress. Is Ingress just IngenX in a container? Quick question. Technically, yes. An Ingress controller, an IngenX Ingress controller, if you look at the container, if you SSH into the container and run IngenX-v, you will see IngenX running in the container. The Ingress controller is it has an additional daemon to configure IngenX. So when you configure an Ingress resource in Kubernetes, the Kubernetes API takes this resource and configures IngenX using that Ingress resource. So yeah, it's an IngenX container, but the Ingress controller converts the Kubernetes Ingress resource into an IngenX configuration file. Okay. Does IngenX Ingress controller modify the response header mainly for error response? Not by default, but it can be configured to do that. You can manipulate request headers and response headers using IngenX. And then we have another question. Does IngenX-plus-based Ingress controller support multi-cluster Kubernetes? Great question. That is actually more of an egress query. So yes, the Ingress controller can send egress traffic, which is traffic outside of a cluster. And that's a very broad topic as well because you might have multiple clusters. You may need a global server load balancer to bring traffic from Ingress 1 and cluster A to Ingress 2 and cluster B. But yeah, egress is supported. Okay. Does IngenX handle cores, C-O-R-S? Yeah, IngenX by default can handle cores. Traditionally, this would be done using an IngenX server on a virtual machine or a physical machine. But from an Ingress perspective, you can do it that way as well. Okay, I'm looking at about two minutes left. Oh, let's see here. I don't know, Mihal, if you saw any that you really wanted to answer. Let's start with Johans about which is the most used or popular orchestration platform. I would say that depends on where you are and what your organization is. You know, we see high compliance industries gravitating towards the likes of Red Hat OpenShift. I know you've done a lot of OpenShift work in Amia. You know, the more cloud native ones are tending to use the cloud providers, companies or organizations with open source mandates will often go with Rancher. What are you seeing as the leader or is there a leader at this point? Yeah, it's a good question. You're right though. It does depend on the region as well. I've noticed that cloud platforms are very popular in certain areas. Other regions may have physical because of the security reasons. So yeah, I would say I don't know who the leader is, to be honest. But what I do see very often are the likes of Red Hat OpenShift, of course. I'm seeing VMware, Tanzu, Rancher, managed Kubernetes clusters, as well as the cloud platforms, AWS, Google Cloud, of course Microsoft has zero managed Kubernetes also. I think we've hit the end of the questions we can answer in the time we have. There were a lot of technical ones in there and I see a request in the chat to have a follow-up session covering a more hands-on approach. We'd love to do that. We also have a YouTube channel. Look for Inginx Inc on YouTube. And there are a lot of demos and other types of videos on there. We have done some quite a few in-gress live streams. So with that, I think we're about done. Thank you so much to Jen and Mihal for their time today and thank you to all the participants who joined us. As a reminder, this recording will be on the Linux Foundation YouTube page later today. We hope you're able to join us for future webinars. Have a wonderful day. Thank you. Thank you.


What's up everybody Jason here for jazby's case base comm this sells out spectra 2021 football 2 box picker team number 3 random number block For the bucks eagles and Steelers and you get a piece of these three teams for a fraction of the price You would have paid for all of them and again we get Randomized the customer names and numbers from 0 through 9. You can randomize the number Here's your example. We go by the first number on the left side of the left side of the show number dash and of course any one-on-ones go to Spot one from these three teams that pop out of the break any Redemptions go to the tee go to spot zero and of course any non-number cards are randomized to the group So there's a dice roll of this because we're named Kevin down to Patrick and then from zero one two three four five six seven eight nine Let's dice roll it two to one or one of two three times one two three boom Mark at the top down to Patrick Then we've got three times one two three Boom Eight down to seven All right, so mark with eight Kevin with one any one of one Stephen Kendrick with two Patrick with zero and in all redemptions as an end spot And I mark with five Patrick with three Kevin M with Four Kevin Dixon with six and Patrick with seven There there you go guys so coming up next is to break itself. Good luck everybody


Question is from Captain Unimpressive. How do you go about fixing externally rotated feet?  Yes. Oh man. Yes, I definitely had a few clients like that where they could turn their feet all the way like this. Oh, that's how they stand? They always wanna pivot out to balance and to stabilize. Yeah, I've worked with a few, but I remember the first time I worked with a dancer, the external rotation that she had and that dominated her movements was like a conundrum for me at the time. I remember thinking like, how do I work with this? She's got such good mobility and stability when we squat. Is that really good form? Even though her feet really turned out, I couldn't figure it out. I remember consulting with one of my co-workers who had been a trainer for years was also a physical therapist. And he kinda walked me through what to do. What you'll notice with rotated feet, feet that turn out, oftentimes is that knees also like to go apart when they do exercises. So, here's a simple exercise. Well, this is more rare. We've talked about the band or the basketball between your legs. This is the case where you use the basketball. And that's what I was just gonna say. This isn't gonna be great for everybody, but for a lot of people with this issue, here's your- I've had a lot of these though, it's weird. Have you really? Yes, I have. This is more rare. This is more common for clients I've had. Wow. Wow, then pronating? Yes. Oh, wow. See, I've been dealing with this a lot. I'm with you, Adam, but I have had it a few times. So, great exercise.  So, you have to squeeze together as you do the squat to encourage, you know, that kind of hip activation. Before we even get started on, you know, any squatting day or anything, I typically I'll take like a rubber band and I'll do a lot of adduction and, you know, get the everything primed in terms of like internally, like moving everything inwards. And then, yeah, stuff like that. And then we'll do hip ridges all the time, like squeezing a soft medicine ball. So, yeah, just constant stuff like that. And then also just like, I have her do a lot of walking patterns because, you know, you could just see it already, like the tendency wanting to externally rotate even on every single step. And so just to have that sort of intention and then, you know, bring the feet in good alignment and, you know, there's a whole process to it. And it's just like constant thing because so many hours and so many years have been put into these pivoting moves that you're just going against like completely hardwired system. Yeah, so I love those movements as corrective. And then I like strength building stuff to be like single leg stuff. So doing like a single leg toe touch. Keeping everything straight. Yeah, so yeah, exactly. So they're gonna start to work on, so doing a single leg deadlift, single leg toe touch, pistol squat, like doing movements like that after you've done the corrective work, like we're talking about. Because the exercises we're talking about now are more corrective to like address what's going on. For me, though, that was more rare. So that's crazy that it was very rare I had to do that at Duck Field. And it was probably dancers. And you're probably right, like the people that all of them I can think of were dancers. Most common for me is the internal rotation and pronation of the feet. Oh, it's interesting when you work with an athlete, you can see how their body has formed around their sport. And dancers, you know, I've worked with a ballet dancer and that's the one I was talking about, where her feet were super turned out very naturally. And her posture was so exaggerated. Her posture was so tall and so exaggerated that it was actually, we had to correct that with exercise because it was too much. It was too much of this head tall type of posture. So I had to work on offsetting that a little bit. Did she have knee issues as well? Knee issues because of that and some neck and shoulder issues also. So I had to work on some of that. But another thing you can do is you can focus on internally rotating very basic. Lay on the floor and your feet wanna go out, right?  And create that tension, hold that for a good five to six seconds and then relax and then do it again. Just connect. I'm gonna add one to that.  So the toes up and you're on the heel and your legs straight. And then I'm adding that tension and I'm like turning my whole leg in. So get that hip or internal rotation. I believe you did a YouTube video on that. I think so. That was back when we were doing videos at the other gym. I think you did a good video on that. We have one from Serene coming that is a move I've actually never seen. I forget, I don't know what she called it, but I was just, I was watching Eli edit it yesterday and loved it. So it should be, when this episode goes live, it'll probably be coming in that week or so. Whoever asks this question, if you follow up with me and you don't find it, I'll find it for you. It's funny, I remember I worked with a boxer once and or no, I've actually worked with a few boxers and boxers just have this forward shoulder position. It's beneficial when you're boxing. You gotta keep your shoulders up and forward to cover yourself up. But when they, when we're doing exercise or whatever, it's like, okay, that's the problem. Now here's the other thing too, if you're a trainer and you're listening, if that person you're training has these attributes or these movement patterns related to their sport and they're still competing at a high level with their sport, be careful of over-correcting the problem. Because you can actually, because a ballerina with really externally rotated feet, if she's performing at a high level. It's advantageous for her. It's advantageous. If you try to correct it too much, same thing with a boxer, the forward shoulder, if I have them stand with good posture, fix that real good, and then he goes in and gets a boxing match and now it's not natural for him to cover himself up like he was before, it can cause problems. So typically these were people that I worked with when they were done. You know, when they're done, they're just trying to live normal now. That's it.


You wanna know the two biggest roadblocks to prayer? The first one is pride. We think we can do this thing on our own. When life is going well, why do we need to ask God for anything? We are the rebellious child and he is the loving father that we want nothing to do with. The second roadblock is shame. You see, when the pride fades and life turns out to be more than we can handle, shame so easily consumes us. I'm such a bad Christian. I don't read my Bible enough. I don't pray enough. God probably hates me. We listen to the lies of the enemy and in so doing, we rob God of the honor and worship that he is due. And further, he desires to be in relationship with us. Let us then draw with confidence to the throne of grace that we may receive mercy and find grace in our time of need. Hebrews 416, follow for more Christ centered content and help support my ministry on Patreon.