5 ms·
It's not an either this or that, but a matter of convenience. If it's easy to build that library into your app in terms of testing, go ahead. But it might be
by marmaduke 6y ago
It's not an either this or that, but a matter of convenience. If it's easy to build that library into your app in terms of testing, go ahead. But it might be easier to validate the library and app separately, and then run them together.
For instance, I have an app that needs to securely access sensitive data. I can build that access into my main app, as a wild violation of "separation of concerns" or build a sidecar which handles the access and exposes the data as a read-only file system to the app container. I test both locally and separately then rely on the container platform to ensure that the app only accesses the data through a read-only volume mount.
Which is easier? If you are green field, monolithic or meet all devs each day, maybe the library is easier. But what if the two parts are built by different teams in different countries? and Ops is a third team in a third country?
- _-___________-_ 6y agoIf the library has a well-defined API and is built and maintained by a team following good engineering practices, and your app is built using a language/platform that makes accidentally working around their API impossible, the difference between that and a sidecar container being communicated with via a readonly FS or local network seems largely academic.
- p_l 6y agoAnd assuming you don't have annoying issues like language incompatibility, or have already accepted CORBA/DCOM into your heart (then nothing stops you from running the separated code in a sidecar :P)
- icebraining 6y agoI don't think there are many languages where you can give certain permissions (e.g. r/w access to a directory, or TCP connection to a certain host) just to a single library in the application, in a way that can be enforced at runtime.
- jayd16 6y agoWhat does this secure? The same party controls both the main app and the sidecar so the assumption is an attacker can break into the main app only?
- marmaduke 6y agoI think this misses the point. The author of the operator delivers software as the operator + sidecar and a different can deliver a different software as the main app being operated and sidecar'd. Imagine you only want to write a REST API without worrying about DB, for example. An operator manages you DB cluster and REST API server scaling
- icebraining 6y ago> the assumption is an attacker can break into the main app only? Yeah, the idea is that the main app is more vulnerable (both due to being more exposed, and also because it's often more complex), hence it should have very limited permissions into the internal infra. This approach is also used in other situations, like browsers, where the process that processes website content is very locked down, and can only perform actions in the system (network, filesystem, etc) through a limited channel to an outside process.