Open Source software pitfalls; why you should test in a very restricted VM:

TL;DR: a free open source software package with buried install routine that tries to AWS Cloud Formation a server cluster… would incur ~$22K/month.

In recent weeks, I’ve been reviewing dozens of open source applications. Some of the stuff I’ve found deeper in the details has been truly amazing.

The best one so far has been an open source map rendering application. The concept is pretty straightforward… it provides a client app and a server app. On the client, a user creates a set of points (coordinates), and the server renders a map for the client.

The client/server model should enable multiple users to utilize low powered mobile devices to gather data and let one server do the heavier processing.

Sounds good; I added it to my “evaluations” list.

My primary goal for these evaluation activities is not to install/run these apps, but rather to collect some apps that I can use as working examples for my own software development “continuing education” projects. I learn more by taking things apart.

After some preliminary reviews, fiddling around with a live online demo site, and using some packaged bitnami/docker type bundles… I git cloned the source code and started exploring.

As I followed a few threads of packages dependencies, I stumbled into a package of utilities and scripts… best described as “deploy an n-tiered high capacity solution.”

Notice that I found this in package dependencies and scripts.

Many app developers provide this kind of info in documentation. Not these folks. It’s deep in the installation/deployment code published in their GitHub repo.

So what happens when someone downloads and deploys the content of their GitHub repo. For most people, I’d expect the process to fail rather quickly.

However, if attempted on a host that is used to admin/deploy stuff on AWS… better hope someone configured AWS roles and account limits/restrictions.

If you’ve ever setup “AWS CLI” to make it easier to administer AWS services… and then ran the command line “aws configure” to set up your keys… well… you should be getting a feeling that a train wreck is leaving the station.

That client/server deployment process buried in the GitHub repo… it contains cloud formation scripts to deploy a “high capacity rendering cluster”.

After I reviewed the target configuration, and looked up the current AWS pricing, I estimated the services turned on would have a monthly cost of about $22K.

That isn’t the only open source repo I’ve found that hides a narly surprise, but it’s currently the top of my list.

A couple others, that take somewhat smaller bite, but nevertheless demonstrate why caution is necessary.

A package that is described as a howto guide walks the user through steps to set up a free Azure Functions demonstration… at the completion, the user account is provisioned with a persistent (always on) service that prices out as $1,803 per month. Unfortunately, the Microsoft Azure admin interface does nothing to warn the user or even ask permission. I only found that little gift by thoroughly reviewing all of the created services afterwards… and promptly deleting them. Had something external interrupted me, and I’d delayed that post config review, the unexpected bill would have been a real kick in the backside.

In another open source git repo, I found what appeared to be a promising little utility for scraping news sites and parsing the results into simple/clean text saved locally for offline reading. Turns out that streamlined reading material comes at a cost. The app’s install routine included a “pip install” of numpy, matplotlib, scipy, and tensorflow. Congratulations to anyone who installed this one… you just donated your machine to the authors machine learning network.

If you’re thinking , “Gee, Wally how many people actually make these kinda mistakes? Don’t detect them? And, don’t clean them up?”

Google search “wasted cloud spend”.

An article published Jan 3rd, 2019 puts the current cloud waste at $14.1 Billion.

Implementing Delegated Administration with the ForgeRock 5.5 Platform – ForgeRock Forum and Blog

Implementing Delegated Administration with the ForgeRock 5.5 Platform – ForgeRock Forum and Blog
— Read on

Apple, IBM add machine learning to partnership with Watson-Core ML coupling | TechCrunch

Nice step in closing gaps between ML training, usage, feedback, and retraining. Hopefully it will also evolve into a service that independent app developers can use.

Apple, IBM add machine learning to partnership with Watson-Core ML coupling | TechCrunch
— Read on

COTS and corporate consumerism.

It is truly amazing the number of companies who go on consumeristic shopping sprees buying so called “COTS packages” in hopes of instant gratification.

The marketing wordsmiths of the software industry have achieved great results in convincing folk the definition of COTS is something like:

Short for commercial off-the-shelf, an adjective that describes software or hardware products that are ready-made and available for sale to the general public. For example, Microsoft Office is a COTS product that is a packaged software solution for businesses. COTS products are designed to be implemented easily into existing systems without the need for customization.

