Docker, OpenStack, AppScale, GAE, Software Quality, GNSS, lftp

Post date: Oct 1, 2016 7:01:27 AM

• Interesting article about Docker. I wonder if things are getting simpler or not. Actually I find some great PaaS platforms very simple to use and well scalable. Getting something like Google App Engine out of 'Docker' and adding required stuff for that or using OpenStack to get all similar functionalities requires a bit more work. And that might be radical understatement. Sometimes it's fun to run all stuff and manage it for 'fun'. But in real life you might be busy and not really interested to trouble shoot all kind of 'interesting' production stopping cool new problems you're encountering. - As far I know, many of the developers are really frustrated about ever widening and deepening 'stack'. You'll need to know in detail tens of different projects to get anything done. It's something you can't do reasonably at work time at all. It requires two shifts like I've said before. One working and second one, during evens and weekends studying. And even if you do that, it's still extremely hard. You can lightly cover many subjects, but that's not same as having good experience and actually being able to manage production systems without causing major devastation.
• AppScale: Datastore Changes in 3.0 - Seems that they've finally made it sane. The old design was simply extremely bad. Good for them. Nice article which well explains, why 'invisible' internals of software are still extremely critical for performance. Nothing new. There are many ways of doing same thing, all of those might work just fine in normal situations. But when failure scenarios or performance issues kick in, then the different solution models might perform radically different. - I think that Google App Engine is still very scary from vendor lock-in perspective.
• Had interesting discussion with a friend. People always complain about software quality. But just as I've said. It's always delicate balance. It's easy to make crap software. But it's also easy to make software which is 'way too well designed and engineered' and therefore way too expensive. There's also secondary problem, even if it's perfectly engineered. Might still mean that it's totally unusable for actual end users. Just like selling Bugatti's or Lamborghini's for local Pizza Chain, because it allows faster delivery. ;) - My friend were working in a company, which made just way too well designed and engineered code. Code was perfect, yet the business failed totally. Would you buy a house which is 10x more expensive than the similar looking house next door? Do you care if it's high quality house? Actually in cars this does happen at times. It's secondary question if the actual use value of 10x or 100x 'normal car price' car actually brings similar additional production value. - This also happens in data center services. If you pay more, do you really get the bang for the buck? - The key is to fine tune and get it right. Just like the efficient frontier in investing.
• Actually the previous step reminded from me one thing I made. There was batch ID which was required to be unique / year. It had reserved number space for 6 digits. I added a wrap-around code there if the batch ID is larger than 999999 it wraps back to one after increment. After thinking a while, I started to laugh. Because it's daily batch job, it would take more than 2739 years before this if statement will trigger. Well, at least nobody will be claiming that the 'critical range check' is missing. Laugh. Maybe I should create unit-tests for that check too. Eh. Well yeah sure, without that, there's no guarantee it will work because every line isn't being covered.
• Something slightly different: GNSS enhancement - I'll be revisiting this topic later.
• Even more issues with LFTP. It's perfect example of software which has been designed inherently so bad, it's almost impossible to configure so that it actually works. That's in a way great. Computer experts are required, just because some stuff is so insanely badly that no normal person can make it work in any reasonable time. Some of the software takes days to get working, even if it should be extremely trivial thing. Sometimes when encountering extremely bad software there's annoying temptation to write a better implementation. I guess I would have already written working implementation using Python if I would have started immediately and not wasted time with lftp. Yet on other hand, it feels so darn stupid to re-invent the wheel because the old wheel is just slightly broken. But sometimes that being slightly broken is the show stopper.