Microkernel 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 software architecture patterns. In this episode, we're going to look at the microkernel pattern. A microkernel is probably a name you've heard before. You may or may not know what that means. It's just one of those that shows up often enough. It is actually a rather common architecture pattern, particularly with. I will call it there's a lot of different things, but particularly when you think of commercial software. Where you have these these plug ins that you can use to build out your product, you probably see it a lot if you use development, a lot of modern integrated development environments as a developer, you're going to see these. You're going to see that microkernel pattern use over and over again. If you look at Visual Studio code, just Visual Studio code, that product, not the full Visual Studio. If you look at Eclipse and if you look at any of the like IntelliJ and things like that, any of the the Storm type products that are out there and PyCharm and PHP Storm and Web Storm and all those kinds of good things that are pretty much all built from the same company. JetBrains typically does these. They're all going to they have some sort of a they have a microkernel pattern used for their software. And actually, in a sense, if you think of every console that exists out there, you know, from the old Atari 2600, even up to things like the modern PlayStations and Xboxes and stuff like that, it's technically it's a microkernel pattern. You know, you have this sort of stepping right into that or I guess backing into the definitional bit. You have a core and then you have these things, these plugins that you use that are a way for you to extend or specifically utilize that core. And while the microkernel typically is really the idea is that there's going to be multiple plugins that you can do at a given time. It could be as simple as a game cartridge into a console where you can only plug in. You're only utilizing one plugin at a time or only one is active at a given time. Now, this architecture allows us to build a common ground to solve certain problems. And you can think at a very large scale like, say, Salesforce or NetSuite or one of those kinds of large enterprise level solutions, there is that foundation, that core that is the ability to move data around. It does it in a consistent way. It has a consistent interface type thing, stuff like that. And then you can add on top of it, you can plug stuff in and expand it to go in a modular way, go into different solutions. So you can have something that is a core, for example, accounting is a nice, simple, not simple, but a nice example is that you have a core accounting piece that generally does transactions and stuff like that. And then within that or utilizing that, you can have plugins that plug in for accounts receivable or accounts payable or different forms of reporting, things like that. You're building on top of that foundation and it gives you that foundation gives you a set of tools to work with that data set or that within that scope. And then you build the specific tools on top of it. So one way you could think about it would be the database related, you know, another one, we've seen a lot of these database related IDEs of various sorts, where what you have is this, this foundation, you have this, the microkernel piece, that core that allows you to deal with a database. But then your plugins is that you can have these things that connect to various database types. Another good example that may be even better because there are different ways plugins can, there are different types of plugins potentially is to think about a laptop or desktop computer. It's sort of this type of pattern. You have this core functionality, the computing piece of it, but then you can have all kinds of different plugins. Now they may be the same. Apple, for example, typically has its sort of its primary connector that most things are going to have that look as far as the plugin interface. And then it figures out what the plugin does. But then there's also cases where you have very specific plugins. She may have one that is for power, one for keyboard, one for mouse, one for a monitor, one for audio in, audio out. And those each of those plugs, if you're thinking about it, if you look at your, you know, the back of your desktop computer and all the wires coming into it, they're very different. And whether or not you have that plugin determines whether or not you have some of that functionality. If you don't have a mouse plugged in, you're not going to be able to do mouse stuff. But this also means that the solution, in this case, the computer, that foundation, that core can focus on doing work for things that care about it. It's a little bit like the listener type of approach that we use with events. This one's though a little different because in this case, we can actually check to see, for example, if this is a process that has a UI plugin, it can say, Hey, do I have a UI plugin actually plugged in? Do I have something that's plugged in that is a UI device? If it is, then I need to go do this work and generate data so that that, you know, that'll go back out through that plugin and allow for a user interface for some sort of display, basically. If not, I don't have to do that work. I can just skip it. I say, you know, I say, Hey, I don't have to worry about the display portion because there's no request. It's almost like a, it is a little bit like listeners and it's sort of like a, a standing request in a plugin in some cases. But in other cases, it's a standing series of, of, it's a feed that you could have a plugin that is a data feed of some sort and says, okay, if I'm getting data fed, then I'm going to go do this stuff. If I'm not, then I don't have to process it. So it's a little different from listeners because in the, in the event approach, all this stuff gets done and it gets, gets thrown out onto queues. And then if something wants to pick it up, it can. In the microkernel, if we don't want to have something essentially registered, if we don't have something plugged into a certain or certain spot or a certain type of thing plugged into a certain spot, then we don't even have to do that work. We also can plan for the future to some extent where we can say, let's build that core functionality and then there are these other things that we may, other features or enhancements that we may want to deal with in the future. And we will pass information into those for those plugins to do that processing, processing at that time. If we don't have to, then, you know, we won't. It's just that plugins there. The data that we know we're going to push to it is there. The functionality just won't be there until there's a plugin that, that takes that on and if our plugin interface is very generic, we could actually have a lot of functionality that is available only at some later point when the actual, you know, plugin gets created to do that. In the world of data, that's actually a really powerful thing. Think of, for example, let's go back to the idea of streaming. Let's say we're streaming in data sources that are financial feeds. It's financial transactions of some sort or another, and we're just pulling this data in as our core piece. We're pulling this data in and into a data lake or something like that. We're doing something that basically says, let's take this and do some sort of massaging and then the plugins are basically access the data. Now this may sound like some sort of, like an API or something like that. And in some extents, in some instances, it can be that, that your plugins are roughly an API call of some sort, but that's not really, that's not really a microcurrent that's faking it. Because with the plugin, you have a, you have a connection that connection's there. The, the core effectively knows that the plugin is there. And then the, the plugin obviously knows that the core is there. And so those two can work together and know that each other exists. And knowing that with that context, take the best steps to solve the problem. So while the two, the plugin and the core don't require each other, it's one of those that if that connection exists, then there is a way for them to work together to solve a problem or provide a view into a problem in a sense. Cause it may be that you have a, you know, sort of that data stream approach is you have this data and really all the plugins are effectively different views or different ways to slice and dice that data. I think you can, you know, if you think about it a little bit, you can see where that becomes a very powerful pattern for building a core and then allowing additional functionality or even enhancements to some of your core offerings to be done later on. You may have some of these plugins. Uh, the things that they provide may be provided in the core. If you think of like a game console, you could have a little interface that does, I don't know, it gives you some basic, maybe it's enough that you could play a game on that little console. Uh, if you think of the Nintendo switch, it is a console, but it also can be, you can plug in a monitor and a whole different, uh, game controller and stuff like that, so you can turn it into a full blown console or it can be a little mobile thing and we have a lot of devices like that. That is the power of the microkernel. And that is all we really need to talk about for this pattern. So we're going to go ahead and get back into our work for the day. We will continue talking about patterns, but as I said, we're steadily approaching the point where we're going to get into the negatives and talk about what not to do, start talking about some Andy patterns in the next few episodes here. But until then, 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. One more thing before you go, the developer podcast and site are a labor of love. We enjoy whatever we do, trying to help developers become better. But if you've gotten some value out of this and you'd like to help us be great. If you go out to developer.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will see you next time. Thank you. And maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.