Why it matters
Managing a Hadoop cluster by hand is a nightmare. Every service has dozens of config files, each config file has dozens of parameters, and consistent configuration across hundreds of hosts is a manual impossibility. Ambari solves this by treating cluster configuration as central, versioned state and pushing it to every host consistently.
Ambari also produces alerts and dashboards that operations teams need. Without Ambari (or an equivalent), you have to build the monitoring stack yourself, which is a lot of work.
The architecture
Ambari has three main components. The Ambari Server is a Java web application that hosts the UI, the REST API, and a database with cluster state. Ambari Agents run on every host and receive commands from the server (install this service, start this daemon, update this config). Managed services are the Hadoop components — HDFS, YARN, HBase, Hive, Spark — that Ambari installs and controls.
Configuration is centralized. When you change a config parameter in the Ambari UI, the change is versioned and pushed to every affected host via the agents. Ambari also computes recommended values based on cluster size, memory, and other cluster characteristics, which is a huge time saver for initial deployments.
How it works end to end
Blueprints are Ambari's declarative cluster definition. A blueprint specifies which services run on which host groups, plus a stack of default configuration. Given a blueprint and a host mapping, Ambari can install and configure a complete cluster with a single API call. This is critical for reproducible deployments across environments.
Alerts are built into Ambari. Each service ships with default alerts (NameNode heap high, DataNode down, region server unresponsive) and users can add custom ones. Alerts fire based on JMX metrics, log patterns, or health-check scripts. The Ambari UI shows all firing alerts in one dashboard.
Ambari is undergoing displacement. Cloudera Manager took over the Hortonworks/Cloudera merger. Kubernetes-native distributions run on Helm charts and Operators, bypassing Ambari entirely. New clusters increasingly do not deploy Ambari; existing ones stay on it for stability.