Once upon a time, in a land far far away software was sold that ran on a single computer. That computer was a lonely device. It didn’t have many other computers to talk to, so all of the software was concerned with internal processes and internal calculations and making sure it didn’t crash. Everything was under control and the software QA team was small and happy:

Along came networks and suddenly pieces of software could talk to each other over great distances. Suddenly it was not good enough for software to run on just one computer, it had to talk to many computers at the right time and with the right computer vocabulary. It was a time where the QA team had to get bigger because there were more things to test, but the team was medium sized and happy. Very very big computers lived at the far end of the network and were accessed by terminals that the users sat in front of. These were the good old days.

Time passed and eventually some bad people discovered that there were bugs in the network software and they could get into any computer they liked by exploiting these bugs and stealing data and causing havoc. The QA team was not happy any more and they grew a security division and also some IT sys-admins who put up firewalls and other security devices.

More time passed and the internet was born. Now data was moving freely between computers and the firewalls were very good and people used their personal computers for running lots of powerful software that was so complicated that it took a long time to learn.

Today we see that the “cloud” is arriving. It looks a little bit like a super duper version of the Mainframe and terminals from the good old days but there is an important difference. The mainframe was all about dumb terminals talking to a central computer that was far away. The cloud is all about smart applications talking to other smart applications with smart APIs and users joining them together to do really neat things, even though the computers are still far away.

At AmberFin we’ve known about the importance of the API since the first day we launched the company. Our APIs are stable and well used. In fact about half our customers don’t use the GUI – they only use the APIs to control their transcoding, QC and ingest. This approach makes it very easy to turn our standard product into something that looks like a customized solution by using a local programmer to call our web service APIs from within a browser, within an application, from a MAM or from a command line.