Why it matters
Most modern data platforms have polyglot access requirements. Python for data science, Go for services, JavaScript for web. Forcing every language to use JVM shims (via Py4J or similar) is painful. The Thrift and REST gateways give clean native-feeling clients in many languages.
The gateways also enable ad-hoc access from tooling that supports HTTP or Thrift, without needing a full HBase client installation. curl, Postman, and browser-based tools all work with the REST gateway.
The architecture
The Thrift gateway runs as a Thrift server on a chosen port. Clients use Thrift-generated bindings in their language of choice to make calls. The gateway translates each call into HBase Java client operations and returns the result serialized as Thrift objects.
The REST gateway runs an HTTP server. Clients issue GET, POST, PUT, DELETE requests with paths like /table/rowkey/family:qualifier. Responses come back as JSON or Protobuf. The gateway does the same translation to HBase Java client calls.
How it works end to end
Deployment is straightforward. Run one or more gateway processes on hosts with access to the HBase cluster. Put a load balancer in front for HA and throughput scaling. Clients connect to the load balancer, and gateway state is stateless enough that any gateway can serve any request.
Performance is lower than native Java. Every request pays for one extra serialization step and one extra network hop through the gateway. For light workloads this is invisible; for heavy workloads (millions of requests per second) it matters.
Security is per-gateway. Kerberos support exists for both Thrift and REST gateways, allowing authenticated access. Ranger plugins can enforce authorization at the gateway. TLS wraps the transport for confidentiality.