Skip to content

Why PadoGrid

Jump to bottom
Dae Song Park edited this page Sep 13, 2022 · 2 revisions

Why PadoGrid?

  • You need to integrate several clustering products and wish to manage them with a unified set of commands.
  • You are spending too much time configuring each product individually and repeatedly. You need a quick way to setup clusters on the fly.
  • You wish to stash away your local environment and be able to reinstate as needed.
  • You have multiple setups that need to be individually cataloged so that you can quickly revisit them as needed.
  • You need to capture your local environment and reproduce it elsewhere. You want to deploy the exact image to another machine.
  • You want to share your applications with others.
  • You wish to create a local environment where you can test and troubleshoot production system issues.
  • You want to be able to reuse your environment to prevent the others from reinventing the wheel.
  • You are an end user with little or no backend experience. You just want to be able to spin the backend and have your app running in your own sandbox.
  • You are new to creating distributed systems. You want to get a firm grasp of how a distributed system works so that you can build one.
  • You are given the task of migrating a legacy system to mondern technologies, i.e., clouds, Kubernetes, etc. You want to maximize your learnng time by going through hands-on examples and use cases.
  • You have production problems which the support team is unable to reproduce. For security reasons, you are unable to provide what the support team needs in order to reproduce the product problems.
  • You want to conduct performance tests on distributed systems.
  • You want a shrink-wrapped, out-of-the-box solution to your use case.

PadoGrid Manual

Overview

Operations

Tools

Platforms

Clouds

Pado

Geode/GemFire

Hazelcast/Jet

ComputeDB/SnappyData

Coherence

Hadoop

Kafka/Confluent

Mosquitto

Redis

Spark

Clone this wiki locally