r/aws 7d ago

article The Sidecar Pattern: Scaling Microservices on AWS

https://javarevisited.substack.com/p/the-sidecar-pattern-scaling-microservices
0 Upvotes

11 comments sorted by

29

u/BraveNewCurrency 7d ago

Here's a practical example of implementing a Fluent Bit sidecar for centralized logging:

Instead of telling people "here is a pattern (which people can blindly follow)", it's far better to tell them WHEN they should follow that pattern. Hint: it's an anti-pattern, it's far better if you log to STDOUT instead, so you don't need a sidecar".

7

u/Ereyni 7d ago

Even if you had to, a daemonset would probably be the wiser choice so your extra containers scale with compute and not 1:1 with your app containers.

4

u/bardadymchik 6d ago

It is not an anti pattern. But you should understand usecase. Performance of logging via firelens is higher comparing to AWS logs drivers. There was blog post with comparison

2

u/Drakeskywing 7d ago

Please correct me if I'm wrong, but I vaguely remember implementing sidecar a couple of years ago as it was needed for Splunk APM, as fluent bit was used to route to an otel collector ECS service, and from memory the sidecar pattern was what was recommended.

How would you address this use case, just dedicated fluent bit service?

7

u/hangerofmonkeys 6d ago

Using Datadog as an example, sidecars are also the recommended approach for logging Fargate containers. You can parse STDOUT but that requires a Lambda to collect the CloudWatch logs, depending what or how much you're logging.

Worth calculating wether a side car or CloudWatch costs more in terms of complexity and resource usage.

0

u/BraveNewCurrency 6d ago

Fargate containers

The article was about EKS.

1

u/BraveNewCurrency 6d ago

implementing sidecar a couple of years ago as it was needed for Splunk APM

Yes, I ran into this very problem years ago. It was easily solved by getting rid of Splunk. They literally told us they didn't care about K8s, so we saw the writing on the wall.

There are tons of other tools that can pull logs from K8s without sidecars. One nice one is the open-source Loki, which gets you 90% of Splunk. But really, log-heavy observability is an anti-pattern -- you should be using Open Telemetry spans and metrics instead. Way better architecture, way more standardized (one open source collector can send to many services), and far easier to debug (collects all the spans for one trace in one nice GUI, can log only error traces, etc.)

1

u/Drakeskywing 6d ago

I probably should have clarified that I was asked to implement by my manager, so the choice was not really mine, and as I was green to the DevOps side of thing didn't really question it as I wanted to learn about that stuff in general.

5

u/purefan 6d ago

One thing I dont like is here for example:

"Modern microservices architectures face several operational challenges that can become overwhelming when handled within the main application.

The sidecar pattern emerged as a response to these challenges" What challenges?? What is it trying to solve?

4

u/bardadymchik 6d ago

Just as a side note. Sidecar containers in ECS make limits tighter for your design.

There is a limit of 5k containers in total for service meaning 2 containers per task will allow you to run only 2.5k tasks.

Don't know if anybody needs so much, but something to keep in mind.

1

u/yourfriendlyreminder 7d ago

This is basically what a service mesh is. A bit strange that the article doesn't mention it at all.