4 ms·

I noticed how much of this focuses on containers and the problems that follow specifically from using containers. I thought the reason for using containers was

I noticed how much of this focuses on containers and the problems that follow specifically from using containers. I thought the reason for using containers was because it makes shit simple.

jacques_chester 11y ago
Notice that, at the bottom, the advice is to use a PaaS.
- jbeda 11y ago
  I think that there are disadvantages to using a PaaS. It can bring all of these components together, but it also means that you don't benefit from best of breed systems at each layer. Also, up until now most PaaSes were vertically integrated and opaque. I imagine that the PaaS of the future will look more like OpenShift where it is a curated set of components in this stack instead of an opaque stack.
  - jacques_chester 11y ago
    I worked on one of those "opaque" stacks, and as you can imagine, I disagree. Not least because everything we develop is done in the open. As a developer, all I care about is that the code I tested locally and that passed on CI runs the same way in production, without further thought or effort. As an operator, all I care about is that I don't get paged when a bad piece of dev code rampages and chokes the shared resource. PaaSes have solved this. There's just no reason left to roll your own.
ashwinaj 11y ago
My sentiments exactly.
deleted 11y ago
[deleted]
jbeda 11y ago
Many of the layers defined there are necessary for any well run production system (things like logging and monitoring). A lot of the extra components allow for dynamic placement and management of workloads. This allows for the system to be self healing and self managed in the face of hardware failure. In addition, much of this automatic management (once set up) can allow for you to run more different things. It can reduce the operations cost of microservices and let you factor your app in a way where you can scale the development team. Hopefully, over time, this stack will come pre-tested and pre-packaged. Things look super complex now because of the abundance of options. As things settle, it'll get easier to reap the benefits without taking on the cognitive burden.
technion 11y ago
I'm always thinking about a Shellshock type scenario. Instead of "use x tool to upgrade bash on every server", it becomes "upgrade bash on every server", followed by "rebuild each of my several types of containers" then "redeploy every single container".
- aiiane 11y ago
  Ideally your containers don't depend on bash, and instead are just running their app's process. So then any given scenario is generally only either upgrade bash on every server (if the problem if lower in the stack than the container) or rebuild and redeploy every container (if the problem is in a library used at the app level).

I noticed how much of this focuses on containers and the problems that follow specifically from using containers. I thought the reason for using containers was because it makes shit simple.

jacques_chester 11y ago

Notice that, at the bottom, the advice is to use a PaaS.

jbeda 11y ago
I think that there are disadvantages to using a PaaS. It can bring all of these components together, but it also means that you don't benefit from best of breed systems at each layer. Also, up until now most PaaSes were vertically integrated and opaque. I imagine that the PaaS of the future will look more like OpenShift where it is a curated set of components in this stack instead of an opaque stack.
- jacques_chester 11y ago
  I worked on one of those "opaque" stacks, and as you can imagine, I disagree. Not least because everything we develop is done in the open. As a developer, all I care about is that the code I tested locally and that passed on CI runs the same way in production, without further thought or effort. As an operator, all I care about is that I don't get paged when a bad piece of dev code rampages and chokes the shared resource. PaaSes have solved this. There's just no reason left to roll your own.

ashwinaj 11y ago

My sentiments exactly.

deleted 11y ago

[deleted]

jbeda 11y ago

Many of the layers defined there are necessary for any well run production system (things like logging and monitoring). A lot of the extra components allow for dynamic placement and management of workloads. This allows for the system to be self healing and self managed in the face of hardware failure. In addition, much of this automatic management (once set up) can allow for you to run more different things. It can reduce the operations cost of microservices and let you factor your app in a way where you can scale the development team. Hopefully, over time, this stack will come pre-tested and pre-packaged. Things look super complex now because of the abundance of options. As things settle, it'll get easier to reap the benefits without taking on the cognitive burden.

technion 11y ago

I'm always thinking about a Shellshock type scenario. Instead of "use x tool to upgrade bash on every server", it becomes "upgrade bash on every server", followed by "rebuild each of my several types of containers" then "redeploy every single container".

aiiane 11y ago
Ideally your containers don't depend on bash, and instead are just running their app's process. So then any given scenario is generally only either upgrade bash on every server (if the problem if lower in the stack than the container) or rebuild and redeploy every container (if the problem is in a library used at the app level).