🎞️ Videos → Defy Architectural Uncertainty by Building Schrödinger's App

Monolith and Microservices: Can an app be both?0:00

Can an application be a monolith and microservices at the same time? In this talk, we will prove that it can be done. It's mostly demos, but we also need a bit of information to align on the subject.

Schrödinger's App: Can software exist in multiple states?0:24

Let me first ask you a question. Is there anybody who does not know who Erwin Schrödinger was?

Well, okay, I will tell you. Erwin Schrödinger was a scientist who created a thought experiment with a cat in a box, to illustrate the paradoxes and peculiarities of the quantum theory, especially the concept of superposition and the problem of measurement. In other words, things can be in any state until you measure it.

Next, I will show you an example of what he meant. I think you recognize this laptop received an update. But does it work or is it broken? We only know that by opening the laptop and have a look. This is the same principle as Schrödinger's cat. But does this also relate to software applications? In other words, can we build a Schrödinger app? Let's dive into it.

Speaker Introduction: From Mainframes to Microservices, a Journey Through Tech2:06

My name is John Meeuwissen. I'm 61.

I started my career way back in 1979 as a mainframe programmer. I shifted to system programming and later software-oriented architecture, middleware integrations. More recently, I worked in low-code development,

the back-up product, and then shifted to software development,

full stack and open source with JavaScript, TypeScript. And personally, I'm a grandfather of 11.

The Big Challenge: Adapting to Changing Client Requirements3:00

Let's now first align on the subject by looking at some data from market research.

Apparently, 13% of the companies were not able to find us. But apart from that, there's one big challenge.

54% of the companies think that adapting to changing client requirements is the biggest challenge of software development.

As we all know, architecture is fundamental. And even when the code is set up modular, application modules are layered like this, like Lego blocks.

Problems with Traditional Layered Architectures4:05

Let us have a look at some problems caused by this sort of application development. First of all, implementing changes often requires refactoring of the application and its architecture. The deeper you have to go, the more it hurts. In other words, the more Lego blocks you have to remove and build up again. Secondly, refactoring the architecture basically means rebuilding the whole application or at least parts of it.

As we can only design for today and not for tomorrow, that's giving us a lot of uncertainty. When designing the application, we want to make an architecture as future-proof as possible. So you have the least need to change it in the future. But how can we make future-proof decisions when the direction of the business constantly changes? This forces it also constantly to adapt the architecture to the current needs.

The Continuous Architecting Cycle: A Time-Consuming Struggle5:46

But that's giving us a lot of time because of the Lego block architecture.

The continuous architecting. Based on the uncertainty in the architecture, we are forced to constantly change the architecture. In the past years, microservices has been the way to go. But now, since we know they come with a cost,

the monolith gains popularity again.

Modern Struggles: Balancing Microservices and Monoliths6:52

Modern struggles.

As microservices bring value in relation to

scalability and fault tolerance, we want to be able to shift our architecture towards them and away from them when needed.

But we don't want to change the architecture every time.

Just-in-Time Architecture: A Solution for Adaptability7:31

What we think might help is a separation

of concerns.

This way, we don't have to bother about the architecture at development and the possible deployment strategies.

So what we would like to have is a just-in-time

architecture deployment model that easily adapts to our needs. So develop as a monolith and deploy it in any

shape you need or like. But this requires the application to be in

a strong modular structure.

Modular Application Structure: Enabling Flexibility8:45

This is an example of an application structure that strongly adapts to the just-in-time architecture style.

It is decomposed by resource modules like post, rating, reaction, etc., and it has the basic layering as above.

This modular application structure allows

Slicing the Monolith: Vertical and Horizontal Splitting for Performance and Security9:33

for slicing.

First of all, vertical slicing. This can improve performance and fault tolerance. For example, you can load balance over multiple split-off modules that are having high load.

Second, you can separate the impact of failures in split-off functions from critical basic modules.

This modular structure also allows for horizontal

splitting. For the same reasons as performance, fault tolerance, and security.

For instance, performance, you can split off the read and write operations and separate them in multiple

segments for performance.

Or you can improve security by putting the database, for instance, in the DMZ.

Current Solutions: Service Weaver and Jitar11:20

