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.
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.
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.
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.
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!".