 Well, hello and welcome to another Dev nation tech talk We've got amazing things to show you guys today as a matter of fact We're gonna have a lot of fun because we're gonna talk about the non microservice today Let's talk about monolithic applications for change and actually it's gonna be kind of fun Because we actually have two experts with us on the phone from red hat today They are gonna be talking to us about their experiences real world experiences they have in the consulting world in the professional services world with real customers and what it means to go from that Monolithic world to a better monolithic world at least that's how I like to interpret it So I'm super excited to be with all you guys today again My name is birth Sutter and we're gonna kick it off right now first up is Eric Murphy So Eric if you could go and get started and screen share Okay, thank you bird. I'll get my screen stick share started here. Okay. Everybody should see my slides So today we're going to talk about future proofing your applications with modular design And before you get in slime by something called the big ball of mud so my name is Eric Murphy I'm an architect for red hack assaulting specializing in application development as first said very experienced with modernizing legacy monolith applications and building microservices for our customers and Also more recently. I've been getting involved with helping our customers adopt AI ML technologies as well Let's on helping customers architect and build cloud native Applications. I am passionate about open source technologies and the DevOps culture And I also maintain a blog which you can find at a lash not sec calm. Okay. It's great, by the way So it's for today's discussion. We're going to discuss modular application architecture and apply modularity to both monoliths and microservices For any architecture also a lash is going to demo a simple application Modeled after Instagram that that is modular It has different features like photos and legs and he's even going to do a code walk through in the demo So next let me talk about something called the big ball of mud So the big ball of mud is a haphazardly structured sprawling sloppy duct tape and barely a wire spaghetti code junk jungle these systems show unmistakable signs of unregulated growth repeated expedient repair Information is shared promiscuously among distant elements of the system often to the point where narrowly all Important information becomes global or duplicated So I bring this up because you know many applications. They start off with it with a great design But they slowly evolved into big balls of mud, right? And in a major way that you can prevent that from happening is implementing a modular architecture And by the way big balls of mud do apply to both monoliths and microservices So Bert today, I'd like to propose that there are different flavors of application modularity So the first one would be source control modularity This is where you can utilize multiple get repositories for one large application I emphasize large application there This allows you to scale up your application development across teams and this is known as programming in the large Also, number two is build modularity This is where you can build separate projects and publish artifacts in a repository such as nexus and Artifactory and for Java. You may also want to utilize mava modules a Application or contractual guarantees during compile time. So that's a great benefit I know they're not commonly used, but they do help improve your code modularity Number four is data modularity. This is where you do not want to create a tight coupling of data between your modules Such as sharing a database schema Generally speaking, you want to have a separation that concerns with your data So, you know with these four flavors of modularity They do apply to both monoliths and microservices and for building large applications You really want to apply all four of these flavors if possible But there also may be an additional flavor modularity that only applies to microservices So what is that? It is deployment modularity So deployment modularity allows you to deploy in a multiple microservices or even serverless functions Instead of one application and this may also involve partitioning data into separate deploy databases It requires inter service rather than interest service communication So you have to propagate events using a network transport Also, your your clients or your user interfaces They must utilize multiple services and potentially you might want to use an API aggregator So how do you avoid getting a slime by this big ball mode? Well, you want to strongly enforce all the layer flavors of modularity source control build code data and deployment So food for thought, you know, what major differences in code would exist between a strictly modular monolithic application and In the equivalent microservice implementation So keep that in mind as we go through the demo So now I'm going to hand it off to LS for the application demo and we can switch the slides. All right sharing my screen Okay so All right, so in this part of the presentation we would like to show you a demo application which we built in order to show you the flavors of modularity in practice and our application is called a photo gallery and it's an event-driven application and We were building it to meet the following functional requirements we have users in our photo gallery creating photos and each photo has a name and we also Organize photos in the categories like for example, we have photos of animals photos of buildings and people And when the user is browsing the photo gallery There is a button displayed next to each photo Which allows the user to add likes to a photo which he finds interesting So we are counting the number of likes per photo and we also allow users to formulate more complicated queries like for example Users may be interested to know what are the most popular photos in each category in order to address these requirements we came up with the following architecture and You can see here on the diagram that we are having The application broken up into three microservices. We have a photo service a like service and a query service And each of the services has its own Dedicated storage photo service has its photo photos database like services its own and the query service has its own data store as well now to give you an idea how The services are communicating with each other and how The application works. Let's take an example where the user is creating a photo When user is creating a photo it sends a post request to the photo service With the information about the new photo in the body of the request photo service will store the information about the photo in its own data storage and it will also Publish a message with the information that a new photo has been created And it will send that message through the message browser Similarly when the user is adding likes to the photo He sends a post request to the like service like service will bump up the counter of the likes for the given photo in its own database and it will also Publish a message to the browser with the current number of likes for the given photo And then we have a query service here who is listening on the browser For the messages coming from the photo and the like service And based on the information coming in the messages query service is Preparing its own data store To be able to later answer the queries about, you know, what are the most popular photos for the given category So I will now come back to the modularity principles, which I'm showing here. So the first one Eric talked about was the code modularity Here you can see that we do have three independent modules the photo service like service and the query service And these three services are decoupled and are only communicating via msg browser Regarding the data modularity We do have each Service having its own dedicated data store Services are not directly accessing each others data On the next slide i'm showing you a more detailed view of how the persistence layer or data model looks like The photo service is maintaining a table where the photo is identified by a photo id and we save the name and the category And the like service is just the storing the number of likes for given photo id query service Is preparing and storing all the information or data it needs to be able to answer the more complicated queries And After the first two print first two flavors, I'm going to now show you the next two Which is the source control modularity flavor and the build modularity So regarding the source control modularity We do store or we do use multiple git repositories to store the source code for the application The photo gallery common repository That's where we store all the common definitions which are actually shared by multiple modules And we also have the gallery monolith repository Which doesn't contain any source code, but it actually contains a POM file for maven to be able to build the monolithic application using the three modules photo like and query so before we go to the last modularity flavor Let me actually show you how the photo gallery looks in eclipse And for that I will switch the window here So I imported the source code for the photo gallery into my eclipse editor and The first project I will show you is the photo gallery common with the common definitions Which are shared by multiple modules We have constants here defined these are the names Of the cues where the messages are published And we also have the Format of the messages in the form of beans here in for example photo creative message looks like this so this information in right or this Classes here in the photo gallery common project Actually shows how the Three services are coupled. This is this is the only coupling they really have The this is the format of the data which they need to all understand If I show you one of the Other services, let's take the photo project Photo is or all services are written as a corpus application There are rest services you can for example see here the photo service Implementing the photos resource And there are two methods which we implemented the first one is the post Which creates a new photo Where user passes in the data, which is immediately parsed from the JSON body And we store it in the database and after that we create a message Which we publish Here to the topic to the to the browser The second method which we implemented on the photo service is the method to get all photos from the database uh here user sends a simple get request and we Create a query to select all the items from database and we on this line Serialize them into JSON and send them back in the response body and One more thing interesting here is the photo gallery monolith Where as I said, there's no source code. There's only a palm file which now Takes as a dependencies our three modules and You builds a complete monolithic application So coming back to our presentation. Let's take a look at the last modularity flavor Which we were presenting or showing today And this is the Modularity flavor our application as it is written can be deployed In two ways either you can deploy it as a monolith or you can deploy it as a set of microservices and if you choose to deploy it as a monolith What you will get is a monolithic process which is Running or which consists of all three modules running inside of that process And the three modules are communicating over a vertex event bus And in this case it is a in-memory communication. So this is not a really a distributed application All communication happens quickly in memory and This monolith now exposes one API endpoint where all three modules the the photo and the likes and the query modules are accessible and You know, you can indeed scale this monolithic application by replicating the monolith itself And you can also see that we are using one physical database However, each of the modules has its own database schema. So there is no data sharing underneath The great advantage of this kind of deployment is that you are avoiding the, you know Downsides of distributed systems like for example unreliable network communication and others Now if you want you can also deploy our application as set of microservices And in this case you will you will get Free microservices where each of the module is running in its own separate microservice or process And these microservices are again talking Over the vertex event bus. However, this time it is a clustered event bus Which is really distributed and sends the messages over the wire now This brings in the entire problematic of distributed applications And the the reliability of it Also Each service will Expose its own end point. So the user will need to somehow be able to find out about all three end points For example, you could put a facade in front of our services Or maybe an api gateway, which would be able to expose all three end points in one single api and Regarding the scaling The big advantage of this approach It is micro services approach is that you can now deploy each of the services independently It means update them independently without touching the other ones So if you are interested you can find the source code for the photo gallery on github And one more demo I have for you is I would like to show you how How this looks deployed on open shift I have two projects here for you to to look at the first one is the photo gallery monolith, which Contains the monolithic deployment of our application. You can see that we have one monolithic process connected to a postgres database and you can Indeed scale the the monolith, you know, you can have multiple instances of it if there is a more load coming into your application no problem and You can also see here in resources Now that there is this one route where all three modules the photo Likes and query are accessible on the other hand In the project here called photo gallery distributed I have deployed the distributed form of our application Where we are having three different microservices each of them connected to its own database and You can now take one of those microservices and Scale it independently and also deploy the new version independently of the other microservices And as you can see here, you know, each of the microservice will be exposed on its own route Coming back to the presentation This will leaves us with the conclusion part. So Eric will draw some conclusions for you. I will stop my screen sharing Hey Lash, since I was having audio issues, would you mind covering the conclusion? so we'll Run my screen sharing again so The basic takeaways from from our presentations are that you've seen an application Where the same code Is deployed in two different ways We have a monolith deployment with the advantages of the monolith but also disadvantages of the monolithic deployments and we and you've seen also the microservices deployment and We implemented the You know five flavors of modularity where the four ones the first four ones are I think Acceptable or are good for everybody with the fifth one where we are talking about the Deployment modularity you can make your choice based based on what you want to achieve if you prefer a monolithic deployment or if you would prefer actually to go all the way to microservices because we definitely know that A microservices has also its downsides and We were showing in this example how vertex event bus can be nicely used and works in both of the types of deployments out of the box and When you are when you are building your application You want to consider Building it first or deploying it first as a modular monolithic application and Perhaps see later if you want to actually deploy it as a microservices if there is The advantage to gain from it And if you want to find out more You can follow us You can see Eric's twitter and my twitter And you can also find more information on my blog at alaschnosec.com and You can also contact Eric on his red hat email address for further questions And thank you for Looking at our presentation All right. So benedict had some interesting questions. Let's let's try to discuss benedict Questions here one was is the broker in memory? And I believe the answer to that is yes because it's the vertex event bus Is that the broker in question that was on your slide? That's correct the vertex broker works In the process in memory And the only difference between the two deployments was that the monolithic the communication goes also in memory While in the distributed deployment the messages are actually sent over the wire Right, but it's still there's no physical broker There is no physical broker separately. Yeah, there is no such thing Okay, and there was a question around MVP. Does that mean model view presenter or minimal viable product? Minimal viable product we put this together with Eric for for the demo Yep, okay, and we already added the github repo for the sources that will be in our chat I can add it again, but we did that at once and then but benedict had another question that I think is very important And that is related to can you actually define in a very quick way? What does it mean to decide between the monolith the modular monolith versus microserfs? What are the trade-offs when you make the decision to go from one to the other? Yeah, that's a that's a very very good question. Um, let me start with the most kind of important things With uh with monolithic applications you get a big monolithic application running which kind of avoids problems of distributed systems like for example unreliable network communication between components and also With monolithic applications, it's easier to work with your data Where whereas in Distributed fashion you typically have each microservice kind of working with its own data, which you can We should then need to keep somewhat in sync and with the distributed way of deployments What you will get and what people most benefit from is the ability to independently deploy separate or So yeah individual microservices into production separately and also people tend to organize their development teams where Each development team is let's say responsible for one or several microservices and you don't have Yeah, so you can you can scale out your development that way instead of when you have a monolithic deployments Um, you have all like you you have the source code of many many people in that monolith Which is now being deployed which then leads to a need for synchronization between people Okay, Eric anything to add there I listed a great job of presenting that definitely Scalability is a concern on why you would want to Go from a monolith to microservice that being said, you know with You know quark is for example as a a new way to deploy Java applications You can create many more instances of your application In open shift for scalability and that applies to a monolith or microservices Hmm. Yeah, I was curious with the monolithic deployment Did you guys compile all the way down to native using quarkus? And if so, how much memory was it using? so This is a yeah, this is a quarkus application, which is a we are running it on jvm Um, there's one interesting Think about the memory consumption and to jvm Um, we know that when you are using java 8 um The memory consumption is very much dependent also on what you said as a max heap size for your application So it's a really a trade-off, right? You can if you let the application Eat more heap The application will definitely use it Well, if you want to kind of save on the memory You might set your max heap size to lower values and keep your application consuming less now indeed As a monolithic application you will actually have only one heap Which is better than having a distributed application where each of those microservices is now having its own heap and its own jvm Okay, now there's some questions related to the database and data for instance, alexander had one related to database modularity And database modularity you show a close coupling of data through the sharing of id's Do you know of any ways to avoid that? So i'll try to take that one. So typically with a distributed system such as microservices You want to use a universal identifier a uuid. That's how you can Create the relationships between the data logically So there may not actually be a physical connection inside of the database through, you know, foreign key constraints um, but You know collectively, uh, that there will be a relationship between the data Does that make sense Yep, no, I like the uuid answer that that makes a lot of sense to me And it's applicable even if you actually use something other than htp to distribute your application, right? You know it could be a Kafka based backbone to distribute the application or like you guys did with the vertx event bus Um, there are three separate schemas for the three tables or collections. Is that an overkill? Or is it really really needed in order to avoid future bbom? I'm not sure what bbom is I'm not familiar with that acronym But generally speaking if you have tables that are one schema The developers or a dba, they're gonna be very inclined to create those Those uh constraints, you know those relationships between the tables That will make it more difficult to separate them out into separate databases in the future Okay, so that's the reason for having multiple schemas Right, right, right And actually for people interested in database I'm pasting in the link to our free ebook that talks all about how to deal with the database In this microservices model or monolith world if the databases you're concerned then there's a ton of Strategies tips and techniques in that free ebook written by etsy and aga I encourage you guys to check that out Now there's another interesting question that I think would is very appropriate for this conversation And that is if I want to deploy one of the microservices that are all they're in the modular model if Is that possible? Some of the words you guys have the photogallery like as an example. Can I deploy like without deploying the rest? So I believe the question is about can you break them off one by one? Is that correct? Burr Well, no, it actually is about deployment. So the and I think the answer is if it's a monolith It's a single monolithic deployment If it's a monolith you have to go to microservices if you want to separately deploy the individual components. That's still true Yes, that's right Okay, and I and the bbom by the way was big ball of mud Which is funny, right because you guys started with that phrase. I couldn't think of the acronym Okay And we are we are officially out of time, but there's one last question. We'll throw you guys wait What about what about our best practice for strangling an existing tightly coupled monolithic application? Do you guys have any quick tips or tricks on how to deal with strangling that big old ugly? tightly coupled monolith So one thing I would say is you can take this legacy monolith that may be a bbom And and try to make it more modular As a monolith first Before you begin to separate off the microservices into independent deployments So you can you know refactor your existing monolith to make those improvements incrementally Yeah, and I would that's a good idea and I would add to it You also if you are then Splitting out microservices. You maybe want to start with a low-hanging fruit And split something what is simpler and is not too much coupled with the monolith And then when you have already a monolith and the microservice running next to it You can kind of feel the distributed systems problematic and decide later how far you want to still go Okay, well, we are officially out of time. I apologize that we can't stay on longer with you folks But it was a nice engaging engaging session And I enjoyed the little application by the way because actually while you were talking I get cloned at all and I did the build on my local machine Uh, so, you know, I hadn't tried to test it properly, but I did get it all to build So that's a good sign by itself So thank you all for today If you have further questions feel free to reach out to eric a lesh or myself on twitter Or you can always find me on email You guys got an email from me to even show up for today's event So you know my email address and I'll pass that on if we have questions in the future But thank you again for your time and thank you guys Everybody