Hi all. Welcome to applications of software architecture for big data. My name is Mike Baronak, and I'm with Tyson Green next to me. Hey everyone. Hey, we're going to be your instructors for the course. Maybe something to mention, this course is the third in a three-part series. The first was fundamentals of software architecture for big data. The next patterns or architecture patterns for big data, and this you could think of as the capstone, or the project for the earlier two courses, applications of software architecture for big data. Maybe a couple of things to talk about. A little bit of the project history, maybe some of our goals, and then maybe a little bit of a preview in terms of what you're going to do as part of this course. I guess a couple of things, why the architecture that we selected or that we're going to put forward for you. It's something that we've used over the years. I would say, geez, I've had been writing software a little while. I probably use this style of architecture first in maybe the early 2000s. What it includes is something that's going to go out and collect data. You're going to have something that analyzes data, and then a web application that then displays that data. I guess the practical side of this we're going to build, we're going to deploy, we're going to run it. We're going to treat this like a regular project that we might do out and about in the industry when folks are building software. We're trying to share that fit a day in the life with you, and maybe some of the lessons learned along the way that we've experienced in the positive sense. That's a little bit of the history. Maybe do you want to talk about a little bit more specifics, and how it relates to the modern day architecture? Sure. Yeah. This architecture was really popularized by Heroku, which is the deployment platform. That was really one of the first deployment platforms that made it easy to get apps to prod with out needing to worry about how they're deployed. Git push Heroku mean, if you've ever worked with Heroku, will magically get your app up and running without you having to provision anything or worry about the infrastructure. Heroku had this idea of a procfile where you could define your stateless web app that was running, and then maybe a couple of workers that'd be running in the background. As Mike mentioned, these workers might be collecting data, analyzing data. They might be running on a crime. They might be responding to other events in your system. But this architecture Heroku made really easy to get up and running in production, and it's really taken off since then. I think another thing around that timeframe, let's say it was maybe 2010, 2012 or so, it was Ruby on Rails. Rails was this really lightweight framework created by an individual, David Hannan Meyer Hansen. That with Heroku just opened up the world for folks to come into the world of software and building software. As Tyson said there was a procfile that embodies the architecture that we're going to go after as part of our project here. Switching gears slightly, there's a couple other things I talked about the day in the life and sharing some of our experiences. Some of these were talked about in the fundamentals of software architecture for big data. But it's things like, let's write some tests so we have confidence when we deploy applications. Let's make sure we bake in metrics and monitoring early, so that that makes it easier for us to run those applications we built. Naturally, there's the automation of that. You might have heard continuous delivery, or continuous integration terms like that. We'll talk about later in the course as we set up the different exercises for you. Then, I guess at a high level, there's a few things that are fairly common. One is just simply interacting with the database. Heroku had that out of the box, as well as maybe talking to an external API. You could think of something as simple as collecting data from Twitter, and then doing something with that data is the analysis piece. There's also when you get into distributed systems where they become more workers and maybe there's more shared responsibilities, you might interact with the different services via message queue. That brings you a little bit forward to what Cloud-native and some of these Cloud-native architectures you might have heard about. It's really getting out almost like single responsibility apps or singular responsibility services. In our case, we're going to do that. One is going to collect data, one is going to analyze data, and then our web app is going to display that information. I think we're off to the races in terms of the project. Anything else other than the setup, or we should say it's part of the setup? I think we're ready to go. We'll dive into things like the rubric. We'll talk about maybe the whiteboard architecture that we're going after. Then we have a little example codebase that will show you what we've done to get closer to the architecture that we described. Good luck. Should be fairly fun. I guess one last thing, we've interviewed a ton of candidates over the last decade or two. Having this type of experience where you put together a project, and that project really embodies what's current and what folks are building at some of the different companies, whether it's a startup or whether it's an enterprise, it goes a really long way. Maybe one last thing, the examples we're going to use. We also run a workshop as part of the company we're at called initial capacity. You're going to see some of our Git repos and some of the initial capacity project starters that we'll share with you to get your project bootstrapped. That's it for now. We'll see on the next video. Thanks.
