You've probably noticed mention of this idea, that teams may have more of a monolithic application or they may be more on these microservices pattern and that this has a lot of implications for the type of test coverage you need. Particularly, as you move towards a more continuous pipeline. In this video, I thought we would dig in that a bit and get you more comfortable with what this means and the implications it has for your pipeline. The basic idea is that, if we're just building a simple app like the folks at HVAC in a hurry, we're probably build it as all one thing. Everything else monolithic. Everything else being called, this keeps things simpler. It keeps test simpler, it keeps version management and all the rest of the housekeeping simpler, deployment simpler. However, as we scale this monolithic and the functional space increases, and the amount of stuff that it does, the scale that it operates at, the size of the team that's working on it increases, we may find a couple different things. One is this that, part one we'll call it of the application, versus part four of the application have really different characteristics. One needs a real time interactive component and the other one needs something else of a different nature. It gets more awkward to put all these into the same code base and the team is working on this, versus the team is working on this. They want to do things differently. Use different technologies, deploy in different ways. Also, we may find that, it's a lot of every little change. We start to make on this thing, which becomes more and more frequent. The more complex it gets, the more features it has. We find that it's very disruptive to redeploy the whole entire application so often. Thirdly, we may find that this part of the application interacts with this part of the application in ways that we didn't exactly intend, or plan, or perhaps don't even entirely understand in some cases and we don't want that. So, one solution that teams find really helpful for them, is to then, take this and began to refactor these components into their own little applications that are independent, but then interact with each other. So, we'd have one, two, three, four, five, six, seven, eight, nine here. So, this is a pattern that is very popular and this works well for scaling the application. But as you can imagine, what happens is that. Now, something that we could understand pretty readily when we're testing it, is a little bit more complicated, because we need to know how this one service over here interacts with this other independently developed thing over here. So, the need for integration and system tests is going to increase quite a lot. So, what I was hoping to show you here is both, generally speaking what this means and two, how it relates to the things that we're going to need from our test pyramid, and our test coverage overall and the nature of testing. In the next segment here, you're going to hear from Jim Rose from CircleCI, about more on kind of the texture and some real life examples of how teams make these decisions and the implications they have for the way teams work together.