LunchBadger: Microservices, Serverless on Kubernetes
First off, there’s that name: LunchBadger. Who does that?
It’s the code name for the company, explained founder and CEO Al Tsang. The idea was that if you could eliminate the ambiguity around microservices, how you build them, what to do with legacy code, how to deploy them, you could eat your competition for lunch.
“In achieving a modern architecture like microservices, there isn’t a lot of tooling and know-how aside from what the Silicon Valley trailblazers did on their own,” he said.
The company set out to take best practices, new technologies like containers and the Kubernetes open source container orchestration software, and other tools and services being standardized around these technologies to create a platform for building and deploying microservices in cloud-native infrastructure.
The company’s software package is based on serverless infrastructure and a Kubernetes runtime.
“We’ve taken what Amazon pioneered long ago with Lambda and API gateway and proprietary runtime, and said we can build a superior experience on top of these technologies that is based on open source, cloud agnostic and provide a single pane of glass to orchestrate these things with a UI that’s easy to understand across developer, DevOps, and even the business folks,” he said.
The LunchBadger visual canvas allows developers to build and manage the end-to-end lifecycle of microservices and APIs. You can compose microservices, integrate with enterprise data stores, set up security and governance policies, write functions, publish external API endpoints and more.
Tsang was co-founder and Chief Technology Officer of StrongLoop, which offered an open source enterprise version of Node.js, and where he created LoopBack, a leading open source Node.js framework for enterprise APIs. IBM bought out StrongLoop in 2015. Tsang launched San Francisco-based LunchBadger in June 2016.
The LunchBadger platform consists of an API gateway, composition and integration tools, and integrated development environment to write functions.
Developers don’t have to know everything about Kubernetes, he said, but there needs to be transparency because nothing ticks off developers more than black-box technology. The platform provides automation for things like deployment and writing YAML files, but it’s all open source.
On the back end for connections to the data sources and model-driven development, it uses the Node.js framework LoopBack, which he calls the leading framework for developing microservices and exposing them as APIs, and the leading integration platform to be able to talk to legacy and polyglot systems like Java and Python.
The gateway is built on Express.js, a project called Express Gateway that’s supported by the Node Foundation and Joyent. It’s a competitor to Kong, Tyk and other legacy players in the API gateway space.
It’s teamed up with Joyent to provide a cloud-agnostic alternative to AWS Lambda and other proprietary serverless offerings.
“People who can’t be on a virtual public cloud or public cloud who want this in-house or who want a choice where they run it, and also reserve the right to run it in multiple clouds, need a transparent solution to do so,” he said.
After the acquisition, it was working on consolidating storage, creating Private Regions — centralized, low-cost storage that’s open and portable across public and private clouds.
“We’re spinning up a lot of these regions for large customers, but they really want to distribute compute across clouds. They really want portability,” said Shubhra Kar, vice president of product and marketing at Joyent.
“So when customers had DIY projects or Kubernetes as a managed service on various clouds, these platforms, once you get locked in, you have so many abstract dependencies: You need to be tied to their gateway, to their IAM provisioning rules, all the event-based services, you need to be tied into a pool like Lambda to do microservices, so it’s not really portable under the hood,” Kar said.
Joyent rolled a multi-cloud Kubernetes solution, looking at managing compute globally, which required cross-cloud monitoring, cross-cloud Kubernetes upgrades, cross-cloud Kubernetes management.
“We are integrating with some of the native Kubernetes services on each cloud, but customers told us it was a good base, not enough: I’m still locked into a database-as-a-service, I’m still locked into Lambda. I like the velocity, I like not having to run operations, but I don’t want to be locked into a black-box technology,” Kar said.
Customers said they might be on to something if Lambda would run on Kubernetes to be able to port from one cloud to another.
“They didn’t start thinking in terms of multi-cloud, as we’ve been demoing it, going into POCs with a lot of these customers. This services layer — we call it a set of open services — is what is emerging: Database as a service, functions as a service, if you are building microservices assuming Kubernetes is going to be the compute, you are able to port anywhere — cross-clouds, back to on-prem, hybrid. You have that flexibility and control, but at the same time you get that velocity,” Kar said.
He pointed to two projects at Samsung using LunchBadger that are in the works, but not yet in production:
- Mobile device management: providing role-based access in a hybrid model across Samsung phones. It would involve a mashup of both customer and Samsung device APIs and identity APIs in a service mesh.
- Bixby, an intelligent assistant: The backend is APIs and microservices needing high performance. It has a lot of machine learning that runs on GPU instances to accelerate compute. Instead of doing this on traditional VMs, it uses Kubernetes for that and integrates with the microservices stack up front to serve the Samsung mobile device.
Feature Image: “L0081839 Woodcut of a badger. Conrad Gessner, 1551” by Wellcome Images, licensed under CC BY-SA 2.0.