Hi everybody. Welcome to the DevNation Tech Talk. This month I'm going to be talking about Red Hat developer hub. It's actually a really cool thing to talk about at the moment because everyone's going nuts on backstage. So what I'm going to do is I'm going to do a presentation which explains the ins and outs of IDPs, what backstage is, what Red Hat developer is on top of that, what it adds to it in terms of the things called plugins. And then I've got a nice little demo to show you how to actually play with it. We've also got a way in which you can actually start to play with Red Hat developer hub right now for free. And I'll explain how you do that at the end. It's to do with actually logging on to the sandbox and doing an installation of the developer hub onto the developer sandbox. But anyway, what I'll do is I'll start with the slides and then I'd say if you've got any questions while the talk is going on, please feel free to put them in the chat and I'll address them as I see them. So what we're going to cover today is basically why we need what's called an IDP. It's all about the fact that developers' lives are hard. And to give you a tiny bit of background, I worked for Red Hat. I'm currently a developer advocate. For 10 years before that I was a solution architect working with the various customers in the UK. But before that, I used to actually work for a living. And I was a software developer in the UK government space for a long, long time. And I used to have a lot of problems as a developer, not in terms of developing software, but just in getting used to the things that were around me, the tools, the frameworks, all the wasted time you had with building boilerplate code and being wound onto projects and stuff like that. And the whole goal behind the backstage, the Red Hat developer hub and the context of an IDP is to try and solve those problems. So we'll be covering all these things in the slide deck today. I normally go through them, but it makes more sense just to actually talk to them as we get to them. So the first thing I want to talk about is the life of Dev being hard.   And a developer wants to develop. We're creators. We like writing code. We like solving problems. But the amount of friction we get from actually dealing with the tools and the sheer volume of tools nowadays is making it too hard. Now, there's a technical term for this and it's called cognitive load. It's the amount of effort your brain has to use to actually deal with these things that actually add nothing in context to the software you're writing. And it all comes down to the fact that technology has become so varied and complex that it's hard to just write that code. I say, if you're thinking of your frameworks, your boilerplate, the patches, the environment, your heart, you're very hard pressed to find brain space to think about efficient and elegant ways to actually write the source code itself. And the goal behind this, the backstage, the Red Hat developer hub and the whole concept of IDP is to reduce the effort and unnecessary thought processes you need when writing code. And that's the simple statement of it. That's what it's designed to do. I say, in the old days, I used to talk to customers about what we call the 70-30 problem. And the 70-30 problem is, you're paying for a developer to write code. And on average, back in the day, you'd spend 30% of your time as a developer actually writing code. And 70% would be installing frameworks, installing libraries, setting up the machines you were working on, and writing boilerplate code. And you would spend so much time burning that kind of effort and not actually writing code. And it was accepted that there was an overhead for developers. But it takes a toll on you as a developer because you're spending so much time concentrating on other things. So the solution to this is something called an internal developer platform. And an IDP is effectively built by a platform team to enable developer self-service. And that's quite a broad statement about that kind of covers it. And it provides, amongst other things, a single point of entry for a developer that has all the tools, guides, documentation, and access to the environment that a developer needs to do their job. And it also supports something called software templates, which are a type of pipeline for guiding the developer through the process of setting up to start writing software. And it also produces a simple and easy to use with less cognitive load mechanism for producing software. And those are the goals behind the IDP. Basically, put it simply, an IDP allows you to open a browser, go to a portal, and everything you need as a developer is there at your fingertips. All the kind of having to have separate tabs for Google, separate tabs for your OpenShift interface, your Kubernetes interface, separate tabs for Sonicube, and all these kind of things disappear. You have a single portal of control and everything you need as a developer is in there. So why do we need an IDP? Well, we need an IDP because organizations are different. You know, you can't come up with a single solution to this. You know, whilst reducing a developer's cognitive load, you can have an IDP that mandates an approach. It can't be too opinionated.  And every organization has subtly different ways of doing things. You have different mandates on the technology they want to use, the approaches they do to actually doing this, the projects, the whole thing. And the concept of a completely configurable IDP is a perfect solution for both problems. With a perfectly configurable IDP, you've got the ability to produce a single point of contact for the developer, but you've got a configuration that allows the organization to produce the tools that are particular to them for the developer to use. And it's all about easing the developers into it. Yeah, when you start on a new team or a new project, there's always that horrible time when you're trying to learn where things are or what you have to do and where JIRA is and where your swim lane tools are and all that kind of stuff. It's not a fiddly couple of weeks to get to that position where you can start to write decent code. And often these processes within an organization are similar to other teams and other projects, yet you're hitting the same problems every time you start a project or join a new team. And a good IDP will provide a configurable mechanism for automating that process. And in the case of Red Hat developer Havin backstage, these are what we call software templates and we'll go into those in depth later. But before we talk about the whole concept of the IDP, I want to very quickly introduce what we call the inner and outer loops. And there's a nice visual overview here. I mean, this is a good visual representation of the theory behind the current state of the DevOps situation. You've got what's called the inner loop, which is the actions of the developer. And the developer just focuses on this. They code, they build, they debug, they push, they repeat. You know, your job is to write code, to test code, to get code to a point where it can be delivered. And the outer loop is the options of the platform engineer and the ops person. And that's driven by the arrival of source code. And it's the review, the build, the check, the test deploy, or triggered by the push action within the inner loop itself. Now, the IDP, the Red Hat developer Havin, the backstage is designed to cater for the inner loop, giving the developer all the tools they need to be able to work consistently in that inner loop. And it's what a developer actually does within the inner loop. So the inner loop concept is a nice abstraction, the process of writing and deploying software. And the inner loop is the action of the developer, code, build, test, commit, whereas the outer loop is the automated action of the ops engine, build, scan, test, and deploy. And the crossover point, as I said, is the submit action of the code delivery. So we're going to give a quick introduction to backstage here. Now backstage is incredibly trendy at the moment, everyone's talking about backstage. Now backstage is an open source project released to the community by Spotify. And to put it simply, put it incredibly simply, it's a database of manifests and catalog entries and a mechanism to build a portal for a developer. At the end of the day, backstage is a web app. It's a complicated web app, but its output is a web page, a web output is a portal that actually interacts with the developer itself. And the strength of backstage is its concept of what it calls plugins. And these plugins, which actually plug directly into the source code of the web app itself, allow for the extended visual and programmatic components. What I mean by that is that when you install a plugin into backstage, it provides additional visualization components that can be served to the user as part of the portal. And it also provides a number of actions that can be consumed to call external processes. And this will make a lot more sense when you understand other covers what backstage actually is. So what's the downside of backstage? Well, backstage is a clever and elegant framework. And it's a framework. As such, when you install backstage, it gives you the scaffolding for setting up the ability to create portals. But there's no real content as such when you actually install the base backstage. It's got fantastic extensibility. But if you install backstage and go to the portal it creates, it's generic. There's almost no content in it whatsoever. It's just the framework. And as such, it requires ops staff to create manifest templates, plugins to actually configure it specifically for the end organization. And that goes back to what we were talking about with an organization needing it to be specialized for the way in which their developers work. And also being open source, and we love open source, but open source is community supported. And this thing can be a beast to install.  But the minute you start to include things like authorization, like plugins, it becomes a little bit more complicated. And it's quite difficult to debug. So when talking to customers that now we're using backstage, it is that situation of getting backstage up and running that is the issue and getting it running in such a way that it's configured for the way the developers want to use it. So what is Red Hat Developer Hub? So Red Hat Developer Hub is a productized version of backstage. We're going to be honest here. Red Hat Developer Hub is backstage. But instead of actually downloading source code, what you do with the Red Hat Developer Hub is you download a pre-built and a pre-opinionated image. Now, what I mean by pre-opinionated is it's got a lot of stuff pre-installed. It's got a lot of configuration set up. It's still got the extensibility. It's still got the ability to add plugins and do all those things. But it gives you a much quicker start point. You know, if you're installing backstage, you download the source code. You do a Yarn install. You then run it and you get this portal out of it. When you're using Red Hat Developer Hub, you get access to a pre-built image. You just execute that image as a container. And you can run it as a container on RHEL. You can run it as a pod within OpenShift for Kubernetes.  And it also has a number of supported plugins which extend the visualization and the functionality. But they're pre-installed. So out of the box you get a certain number of plugins already installed so you don't have to wire them in yourself. And that's the beauty of it. As a question of the thing, backstage should be used to orchestrate self-service deployments of infrastructure as code. Absolutely. And I'll get onto how it does that in a second. In fact, I'll do it now very, very quickly. One of the plugins that come out of the box with Red Hat Developer Hub is a plugin into Argo CD. So if you're doing, for example, Kubernetes distributions or OpenShift distributions, you can actually use the Red Hat Developer Hub to build your manifest and then control the placement of those manifest on target clusters. So yeah, but what you've got to think about with backstage and Red Hat Developer Hub is it's a framework.  There's nothing in the base backstage. There are some initial plugins they provide for talking to GitHub and GitLab and all those kind of things. But they have to be installed.  With Red Hat Developer Hub, there's a huge amount that's pre-installed and the ability to actually add additional plugins through something called dynamic plugins makes it much easier. There's a caveat with direct plugins, but we'll get onto that when we talk about plugins. It gives a single pane of glass for developers that anyone's used backstage has seen a screen very similar to this. So the Red Hat Developer Hub is an opinionated version of the backstage portal. And you'll see on the left-hand side it has a navigation panel. That navigation panel is extensible, but there's a number of core components. We'll talk about those when we get into the Red Hat Developer Hub. It also allows you to extend it from a developer perspective. So if you've got the correct R back, you can add objects to it. And we'll talk about what underpins it in a second, but put simply everything within backstage and OpenShift works in the same way as Kubernetes. It's based on an object model, and that object is a declarative object that's defined in YAML. Now the nice thing about the interface and the portal itself is it encourages extensibility. So if you've got, let's say, an API you want to add, if you've got the API definition defined in YAML, which is understood by Red Hat Developer Hub or backstage, you can just add it as a component of the hub. And what it does is it actually processes it, but it brings in the swagger so you can see the API definitions and where you go. But to understand how backstage and Red Hat Developer Hub works, you've got to understand that there are two views into this product. As a framework, both backstage and Red Hat Developer Hub, which of course is built entirely on backstage, and we need to keep stressing that. We're doing a lot of extensions to backstage in terms of role-based access control and much better authentication and authorization. We're also doing the dynamic plugins. Now those things, changes we've made are being fed back in to the upstream backstage. So you can go and install backstage once we actually committed this to the upstream and you'll get those features. So we're being very open source about this, but at the end of the day, Red Hat Developer Hub is based 100% on backstage. And they are, to put it simply, their web applications. And they work by serving a portal to an end user that is based entirely on configuration of the framework at the server. And this creates two distinct percent of the use Red Hat Developer Hub stroke backstage. The first one is the maintainer. And that's the person who configures the server side Red Hat Developer Hub or the server side backstage. They're the person who actually pre-fills the templates, installs the plugins, sets up the learning paths, sets up the technology radar, sets up all those things that'll actually be portrayed and pushed to the end user as part of the portal. And then you have the consumer, and that's people like me, the developer, who actually work with the provided portal that it gives. So when I log on to Developer Hub, when you see the demo, I'll show you it from a user perspective. This is what you see from a user perspective. This is how you interact with it, this is what it does. But there are two distinct personas and they've got different skill sets. The maintainer needs to know how the engine works, how we can add things to the engine, how to track objects within the engine. And the consumer needs to be a developer, and that's the key thing about this. The portal that's provided is meant to ease the developer's access into the software, into the writing of the software itself. So it's a very, very nice way that you don't have to have any knowledge of how Red Hat Developer Hub or backstage works in order to consume the portal and use it from a developer perspective. So we'll talk about the framework of Red Hat Developer Hub now. So we're going to get down into the gritty, what actually underpins the concept of Red Hat Developer Hub. And it's based around an object model, very similar to Kubernetes. And I said the object model drives the capabilities of the provided portal. So for instance, there's a database that backpins backstage, backpins Red Hat Developer Hub. When you install Red Hat Developer Hub on let's say OpenShift, you use a Helm chart which will install a Postgres database and the application itself. The application itself uses the database as the truth. Everything in the database is actually rendered within the portal. So if you can think of the application as a sausage machine that's consuming the objects that define the database and providing the portal. And these objects represent identically the way that we do it with Kubernetes, using a declarative YAML format. And you can probably see on the right-hand side I've got a template definition. It's a template object within the actual Red Hat Developer Hub. And the template defines things like parameters and the steps that are executed as part of the template. Interestingly enough, when we get onto templates in a second, when a template is actually embedded within the system, the end users can then instantiate it and by instantiating it, what the Red Hat Developer Hub does is it processes the template and generates a number of wizards to actually prompt for all the parameters and steps, and then it executes the steps using actions that are defined in plugins. And those plugins provide external connectivity. So we've talked about Red Hat Developer Hub and Backstage being a framework that generates a web page. There are plugins for the actual Red Hat Developer Hub and for Backstage that do GitHub, and that provides GitHub Actions. Why do I say GitHub Actions? It's like GitHub colon fetch or GitHub colon clone. And the visibility of those actions within the template calls the actual action in the plugin. And you can see if you look very, very closely there's a fetch colon template action in here and one of the steps. That fetch colon template is one of the actions of the internal plugins of Red Hat Developer Hub that actually goes and gets the actual template code itself. You give it a URL and you give it some values to embed in it. So it's that kind of fantastic extensibility where you can add plugins that provide actions and then write templates that a developer can use which actually uses those actions. It's a very extensible system. The core component in both Backstage and the Red Hat Developer Hub IDPs is the catalog. And the catalog basically is the central store that the user sees of the active objects within the Red Hat Developer Hub application. And it close all the templates, components, resources, users, APIs. There's a level of R back on there in terms of controls and visibility and it's self-filling. So if you've got a certain type, for example, if you look at the pull down there, that was done on a Red Hat Developer Hub that had a huge amount of objects created within it. And you can see it as APIs, components, groups, locations, resource, system, templates and users. When you install, after this session, if you want to go and install the Helm template on the developer sandbox, you'll get a catalog that has two or three items because the base database only has locations and components in it. You can add yourself as a user of which point users become. But this catalog gives you visibility of all the objects within the system that you can see. And this is where you go after you've created things. This is where you go when you want to actually look in on the components that you've physically created within the Red Hat Developer Hub. So now about understanding plugins themselves. We've talked about the base framework. The plugins are the real power of the Red Hat Developer Hub and the real power backstage. By design, backstage is an extensible framework. As I said, out of the box, it's an empty framework, just maintaining the base objects that it actually provides. And the plugins provide backstage with the ability to extend the visualization of the IDP for the end consumer. And it does that using tabs. I'll talk about that in a second. And it provides executable external end points for inclusion in the templates. And those are actions that are provided by an external source like GitLab or let's say Kubernetes or OpenShift or Argo CD or Tecton or things like that. If you look on the right-hand side, that is a screenshot from Red Hat Developer Hub. And this is basically visualizing one of the components in the catalog. So I've gone into a template and I've created a component from the template. In reality, what that template did was it copied a Git repository into my Git repository. It built the appropriate pipelines and Argo CD manifests and it deployed that application into OpenShift. So basically, it used Argo CD to deploy a Tecton pipeline. That pipeline was executed and that generated the components of the application itself. What you're seeing on the right-hand side down, I'll show you this as part of the demo, as well as the tabs in the actual portal itself that are plugins. So we've got a plugin that comes in Red Hat Developer Hub that plugs into the topology of the target Kubernetes or the target OpenShift system. So this template actually creates components in an OpenShift cluster and then gives you the ability to actually drill down into those components through a topology page in the same way you would do as if you logged into the OpenShift user interface. The advantage with this is you're going to be able to do all of that in one portal. I can do all my creation. I can do my instantiation of my templates. I can look at APIs. I can go and read learning paths. I can generate documentation for my software, but I can also look at the software running in the OpenShift cluster and there are other plugins in there for Tecton so I can see the active pipelines that are executing on my cluster. There's an Argo CD plugin that allows us to develop a hub via the plugins that are provided. Now the good thing about this is that the RHDH Red Hat Developer Hub comes with a number of fully supported plugins and these wrap Red Hat technologies, they're core components that we brought out of other products that are directly useful to developers. Now the advantage of this is that they are fully supported out of the box. So for example, there are six currently and it's going to grow. There's a lot more in. There's stuff coming in terms of secure software chain. There's stuff coming in terms of S-bombs and all those kind of software material things. But at the moment when you ship you get a plugin for authentication authorization with key cloaks. That installs key cloak and allows you to interact directly with key cloak from within the developer hub itself. So if you're building an application that requires authorization, you can build the authorization components using the key cloak. You can connect that key cloak instance and authenticate. We've got GitOps with Rgo CD and that's a visualization panel from Red Hat Developer Hub that visualizes the application components from Rgo CD. For those of people who don't know what GitOps or Rgo CD is, it allows you to basically take a set of defined declarative YAML from a GitHub repository and push that to a target cluster, OpenShift cluster or Kubernetes cluster. The advantage of that is Rgo CD then sits there and watches the state of the objects it's created and the state of the Git repo. If the objects change let's say you've got an application that's defined to be 15 replicas and some developer logs onto the OpenShift cluster and lowers it to 14 or 13 or 12 Rgo CD will reset it to the value defined in the GitHub repo. If the GitHub repo changes let's say an admin comes along and wants redefine the deployment or redefine their number of replicas for the application. He can change the declarative YAML and push it into the Git repo. Rgo CD will instantly see the push into the Git repo, take the information and apply it. It's a compliance engine that makes sure that the application definition on the cluster always matches the definition of the Git repo. That plugin allows you to see that visualization within the developer hub and again this is what this is reducing is the cognitive overload of the developer having to leave this page to go into another system to understand the mechanics of the other system to find the components within the other system. It's designed to make it incredibly simple and easy to visualize all the components he needs and developer needs he or she needs to actually do their job. The third one is pipelines with Tecton. That works exactly the same way as the Rgo one. It provides visualization within the Red Hat developer hub portal of your active pipelines. So you can see the pipelines are in flight. You can see results of previous pipelines . You've also got the application topology for Kubernetes. You saw that in the screenshot and that's that topology vision of the application within a name space and that's got drill done as well. So you can click on the roundalls and it will bring up the pods. You can click on the pods you can click into the logs. As all the functionality you would normally have to leave your development environment leave your IDE and go into open shift or use OC as a command line to go and see but with this you just move to Red Hat developer hub portal itself. We've also got a visualization component for container image registry for key. So if you've got key locally or you're using the public key.io this gives you visibility of your images. So you can look at the tags, you can look at the history of the image as it was created. You can actually execute the builds on the key.io site to actually rebuild the Docker files to generate the images. And finally the nicest one in my opinion we got the multi cluster view. And what that allows you to do as a developer is get visibility of all the clusters you've got access to. So all the open shift clusters or Kubernetes clusters. So you can see the state of your application running on multiple clusters. You can see the state of the cluster itself. So this allows you to develop your software and all those kind of things. But it's not limited to those. There's a number of plugins that are already for backstage. Everyone's writing plugins because as I said backstage is a framework which allows for this level of extensibility. And because Red Hat Developer Hub is backstage, any plugin produced for backstage will run natively with Red Hat Developer Hub. And Red Hat Developer Hub will support dynamic additions of appropriately coded plugins. The problem at the moment is you have a plugin you want to add into your backstage instance. And it requires code changes in the actual backstage app to enable the actions that are offered by the plugin. So you have to stop your backstage instance, change the code or add additional code files, recompile it, rerun it and away you go. So it's down time to actually add a plugin. So what we've been developing is this concept called dynamic plugins. Now dynamic plugins work by having a generic handle within the backstage system which can handle the actions that are provided to it whilst it's running. So you can have it. The only caveat is you have to write the code for the plugin to match the parameter definitions or to match the the actual method definitions of the dynamic plugin way of doing things. But this means that people going forward can develop their plugins to be dynamic which means you can actually add them to a backstage system or the Red Hat Developer Hub system without having to take the system offline. But you can see on the left-hand side there we've got this concept of additional plugins from GitLab, from GitHub, from Sonocube, for testing, for Sneak, for code analysis, from IBM, for Watson X, for Tecton, for Dynatrace, Jira. So you can actually embed your Jira software in there. So, you know, you can have access to your Jira while you're doing your developments. Jenkins for builds and vault and things like that. And this isn't going to grow massively. So as I said backstage is incredibly popular at the moment. And so people are writing plugins left, right and center. We're going to talk about templates now. So we've talked about the framework. We've talked about the way it works. We've talked about the way the developer initially interacts with Red Hat Developer Hub. But we're now going to talk about software templates. And this is where it really comes into its own in terms of strength. So a template allows a creator to provide a set of executed instructions populated by parameters via a wizard which interact with core and plugin functionality. In English what you can do is you can chain together a number of tasks using plugins to scaffold things for users. And the majority of examples I've seen of this so I say for example we've got a template that we use for one of our demos and what it will do is it will create a Git repo in your own Git account. It will copy the base code in there. It will change some manifest codes for Argo CD. It will actually implement and deploy those applications to Argo CD. It will actually create the tecton pipeline objects within the target cluster and it will do a build. And the theory behind this is you've got let's say a new starter or someone joining a team or someone who wants to get a quick start on an existing project. You can write a template that pre-fills all the stuff they need. It gives them access to the original source code, builds an instance of the application, deploys an instance of the application. So all those things that the developer would have to do themselves to go through a set of phases external to their development to actually get, to actually do you can write as a template. The only limitation on the template is literally your imagination because you can write plugins to do external actions, you can add those plugins into the system and then you can write templates to use them. They work a little bit like pipelines but they're focused on execution functionality from within the core of the framework or externalised components via actions provided by plugins. They're very like pipelines but it's all to do with the actions themselves and it allows templates to be massively extensible and templates are the remit of the maintainers. Now there's a certain level of access that a developer has and I'll show you it on the demo that I show on the developer sandbox where I can import a template from somewhere else. I've got a template which I've taken from the backstage maintainers and I've changed it slightly and I can actually import that template as a user and when I import that template as a user it produces the cookie-cutter object for executing it. So once I've imported the template I can simply go to the create button on the developer hub and I'll be given access to that template. I can click on it it'll generate a wizard that generates input points for all the parameters that are required to execute the template and when I've entered all those parameters through the wizard I hit create and it executes the template and that's the beauty of it is that I can instance these things as a developer if I've got the rights to do it so as a developer I could write templates myself to ease consistent tasks I do or constant tasks I do that are always a pain to actually set up. I want to introduce the Red Hat developer hub user interface now again it's incredibly similar to backstage so it looks a lot like the IDP that's produced by backstage but it comes pre-opinionated so the pre-compiled Red Hat developer hub provides a standardized but configurable IDP UX it's that kickstart if you were starting with backstage you would start with the absolute basics and have to build everything yourself when you're starting with Red Hat developer hub it comes pre-built and it comes with a number of opinionated things that we think are a good start point for developers and it's based around a home page so every time you log on to the base application you'll give an access to a home page and this home page has a quick access set of links which are completely configurable and for example with this one here I've got access to developer tools I've got access to CI CD tools but you can have links to the chat facility for developers you can have links to IDEs which are very nice as well you can have links to let's say reference libraries and tools like that and it provides a left hand navigation panel with the core components from Red Hat developer hub they include the catalog we talked about before which is basically your visibility of all the active objects that are currently running within your developer hub it provides something called GPTs we now call them software templates they were originally called golden path templates via create, self documentation so there's something called docs which uses tech docs facility within the Red Hat developer hub backstage community and basically you write sort of markup in very similar to rebe.md so you use a gear hub to document objects which can be attached to other objects within the system so what this means is you could run your application you could define your API via an API object to publicize to other people in your organization what your API does and then you could document the code and the mechanisms of the code in a doc file that's attached to your component and that's automatically executed and provides another object within the developer hub so other people can have visibility of this self documentation you've done which tells how it was written and how it's actually provisioned so it's very very useful for that and it solves one of those major problems we've always had developers that there's 15 buckets of documentation everywhere this allows you to basically produce a single point of documentation shareable APIs so you've got the API objects that uses swagger so if you know how to write swagger or to export swagger you can create API objects based on that again I'll show you as part of the demo an example of this and it basically expands the swagger documentation and gives you a nice readable definition of all the APIs that are offered through the API objects that are instantiated and learning paths now learning paths are linked to useful archetypal articles on development so when you install Red Hat developer hub out of the box that learning paths entry is full of learning paths to the point of Red Hat developer website with loads of things about different use cases for what you can create talk about artificial intelligence all these kind of things that a developer might want to go and look at or actually have to refer to whilst they're developing their software and again it's through a single point and on the right hand side you have what's called your starred entity so any object you can find within the catalog you can apply a star to so if you find an API you're interested in you can star it if you find a template you know you're going to use 15 or 16 times within the organization you can star it and that gives you quick access directly to that component from the right hand panel it's kind of a shortcut it's kind of a star based shortcut menu for entities within the actual developer hub itself so I'm going to do a demo now or a number of demos I say if you've got any questions please feel free to put it in the chat and I will answer them as we go but what I'm going to show you basically is a number of instances of the Red Hat developer hub to show you different components of the stuff I've talked about but I'm going to focus primarily on an instance of Red Hat developer hub that you can install in 30 seconds using the developer sandbox for those who don't know what the developer sandbox is Red Hat Red Hat developer website has access to a hosted 4.14 OpenShift cluster and you can get on there using an account which you can create it's totally free, gives you 30 days of access to the latest version of OpenShift you're restricted to one project on namespace but we've got Helm Chart which allows you to install and execute the Red Hat developer hub and what I've done before this demo is actually set up an instance of the Red Hat developer hub running on sandbox and again it's totally free and there's no cost for this you can start to have a play with it and see what it does so first of all I'm going to show you what it looks like so I've installed the developer hub as exported by the instance I've got on the sandbox if you want to look very quickly at the OpenShift topology I've run the Helm Chart and the Helm Chart has installed a Postgres database and it's installed the developer hub itself this route here takes me to the developer hub and you can see it's saying welcome back because I've already been on here if I go to settings what I've done is I've actually linked this into GitHub so it uses my GitHub account as authentication and it also has access to my GitHub account so I can use the Red Hat developer hub using templates to provision GitHub repos and interact with GitHub repos what you can do as well is you can actually use GitHub org authentication so you can set up an org within GitHub and then grab members who are other GitHub users and then you can tie that authentication and authorization into Red Hat developer hub so it uses the org and a number of people actually working on the same software and the same repositories going back to the home page you'll see I've got a number of quick accesses these are completely configurable so we've got a base set that we think are reasonably useful things like monitoring tools things like security tools and they are completely configurable on an instance basis I could as the installer of this go into my installation change some configuration files and I could change the way this looks on the left hand side we've got the basic stuff you get out of the box you'll notice this is smaller than some of the other examples I've shown you and we've got the catalog and the catalog basically lists all of the objects that are currently within my visible instance of the Red Hat developer hub again this can be controlled by an R-back so you can control who can see what and you can see that I've got a Myangular app which is an instance that they are used to actually create an Angular app there's a learning path being published in the next couple of days on the Red Hat developer website that walks you through this I did a test with it just to see if it was working it works an absolute treat if I look at the kinds you can see I've got access to four kinds a location is an interesting object that's created as part of the backstage engine behind the scenes that's a temporal indicator of something that's been created within the system and you can see these locations actually refer to GitHub templates that I've actually installed or instances I've actually installed because I actually use a GitHub hosted YAML file to define my user so when this starts up when the system starts up it goes and pulls this YAML definition and the YAML definition for my user I'll show you very quickly is basically this one here and it basically creates a user entity, it creates an ownership entity as well these are internal entities internal objects that are used to tie things together so when I create something in the system it will be created using this so I can trace back objects that I've created but again it's a little bit under the covers there so pop out to the catalog templates are the interesting ones so the templates are the ones that actually define the steps that you can actually do things in an automated fashion we've talked about templates as part of the presentation I've already got one template installed on the system and if I pop very quickly to create you'll see that I've got this one template called the Angular app template it's got some tags to say give some information about it if I hit choose it will actually walk me through the parameters and then do all the things that are defined in that template and afterwards before we move on to the next part I'll show you what a template looks like the APIs are basically APIs I've got no APIs currently installed if I hit register existing API I can just point it at a piece of defined YAML from a github repo which defines the information about what my API exports and the swagger instructions for it and it will build a swagger API for it and produce that API object learning paths is links to a number again this can be opinionated so when you install you can change these but out of the box it lists to a number of useful articles currently on the Red Hat developer site to extend over time as we produce more and more articles that are relevant to what you do in Red Hat developer hub there'll be much more of these articles appearing directly from within the developer hub itself but now on to the cool bits I'm going to hit create so I've got one available template at the moment which is Angular template but what I want to do is I want to install a template I predefined so a template I built somewhere else and so if we go very quickly here I've got this thing called template test I lifted it from the backstage site so I took a copy of it and it's basically it's a template object so as we said it's a declarative API when you push this piece of YAML in the engine will read it as a template and create a template for it it's got a name of our HDH demo one it's got a title, it's got a description which is also the tags for it it's got a specification which is the owner which is service now if I scan down you'll see it's got parameters so there's a number of parameters it defines it defines name and owner and there's a type and whether it's needed and how the user interface responds to it when it's building the wizard and I've got a location as well if I scan down to the steps this is what the template actually does now if you remember when I was talking about the plugins the plugins export actions that you can consume as part of templates what this template does is this I have fetch base which is action fetch fetch a template and it looks in the code repo in a subdirectory for template and then basically it passes the parameters dot name and parameters dot owner so what this does is it creates a template using the information that's in that subdirectory with those parameters it then does fetch docs excuse me what that does fetch.plane is it will lift all the files that are currently in the point in the github repo I'm pointing at and it will actually tag that URL to them so it's bringing this over as well it will then do a publish to github so the template contents and the document contents will be written into the repo that I actually provide as one of the parameters so this published code on github action within the github plugin and what that does is it basically looks at the point in the file system it's working in which is this point where we're pushing things in the target path here and it will publish it directly to the github repo that you stated and you can do things like branches and all those kind of things I then got something called register which uses an action catalog register and what that does is it creates an entry in the catalog for this component so the component is going to create an object that it pulls from the template it's going to create some documents via a linkage I'll show you how those linkages work and then it's going to register that component and when it's done it's got a couple of outputs which actually produces as an end game for the template being executed in this case it gives you access to the repository that it's created because you know it builds the files and then it publishes them to the github repo and it gives you a linker to the catalog entry that it creates as part of the register so it's a very simple it's a very sort of pithy sort of template so what I'm going to do is actually register an existing component so I'm looking at my template page and I know I've got this template that I can use so I'll do register existing template and I give it the direct URL of where that template lives and I hit analyse and what it does is it says right what I'm going to do I've read that template definition I'm going to generate a location which is the temporal stamp of an object being created and I'm going to create you a template called red hat red rhdh demo one and I'll hit import and that's done that's finished so it's added a location into the catalog and it's added a new template now we can test that by going to the catalog looking at the components and looking at the templates and we've now got a new template called the red hat developer test scaffold template from backstage now if you remember when we went to create the first time we were given the angular app template as the template we could do if I now click on the create you'll see I've got access to this additional template which is the one we've actually brought in from the template I haven't done anything of any consequence yeah I just added that set of actions as a template that I can use as a developer so I'm going to go choose I'm going to create it and some names so I'll call it demo and I'll set myself as the owner and what this is doing is this is actually going through the template and generating a wizard for all of those parameters that it needs to execute the actual template itself I'm going to use github I'm going to use my github name which is Utherp0 which is the one I log on because I've actually set up a user which authenticates through github so that Utherp0 is my github username I'm logged on to the red hat developer hub as Utherp0 and repository let's say what was it February 22 February 22 demo as a repository name that repository does not exist in github at this point I go to next step and it tells me that it's going to create group default Utherp0 as the owner and this is going to be the repo URL when it actually does the does the action and I hit create so what it's doing now is it's executing those actions that are defined in the template and it's done it already it fetched the base documents it fetched the file contents it fetched the document contents I told you about it published them to github and it registered it and if you remember it had two outputs and the outputs were the repository that it creates and the catalog entry and if I click on repository fingers crossed it's created a Feb 22 demo repo for me in github and it's populated it with all the contents that were in the original directory that it pulled it from so there's a little bit of random text in there and some random source material as well and there's also a catalog info.yaml file now what that does is it actually creates a component and this is the register part of it so if we pop back here click on open in catalog you'll see we've now got a component called backstage docs there is no group default cncf because I haven't created that group but it's basically because the cncf actually created the original one but that template which was actually defined sorry that component which was defined in a piece of yaml had four links in it and there are links to backstage that I can now click on directly to the discord chat and go to the storybook if I go back to the catalog you'll now see I've got two components that I own one of those is the backstage docs one so you've seen what I've done I've used a template which is defined as yaml and I've used that template to create additional objects I've used that template to create an external git repo and I've used that template to create an object within the Red Hat developer hub system that I can actually interact with which is really really cool I'll give you another example of this my angular app which is the one again I haven't created a group so ignore that for now this one basically creates an angular app a git repo for you fills it with source code for the actual angular app itself but it creates a link in here to dev spaces so I'm running on sandbox and sandbox has got access to dev spaces which is an embedded IDE I can click on this from within the Red Hat developer hub and what it will do is it will take me on to the actual work spaces within sandbox itself to run my IDE so from within the actual Red Hat developer hub itself I can go into the actual source code and edit the source code, interact with the source code and push it back into the GitHub repo and things like that it's going to complain bitterly because I've got an existing workspace, I've done this already I've clicked on it to open the existing workspace and it will eventually take about 30 seconds or so but it will bring up the dev spaces dev spaces are full IDE for editing your code doing tests, actually playing with the code itself running within the browser running within the sandbox and I've got to that directly from a link that I've created as part of the template I did to create it within my Angular app now whilst that's working yeah it's working now, so it's giving me access to the source code I could change the source code I could commit the source code in here and I would see changes in the GitHub repo and all those kind of things again it's a pity example it shows the power of what you can actually link into the developer hub what I'm going to show you now is if I pop over to this one this is actually an instance of developer hub that we've been using for demos that's got a huge amount of components in it and I wanted to show you this because I did a demo using a template and what this template did was it it did a huge amount of things it created a GitHub repo, it used Argo CD to actually instance it in a tecton pipeline it used the tecton pipeline to build the application then it executed the application in the end of the OpenShift cluster so basically if I look for example in this company catalog for me and you'll see there's a number of components I previously created if I look at this one which is a demo I did for a customer if I look at the topology overview it will take me directly into the cluster so this is the application running on the cluster but I'm viewing it through the portal in the Red Hat Developer Hub I can also look at things like tecton so this is another one of the plugins we produce and this actually will take me and show me the status of the pipelines that I've actually executed and what's more I can click on the CI and it will give me a breakdown of the pipeline I used to do this now these are all through plugins this pipeline technology isn't in Red Hat Developer Hub the Kubernetes technology the OpenShift technology isn't in Red Hat Developer Hub but it's all brought into the portal I can interact directly with it as if it's part of a single component system and that's the power of it you give the developers a tool where they can just interact directly with everything they need in one place and that includes libraries and all those kind of things I want to show you something very quick on this as well one of my colleagues added an API so he was working on something to do for the generation so he actually created the software for it he set up the API object and he installed it so I could see it so I can click on this API here and basically it can give me the relations about who owns what components and where it's used within the Red Hat Developer Hub itself but if I click on the definition it will go and list all of the endpoints that I can call and I can expand it and look at it so it's done a kind of swag of viewpoint but it means that you can actually publish your own APIs within the Red Hat Developer Hub appropriately and that's one it's one of those lovely features that brings everything together I think I'm coming to the end of the demo I just want to quickly pop back over here a second to show you one more thing and that is so you're not limited to just creating templates and interacting with components it also has the capacity for building its own docs and also having website linkages so I've got for example some APIs, some YAML definitions for Red Hat Developer Hub that have a list of critical websites I need when I'm doing certain types of programming so I'll have one that has like the Quarkus website you know the Quarkus scaffolder links to some Red Hat Developer blogs on how I use Quarkus with land chain for J to write artificial intelligence so I can bring all those together in a single documentation object called a website object and I can put that into developer hub and then I can star it and I can get access from it immediately so I can be looking at my developer hub I can jump to my source code I can go to that helpful little website URL set and I can click on those to go and find more information so I was a very very quick introduction to what underpins backstage and what underpins Red Hat Developer Hub itself I just want to pop back onto the slides for a second because I've got a QR code here if you go to that QR code I'll leave it up for the rest of the session but if you point at that QR code it will take you to the Red Hat Developer website which has a number of useful articles free ebooks you can download including the first three chapters of a book on Red Hat Developer Hub it also gives you linkages into the sandbox and that sandbox is what I've actually been running that demo on I showed you the instantiation of the template and the actual execution of the components it's also got this learning path on it which you can go to and this learning path is something I wrote that was actually published on the day we released Red Hat Developer Hub and this walks you through very simply how to set up Developer Hub using the helm chart on the developer sandbox how to set up GitHub authentication and then to actually instantiate that template you saw me instantiating as part of the demo so as an endpoint if you're interested in anything after this with the Red Hat Developer Hub Red Hat Developer Hub stuff itself please feel free to go and have a look at it follow the links and read that learning path we've got another learning path coming imminently in the next couple of days and that one is going to do the Angular app that you saw the other example of and that one links into Dev Spaces so when that one is published you'll be able to install the Angular app you'll be able to have a play with the actual application to the free version of OpenShift that we call Developer Sandbox and that was pretty much it and if there's any more questions please put them in I've just seen one now saying can you talk a bit about licensing is it like to put a maintainer or consumer it's actually without being rude it's a bum on seat license it's the first bum on seat subscription we've done so basically you pay for the number of users if you're actually consuming your Red Hat Developer Hub and when we talk users they are that user object that you actually saw so when I logged on as a user that is one user and what we do is we sell sort of batches I think 5, 10, 50, 100 also some of the gone parts have actually overlapped similar functionality of Odo and Dev Files the 1080 functionality was absolutely what I've seen with this is that for example you can set up a template that instantiates a Dev Spaces based on a Dev Files to drive the way that Dev Space will actually build the software deploy the software and pre-configure and do dependency injection on the software the thing with the templates is it's limited only by your imagination the plugins we've given you the plugins that come out of the box with the Red Hat Developer Hub in terms of getting access to Argo CD getting access to the command lines for Kube CTL and OC means that you can do anything through an action so you could write a little plugin that gave you direct connectivity via Odo into your applications and then you could call Odo actions from within the template it's a lovely little system in terms of being able to do extensibility the only thing as I said before is that out of the box if you use Backstage the plugins aren't there you have to physically build those plugins into the system it's not a mature technology Backstage is reasonably new Red Hat Developer Hub has only just been released at release 1.1 we're getting dynamic plugins we're getting a couple more additional plugins to do with trusted content it's going to evolve very very quickly the last thing I'd say before we close the talk is that there's a huge community interest in Backstage and for me because Red Hat Developer Hub is Backstage anything that goes on in the community is just going to push everything forward and it's going to be absolutely fantastic with a number of customers I've talked to in the Backstage room you spend a huge amount of time configuring it and it feels hard and it shouldn't feel hard the complexity of this should be in producing something that the developers can use it shouldn't be complex just to set it up and that's the advantage you get with Red Hat Developer Hub it's a pre-built pre-opinionated but still massively extensible version of Backstage so that's pretty much it for the session thank you for attending we'll be back next month with a topic I think we're going to be talking about Service Interconnect I'll be hosting that with a colleague Service Interconnect is an incredibly interesting technology about point-to-point service communications but I hope that was enjoyable and again feel free to use the QR code and again sandbox is totally free so go and have a play with it use the HelmChart install it follow the learning path just get a feel for what it does and then you'll see about how rich this can be and if we haven't got any more questions I think we'll call it a day then


