Jean-Paul Smets
Picture this scenario as a young enterprise: You are a customer of Azure, AWS, or the Google Cloud Platform, assuming they are the frontrunners. While traveling in Russia or a European Union country on a mission to expand your business, you discover that you’re required to have data locally stored. Even worse, in the EU, you face the GDPR and have national regulatory authorities warning you how using U.S.-based clouds in the EU violates the GDPR.
This is a huge problem. No matter where you go outside the U.S., you’ll have to comply with different regulations that could ultimately prevent you from deploying your applications successfully. By using the APIs of the big players, there’s either the possibility of no connectivity or even legal risk.
How can enterprises get around this issue? This is where fully open APIs based on open source software are a great help and the technology of the future.
“Fully open” APIs contain open source software with open source operation procedures so that the technology can be reproduced and audited in any region, which resolves the geopolitical conflict mentioned above.
Fully open APIs give the end-user control on how to debug the software (which powers the API) while also potentially keeping costs down due to their scalability and a complete lack of maintenance costs compared to a closed-loop system. These closed systems are limited by their dependency on a particular platform, driving costs and other limitations on developers. Fully open APIs don’t just harness open-source software, but rather are combined with a complete description of how the infrastructure is made and how it operated – it’s an entirely open process.
In Europe, security is becoming increasingly critical. New security qualifications, such as the French-German ESCloud Label for secure cloud computing, are examples of cooperation aimed at raising the level of cybersecurity in Europe. Any technology that extends the extraterritorial application of U.S. law could soon be banned from both government markets and processing personal data.
In many international markets, local laws regarding personal data require that the services or technologies used are free of technical components that could lead to foreign surveillance by the U.S. This creates an apparent conflict that is deeply connected to legislation, and U.S.-based companies that provide APIs are in the middle of it.
Adopting fully open APIs
To implement a fully open API, you essentially require an open process that lets third parties implement APIs independently of their original creator. For the process to be open, all the steps need to be described in such a way that a third party can reproduce them and verify that the outcome satisfies customer expectations.
Ideally, the software and hardware that implement the API should also be open source. Use of software without being able to audit its source code poses a risk of backdoor presence, which is incompatible with certain legislations for data protection. Use of hardware without being able to audit its design poses a risk of logistics attacks. Both risks are well understood by hyperscalers for their own infrastructures, which are now mainly based on open source hardware and software.
Enterprises should adopt the same attitude as hyperscalers when selecting an API. They should ask their API vendor: “Can you provide us with the detailed process, software, and hardware to implement this API by ourselves on a network without Internet access?”
If the vendor says “Yes,” it’s safe to assume this is a “fully open” API and you can use it without risk. Just make sure the API subscription agreement includes reversibility provisions with prices so that you can later access the process, software, and hardware to implement the API yourself.
If the vendor refuses, though, it will mostly be illegal to use the API in many regions globally, unless they already have independent, local partners to implement it in every region.
In Europe, ten cloud providers are offering governments to license their APIs – software, hardware, and processes. OVHCloud, which previously acquired VMWare vCloud, announced that it would make its cloud platform and APIs open source.
Rapid.Space has produced a step-by-step tutorial on installing open source networking APIs for the Accton Operating System on the Edgecore AS5812 switch. Many companies related to the open source community are ready to provide or develop fully open APIs at a very reasonable cost.
If your API vendor is adamant on refusing to let you maintain the API yourself, try explaining that you are not requesting to make its technology open source but only to license it. If they still refuse, then do as hyperscalers do – develop or sponsor the development of an open source software for a fully open API. This could even get you a tax break.
Why fully open APIs are the answer
We have already seen the implementation of document storage APIs used by the /e/ Foundation as an alternative to Google Drive. They provide the service, the source code, and the corresponding steps for installation so that anybody can reinstall it anywhere in the world despite any geo-restrictions in place.
Taking it a step further, enterprises that want to create a content delivery network (CDN) or implement their own instant messaging can look beyond Cloudflare or Whatsapp, which are restricted in various countries. Delta.Chat enables end-to-end encrypted instant messaging everywhere, even in North Korea, based on the standard Incoming Mail (IMAP) and Outgoing Mail (SMTP) server APIs.
Both APIs, widely available and already used by Gmail, can be replicated with open source software called Dovecot and Postfix. Nexedi’s SlapOS operation management software includes a cloud-native, open-source CDN that can be self-deployed everywhere, including in China. Again, these two solutions quell the problems created by data access being blocked in a particular country.
How secure is open source software?
Those considering switching cloud providers know that security is a priority concern – customers will make buying choices based on the reputation for confidentiality, integrity, and resilience, and the security services offered by a provider, more so than in traditional environments.
The development of fully open APIs marks a clear point of transformation regarding business behavior with data. The common wisdom used to be that organizations need to do everything in their power to hold data on their premises. This has evolved into enforcing trust through contracts and policy compliance with facility management and cloud. However, to take advantage of the sharing of tools and data through a “plug-and-play” model, it’s crucial to use fully open APIs.
In the case of clouds powered by proprietary software, the customer has no hope of discovering backdoors, because they have no access to the source code. They just have to trust the supplier without any way to verify what they are doing.
Open source projects at the core of fully open APIs are less likely to include bugs and security vulnerabilities than closed source clouds, because closed source clouds tend to have much longer release cycles for some of their software, so vulnerabilities will take longer to resolve. Many open source projects have hundreds or thousands of contributors who can review any problems almost immediately.
Beyond fully open APIs, open processes
Fully open APIs give any developer the same level of control and freedom in the cloud as open source brought to the software industry, with no adverse effects. They present an opportunity for greater innovation to customers, partners, and vendors in ways that we may not have already considered for APIs.
Creating a fully open API that the external end-user can integrate into their application and customize removes any barriers. With data regulations imposed by governments worldwide continuing to tighten, cloud computing isn’t far from hitting a wall, and embracing a completely open process for cloud-based on open source software could well prove to be the answer.
Comment