seperman

Very interesting. Why does Claude find more problems if we mention the code is written by another developer?

I’m the same way — I skip straight to pricing too. Curious though: when you get there, do you prefer seeing a few fixed tiers (like the classic “3 bucket” layout), or would you rather have a usage-based formula where you can adjust a slider or input your exact needs and see the price change in real time?

I have been working on a data validation tool for a while. I even tried creating an extended YAML parser for data validation. You made me realize I wasted my time with that approach. Better now than later. I would love to talk to you before I throw away more code. Can we connect?

It seems things are coming back full circle. From what I remember, Guido wanted Python 3 to be a whole new spec and not be backward compatible with Py2. Then they kept adding features to make it backward compatible.

We do use libraries as much as possible. However we avoid putting business logic into libraries.

It took over a quarter of the year with one engineer 100% dedicated to it and between 1 to 3 other engineers involved part-time over different stages of the project.

That is a great question. Kubernetes and docker and the recent addition of service mesh layer definitely do make things easier for micro-services. However as another commenter mentioned, Microservices are typically an organizational rather than technical feature. We do use pubsub pattern for distributed processing widely. Regarding the http boundaries point that you brought up, we use gRPC instead of HTTP for most services.

Hmm, not sure if I'm completely following... Yeah you can consider them separate entities if they are truly decoupled.

There are pros and cons to the micro-services architecture. To your point it is not a black or white solution. Our systems are fairly large and over-engineered.

Often switching to microservices means reducing the complexity of communication between teams at the expense of increasing the complexity of communication between services.

Exactly. I could not have explained it better than you.

This is a very simplified version of our architecture just for the purpose of this article. We have exactly 83 micro-services currently.

I was just disagreeing with "Microservices are almost completely opposed to agile development". You can be agile in both monolith architecture and micro-services. I don't see why microservices can be opposed to agile.

Lol, Mirco-service architecture is a vehicle that can make it easier to achieve those goals. It is not a black or white solution. There are pros and cons.

Not sure if I agree with you regarding the agile part. If each team owns their "micro-service", then they can have their own "sprints".

So far it has worked I guess!

The performance gains of the API were not the by-product of cutting into micro-services. Basically this article is about "We had some issues with the monolith, we cut it into micro-services and also did these other changes along the way that saved us money and gave us performance boost. Changes that we could have done in the monolith but they were less risky and easier to do in the micro-service in comparison to doing them in the monolith."

I do not disagree with your comment. As I mentioned in the article the main reasons to break into micro-services are:

1. Independent releases 2. Easier for on-boarding new engineers 3. Scale micro-services independently

The rest of the article is about how to use the breakout opportunity to make major changes to the code and the data-structure. The goal is for the users of the service to have an aha moment of "Search is so much faster after the breakout!".

Mainly saved in infrastructure costs: Elasticsearch and Kubernetes resources.