Hi guys, welcome back to yet another video. It's mext from the next creation. Remember, it's Qatar 2022, the FIFA World Cup Qatar. And we cannot fail to mention about the FIFA World Cup festivals or the fun festivals around Qatar. And most of this time that we are talking about, we are talking about the happiness. You know, the FIFA World Cup is a tournament that hosts 32 countries in the world all coming together with the common aim to win what you call the trophy. And the end of it all, the winner takes it all. And we are looking at what are the fun zone, what are the fun entertainments, what other events are happening in the Cornish. Cornish is one of the FIFA fun festivals that is a society to entertain the visitors and even the residents and the nationals inside the country, which is something very big. So we are trying to look at the United Kingdom pavilion. We want to see how better they have to organise it and how better have they tried to put it in order to welcome or to give the services to the new people. Enjoy with me as we try to take a tour of the United Kingdom pavilion. Thank you so much for coming back to channel by the way. If you saw first time, please don't forget to support this channel by clicking the subscribe button and also clicking the notification bell. You will always be notified wherever we upload a new video. Thank you so much. Let's go straight into the video, let's try to see what they have and how better are they organised in the pavilion.


Okay. Good morning, everyone. Welcome to a new week, new session. Let's just begin this time with a word of prayer. So could one of us please lead us in prayer? Mr. Rupa, can you please lead us? Good morning, sir. Good morning. Good morning, friends. Father God, Father, we acknowledge Your presence in our midst, Lord. Holy Spirit God, thank You for Your work in each one of our lives, Master. Father, we commit this time at the throne of grace. We commit our hearts. Please open our hearts to receive Your teaching through Your servant, Lord. Bind us together, Lord. Father God, pour out Your power and presence and Your knowledge into our midst, Lord, that we may receive and perceive. Lord God, Father, we thank You and let Your will be done in our lives and let Your purposes be fulfilled through each one of us. In Jesus' precious name we pray. Amen. Amen. Amen. Thank you, Mr. Rupa. Okay. Before we begin, let's just quickly do a review of what we did last week. So last week, we looked at chapter five. We looked at a few revival stories and how the revival that these people, that the Lord used, we also looked at a few reflections. So let's look at the first one. We looked at the Moravian revival and how in Germany, Counts ins and off a rich man through him, very young man, 27 years old, but through prayer and times of dedicated prayer and standing together in unity, we see that the Moravian revival went on for a hundred years. We looked at there was unity. They were responding to the Holy Spirit. None of them said, no, I don't want this happening. I don't know why the Holy Spirit is doing this. Nothing like that. They were responding to the work of the Holy Spirit. And also this movement fueled missions and revivals is the different parts of the world. And then we looked at the second great awakening as well, where we see that it went into North America and then college campuses saw revivals. And one of the precursors we saw to revival was consistent prayer movements. Now, something unique in all of these, not unique, but something common in all these revivals was the aspect of prayer. It was the aspect of prayer. And also we see that most of these revivals, there was unity because later on, we see that there was in certain revivals, there was divisions later on, misunderstandings, jealousies and all of that. But the main precursor for a revival was prayer and unity. We also looked at how God was able to use normal people, working class people and the layman's prayer revival in New York. What started off with about 10 or 12 people, six people initially went on to 20 and then 50. And then they saw almost 10,000 people all across New York. Coming in the afternoon at 12 noon, 12 o'clock one in the afternoon, praying for revival in New York. And this, again, this prayer movement was lasted for many years. And through this prayer movement came the whole aspect of ministry towards working class people. During this time, it was New York, America was going through a depression. Things were, business was low. The churches also were seeing a dampened state. But we see that God used this man, Jeremiah Landfier, a working professional. I just put a burden in his heart to start a prayer from 12 noon to 1 p.m. But little did he know that this prayer movement would sweep across America and touch thousands and thousands of lives. Later on, we see that the same prayer movement went into Ireland, Scotland, Germany, Britain, Netherlands, West Indies, South Africa. All these countries began to have a 12 to 1 p.m. prayer time. Did he, would he have pictured this? Maybe Jeremiah Landfier would have thought, okay, just a few friends, let's just get together and pray. He may have never thought that this would turn into a revival. The whole point of coming together was, God, just help us get back to our feet. As a nation, we have gone away from you. As a nation, we are deprived. As a people, we are sinful. So God put this in his heart. And here's the important thing. He was obedient to that. And he didn't say, okay, 12 to 1 is our resting time. Or 12 to 1 is who's going to come. It's a working day. Who's going to come? But with the six people who came, Jeremiah Landfier took this whole prayer revival to another level. Thousands of people gathered together in prayer. So we see something that took off through this was, God used just lay men. None of them were pastors. There was no pastors. There were no preachers. We see that in that revival later on, pastors, evangelists, those who are in the ministry would try, would come in and attend these prayer meetings because they wanted that spark of revival in their own hearts and then in their own churches as well. So God used just lay people, regular people to do, to start a revival here. And also we see that newspapers played a very important role. People started reading the newspaper saying, Hey, there's something happening 12 to 1 o'clock. There are thousands of people gathering in prayer. And then news reporters would put this on their newspapers, news channels. And so there was a global impact. But I'm sure Jeremiah Landfier wouldn't have thought of all of that. He would have just said, okay, let's start prayer. And then we looked at the Welsh revival, how God used Evan Roberts, a coal miner's son, simple young man, but completely dedicated to God. He joined the Bible College. And after the Bible College, he was so much in fire for God that he went back to his hometown, began to preach to the students and the youth there. And we see that through this Welsh revival, people came at four o'clock in the morning. They didn't want to go back home. The first five weeks saw 20,000, 30,000 people in attendance. But more of all, the outcome of this Welsh revival was extremely impactful. Towards the end of last class, we saw that Taverns were closed. Drunkenness was dropped to a half. There was no crime. The police had no work. So they would join the singing team in the church and the coal miners wouldn't use bad language. And so everything, there was a complete change. And the moral standards of people in Welsh. And many years later, we also see that one of the things that Evan Roberts didn't do was because of his pressure of his schedule and rigorous ministries traveling to places, he did not take care of himself. And he went through a difficult time physically, mentally. He almost went into a place of mental pressure being so much that he almost went into an emotional collapse. But he was able to revive from that. He spent the rest of his years just writing books and all of it. But eventually the Welsh revival lasted for some time, but then it just dampened out. The news reporter asked Evan Roberts, can we see a revival like we saw during your time, during your youth when there were 20, 30,000 people every Sunday's meeting and people crying and wailing and asking God for forgiveness. Can we see that? Evan Roberts said, we can see it, but who's willing to pay the price? Who's willing to pay the price? And so what the reflection that we see from this or the learnings from this is, Evan Roberts prayed for seven years for revival. He was surrendered to God, he wanted to pursue God. He was an uncommon person, not a son of a preacher or a pastor or anything, just an uncommon, a coal miner's son. And we see that here the Holy Spirit began to bring fruit into people's lives. And so it's so wonderful to study all of this, to see how God is using these simple people, yet he's able to empower them with such a power, such an anointing that is able to impact entire nations, people who are in small cities, small towns, impacting the entire nation. So we stopped here. From today, we'll just pick up on two more revivals and we'll take a few reflections from that, and then we will bring this chapter to a close. And so we can, you know, the main point of this chapter is to have a few takeaways from each revival. Now we're not going entirely in-depth into the revivals in the sense that we're not studying about what are the books they wrote, because all these revivalists wrote many books from their experiences as well. So we're not going deep into that. We're not going into deep into events that happened, but we're just doing an overview so that we can have some takeaways. So 1905, I'm on page 70. We did touch upon the Mukti Mission revival and Pandit Ramabai. So we know that Pandit Ramabai, she was a Brahmin girl. She gave her life to the Lord. She started a house for Brahmin widows in Mumbai. And it had about a hundred children. And then from there she started another home in Pune, which is called the Mukti Mission. And that had 2,000 girls. Now these girls were young girls who were married off to rich Brahmin, older men.  And so these girls had nothing to do, very young in life. So Pandit Ramabai would take them into the orphanage. But what she would also do is it was not just kind of a shelter home or something, but she would pray, she would get everyone together and she would pray for revival. She said, it is said that many of those Brahmins didn't know what is revival. Because Pandit Ramabai, she would spend a lot of time reading about these other revivals. The Great Awakening, the first revival, the Korean revival that inspired her. And Hudson Taylor was one of her inspiration where he went into China and did great work there as well. So she was very keen on seeing a revival. So she would ask these girls, these Brahmin girls, why don't we pray for revival? And they said that those girls wouldn't even know what is the meaning of revival. And she knew it that they didn't know. But she would just say, let's pray for revival. And so she would get around all of them up, 2,000 people, children or girls, young girls praying for revival, praying for an outspouring. It is said that Pandit Ramabai would do that every day in the morning, the afternoon and in the evening. Then she would go back to her home or her room and she would spend many hours praying, many hours fasting and praying for revival. And eventually they began to see a move of God. These Brahmin girls who didn't know what is revival, didn't know much about Christianity, she began to teach them about the word of God. So she realized, okay, we need to teach the word of God to the girls. So she would spend many hours studying and teaching and preparing the girls. All of a sudden there was an outpouring. The Holy Spirit moved in that place. The girls fell under conviction. About 1,200 girls were baptized in two months. Picture this, 1,200 Brahmin girls were baptized in two months. So Pandit Ramabai also heard of the well-survival and what was happening there. So she was encouraged even more. She said, okay, what we're going to do now is, now we've received the Holy Spirit, now we have come into the Lord, she made teams of prayer groups, 10 girls in each team. Now you go ahead and pray for this purpose. She would make prayer points and give each of them prayer points to pray for. And so there were girls praying in groups throughout the day. About 30 young women met at Mukti Mission to pray for the Holy Spirit. And then they would evangelize. The Holy Spirit would move powerfully among the girls. And then slowly these people, these young women would go out and minister to other people. Now picture this, this is the early 1900s. This is India. Now imagine you've got some young girls probably in their early 20s filled with the power of the Holy Spirit, completely on fire for God and they're making groups and they're going out onto the streets and evangelizing. Now firstly, it's India. Secondly, they are women. If you read about the history of India, women were not considered people who should be going out.  These are Brahmin girls who have become Christians and they're going out to preach. But what happened? People were moved to tears. People began to pray. People began to see visions.  You know, others started seeing visions of Jesus. The meetings went on nonstop for 17 hours. Now these young girls would take turns, you know. So we read more about the Mukti Mission. What they would do is they had no instruments because they were only young girls and not many of them knew. It is said that they would come. A group of ten would sing. The moment they would finish the first song, you know, by the time they finished the first song, already people are crying. Already people have fallen on their, you know, fallen off their seats crying, weeping under conviction. Before the first song ends. So they would open it up. People would come in front. They would cry out their prayer. Then that would go on for a couple of hours. Then another group would come sing another song. And then they would sing that song. Again, there's another group of people under conviction. So this went on and on. 17 hours in a day. Repentance, conviction of sins, speaking in tongues, dreams, visions. There were stories of people prophesying. There were stories of miraculous supply of food and, you know, God's intervention for the women in the Mukti Mission. So it's so powerful to hear this. The baptism of the Holy Spirit was so evident in that place. It is said that people who walked on that street would be so convicted that they would fall off on the streets. And so people would run out, hey, there's some people falling and they're crying on the street. They don't know why. People outside don't know why they're crying, but these who are inside you. So they would go and carry them and bring them in and then pray for them.  And so this was the kind of move that was happening. It is also said that people began to see visions of Jesus. They felt that Jesus was right there in that auditorium next to each of them. They felt that, you know, a burning sensation on them. At times they felt, you know, like rain being poured out on them. So it was a, you know, complete mixed emotions. The Holy Spirit was working in different ways.  Next, a couple of hours they would feel like the rain of the Holy Spirit. So it was a powerful time. 10,000, 15,000 people would gather to hear insignificant Brahmin widows to come and preach the word of God. 15,000, 20,000 people. One of the problems that they had was they couldn't find place to, you know, to have these meetings. So they said, okay, we divide these meetings. We will send one group of people to this place, 10, maybe 10 girls to this place, another group to this place. And so they were divided. So, you know, it doesn't, they don't have to come to one place. Many Westerners came to the Mukti Mission. One of them was an American Methodist missionary named Minnie Abraham. And she writes a book, and this was the baptism of the Holy Spirit. And in that book she writes, it was as if we felt we were in heaven. It was, it was as if God was moving in our midst, walking in our midst during the meetings. Minnie Abraham herself, she came to write about it. She was a, you know, Methodist preacher. And she saw all of this and she said, this is a genuine work of God. This is what happens. And there is an outpouring of the Spirit. This is what happens. This is what happened in the Book of Acts. People said that, you know, a lot of these Brahmin widows, even though they were young, they went through a lot of physical ill treatment. So they had bruises. They had pains in their bodies during their time of marriage with these older men. They would sexually abuse them. But during the meetings, they were all healed. Nobody prayed for them. Just the Holy Spirit moving on them and they were all healed. This revival that happened in a small town in Pune. And then these Methodist American preachers writes about it. And this whole revival spreads to different parts of the world. What happened? This woman played a very significant role in the Mukti mission. She was willing to take up the task that God had given her. It was not easy. Picture this.  Two, you got Brahmins who have been converted and it's not an easy task, but she was faithful. One of the important things that happened in this Mukti mission. One was prayer and two was teaching of the Word of God. They completely relied on the Word of God. So let's look at a few reflections that we can take from this. Once again, just like every other revival, prayer was the precursor. They saw a deep hunger and they had a deep longing for the presence of God. Pandit Ramabai, she would go into a room and spend many hours praying and seeking God saying, God, you need to do something in this place. A deep hunger, a deep desire for God. Secondly, Pandit Ramabai stewarded that revival in the right way. The word steward means to look after. We use the term steward what God has given to us. So she stewarded the revival in the right way, which means that when there was this, she was praying for revival, but when the revival slowly sparked, she didn't go and announce it to everyone, okay, revival is happening here. She just kept calm. And when they are pouring, the revival just overflowed. That's when she was able to, she told everyone, okay, and everyone got to know that this was a revival. And we see that she was able to consolidate the work. She didn't say, I'm only the leader. I should be there everywhere. No, she made teams of 10 people everywhere and the work was consolidated. And three, we see that the spreading of the revival was done only by Bible women who went and evangelized and spread the fire of revival. So God is able to use anyone. It does not matter. It doesn't need to be a man. God can use women. Simple women. All we need is the desire or deep hunger for God. God is able to move in our hearts. So that was some very important learnings from Pandit Ramabai's life. And even now, what happens there is, I'm not sure if they've renamed the place. I didn't look it up. But one thing I do know is there are homes in Pune and Mumbai, which house of widowed women and there they teach them the word of God and they teach them about the Holy Spirit and the gifts of the Spirit. So those things are still happening. But we don't know whether they still have these times of prayer morning, afternoon and evening like how Pandit Ramabai did. So we see that God used this woman powerfully. Okay, let's look at the last one, the Azusa Street Revival. Now this was also one of the most famous revivals that we can read of. The first thing that comes to our mind when we say, yes, Mangi has raised your hand.  Thank you, sir. Pastor, I just have a question. My question is what's the difference between revival and someone who doesn't know Christ, knowing Christ for the first time, because when you are teaching and instructing us about revival, it feels like it is kind of the same thing where people get filled with the Holy Spirit, they go out and preaching and then people get to meet Jesus. So please, can you help us with the difference between revival and someone being born again? Thank you, sir. That's a good question, Mangi. Thank you. Right, so here's the thing. The word revival means to revive something, right? We looked at that, something that's already taking place to bring it back to life. So for example, if somebody is swimming and they're drowning, and then they've lost breath and then you save them, what do they do? They try to revive that person back to life. So, Mangi, revival is basically, see, what happened in the book of Acts was evangelism, the move of the Holy Spirit, right? And we see that there was an outpouring of God, right?  But like what we studied was in the first century, it was doing well. But then slowly the Roman Catholic Church came and there was a complete oppression towards the gifts of the spirit and things that were happening in the church was completely turned away, right? There was like what we studied, right? We studied that, you know, the believers could not have their own Bible. And so many of them gave their life just for, you know, writing the Bibles and all of that. So, they, the people that God used were revivalists, right? Martin Luther, when he did the 95 theses, they wanted to revive the church in the sense that they said, hey, this is not what the church is meant for. When we look at the book of Acts, right, the Holy Spirit fell on everyone and there was a move of the Holy Spirit. But now we don't see it happening. And so the, you know, Martin Luther said, we are saved not by the Catholic church or the Catholic system, but we are saved by faith through, you know, through Jesus Christ. So that was his main message. So what they wanted to do was they were revivalists trying to revive the church as to what it should be, right? Now, when they were trying to do that, there was a revival in the sense that, okay, people began to see the truth, which is what? Okay, it is not, this is not how the church is supposed to be. But, you know, the church has been revived. And so many people began to accept the truth. Now during a revival, it could be that, you know, Christians who are living an empty life, a dry life, they don't really know God. They have been revived back with the power of the Holy Spirit. They've been revived back. They're thinking their understanding of ministry or Christian, the religion as a whole, their work with everything has been revived back, right? And also the Holy Spirit has touched many other lives who are not believers, right? So for example, if you see during the first and the second century, there were many people who were not believers, right? If you look at, you know, nations like Africa and even India and Sri Lanka, where we see that people wanted to revive the church. But the outcome was not only did the church get revived where believers got to know their true identity, but also unbelievers began to come under the conviction of God. So to answer your question, Maggie, what you're expressing is revival is a fact of, you know, now their mindset was, I want to bring back, you know, the way the church should be, right, as in the scriptures. Now they were revivalists. Their focus was to get the church back to moving in power and the anointing of the Holy Spirit. And with that in mind, the Holy Spirit began to move on everyone, right? So for example, if we see in Africa, in China, during the communist time, Hudson Taylor, they wanted to, they went there or the aspect of, okay, they went as missionaries, right? So they went there to teach the church, to, you know, impact the church, to teach them on the word of God, to teach them on the gifts of the Holy Spirit or whatever. They went to teach the church. But they, because with what they were doing, they had this deep hunger, God, do something more. And so what happened? People in China, whether they were believers or unbelievers, all started to get, you know, under the conviction of the Holy Spirit and all of them began to, you know, accept the Lord Jesus as their personal savior. So they didn't go with the mindset of, okay, we want revival, we want revival, right? Like meaning thousands of people should come and maybe that was not the mindset. The mindset was more of, let's get back to God, right? Let's get back to God. And the work of the Holy Spirit is to bring conviction, right? So for example, what we just studied here in Pandit Ramabai's case, she prayed that there will be a move of God, right? She was a believer. She took in these Brahmins, right? But she prayed for a move of God, for her life and for the church in general and for the place in that she's housing these girls, right? And the Holy Spirit came and convicted all of them. Now through this revival, we see that other churches were impacted. Other ministries were impacted in different countries. So to sum it up, Maggie, I would say that the focus when we say revival, now for example, we are praying in, Maggie, you're in Africa. So you're praying, God, revive the church. You know, the church is doing so much here. So many wrong things are happening. So we are praying for Africa. Now, not only will the church, the believers come back to God with a true, you know, repentance, but there may be Muslims and people from other religions, Hindus, Muslims and people from other religions. Because of the move of the Holy Spirit, even they will confess their sins. They will come to know the work of God and they will come to know the God saving grace and they will be pulled in, meaning they will accept the Lord Jesus as well. So that the Holy Spirit is not contained to one church, right? And we see here that it spread to different places. So I hope that answers your question, Maggie. Do you have any follow up question? Thank you. Thank you, Pastor. That's awesome. Okay. Thank you. Yes. All right. So let's look at William J. Seymour, William Joseph Seymour, the Azusa Street revival. Now, the Azusa Street revival is one of the most famous revival. So, you know, when I was studying in Bible college, when the first time I read about the Azusa Street revival, I was so much impacted with it. I will never forget his name, you know, in the notes that we had when we were studying it was William J. Seymour. So only later on I came to know it was Joseph Seymour. So William J. Seymour, the Azusa Street revival. Everyone would know that, right? Because God did a powerful work through a black man, right? So let's study about this Azusa Street revival. William Seymour was born of Louisiana parents who were slaves, right? At a young age, he contracted smallpox and he lost his eyesight in one eye. But he was very fervent for the word. He was, you know, he always loved the gospel. He loved to preach the gospel. And so he began as an evangelist going to many places.  Why don't you join a Bible college so that you can study more of the word.  So he said, okay, and he joined a Bible college. And in that Bible college, they were teaching about the baptism of the Holy Spirit. Now, this Bible college was in Texas. And so he was not allowed to sit with the whites, right? Remember, the blacks were considered slaves, the whites and the blacks were always separated. And so the whites were sitting in the class. He would have to sit in the corridor with a few other blacks and they would listen to the lectures that were happening. And so William J. Seymour was very fervent. He would sit in the class, take notes and he would listen to each and everything that was being taught. And it would just be like a, you know, like a funnel just receiving everything that was being taught. And they began to study about revivals and that really touched him. He said, if God has moved this way in North America and the first awakening and God has used these people, God can use me also to, you know, to touch many lives. And so William J. Seymour, even before he graduated from Bible college, a friend of his said, invited him to a church to preach to another church. And so he went and he preached and he delivered a powerful message on the gifts of the Holy Spirit. But the problem was this church was not a charismatic church. It was just a, you know, a regular church that did not believe in the gifts of the Holy Spirit, a traditional church. But he went and gave them a strong sermon on the gifts of the Holy Spirit. And he thought to himself, you know, God is going to move.  And so he was no longer part of that church also. They were asked to, he was asked to leave that place.  And all of a sudden those prayer meetings, which started with 15 African Americans, there was a powerful visitation of the move of God. The Holy Spirit began to just all of a sudden fall on people. They were beginning to speak in tongues and, you know, William J. Seymour would lay hands on people and they would just fall on the ground. And there was another woman named Jenny Moore who spoke six languages and she would play the piano and sing in tongues. Now eventually it became 50, 60 people and they had to move out of that place. And so they took up another small place and their prayer meetings went on from morning to afternoon. So they would have the worship and then they would be baptized in the Holy Spirit. Same thing. They would fall on the floor like that. They would speak in tongues. People on the streets would hear that and come in and they would be convicted of the Holy Spirit. And the ministry began to grow.  So in Azusa Street, now if we look at pictures and, you know, Azusa Street is like a main road. And parallel to that main road is these, you know, the streets. And so it was a corner's place, Azusa Street, a dilapidated building which was partly burned down. And so William J. Seymour took this place. He used it. There was like a ground floor and then there was a first floor and then a room on top. So he would use the ground floor for prayers. The top floor was for meetings, meaning the staff meetings and all of that, and Sunday school. And then the floor above that was where he would stay. And so the whole movement started to spread powerfully. Now here's the thing. People from different cultures, different background, different races, different ethnicities would come for this revival. They said that it came to a point that even whites, white people came to the church, right? In that street corner, that small place, which could house actually only about 1,000 people. They were cramping up with almost 2,000, 3,000 people. William J. Seymour said, this is not happening. We need to do something about it. So he would have a morning service. He would have an early morning service, then a mid-morning and an afternoon and evening, and then a night service. And this was every day. So on a daily basis, they had about 15,000 people coming in and going, coming in and going. So it was like, you know, which service did you attend? Oh, I attended the early morning service. Which was you attend? Okay. I'll attend the evening because I didn't get place in the morning. So that was the atmosphere that time. The whole day services are going on. So people would come, people would go. At times people wouldn't go because the anointing was so much, the move of God was so much. It just stayed there itself. The unfortunate part was they could not find a bigger space. And even if they did find, they did not have the finances, you know, because they were, see another thing was they were black. So they were not given preference. And now you've got people coming from different races, different cultures coming in and setting for those prayers. God is moving powerfully. It is said that in the Azusa street, the corners at 5 a.m., people would come with their umbrellas and they would stand and wait for the church doors to open. And the team and Azusa's, sorry, William J. Seymour had a team of people. The moment they would come open the door, people were just strong inside that place. They would stand outside waiting in the rain. Some of them would come early because they would have to go to work. So they want to finish the morning service and they would go. Now, this is not only on Sundays. This is every day. Every day, thousands of people, 15,000, 20,000 people picture this in a street corner. What's happening? News channels are there. News reporters are there. There's revival happening in Azusa street. God is using a black man to impact the lives of so many whites and so many people. There was a, there was a, you know, the Daily Times wrote, Azusa street is the center of attraction for the entire city and the nation. A small, narrow lane, you know, a burnt building. You know, they asked William J. Seymour, why don't you repair this place? And he said, if I, if I try to repair this place or get it renovated, where will we have our services? So leave it as it is. Thousands of people are coming. I can't stop them. More than the, you know, the infrastructure, they're seeing a move of God. So let it be so. When we dig deeper into the Azusa street revival, William J. Seymour went to many places for to get a, you know, a bigger piece of land. But since he was a black, he was not given a place. People denied him. But still God's favor was upon him. There were people who were, who had become believers who were well off. And so they would give to God, give to his ministry. And so he was able to, you know, form a team. He was able to have paid staff. He was able to, you know, house these places, you know, to keep the church open the entire day, seven days a week. So that was a blessing for him. Now, what are the things that we learned from this revival, right? William J. Seymour was a man intense, with intense hunger for God. Even as a young man, we see that his, his, you know, his standing in society did not stop him from knowing God, even though he had to sit outside the corridors for the Bible school. There was no self pity. Oh, I'm like this. How can God use me? No. He said, God is able to, if God has used people before, he's able to use me. So he was so intense for God. He was fasting and praying. You know, while praying, he would spend five hours a day in prayer, five hours a day. And then one day he was, you know, as he was praying, the Holy Spirit ministered to him and said, if you want to see revival, you need the work of the Holy Spirit. And he said, okay, I want to move my prayer from five hours to seven hours. So seven hours a day he would pray and this happened for two years, continuously seven hours a day. And we've said this so many times. Our public ministry reflects only what happens in private. Here we see why is it that 10,000, 15,000 people are coming to a corner of a street standing with umbrellas of the rain early morning to this burnt building with no facilities, nothing, to a black man's church. Why is it that they're coming and standing there? It was nothing, you know, if you see pictures of William J. Seymour, he was a stout man, very his eyes, one eye was like kind of a bulged since it, because of smallpox. He had a lot of, you know, spots on his face.  Why is it that 15,000 odd people are coming every day to listen to this man? Because when he goes back home, he's praying five to seven hours a day. So they're not coming to see William J. Seymour, they're coming because of what he carries with him. He was a man steeped in prayer, day in and day out. The most important work or the most important mission of Azusa's ministry was prayer. Even as he, you know, there were times that Seymour spent most of his time behind the pulpit praying. And there were instances that we read that, you know, they would finish the worship, all of it. William J. Seymour was a stout man, so he was short and stout. And so by the time he would come up from the chair to the pulpit, he would stand and he would open his Bible. And by the time he opened his Bible, there would be a deep sense of conviction in people.  He wouldn't have even started preaching. So William J. Seymour himself says there are times I've prepared for four or five hours on a sermon but I've not even been able to preach it. Because remember earlier on he loved to preach, but he didn't get much opportunities to preach because the move of God was so powerful. Every time he would go, people would just fall off, even because of the anointing that he carried. But yes, later on what he did was he also started Bible studies, home groups and all of it where people could meet together and study the word of God. So one of the other things that we noticed was the services in Azusa was spontaneous. There was no special choirs or special singers and all of that. What was happening there was, if God is moving in a certain way, all of them would be in line with that. The local church pastors, evangelists, preachers, they would all come to Azusa Street. Why? Because they wanted to carry that spark and go back to their churches. And many churches saw that many pastors, evangelists, they carried that fire. Their churches began to grow bringing, you know, attendance to thousands each week. The most important aspect is here races mixed together and they were worshiping God together, which didn't happen during the early 1900s. Another important thing was William J. Seymour planned and organized this thing. He had regular staff, he had regular volunteers, he had membership, he had a statement of faith, he had an accountant. He had children's church, he had organized teams, organized volunteers. He had a director of missions and so it was very organized. It was not random. Even though what was happening in the services was God was moving in his own way, he had a good team, volunteer staff, directors, director of missions and all of these things. They had pastoral meetings, staff meetings. It is said that their staff meetings would have about 600 people, meaning staff and other pastors also began to come, pastors and evangelists. So you didn't know what to do, you didn't have place to have these meetings on top, which is the office kind of place where they would meet in the church. The moment they would come down to the church, the presence of God was so powerful that they could not even have the meetings. But here's what happened towards the end of this ministry. There was strife. There was jealousy.  There was, you know, criticisms, misunderstandings. People started saying, how can the blacks be with the whites or how can this happen? This is not of God. How can, you know, so a lot of ministries had to close down. Eventually, the revival fire was completely dampened. You know what happened in the end? It was one of the most sorrowful stories. Azusa Street revival was completely dampened. The church in the end had about 10 people, 10 blacks people sitting in the church, 10 or 12 people sitting in the church. And William J. Seymour continued to pastor that church till his death. But the ending was very sad.  But we see that he had good organization, good structure, good leadership, but jealousy, pride, organizational values came higher to the work of God. And so the revival was dampened. It was a sad ending. But the ministry did make a large impact over different nations spreading revival across the world. Right, so we will close with this. We have completed this chapter. Sorry, I've taken a few extra minutes. So we'll pick up from tomorrow. Let's just close in prayer. Okay. Father, we want to thank you for today's class. We want to thank you for all that we've learned to God. Lord, it's such a joy that you choose to be unqualified, to be qualified in your presence to God. Lord, what a joy it is to serve you. And I pray God that each one of us will have this desire, this hunger for more of you in our lives, that we will spend time in prayer, worship, reading of your word. And Lord, that you will use each of us in the ways you want to use us a God. Thank you. Thank you, Lord, for the work of the Holy Spirit in each of our lives. And I pray for each and every student, Lord, that you will continue to, Lord, bring your word, bring revelations into each of their hearts a God. Be with them throughout this entire week, Lord, as they study, may your word bring life into their spirits. In Jesus' name we pray. Amen. Amen. Amen. Thank you so much. Sorry, I took an extra time. Have a great day ahead. God bless.