We haven’t publicized or released features for a few weeks now. We’ve even received a few inquiries asking what we’re up to. Here’s what’s coming.
Simply stated, we’re about to blow the boundaries for a PaaS provider (a categorization we don’t necessarily embrace, by the way). Pagoda Box has never been merely an Amazon provisioning service, but upcoming developments will make other PaaS comparisons obviously inane.
What’s Being Added to Pagoda Box:
Public Cloud, Private Cloud and Dedicated Hardware
Every web, cache, db, and worker component will soon have the option to scale with Public, Private and/or Dedicated (bare metal boxes) resources. We still handle all the migrations, deployment and updated networking without downtime, while allowing users to switch between 3 types of resources. That means anyone can start free on Public Cloud, then scale to Private resources (dedicated RAM and CPU) or fully Dedicated hardware (you specify server RAM, CPU, Disk I/O and Storage), and back again.
A dedicated hardware option obviously opens the door for VERY high volume applications, as well as more creative use of dedicated, private or public resources in a single application. For example, an image manipulation application could scale a cluster to 12 servers at 96 GB RAM, 24 Cores each, yet keep the blog on two 200 MB public instances. Architecture can be adjusted specifically for traffic and usage, all managed simply without a SysAdmin.
Automation is fantastic when you know all the details. However, because we provide new users so much flexibility via the Boxfile, Deploy Hooks and Data Migrations, occasionally the Transaction Engine hangs on an unexpected command. So we’re introducing a feature that lets developers back out of a paused infrastructure transaction, reconfigure, and try again. Coupled with Streaming Logs (below), this feature makes it easier to push the limits of automation on Pagoda Box, with a handy ‘UNDO’ in case you push too far.
Same Network Equals Minimal Latency
All services (including Dedicated servers) reside in the same local network, which provides a HUGE latency reduction over other alternatives (ex: code hosted with one provider, DB with another). We won’t even mention the security issues this avoids.
Monitoring, Alerts and Auto-Scaling
With this coming update, we’re also releasing the ability to generate Alerts or Auto-scale resources up or down. Monitoring will track either Time, or CPU, RAM, and Load. Users will specify conditions for Alerts or Auto-scaling based on those metrics.
By introducing Dedicated server options and Auto-scaling, we’ve also totally revamped Analytics. Analytics provide the metrics which trigger Alerts or Scaling, and needed to be consistent across Public, Private and Dedicated resources. It’s a significant, and much more useful shift from the previous Analytics, and has obviously taken a significant retooling.
Streaming / Searchable Logs
We’re also releasing a unified Logger, which manages logs from every single component process (meaning every individual web instance, db instance, application logs, etc.) no matter how large the scale. Logs will be combined for an entire application, streamed real-time through the Pagoda Gem (terminal). Logs are also filterable, to help users extract isolated Logs from individual components, like MySQL or specific web instances. It will provide more visibility behind the scenes, and help application developers troubleshoot code.
1 or 2 More Things:
We’re also about to open up 1) visibility into a hosted PaaS infrastructure and 2) manipulation of the infrastructure in a way that PaaS hasn’t seen before… You might want to stay tuned.