So, when my iPhone battery started lasting about 6 hours, I started looking elsewhere and someone showed me the “Xiaomi Poco X3 NFC”. It’s an incredible spec for a mere £216! What the hell, let’s do this – it’s going to be painful to start with but let’s get it over with and see if it’s possible to break free of the Apple handcuffs.
That idea has always been in my mind as we have developed our own software; we don’t want to trap people into a technology that they later can’t get out of. Why? So that we have to keep delivering value – it keeps us disciplined and behaving like the sort of company I would like to buy from.
To that end we have a few of principles that we follow:
1. Avoid copying data wherever possible
2. Recommend open-source technologies wherever possible
3. Don’t depend on cloud services with obscure billing models
It’s this second and third points that I want to focus on here. A decade ago, Open Source software meant it was free to use but you had to employ an army of developers to support it for you. Things have moved on now though. Databases like PostGres are so good I don’t know why you would want to buy Oracle unless you are running huge distributed databases. Frameworks like Spring and React didn’t exist when we started over 12 years ago (or at least Spring was not much to speak of) but now you’d be mad not to use them.
We wrote our code in Java so that it could be run on Linux machines to minimise licence costs for our customers, and now we run in Docker or Pods.
Influxdata is an excellent Open Source TimeseriesDB that we recommend for storing timeseries data. Our Timeseries API lets users seamlessly combine data from OSI PI, Aspentech IP21, Cognite CDF and Influxdata, but if they ever wanted to use another product, the data is there in Influx, not a proprietary Eigen database.
Neo4j is a very mature Open Source graph database with excellent performance. We use it to store our data model (Shared Asset Model) so that our customers know if anything happened to us, all their data is still there and accessible. And they can migrate it to another system if they want to.
There are some Open Source experiments we’ve tried ourselves and abandoned, for example Xen for virtualisation; it’s too complicated and needs dedicated staff to run it so we have kept with VMWare, which is still just about on the side of value (though they are pushing it!).
So to the third point on chargeable cloud services; from about 2017 we looked seriously at the new cloud services that seemed to allow you to build apps quickly – especially AWS. This looks tempting as you can just string some building blocks together and hey-presto, you’ve got an app that connects to remote devices and streams data. But this is not a model for long-term low-cost ownership. No-one can tell you what the usage costs will be until you have built your app. And when you build it you need an expert in cloud services architecture because you need to think smart in order to minimise your usage of billable components.
For example, a friend of mine wrote an AWS app that processed data from remote devices by calling Lambda functions, which are charged each time they run. Because of the way the code was written it called them 400 times more than it could have done if it had been well architected. Her bill was a lot higher than he expected! She realised he had to re-write it before she dared to roll it out to more users. Plus the fact that the code can never be run anywhere else other than AWS. You cannot export it as an Azure app, you would have to re-write it in Azure.
I guess I am saying that avoiding lock-in takes a bit of thinking early on but it’s worth it in the long run. And we’re on the same side:)
*And before anyone who has sold their soul to Windows or Linux laughs, I’ve tried both of those. Windows does the same it’s just a worse experience. Linux is cheap but completely impractical unless you and all your family are developers.