 I'll start with an apology. I am the father of a four month old baby. So sleep has been very valuable commodity lately. So if you see me just pausing and looking out into the distance, I'm just trying to... It's been hard. Okay, so thanks everyone for showing up. This was built as how to build Drupal applications with APIs and microservices. And as I was preparing the slides, I realized it's probably misleading because it's... Drupal doesn't matter in that if you're using microservices, the way you're using them doesn't change because it's Drupal in the equation. And it's partly how to, but perhaps the more important thing is why would you even use microservices? And if you get those guiding principles, then it also doesn't matter what you call them, call them microservices or something else. So obligatory survey. How many people are building things with microservices? And how many people are absolutely confident that what they're doing is microservices? That's me as well. So we'll see where we get in terms of defining microservices. I have to reveal a bias. So my background is in something called agent-based software engineering, which probably no one has ever heard of. It's partly kind of an obscure academic thing. And it's about building communities of intelligent, AI-enabled programs that communicate and collaborate and coordinate to solve problems. So I have a huge bias towards microservices because this is one possible definition of microservices. It's something that's capable of action. Maybe it's not flexible and autonomous, but it's capable of action in a dynamic environment that's unpredictable and maybe it's not open in the sense that you can't just have new microservices joining the environment, but it's heterogeneous. There's lots of different things going on. So yeah, I'm kind of biased. I really like these things. I get excited. Not so much now because I just want to see. If I were to get into the specifics, what is the issue? Why do we even care about microservices? What problems are we trying to solve? I guess the first problem is that we don't have a single problem. We have lots of different problems. And whenever we're building applications, we kind of have to figure out how all these different things are going to fit together, how they're going to communicate, how they're going to adapt over time. And we need a way of architecting systems that helps us with that. So there's a lot of things to build. That problem we have is us, humans. I don't think I've ever been on a project where at some point, the phrase, this would have been fine just as long as X or Y or team X or Y behaved in a different way. There's always this kind of really hard integration problem in terms of getting different teams that are building different things to cooperate. So microservices tries to solve this problem as well. It's not just kind of how do you build things in code, but it's how you build things in code where the things that are building the things are human beings. Once we get to the point where AI is building everything, it's going to be just fine. But we're still not there. The other problem we have is speed. We want to release things quickly. Well, probably if the majority of us are developers, we don't necessarily care. But other people want us to release things quickly because of market concerns and so on and so forth. So how do we architect a system that lets us move quickly? Then we have the usual scalability, resilience, availability issues. You want to scale horizontally, just add more copies of the same thing so that I can handle more of it. You want to scale vertically, just use bigger machines and so on. And again, you need an architecture that's going to help with that. We need things that are testable. And we need to make a distinction between testing individual classes or individual modules and testing a big, complicated system that spans organizational boundaries because there you get emergent behavior, necessarily. And that level of complexity is really hard to test. At times it's almost impossible. So the objective is just to get to a point where it gets as good as it can get. So even though, essentially what I'm saying is, even though your code has 100% test coverage, you're still not testing the entire system because there's emergent behavior. So you need a better way of understanding your system. And then there's the ability to replace things. And there's two sides to this. There's replacing components within your code, and that's fine, you want to take one thing out and put another thing in because there's a better, faster, clearer way of doing things. And you have to deal with people living, the team, the organization. And kind of replacing who is actually working on the code so that we get out of this cycle that every time a new team moves in, they look at it and they say, where the hell is this? We're just going to have to redo all of it. And, you know, I've done it plenty of time. So it's how can you build a system but even if the team is going to say that, the impact is going to have to the overall system is smaller. Okay. So those are our problems and there are hard, big, complicated problems. Let's talk a bit about the non-microservice way as a way of thinking of what is a microservice way. It's really either monoliths, no single application, single code bases, or badly designed service-oriented architecture. And I'll let you in on a secret. There is no difference between a service-oriented architecture and microservices. It's just a different word. That's the difference. But the reason the different word was required is as a way to group a set of principles and practices and patterns and re-propose them and say we need to do this properly. We're still talking about service-oriented architectures but trying to implement them better. What are the problems with monoliths or badly designed service-oriented architectures? You have tight coupling. It's hard to support concurrency and partitioning. If the boundaries of your system are not clear, you don't know what can run at the same time and handle multiple tasks. You don't know how to partition it. It's really hard to have efficient testing. Perhaps one of the biggest things... Let's do another survey. How many people have been in a room where the project manager or the solutions architect said, let's slow down because I'm not confident about what's going to happen after this release. Be honest. You're extremely efficient. You've never had fear when you're releasing new code. We need to handle the human issues that monoliths don't help us with, control. Who has control of this code? We're allowed to commit what language, what pattern and so on, reliability, consistency. It just accrues technical debt over time, inevitably. Then it's so hard to pull that back. As it grows, it's increasingly harder to manage what this system is doing. Monolith management becomes a huge issue. The simple truth is, we've been building monoliths forever now. It rarely ends well. Big applications that do a hundred thousand things end up breaking and we end up building them and so on and so forth. What can you do? Well, there is the microservices way. This is a bit like the Church of the microservices. Welcome to the sermon. It's a set of beliefs of that. You just have to... It's more than that, actually. We'll talk about it. There is that need to constantly repeat to yourself, my system needs to abide by these principles and you need to keep these principles in mind throughout. So what are the principles? We'll talk a bit more about bounded context, but what it means is every part of the system has a well-defined context within which it's going to operate and it's bounded. It cannot get out of that context. Do one thing well. This is probably the most important thing with microservices and where the word micro comes from. It's a bit unfortunate because micro makes people think, well, it's small, so I have to have small services. You don't need to have small services, but you need to have services that do just one thing well. And usually that this leads to smaller services. But it's not smaller just because. It's smaller because they just do one thing. It's also smaller because they actually have to be comprehensible. So if I look at a service, I should be able to understand it without having to spend weeks working with it. They should be independently deployable. So if I'm switching out a microservice and that means I have to bring other things down, that's wrong. And as you've noticed, my presentation has a pattern. It's a word and an icon. Just because I'm very lazy in terms of finding exciting pictures because it's much simpler. But I was thinking what would be good for independently deployable, what would represent and be deployable. And this is a satellite in case you have one. And just imagine if the Galileo European Union system for GPS, which is, I think it's something like 30 satellites, was a monolith. And if you have to change it, you have to bring all the satellites down and launch 30 satellites up. That's what we're doing with our applications when we're building them as monoliths. We bring all the satellites down and we send new satellites up. That's a bad idea. So you need to be able to have satellites that fail and drop into the earth and burn up and you send new ones up and the system just recovers. So as to be confident in terms of what you're doing, you need to be able to deploy through automated process builds. So it's all part of the ingredients to the recipe that say I'm happy with my system, I understand individual components and I'm happy to deploy, deploy often, change without issues. And for that you need automation. And they're message enabled. So microservices communicate with each other by exchanging messages. And if you're thinking rest crowd, we will get back to that because that's not what I mean. Really, they should be composable and that's partly an obvious one. You should be able to use a number of different microservices together in order to achieve a goal. And they should encourage polyglotism. And I don't mean English and I just realized, I don't know what language this is. I was going to say Chinese, but I don't actually know. But it's about allowing the individual teams to use whatever programming language they feel is the best for their microservice. So it's fine to have PHP and Go and Haskell and whatever is your flavor, whatever has a characteristics that solves your problem in the right way. So overall, what we're building using the microservice principles is a system that makes change easy, safely, and at scale. And the scale is kind of important here because putting together a system that supports microservices is a lot of work. It's not about the individual microservices. There's no... You cannot build one microservice. That makes no sense. You're building a system that uses a number of different microservices together. So this is solving big problems, not small problems. I often talk to developers and they're saying, we're using microservices, but they're like two people. Yeah, maybe. There might be reasons why you're doing that, but this is really about big problems rather than small problems. So a system that makes change easy, safely, at scale. It has to be a cohesive system. And this is how many people know Uncle Bob? Look him up. He will change your life. One of the best kind of architects in software engineering architects. So what's a cohesive system? Gather together those things that change for the same reason, so that when you apply a change, you do it in one place, and separate those things that change for different reasons. Seems obvious, but that's not actually how we build systems. If your system is cohesive, it's also loosely coupled. Because the individual things don't depend on each other. And that's probably one of the biggest things. So cohesion, loosely coupled. Any questions so far? Does this match the... So you were saying that it has just been a competitive role around the quality of the system. Does that mean that quite definition we must be using some marketing aspect or asking people to do that? You said not so much rest or crowd. So what would be the alternative if it's two small projects we're using at this stage? It's not rest crowd as one thing. It's not really rest. That's fine. Crowd is a different thing and we often conflate that. I'm building a rest service, okay? So you can create, redact it and leave. It's not necessarily that way. In terms of... Well, we'll talk about how microservices communicate. And it's... It doesn't matter in what programming language you've got. It matters obviously in what they use to change messages between themselves but their services. So I just realized that was probably one slide ahead here. Anyway, that's fine. How do we build what does the architecture look like? We talked a bit about this but I'll just repeat it. It's not about the size of the service. There's characteristics you want to hit. It should do one thing well. It should be comprehensible. That's probably going to lead to smaller things but don't get hung up on oh, this is big or this is small and so on. It does one thing and it's comprehensible. Or it's 42. If you're architecting a system using the microservices way it's not just about the service. That's one of the components. You're really dealing with everything. The individual services the overall architecture and solution how the organization works you actually need to ensure that the organization that you're developing the solution for is capable of dealing with microservices with the ability to change things quickly. There's not necessarily I don't know a CTO or someone else that says no, everything is going to be done in absolutely the same way. There's culture issues there that you need to make sure are addressed otherwise the system is just not going to work. To me it's unfortunate because really I would like to get on with the services and the solution, the interesting stuff. But unless you solve this annoying stuff the human stuff the rest is just not going to work. It's just how it is. And then obviously you need your processes and your tooling to be able to handle microservices. The next thing I would suggest is to read this book The Main Driven Design One of the biggest travesties that educational institutions that teach computer science perform is teachers to normalize databases. You should just stop doing that because it makes a thing that that's a really important system characteristic and you have to have the one canonical model of your problem starting from the database working your way up. Instead what the main driven design says is actually if you look at an organization there are overlapping models of the same things. So in this case what it's trying to say is there's two models of product and two models of customer they overlap. They talk about some of the same things but if you try to create a single model it's not going to be good enough for the sales complex and it's not going to be good enough for the support context. So what it's suggesting you do is you define two bounded contexts one sale, the other support they communicate through a clear set of APIs but they can have overlapping models. Where this information is stored is not our problem. What's important is that within the system they can do what they need within the system they can do what they need and they can exchange information and this is it takes some time because we are really used to here's a problem okay I'm going to have a customer table and then there's going to be a product table and it's going to have this things and it's not necessarily the right way. This might sound weird but it's actually it's a perfectly valid architecture strategy to design a monolith and then break it up and the reason you're designing a monolith is to learn about your system to learn what actually makes sense and then you break it up into microservices because this stuff is hard there is no right or wrong answer so you need to really get into your system and learn it. Once a test you need to continuously apply is if you if you're applying a change and you end up touching different microservices because of this change we've done it wrong right we need to go back to the drawing table and rethink what our bounds are what the context is because it's not coupled loosely. This goes back to what I was saying before don't start by designing data models focus on business capabilities what is what are we actually trying to do you know a customer buys things the customer has a complaint something needs to be shipped from A to B those are our problems. How the data is going to eventually look once it's stored somewhere is later down the line right and that's why REST CRUD is there's nothing wrong with it I mean you can do that and the fact I don't know like Drupal has CRUD APIs that's fantastic it can be very useful but if you're building a big system with lots of different microservices this is not your objective your objective is not to build something where you can say put this change in this database table using this API and so on you might end up there in certain cases but not always right so don't just assume what I'm going to do is find my entities REST CRUD on top of it hey I have an API now you don't really just have a way to read and write data again because this is where a lot of the source of the coupling comes from delay dependency on data stores right to the end build interfaces build models build more replies and so on Robert Martin has a great story about this building this wicked system and they just kept delaying where they were actually going to store the pages they built the whole thing it was working but they had no data store and in the end they realized that the simplest thing which was text-based was the data store they were going to go with sort of file kind of text-based as opposed to the usual thing you would do as a MySQL database or something like that we're not database administrators we are software engineers and we're solving problems in the real world as opposed to data storage problems eventually you're going to have data storage don't have your microservices point to the same database you just pointed everything to kind of a single model and you've coupled them all together now so just be and we won't see an example of that so I'll get back to it well is everyone in agreement or are you just thinking what they have in agreement excellent how do we integrate our microservices we said it's going to be message-based and this is a great quote from Alan Kay that it was in some message board Alan Kay fundamental to object or into design I'm sorry that I call it the term objects because people focus on objects the really interesting idea is messages you have individual things and sure they have their attributes and their internal structure and so on but the way they communicate with each other is through messages another quote developers have used APIs and web services as tools to transmit serialized objects and if we've done an API we've all done it and there's so many frameworks out there say hey I'm just going to serialize all your objects so you don't need to worry about your API but that's not really solving a problem because we're not properly defining the bounds and the domain problem we're just sending data around and then we need to figure out what to do with it still so we need to look at it as services exchanging messages and within that message you're going to have some data that's fine but don't just think as long as you can send the entire kind of row of a table as Jason or to the other side you're done that's fine now there's any number if we can get to the lower level of how you actually exchange data there's any number of ways to do this and there is no right or wrong way as long as it works for you and I'll just give you an example so Netflix which is one of the organizations that has really gone all in is uses three protocols internally and those are all protocols that are far more efficient in terms of how they package data and then it uses Jason over HTTP for external consumers and Jason over HTTP is perfectly fine one thing to keep in mind and think a bit more before you build an application is do you just want to send kind of standard Jason that represents a bit of data or use something like HOS how many people know what this is or used it actually used it let's say so haters is a terrible acronym but it's hyper media as the engine of application state and essentially the idea behind it is says if we're only sending kind of the result or something for sending just a specific message we're not giving you any information of what you can do with this thing or what should you do next a developer still needs to go and look at the API documentation and figure out what else they can do this is essentially embedding information about what you can do with the thing that I just sent you and it's using the hyper media principle essentially links so here's the message and here's some things that if you follow them this are the things that you can do next or you can do with this message and so on so it's a really powerful way of doing your messaging it's also quite complex and it's not necessarily always required again it's about kind of scale and where things exactly fit the other thing to be thinking about is event sourcing and this is nothing to do with microservices specifically it's just a way of keeping track of what's going on in your application and sharing data and it's what financial institutions have been doing forever so this is understood really well so the simplest example is kind of your bank statement that bank don't just store this which is the final result your balance is 7 pounds banks store all the transactions all the ways that your bank balance has changed and that's how you can figure out where the data is right now and you get all sorts of benefits in terms of you can always replay things you can play them in different ways to see what happens and so on so think about whether as you're exchanging information between microservices what you're going to be exchanging is a series of events about how things are changing versus just a structural data model so series of events just a result and again one may be more appropriate than the other depending on what's the situation you're trying to solve another thing to be thinking about and this is you kind of see the span of the microservices way is really there's all these practices and patterns and it's putting all this together so instead of just one service sending a message to another service what you can do is use an events hub so you a service says hey this happened someone just ordered something or a package has arrived that's what that service does it does one thing and it just publishes I know that this thing happened then you can have a number of other services that subscribe to that events hub and say oh a package just arrived okay I'm the marketing service and what I'm going to do is email the user to say congratulations you know you've received your your thing or how do you think about your thing and so on so there's no direct interaction between the two services but they still coordinate to solve a problem because one of them is one of them is saying something happened and everyone else is reacting to it which leads on to how you get your micro services to achieve something together and there's two basic principles well there's many more but these are the two most important ones are you doing calligraphy or are you doing orchestration so orchestration is a single conductor and is telling each micro service what to do and that's kind of not a good idea if you're doing calligraphy it's the reason they call it calligraphy is because it's like a bunch of different dancers and each one is reacting to the movements of the other one so there's no central control they're just reacting to each other now let's look at so I have nine minutes maybe eight for example and so I have to go fast okay here's the problem we have a hotel booking service it has availability it knows when rooms are available and when they're not there's a bunch of channels that sell that hotel's availability as well this is your booking.com hotel.com and so on and so forth our problem is we need to synchronize the two so when someone books over here we need to tell all of these people we've booked there's no availability from this day to this day and this is a real problem this is something that we've built so those are my context in a way we talked about boundary context one solution is to just place something here a module whatever that knows how to talk to each one of those and it will update them looks like a good idea each channel has a different API by the way so why is this maybe not a good idea well I can't add a channel without deploying the entire Drupal site because I have to add more functionality I actually I don't have one Drupal site I'm managing about a few hundred Drupal sites for a few hundred different hotels so it's a real issue if a channel changes I need to deploy everything again if I have 50 channels this Drupal site is going to go crazy it's trying to communicate and make sure it did all the right things with all the individual channels so even though I have services here it's still not a good solution so what could I do step one what our Drupal site is going to do is become an event producer and it's just going to send events to a message queue we use message queue saying hey our mobility has changed right problem solved I send information I've still though coupled Drupal to some queue to some specific implementation of a queue and I will still need to redeploy based on changes and at this point you can make a decision whether that's fine or not in our case we thought no this is not good enough so what we actually did is we built a very simple service micro service that just knows how to get messages from this Drupal application and put them in a queue and that's it, so at the time availability changes we send a message and that little dot puts it in the right queue and now I can actually start, you know, if I get a load of sites I can easily kind of scale that, I've solved a few problems next step because we're still not sending it to the channels there's just a message that says something that's changed so now there's another service called the channel manager that picks up messages from the queue and I'm hiding a few steps of complexity here but essentially the end result of that is that it's going to talk to a number of individual services each one specializing in how each one of the channels deals with availability yeah so what I've done is I've completely separated my problems now I can change my Drupal sites without any issues I can have more channels or fewer channels and as channels change the way they want to accept information I can do that separately and all of this can be scaled there's one problem in doing all this information might have changed so there was a booking here at 0 1 second and it went to the queue and then there's another booking at 0 2 seconds but by the time I processed my queue I didn't actually I kind of lost that information right so if what we're sending the queue is the actual change by the time we get to process that change it might no longer be valid so what we're actually doing is using telling the channel manager your job is to go see if there is a change and if there is go ask the site what change that is so we've separated that bit of responsibility as well so the only thing the queue knows is something changed I don't know what it is by the time we get to process it say there was a change from the 20th to the 25th of the month there was a booking and then that booking changed so it's from the 20th to the 24th by the time I get to ask the site when I actually ask the site I'm going to get the latest information right so I've kind of solved that problem and again there's more issues here I'm trying to simplify and we do that by a gateway we actually need to know how to talk to Drupal sites so that's that's kind there's two issues here on the one hand what we've changed the system and solved a whole bunch of programs and we can actually scale and do all sorts of interesting things on the other hand crap like I had one site in channels and look at all this mess like I have to manage all of this now and that's where actually having an ecosystem that can manage and monitor all of this becomes important but you need that tool here because it's one or the other right so it's a simpler system in many different ways but you need a lot of tooling to manage it we are very lucky right now because we get all this functionality for free with cloud-based services and actually the next iteration of this solution uses longer functions from AWS and longer functions are fantastic because I don't need a listener I just need Amazon to fire up a little function and do its thing and then it dies away and it can scale until it has three breaks and then everything breaks I'm finishing. What next? I didn't talk about testing monitoring security, API getaways I'll share the slides go get this books let them read up on APIs and so on and I have to do my favorite slide just going to take one minute here's what we need to do and I'm going to read these things make each program do one thing well to do a new job, build a fresh rather than complicate all programs by adding new features expect the output of every program to become the input to another as yet unknown program do not clutter output with extraneous information avoid stringently polymer binary input formats don't insist on interactive input design and build software even operating systems to be tried early, ideally within weeks don't hesitate to throw away the composite parts and rebuild them use tools in preference to unskilled help to lighten a programming task even if you have to detour to build the tools and expect to throw some of them out after you finish using it so who knows where this comes from 1978 the Bell Labs Unix sharing system documentation 2017 we're still trying to learn these things on your solution you still seem to be having you still seem to have you have the message Q being interacted with by both the listener and the channel manager and you said don't share your database don't share your database the message Q is not a datastore though it just says something changed it's an abandoned hub as opposed to a datastore next question so you said at the beginning you meant services for solving big problems and I think you mentioned whether there's maybe hundreds of developers in the organization how much do you think can be applied is there a small team does it come as to several different external services do you wonder how much it might sense to apply much services like this I think to a certain extent it does so for example this is actually a small problem in the sense that this is really a SaaS platform program and this is being built by originally it was like seven or eight people it's more the characteristics of the problem we have and usually it's about the bigger teams but not necessarily if you're interacting with a lot of different external internal services then it makes sense anything else you're all believers in the microservice way it relates to the services so if they would like to explain what the context is what the actual context is and if that context is created for availability more things you're having message queuing how do you actually handle that like I can say cashier how do you handle that between those all those pieces there isn't I have the perfect there isn't a single way of handling that we have to look at the specifics and think about where you're exchanging data it's like that so for example the delay we have we fixed it by going straight to the side as opposed to saving the data so that you kind of change the architectures like to fit the views we're saying to minimize how fresh the data we're actually getting is but then you have to look at each single problem and say what are the tools that might be stored in here and maybe some of those tools are literally hardware or networking specific and that you dictate some latency to minimum or maximum latency and so on some of them are kind of software things I totally ignore that answer but there is no answer there's no answer there's no matter there's no answer Have you found it challenging to create this kind of much larger ecosystem? Yes it's yeah so the initial QA was we were getting Slack messages on everything and then looking at the Slack messages we realized how we can build monitoring systems that asked the right questions and the problem is there is emergent behavior even in a system as small as this and unless you actually see it and it's hard to know in advance what to you can test the individual things and you know that the individual things are doing what they're supposed to do but what's going to come up as a result is you kind of need to see it okay thank you it's Jason Jason API do you know what Jason API is yeah so yeah Jason Q yeah so it's essentially you can package the message and then you have the link in your way okay I just wanted to check the results thank you best of you I I I I really I I I I I I I I I I I I I I I I I I I I I I