Dapr and Spring Boot - Solving the Challenges of Distributed Systems by M. Salatino / T. Vitale

Подписаться 33 тыс.

Просмотров 3,6 тыс.

50% 1

Spring I/O 2024 - 30-31 May, Barcelona
Speakers: Mauricio Salatino / Thomas Vitale
Slides & Repo: www.salaboy.com/2024/06/03/sp...
Imagine you are tasked to build the most straightforward application in a distributed system. How will your application consume external services? Which strategy will you use to ensure resilient interactions with other applications in the system? Will data consistency be guaranteed even when transactions cross application boundaries? Are you making your developer experience worse by dealing with all the complexity?
We’ve all been there. This session will demonstrate the combined power of Dapr and Spring Boot for handling the most common distributed application challenges. Dapr is an open-source, cloud-native project designed to decouple application concerns from the underlying infrastructure through convenient APIs, enabling developers to consume several capabilities without extra cognitive load.
Through live coding and hands-on demonstrations, Thomas and Mauricio will show how Dapr integrates with Spring Boot and helps you focus on writing the business logic rather than creating new solutions for recurring cloud-native patterns.
Developer experience will be paramount. It’s a promise: no YAML and no Kubernetes will be needed to develop your applications! Here’s the catch: once you’re done, your applications will run across different environments and configurations (such as Kubernetes or a cloud platform). They will integrate with other services in the system without any code change. Will we reach the goal? Join us and find out!

Наука

Опубликовано:

3 июн 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 12

@igatmatthew2283 Месяц назад

The video for screen is lagging slightly behind the audio.

@maneshipocrates2264 Месяц назад

Very interesting. Will it be optimal to refractor a multimodule spring application to use dapr?

@salaboy21 20 дней назад

It really depends on what challenges are you facing, I wouldn't refactor an entire application to use Dapr if that application is all being coded and changed by the same team. Dapr can help when you have different teams to unify approaches.

@tranceyy Месяц назад

Many have tried to solve the challenges of distributed systems, all failed.

@romank9482 29 дней назад

Are you guys so much HIGHed ? Why should i use dapr when we have spring? If you will use .NET (which has no other option then dapr - i got that) then it makes sense, but in java??? come on !!!! For other reasons there are a lot of service meshes (for logging,audits etc.) So again, why use dapr? To have limited api? Even kafka is known about using own binary protocol made them really consitent etc. And dapr is rest api.... Again, WHY???

@sawekpiotrowski4371 26 дней назад

We are currently using DAPR in a project and looking at the result I can confidently say that it creates more problems than it solves

@salaboy21 20 дней назад

@@sawekpiotrowski4371 I will be very interested in hearing which challenges are you facing, Dapr is an open source project, so if we get feedback from users we can make it better

@manuelmoya6607 15 дней назад

@@sawekpiotrowski4371 It is your point of view. Dapr is not intrusive, why are you using it if it is causing those problems? ( just curious )

@manuelmoya6607 15 дней назад

First of all, it is not an All or Nothing product. It is not intrusive, even you can use it with a service mesh. In products where you are using azure service bus, I would use it before spring cloud for azure products. If you want to use a durable execution framework, you can do it as well. For actor model ( virtual actors ), the complexity is reduced compared to akka.

@sawekpiotrowski4371 15 дней назад

@@manuelmoya6607 Thank you for your comments. While we continue to use DAPR due to existing dependencies within our codebase on it, its long-term viability is questionable for several reasons. DAPR acts as an extra abstraction layer for functionalities like secrets management and pub/sub, as well as a proxy for mTLS and tracing. This additional layer has not only introduced greater complexity but also brought a range of specific bugs that impact our operations (many of them in DAPR itself). From our real-world experience with actual project, the drawbacks, including the added complexity and maintenance challenges, significantly outweigh the benefits. Therefore, I am inclined to recommend against adopting DAPR by default for new projects.