With this post I continue introducing Adobe’s new technologies, that – in my opinion – will have a big impact on how we create applications that integrate with Adobe products. As the technology discussed in this post is in Alpha status, yet, this post is basically my own interpretation about what we will get. This post is supposed to be a teaser about Adobe I/O Runtime and I will introduce this technology in practice in another post later.
Serverless is a hot tech trend. More and more people and organizations consider serverless as a valid architectural choice. Adobe (collaborating with IBM on Apache OpenWhisk) also joined this trend and creates Adobe I/O Runtime.
Before looking into Adobe’s offering, lets see what serverless architecture means.
Serverless actually doesn’t mean No Servers.
The term, serverless architecture, refers to an event-driven application design and deployment paradigm where applications strongly depend on 3rd party services or code that runs in short-living, reusable containers. Such architectures remove the need for the traditional, always-on servers behind an application.
With serverless, there is no direct need to manage resources, so using such architecture can significantly reduce operational cost and complexity, but it comes with extra cost because of dependencies on vendors and the immaturity of the available frameworks. The best known vendor currently is AWS Lambda.
The real power of serverless is not in having a cheaper, simpler way of mangling the bits, but in the ability to create new applications by combining and extending APIs easily. This can be referred as application level serverless.
Developers want to focus on writing code and see it run, not doing tons of tasks needed to create and maintain environments, builds, deployments, …
The Openwhisk project was started to address this concern and empower businesses to enable their developers writing functional code without worrying about the rest.
Adobe I/O Runtime is one of the technologies powering the Adobe Cloud platform. You can use Runtime to write and deploy custom code that integrate with Adobe products or extend them. For example, you can create code that responds to Adobe I/O events.
The way how it works with OpenWhisk is that developers deploy event handlers to a cloud service and register them to respond to various events. Examples for events include AEM page/asset events, IoT sensor readings, GitHub repository changes, HTTP requests, etc.
One of the subprojects of Openwhisk is API Gateway which performs tasks like routing requests, triggering the serverless functions, throttling and logging. This API Gateway gives centralized access to Adobe’s products to combine the serverless functions with the Adobe APIs.
The following diagram shows a use case I found out for using Adobe IO Runtime to combine various Marketing Cloud APIs.
- Use Adobe IO Events to subscribe for certain events from AEM, for example a user submitting a form.
- We use Adobe IO Runtime to respond to the event and combine the APIs of Marketing Cloud products to deliver a transactional email with relevant, personalized content.
- We request information about the user from Analytics
- We use the capabilities of Campaign to trigger sending the email.
Adobe I/O events are exclusively available through a private beta program only. If you have a good use case, you can submit it to Adobe and get private access to familiarize with the new technology.
Adobe I/O Runtime beta is coming soon. I’m looking forward to trying it and sharing my experiences with this technology and how to get started.