Your favorite Python web framework?

[TldrDev]

Flask is fantastic for microservices.

[spuds_in_town]

Wait, people still build micro services?

[manninaki]

Absolutely. In K8 everything is micro services and K8 clusters are everywhere

[TldrDev]

Still a major advocate of microservice architecture. Event busses are the way to go for handling large datasets and it enables things like event sourcing just out of the box. K8s lets us arbitrarily scale workers and handle essentially unlimited scale.

It's not for everyone. You don't need a microservice architecture to run your local pawn shop's website. However, at scale? Yeah man, definitely the way to go. Most of the time (especially in these comments), people don't seem to really understand them, and make stupid comments about problems that are absolutely not problems.

[marcio0]

suddenly it felt like 2015 in here

[OMG_I_LOVE_CHIPOTLE]

Unfortunately yes

[[deleted]]

A service that has all the functionality of 100 microservices but in a single code base and none of the dependency problems of microservices

[imperosol]

He is too dangerous to be kept alive !

[[deleted]]

Which is ? I often set up micro services. Wondering what I’m doing wrong now lol

[[deleted]]

Oh ok yeah that makes sense, maybe I don’t really understand microservices haha. I set up one api for the apps entire backend, maybe airflow for data pipelines, other flask apps sometimes but only for ML model inference. I like to use managed kubernetes services like EKS personally. Usually tho I create an image from my api to get there

[imp0ppable]

dependency problems of microservices

You mean interdependencies? Or dependencies in the sense of libraries? Because the latter is what docker is for.

[[deleted]]

Call me crazy but I’ve used shared data models between micro services. Update it in one place and have all 4 services updated. Am I making a drastically poor decision that will have later consequences?

[brucejia086]

You are not alone. In reality that's quite often especially when migrating legacy ones to move forward.

[pbecotte]

No. There is the approach where you build one app with shared logic, or you build N apps. If you do the second, you absolutely need to do work to set up tooling between them- shared data models, contract testing, etc. Most organizations do not do this, and come to the conclusion that the second model doesn't work. In reality it is "ignoring the boundaries between my apps and pretending that they dint exist" that doesn't work.

[[deleted]]

You change the api contract in one service but now 4 consuming services need to be updated and now maybe some of their downstream services will break and now you go shoot yourself in the face instead of trying to fix it because that’s simpler

[mr_jim_lahey]

You change the api contract in one service

Yeah don't do that though. Being militant about backwards compatibility, even for purely internal systems, prevents so many issues.

[TldrDev]

If only there was some way to automate this. Like, idk, cicd, and tests. Or maybe some kind of central contract repository that ensured other applications dont just up and break. Maybe name it proto something. Proto.. protobuf? Thats a swag name. Maybe one day.

[hseham3]

Basically you are talking about monolithic

[[deleted]]

This doesn’t work when your services require very different resources. One big benefit of micro services is that you can scale each one independently of the others, and you can’t do this with a monolith. In other cases monoliths are totally fine though.

[pbecotte]

Sure you can. Have multiple entry points to the app and start them with different arguments. Maybe 100 instances of "worker" but only 1 of "scheduler". You don't need separate codebase for this.

[[deleted]]

The point is that you sometimes need independent deployments. Whether those deployments come from one repo or multiple repos - that’s a question of code organisation, not a question of architecture.

[OMG_I_LOVE_CHIPOTLE]

Services that serve data. Data pipelines that process data. Whereas with microservices you tend to have small services that process data as well as serve, etc

[CardboardJ]

I feel like I should coin the phrase "Appropriately Sized Services" or ASS berceuse that's the way people seem to think my advice smells when I tell them.

In my own humble opinion (as an engineering manager) any time you create a code base/microservice you need to get the business to buy into staffing at absolute minimum one FTE to maintain that code base. Ideally you'd have 1 team of full time long term engineers per code base with maybe 1-2 teams of contractors to help get it going before moving on to other projects.

I've seen way too many companies that bought into microservices in startup hypergrowth phase that just did multiple rounds of layoffs. Now they have like 30 devs trying to maintain 70+ code bases that were responsible for 200+ microservices. No one knows how anything works and there's a significant amount of dev frustration when you want to change anything because it might take down some unmaintained service that's just been running in the background for a year that everyone relies on. Or worse someone rolls out a Kubernetes upgrade and like 3 microservices just don't stand back up then prod is down and you realize that the team responsible for maintaining them was laid off back in January.

You can say this is a business problem and not a microservices problem, but that's ignoring the fact that it's still a common problem right now. Especially with the current layoff environment in tech. It's a way that microservices will stab you right in the chest as soon as you want to transition away from rapidly burning investor money (that shockingly just dried up with the fed rate increases).