Great Functionality

The company from Palo Alto offers a full feature set: Although Photon OS does not use Docker itself, it does support its container format, and it can also handle containers that use the Rocket format. Of course, perfect integration with existing VMware environments is guaranteed. If you already use a VMware virtualization platform, you can seamlessly connect Photon OS instances to this management software.

Surprisingly, VMware is developing the product openly, right from the outset. In this way, the company is seeking – according to its own statements [5] – to establish a community around the product and hopes that patches will be contributed from the outside that might fix bugs or extend the functionality. The open source code allows for some rare insights: Photon OS implements containers using its own tool, container, which is based on cgroups and namespaces.

It is at least questionable whether the product will meet with the success that VMware hopes for within the community. Even if VMware is looking to establish a reputation for universally deployable functionality, the first point on the feature list is the previously mentioned integration with other VMware products. Integration with third-party environments looks less promising: For example, OpenStack integration has not been mentioned thus far, with no code for this purpose.

VMware still has an ace up its sleeve, though: Lightwave is being bundled with Photon OS and will, in future, take care of container security management. VMware is looking to provide an option for handling various aspects, such as user management or X509 certificates, centrally from the cloud controller. Ideally, the cloud controller should be a VMware product; however, compatibility with protocols such as LDAP or Kerberos is intended.

Compared with the other candidates, Photon OS leaves one in two minds. On the one hand, VMware's intent is clearly identifiable – opening up an option for creating a business driver well away from its own classical product portfolio. That the company is relying on open source software to do so is worthy of praise, at least if the motivation behind it is more than just bagging free patches. Tight integration with existing VMware products is undeniably visible. Whether the niche market of VMware users who are prepared to contribute to the codebase is big enough remains to be seen.

Conclusions

The market for new container solutions remains pretty confusing. However, the era of adopting a universal approach looks to be coming to an end: Docker has exhausted this market already, and in a cloud context, operating individual containers does not make sense anyway. The focus is now on container swarms.

If you need such a universal approach, you will probably look to one of the many available alternatives: Google's Kubernetes is based on Docker, and CoreOS (still) has its own Docker interface. If you do not rely on specific Docker functionality, Rocket provides a leaner container format within CoreOS, and development is not exclusively driven by the interests of a single enterprise.

When it comes to integration and cloud computing solutions, LXD in combination with OpenStack seems to be the most promising approach right now. You will not find alternatives that work well either in the cloud camp or in the container camp: CloudStack, for example, which has survived as perhaps the only genuine alternative to OpenStack, does not currently have support for Docker or for any of the other container technologies I looked at here.

VMware makes you think that the company is looking to establish its position in a new market with Photon OS. However, Photon OS at least currently, is so tightly meshed with the typical VMware products that independent operations with Photon OS do not seem to make much sense. VMware's solution – viewed in this light – would be competing with offerings such as CoreOS or Kubernetes.

At the end of the day, the clear-cut options for production operations with containers depend heavily on your use case, but the number of options for each use case is very limited – and mostly to just one.