Introducing our New Add-ons Section

We are committed to helping you build and grow epic apps in every way possible. With hundreds of innovative companies out there building great services complementary to our platform, we want to make using those services as easy and seamless as possible.

That’s why we started the Add-on Partner Program over 2 years ago. And that’s why, today, we are taking next steps in expanding the program.

We are excited to announce a new home and updated design for Add-ons at addons.engineyard.com. (The old Add-ons UI will remain fully functional during the transition.) Along with the new UI, we now support a new API, and are pleased to announce the first new Add-on to integrate with it: Rollbar Error Tracking!

The New Look of Add-ons

We had four major goals with our addons.engineyard.com redesign:

• A UI that fits with our new design direction and branding

• A UI that is flexible enough to accommodate multiple Add-on types

• A UI to manage Add-ons that works for environments running on both cloud.engineyard.com and ui.engineyard.com

• Allow Add-on Partners who have integrated with other Add-on marketplaces a quick and easy way to sell their services on the Engine Yard platform

Introducing Rollbar

Rollbar is the newest Add-on available on our platform! We use Rollbar every day here at Engine Yard for all our exception tracking. Here’s a screenshot of recent exceptions happening on the app responsible for UI and API traffic for addons.engineyard.com. Our internal name for the project is ‘tresfiestas’.

To start using Rollbar select an application environment from the drop-down and choose a plan.

After you’ve installed the rollbar gem and configured your app you can access the rollbar dashboard from the Add-ons UI by clicking on the environment name.

Remember that you will need to add the rollbar gem and deploy your application before Rollbar will start collecting exceptions.

How it works

Rollbar is using our new “haiku” API to implement their Add-on. The curious can check out the API documentation.

When you login to the Add-ons system we lookup your existing user session and ask our API to list your accounts, applications and environments.

Activating an Add-on on one of your applications dispatches an API call to Rollbar with your application and plan information. Rollbar provisions the service and returns a set of variables that our platform makes available to your application.

The next time you deploy your application our deployment system calls the Engine Yard API to fetch the configuration specific to that application enviornment. The deployment tool then writes the file ey_services_config_deploy.yml which your app reads from by using the ey_config gem.

Evolving Architecture

At the time of this blog post, both Add-on UIs are still fully functional. So while the diagram above shows “Old” vs. “New”, the current reality is the combination. But, ignoring that for the moment, let’s talk about the change in architecture and philosophy behind it.

In the “Old” world most of our product and UI were part of a monolithic merb rails app which we refer to internally as “awsm”. When dealing with the monorail, we are always looking for ways to extract smaller more manageable services. So when the concept of Add-ons was originally conceived and subsequently designed, we decided to implement the system as a separate app.

Having a seperate app made it much easier to iterate on the public facing API design, but we also made premature assumptions about what the UI would be like and thus what APIs would be needed to power it. The interal API exposing “what Add-ons are available” and “here’s the information about an Add-on” is inherently coupled (and thus optimized for) the UI. This worked out for the initial launch of Add-ons, but added extra overhead whenever wanted to make simple changes to the Add-ons UI, such as providing different instructions based on app languague (Ruby vs. PHP).

Our new architecture slims down our monorail not just by offloading things that can be abstracted to external services, but also by entirely removing the Add-ons UI. To do that end we are exposing this information through a unified API as part of our monolith. Instead of Add-ons service providing an API with information about available Add-ons and how to activate them. Our platform provides an API to update configuration on accounts and environments. This API also provides single-sign-on, user, account and environment data.

The end result is a much smaller, simpler and faster set of interactions between both systems. As an added bonus, if Add-ons is down there is no effect on availability of configuration variables to your applications.

Different APIs

Now that we have an independent Add-ons UI, we are tacking advantage of the flexibility to customize the workflow for each Add-on.

You might notice that enabling Rollbar works slightly different from other Add-ons such as SendGrid. With Rollbar you select a plan in the Engine Yard UI and click “Activate”. With the SendGrid Add-on there first a “Set it up” step which redirects you to a SendGrid page where you select a plan. And then when you “Actitivate” there is no need to select plan. As a result, the pricing structure is different too. With Sendgrid you pick your plan once at the account level, with Rollbar you pick a plan for every project you use.

This is partly a side-effect of choices made by the Add-on developers. By using the “sonnet” API SendGrid is able to control the plan selection process and provide plans that cover your entire account. The result is a more involved setup workflow for first time customers but a simpler workflow when adding SendGrid to your second or third application.

We’re certainly not done yet! Engine Yard and our partners will continue to work to refine and improve the Add-ons experience. Sometimes that means offering different tools to our partners so they can customize the experience better to the way their Add-on works. These tools come in the form of different APIs to use, and different Add-on-wide configuration options available to the Partner. Sometimes that means customizing our UI to support a varation in workflow while maintaining compatible API calls underneath. Always, it means working with our partners and striving for the best possible experience for our shared customers.