Hello. And welcome, to this course where we're going to be concentrating. On. Microservices. With, spring, boots, this. Course has three objectives if. You're. New to micro-services, then i'll be giving you a feel of what microservices. Are all about and, as, with all of our courses you'll be getting plenty of hands-on. Experience. We'll. Also be using spring, boots, in anger. By, the end of this course we're going to have five, or six separate. Spring boot projects. You. Can use any language or platform, to build micro-services, but. Boot is very, well suited to the task as I hope to prove on this course, but. If you're not interested in spring boot then no problem you'll still find the exercises. Valuable, and, we're. Going to be using a suite of components. Provided by boots called, spring, cloud, these. Are a grades, kind. Of management, Suites, for micro services, and they're, based on work done by one, of the pioneers, of micro, services, the, Netflix. Development, teams. Again. Even, if you're not planning on using spring, cloud netflix in your production, work it's, still, a great way to get some experience, in, the kinds of problems you're likely to face in microservices. And why. Some, kind of management software, is definitely. Needed in. This chapter I'll be doing a nice high, level overview of, micro services, you. Can skip the rest of this chapter if you're already familiar with them and you. Just want to get cracking, with spring cloud. Then. We'll take a bit of a diversion because, messaging. Is a useful aspect, of many micro service architectures. We'll. See how to send and receive messages, from a cue in spring, framework I should. Have covered this on other courses, by now to be honest but I haven't and I'm going to make amends for that now but. Then we'll start the focus on micro, services, we'll. Need a whole chapter where, we're going to work on getting a small group of micro services, to collaborate, and. Then we, can finally, get to work, with spring cloud we. Will be covering. Eureka. For service discovery. Ribbon. For load balancing. Hystrix. Will fail safety. Feign. To make our rest calls clean, and efficient, and, spring. Config, so, we don't have configuration.
Data Scattered. All over the, system it's. Seven hours of intense, work so. I hope you enjoy the ride let's. Start with. That high-level overview while. Micro-services, is certainly, a topic that has seen a dramatic rise. In interest. Over the, past, well. At the time of this recording it's, the past couple, of years you, can see from this Google Trends graph that, sometime. Around, the start of 2014. There. Was a sudden, rise in interest, in, this, topic. So. What, is microservices. All about well the easiest, way to explain this is to. Contrast, a microservice. Architecture. The, one that we're aiming for on this course with. A traditional. Architecture. And commonly. We call these traditional. Architectures. Monoliths. A. Monolith. You'll, probably, be familiar, with this. Is where an entire, system is deployed. As a. Single, unit, if. It's, a java, web based application. That we're talking about then, that would be a single, war, file, now. Unless this is a very simple, application, the. War file won't, be just fulfilling, one business, need it. Will probably be fulfilling, many, many, business. Requirements. I'll. Go for an easy example if this. Was a shopping, site. Then. Inside. That war file you, would typically find code. For, things, like shopping. Carts, management's. Catalog. Management. Sales. Inventory. Management. Authentication. We'd. Have some kind of back-end, administration. Might have a reporting, facility, and that would, go on and on, and on, I'm sure. That you've worked on, one, or many, of these systems, in the past and of. Course the. Natural thing, is that over time they. Get bigger and bigger, and bigger, encompassing. More, and more different. Business, requirements. And. Usually. Of course there, will be a, global, database, backing. This application. And all. Of these business, areas, would. Typically, be able, to read and write to. That database schema, that's. Not always the case the, schema could be broken up into separate, schemas, but, it is common. To have one. Of these global. Databases. And often. This, database, might even be shared with other, monolith. Applications. A very. Common term for this type of database is an. Integration. Database. So. All fairly straightforward, what's. The problem here well of course, the, monolith, gets bloated. Eventually. It gets too. Big to manage easily. And. It gets harder and harder to make changes, to one business area, without. You accidentally. Breaking, another business, area, it. Gets harder, to coordinate, by. The time the monolith gets this big we're. Going to have multiple, teams working, on this application, and. Those teams are going, to start cutting across, each other so. If I want to make a change here then. I've got to consult, with colleagues, from the other teams, to make sure that I'm not impacting. On them and we. Also end up having to delay, any new, releases of the application. Until such time as we're able to. Coordinate. A release, of the entire, monolith. Let's. Say I've made a change here but. That's required, to change to a bit of code over here and a, bit of code here, so. I can't. Release my code until. The code here, and here, has been upgraded, so. By necessity we, have to have some, kind of a big build, process. Where. The releases, are coordinated. And. It's. Often, the case that days. Or weeks pass before. We dare to do this BIGBANG. Release, of the monolith, well. The solution to this is pretty. Natural. It's. Just. Good engineering, really and it's the kind of thing that as an industry, we've. Been talking, about for years you. Can really think of micro-services. Has just been an extreme. Form, of modularity. Of. Building, the system, as a, set of, self-contained. Components. Now. That would have been the term that I traditionally, use, to describe this kind of architecture but now.
Micro-service. Is very much the buzz term, but. You could think of a micro service as being a component, or, a. Subsystem. And. The. Key thing is that these micro. Services, can function, on their own they. Can be deployed, on their own they. Can be developed. On their own, but. These micro services, can of course communicate. With each other through. Well-defined. Interfaces. By. The way this picture is a fragment of UML, and the. Symbol, here I don't know if you know represents. A UML. Components. And I think that fits with. The concepts, of a micro service, perfectly. I've. Probably used diagrams. Like this for 10 years or more on, courses. And at work but. The big idea of micro services, is that this separation, is going to be extreme. Traditionally. I would, have probably built these components. As separate. Java, packages. But. Ultimately, I would have combined, all of the code together into, one great, big Wharf file. Packages. Are really weak they really, don't give any serious. Level of separation, and certainly, not at runtime. So, these micro services, are going to be developed, in their own workspaces. And, most. Importantly. They're. Ultimately, going to be deployed to their own standalone. Hardware. If, we. Can afford it we would have each, service. Would. Be running on its own private. Physical. Instance, of a server. Well. Actually that could turn out to be quite expensive so, in, practice, the, micro services, would often be deployed to their own containers. Which. Is a sort of virtual. Machine instance, you. Might be familiar with tools such as docker, and, docker. Enables, us to divide, up a physical Hardware server in some multiple, containers. Which. Are highly separated. They're. Like small virtual, machine instances. And, we can put one Micra service into each container. Now. Getting ahead a little bit there and we will be covering that in detail in the follow-on, to this course where. We will be deploying the, code that we write in this course on, to some real hardware. But. I think the point I want to get across here is that each micro, service is going to be for its entire. Lifetime. Through. To its deployments, it's, going to be really self-contained. The, coding one micro service is going to have no direct visibility. Of code, in another, one now. Of course there's, got to be communication. Between them so there will be interfaces. And there. Are a lot of options here, traditionally. Rest, calls, are used but. You can also have messages. Passing, between them we're. Going to be doing both of that on this, course on, future. Courses, we'll, be looking at how we can use more advanced, features, such as spring, integration. Streaming. And reactive. Technologies, to get even. Looser, coupling, but, for this course we're going to keep things simple to establish, the basics, and, we will use rest and, messaging. So, in many ways there's nothing, new, here but. The reason that micro services is getting, a lot of attention right. Is, that some of the major internet. Real Estate's and the one that I have in mind particularly, is of, Netflix. But there there, are many others as well they've. Really, taken on board some, very, bold, and, extreme. Working. Practices, and they've, also been very good at talking about what they're doing with. The larger IT community. So. At one, level then micro, services are easy we. Just architect. The system as a, set of small, services. And each. Of these services will be responsible for one, and if. Possible. Only one. Business. Requirements. While. I'm being vague about what business. Requirement. Means that's. Going to be up to the architect. To decide and to. Have a micro service only dealing with one single. Requirement, is, something. Of an ideal, but. We have some rules of thumb here, we'll talk about this in a bit more detail later on in the course but one, rule of thumb that you might have heard of it that many companies are adopting is, the idea, of the two Pete's a rule well. It's a little bit cute this one and apparently, it originated, from Amazon.
And It was in fact an, idea, that Jeff Bezos the, CEO, of Amazon had, in order to keep. His meetings. Focused. And small and, it's, something that the Amazon, developers. When, they're coding their micro services, have adopted, the, to pizza rule simply means can, we feed the entire development team for, this micro, service using. Just two, pizzas. Well. Okay, as I say there's a little bit cute they, don't say how big the pizzas, are but, I hope, you get the general feel for what we're talking about there, that, the. Micro, services, are going, to be very, constrained. In their, size, if, you, start finding that you have four five six developers. Who need to work on a micro service then it's definitely, too big and, it's time to break it down I'm, going to keep saying, my rule of thumb is that, a micro, service should be dealing with only one. Specific. Area of business. Functionality. I recognize. That that's vague, but. As architects. We have, to use our judgment on, a case-by-case basis. As to. Where the dividing line is at what point do we break a micro. Service down into, multiple, micro. Services, so. Keep that in mind we, will keep returning to that theme but, I really want to highlight the facts here that it really is possible to have a micro service, that, is just, a few, lines, of code another. Chief concern, with micro, services, and again, this, is just good design it's, good architecture. That we will have discussed, on many previous virtual. Pair programs courses is that. Each micro, service should be, highly. Cohesive, and. Loosely. Coupled. These. Are two of the most important, principles, in software development and very, relevant, to micro services. Let's. Look at each of the principles. Highly. Cohesive well. I've, already really covered that by saying that each micro. Service, should be handling, one. Business. Requirement. Cohesive. Means that a micro, service should, have a single. Set of responsibilities. As, a. Quick example you might have a micro service whose job is to maintain, mailing. Lists, and when. A customer signs up this, micro service is responsible, for storing, their details, their. Mailing preferences. And so. On there might be some logic in there that says no, this customer's an invalid, customer, and they can't, be signed up because they've previously opted. Out of the list things, like that and the, service could also be responsible for broadcasting. Email, newsletters. Well. Okay. Could but. Really handling, emails, is a totally. Separate, requirement. It's a separate concern, from. The job of maintaining. Mailing. Lists, so. I deliberately, misled you there really be. The broadcasting. Of emails would probably. Be a separate. Microservice, we'll, call this the newsletter, service, of course. Somehow. These, two micro services, are going to have to collaborate, with each other their, newsletter service needs to know which emails. To send to we'll be talking more about that later but that's, a great example where, it's really, easy to. Accidentally. Combine, two separate, business areas. Email. And list. Management, when. They should be separate. The, other principle is loose, coupling and this means that where possible we, need to minimize the interfaces. Between our. Micro, services, it. Would be no, good if the dependencies. Between the, micro services, look, something, like this, now maintaining. Loose coupling is hard, and I don't deny that we have to be very careful, in, designing the interfaces. And not, letting, them get out of control, and. That's typically, the job of a system architect. Who maintains. A kind of overall, view, of, how. The micro, services, are fitting together, we're. Also going to see on this course that we can use messaging, and that, can help us to loosen, the coupling in the system, so, more, on that in the next couple of chapters but. What about the database, well. This is controversial, because. Of course many businesses, many projects, depend, on their integration. Databases. These. Databases, might have been built up over years and, years and, it, could well be their biggest business. Assets. But. For micro, service architectures. Integration. Databases, are a definite. No. So. Why. Is that the case well.
It's Because they immediately. Violates. The two principles, that we've discussed, they. Are by design not. Cohesive. Because. They contain many different business. Areas, and they're. Certainly, not loosely. Coupled because any. Part, of the system, can, read or write, to, this database, and. As. It's. An integration, database. Perhaps. Even other systems. Are going to be able to read and write to, it now. Another thing you can do things such as manage. The users, privileges. You. Might have multiple roles, for different business areas, which have different read, and write privileges and, of. Course you might have a database, which is broken into multiple schemas. But. Even, with those features in place I hope, it's clear that, we, still have a major, points. Of integration, in the system, and that's. Going to cause a lot of coupling. So. As I say I realize that for many projects, that's a showstopper if, the integration. Database. For you or your projects. Is a. Precious. Thing that, you can't, change, you. Don't want to get rid of it then I don't. Really have any workarounds, for that, microservices, are simply, not for you and, that's fine Micra, services, are definitely. Not a silver bullet that solves every problem that, every. Project in the, world can adopt, well. Of course we're still going to need data, stores, whether that's traditional, SQL, relational databases. Or. No. SQL big, databases, or, maybe just persistent flat, file storage. Whatever. The, key thing is that each micro, service will. Maintain its, own, data. Store. And that, microservice. Will be really. The only part, of the system that, can read or write, that, data well. This really is just the age-old, principle. Of encapsulation. That you'll be familiar, with from object orientation, but, it's, being applied here at a, higher, level of the system first. Advantage of this is that it's now no problem, to have multiple, types, of data storage. If one. Micro service is best. Suited, to be, using, a relational. Database, that's. Fine that microservice would have that if the, Micra service over here is better suited to using big database, then, it. Can use a big database but. That is going to mean that you're going to have to think differently, about the data models, and it's, going to mean that data is. Sort, of spread, around the system in a, different way to the, way that you might be comfortable, with a very. Quick and perhaps, over simplified, example but, I hope it gives you the idea in the. Traditional, system with, a monolith, you, might have a user table. Containing. The users details that, dress and so on together, with their username, and password, then. That monolith, you might have a routine, somewhere, that ships, our product, to a user which. Is going to have to read that user table, to, find out the address to ship to there, be other requirements. As well though we would of course have an authenticate. Routine, where the user logs on and this, routine, would be reading, the user table to. Query their username, and password. All, that's fairly standard, and I admit, I have, certainly, modeled systems, like this in the past but. Really there, is a mistake, here about. User table, even, though it's simple is already. In cohesive. It's. Capturing, two separate.
And Totally. Unrelated. Business. Concepts. We. Have in there the user's identity, credentials. Username. A password and. Their. Physical, location, on, planet, Earth their, address well. In a microservice architecture, you will be forced, to refactor. Away, that in cohesiveness because. We, can't have a single user table, that's going to be read by two separate. Micro services so. We'd break it down a possible. Solution is that we would have one microservice let's call it, principle. Management. I, don't. If you're familiar with the term principle. That's a term that basically means, user, when. Applied to security. So, this, is going to be responsible for identifying. A user's, username and. Password, and checking. If they're valid. It's going to have its own data store, let's. Say an SQL, database but, it doesn't have to be and that's, all that, that service, does, there's. Going to be a separate, micro service responsible. For order, shipments, it. Would have its own table, containing. Just, the data, relevant. To. The users, physical, location. Address, so. We might have a user, table, in here as well albeit. Containing. A different, subset, of data we. Might not call the tables user, in this, micro service it might be better to call that table, principal. And in, here, well, the table might be called user, address, I don't, really know well. Actually you. Can probably spot, and I'm thinking now that this shipping, module, probably. Wouldn't be responsible, for managing, users, addresses. Because, the, job of the shipping map module is to do shipping and to schedule deliveries. So. There's probably even going to be another, micro, service, responsible. For managing. Users. Addresses. I don't. Know what this would be called I'm just going to call it the address book service, for, the purposes, of this caption, I haven't, really thought through how this works, this. Service, would probably. Have to collaborate with the shipping. Service, somehow, now, I'm just trying to illustrate they're, the kinds, of thought processes.
You're Going to go through I don't. Know if any of this is correct because this. System doesn't really exist and, I haven't built this software yet I just really wanted to explain that what you might have thought of previously, as simple. Database, tables, are, probably, multiple, concepts. That. Are going to be modeled as separate, databases, in their, own right, and. It's worth mentioning then that we're. Building a micro service architecture, I don't, believe you can possibly, do, a big, design. Up front. Micro. Service architectures. Are very as we we say emergence. They. Tend to develop over. Time as your understanding. Of the system, proves so. You will find yourself designing. Building. And deploying a, micro service, like. This shipping one I did here which, ends up being in cohesive, and you realize, it's doing too much but it's only a few weeks later or whatever down the line that you you have a Eureka. Moment and you realize, that no. That that's too big it's doing too much it should be broken down, that's. Fine that's, good you, refactor, later, and, I'm finding on my projects, that's exactly, the case we're. On a Friday afternoon I design a micro, service and I don't even realize, that I've, just accidentally, combined two or three separate, business areas, together that I shouldn't do that's. Not, a problem we refactor, later, so, agility, is really important, in micro services, because. It is impossible. For any human being to get the right answer, in advance, of, building, the system, a jargon, term associated, with, what I've just been describing, is the term called bounded. Context. And I'm. Here on the mountain Pharma page because as usual Martin, does a great job of, explaining these concepts, but in fact this is a term that originated. Originally. In a book by Eric Evans called, the main driven, design it's. Quite old this book now it's getting on for 15 years old but it's, still a recommended, book I must say it's perhaps not the easiest, book in the world to read but it, really was full of some groundbreaking, concepts. That have influenced. Software, development, ever since. Unbounded. Context, was one of those terms and really, this jargon term means what I've just been describing, where we have large models, that have been divided. Down into, different what. He called bounded. Contexts. And a, bounded context, is where you have data, purely. Or one, specific. Business, area, so. There's a nice example here, where this previously, monolithic. Data model has been broken down into. A data model for the, sales area, or. Context. And a. Data model for the support, area, or content. And, you can see that there is some apparent, duplication. In that there's a customer, table in, both of them but, these will be different. Customer. Tables, there. Will be different, data, relating. To a customer, for support, as to what we would see in the sales. Customer. Table, so. Although the, main driven design predates. Micro-services, by a long way you. Can see that these bounded, contexts. Would, make ideal. Databases. For, a single, micro service so, do check out the Martin Fowler page or the, domain-driven design book, if you want to read more about that generally. Bounded context. Is not a term that I feel, comfortable, using, because it feels a bit jargony, I just. Hate the word context. We seem to overuse, that in software development but. It's certainly a term that you're going to be hearing a lot in the, real world so, on this course we're going to be building some micro services, using, spring boots as. You can probably guess you can develop a micro service, using, any, programming. Language or framework, and, you. Could build one micro service using, spring. And Java you. Could build another micro, service, using. Python. You, could develop another micro service using, I don't know Scala, or closure, as long, as these micro services can communicate. With each other it really doesn't, matter what language you're using however. I think that spring, boots is especially. Well, suited to, the task of, building micro, services, so. We're going to be building a few on this course but really. The interesting, part of micro services, is not. The services, themselves, it's. The overall, architecture. Which is how, the services, fit together and how we. Develop them, properly and also. How we deploy them, now, I designed this course to be primarily, a course for developers. So. I'm only going to be looking very briefly, at, deployment. On this. Course, there. Will be future, courses, where we do look at how to deploy, the system and, you. Definitely do need a lot of, and, supports. To do, a micro service architecture. Ideally. For instance you would have separate, code repositories. You. Would need some kind of continuous, deployment systems. Such as Jenkins. And our my projects, and the projects are we'll be doing on this course we, would have totally.
Separate, Eclipse workspaces. For each, of them now, because you're going to have a lot of micro services, Netflix. For instance report where they have over 600, micro services, on their system, you. Have to automate, all of this so some kind of automated, deployment. System, using. Tools such as puppet, chef, or ansible, would. Definitely, be needed so they, will be covered on future, courses but, for this course as I say we're, going to concentrate on, developing, the, micro services, and stitching. Them together so. I hope that's a good overview, of micro, service architectures. In the, next chapter we're going to get started, we, won't be doing micro services immediately but, we will be looking at how to send, and receive messages, using. Spring boots. You.
2018-01-15