Clusters & Containers on MassiveGRID PaaS

Clusters are where a platform earns its keep. Building a Kubernetes cluster, a Docker Swarm, or a load-balanced Tomcat farm by hand takes days and a runbook; on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic), each is a package. Kubernetes installs a control plane and worker pool with an ingress controller, dashboard, monitoring, Helm and persistent storage; Docker Swarm installs managers and workers with the routing mesh; Docker Engine gives a single Docker host with Compose; the Spring Boot, Tomcat/TomEE, WildFly and GlassFish clusters put Java application nodes behind an NGINX load balancer with synchronised deployment and auto-scaling triggers; GitLab and Jenkins arrive with auto-scaling runners and agents; Couchbase and GlusterFS provide a document database cluster and replicated storage; Open Liberty in Kubernetes and the Spring Boot builders cover Jakarta EE and microservice builds; an IOTA node rounds out the list.

Nothing in this category carries a control-plane or per-cluster fee. Every node is billed hourly by the cloudlet (128 MiB RAM plus 400 MHz CPU) at $0.003372 per cloudlet-hour, so a development cluster that is stopped at night with the Start/Stop Scheduler costs a fraction of a production one, and a cluster that scales out for a release scales back in afterwards.

Kubernetes or Swarm is a team question, not a technical one. Swarm is simpler to operate and enough for a dozen services on a handful of nodes; Kubernetes is the ecosystem every tool integrates with and the right choice when the team already speaks it or needs operators, Helm charts and namespaces. The decision post works through a concrete application.

For a Java application, the cluster package beats a container image. The Tomcat, WildFly, GlassFish and Spring Boot clusters are certified stacks: the platform knows how to scale them, synchronise a deployment across nodes and keep sessions alive through a failover, which a generic container does not get for free. Use Kubernetes when the application is already packaged for it.

Size the workers, not the control plane. The Kubernetes and Swarm control planes need a fixed, modest allocation; the capacity your workloads get is the worker pool, which is what the sizing rows on the package pages grow. Start with the Starter row, deploy, and read the real usage from the dashboard before raising it.

Every package page carries a sizing table with three configurations. To price a configuration of your own, or to see what a package costs on a working-hours schedule, use the PaaS pricing calculator.