Packaging Code for Reuse - A Brief History
How programmers through the ages have shared their code…
1960s: Add these cards to your program. Jump to the address of the subprogram you want to reuse.
1970s: Copy the function from this tape. Push the parameters and return address onto the stack then jump to the address of the procedure you want to call. Pop the parameters and return address from the stack after the call returns.
1980s: Add the headers to your compiler flags and library to your linker flags. If the ABI of the compiler used to compile the function is the same as that of your compiler, call the function. If not, you may be able to use some kind of pragma to specify the ABI, or you’ll have to write some assembly code to thunk between the two ABIs.
1990s: Add the DLL to your system. Add the include directory to your include path and the library to your link options. If the ABI of the compiler used to compile the function is the same as that of your compiler, call the function. If not, you may be able to use some kind of pragma to specify the ABI, or you’ll have to write some assembly code to thunk between the two ABIs. If you installed the dynamic library in a system folder, your program will stop working when you upgrade your system. If you installed it in an application-specific folder you’ll have to specify its location in an environment variable, and even then your program will stop working when you upgrade your system because the library itself depends on libraries that are in the system folder.
2000s: Install a VM and large class library in bytecode files. Hopefully your program is written for the same VM. If not, wait until somebody to port the library to your VM. If you do use the same VM, copy the bytecode of the classes that you want to reuse
2010s: Script AWS to deploy the code as a cluster of replicated HTTP microservices on virtual machines, behind redundant load balancers and an API gateway. Configure the microservices to send log output into an ElasticSearch cluster and performance monitoring into a Graphite cluster. Script AWS to deploy graphical front ends so you can see the logs and performance metrics. Generate HTTPS certificates to secure HTTP traffic to the microservices. Generate API keys and distribute them to the program that will use the microservice. Serialise the parameters into, and parse results from, JSON data. If the data is not tree structured, you will have to hand-code the serialisation because JSON doesn’t support links. Make sure your program follows hyperlinks (which cannot actually be encoded in JSON, remember?) in the resources returned from the microservice instead of hard-coding the URL schemes so that you can easily upgrade the microservices when you upgrade to close a security hole. Keep an eye on the latest security bulletins to know about security holes in the microservices and the rest of the system software deployed on your virtual infrastructure. Upgrade as quickly as you can whenever a security hole is announced. Which is probably every day.