Sidecar Pattern to SIMPLIFY services or just more COMPLEXITY?

What is the sidecar pattern? Applications and services often have generic concerns such as health checks, configuration, metrics, as well as how they communicate with each other either directly or through messaging. Services usually implement these using libraries or SDKs to handle these concerns. How can you share these concerns across all these services so you're not implementing them in every service? The sidecar pattern and ambassador pattern might be a good fit to solve this problem.
🔗 Solace
solace.com/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to source code & demos!
/ @codeopinion
🔥 Don't have the JOIN button? Support me on Patreon!
/ codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo...
0:00 Intro
0:47 Common Concerns
1:38 Sidecar
2:47 Ambassador
5:27 Dapr Example
#softwarearchitecture #softwaredesgin #dapr

[@CodeOpinion]

I forgot, but wanted to mention latency. If you're using the sidecar for inbound or outbound communication, you're going to be adding latency because of proxying through the sidecar. Just another consideration.

[@coolY2k]

But how much does a local call takes? Also Dapr works with gRPC too.

[@rgroover007]

+1 on Dapr. If you could do a few videos and maybe some in-depth detail on pros/cons of Dapr, that would be cool.

[@manuelmoya6607]

@@coolY2k It is always under the milisecond.

[@andrewcolleen1698]

Ridiculous claim! Dapr already did benchmark and it turns out that the added latency is negligible!

[@yonatandaniyel5640]

Wow, mind blowing.. Finally, got a grasp on Sidecar and Ambassador and wonder how I may need to apply it to our current system I am working on that will requiring strangling a monolith into more autonomous microservice bounded contexts and eventually a complete migration to full on microservices.

[@Tebralicious]

Heyo my man! You are just the teacher I was searching for.. Thanks for doing this ❤️ Have a great day and keep on making these. Love your website too, packed with knowledge!

[@CodeOpinion]

Hey, thanks!

[@Its_ur_izzy9]

Excellent explanation

[@mateusztocha9260]

Thank you !

[@CodeOpinion]

You're welcome!

[@bizoton19]

great video. What is disappointing about dapr is that it has to many pre requisites for services and sidecars that are on different machines.

[@FlaviusAspra]

I'm so glad you set things straight at the end of the video: if you don't have many services with different stacks, don't use sidecars. If you have different services and different languages, I would add: question that first.

[@CodeOpinion]

I think there are a lot of reasons why you may be using different languages/platforms for various services. Not saying don't question it, but I do think it can be very valid.

[@FlaviusAspra]

@@CodeOpinion I've seen just too often teams choosing yet another language just because.

[@coolY2k]

Dapr was created for building distributed applications with the same or different stacks. I do not understand the logic behind your other stacks argument?

[@tharun8164]

You can still benefit from sidecar even if you use the same stack. In our case, we use multiple services on same Java stack. We use sidecar for handling resiliency aspects like retry logic, circuit breaker, mtls and monitoring. Infrastructure aspects can be decoupled from application logic and can be made unified across all microservices.

[@FlaviusAspra]

@@coolY2k I'm very much a proponent of convergence in architecture. I'm not against using Dapr when appropriate, but more often than not I see such tools used as bandaids, leading to a mutilation of the architecture. Too many tools, used too often improperly, which lead to unnecessary complexity. I'm the kind of guy who as a contractor got told that I did in 3 months alone what Amazon would do in a year with an entire team. There are plenty people better than me, but I also know my sh&%

[@raghavbuz]

I might have missed something, but where is the code for side car? Do you have any github repo with example which you mentioned?

[@AdamTheBen]

Hi Derek, can you recommend a book where I can find these patterns?

[@CodeOpinion]

There are some older books that still hold some weight. Enterprise Integration Patterns by Gregor Hohpe is one.

[@ShayanFiroozi1]

#request Hi please compare , design and implement the best way for Interprocess Communication in C# , WCF , Named pipes , shared memory or what ? Thank you.

[@greenpulp.]

Could this sidebar approach be used to implement the Outbox pattern?

[@CodeOpinion]

You could so as long as the sidecar is leveraging the same data store where you're persisting your business data or it had some means of providing a distributed transaction with it alongside your primary data store

[@joebowbeer]

Getting hooked on Dapr, I lament that I can't use it to proxy my own services as well. Given that Dapr exists for cloud services, why can't I add my own services so that Dapr proxies everything consistently?