Sounds great doesn’t it.  Here is a portion of an alternate definition which rarely makes it into the marketing brochures:

“typically requires configuration that is tailored for specific uses”

That snippet is from US Federal Acquisition Regulations for “Commercial off-the-shelf” purchases.

In other words, most of the COTS packages should at least come with a “some assembly required” label on the box.  Granted, most vendors do disclose the product will need some configuration.  But most gloss over the level of effort involved, or sell it as another feature.  And most organizations seem to assign procurement decisions to those least able to accurately estimate implementation requirements.

The most offensive of these scenarios involves developer tools and prepackaged application components for software development shops. SDKs and APIs are not even close to being a true COTS product, but numerous vendors will sell them to unsuspecting customers as “ready to use” applications.

If the organization has a team of competent software developers… then really, what is the point of purchasing a “COTS” package which requires more customization (through custom software development) than just developing the features internally?

Some vendors have sold the idea that they provide additional benefits you wouldn’t get from developing it internally.  Such as:

  • packaged documentation comes with the software.
  • vendor gets feedback from many customers and makes it better for everyone.
  • vendor specializes in supporting the product.

Those are all suspect.

  • If the product requires customization, will the vendor provide custom documentation?  If not, their pre-packaged documentation will likely be useless.  The only authoritative source of documentation for source code… is the source code.  Good coding standards, including commenting and version control statements, will provide far more value than a collection of PDFs from VendorX.
    • Can the vendor provide an IDE plug-in which integrates Class, Method, API, and Interface documentation with the rest of your language environment?
    • Can the vendor be expected to keep these up date for the development tools your team uses?
  • Increasingly,  Vendors are no longer the best or primary source of product information.  User communities increasingly evolve independently of specific vendors.  Many online user communities begin with the overall service or concept involved, and develop sub groups for specific vendor products.  As a result, it is increasingly easier to compare and contrast information for many competing products at a site which shares common interests and contexts.
  • Vendor support comes in many flavors, and not all of it equally useful (or affordable) to all customers.
    • If the customer configuration is complex, continuity of support personnel is important.  Dedicated support from a large software vendor can run $1 Million per year per named individual providing support.  Otherwise your support calls go into the general queue with no continuity.
    • Large (publicly traded) software vendors operate on a financial basis which makes it difficult for them to run large scale professional services businesses.  Most every company that tries to combine product with large scale (i.e. thousands of staff consultants) professional services eventually implodes due to the cultural and financial conflicts between the two lines of business.

Failed software implementations can drive a company into the ground.  Complex COTS packages which only serve as a component to be “integrated” into customer systems through custom programming can often be a major contributing factor to project/program failures.  The larger the failure, the less likely the organization can retain sufficient stakeholder trust to try again.

Organizations with existing capabilities for large scale internal software development should reconsider the mantra of “All COTS, all the time, everywhere.”

US corporate financial practices haven’t just indoctrinated the citizenry into consumerism.  They’ve equally indoctrinated organizations of all kind.  Before you make that next COTS purchase order, pause, and give a moments consideration to “producerism”.  The long term benefits could be startling.

By the way, this phenomenon isn’t limited to software components.  I’ve seen organizations procure “appliances” at six figure costs because they perceived it to provide an application service which would save them $1 or $2 Million in software development costs downstream.  Unfortunately, they eventually learned it would require an additional $2 to $5 Million of software development costs to modify their application portfolio to work with these appliances.  After spending (wasting) 18 months and over $1 Million, they eventually found a solution they implemented internally with very little cost (simply replaced an old/deprecated programming language API with a newer one).

Handling Interruptions in your iOS App.

iOS – Handling Interruptions

As we all know, iOS Apps run on mobile devices.  The users of mobile devices can be interrupted by any number of things.  Many of the interruptions come from other services and features of the devices themselves.  Incoming phone calls, text messages, notifications, alerts, etc.
As an App developer, it is a good idea to plan for handling interruptions and test the results.
One simple technique for testing uses the iPhone’s built in Clock App.  Setting the alarm clock about ~ 1 minute ahead, use app and observe behavior when alarm interrupts the app.
A well designed App should respect the interruption, be prepared to be backgrounded, and be prepared to be exited.  For a good user experience, the current application state should be saved (if applicable) so the user can eventually return to the app and resume where they left off.