Simple Confidential Computing. Containerization: All Eggs in One Basket, What Could Go Wrong?
Last time we talked about how virtualization decouples hardware and resource management, allowing developers to focus on their apps and scale them on demand using the public cloud, but that’s just one of the layers. Modern app development is based on a trial-and-error approach: you come up with an idea, make some changes in your code, and deploy the new version (“ship it” for short).
There are a number of things that could go wrong during this process. The changes you’ve made don’t work well, and the new feature makes the user experience worse or doesn’t work the way intended; the code contains crucial errors that crash the app. In any scenario, a developer would want a tool that allows to (a) test and ship new versions of the app as fast as possible; (b) release bug fixes or reverse to a backup version just as fast without affecting the end user.
Containerisation does just that! It wraps the app in its own cozy environment inside the operating system. This environment contains everything the app might need (libraries, plug-ins, drivers, etc.), allowing you to modify and rebuild in an instant. So, for example, you could create several versions of the app with different features (usually, an old stable version and a newer experimental one) or even use different tech stacks (in a less dramatic way, different versions of the same library). And in case one of the apps doesn’t work, you could just redirect users to another container without them noticing that smth is a miss.
Bet you’ve heard a developer say: “it works on my machine,” at least once in your life. Having an app containerized also means unification — if it works in a container, it will work on any machine (given it’s capable of running such software) within this container. Furthermore, as containerization works on the operating system level, there’s no need to launch a virtual machine (virtualize it) for each new application, meaning you could do more with less hardware.
To sum up, while virtualization allows to split hardware resources into convenient chunks based on the task at hand, containers create loosely isolated environments inside the operating system allowing to run multiple apps (or various versions of the same app), even those that would not work together otherwise.
While further improves the application development process, provides developers with needed tools for experimentation, and removes the risk of breaking the app completely, making it unavailable for its users, there are certainly downsides. When several containerized apps share a single host, one “bad apple” can compromise all others. If, for example, a malicious actor finds a way to bypass security and gain access to the underlying operating system, they could easily access all other apps running in the system, including all of their data.
Fortunately, there’s a next level of security here — Trusted Execution Environment (for a thorough explanation of TEEs see our guide). TEEs create protected enclaves on the hardware level only authorized apps have permission to work with. If an app gets compromised, the hacker will be unable to access any other apps that are run inside TEE.
Super Protocol is built to make TEEs based on IntelSGX tech affordable for a wide audience of app developers. Designed with the best of both worlds: public clouds and decentralized networks, we aim to make Web3 better and safer with the help of TEEs and the confidential computing they provide.