In the same way that copyrights on photographs cut down on the availability of picture frames?
109 karma · joined August 14, 2013
I remember the panic of the ‘90s about the coming disruption from internet technologies, but at best it has been a horizontal revolution, rather than a vertical one, and the same wealth and power centers have survived.
You would think that a new, superior set of technology and process would revolutionize, say, the hiring process. Instead, the brute force of lots of money provides a moat where HR, hiring managers, teams, and candidates are protected from meaningful disruption and progress.
All that said, my comment is almost certainly nonsense. I was referring to the broad sway of competitive advantage and the inertia of inadequate equalibria (more nonsense, surely). If you believe I am not properly building a warrant against the technical meanings on investment analysis terminology, you are right.
After all of that resolves, it's pretty hard to emotionally connect with the rest of the story, since you are exhausted from all that came before. The final act is worthwhile and interesting, it's just a pretty big change in direction.
What is depends on is how much horizontal scale you expect to have. At a small scale, you can use something like postgres as a centralized broker of sequence. A single postgres cluster can sequence a lot of records in a hurry, no problem.
At a larger scale you might need to decompose your domain into multiple, independently ordered aggregates. Now you have multiple choke point brokers, each of which can handle a lot of records, but which don't block each other.
Step it up another notch, you can use a consensus algorithm (paxos or raft) to get a cluster of machines to agree on the state of the sequence, and perform optimizations such as assigning blocks of sequence by shard and node.
I recommend not over building your event storage architecture until you measure your actual needs. There are cheap ways and huge expensive ways, and building too much is an easy way to make your project fail. Also, one of the nice things about a sequenced set of events is that it is pretty easy to replay into your new, faster event storage later once you've had the happy problem of too much success.
Right now the compliance world is addicted to firewalls, to the detriment to reasonable appsec. In my fantasy world, I'd like the auditors to be telling companies 'in 5 years, you won't be allowed to firewall your business network, and if you aren't secure without the crutches, then no certification for you.' That would light a fire under management to care about software quality all over the place.
Now, clearly, if everybody is killing everyone beyond their immediate family, it is hard to have any sort of larger society. Living and collaborating under constant threat of immediate death wouldn't work. So we have a large set of social adaptations to limit the killing and restrain ourselves.
My point here, is that 'why do human kill other humans' is a less interesting question than 'why are the social adaptations that prevent killing not taking affect?' The problem of fighting isn't a moral failing, or some flaw in the human soul. Killing makes sense within the decision making scope of our conscious brains, and is the result of inadequate build up of collective structures of inhibition that are required to have larger groups of people in closer contact with each other, and as the groups get bigger and the contact becomes closer, we need to engineer new schemes for inhibiting the 'lets just kill them off and solve this once and for all' urge.
However! I know of a number of PaaS products that provide similar functionality, and with some effort, you can build it in AWS or Azure features, or you can build your own on top of RabbitMQ or Apache projects. The characteristics are going to be different, but it's doable. It might be like a MySQL to Postgres migration, or it might be like a MySQL to Mongo migration, but there _is_ a migration. Using a vendor product with unique advantages as a dependency is a known engineering problem with known risks. Take your dependencies carefully, but it's riskier to take no dependencies and fail to deliver a useful product.
...seriously, though. All of our views are out of date by the time we see them, and all of the user inputs have to be dealt with for races and double-submits. Eventual consistency is just the patterns you already know, but bigger.
HW sensor issues are strange, but understandable in a new product. Also, it's a pretty small impact.
The damning thing in your statement is your conversation with apple engineers...but you don't provide any information from that conversation.
Two minor quibbles with the new phone, and a secret, don't really add up to a reason for us to doubt Apple. Can you elucidate your claims, or do you just have 'a bad feeling about this'?