VMWare In The Age Of Containers
VMWare’s attempt to survive in a world of containers and ever expanding public clouds has led them towards an acquisition and innovation approach, with the emphasis on acquisition. One aspect of this strategy is leveraging their enormous installed private “cloud” base, and embracing containers, emphasizing hybrid cloud solutions, and courting devops audiences as an unopinionated, comprehensive, microservices based platform for heterogeneous environments. The comprehensive nature of the platform, while reducing integration woes, creates a kind of lock-in that trades short term convenience for long term stagnation and mediocrity.
VRA As The Platform To Rule Them All
There is no “best” technology stack for any problem domain, especially with the explosion of tooling options that have emerged in recent years. Even if there were, it would quickly diverge as superior innovations appeared. There is no “best” stack, because tech stacks exist to solve specific problems, which in the real world have multiple potential solutions, and exist in various larger contexts that they must integrate with. Indeed, the idea of “best” can vary from project to project, and even team to team. Also, new opportunities arise constantly, each with their own unique characteristics.
In the case of VRA, the recent acquisition of SaltStack is illustrative of the consequences of creating an opinionated solution/stack. SaltStack is a provisioning tool that promises to “Provision, configure and control any cloud or on-premises infrastructure at scale”. As such, it is a member of a rather crowded field, including Ansible (Redhat), Puppet, and Chef (Progress) among many others. Beyond these general purpose tools, there are numerous domain specific (or even vendor specific tools) that will always be more capable and up to date compared to a general purpose tool. Besides being an odd choice for a company moving towards a cloud native (AKA Kubernetes) philosophy, it forces users to both abandon any existing non-SaltStack investments in configuration automation, as well as locking them in for the future. Of course VMWare promises to “support” other configuration tools as well, while standardizing everything internally on SaltStack. In addition, SaltStack incorporates it’s own closed loop automation system (Beacons) to enable capabilities like auto-healing. All this assumes the user (or use case) can tolerate installing agents on the managed servers and can tolerate SaltStacks concept of closed loop automation.
These attempts to create a master platform for automation are doomed to failure over time. Once a company essentially delegates it’s automation tooling to VMWare (or any other vendor), they become limited by that vendor. The vendor has to satisfy the needs of many clients, without breaking compatibility which usually means lagging well behind the state of the art. It also means the platform is weighed down with many features that take a cognitive toll on users, but have no benefit for their exact needs. The insidious outcome of this kind of vendor dependency is that it becomes hidden over time; a hidden cost of doing business because breaking free of the lockin is so expensive. The larger the scope of the platform, the worse the effects become.
Best Of Breed Beats The Monolith
Open source automation platforms that take an agnostic approach to tooling, while often requiring more effort initially, facilitate best of breed tooling for the users exact problem domain. Open source systems are community driven and visible, allowing you to see exactly how features are designed, and (if need be) make changes and enhancements yourself rather than waiting on a vendor roadmap. A technology agnostic orchestrator focuses on it’s core mission:
- Expressiveness and completeness of its model/template language
- Adaptability / plugability to various northbound and southbound systems
- Platform availability, scalability and security
- Efficient parallel local and remote task execution
- Orchestration workload visibility and manageability
Such a platform needn’t specify whether a user should use bash or Ansible (or Salt) to configure applications or compute hosts. It must, however, facilitate a users ability to use any or all of them. Such a platform shouldn’t “know” what a cloud or container is. It should be adaptable to either, or neither (e.g. devices, bare metal, hypervisors, etc..). If using closed loop automation, it likewise should be unopinionated. A system purposefully constructed in such a way will never be locked into any technology stack and allow for the development and evolution of an organic automation stack that will only improve and adapt over time. Being open source only enhances this potential, if an open catalog of compatible integrations is created and contributed to by a community of developers.
VRA will always be biased, even if unintentionally, to VMWare products. VMWare has a “dog in the race” if you’re deciding to use their CodeStream component vs Github actions or others for CI/CD. The agnostic orchestrator, however, doesn’t force a compromise in tooling. The agnostic orchestrator can automate VCenter/VSphere and SaltStack, if that is the “ideal” stack for a certain company or project. Or it can blend VSphere, Nagios, Gitlab, and Puppet if that is more appropriate. In fact, sufficiently flexible orchestrator should be able to delegate tasks to VRA itself for VMWare workloads, and other platforms to exploit their specialties. Luring users into an opinionated Orchestration Platform as a Service ( a VMWare objective), is superficially attractive, but ultimately a dead end for customers.
Conclusion
One of the most powerful ideas in computing was the Unix philosophy of small, focused utilities that could be linked together in ways unimagined by the creators of Unix itself. This was revolutionary compared to the monolithic operating system interfaces of the day that explicitly limited what could be done. Oddly, VRA attempts to create an orchestration monolith essentially dictating how and what can be done with their system. Open source, technology agnostic orchestrators are the “microservice” alternative to the monolith. Do things in the way that is appropriate to team or company culture and needs, in a framework that takes care of the bread and butter of orchestration, and enjoy an unconstrained, open future.
Nati Shalom is the founder and CTO of Cloudify, a serial entrepreneur and thought leader in open-source, multi-cloud orchestration, network virtualization, DevOps and more. Nati has received multiple recognitions from publications such as The CIO Magazine and YCombinator and is one of the leaders of Cloud Native and DevOps Israel groups. Nati is also a frequent presenter at industry conferences.