Yes, but this "enterprise" crapware is the transaction system of your bank, and those "few bytes" are your last paycheck. Have some respect for the software that makes the world around you function.
They're most likely still running all their transaction processing on a single mainframe (+another one for redundancy) with something like IBM CICS [1, 2]. And they most likely also have a lot more transactions than in the 60s (card payments, internet banking, etc.).
Most banks and payment systems have old, reliable codebases, a lot of them even in COBOL. Banks don't play with those systems often, and they don't use monstrocities like J2EE for them.
It's the other kinds of enterprise systems that are crap and deserve no respect. Intranet apps in big corporations, the BS systems that always mess up your bills in services companies, slow as molasses web portals for big enterprises and organisations etc, ERP and CRM apps...
Grew up on a farm in Scandinavia and have witness a few of these up close. The amount of debris they can accumulate is staggering - mostly nails, and corroded clumps of metal (probably from old farming equipment). There was nothing particular about the fields where their food came from, in fact it would be considered very clean, almost ecological. But hundreds of years of harvesting will leave a footprint. Also, in the earlier days when renovation was not set in system they used to bury their trash (what else could they do really).
My father always explained that interest for rusty metall with the cows attempt to balance out a iron-deficiency. Could be wrong though.
Found there behaviour always fascinating. They internal groom-group friendships and the one or two weakest cows they would trash up to feed them too any predator(yes, they have a social life in that way).
Not happy how dairy farming selective breeding has crippled them. If you have to inject a hormon into a creature for milking, else it gets sick, you have overstreched it to the point of crippeling.
still like farmers though and without them cows would go the way of everything wild in that juicebox that is earth.
I don't know, S3 and DynamoDB are both eventual consistent. And keeping in mind the CAP-theorem it makes sense. And I for one love SimpleDB - it's just that, simple. And great for prototyping (really cheap) and small production-loads. Often you just need a place to stick your data, scalability can be achieved to adding a caching layer.
You can choose eventual or fully consistent in DynamoDB. Given that full consistency comes at a higher cost (read from a quorum of replicas) we expose that cost to you.
BTW nobody wants eventual consistency, it is a fact of live among many trade-offs. I would rather not expose it but it comes with other advantages ...
They have actually been making S3 _more_ consistent over time: in the newer regions you get e.g. read-your-writes for object creation. DynamoDB also supports consistency, though still defaults to eventual consistency if you prefer.
In my mind, there's definitely a trend towards consistency here. I'd love to see an AWS blog post about the reasons behind this!
Could you elaborate on which issues you ran into. We are in the process of upgrading to from jdk7 to jdk8 (at-least for the services we see having a long lifespan) and it would be great to hear some real world experience.
Yep, no problems here. 80GB dataset, indexes are around 10GB, one master, two replicas. Lots of reads, all writes are done in bulk during the night (low read throughput). We also use Cassandra and postgresql a lot - there's no silver bullet when it comes to storage systems.
I worked in the air-force as ground-crew servicing F-16 for a year. Every now and then they would exercise gun target-practice by having one jet tow a red "sail" (I think it was called a "taxan"). The towing-line was several hundred feets long, and the towing jet would fly in a large circle. The practice always intrigued me, and seemed very low-tech compared to some of the other stuff in the domain.
Don't know if that was what you saw but - they did not fire missiles at the target how ever, and certainly not over populated area. They always flew out over the North-sea.
I'm from Norway and I had the same experience when visiting Berlin last year - having to take out euro-bills from the ATM.
Here in Norway I never carry any actual money - I only ever take out money to pay my foreign hair-dresser which cuts my hair for a low rate. I suspect he does not have a credit-card machine so he can avoid some taxes. I even pay for coffey and other cheap stuff with my card. They say we will go completely cash-less by 2020 - can't wait.
Typically you create your class manually and map to-and-from json-strings. In a web-context you'd usually let the container handle the serialization/de-serialization (jax-rs), in other contexts I tend to use Google's GSON-library.
Give him a break, this is how projects - and especially personal projects - develop. You find a cool idea you want to explore on, the end product might be something totally different then what you started with.
Yes, but you don't typically replace the same domain with two totally different services. You create 2 new domains. I would never pay someone for a service when they've repeatedly shown that they're willing to throw out the system people have started depending on and replace it with something radically different. Not only can I not trust the stuff to stay around, I can't trust the developer to have enough of an attention span to care about the old stuff enough to even just leave it alone to keep working in maintenance mode.