[@bretzel30000]

I don't get it, even if there are polyglot containers running in the microservice system, they will talk with Rest or Grpc with each other which already provide the abstractions, why do i need this additional level of abstraction?

[@CodeOpinion]

Sidecars can provide a common way to deal with shared concerns such as how you do healthchecks, configuration, logging, tracing, etc. Instead of each service implementing it's own, just use the sidecar that provides it.

[@tharun8164]

In the usecase of message broker(MB), instead of directly using message broker's sdk you are using dapr sidecar sdk. What's the real benefit in this scenario?

[@CodeOpinion]

Abstraction. You have a uniform interface for all services that interact with the underlying broker in the same way that's provided by the sidecar. Serialization, retry logic, routing are all handled by the sidecar. If you have different "channels" for different services, the sidecar handles knowing where to connect/publish/subscribe.

[@m1dway]

@@CodeOpinion keep in mind, there's no inbox/outbox pattern, so that might be a bit of a bummer.

[@okharev8114]

if im not mistaken the dapr sdk is a just a simple wrapper around http rest api calls, it's just there for convinence, but you could just use the standard library of your language to make a call

[@felixcornelissen89]

It can also be helpful for designing relatively liberal enterprise policies. As long as teams only use libraries that have a sidecar, and only write in languages that have a dapr sdk, they can theoretically use any combinations of the two. This can make the decision to support either a library or a language in an enterprise a bit more straightforward

[@andrewcolleen1698]

It handles observability and trancing as well as security

[@n3v3rd1e]

Why do you think that setting up env with libraries and SDKs for only one language is easier than doing it with dapr? Why not use dapr as a default "framework"?

[@CodeOpinion]

It depends on the number of services you have. If you have 3, it may not be worth the sidecar because you could just share package and keep it in-process

[@n3v3rd1e]

@@CodeOpinion What I mean is, why wouldn't I prefer dapr even having only one service? Don't you think it provides enough benefits in this case as well? Why exactly not?

[@everydreamai]

@@n3v3rd1e Did you watch the video to the end? It's more complexity, thus more work to build initially, slower time to market, more processes to monitor, more to deploy, more latency for adding more network hops and marshalling data over the wire, maybe an extra contract to write and maintain, etc. Instead of using DAPR you may be able to just reference Polly in your code, and that's probably less effort to learn and implement. If you are looking to learn I'd suggest trying to run your own kubernetes cluster. Once you start working on tutorials and such, writing a few services, you'll likely encounter sidecars more naturally.

[@CodeOpinion]

Correct. As usual, it's tradeoffs. Adding a sidecar adds complexity, everything you outlined. However, that can be beneficial if you want abstract/uniform way to handle common concerns and communication, etc. Having a ton of services that all need to implement the same thing over and over again, which likely is inconsistent, a sidecar can actually simplify that, but at the cost of everything you outlined (more latency, deployment, monitoring etc).

[@andrewcolleen1698]

@@everydreamai how does it make things complex? Dapr is design to make things easy so developers can focus on things that can add real value to the business rather than worrying about infrastructure.

[@damilola_adegunwa]

you said nothing about the part of the cli "dapr run..." thing you did. I was trying to recreate... I was getting: =) "Error starting gRPC call. HttpRequestException: An HTTP/2 connection could not be established because the server did not complete the HTTP/2 handshake.", DebugException="System.Net.Http.HttpRequestException: An HTTP/2 connection could not be established because the server did not complete the HTTP/2 handshake. What do I need to do in the cli??

[@CodeOpinion]

Check out the quick start: docs.dapr.io/getting-started/quickstarts/pubsub-quickstart/

[@dariobellini1802]

@@CodeOpinion Thanks

[@coolY2k]

I think you should have explained Dapr better. Sidecar pattern for only pub/sub may not be that practical. Still, if you consider that you get with Dapr: actors, state management, secrets, pub/sub, service discovery, etc., it looks like a much better proposition. Also, even junior devs can work with REST. It can be easier for new developers to work with simpler abstractions. Maybe a separate video about Dapr only?

[@CodeOpinion]

My intent wasn't to really illustrate/spotlite Dapr it was more to explain the sidecar and ambassador patterns and the problem they solve. As with most of my videos, I like to show some example of the underlying concepts. I was just using Dapr to illustrate.

[@andrewcolleen1698]

Lol to say sidecar adds complexity is ridiculous 🤣🤣🤣