6 Week Roadmap

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.

Massive Scalability

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.

Abort Transactions

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.

Updated Analytics

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.

12 comments on “6 Week Roadmap

  1. Very excited to hear about the new dedicated setups. So from what I’m understanding I could give redis a dedicated machine with 8 gigs, while keeping my web app at free.

    • We get this question a lot, not surprisingly. Here’s an official look inside Pagoda Box decision making.

      Mongo is awesome, and we use it internally for a number of tasks. We can’t wait to release this to our users. However, keep in mind that our Mongo service has to be scalable, automated, and optimized to “just work” out of the gate, even when migrating between public, private and dedicated resources.

      While we’ve wanted and intended to release Mongo for quite awhile, recent developments highlighted the need to first unify global server and system processes (resulting in Private and Dedicated options). We realized it’s better to solve the very complex migration and transactional Mongo problems once, rather than solving them 3 different ways as each new change is rolled in.

      Additionally, we’ve recently restructured the underlying technology and processes used to create services. Without saying too much, it will speed our release of additional services like Mongo, and will open up new PaaS controls for users in the not too distant future. As I said earlier, you might want to stay tuned as this plays out.

  2. really looking forward to this rollout. auto-scaling and the return of metrics has been at the top of my wish list for sometime now & can’t wait to give it a run. if you need a tester for this, i’m in!

  3. Sounds really exciting and I really like Pagodabox. Any updates on analytics improvements and the improvements mentioned on this blog post?

  4. Can’t wait to see the new features come online.

    Are their any plans to make it possible to deploy applications in different regions? I’m based in the UK and would really appreciate the speed boost I’d get from being able to deploy sites in Europe.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>