This week we’ve got another special guest - Dr. Andreas Nauerz from the IBM OpenWhisk project. Andreas is the Technical Product Manager for IBM’s answer to serverless architecture. OpenWhisk is a service for running custom code based on incoming events, scaling up and down with demand.
Longtime readers already know that this kind of service brings a ton of engineering effort to bear on problems so that developers can work on their application, not on generic problems that affect all infrastructure. Scaling, monitoring, patching, and provisioning underlying hardware are all done by IBM in the Bluemix-hosted version or by your operations team if you run the Open Source code in your own datacenter.
OpenWhisk is built on and with other open tools including Kafka, Docker, Swift, and Scala so the full stack is open to users for inspection and modification.
Now that we’ve covered a bit about what OpenWhisk is, let’s hear from Andreas about its origins and future.
How long have you been working on OpenWhisk? How did the project start?
OpenWhisk started as a Research project in the Cloud Technologies Programming group at the IBM T. J. Watson Research center, initiated by the Bluemix team which saw a need to address the serverless space in an innovative fashion. This Research group has a long history of pioneering work in programming languages and programming models in a wide variety of domains. The Research team built the initial prototype of OpenWhisk, and was joined by the BlueMix development to drive the prototype to production.
In the long term, where do you see "serverless" or "event-driven" runtime-as-a-service solutions being in the marketplace? Is there a rough guess of the percentage of workloads that could be run with this model?
First and foremost: We don’t think that serverless computing will entirely replace the other approaches being available to do cloud-native application development. We think that all these approaches will remain to coexist.
So, for instance, when looking at Bluemix we believe that, in the future, people will still continue to work with VMs, containers, CF apps, too.
As usually all these approaches have their pros and cons and it will always depend on the particular use-case to decide which approach is “the best”.
While VMs provide you with maximum control & flexibility as it let’s you pick things like CPU, mem, storage, OS, OpenWhisk will help you to get started quickly because infrastructural and operational tasks are abstracted away to allow you to focus on developing value-adding code.
But if we look at the current trends in IT we think that the amount of applications being developed by following a serverless approach will significantly rise.
The top trends include things like IoT - here a lot of sensors are continously sensing a lot of data which are actually events - perfectly suited to be handled by an event-driven programming model.
Other trends to mention: Analytics - where you may want to react on a trend (=event) you detected; cognitive - where you may want to react on the results of a semantic analysis; mobile - where you may want to outsource compute intensive tasks to a scalable cloud platform. Data-centric scenarios aren’t a new trend and have been key to IT since ever - but even those can now be addressed more efficiently due to the existance of a true event-driven programming model that allows you to react on data changes.
So, we think that there are so many trends that require an event-driven programming model that serverless has a promising future.
Even the way organizational structures have changed and continue to change may drive people into the direction of serverless; organizations have started to organize themselves in small teams able to quickly deliver flexible & scalable components. Hence, they require a flexible programming environment that allows each team to reuse existing skills and to develop each component by using the best suited technology.
Serverless solutions provide them with such an environment. They allows them to develop in different languages like NodeJS and Swift to reuse skills and to develop in a fit-for-purpose fashion. They do not dictate a one size fits it all approach.
The granular pricing model of serverless solutions may also drive people into this direction.
Are there other projects you count as inspiration for the OpenWhisk project? What do you think those projects did well that you hope to replicate in OpenWhisk?
Recently IBM has been working with the Swift project initiated by Apple, and been active on the Swift@IBM engineering effort.
We have been in touch with the guys that ran that project from the very beginning in order to learn from them what works and what does not work and how to carry out specific tasks.
We ran our project as open-source as well, so that we could replicate some decisions they made – and avoid reinventing the wheel.
What makes Swift such a compelling choice as a language to support? There are lots of options here (Python, JVM-based languages, Ruby, etc)
Serverless/OpenWhisk makes it easy for mobile developers to outsource compute intensive tasks to a powerful cloud platform, esp. as they can continue to code in one of their favorite languages - Swift - relieving them from learning something new.
OpenWhisk makes it easy to do so, by providing SDKs, e.g. for iOS, to ease development with OpenWhisk and by supporting languages like Swift even on server-side to avoid the need of learning new languages for the typical mobile developer.
Was there something in particular that drove your team to choose the Open Source route with this project? A lot of service providers might choose to keep their tools closed to be more differentiated from other options.
We made OpenWhisk open to avoid what we think people do not like: vendor lock-in - that is why we built OpenWhisk in a way it can be deployed and run anywhere.
Despite that we also regard an open ecosystem of services from different domains and vendors as crucial, this is yet another reason why we made OpenWhisk available as open-source encouraging others to participate and contribute to accelerate development and help building such an ecosystem. Due to the openness of OpenWhisk we even allow others to add support for additional languages and runtimes and accelerate development even further.
How much proprietary code is there in the project that isn't up on Github?
Well, as you may know we have one (commercial) offering running as part of Bluemix as well as an open-source project.
One is the commercial offering - currently available as experimental program - running as part of Bluemix.
At its core this offering is entirely based on the open-source offering; it only contains minor additions to adapt things to Bluemix plus UI components such as our visual code editor.
The open-source offering is entirely open, of course, and is on Github.
I see the backend is written in Scala, how did the team decide on what language to use?
Are there any limitations on what can be run in OpenWhisk? Swift and NodeJS are supported by default, but I see users can upload their own Docker image. Are there limits on size or anything for that?
Yes, especially for the commercial offering, we are currently defining necessary limits (to keep load under control and to protect us and our users from DoS-alike attacks and such).
As we are still running as experimental program we have not finalized all limits so we do not want to communicate the details yet.
Have you written a product like this before, or is OpenWhisk your first crack at the event-driven platform space? Tell me about what you learned from past iterations.
At least for me it is the first time that I am developing a “real product” playing in this space.
But when I joined in 2015 I came on board with some at least “related” background; at university I was the head of a research group working on a project called Mercury which was (and is) very similar to IFTTT. IFTTT isn’t quite like OpenWhisk, as IFTTT is more about automating processes instead of outsourcing tasks to a scalable cloud platform and more about if this then THAT instead of if this then CODE it obviously has things in common.
Things I learned:
- As a product manager it’s an unbelievale broad spectrum of tasks you need to take care of… both: Very challenging and exciting.
- You need to work very organized and with a lot of discipline to keep track of all this different things that need to be taken care of.
- You need to make sure to keep all stakeholders in the loop and talk/sync/meet a lot.
- You need to invest a lot in non-technical topics, esp. into marketing topics and community-building to drive the momentum behind your project and to keep everything vibrant; for instance, social media activities are important.
- Also, there are many long-running things to be taken care of when launching a product that you as a product manager should start with early; one simple example: Finding the right name and a logo :)
- And there are tasks less fun but necessary to be taken care of - like all “legal” discussions”.
In previous projects, the Research team worked on a number of projects with similar language concepts. The most relevant projects include the IBM Bluemix Workflow Service and the Liquid Metal programming language.
What monitoring can OpenWhisk users depend on? Tell me what a user would do to keep an eye on their production application if it were hosted in BlueMix vs. running OpenWhisk on-premisis.
Well, on the one-hand side it is of couse up to the developer - as with any software development - to implement his code robust and in a way to make it easy to debug.
But of course we help :)
As one example, we provide you with an analysis dashboard… it allows you to review (the results of) your recent activations so you can see if they succeeded/failed, what the response was etc.
In the future we will event extend this dasboard to make it even easier to filter for particular activations, e.g. to find ones that failed in a certain time-frame, find ones by memory they consumed or by their execution time…
The analysis dashboard also provides you with statistics that help you to understand you activations’ behavior. As another example, we provide you with a visual code editor that allows for writing code and means to quickly test your code even from within a browser.
Are there any tools or libraries you found particularly helpful either while building OpenWhisk or for running in OpenWhisk that you'd like more people to know about?
We have had pretty good experience using Kafka, Consul, the Eclipse Scala tools, and ELK. We rely heavily on SoftLayer for our development infrastructure – we encourage people to give SoftLayer a try for IaaS.
Dr. Andreas Nauerz will also be speaking at ServerlessConf coming up on May 26&27 2016 in NYC. There are still (a few) available tickets, and all the talks will be recorded after the conference.
To learn more about IBM’s OpenWhisk project, check out the project homepage, or try out their (beta) hosted option. If you’re interested in IBM’s involvement in Swift, and using it on OpenWhisk, IBM also has a Swift Developer Center.