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.

 

  • No labels