...What? There is a spectrum of importance to national security, food and energy are very much on the side of more important, so not sure why you chose those as an example. It's extremely reductive to say any country that imposes limits on trade for its own strategic benefit is an autocracy.
Autarky, not autocracy. It’s an economic goal of having an economy that can continue to operate fairly well even if foreign trade is restricted. It’s associated (perhaps not exclusively) with fascist movements, which emphasized national independence from the broader world.
(I don’t agree that hedging against potential action by a single major strategic adversary is a strong move toward autarky, however—if, say, Canada had tons of fabs instead of the precariously-perched Taiwan, I bet we’d not be spending so much money on them)
Not having your country days away from starving if international shipping were disrupted isn't fascism, it's just common sense. Every country that can practically manage to have sufficient domestic food production will do so.
Meh. People still do athletics competitions even though cars exist and can outpace any human. Weightlifting is also still a thing even though even an entry-level forklift beats any human weightlifter. Chess is more popular than ever before, even though nobody has any hope of beating a computer anymore.
Out of all the fields that human do professionally, sports will be one of the last ones to disappear. The fact that it is (unaugmented) humans competing is the entire point.
I don't think the unaugmented qualifier is accurate. What matters is that there are well-established rules defining scope. People racing cars is still a very widely enjoyed form of entertainment.
> Out of all the fields that human do professionally, sports will be one of the last ones to disappear. The fact that it is (unaugmented) humans competing is the entire point.
This is my thought/hope for what we'll expect in the coming years as AI's automation becomes more commonplace. Society's interests will start going towards activities that showcase human ability - sports, livestreaming (very much its own industry now, but mostly for socializing, art, and gaming), performance, dance, etc. Sure AI can 'do' these things, but not at the level elite performers can or with the subtle nuisances in human personalities.
Even in the future when the AI is provide everything and we are no longer able to understand it, humans will be doing human competitions, playing chess, etc... The human on human action will be only thing left, and only thing humans care about. Chess is already unwinnable, but humans still want to measure themselves against other humans.
Chess, Go, what next? Pizza delivery? Accountant Simulator? Humans are already being outclassed one feature at a time.
>Truck drivers earn between min wage and 150% of min wage
Where are you getting this information? It's absolutely wrong. Long haul truckers (the one's you're saying don't have social lives because they drive 8 hours per day) make $71,196 on average in the US[1].
He is talking about France in the sentence before. There are barely any truckers in Germany with a German nationality. They are simply not competitive. Same goes for package delivery.
Just imagine what would happen to a trucker's salary in the US if it were to create a unified market with Mexico and all of Central America.
It's not necessarily a bad thing. Economies of Eastern European countries have been growing after all and Western Europe does not have enough workers because of its demographics anyway. My take is, that everybody is winning, there is less poverty than before, but some sideffects look ugly for a while.
The dose that recreational users are being told they're getting is FAR off what they are actually getting. When someone says they're taking 3 tabs of 100 microgram dosages, it's likely they're taking 50-75% of that.
Incompetence. Take my friend’s company for instance. They were frustrated paying $60K/mo to Amazon so their brilliant sysadmin bought $600K of servers and moved them into a cheap colo.
Over Christmas, everything died, and the brilliant sysadmin was on holiday. Nobody could get things going again for many days and so their entire SaaS business was failing. They lost a lot of business and trust as a result.
The sysadmin is now gone and they are back on AWS.
No key person risk management -> no risk register -> no management. Your friends company will fail regardless of poor sysadmin decision making or not. They need to hire competent management ASAP.
This is basically the logic of people who say the cloud is too expensive, you have to ignore so many things to make being on premise logical. Basically you are lying to yourself if you think you can run a datacenter cheaper and better than Amazon or Microsoft can, because if you can you are just making huge sacrifices somewhere (usually time, which is why reddit sysadmins complain about how much work they have while defending being on-premise because they couldn't possibly be wrong).
>Basically you are lying to yourself if you think you can run a datacenter cheaper and better than Amazon or Microsoft
what magical things do they have? that every single reasonably sized enterprise doesn't have? it should be extremly easy for a small enterprise to beat any of the main clouds* - they make crap ton of profit from you
*making an assumption that your needs are reasonably static and not MASSIVELY busting up and down your infrastructure
The "magical" thing they have is thousands and thousands of people thinking about how to improve the performance/efficiency/availability of their datacenters.
And yes, they pay the costs of those people and take a good profit margin, and yes there are in some ways diminishing returns to go from 3 nines to 6. But most enterprises can't match that depth of concentrated expertise, certainly not most small enterprises.
just to confirm I when i say small(ish) enterprise - i'm referring to company with around 500+ people and a IT dept of over 20+ people
seriously??!? you think you need thousands of people to to improve your effeciency and performance I would strongly suggest employing a few good infrastructure engineers/ architects who know what they're talking about - there really is no secret sauce!! just lots of kool aid on cloud
the whole cloud thing only looks wonderful and magical if your inexperienced.
re: the whole up time x9 thing is fairly useless in the real world, since the architecture of the application is really the king here!! christ on a stick i got an application running 100% for 3+ years on NT 4 because of good design (the clue is active - active - active)
also to add... availibilty zones are a very very poor mans DR
With cloud and SaaS services you are paying to reduce person risk profile.
Your forming a larger dependency on a team lead against a custom system that now is a liability as new people come to the organization don't want to adopt an abandoned poorly understood project.
This company is reasonably well run. After going back to AWS, they doubled their revenue and things are going well. They are not incompetent. They did earnestly try to cut their costs and just didn’t see the iceberg.
> [ Unmentioned - Single Point of Failure Service dependent on a single admin ]
If you are fully accounting for vacation, training, sleep etc then you need a minimum of 5 admins for mission critical services. Now, you can engineer around this to reduce your staffing requirement but I wouldn't recommend going under 2 ever because accidents happen.
This business seemed one below that, without the engineering, and I would point to the mgmt, not the brilliant admin as the problem.
> The sysadmin is now gone and they are back on AWS.
This story has nothing to do with AWS or on-prem.
It's a story about incompetent management allowing a single human point of failure. If they don't change that, they'll have the same problem wherever they go.
Non-scalable incompetence or basically pretending that the datacenter will never go down. Any high schooler with an iPhone can set up and maintain a datacenter full of servers.
But if you want something reliable that I can spend 30 seconds writing some terraform for, it will take an entire infra team to set up and maintain it, not to mention an entire procurement process and now having to integrate a new supply chain just for a basic multi-az setup (probably without things like backups and still without basic features the cloud gives you automatically).
> Services that require ad hoc query access. Though it’s possible to use external relational frameworks to implement entity relationships across DynamoDB tables, these are generally cumbersome.
> Online analytical processing (OLAP)/data warehouse implementations. These types of applications generally require distribution and the joining of fact and dimension tables that inherently provide a normalized (relational) view of your data.
> Binary large object (BLOB) storage. DynamoDB can store binary items up to 400 KB, but DynamoDB is not generally suited to storing documents or images. A better architectural pattern for this implementation is to store pointers to Amazon S3 objects in a DynamoDB table.
I said moving the workload to DynamoDB, not doing the same query pattern with DynamoDB ... :-)
For each of these workloads you switch the query pattern to accommodate for DynamoDB and provide a solution for your workload and/or app. That is actually the secret of NoSQL. You do the work upfront.
So your reading of the recommendations is correct on the surface but incorrect on the fundamental usage aspect of it. Lets have a look at each:
> Services that require ad hoc query access. Though it’s possible to use external relational frameworks to implement entity relationships across DynamoDB tables, these are generally cumbersome.
A: Dont do this. Don't do ad hoc query access. Define a series of access patterns and lay out your data to support them. You dont get ad hoc query access
for Netflix, Amazon or your Airline Travel website...
> Online analytical processing (OLAP)/data warehouse implementations. These types of applications generally require distribution and the joining of fact and dimension tables that inherently provide a normalized (relational) view of your data.
These are not most SQL Patterns. This is OLAP and was always or should be done with MPP systems, not with your relational database like your SQLServer or your Oracle. So this is going on an edge...
> Binary large object (BLOB) storage. DynamoDB can store binary items up to 400 KB, but DynamoDB is not generally suited to storing documents or images. A better architectural pattern for this implementation is to store pointers to Amazon S3 objects in a DynamoDB table.
Your Relational Database will not store BLOBs more efficiently than S3 anyway....
DynamoDB can't even represent SELECT * FROM items LIMIT 25 OFFSET 100. It's just not designed for that. It's not meant to be a relational DB replacement.
How would you do it? Assume we want proper pagination, and not rewrite the app for cursor based "Load more" style pagination. Why? Because the React Admin provider API insists. https://github.com/marmelab/react-admin/issues/1510
Your example itself shows why you would not want to do this. The database still has to read through all the rows up to the OFFSET point...
You are not supposed to do the same query patterns. My argument is that you can substitute your relational database, by changing the app and the layout of the data to match the proper patterns for DynamoDB.
If you place arbitrary restrictions upon it then of course it won't fit your model. Dynamo can handle pagination easily by passing in the last seen ID in the request. We used IDs that were lexigraphically sortable by time which has some nice properties such as never losing your position due to extra items being inserted in the middle of your query. Offset/limit aren't fun to work with.
You can go further by using the streams feature to dump your data into an analytical database for your querying needs.
DynamoDB lacks consistency (in the ACID sense, it has been it in the CAP sense which is more related to Atomicity in ACID), so you can move an SQL workload to DynamoDB by moving the consistency parts out of the DB into the code of any application that hits the DB.
That's an article about isolation, not consistency; and even there, both the RDBMS’s relevant to thus discussion (those on Aurora Serverless that it is suggested in this subthread be replaced with DynamoDB) supported serializable isolation even in their current versions at the time of that article a decade ago.
So your post is both irrelevant as a response to mine about consistency and more generally irrelevant to the entire discussion here.
The article is about ACID, both consistency and isolation not just about consistency and you can't isolate them (pun intended). The underlying of the discussion was not on consistency, instead on the possibility of using DynamoDB where you would use a typical relational engine.
From the article:
"The textbook definition of ACID Isolation is serializability (e.g., Architecture of a Database System, Section 6.2), which states that the outcome of executing a set of transactions should be equivalent to some serial execution of those transactions. This means that each transaction gets to operate on the database as if it were running by itself, which ensures database correctness, or consistency."
" This means that each transaction gets to operate on the database as if it were running by itself, which ensures database correctness, or consistency. A database with serializability (“I” in ACID), provides arbitrary read/write transactions and guarantees consistency (“C” in ACID), or correctness, of the database. Without serializability, ACID, particularly consistency, is generally not guaranteed"
I am of course ignoring the Consistency you are certainly aware that exist in DynamoDB with Strong Consistency and DynamoDB Transactions.
Moving consistency management outside of DynamoDB as you propose doesn't circumvent the CAP theorem's limitations.
I didn't pick up regular staph -- I picked up an already moderately resistant strain that became more resistant due to treatments stopped too-early due to both allergic reactions (my issue), illness/vomiting due to collapsed "stomach biome" (my issue), and undersized prescription lengths (doctors issue).
His book The Vital Question does actually address this. He says the RNA world hypothesis doesn't perfectly explain early catalysis, as RNA is a sophisticated polymer. It was most likely more simple things like metal sulphides or other inorganic complexes were primarily responsible. Amino acids and nucleotides also have catalytic activity.
