Compute Workload Abstraction - Part 4 or The mental mettle to manage metal

This is part four in a series exploring the topic of compute workload abstraction, in the three previous posts we have set the scene for containers and covered off some of the impact on the wider IT ecosystem. In this post we look at how containers could affect your current environment and draw a close to this first series (almost…)

Do I need bare metal servers anymore?

There remains a market for bare metal in enterprises but it’s shrinking. The market remains for three primary reasons, maturity of the cloud, legacy applications and security. All things being equal there should be very few reasons that any next generation application would require a bare metal hardware platform. It is worth considering though that the bare metal market for another market segment is accelerating, namely ODM or ‘Other Device Manufacturers’ these are the firms which make the white box servers for some of the public cloud players and also provide the bare bones for functional appliances. Appliances in this context are self-contained purpose-specific combination of compute, storage and network. Recent appliances tend to be based around x64 compatible componentry as a lowest common denominator and widest development environment coverage platform.

Another management point?

If you look at containers in isolation then there could be a worry that their existence just means another management point in an already overly complicated application landscape, but because of the devops movement the automation bar of entry has never been higher for a new platform, there are simply not the cycles, from a cost or attention perspective, to be managing individual containers, they need to be considered like processes not servers of old, you won’t be giving them server names of remote galaxies or characters from the Simpsons. There are already schedulers, such as Google Kubernetes and projects like Apache Mesos which provide pockets of abstraction automation – check them out for more info.

Portable and Potable

One area that we have not covered in any depth is the portability of containers, enabled by their ability to create self-contained execution environments. It strikes me that this will the single biggest operational benefit of containers, but will be cast into the statistics shadows by the speed of spawning, size of images and sheer volume of containers. The ability to run container ecosystems such as Docker across different underlying platforms provides the ability to create and consume services without being poisoned by the surrounding environment, leading to a more stable, predictable application, which in the end is what we all want.

In conclusion

In my opinion container technology and its supporting ecosystem epitomise the saying popularised by Newton “If I have seen further, it is by standing on the shoulders of Giants” in that it is only through the maturity of the underlying platform, reliability of package distribution and the deepening of the virtual canals through which data travels that we have the conditions for creation, and it follows that without one of these, it would be difficult to achieve the critical mass that it requires for industry wide adoption.

Previously

Next Time…

In a special extension to the series we will look at performance and how your regular trip to a restaurant is not too dissimilar to running a container! Don’t forget to comment, get involved and get in touch using the boxes below and reach out direct @glennaugustus