Additionally, network connections need to be short-lived – they are created and authenticated for the duration of every request. This differs from the prior castle and moat approach of authenticating at a single entry point and then allowing extended access to all resources on the local network. An analogy would be checking a visitor’s ticket once at the entry gate to the amusement park for the day, versus verifying their ticket before every ride. The latter approach is called Zero Trust and is becoming the norm, as a requirement of a fully distributed workforce.
Applied Materials (AMAT) Investor Presentation, April 2021
Decoupling Applications. Even before edge computing emerged, developers were breaking up large applications into smaller, independent components. The original Internet applications were monoliths – all code for the application was part of a single codebase and distribution. It executed in one runtime, usually a web server in a data center. Monoliths generally connected to a single database to read and write data for the application.
Further up the stack, Docker and Kubernetes allow DevOps personal to create a portable package of their runtime environment. All of the components needed by their application, app server, database, cache, queues, etc., can be codified and then recreated on another hosting environment. This represented a major improvement to the decoupling and reproducibility of software runtimes. It also helped plant the seeds for further decentralization. No longer were production runtime environments constrained to a physical data center that SysAdmins needed to set up and tune by hand.
Because these functions are asynchronous, the serverless runtime could be spun up slowly (referred to as code start time). Some more progressive CDN companies realized that they could adopt a serverless model to allow developers to run code on their geographically distributed network of PoPs. They created optimized runtimes that could start executing code in a few milliseconds or less. This change enabled serverless runtimes to be used for synchronous processing, responding in near real-time to every user request.
The current system of user identity would be much improved if the consumer had a method of maintaining their own encrypted store of personal data which could be shared with applications as appropriate for each use. The consumer could review their personal data to ensure it is accurate and up-to-date. With the right protocols, applications wouldn’t need to permanently store a user’s personal data. Rather, they might maintain an anonymized reference ID to that user, and then load the data from the user’s private store during an actual engagement. This is already how some payment systems operate.
The CEO of Zscaler summarized the new demand environment as “The Internet is the new corporate network, and the cloud is the new center of gravity for applications.” This underscores the outcome of applying Zero Trust practices to a SASE network. With those services layered over the Internet, it is feasible for enterprises to treat the Internet like a private network. This new approach replaces years of capital spend on fixed network perimeters and physical devices to protect them.
The final solution for fully decentralized data stores is to support full-featured transactional databases at each edge node. These would be located in every PoP (or at least geographically close to it) and available to the application runtime. Data would be persisted across user sessions and available to all users of the application. That application data could be shared across PoPs, with an expectation that state would be eventually consistent between nodes.
A requirement for strong consistency increases the complexity of the system by an order of magnitude. Clustered data storage systems like Cassandra have wrestled with various algorithms to ensure that data is synchronized to all nodes. There are different tactics to address consistency. Other approaches involve a form of data replication. Some providers are researching new data storage methods, like CRDTs, which sidestep challenges around ordering of data updates by supporting only data structures that support consistency in all cases.
In response to concerns around user privacy, one of the more recent trends is decentralization of identity. In this context, the ownership and distribution of user data is moving from multiple copies managed in centralized enterprise stores to a single copy managed by each user. Rather than establishing a duplicate copy of login credentials, preferences and personally identifiable information (PII) with each digital business, the user would manage a private, encrypted copy of their own data and share that with each digital channel as needed. Identity would be established through a single, consistent authentication method. The user could share data needed by each enterprise on a temporary basis. Enterprises would be prohibited from storing identifiable user data permanently.
One emerging standard that addresses these goals is Decentralized Identifiers (DIDs). These enable verifiable identity of any subject (person, organization, etc.) in a way that is decoupled from centralized registries or identity providers. DIDs can be established for an individual, allowing them to engage with any Internet service with a single identity over which they have full control. The individual can decide the level of personal information to share with each application.
DIDs begin life with no evidence of proof, representing an empty identity. They can then be tied to an owner who can prove possession of the DID. DIDs can build up legitimacy through attestations from trust providers like governments, educational institutions, commercial entities and community organizations. Any of these endorsements could be independently verified. By accumulating attestations from multiple trust systems over time, an identity can build up enough proof of its legitimacy to enable it to surpass whatever risk level is established by an app or service.
Decentralized Identity Whitepaper, Microsoft Web Site
As an example, the identity of Jane Doe might be established at birth by her government. She would be assigned a cryptographically secured wallet, into which all identity information would be stored. As she aged, additional attestations from educational institutions (test scores, degrees, other credentials), financial organizations (credit scores, loan repayment, accounts) or civic organizations (membership) might all be collected. Jane would also be able to keep personal information (name, address, phone, preferences ) up to date. Finally, she could set up different profiles that would be shared with online services based on context. Twitter might get a pseudonym with limited information, whereas her bank would have access to her full identity.
Some of the emerging concepts in decentralized identity management are very interesting and likely have near term broad application. As discussed earlier, Decentralized Identifiers (DIDs) enable verifiable identity of any subject (person, organization, etc.) that is decoupled from centralized registries or identify providers. Not wanting to miss out on this trend, Microsoft is building an open DID implementation that runs atop existing public blockchains as a public Layer 2 network. This will be integrated into their Azure Active Directory product for businesses to verify and share DIDs.
Web 3.0 Technology Stack, Web3 Foundation Web Site
One of the future directions for optimizing the Ethereum network involves updating the Ethereum Virtual Machine (EVM). One of the proposals that appears to be gaining steam is to migrate the runtime for Ethereum transactions to be based on WebAssembly (WASM). This flavor of virtual machine is being referred to as eWASM, basically Ethereum’s transaction framework based on WebAssembly. eWASM provides several benefits over EVM, including much faster performance and the ability to utilize multiple programming languages for smart contracts.
The reason I find this interesting is that several serverless edge networks utilize WebAssembly as the runtime target. These products include Cloudflare Workers and Fastly’s Compute@Edge. In the case of Fastly, they further optimized the WASM compiler and runtime for extremely high performance, released as the open source project Lucet. Lucet claims to the best performing WASM runtime available. I mention these examples because if Ethereum moves its virtual machine to be WASM based, then software providers like Cloudflare and Fastly may be able to extend their existing WASM tooling to offer services to the smart contract ecosystem.
If the hyperscalers all provide these edge compute and data services for industrial use cases, there will still be a need to serve software applications that work across these installations in a vendor-agnostic way. For example, if one factory implements AWS’ 5G edge solution and another factory uses the same from Azure, a data service that needs to communicate with machines in both installations would be better served by a cloud-neutral, multi-tenant, multi-location edge compute and data distribution solution.
This is why I think there will be an equally large opportunity to service “edge compute” workloads for the multi-tenant providers like Cloudflare and Fastly. The hyperscalers, working with telcos and wireless network providers, will likely represent the primary entry point for data and compute from industrial IoT use cases. However, any compute or data service that needs to transcend multiple locations and cross hyperscalers will be best served by edge applications and data distribution provided by the independents.