221–230 of 243 posts
Earlier quoted context omitted.
When I worked at Google, they had their own string type in place of std::string for various reasons. Python has byte strings, Unicode strings, format strings, regular expression strings, and probably a few others! Rust has str and String, depending on ownership.
> Rust has str and String, depending on ownership. Why I hate Rust
I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries…
You're right that factoring into services should be based on natural domain boundaries. That said, it feels like a bit of a strawman to suggest that people are driving their architecture with naive math like this. I've definitely seen journeyman engineers coming out of FAANG and other big companies proposing overly complex service topographies, but there is always at least a veneer of semantic justification. That's n…
Is there though? Operating systems have 10K - 20K devs based on a casual internet search. Of course there are many services / processes but they are not communicating using an http API or message queue. Similarly, Postgres has 350 people. I don't think team size is a factor at all.
Earlier quoted context omitted.
You're right that factoring into services should be based on natural domain boundaries. That said, it feels like a bit of a strawman to suggest that people are driving their architecture with naive math like this. I've definitely seen journeyman engineers coming out of FAANG and other big companies proposing overly complex service topographies, but there is always at least a veneer of semantic justification. That's n…
>> there definitely is a ceiling Is there though? Operating systems have 10K - 20K devs based on a casual internet search. Of course there are many services / processes but they are not communicating using an http API or message queue. Similarly, Postgres has 350 people. I don't think team size is a factor at all.
Earlier quoted context omitted.
> (...) like using microservices on a system that gets 1k users a day. This sort of specious reasoning just shows how pervasive is the fundamental misunderstanding of the whole point of microservices. Microservices solve organizational problems, and their advantages in scaling and reliability only show up as either nice-to-haves or as distant seconds. Microservices can an do make sense even if you have 10 users makin…
> Microservices can an do make sense even if you have 10 users making a hand full of requests, if those services are owned and maintained by distinct groups. Maybe, but after the next CEO comes in, those groups would be reorganised anyway :-/ Few companies maintain their org chart for a large length of time. My last place had the microservices maintained by distinct groups when I joined. When I left a third of the pe…
That's perfectly fine, because microservices excel in that scenario: just hand over the keys to the repo and the pipelines, and you're done.
Earlier quoted context omitted.
> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The main misconception about microservices is that people miss why they exist and what problems they solve. If you don't understand the problem, you don't understand the solution. The main problems microservices solve are not technical, but organizational and operational. S…
> Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface. If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?
Earlier quoted context omitted.
> Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface. If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?
> If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?
What microservices easily provide in this scenario that is far harder to pull off with a monolith is that with microservices the service owners are able to roll out a dedicated service as a deliverable from that dialogue. Whether the new microservice implements a new version of the API or handles a single endpoint, the service owners can deploy the new service as an extension to their service instead of a modification, and thus can do whatever they wish to do with it without risking any impact on their service's stability.
Earlier quoted context omitted.
>> there definitely is a ceiling Is there though? Operating systems have 10K - 20K devs based on a casual internet search. Of course there are many services / processes but they are not communicating using an http API or message queue. Similarly, Postgres has 350 people. I don't think team size is a factor at all.
I was thinking of common server-based applications serving millions of clients. Obviously lower-level applications that must run on a single box need different techniques to encapsulate logic and enable scaling of their teams.
Earlier quoted context omitted.
I'm convinced that micro-service hell happens when the primary app calcifies and becomes too difficult to modify.
Micro-services are currently on trend so hard to argue with unless you are a founder. Maybe the best thing to do for the industry in general is go absolutely nuts with microservices. Factor projects so every method is a separate service / lambda. If anyone complains, use the single responsibility principal to snuff out all opposition. Once we've explored this to its logical conclusion the pendulum will swing back to…
Earlier quoted context omitted.
In that case complexity is created thereby proving my point anyway. Typically I define complexity as a low probability macrostate meaning low entropy. So debris generated from the explosion has a high probability of randomly occuring, while a new car has a very low probability of randomly occuring. Following this definition you arrive at a formal definition of complexity that is intuitive. Imagine a tornado that rand…
> So it is very likely for a tornado to reconfigure things into debris and extremely extremely unlikely for the tornado to reconfigure everything into a brand new car. Is this not a linguistic sleight of hand? There are billions of trillions of states we label with "debris" but only a few thousand we would call "car". So a specific state of debris, then, is equal in complexity to a car?
It is literally within the formal definition entropy. Debris is a high entropy macrostate, while a car occupies a lower entropy macrostate. There are less possible atomic configurations for cars then their is for debris. Each of these individual configurations of atoms is called a microstate.
A macrostate is a collection of microstates that you define. Depending on the definition you choose that definition has an associated probability. So if you choose to define macrostate as a car, you are choosing a collection of microstates that have a low probability of occuring.
The law of thermodynamics says that systems will, over time, will gain entropy meaning they naturally progress to high probability macrostates over time. So in other words, complexity is destroyed over time by specific laws of entropy.
https://en.m.wikipedia.org/wiki/Entropy_(statistical_thermod...
The reason why this occurs is straightforward. As a system evolves and randomly jiggles over time it trends towards high probability configurations like "debris" because simply that configuration has a high probability of occuring. Generally the more billions of microstates a macrostate contains the higher entropy that macrostate is.
Through logic and probability and the second law of thermodynamics we have a formal definition of complexity and we see that complexity naturally destroys itself or degrades with time.
This is the thing that confuses people about entropy. It's definition is a generality based on microstates and macrostates you choose to define yourself. It's similar to calling a function with generics in programming where you choose to define the generic at the time of the call.
But even within this generic world their are laws (traits in rust or interfaces in c++) that tell us how that generic should behave. Just like how entropy tells us that macrostates we define will always trend towards losing complexity.
The heat death of the universe is the predicted end of the universe where all complexity is inevitably lost forever. You can define that macrostate as the collection of all microstates that do not contain any form of organization.
Earlier quoted context omitted.
> So it is very likely for a tornado to reconfigure things into debris and extremely extremely unlikely for the tornado to reconfigure everything into a brand new car. Is this not a linguistic sleight of hand? There are billions of trillions of states we label with "debris" but only a few thousand we would call "car". So a specific state of debris, then, is equal in complexity to a car?
The technical term for this is macrostate. It is not a linguistic sleight of hand. It is literally within the formal definition entropy. Debris is a high entropy macrostate, while a car occupies a lower entropy macrostate. There are less possible atomic configurations for cars then their is for debris. Each of these individual configurations of atoms is called a microstate. A macrostate is a collection of microstates…