Microkernel Architecture Pattern

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we're looking at architecture, software architecture, patterns and anti-patterns. And we are still plowing through patterns. So, front load with the optimistic stuff. This episode we're going to get small. We're going to talk about the microkernel architecture pattern. This is a pattern that you probably have seen probably many times. Maybe you didn't think of it as a microkernel architecture or that pattern. Nevertheless, I think as we walk through it, you'll say, oh yeah, seen it. It's very common. The core of how a microkernel pattern works is that there is a core. There is a piece of functionality or, you know, pieces probably understating it. But usually there is a, we'll say a foundation of a solution, which is the microkernel piece of it. And then the way that you add to it or expand to it or enhance it is through plugins. In the world of hardware, for example, we see this all the time. If you think of your laptop or your desktop, you have a core functionality of the computer. But then you've got all these plugs that are maybe for power, for audio, for mice, for mouse, for keyboard, network. You've got all these plugins. Those things provide some sort of functionality and they're based off of that interface, which is the plug. And that's how a microkernel works as well. We build our solution, which is the really the shared logic, the shared guts of our solution. And then that again gives us something to sort of think of it like the heart that now we've got that built. It's hopefully very ideally solid, high quality, does all the things that we needed to do. And then we build on top of that through these plugins. So we have these interfaces or hooks or plugin points where we can build on top of it. A lot of software solutions work this way. If you think of just about anything that you've bought or that you purchase that has modules or sometimes are called plugins or other things that you can add, add-ons to it. Even in the gaming world, it's sort of DLC, downloadable content. When you've got something that has a core piece and then you've got that interface built that says, okay, I have what I need for now. However, I'm going to provide this interface for future expansion or enhancement. Then you're looking at a microkernel pattern. The way we do this is to build something that is in itself sort of a self, essentially a solution. But then within that, determining where we can, we'll say make changes, make improvements, make adjustments. The plugins are, it's not like some of the other patterns where it's just sort of out there and it's like a listener where it just sort of goes and checks some data occasionally. Since it's a plugin, you're thinking of a plug even in the real physical world, when you put something into a plug, one, there's sort of a limited number of outlets of things that you can plug in. Then when you plug it in, that thing that is plugged in is connected to the core. It knows, the core essentially knows the plugin is there and the plugin knows that it is working with the core. Our interface, while it may be fairly simple, it could also be very complex. Within our core, we may even have something that says, here's our possible plugins. As we are running through solving problems, we can check to see is a certain type of plugin available? Does it exist? For example, if I've got a solution that possibly could generate a user interface, some sort of results, but I don't want to do that unless I'm connected to a monitor or some sort of output device, then while I'm going through, while I'm doing my solution, one of the things I can do is say, hey, is there an output device available? If there is, okay, then I'm going to send information to that, possibly to that. Maybe I've got something in the core that does it, but most likely I'm going to send through that plug, through that interface, information that is needed. Then the plugin is going to be able to do what it wants and display accordingly. Think about display. That's a good example because it may be a plugin to a monitor. It could be to a printer. It could be to some sort of file store. There's a lot of different things that you can do, but that interface is tightly defined. It's not squishy or anything like that. It's not like, for example, listener where you just say, hey, I'm sending information out there and then listeners are going to pick and choose through it. They are connected and saying, I'm working with you. From the core, here's the definition of how you work with me for this type of problem. It can be essentially just a data transfer mechanism. If you think of, I say, a customer relationship management CRM solution, the core may be the customer data and some basic manipulation of that. On top of it, maybe you have plugins where really all the plugin is, is that it connects and says, hey, I need customer data or I need access to customer data. The core, while it's doing stuff, will say, oh yeah, this thing is needing data. It needs to get updates. It's going to send me some sort of information. Then I'm going to work through that interface and pass data back and forth. It's also usually not a one way approach. It may be like a read-only plug, plug-in interface, but more often than not, it is two ways. It's going to be reading data, but it's also going to be sending update through it. That's one of those where you might as well leverage that pipe, that connection from both ends if it makes sense. This is a pattern, I think now as you've described it a little bit more, you can say, yes, that I've seen that. Now the trick is not just saying, hey, we've got plugins, but having the foresight to build plugins that are useful to external systems. That's a little different from an API. An API technically could be a form of plugin. You could have certain calls that are available and certain calls that are reading and certain that are a put or an update or an insert of some sort. You could actually use an API as a sense to build out a plugin kind of interface. Typically that's not the case. It's much more a direct connection and not just that, hey, I'm going to hit you up via an API. It's something where you are, if you're running as a plugin, if you're up and running, then it's while the core is up and running. It's not as disconnected potentially as an API solution is. That's a little different and we'll talk about some of those things in the future. With a plugin, plugins typically not going to be, it's not really going to be standalone. It's going to be something that more likely than not is very connected to that core. If that core doesn't exist, then the plugin is useless. It's sort of like a monitor. Yeah, you can plug it into power, but if you don't plug it into a computer, then you're not going to get anything displaying on it. So it doesn't really help you. That may not be a perfect analogy, but the idea I think can get across is that plugins are not, they're not standalone things. These are built on top of that core. If you think of integrated development environments, they have plugins galore, but the key to all of those plugins is that you have that core environment up. Microsoft Visual Studio Code is one of those things or Eclipse. All of those, they have these plugins that expect a certain functionality to exist, which is that core. That's the kernel part of the microkernel. And it can be very big. Both the plugins and the kernel can be very big. These can be very large pieces unto themselves or they can be smaller pieces. It depends on the problem you're solving and it depends on how you implement the pattern. Now, the challenge is, of course, as I mentioned already, is that you've got to be able to have some foresight into what sort of plugins would make sense. And then what access, essentially, do they need to have to that core? Maybe to the data, maybe to certain functions and methods. And it does fall into sort of the same kinds of things we run into when we're doing object-oriented design in general. When we decide whether things are private and public and protected, there is sort of that feel when you're doing a plugin. If you think of a class as being essentially that core, that kernel, and then other classes that work with it could be plugins, it's not, again, an exact analogy. But it's the same principle where we need to think about what is it that we need to make available to the plugins and what is it that we need to accept potentially from the plugins. And it's important to note that the plugins may be very different and you may have multiple flavors or families or types of plugins. Again, thinking back to that computer desktop example, you have maybe a plug for a keyboard, a plug for a mouse, a plug for a network, a plug for audio, a plug for video out, maybe some generic USB ports and things like that. Each of those ports, each of those plugin points is a very different interface. Now, you may have generic ones like a USB that it reads some stuff and figures it all out because that plug, that plugin point by itself has some intelligence to figure out what is being plugged in. But then you also have some that are more performance aware. They're going to be faster and tighter because they know exactly the type of interface that's required. It's a big difference if you're saying, let's have this generic USB and figure out that it's a keyboard on the end and then figure out how to work with that keyboard versus we know this is a keyboard plug. We know this is what it's sending. We know this is what it's going to be able to receive back from us if anything. And then we can go build and have the logic around that plugin point. You can do that with your application as well. You may have plugins that are focused on like read only. So maybe they're more reporting types of things. Maybe it's more display oriented stuff. Maybe it's a kind of stuff where you're doing additional computations. So data is going out, but you know that you're getting manipulated data coming back in as well. Those are different data sets. Those are different tasks. Those are different flows. And so you may have those things sort of categorized within your solution so that you can do them in a way that is as productive as possible so that where you can limit additional logic that's essentially trying to figure out what are we doing? What is this plugin interface? You can build it a little tighter because you know what to expect. And then you know if something tries to plug in and it's not that, then it's not going to work. It's as simple as that. So there are definitely some challenges to it, but it's also a very powerful way to look at building a pattern for architecture of not only your entire application, but maybe specific problems that you're trying to solve. Again, we're looking at something that can be a little bit distributed, but more likely is it's really more about flexibility. Flexibility and that is the idea of and maybe even scalability. So really those two as opposed to some of the other things that we tend to look for in our patterns like reusability and things like that. That'll do it for the microkernel pattern. We will come back next episode with yet another micro type of pattern and we're just going to keep chugging along here. If you have any requests, any questions about any of these, we can always tack some patterns or any patterns on as we get further into the series. But as always go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers to develop a new podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember just a little bit of effort every day ends up adding into great momentum and great success. Hi, this is Rob from building better developers, the developer podcast. We're excited to be on Alexa. Now you can enable us by simply saying Alexa enable building better developers and we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon.