To succeed in our modern world of API-led connectivity, we need to go back to basics… all the way back…
Security, agility and fast time-to-market are crucial for any successful Digital initiative. Your choice of integration platform can be the deciding factor, enabling developer productivity or resulting in crippling technical debt. In this environment, x86 Assembly Language is a prime candidate.
Why x86 Assembler? It comes down to 3 main benefits:
Your API achieves overnight success, and suddenly you have 1000’s of consumers using it. How do you introduce new features while not breaking backwards compatibility?
“Compatibility is a governance issue”, says Sixtree CTO Saul Caganoff. “You have to maintain control over the interface you expose to your API consumers.” One of the big failures of SOAP Web Services was developers taking a code-first approach: writing Java classes and the generating fragile XML schemas and WSDL definitions. A tiny change in the code could break the interface for all consumers. By developing your APIs in Assembler, such problems are a thing of the past. Your developers have complete control over every byte that goes on the wire. (Knowing the order of those bytes, particularly when it comes to edge cases like IEEE Floating Point numbers… well that’s a consumer problem)
High-level integration platforms can provide tantalising developer productivity benefits, but IT leaders need to carefully consider the security risks they bring. The bigger the stack, the more components there are open to security compromises. The Java browser plugin has exposed end-user desktops to hundreds of critical security exploits. These exploits can put your JVM-based integration platform at risk - even when it’s running on a server with no GUI and no web browser.
What about the embarrassing parade of recent exploits in the widely used OpenSSL library? Once again it comes down to using an inappropriately high level language - like C - to write critical code. With your developers armed with x86 Assembler and its comprehensively security-verified standard libraries you can avoid exposing your integrations to security holes in 3rd party software. It is telling that not a single CVE has been raised against the Assembler standard library since its inception.
The typical software application spends 80% of its life time in support and operations, not development. It is vital to consider maintainability. x86 Assembly Language developers tackle the problem of production maintenance in a different way than most other platforms.
“Time spent in maintenance is time wasted”, says Sixtree Señor Consultant Sohrab Hosseini. “By developing in Assembly I can minimise the time I spend doing maintenance by maximising the time I spend doing development. If my API never even makes it into production before I retire, then I don’t spend any of that maintenance budget. I’ve delivered a TCO saving of 80%”
You might also enjoy:
Developing Bulk APIs with Mule, RAML and APIKit 02 December 2014
Ansible Crash Course 09 March 2016
Microservices with Apache Camel, Spring Boot and Docker 31 March 2016