A lot of organizations are adopting and implementing Platform Engineering. In the book “Team Topologies” the authors write that the platform team provides internal services (reusable components) that the stream-aligned team can use.
So, a platform team builds reusable components to allow organizations to scale faster. Could container base images be considered reusable components? I think yes, it depends on the maturity grade of the Platform.
But, let’s take a step back and try to define a base image: base image (technically parent) refers to the contents of the FROM directive and it’s the image that your image is based on. Commonly, the base images are customized, adding configurations, packages, and tools needed by the applications and then needing some maintenance and security updates.
Large organizations usually centralize the responsibility of these tasks, but is it the best approach? Let’s see together the pros&cons of this approach and a potential alternative.
The schema above shows two different patterns for managing container base images: the blocks are image layers, and their coloring means who is responsible for it.
On the left side is represented the pattern according to which updates and security issues should be made by the Platform Team, then all the development teams use this image and add to it the application code. This pattern has the pro that you can fix in one place but, at the same time, the Platform Team could become a bottleneck when it has to deal with multiple demands from multiple teams.
On the right side, there aren’t common libraries then every team could create their image and does their things, according to their needs. This reduces the dependencies between teams but can potentially generate a lack of security and also a potential for chaos.
Top comments (0)