 Hello, everyone. So when I submitted this presentation, I didn't know that I would have the slots right after lunch. That's possibly the most difficult slots to have at an event. And usually, you need to fight pretty hard to get people's attention and to keep it and to prevent people from falling asleep. Luckily, I have a good buzzword and there's nothing like a good buzzword to keep people awake. And just in case you have... Well, I didn't see any coffee during lunch, so I added a couple more buzzwords. So there you go. Is that enough? So maybe a bit of a disclaimer at this point. Yes, there's a lot of buzzwords. No, I am not an expert at each of those. So if I say anything that's wrong or anything that's inaccurate, just let me know after the presentation. But the main topic here is microservice. And, well, yes, it's a very hot buzzword, but what does it actually mean and what would it mean, like a Drupal in the era of microservices? That's a very vague thing. So I did a good amount of research and asked quite a few people. And to me, I see really four main aspects where microservices play a big role and where I think it's interesting to take a look how Drupal plays along with these kind of aspects. So the first role, the first aspect, is definitely technology. Containers, of course. The second aspect is architecture. So containers are great, but how do you put these containers together in a way not to, like, you don't actually want to have some kind of architecture for the purpose of using containers, but you want to take advantage of all the benefits that containers give you to be able to really, like, deliver on some higher level, like, business goals. Then an architecture is good, but the kind of projects that we're working on, the digital project, they evolve over time. And so we need processes that really evolve over time as well. And here I want to take a look at how we involve and how we interact with a microservice architecture and compare that to how we interact with a Drupal project. And last, but not least, it's also about people because changing the structure of the project that we have, yes, it affects the technology, but most importantly, and I think the reason behind microservice architecture is all about how we structure people. So let's get started. As I mentioned, I have these four topics, four aspects. And for each of those, I'd like to take a look at what this actually means in general, not Drupal specific, and then also take a look at how we can apply this to a Drupal specific use case. So first one is technology. And is there one technology that comes to mind when you're thinking of microservices? Docker, yes. That was an easy one. So yeah, Docker, and well, yeah, Docker container stuff, I think, like, is everybody more or less familiar with what Docker is? I guess more or less. I think, yeah, so containerization, the idea is that you can pretty much package your software inside of a container and then you can put this container pretty much anywhere you want, move it between servers and so on. I'm not going to go too much into the details, so if you're understanding this much, that's good enough for this presentation. But Docker is about containerizing individual applications and then we can actually put multiple containers together to build more complex applications. So there's tools like Docker Compose, Kubernetes. Kubernetes is a bit of a different thing. It also does much more than just combining applications. There's other open source tools like container. And what you're doing at this level is splitting your application into multiple components. So if we're thinking of Drupal, then yes, you can definitely have one Docker container that will have a completely self-enclosed Drupal installation with the database, web servers and all of that. But actually, you might just as well use a virtual machine at that point. It doesn't make much of a difference. What's interesting with Docker Compose and all the tools that are variations of that. What you can do is you have one YAML file that you, where you define, I want a PHP web server. I want an NGINX and I want a database and I want the web server to talk to the database this way and so on. So you pretty much have one YAML file that determines the different parts of your application and then you can deploy that as a whole. But yeah, deploying that, that's, I mean, it's pretty easy to play around with Docker, but then when you want to take this into more serious setups, for example, in production, there's a couple hard problems. Hard problem number one, orchestration. So you have multiple containers. Ideally, for high-of-validity, you want to deploy them on multiple machines. Figuring out what services to deploy where and what to do when one of them goes down and all that, that's actually really difficult. And I personally don't want to have to deal with this. This is also something that's very difficult. I just want to let someone else take care of it. So one of the options, and I think that's, there are plenty of options that I'm going to mention just a few, is to just delegate that. There are plenty of systems that are competing with each other. Amazon ECS, so Elastic Container Service, is one of them. You just say, hey, I have these containers, please deploy them for me. And Amazon will take care of figuring out how to distribute things. Google Kubernetes Engine also does the same thing based on Kubernetes instead of Docker. There's also an open source called container, mentioned it before. It also provides something like that, both as a hosted solution, as like fully open source software like Drupal. So yeah, these kind of things, don't try to solve it on your own unless you really understand what you're doing. And then if you are at that point, you're probably starting, about to start a hosting company. And yeah, so that's a different topic. But if you're just looking to get some hosting, yeah, make sure that you delegate that part of the problem. The second problem is persistence. So how do you keep your data alive and make sure that it's always there, that it's encrypted, that it's backed up when, well, your infrastructure is built on containers and the whole idea of container is that you can spin that up and kill them whenever you want. That doesn't really work well with persistence. And well, also containerization is one form of virtualization. That means that you have some performance trade off. And so if you have some like high performance requirements, especially for the database, you don't want to have that in a like virtualized environment. There again, the solution is to just delegate that. If you're not familiar with the logo, that's Amazon RDS, Amazon S3. So typically the database, yes, delegate that to someone else. The file storage, also delegate that. And also our friend Contana here, they also have some interesting solution. I'm not affiliated with Contana in any way, just something that we are trying out at the moment. And actually having a lot of fun with it and being quite convinced by how it's performing. So yeah, these two things make sure that you're not trying to tackle them by yourself. But of course, if you want to get started with containers, maybe the first place to start is not going to be in production. And there's a very easy way to just get started, not in production, but for local development environments. There's a Lando. Is anyone here familiar with Lando? Okay, see quite a few people. It's actually a tool that came out of the Drupal community and it gives you a fantastic tool for local development environments where you have just one YAML file and you say, hey, I want a Drupal 8 project. Please spin that up. And Lando starts, spins up a few containers and you have something that's running. Independently of if you have a Docker-based infrastructure to start with. So this is a great way to get started. We actually started using this as the new replacement for our, the alternative to our vagrant-based solution. And it's really working great. And it lets you have a very easy start. So as I mentioned, just one YAML file that say, hey, Drupal 8. But if you want to say, well, I want Drupal 8 and I want to use NGINX instead of Apache because that's what I'm using in production. Yes, you can do that. If you want to say I want Drupal 8 with NGINX and actually I want a very specific Docker image of NGINX, you can also do that. So it works out of the box, very simple by default and also very flexible. Also comes with great documentation. So I think this is the perfect gateway drug to the world of containers. And since I'm talking about technology, well, containers are great, but that's kind of like Docker and all that. That's so 2015, we're in 2018 now. If you want to skip to the new stuff, well, take a look at Serverless. So you've probably heard of Lambda functions, a service from AWS. So instead of having containers where your application is running and it's running all the time, you can actually have single functions that gets executed and you only pay for the time that it's getting executed. Super, super cheap, there are huge community sites that are running on this kind of infrastructure that have a server bill that's maybe like 50 pounds a month. So something that's actually like amazing and that's completely different. Amazon is not the only one that offers something like this. There's also Google Functions, Azure also has some similar offering. If you want to get started with that, there's a fantastic framework called Serverless. So this is not the only way to do Serverless architecture but the Serverless framework is a great way to get started with Serverless stuff. And of course I, well, I do stuff with Drupal and so I thought, I wonder if we could get Drupal to run on Amazon Lambda. First problem is that, well, Amazon Lambda and none of the other solutions offer PHP as a language. You can find ways around that, but it's, yeah. That's a one hurdle. And then the first time that this kind of function boots, it needs to load the entire code base. And the problem is that Drupal, well, you can't just load part of the code base to execute Drupal. You need to load everything. Even if within a single request, only part of your code base will be used. And that means that the loading time that you're gonna get for a single function is way too slow. So no, unfortunately, it's not realistic to run Drupal on Amazon Lambda. If you think of trying it out, sorry, it doesn't work. But nonetheless, something that's really interesting and something that could be a great complement to your Drupal infrastructure. And so if you have any, like one off task that need to be run or something, like chunks of things that need to be downloaded based on cron runs and you don't want to have a dedicated server that Lambda functions are an absolutely fantastic tool. But going back to our topic, so, well, we have containers, we have architecture. And the architecture, how do we build an architecture around containers, especially for Drupal? And so you might think, and this is also one thought that I had at some point, well, in Drupal, in Drupal 8 specifically, we have services. We have this service-oriented architecture. So could we just turn these services into microservices? And just, well, is this analogy that makes sense then? Unfortunately, the answer is no. There are a few reasons for that. The first is that, well, Drupal services, there's a ton of them and they communicate between each other. And for typical requests, you go through many levels of services that talk to one another. And so if you have one network request for each of those, the response time is gonna be absolutely disaster. So no, this is not something that works. This is, Drupal services are way too granular. And also, Drupal services tend to be very much integrated with each other. So it's not just one vertical thing. There's also plenty of connections that go between them. And there's one very important design principle with microservice architectures is to not share storage. So this is the thing that you should not do. So if you have two separate microservices, don't have them interact through the storage, for example, through the database. Because then you're pretty much, like you don't have a clear interface, how these should be talking to each other. They are not independent. You cannot replace them independently from one another. So the way to do it is to actually have separate services with separate storage. And the only way that these services interact with each other is through a clearly defined API. So they provide an API endpoint and you really want to be able to communicate through that. This kind of principle, you can already apply it today in your own Drupal project. This is a bit of a rant, but I really dislike this field underscore prefix because it seeps into all of the data structure that you provide even through REST APIs. You find it everywhere. And if you were actually to determine like an information architecture model, would you ever call your fields something? No, no, you would just call them what they are. So this is a clear indication that we have something that's actually coming from the storage model that we use in Drupal that is actually being affected elsewhere. And so if you end up in your code interacting with entities that are coming from a different module and you're interacting it with it at the field level and you're saying, hey, this feel like give you this value, then you are actually dealing with the storage model of the other system. And so instead of doing that, just use a service or use a method on your entities so that you have something that's typed and you have a clear interface and that means that you have the possibility to change the way that these different systems work internally without changing the way that they interact with one another and gives you a lot more resiliency and it gives you also the possibility to change things over time in a controlled way. So maybe a good example of microservice infrastructure could look like this. So we have one service that has its own database, separate service that also has its own database. Maybe they could be talking to each other if needed. There might be services that don't have any storage. Things that just calculate something and provide an answer. We could also have services that are not really directly accessible and they just provide like helper functionality or data for other services. A good example for this would be maybe a single sign-on solution authentication server and typically you maybe have a load balancer in front of it that just makes it all look like just one single service to the outside world, but internally it's actually handled by different systems. And yes, maybe one of those systems could be Drupal. Maybe Drupal could be the default for these different kind of services but I think what's important here is that this is not a Drupal project. This is a project that makes use of the best technology for the right case. And yeah, maybe Drupal is the right solution for part of that. But for example, if you want like a single sign-on solution authentication server, yes, you could do that with Drupal. Is Drupal the best solution that you can get for that? I'm not entirely sure. And if you have this kind of infrastructure where everything is independent, well then you can make the best decisions for the right case. And yes, you still have to take consistency into account so you don't want to take just different technology for everything just because you can. You still need to be considered about that. And the goal here is, well, you want a system that is decoupled so that you can take the decisions about each part of the functionality independently. You can upgrade them independently. You can have different teams working on them independently again. That's the whole idea behind these microservices is to have a system that's decoupled. And in the Drupal world, when you mention decoupled, a lot of people think about decoupled means headless. Decoupled means a JavaScript front-end. And I think yes, sometimes you can, yeah, that makes a lot of sense. There are plenty of use cases where you want to have a richer experience, more user interaction, something that's better. But decoupled is not necessarily headless and headless is also not necessarily decoupled. Just because you have a JavaScript front-end that talks via REST service to your Drupal site doesn't mean that it's decoupled. It could be a tightly coupled JavaScript front-end that talks to Drupal. And so I think it's important to see that the benefit of decoupled is not JavaScript and everything that comes along with that. The benefit of having a system that's decoupled, it's actually that you can modify and you have a different life cycle for your front-end and for your back-end in the case where that's the part of the systems that you want to decouple. Then that's probably the point where I think that as a community we're missing the biggest aspects with this whole decoupled Drupal discussion. It's the process because when we're talking about an architecture and especially decoupled architecture, the goal of having this kind of setup is not so that we have things that are separate for now. It's the goal is to have things that are separate as we evolve them. And this is something that we see as a major issue with a lot of existing huge Drupal 7 installation that have been built and grown over years is that we have something that's so huge that we can't do anything about it. Like there's no budget is going to be big enough to migrate all of this, to upgrade all of that to Drupal 8 and then still end up with the same problem with Drupal 8. So what we want really is to have independent deployments for parts of the application. And so that means, well, having microservices, that's great but if you need to deploy all of your microservices at the same time, that's not gonna be a real benefit. So you want to be able to deploy those. And again, well, you want to be able to deploy those not like once every month or once every year. You actually want to have something that's much faster and that maybe, well, maybe for the typical Drupal sites and actually there's no such a thing as a typical Drupal site but deploying every day. That's definitely something feasible. Maybe if you're Amazon or Facebook, you want to deploy like a hundred times a minute. Of course, you're not deploying the entire application all the time but you want to have the possibility to deploy every single part of the application whenever you need it. And for that, you need to change, well, your deployment process but also the way that you collaborate in code. So what we've used for a long time is actually something similar to GitFlow. This is a branching model that's actually quite common. And what we're doing now is we're moving to something that's slightly different. It's not completely, it's not in conflict with GitFlow but it's a bit of an iteration on this idea. It's like trunk-based development. So yes, we still have future branches but the goal is to get them committed back as soon as possible and to really have a much shorter iteration when it comes to getting things back into the main code branch and also, and that's important to also get those things deployed. So it's not only about continuous integration to make sure that you get all your code merged together but it's also about being able to deploy this on much, much more frequent basis. If you want to do that, of course you need to take care of quality because you can't just push stuff to production and not worry about it and not have any checks. And those checks would actually be best automated. So things that you can test, especially coding standards, might think, you know, wide space and like the length of the comments and so on, it doesn't really matter that much. But actually it's a good thing to have. Having code that's readable, it's definitely one good thing. And also if you use PHP CS, so the PHP Linting tool, it gives you a lot of very useful feedback on something that will probably be bugs, including some security vulnerabilities and so on. So this is something I would definitely recommend to anyone. Make sure that PHP CS runs regularly or pretty much on every single commit as part of the OCI environment. Now a few other tools that do study code analysis that look at the complexity of the code and also point out to other vulnerabilities. So this is definitely something that's very useful. Of course you want to make sure that your build actually works. So installing all the dependencies, making sure that you don't have any conflicts between versions and so on. You should also run automated tests, whatever format works for you. So for some product, unit tests would be best for some other projects. You really depend on integrations or on content. And so you want to run integration tests there, but make sure that you run something and it doesn't need to be super deep, but it's good to have something that covers everything in general. So this way when something goes wrong, you can usually catch those. And then as you're running tests, why not run some performance benchmark? How long do the tests take to run? So that when you add something that has a little bit of a performance drawback, that you know that right away. Because as we take infrastructures and split them into multiple components, when the site is low in the end, who's going to be blamed for that? And if you need to debug performance issues across multiple services at the same time, it's going to be difficult. So make sure that you track the performance of each one of those services so that you see when you're affecting the performance. And usually, as with a lot of projects, at first the performance is great, and then the project grows, and over time it just gets worse. So being aware of that performance, I think this is really important. Same thing for security. There are many tools, like actually many of these static code analysis tools, provide some kind of security. So the security testing will not guarantee that your site or that your application is secure, but it will actually warn you when there are things that actually look not so great. So this is a good thing to have. And also monitoring. Monitoring, this is something that we typically have only in production, because the kind of tools that we use are either expensive or they're complicated to set up. And what's really interesting when we switch a Docker container-based architecture, we can actually use the same way that we facilitate the creation of these infrastructures, we can also facilitate the monitoring setup. So that means that you can have monitoring on your feature branches if you want. Could even have monitoring on your local development environment, why not? So that you have the possibility to see, hey, how are things performing over time and really to be able to catch anything that might be unusual as soon as possible. This could be monitoring, this could be logging, making sure that whenever you push a new commit to make sure that there are absolutely no errors that happen whatsoever in the database, or in the, well, database log or actually any kind of logging system. So how do we do actual deployment? And the typical deployment mechanism that you have in all of these Docker-based systems, it's pretty simple, it's a rolling update. So you start by taking down one of your instances, replace it with a new code and you just go through that and look, no downtime, that's great. You can also use these kind of mechanisms to only deploy the new version on one of your nodes and say, hey, this is the new version, send maybe 10% of your traffic to it and then once you're sure that it actually works, you can continue with your release and just spread that out to the rest. But there's one problem is that, well, all of these services, especially with Drupal, they all need to talk to the same database and you have a new version of the code and the old version of the code working at the same time. When do you import the configuration from code? Because, well, I hope everybody is using code to version Drupal configuration, but if you pushed a new configuration right away, then that's not gonna work because maybe you're depending on a new module that's there in your new code, but it's not there yet in the old code base. So you're gonna run into issues and yes, when we're using configuration management, what we're doing is we're putting this information about the database schema in the database itself and so we have this problem that we actually cannot have multiple versions of the code base that are actually talking to the same database at the same time. And then again, when running database updates, maybe you're changing the schema completely, this is the kind of thing that is guaranteed to lead to problems and yes, I always want to make sure that I have some flames in my presentation at least once. So the work around how do we do this? Well, I've actually been talking to quite a few people that actually deal with large legacy applications because these large legacy applications have exactly the same kind of problems that we have in Drupal, not saying that Drupal is largely a legacy application, but the work around is to, well, we have all these current instances of the code running and then we just take them down and spin up the new ones and there we go and there we can run our database updates and so on. That means there's a downtime, it's short one. In many cases, that's actually not a problem but if you have like a very high traffic website with like content being created all the time, this is going to be a problem and so that means that, well, whether it's another problem that you really need to fix it, this will depend on the type of application that you're working on, but there's actually a very good reason why many of the larger web applications around are all using this kind of mechanism. Well, not this one, the rolling updates because it actually provides a great safety and also great continuity type of work that you have. And one of the key methodologies that is being used to be able to push new changes is feature toggles. And the idea here, well, you want to have this kind of different deployments but the main thing that you want to do is you want to separate the deployment of new functionality from the release of new functionality. So a typical example you imagine that you have a site with a big announcement, some new functionality coming up exactly at noon tomorrow and then everybody's just waiting and just like refreshing the page like crazy. You don't want to be doing that deployment at noon tomorrow exactly at the moment where things are being like made accessible. So you want to have a toggle. So you want to have the new functionality that's already been released. But no, you want to have the new functionality that's been deployed but not released yet. And then you have one toggle that you just say, hey, now it's open. So this would be a global toggle, something that like it's either on or off but you also have roll toggles. So based on users, maybe something that's like new functionality that's only for beta users. Maybe it's based on a session. So you want to do some A-B testing, like set a cookie for half of your visitors and gives them some different functionality. Maybe you also want to schedule something. Maybe some functionality that you think might have a big performance impact. So you turn it off during like high traffic hours. And by the way, these features, this has absolutely nothing to do with Drupal features. But this is actually a very common pattern that's like if you go to microservice made-ups and these kind of places, there's plenty of presentations and articles written on this topic is actually quite interesting. But this idea, we've actually had it in Drupal forever. Like having code that's on your server and that you can activate and deactivate, that's modules. And then if you want to have different functionality for different users, actually that's just a permission system. Session toggles, we don't have something out of the box but that can be worked out. Schedule toggles, we can probably get something like that. But the problem that we have is that all of these things rely on configuration. And configuration is something that we are deploying. And so we're back to the same problem that we had before. How do you do that in a way that's like, that's decoupled from your deployment system? So there are ways to make this work but it's not straightforward and it needs some considerations. And also we need to maybe make the difference between when do we need to have something like this? When can we just do a simple deployment? And so here we have a few different cases that we really need to think on a case-by-case basis based on the project, based on the functionality that's being deployed. And I think I don't have an answer. Well, I know I don't have an answer. And I think it would be good to work out the different use cases for this to try to see if we can get a solution based in Drupal itself. Because anything that we put as an add-on, it can work but this is the kind of thing that would be really great to have inside of the configuration management system, for example. And finally, well, organizations. How do we build organizations and organizational structures around these micro-services? Because I've been talking to quite a few people, as I mentioned, and also many large industries, some people in the automotive industry, also large public organizations. And the main reason for moving to this kind of micro-service architecture, it's not for technology. The main reason is that having one big team that works on everything, it's just like super ineffective and it's very expensive and it leads to poor decisions. And so these large organizations want to work not with one large vendor, they want to work with multiple teams that are making the right decisions, that are evolving, that know the part of the business that they're working on, the part of the problem that they're working on by heart and can really take ownership of this. And yeah, so actually most of the places that use micro-services, they have one dedicated team for micro-service and this team really has ownership of the micro-service. And so it's not one team that has only developers and then they send that to someone else and that other person will do the hosting. No, we have teams that build the system and because the system is small enough, because it's contained, it's possible for that same team to also be responsible for the hosting and making sure that things are running properly. Yes, it requires some more awareness of architecture and so on from developers, but because the scope is smaller in terms of functionality, then we actually have something that is possible. And what we're seeing, yes, this means that we will not necessarily have like one Drupal project and that as a Drupal agency, we will just build the entire project. It means that we'll need to interact with others and so in these kind of larger multi-vendor setups, we'll need to interact with other companies and yes, it means APIs and just the same way that we have this principle for micro-services that if they talk to each other, they should do that through interfaces and not just by reaching into each other's database. The same way when we are working with these kind of setups, we need to get used to working with other agencies that might have completely different focuses. So we need to be able to work with API gateways. We need to work with companies that are fully focused on creating rich front-end applications. And so it's really about being able to work in a setup that has multiple types of people, multiple people from different organizations and yes, maybe some of those will be based on Drupal but I think it's stop working. So yes, maybe some of those will be Drupal but I think it's important to see we have projects, we have functionality, really put the functionality and the teams at the foreground and then Drupal is a technology that enables that but I think in the future, we're going to say less Drupal project, especially at a large scale and actually more projects that are just general digital project that also use Drupal in the place that makes sense. So in summary, can we put Drupal in microservices that Drupal have a place in this era of microservices? Well, I think yes. So running on containers, check, that's easy. You know, it's not trivial but there are plenty of people who have been doing it. Also, many people have been doing it for years. Many like hosting companies like Pantheon, PlatformSH that are using containers, not necessarily Docker but in terms of technology, this is definitely possible and there's nothing that stops anyone from using Drupal based on containers. Then creating decoupled architecture. Yes, we can do that. I think we have in all the work that's going on into different kind of API, like API first development. This is actually, yeah, actually being very useful. I think that Drupal actually works quite well in this kind of setups where it's one of many applications. Then in terms of processes, we have some work that we need to do. Make sure that Drupal can actually play by the rules when working in this kind of container-based environments where you have rolling updates and different ways of deploying code because it's not fully compatible yet. It's not incompatible but there are a lot of things that at the moment require manual attention and it would be nice to have built-in tools for that. Then for organizations, how do we work with others? Well, I think, yes, this can be done but it's something that takes effort and time and really a lot of awareness and looking beyond just Drupal and looking at technology and how to interface with other technology teams and to really use these kind of relationships to build better systems. Thank you. Any questions? Actually, as you started your question, I was thinking, yes, users, authentication. And this is one of the things that's actually very difficult to do. You can disable the node module so you can have a Drupal 8 site that doesn't have content. A Drupal 8 site that doesn't have users is currently not possible. And I think this would be very useful especially for large applications, for example, or large organization where you have some kind of Active Directory integration or some other authentication mechanisms that you don't actually want to have Drupal users, you just want to have an authentication in the system. And I think this would be great if we could put some work into making sure that not removing that functionality from Drupal but making sure that it can be disabled for those cases where we don't use it. And there are actually many services that provide this kind of authentication. So Auth0 is one of them. Amazon has like Amazon Cognito system. So, and these are actually great at doing, well, also the kind of difficult stuff, for example, GDPR, how do you handle like personal data and consent and all of these things. It would be really great if we could just delegate that to someone else. So I think, yeah, user authentication is definitely at the top of the list of what I would make optional in Drupal. Yes? So, yeah, so the question is, with just so that it's on the recording, so with this kind of multi distributed architecture, aren't we taking a step back in terms of like the consistency especially at the UI level? Yes, yes. And I think that Drupal, I would say, don't go into like distributed architecture, microservice architecture unless you need to. So if you only have one team of three people, don't separate that into like 10 different microservices because there is a certain overhead with this kind of approach and things like keeping consistency, this is really difficult. And this is actually for quite a few of these, like big case studies of microservice architectures, they still have a common front end. But yes, there are certain things like the interaction between the front end, the back end, in place editing, for example, this is really difficult to do in these kind of systems. So there are some trade-offs and yes, sometimes it's, we end up missing certain things that we are used to. But at the same time, it's also quite interesting when you don't have, for example, in place editing, editors generally don't miss it that much. So they're used to just going to the back end, finding their piece of content that they want to edit and edit it like starting the journey there rather than going to the end, like the page for the viewer or for the visitor and just starting from there. That's something that actually not a lot of users do. So I think it's really about your use case, about the needs of your users and really taking a look at what kind of compromise they want to make. Yes? Yeah, so the question is communication between microservices using queues rather than direct API calls. And there's, well, we have some projects that are using queues also in this kind of manner. Usually it's more of a buffering system, but there are also a lot of very well-documented ideas on event-driven architectures, like event queues, where instead of having direct communication between each of the system, you have exactly this kind of queue system that allows you, like it gives you more flexibility because you can have multiple systems that are like, well, they don't need to be online necessarily at the same time. So that means that if you have some downtime in one of the systems, when it comes back up, it can still respond to something that happened earlier. And so I think that these kind of systems, that's kind of the next level of decoupling from having one service make a one microservice making a direct API call to another. It's actually just putting something in a queue and then having another service respond to that queue. Yeah, so actually, if you're interested in this topic, there's this methodology called event sourcing, where pretty much the only form of communication between the different components in the system is all based on events that are stored in a queue. It lets you go back in time and do some pretty crazy stuff. But this is actually, well, it's not necessarily something that's easy and it's something that you need to have that from the start of your architecture. It's not something you just add on as an afterthought. But I think this is something that's really powerful and that we're probably going to see more of that. Yes, how to handle errors. Yeah, so actually that's one point where, well, of course you need to have a very good monitoring system that really takes everything from each of those services and when something is going wrong in one place, like your team needs to know about it. So you need to be aware, I think that's the first point. And then this is definitely one place where queues play a role because if your email is not sent out right away, you still want to know what was the information that should have been in that email. And so a queue actually lets you provide some kind of persistency for all that data and you can say, well, actually, I realized that the email server has been, has stopped working last night at 2 a.m. What are all the emails that should be sent again or these kind of things. So having some proper monitoring, also logging and these queue systems actually provide both logging and persistence of information. Yes.