salamander014

This is a better analogy, but still not quite right.

This issue constantly comes up with keeping the internet free and open. Take the following:

The customer pays for their connection, say 10mbps over Verizon's network. Under a free and open internet, the customer is allowed to use that 10mbps that they PAID for in whatever damn way they please.

Why should I be subject to Verizon's idea of what my connection should be used for? Congestion happens, but a properly designed network means that the pipes are mostly free and available under normal circumstances to all customers for all the bandwidth they paid for. Doesn't matter how many devices I use on the other side of that connection, I bought 10mbps and I should be able to use that 10mbps the way I want.

This is price gouging. Plain and simple.

Also, a true Data-Warehouse has it's data frozen on a set recurring schedule, say every hour or every 24 hours. This is so that users running related jobs at different times throughout the day see the same results and are working with the same data.

If these apps get banned because they use poor dependencies, maybe better dependencies will become popular, and developers will also have a reason to be more aware of what code they are using.

Are there wing designs that encompass strong dihedral characteristics?

Their Music app versus Spotify, their Photos app versus Google Photos, their News app versus NPR...

And that's not everything.

The whole point of doing microservices is so that you can split up processing responsibility boundaries reasonably, and each team is responsible for being an "expert" in the service it's responsible for.

This also means that each service should have no other services as dependencies, and if they do, you have to many separate services and you should probably look into why hey aren't wrapped up together.

Using a stream from a different service is one thing: You should have clearly defined interfaces for inter-service communication. But if updating a service means you also need to fix an upstream service, your doing it wrong and are actually causing more work than just using a monolith.

EDIT: and because you have clearly defined interfaces, these issues with updating one service and affecting another service literally cannot exist if you've done the rest correctly.

Plug for a related tool that I use constantly.

It's called Swiss Army Knife for SMTP, or "SWAKS" for short.

http://www.jetmore.org/john/code/swaks/

This tool is one of the best tools I've ever seen. It's well thought out, well designed, and the documentation is very usable.

(Full disclosure: I have no affiliation with the author or the tool.)