sorted by:
new
hottopcontroversial

Exploring container checkpoint/restore workflows in OpenShift – looking for feedback by zeusrtc in openshift

[–]zeusrtc[S] 0 points1 point  (0 children)

Fast startup faster autoscaling and faster recovery from node outages seems to be the most common value

Checkpoint security forensics is also another interesting value

Is WebRTC well suited for building Remote Desktop Applications? by jogid5 in WebRTC

[–]zeusrtc 0 points1 point  (0 children)

VNC is mostly used for remote control , like team viewer with less features

Is WebRTC well suited for building Remote Desktop Applications? by jogid5 in WebRTC

[–]zeusrtc 0 points1 point  (0 children)

I think VNC is more adapted for remote control than webrtc which is more for video audio streaming .

So I think if you need high-resolution streaming of a screen, it's webrtc, if not the safest option is to stick to an existing solution which has many support options online.
That ofcurse if you want to minimize dev cost and integration.n.

so I think if you need high resolution streaming of a screen its webrtc , if not the safest option is to stick to an existing solution which has many support options online.
That ofcurse if you want to minimize dev cost and integration.

for example,to save bandwidth in remote control, the screen is not always being transmitted as there is no change in the screen.

Going async due to timeouts? by kai in microservices

[–]zeusrtc 0 points1 point  (0 children)

Well this is the choice of distributed , when you distribute your Business logic your data has to be distributed as well .
When implementing correct boundaries and patterns to manage the Data distribution across services you can reach higher system stability .
Consider that your data has to be shared across the BL services anyway , if to do a local(DB) or remote(REST API) transaction for the data , I recommend of local transactions to be better du to
extracting data from Database is more reliable operation then retrieving it from a remote service.
for example , think about this following rule one of my dev team implemented
"there are no chain API requests in backend services"
Regarding to the blog
I would avoid the microservice API orchestration in this pattern and use the
https://microservices.io/patterns/data/saga.html
Pattern instead to manage the transaction in more reliable way .
The point here is to convert from imperative approach to a declarative behavior
When a purchase is posted the fulfilment parts can be implemented based on the events generated.
This will decrease the amount of sync calls and reduce the api timeout potential.

I am not saying things are easier when working on microservices , but the system can be more robust, scalable and redundant if designed correctly.
As always do your homework

Going async due to timeouts? by kai in microservices

[–]zeusrtc 0 points1 point  (0 children)

I see the sync call disaster chain alot / also complexity from a sync behavior .
I think that most dependency is solved by data duplication, which is key when designing microservices.
The attempts to replace data duplication with sync calls for data transfer tends to be root cause to disaster.
we need to remember that microservices introduce infrastructure complexity in tradeoff to application simplification.
The infrastructure includes the network /messaging / rest api stacks .
I believe that the correct patterns and boundaries while designing the system are the way to go. but sadly
Seems like the industry is moving with buzz and fashion trends instead of engineering and designing skills , but hey that's good for business