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.
The Interview
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.
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.
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.
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.
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.
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.
The Research team started by prototyping most components in node.js. Over time, the team came to the conclusion that Javascript was limiting our progress due to difficulty in refactoring, and also immature support for the kafka SDK in particular. We decided to move to a JVM-based language to exploit first-class support for Kafka. We considered both Java and Scala – having deep experience in Java, we decided to try Scala as an experiment. We now consider switching to Scala one of the best decisions we made. The language allows us to write shorter, more elegant code; and when used correctly, the language eliminates whole classes of runtime errors including null deferences. We think switching from Javascript to Scala increased reliability of the core components significantly.
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.
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.
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.
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.
Wrapping Up
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.
Keep up with future posts via RSS. If you have suggestions, questions, or comments feel free to email ryan@serverlesscode.com .