Irina Dominte(Scurtu)
Microsoft MVP, Software Architect @Particular Software
Iaşi, Romania
Actions
Software Architect @Particular Software, Microsoft MVP for Developer Technologies, Microsoft Certified Trainer, always in a quest for the latest trends and best practices in architecture, .NET, and the world around it.
Irina has more than 1000 hours of delivered training, workshops, and presentations, is passionate about .NET and the world around it.
She is the founder of DotNet Iasi User Group where she tries to gather people who are willing to share their knowledge with others, and from time to time publishes articles on her blog: http://irina.codes
Links
Awards
Area of Expertise
Topics
Messaging Patterns for Modern Software Solutions
Modern software systems are becoming ever more distributed and complex, requiring efficient and reliable communication mechanisms to maintain consistency and performance.
With many moving parts, applying well-established patterns like Outbox, Inbox, and Sagas becomes crucial to achieving the key ‘ilities’ you are looking for.
In this session, we will dive into practical use cases, demonstrating how these patterns can be leveraged to tackle some of the challenges in modern software architectures. Through real-world examples, you'll learn how these patterns can enhance the resilience and maintainability of your distributed systems, ensuring they meet the demands of today’s complex environments.
The Unsung Hero of Modern Software: Asynchronous Messaging
In today’s interconnected digital world, the need for scalable, resilient, and efficient software systems is greater than ever. When simple HTTP request/response calls start to introduce brittleness and complexity, embracing messaging becomes crucial.
This talk will provide you with the knowledge and best practices to fully harness asynchronous messaging within the .NET ecosystem, highlighting how it can help decouple services, enhance fault tolerance, and transform the way you approach API design.
1 day workshop - From REST to async messaging
Most of our systems have or expose APIs that are consumed by other downstream services.
We call them REST APIs, but we actually put into practice only some of the principles that made REST a powerful architectural pattern. By doing this, we just ended up serving JSON or XML responses over HTTP.
As a consequence, we extensively use HTTP as a protocol throughout our systems without considering its limitations.
Even though we might leverage syntactic sugar like async/await when we implement communication between our system’s components, HTTP protocol has a synchronous nature.
This limits our options when it comes to choosing a communication pattern or introducing very important quality attributes like resiliency, fault tolerance, or temporal decoupling.
We overlook some of these architectural aspects until is too late, and we learn the hard way that we need them.
In this workshop, we will start with a ‘traditional’ RESTful API and make the necessary changes to introduce asynchronous messaging, all with an eye on non-functional requirements.
This is a hands-on workshop, so be prepared to write code!
By the end of the workshop, you will know how to evolve your architecture from simple to complex, from RESTful to messaging-based, that has all the extra aspects that messaging brings..
Introducing asynchronous messaging in a system is not an easy task. Sometimes, we have to unlearn what it means to do a simple Request/Response using HTTP so we can progress. Exactly this is what happens here.
We will see what are the usual steps to do that, and what transformations we have to do in our arhitecture, to accommodate this.
We will deep dive into a new world that covers queues, topics, message brokers, different abstractions, and patterns like outboxes or sagas specific to distributed systems.
# Workshop Structure & Contents
- Why API design matters
- How we address the NFRs
- what makes a good API
- Pub/Sub
- Commands
- Request/Response with messaging
- Dealing with errors
- Reliability
- Error Handling
- Fault tolerance
- Resilience tactics
- Outbox
- Sagas
- Routing Slips
- Observability
Prerequisite
This is a Bring Your Own Device (BYOD) workshop. Therefore, attendees are required to bring their device with the necessary software already installed:
- Need to have Visual Studio, or an IDE you are familiar with
- .NET 9 or higher
- Docker
- Github
- RabbitMQ installed as a standalone instance, or we will install it in Docker
Who should attend?
- The workshop targets .NET Software developers who want to have a more architecture-focused approach
- C# developers who want to understand the communication patterns and the best practices for APIs in distributed architectures.
**At the end of this workshop, you will be able to:**
- understand which APIs are best suited for which scenarios
- understand what are the non-functional requirements needed for production-ready APIs
- evolve a ‘traditional’ architecture to a more complex one that uses asynchronous messaging
- Understand what asynchronous messaging brings to the table and where it can benefit our distributed systems
.NET gRPC - deep dive
With an increasing need for scalability and performance dictated by the modern web, it becomes harder and harder to choose an API paradigm that is suitable for service-to-service communication.
While the classical models still work and have their own merits, some of them rely heavily on documentation, extensive coordination between teams or code-sharing. We use shared libraries, and over time our projects become intertwined with dependencies. In these cases, we need something to untangle those and reduce coupling. Welcome gRPC.
gRPC has been around for a while and .NET Core 3.0 welcomes it as a first-class citizen. It is contract-based, performant - with smaller response/request bodies, perfect for polyglot environments and supports different models – from client-server to bi-directional streaming out of the box.
If we sprinkle some client-side load balancing and the ability of exposing a gRPC service also as a HTTP API we might the perfect point-to-point communication mechanism.
In this session, we will deep-dive in how to use gRPC, configure client-side load balancing and gRPC transcoding to streamline communication.
1 day Workshop -From RESTful API to gRPC
gRPC has been around for a while now, but never gained the first-class citizen title when it came to implementing a downstream API.
It is contract-based, performant - with smaller response/request bodies, perfect for polyglot environments and supports different models – from client-server to bi-directional streaming out of the box. If we sprinkle some client-side load balancing, transient fault-handling and the ability of exposing a gRPC service also as a HTTP API, we might the perfect point-to-point communication mechanism.
In this 1 day workshop you will learn the how and the whys and understand where gRPC fits in the .NET APIs ecosystem.
Topics covered:
- What gRPC is and how it fits in an API context
- working with proto files, most common scenarios
- the 4 gRPC types
- Implementing and consuming gRPC services
- Documenting and exposing gRPC endpoints
- Client-side load balancing
- gRPC transcoding
- transient fault-handling
Prerequisites
Attendees will require a laptop with the latest version on .NET SDK and their editor/IDE of choice:
- Visuals Studio 2022
- VS Code
2 Days workshop - From RESTful API to gRPC
It is contract-based, performant - with smaller response/request bodies, perfect for polyglot environments and supports different models – from client-server to bi-directional streaming out of the box. If we sprinkle some client-side load balancing, transient fault-handling and the ability of exposing a gRPC service also as a HTTP API, we might the perfect point-to-point communication mechanism.
In this workshop you will learn the how and the whys and understand where gRPC fits in the .NET APIs ecosystem. At the end of the workshop you will be able to use gRPC in real production environments.
Topics covered:
Introduction
- What gRPC is and how it fits in an API context
- gRPC vs RESTful APIs
- gRPC vs WCF
Protocol Buffers
- working with .proto files
- understanding the syntax
- defining custom types
Working with gRPC
- the 4 gRPC modes
- Implementing and consuming gRPC services
- Documenting and exposing gRPC endpoints
gRPC internals
- Accessing the gRPC context
- Accessing the gRPC HTTP context
- Trailers
- Headers
- Status codes in gRPC
- Exceptions in gRPC
Transient fault-handling
- Defining policies
- Configuring a retry policy
- Configuring a hedging policy
Interceptors
- Client interceptors
- Server interceptors
- Configuring interceptors
- Interceptors vs Middleware
Client-side load balancing
- implementing a client-side load balancing
- Configuring client-side load balancing
- load balancing policies
- Round-Robin
- Pick first
- Implementing our own policy
Transcoding
- what is is gRPC transcoding
- exposing our services as HTTP
- Consuming methods from the browser
- How routing works with gRPC transcoding
- gRPC JSON transcoding vs gRPC-Web
- grpc-gateway - alternative to transcoding
Testing
- Testing with Postman
- Unit testing service operations
Health-checks
- Implementing health checks
Securing gRPC services
Documenting gRPC endpoints
Prerequisites
Attendees will require a laptop with the latest version on .NET SDK and their editor/IDE of choice: Visuals Studio 2022
Contract Testing Made Easy: Mastering Pact for Microservices in C#
In a forever evolving world of microservices, with so many moving parts, we often rely on integration type of testing to prevent bugs and regressions.
The problem with these tests is that sometimes they become flaky, unreliable and expensive to maintain and execute, due to the distributed nature of our system.
But what if we could ensure that our system’s components are compatible and can communicate with each other straight from the development phase?
Let’s have a look at what Contract testing is and see how it can help us mitigate the risk of integration bugs before running long tests, with examples in C#.
NDC London 2025 Sessionize Event Upcoming
Swetugg Stockholm 2024 Sessionize Event
DevReach 2023 Sessionize Event
Copenhagen Developers Festival 2023 Sessionize Event
NDC Oslo 2023 Sessionize Event
Techorama 2023 Belgium Sessionize Event
Swetugg Stockholm 2023 Sessionize Event
NDC London 2023 Sessionize Event
NDC Porto 2022 Sessionize Event
Techorama 2021 Spring Edition Sessionize Event
JetBrains .NET Days Online 2021 Sessionize Event
NDC London 2021 Sessionize Event
Update Now 2020 Sessionize Event
.NET DeveloperDays 2020 Sessionize Event
Tech Con '20 Sessionize Event
.NET Core Summer Event 2020 Sessionize Event
NDC Porto 2020 Sessionize Event
Swetugg 2020 Sessionize Event
NDC London 2020 Sessionize Event
ProgNET London
RigaDevDays 2019
Everyone wants to avoid the big, bad, ugly monoliths and work with “Microservices” – these awesome, world-changing, independent “micro” puzzle pieces. You can distribute the load, you can scale better, you control everything and then you fail. And then you want the monolith back. And fail again.
Microservices should be autonomous and independent, but what happens when your business domain doesn’t allow it, and you need to get data from other microservices? You’ll soon realize that simple HTTP calls are not enough anymore, or that your app is more brittle than ever and then you switch to messaging. With messaging you need to have a different mindset and be willing to embrace new challenges.
In this session we’ll explore different ways of getting data from one ‘micro-service’ to another and while doing that we’ll talk about the benefits or the drawbacks of choosing an approach or another.
Irina Dominte(Scurtu)
Microsoft MVP, Software Architect @Particular Software
Iaşi, Romania
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top