In a world where microservices continue to grow, offering better agility for iterating quickly, many of the tools you use in building applications must adapt. Microservices bring together challenges in a variety of ways for the services you consume – logging and monitoring tools now need a broader perspective than that of a single app, data services may be shared either for reporting or direct access to data.
Heroku has been on the forefront of creating a developer tools add-ons ecosystem that lets you focus on building your app by grabbing the service you need off the shelf. Today, the Heroku platform is becoming even more powerful with add-on sharing – a new feature for composing applications that allows multiple apps to share add-ons and add-ons to bridge multiple apps. This new iteration of our add-ons API provides several key improvements, making working with the add-ons you already know and love even better. These include:
- Share your add-ons: Ability to attach your add-ons across multiple apps owned by the same account
- Have multiple add-on instances on your app: Ability to have multiple add-ons from a single provider on an app
- Improve add-on visibility: Create unique names for your add-ons, making it easier to share and communicate to your team about your add-ons.
Let’s take a quick drive of how you’ll experience this new functionality.
First let’s create our add-on:
$ heroku addons:create heroku-postgresql --name my-sushi-db -a my-sushi-app Creating my-sushi-db... done Adding my-sushi-db to my-sushi-app... done Setting DATABASE_URL, HEROKU_POSTGRESQL_JADE_URL and restarting my-sushi-app... done, v4 Use `heroku addons:docs heroku-postgresql` to view documentation.
Now that we have this new database on my-sushi-app we can reference it two ways, via
HEROKU_POSTGRESQL_JADE_URL. But we can also add the my-sushi-db database to another app, and for better clarity we can name it as well:
$ heroku addons:attach my-sushi-db -a my-sushi-reporting --as MAIN_SUSHI_DB Adding MAIN_SUSHI_DB to my-sushi-reporting... done Setting MAIN_SUSHI_DB vars and restarting my-sushi-app-reporting... done, v3
An important item to note is that with this powerful change to how you’re able to work with add-ons, we’ve made modifications to the commands used to work with add-ons. The
create command is now used to create your add-on and the
attach command is for sharing it across apps; in the future we’ll be working to deprecate the
addons:add command in favor of this new nomenclature
Now that you’ve gotten a high-level picture of what this means to you, let’s dig in a little more on the specifics of what add-on sharing enables for you.
When Rails emerged it allowed faster development and richer applications. It helped popularize the MVC approach to building applications, which made decomposing your app into smaller pieces possible. Since then, we’ve seen a trend toward further decomposing apps into smaller microservices, allowing teams and companies to move even faster. Though as microservices grow you have other trade-offs – namely getting visibility across your entire application.
Let’s dig deeper into one example of how add-on sharing gives you this visibility back. One of our most popular add-ons New Relic provides performance monitoring for your application. As your app becomes decomposed you have may have previously had multiple instances of New Relic running attempting to correlate across them. With add-on sharing you’ll be able to simply share your core instance of New Relic to all the other smaller apps and get both a broad but detailed picture into where your performance bottlenecks are.
Here’s what Bill Lapcevic, VP of Customer Success at New Relic, had to say about the new add-on sharing – "New Relic has been an add-on partner from the early days when Heroku pioneered the developer tools ecosystem. We’re excited to be among the first add-on providers to have access to Add-on Sharing, a powerful feature that allows developers to monitor multiple Heroku apps, giving them unprecedented visibility into their environments."
When it comes to the services backing your application while you care about all of them, often you don't care about all of them equally. A great example of this is the multiple use cases that exist for Redis. The two use cases we see very often for developers on Heroku are queueing and caching. When asked which they care more about, we hear a resounding answer of queueing. As an architectural pattern what we see is companies pick what they feel is the most reliable Redis provider and plan for their queue, and are often more flexible on which provider and plan they use for their cache.
With the changes announced today, you’ll be able to choose a single provider based on the same factors and simply choose different plans to suit your needs.
Having a unified view of everywhere your service configs are set gives you back the safety you need while still letting you decompose your app into smaller services. As highlighted within the 12 factor app, storing your config in the environment is a great practice, but in a production environment you less often need those raw values but rather a reference to it. With underlying updates to easily give you an unique reference to your add-ons, we provide greater visibility to everywhere.
Let’s take a quick look at the references of dozing-idly-4940 (the database we added above):
heroku addons === Add-on Attachments my-sushi-app DATABASE @dozing-idly-4940 my-sushi-reporting MY_SUSHI_APP_MAIN_DATABASE @dozing-idly-4940 my-sushi-app HEROKU_POSTGRESQL_JADE @dozing-idly-4940
We’re excited for this iteration of add-ons to provide even more power and flexibility in the apps you build.
As our other add-on providers enable this support you’ll automatically be able to take advantage of multiple instances of an add-on, and as well as sharing your add-ons across your applications.