ElasticBox –
PaaS providing unified/automated IT administration of cloud resources and applications in public clouds. Purchased by centurylink – the ElasticBox seems to become their application catalog.
Single management dashboard for all clouds and applications
Applications catalog based deployments – deploy managed applications
Provides basic IT sysadmin type services: monitoring, update, patching, configuration, access management, licensing management.
$0.13/hr/instance for basic service, focus on professional consulting for advanced deployments
NDS compare
catalog concept is similar, but difficult to determine what’s published. Appears so similar to juju that it may be juju underneath. Unclear how to develop/deploy custom applications/catalogs.
Private cloud is not mentioned, probably falls under their custom consulting.
Brownfield integration not offered, assumed to fall under their custom consulting. Could not integrated with existing resources in NDS not in public cloud.
Assume data-services are traditional in-cloud provided services.
Heroku –
In-cloud PaaS for deploying, and managing applications in-cloud. Platform manages
deployment, update, scaling, and management/monitoring/configuration services with environment-specific cli tooling and github integration.
Environments for node, ruby, go, java, scala, python, clojure.
Github-oriented – “git push heroku” sends code into CI/CD for deployment/operation.
NDS compare:
NDS is a user-centric service platform -
Deis –
Container oriented system for building PaaS style systems based on containers and kubernetes.
Kubernetes based, open source, with additional services
Automated build/deploy via code commit
Helm package/catalog system
Steward – service broker/gateway based on CloudFoundry’s – integrates services in/out of cluster
Service/training offerings: learn kubernetes, migrate your apps, test/optimize/pre-flight, deploy, etc.
NDS compare:
Helm vs NDSL catalog – helm is more comprehensive but more technical and less end-user oriented
Helm graduated Kubernetes incubator – now officially upstream.
RedHat OpenShift –
Container-oriented PaaS layer over kubernetes with workflows/support for developing, building, deploying, and managing containers.
Kubernetes base (major contributor to upstream kubernetes) with additional systems service and workflow integrations
Helm application deployment – Configure and deploy apps and services from official/public/private on-line catalogs: https://kubeapps.com/
Auth/Identity system out of the box – multi-tenant RBAC
Key integrated add-ons - Integrated self-hosted storage, IT-oriented management dash
Open source DIY, Redhat packaged DIY, and hosted/managed openshift as a service.
most comprehensive end-to-end full-stack plus services offering of kubernetes
NDS compare:
WB vs. Helm – Helm is Kubernetes standard, more technical. Helm integrated with openshift RBAC, WB has built-in primitive user account system.
Openshift is more comprehensive and conducive to deployment by IT admins.
NDSL for targeted communities could run on Openshift
Platform9 –
SaaS managed openstack and kubernetes for private on on-premise private clouds.
In-cloud managed, priced per socket
Does openstack and kubernetes both on same infrastructure (enterprise version)
Manages HA deployments of tested configurations – installation, operation, upgrades, management
NDS compare:
P9 provides the openstack/kubernetes layers as a reliable easy service – potentially eliminating the infrastructure-setup headache
WB PaaS would live on-top of the managed kubernetes
Fabric8 –
PaaS layer tooling built on kubernetes oriented to java
Tooling for developer, operations, social, ci/cd, metrics …
Strongly java oriented
NDS Compare:
F8 is java focus – NDSL is open and non-opinionated about tools but less automated.
Comments and comparison on features:
What we consider workbench can be partitioned into logical layers:
IaaS – infrastructure (openstack for now)
Orchestration Layer – Kubernetes
Orchestration operational addons:
Storage, registry, cache
PaaS – The WB code that operates on/in the orchestration layer that provides a very basic model for catalog/service/instantiation.
Many of the systems above provide or manage the layers underlying the WB and provide these layers in a value-added service model. The NDSL underlying layers are not operationally automated, or offered as a value-add, but could both help provide a site with self-hosted value-added layers. This could be useful for self-hosted instances independent or in federation with NDSL.
Workflows: WB has very simple user-oriented service up/down workflows and tools. There could be other workflows built-in, or built as WB services, that perform administrative, operational, or other tasks.
User Management: WB has a primitive model, others have much better tooling for user management, policy enforcement, and integration to enterprise/existing systems.
Data Management (for computation, not data tools): None of the tools have meaningful data-management above their underlying IaaS models – openstack and similar. This is an opportunity for the NDS platform to differentiate in a meaningful way.
Production Operations: The hosted and managed tools have operations built-in (for the price), WB doesn’t – but we could offer the tools (some of which we deploy) in configurations for self-hosting sites, and even extend these tools to ‘backhaul’ to a main operational NDS site that collects aggregate usage, status, etc. for consolidated federation info.