Using Apprenda’s Add-On Model to Achieve DevOps Nirvana

By Atos Apprenda Support

Apprenda Lego Add On

Almost three years ago, Apprenda introduced a platform feature called Platform Add-Ons. In the time since, our customers’ Operations teams have used Add-Ons extensively to provide services to their developers, ranging from network storage to SMS notification capabilities.

The premise of the add-on model is quite simple: allow Platform as a Service (PaaS) operators to provide access to off-platform services through a controlled “broker” model. Off-platform services can be other systems in the data center (NetApp Filers, MongoDB clusters, etc.) or they can be public cloud APIs (AWS S3, Azure Blob Storage, etc.).

Platform operators create add-ons, or they grab them from Apprenda’s growing GitHub repo and apply them to their platform instance. Developers can then browse the catalog of add-ons, select the ones their application(s) may need, and instantiate their own dedicated instance(s) of these add-ons. When they do so, the add-on provisions access to the service and configures the developer application(s) with the information necessary to connect and consume the provisioned service.

The add-on model in Apprenda is extremely helpful for standardizing how developers consume enterprise (and public) resources. By supplying developers with brokered access to these resources, IT departments can control how developers use them. For example, because the add-on is responsible for provisioning, it could use a single cloud service account or subscription across the enterprise without having to share that account information with developers.

All the developer needs to know is that the add-on has provisioned the resource for them and configured their app for access. The developer then uses the API or other information associated with the resource to leverage it within their app code.

I was recently speaking with a customer who wanted to take this a step further in terms of standardization, so together we designed an approach that effectively abstracts the add-on model. The Apprenda operators implement their own web service API that fronts an off-platform resource and then provides an add-on that connects developer apps to that web-service API.

Why would they do this? Consider the following: IT wants to offer a cloud-based notification capability to their enterprise developers and decides that a PaaS add-on is the right approach. Initially they choose cloud provider A, yet over time for one of many possible reasons they decide to move their notification business elsewhere. Even with their developers using an add-on to broker connectivity, they will still have a large collection of apps that have coded against provider A’s API. Instead, providing their own web service API in front of the actual cloud service, they’ve abstracted the cloud API.

Imagine a simple notification API. The web service might look like this (in pseudo code):

SendEmail(string message, string address)
SendSMS(string message, string telephone)

Of course, this simple API and its backend logic can be deployed as an app on the platform by the Operations team. A corresponding add-on will provide provisioning and connectivity linking developers’ apps on platform to this web service. Developers then code using SendEmail() and SendSMS() in their apps. On the backend, though, the implementation of cloud notification can be changed by simply patching the notification web service.

Visually, the architecture looks like this:

Apprenda Add On

PaaS really is a tool that changes IT into a services-based part of the enterprise. With the platform add-on model, IT can offer their own services backed by private and/or public services that they otherwise would not be able to offer to their developers.



Atos Apprenda Support