On Docker absorbing Unikernel

Docker just bought Unikernel. This is an interesting move from this company. It allows Docker to make a counter move to its usual strategy which revolved around expanding its deployment practice, management tools and platform management offer.

The main attraction of unikernels, for Docker and its users, are performance and security. While some may argue that performance might be a red herring. You have to remember that, with unikernel, Docker is able to make a significant foray in the world of :

• networking where real time performance in NVF is crucial (Rump is really nice for that). Storage might also be another use case.
• IoT where speed and minimalist footprint provide a significant advantages

On the Security side , obviously, this will enable docker to deflect a lot of the concerns that have been plaguing them in the debate of Virtual machine vs containers.. This will allow potential customers that are kind of interested in Docker but have been put off for either security, isolation, performance to try out this alternative.
In order to make unikernels attractive to the current its current developer base. Docker will have to put tremendous efforts in creating user friendly DevOps mechanism that made Docker popular. This is a significant challenge as unikernels often requires specific tools and application build to run. Making this offer transparent and easy to use will make or break this acquisition. Capstan from OsV is a step is a right direction to achieve that by example.

However, Docker might have a darker motivation :

• if docker successfully embrace the unikernel tech, will accelerate the vendor lock in due to its inherent nature. 
• if docker fails it would have simply extinguish a competitor and part of a competing tech with it.

Either way I feel that docker has a greater challenge ahead with the rise of AWS Lambda style stacks.

On avoiding vendor lock-in by leveraging Openstack

One of the main drivers for user to adopt Openstack is to avoid vendor lock-in (see stats here ).

Architecture is rapidly becoming a commodity

Arguably, if you develop you own cloud solution you are locking yourself into yourself. Openstack in its current state require so much effort, customization, and maintenance that you end up building your own cage. Managing your maintenance and devs cost becomes critical in order to have a good ROI. Unless you plan to resell these services or expose them directly to your customers you won't benefit from the scaling strategy.

Often you might be better off  with a vendor lock-in as you "should" more easily control your costs and ROI. Or better, contract out your Openstack implementation from a third party and outsource the maintenance and development cost while retaining a certain degree of flexibility.

Different size , different strategy different risks

SMB customers can be very aggressive about getting into the cloud, and they do not have a legacy to deal with, whereas the enterprises tend to be very risk-averse. They have to protect what they have, and they cannot be as aggressive.

As a result we are seeing a number of mature enterprises looking toward a multicloud strategy. Whether that is through multiple platforms or whether it's deploying on an open cloud platform, the outcome that they are trying to achieve is the same. Enterprises are increasingly transitioning from general-purpose tools to point solutions as their IT environments become bigger and more complex.