Viewing profile — 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 rat…

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 approac…

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 featu…

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 ment…

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 …

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 m…

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…

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 engineer…

Mainly saved in infrastructure costs: Elasticsearch and Kubernetes resources.