@siy, I didn't know the native image could be worst than JVM 😯
If you think of a microservice architecture, a solution deployed on Kubernetes will scale horizontally faster with native image and that's something good to have.
I am the kind of person that a half water glass 🥃 is almost full 😅
Yes and no. Instead of applying "microservice architecture" patterns blindly, let's look why you need to scale it and scale quickly. And here appears the problem: you need to scale it because initial performance is very bad. And you need to scale it quickly because, besides bad performance, overload handled even worse - Spring (to be precise - Tomcat) nearly stops handling requests. In microservice setup this is especially bad, because whole setup is not fault tolerant (despite advertising). So, deploying new instances quickly is the only way to mitigate the issue at least partially.
Besides much better performance, modern asynchronous solutions (no, Spring Web Flow is not one of them) handling overload much better, gradually increasing response time and sustaining throughput. This means that new instances have enough time to start. And number of necessary instances is much lower - i.e. handling of the same load is cheaper and causes lower impact on the environment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@siy, I didn't know the native image could be worst than JVM 😯
If you think of a microservice architecture, a solution deployed on Kubernetes will scale horizontally faster with native image and that's something good to have.
I am the kind of person that a half water glass 🥃 is almost full 😅
Yes and no. Instead of applying "microservice architecture" patterns blindly, let's look why you need to scale it and scale quickly. And here appears the problem: you need to scale it because initial performance is very bad. And you need to scale it quickly because, besides bad performance, overload handled even worse - Spring (to be precise - Tomcat) nearly stops handling requests. In microservice setup this is especially bad, because whole setup is not fault tolerant (despite advertising). So, deploying new instances quickly is the only way to mitigate the issue at least partially.
Besides much better performance, modern asynchronous solutions (no, Spring Web Flow is not one of them) handling overload much better, gradually increasing response time and sustaining throughput. This means that new instances have enough time to start. And number of necessary instances is much lower - i.e. handling of the same load is cheaper and causes lower impact on the environment.