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.
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).
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.
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.
Been using http://commons.apache.org/proper/commons-dbutils for the same purpose. Works well when I don't need the slede-hammer a full ORM-framework can be. Will look into JDBI as well next time.
The replication factor is set to 3, meaning that all data is stored on tree separate nodes - in different availability zones. So in practice the writes per sec is 3x.
I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, android, etc. I've used lots of frameworks like Spring and Hibernate. Although such frameworks often provides abstractions and encourages usage of design patterns, I've never really found my-self getting lost in their layers of abstraction, and I've can't really say I've come across any "AbstractAdapterFactoryProviderBean"-either.
I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past.
When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.
Having used HazelCast extensively, and considering making some of my code Sirius-depentant, I can tell you that it is not more advanced. Sirius is basically just a distributed key-value store w/no partitioning, whereas HazelCast has a lot of abstractions built on top of the simpler principle[1]. In fact, it might be a bit overkill in some situations, and that's one of the reasons I will consider Sirius.
I'd say that depends on what kind of service the provider is offering. Later generation cloud providers might specializing in providing such VMs - Heroku and GAE comes to mind. But on providers that offer more "bare metal" VMs one should not expect such migration. Indeed it would be almost impossible to do, since it would require a lot of information about the application you are running. Heroku and GAE solves this by limiting the capabilities of the VMs so that they have more control/information about the running applications.
Started with Visual Basic back in 98, switched to java around 2003 and haven't looked back. I can still remember I thought the "Obejct" in "Object Related Programming" was referring to the nice GUI-components in the Visual Studio editor.
When the cloud was first being introduced one of the core principles was that your instances should be considered ephemeral - and that they can terminate at any time, without any notice or further explanation. I think some people sometimes forgets that this still holds today.
Don't expect your instance to run forever. Design your architecture with this in mind. There is a reason e.g. aws provides multiple availability zones.
These guidelines does not apply to all websites but (and I translate) "private and government enterprises, communities and organizations that uses the web as it's main channel for distribution of information to the public". But I'd tend to agree that it's a bit far fetched to force on any kind of guidelines.
That's how things play out sometimes - reminds me of how contractors here are forced to build all new houses with certain dimensions on bathrooms, halls, and kitchen to accommodate handicapped people. This again have led to higher prices of housing.
One great thing about these new language features is that you don't have to use them. You can run on jdk8 and program as if it was your grandmas vm. This was true for generics and will be true for lambdas etc. As programmers become more advanced they understand the need for the more advanced features and start to adopt them - but they are not strictly required from the start.