Currently, there are two solutions aiming at splitting of a modular monolith into different services at any time. The first one is Service Weaver. It's from Google and it strongly focuses on the cloud. It supports the Go language. They offer a framework and their scope is backend. The second option is Jitar. That's an abbreviation for Just-in-Time Architecture and it's created by Masking Technology. It supports JavaScript, TypeScript. What we offer is a runtime and our scope is full stack.

Today's pick will be Jitar.

Jitar Demo: Three Deployment Scenarios with Comify12:28

Demo time. In a moment, I will show you three different

deployment options.

The first one will be the monolith by running it as a single page segment on the server with only

the backend for frontend functionality exposed.

Next, we will split off the notification function and later load balance it.

And finally, we will split off all read and write operations and put them in different segments on different servers.

To demonstrate these scenarios, we will make use of our showcase application Comify. It's a social media app.

It's a single page responsive application that can run on the web browser, tablet, or phone. And the technical stack is, it's running on Node.js, Jitar of course, React for the web UI and Java, TypeScript for the backend, and Keycloak for the authentication, Mongo for the database, and MinIO for the file system.

Comify Showcase: A Social Media App for Comics14:44

I'm a bit bigger. Sorry.

You have the profile, you have a timeline. You can explore for other comics or other creators. And here you can see who's following you or who you are following. If you have a look at there, you can find their comics. And you can react with another comic or you can react with a comment.

That's about the application.

Jitar Deep Dive: A Runtime for Just-in-Time Architecture15:36

Okay. Let's now have a closer look at Jitar.

It's important to mention that this talk is about the concept. It's not selling Jitar. For two reasons. First of all, it's open source anyway. And secondly, it's not ready for production yet.

Okay. Well, Jitar is a runtime we deliver and important thing is that it automates all client-server communication based on segments. It supports end-to-end type safety. And maybe most important, it's by configuration only. So there's not a single line of Jitar code in your application code. It also brings some powerful features like segmentation. So you can split up your application in any deployable part and deploy it distributed.

It also does orchestration over the segmented

functions. And it automatically does load balancing.

Demo: Monolith to Microservices, Step-by-Step17:21

Now, I'm going to show you the different scenarios.

First of all, currently the application is running in, like I said, a standalone mode. So everything is in one single segment.

Well, what Jitar does, it works with segments,

like I said.

By the way, is it readable for everybody? Also in the back?

Okay. Well, I will first introduce the segments.

The segments contain what will be split up.

This is, for instance, the BFF segment.

Here you expose all your features that you want to publish. And with access is public, then everybody can use it. There's also private. That means that this function can only be called within the segment.

I also have some other segment files I prepared for the demo.

Then we have services. Like I said, I now run the application with standalone. And then you can see it will start up the node, the gateway, repository, everything. And it loads a segment that that's the BFF. So that's the only one. But now, and like I said, this is running currently.

And you can see, like I showed, it works.

Demo: Splitting off Notifications and Load Balancing19:44

Now, I'm going to split off the notifications.

So I have to make this segment available for Jitar.

Because it takes all the segment files that are called JSON, segment or JSON.

Okay. Then, changing segments, you always need to rebuild

the application.

Now.

Yes. As you can see, it now builds the BFF segment only.

No.

Yeah. Here you can now see it built the notification and the BFF segment. Okay. Then we have to start up.

The repository first.

Okay.

Then run the gateway.

Then run the proxy.

And then run the BFF segment.

But we now also have a notification segment. So you also need this. And you can see he exposes the notification segment, the notification features. If we now go back, you will see that the application still works. And now if I ask for notifications, you will see that suddenly the notification segment gets a call for his feature. And the rest is just running in the BFF. Okay.

Now, I will start second notification segment.

And if I look at the gateway here, you will say, "Hey, I added a worker." So the segment is automatically registered at the gateway and will run it.

If we now go back and run notifications again,

you will see that it went to the other segment. And if you do it again, you'll see it went to the first segment again. And so on. Round robin load balancing automatically.

Demo: Separating Reads and Writes into Different Segments24:44

Now, I will split off the reads and the writes also.

So I have to make them active segments for data.

I have to stop all the workers.

And now I can rebuild the application.

And you will now see that he built four segments.

And then, oh, sorry.

I have to start all the workers again.

I have to run the BFF again.

Yes, so run the BFF.

Run the notifications again. And now we have new segments. We have to start the reads.

And you have to start the writes. And if we now go back, it still works as if nothing

happened. But if you now look, you will see that here, this is the read segment. It will suddenly get all the reads.

And you can see that again, the notifications are sent to the single notification segment again.

And if we for instance say, "I like this post," a notification will be created.

So indeed, you will see here in the write segment

activity.

Show Me the Code: Principles and Structure of a Jitar App28:14

Well, but talk is cheap. Let's show me the code. Okay.

Time to take a look at the state of the application.

There are a number of things you have to stick to to make it possible.

How you set up your application code is important

to make it work this way.

So if we look, we have web UI containing all the React components. We have integrations containing all our integrations like Keycloak, Mongo, MinIO, et cetera.

And we have of course the assets. And on the domain level, the highest level is features. It's all containing a single feature.

It's modular.

And it's in, that's about the architecture. It's a modular design. The highest level is feature and in React, in the web UI, it are all React components.

Database Management: Immutable Objects and Sagas30:11

Then the database management. One important thing, we only can work with immutable objects.

And there must be no relation in the database.

Referential integrity is in the application. And to support that, we work with sagas.

Yes, this is an example of the add of post with the saga.

Security: Keycloak, Ownership Model, and Data Aggregation31:07

Then for security, for access, we have Keycloak with OpenID. The security of the data, we have an authorization model of ownership. It means you can see everything, but you can only change what's yours. And we make use of data aggregation for the BFF. So that means we aggregate all data for the web UI. So you only have to show to them what you would like them to see. Things you don't want to expose to them, you can just leave them out of the aggregation.

Okay. And function calls are secured by the code so-called

Jitar trust key.

That's a trust key to specify at the cluster level.

Let's have a look.

No, sorry.

It's in the services.

Yes. Here, we have a trust key.

That's used on the cluster level of Jitar. And it makes sure that every function call will be

checked if it has access mode protected. The function can only be called if the caller has the same trust key. And again, the function will only run if the caller also has the same trust key as the segment has. So that's how we secure function calls.

So, as you can see here, this is for the post that

all on feature level.

So that's about it.

Q&A: Addressing Database Access and Security Concerns33:58

Are there any questions?

You have a microphone?

So my question is, those constraints, how are they For example, if I import the database directly from a place I shouldn't be, will the... Because I presume we have to compile it to something first, right? No, just build your application. Yeah, okay. When you build, will I be warned if I import something that I shouldn't be?

We work with integrations and the database is not

dynamically imported. It's imported when you build your application. You make somewhere an import of the database. But that's in a function. And you can... That function is protected by the Jitar trust key.

Okay, I see. So basically, the function that you showed us in the 𝚏𝚎𝚊𝚝𝚞𝚛𝚎.𝚝𝚜, that basically gets injected all the dependencies that it needs, and we access it through the object that gets passed to the function? Yeah. Well, all functions are exposed default, exported

default. And you just do the imports in every function. You do the import that you needs over there.

Yes? I see, I see. And in the segment, you only specify the features

that you want to expose public to the BFF or

protected, so only within the application.

And that way, the databases database access is

protected. I see. So if I do something I shouldn't, the build is going to fail, basically. The build when you do npm run build is going to fail? Or is it going to fail during runtime? Well, which protection of the database do you mean?

You mentioned that the database access is protected by some keys, right? And let's say I violated some of the rules identified

defined by Jitar in the configuration, in some of the JSON. And then if that were to happen, will the build fail during build, or will the application fail when someone calls that function? I don't quite understand. I mean, you import databases in one of the functions

of your application, yes? Well, if that import works, then the database

connection is only available to that function. And that function can only be called by trusted other

functions that call it. Oh, I see. Okay, yeah, I get it. Yeah, you never can go directly to the database. Okay. You only call database functions, and they really go to the database. Yeah, okay, I got it. Thank you.

Closing Remarks38:10

Okay.

So, any more questions? No? Well, let me show you one more thing.

Thank you.

And for those who like Mr. Schrödinger, there was a

little cartoon I found.