GCP Podcast - Serverless Made Easy with Nimbella

Transcript

Rodric Rabbah 0:00
I see a path where eventually you will be serverless and companies like ours are about looking at how do you compress that time of migrating from existing applications into the cloud, but also about looking for, you know, design methodologies for developing new applications.

Darin Pope 0:19
This is DevOps Paradox Episode Number 65. Serverless made easy with Nimbella.

Darin Pope 0:28
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make us sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin Pope 1:21
We've been talking serverless for the past couple of weeks. And today, much like what we talked about on the previous episode, we said we were going to have a guest. Now, our guest today is Rodric Rabbah. He was a principal researcher at a three letter company, I'll say it IBM, where he was the creator of Apache OpenWhisk, which if you don't know what OpenWhisk is, it's an open source serverless platform. But right now he's the co founder and CTO of Nimbella. It's a serverless cloud provider. Rodric, thanks for joining us today.

Rodric Rabbah 2:05
Thank you for having me, Darin. Thank you, Viktor.

Viktor Farcic 2:08
We had a short chat before we started and I think that what you're about to explain fits very well into into what we're doing and what we didn't reveal yet to people, but anyways, can you give us your view of serverless?

Rodric Rabbah 2:26
Yes. And I think, to do that, I should look at how my journey into serverless began. And it started about five years ago. It was shortly after Amazon announced their new service called Lambda. At the time, I along with a small team from IBM Research, we were working on something that was related. We hadn't realized that this ability to just push code into the cloud and run it not thinking about infrastructure, not thinking about the server, not thinking about the runtime, was incredibly powerful. And we were doing that in a slightly different context in the context of field programmable gate arrays. Not going to get into that too much, because I think it would be a big distraction. But when we saw Lambda it was immediate light bulb for us was like, Oh, this is incredibly powerful. And so we got together a small team and started building what became Apache OpenWhisk. And my team launched IBM Cloud Functions at the time. And over that period, what I, when I got the benefit of working at IBM was to work with many of IBM's early adopters of serverless computing. And through that experience, I became convinced that the future of the cloud is serverless. And the reason I believe that is because serverless makes the cloud accessible. And it has a lot of properties that are desirable, and that I think, are necessary as we look into the future of the cloud era. So I've been saying this term of you know, in my view, serverless is inevitable. And that's when I decided to leave IBM. And after a few months, I started a new company, Nimbella.

Viktor Farcic 4:07
So what is serverless then?

Rodric Rabbah 4:10
So I think serverless is really a transformation and it is a methodology that organizations have to adopt. And the reason it's a transformation and not any one particular technology is because it's a fundamental shift in the way you build and develop and deploy cloud applications. It's this emphasis less on infrastructure and underlying machinery that you use to build applications and more on the value creation that organizations must deliver to their end users. And so serverless to me is really about developing at the speed of innovation.

Viktor Farcic 4:45
I'm gonna say that I kind of like it, what you just said, because what I feel is that, you know, because the first successful implementation, or widely used implementation of serverless were related to functions, right? So, now when when people say serverless, they really mean functions. And when they say functions, they mean serverless. And I have the feeling that there is this myth that some kind of misunderstanding of what serverless is. And I, I don't see it as being functions, maybe functions can be a flavor of serverless. But functions being serverless, kind of putting the equal sign between the two to me sounds a bit strange and maybe the wrong path that we're taking.

Rodric Rabbah 5:35
I agree. And in fact, you know, when we talk about, you know, my company, and in the conversations we've had with a lot of early adopters and just potential customers, that notion of Functions as a Service really was a distraction, because I think it put the emphasis on the wrong part of serverless. And when you look at organizations that are still trying to figure out how to move into the cloud, and they're just learning about containers. They're learning about Kubernetes. And you say, forget all that. There's this alternative functions model and you should just go to that. It's very disruptive and it's a high cognitive load. And when I talk about serverless, I don't like to mention functions of service at all. Because like you, I believe it's really just a building block in a larger context. A function by itself isn't an application. At Nimbella, we aren't a functions provider. We are serverless cloud, as we say. And I think in some ways, this Sorry, go ahead. You had something to say there.

Viktor Farcic 6:35
It's okay. Continue.

Rodric Rabbah 6:37
Yeah, and I think, you know, the emphasis on functions really misses the boat, because as I was saying earlier, it's about the transformation. And if you're talking about moving into the cloud era taking applications, you have to go through a path that has to be a gentle migration path, one that includes containers, one that includes a path where you re-architect the application, because by the end when you've adopted a serverless model, you've re-architected your architecture, you've re-architected the application. It is no longer the same application if you've done it right. And so that transformation has to have a broader view and not just a single minded focus on Functions as a Service.

Viktor Farcic 7:13
Actually, I would go even further, more radical view is that I cannot imagine a serious company transforming significant workload percentage of a workload into functions. That, to me, just simply sounds unrealistic. Yeah, I mean, I'm not saying there is no place for functions. And I'm not even talking about serverless now, but kind of, you know, developing something that is 50 lines of code. That simply sounds unrealistic to me, because then if we take a serious organization and say, some kind of enterprise, and then I say, okay, let's transform zillions of lines of code into functions that simply... I don't see it happening.

Rodric Rabbah 7:56
Absolutely. And if you look at some of the architectures, that organizations that have gone through some of their serverless journey and they've published essentially their architecture, you look at it and you know, if these are on Amazon Lambda, you know, the Lambda is a tiny part of the overall architecture. I think it serves a particular purpose. But applications in general have more components. There's, there's the compute, which is what functions give you. But then there's a storage, there's the event architecture, there's the bus mechanisms for communicating between things. And there's many different components that wrap around, just to compute. And I think you know, why it's not just functions is if you look at what a computer is, it's not just the core CPU, it's the memory around it. It's the interconnected buses between them. It's the memory hierarchy. It's the network. There's lots of things that make up a computer. And just like that, you know, if you think of the cloud as a new supercomputer, that just happens to be serverless because somebody else is managing it, then you have to look at the totality of what it offers. And it's not just functions.

Darin Pope 9:01
So let me ask a question. Because what if everybody thinks that lambda is the right solution, is there is there a use case that the lambda-like things truly solves?

Rodric Rabbah 9:22
There are. And I think you have to also take that in context. So I think the use cases are largely around reactive events. And I like to think of lambda and functions of service as providing a actor oriented programming model that's now living in the cloud and easily accessible. And you look at the use cases that functions have been used for. Whether it's for offline processing and synchronizing, you know, data buckets, across regions or across clouds, computing thumbnails, implementing REST API's. There's a number of use cases for which lambda is really well suited for and the growth that it's had over five years is incredible. I think it's exponential growth. I remember at the first serverless conference five years ago where I met Dr. Tim Wagner, who's considered the inventor of Amazon Lambda. And I had asked him, you know, how many lambdas are you processing a day, and I remember the number it was 2 billion lambdas a day. And you know, last year, that number was over 2 trillion. And that's incredible five, you know, an exponential growth over that period. But it's a tiny fraction of all the compute that's happened in the cloud, which is still happening over servers, EC2 instances, increasingly containers in Kubernetes. So there's a lot that lambda hasn't actually been used for. And the place where innovation is happening today on figuring out what can use this programming model for for which it wasn't necessarily intended, is being done. I mean, there's lots of academic papers that are coming out on doing video processing on doing rethinking how you actually build your Linux kernel, for example. That's using this power of the cloud with functions. And what it will lead to, in my view, and why I think, you know, it's a building block is new abstractions and new models that lift and raise the model of computing the programming model, essentially, that's available to developers. So more and more functions play an important role in what overall architecture becomes. But to build larger applications, you need to build new abstractions. And that's not I'm not saying anything new in that, that move to increase abstraction, and increase automation is ingrained in the history of our computing, where you start from mainframes to infrastructure as a service platform as a service. And really, if you're looking at any, any aspect of computing, there's a vertical stack and we're increasingly moving up it.

Viktor Farcic 11:50
behind the scenes, right. The future of serverless is likely some form of containers, some form of scheduler that does all the good things. For you, in a way, right? Is that how you would see it? Or

Rodric Rabbah 12:05
I actually think it's more of a continuum, right? Where your code runs, isn't necessarily all about containers. And I think there's a continuum of technologies that can be used depending on the context. And it ranges from containerless functions, running in things like V8 isolates, or similar technology, unikernels, containers, micro VMs, or maybe just proper containers, depending on the profile of the function. Do you know that it's actually stateless and well isolated? In which case, you can get much more compute density as a cloud provider by running it in a different context that isn't necessarily containers. But keeping with the serverless methodology, right, that shouldn't be an optimization that developer makes. It's part of the optimizations and the runtime orchestration that the provider makes, right. So it's the Amazon that does that. It's Google, it's Azure, it's IBM, it's Nimbella. And that's actually what we do. at Nimbella, in fact, I'll just call out one optimization, which is you can start with a function. And we promote it to a container, actually making it more visible as a container, under certain use cases where you need more sustained load. And it looks like its profile starts to look like more of a long running micro service. But that's an optimization that happens completely independent of what the user's intent was. So that's my view, I think there's a lot of technologies of which we are on containers and very container centric today. But if you look at technologies coming out from CloudFlare, and Fastly, where it's edge computing, different performance profiles running in isolates, there is a continuum there and for the right use cases, you want to use the right underlying technology.

Viktor Farcic 13:49
So what's kind of the the type of involvement that you would expect from let's say a developer right? There is the obvious here's my code, run it, right. But then I guess you need some a bit more than that kind of this is the type of application something like that that would allow the provider to choose what is the right strategy. Right?

Rodric Rabbah 14:13
Yes, I think the holy grail is really a way to understand that is to look at what's happened in parallel programming or programming for distributed machines. Right? The Holy Grail of parallel programming is you take a program and a compiler, partitions it and then runs it on, say, a multi core system creates all your threads handles all your locking, etc. But that was incredibly hard to do. And, you know, we haven't solved that problem. What happened with serverless computing and what's happening with the availability and the commoditization, if you will, of Functions as a Service is that you now have a computer that is distributed by its very nature, and it's flipped the programming model around. It suggests that to take advantage of this cloud, you have to build small functions and run them in the cloud. But by virtue of doing that, there's a lot of optimizations and a lot of metrics that the vendor can collect about the optics, about the execution of the application. So it just begs for machine learning, optimization analysis and feedback directed optimization to say, hey, there's correlation here between functions that are running together. Maybe I should fuse them and run them as a larger monolith, if you will. And it's easier to go from smaller functions into coarser applications than the other way around. And so I think it would be ideal if the developer didn't really get so involved in saying here are the directives I want to provide for how you actually execute my code. We are not there today. And you see this in a different technologies that are available. You know, if you run on lambda today, if you want to run a stateful lambda, you use their model that says run this with concurrency limited to one and that gives you sequential execution. If you're using technology that is more Kubernetes based like Knative or OpenFaaS, then you're providing sort of your minimum replicas, your maximum replicas. And that's a bit more cognitive load that the developer has to think about. Apache OpenWhisk, which is technology I helped develop is more like the Amazon lambda model. You just run and the scalability just happens for you. You don't think about specifying minimum or maximums. So so it's going to be a delicate balance between how much the tools can take in as directives and knobs and what the programmer can actually wrap their head around to provide as input to the platform. But I think we're still in the very early days. This is like when the mainframe was invented and Fortran in the 1950s. I think there's incredible innovation happening in industry. It's happening at a very fast pace. And the solutions that are coming over the next few few years, I think will be incredibly transformative.

Darin Pope 16:58
Listening to what you were just talking about a couple of things stood out to me. One was, especially the way that Nimbella is doing it. I, as a developer, could care less about how it runs.

Rodric Rabbah 17:19
Right

Darin Pope 17:20
It is just, here's my code, go take care of it. But you had also mentioned earlier on, that the developer has to think differently when they're developing. What is that shift? What is that shift that a developer has to make? Because I could say, again, as a, somebody that's been working with Spring Boot for 20 plus years, almost, or Spring, I should say Spring Framework. I really shouldn't take Spring into serverless. Now we can argue that but I'm just gonna make it make a broad statement there. How does a developer have to change how they develop?

Rodric Rabbah 18:02
It's really about thinking of your application in terms of its logical blocks, and what is its architecture. And if you think about your architecture, you know, you draw blocks on on a whiteboard or on a piece of paper, you draw boxes, and you draw edges between them. The boxes represent some notion of compute. The edges represent data flow or communication that has to happen between them. And I think if you push this to the extreme, this is essentially what a serverless architecture becomes. It's the consumption of API's that exists in the cloud. It's surfacing new compute, and new data services as API's themselves. And then the application and the architecture essentially becomes a synthesis of the data flow over all those API's. And this is my view of that shift that has to happen from existing application development, whether it's a monolith or functions as a service towards a transformation in, in a serverless sense, where you're largely consuming API's and functions are API's, I think there's a duality between functions and API's. So it's really about that synthesis of data flow and composition over those API's that really represents the application. And if you lay that down, you know, in two dimensions, you know, it's looking at an architecture. It's a data flow graph. And I think this is what's difficult to actually do for most developers, because you're not trained, generally, to think in that way. You know, our programming languages don't push us to think and develop in this way. But that has changed, right? The rise of functional programming as more mainstream has occurred. Whether it's in languages like Scala and their adoption, or the introduction of various models in Go and Golang. That shift is happening. And so it's going to make it easier, I think in terms of thinking about that kind of data flow and synthesizing applications as architectures that way.

Darin Pope 20:03
Let's assume that's true and the developer understands what they need to do. Most of the time, at enterprise level, the developers are not making the decision what to build. It's coming through project management, it's coming through whatever. It almost seems like solving basically, that reprogramming of business analysts and project managers is going to be tremendously harder than retooling the developer.

Rodric Rabbah 20:41
I agree and I think this is why you also need a gentle migration strategy for organizations where they already have applications running. And you know, even if they're committed to being cloud first and shifting and modernizing their stack, that can't happen overnight. It requires training. It requires an acceptance of essentially a commitment to this re architecture. And it doesn't happen overnight. And so I see a path where eventually you will be serverless. And companies like ours are about looking at how do you compress that time of migrating from existing applications into the cloud, but also about looking for your design methodologies for developing new applications. You can't just look at existing applications, but there's new innovation that's happening. And so it's easier to do it for new applications. And that transformation has to be bought in from the top down and the bottom up. It's just like agile. You can't just say we're agile. You have to become agile and has to be indoctrinated and has to be part of the company culture. I think serverless is exactly the same way.

Viktor Farcic 21:49
Is it a very similar. So if I take Kubernetes as example, right? You need to develop applications in certain way to benefit from using Kubernetes, right? We probably all agree on that. But on the other hand, you can also have that kind of transition period, where you throw into Kubernetes whatever you have, you're going to get 5% of the benefits. But those 5% are still tangible, right? Are we looking into something like that with service as well? Is it kind of to get the benefits you need to do things certain way. But you can benefit partly without, or really applications needs to be...is it a requirement for applications to be designed certain way to be serverless?

Rodric Rabbah 22:36
Right. And what I'm saying is exactly what you just said. It must be part of the equation to have this gentle migration path. You're just not going to be able to take applications and transform them overnight. And some things you just might not be able to do. You know, it's just impractical or prohibitively expensive. So you must be able to have a model where you know, Kubernetes raises the level of abstraction. You don't have to think about restart policies. You don't have to think about what happens if my application dies, how my persistent volume is managed, etc. There are things that are automated at the infrastructure level that free you up. And so that's, you know, if you think of serverless as a continuum, maybe that's a little bit serverless. And it has to be, I think, you know, when you're looking at adoption at enterprise, whether it's big or small, that have applications that they're running already, you just can't stop and say, let's re architect everything. It's too expensive. So you have to provide a migration path. And I think that's why Kubernetes is so attractive. It's because it gives you part of that path and gets you into the cloud faster. Right? I think the goal should be for all organizations to essentially just adopt cloud because of the benefits it offers, not just in terms of, you know, re-shifting the investment that you're making within the organization, but because of the tangible benefits that developers eventually are able to extract from it. And that's why in whatever capacity serverless is inevitable, it has desirable properties. And it's happening. It's just a matter of how fast can we get there for the full transformations, in some cases, that might be necessary. And if you look at what Vanguard has put out in terms of how they're doing their digital transformation, they had exactly this problem to solve. And their first goal was, let's just get in the cloud. And so for that, they had to shift and lift and Kubernetes and VMs played an important part of that, before they were able to adopt lambda.

Darin Pope 24:30
So we're talking about most of the things we've talked about most of the time you hear serverless you think state less. Now lambda just introduced EFS integration. Not sure how I feel Actually, I know how I feel about that. It's not positive. But it's just because it's EFS. EFS has performance problems in general. But the concept is fine, right? I get the concept. So it's not a big deal. And one of the things that Nimbella solves, if you will, is actually it's it goes beyond the functions and goes to full applications and not only full applications, but stateful full applications. That seems impossible.

Rodric Rabbah 25:19
Right

Darin Pope 25:20
Why the heck did you want to try to solve that one? Because that to me, that sounds like okay, this should just run in Kubernetes. This should just be on VMs. Why are you trying to solve something that has good solutions today?

Rodric Rabbah 25:39
Right. So let me clarify. We haven't solved the problem completely. I think we're just scratching the surface in what we've done. And I think the value in what we're doing is twofold. One of them touches on sort of what lambda or Amazon has announced with their elastic file system support to build applications. You know, I started by saying applications aren't just functions. And interesting applications have state. And there's many forms of state. And you look at, you know, the kinds of things that you would do in an application. There's things if you're building an API, and it has a front end component and a web component, you need storage. But the kinds of storage that you need are different. So if it's an application that has a front end UI, you upload those assets to an object store, and then you serve them from a CDN, a content delivery network. That's one form of storage. If you are handling session state, or transient data streaming properties, you might use a key value store. If you are handling files, and your application needs to process images or PDFs, etc, you need an object store. And then there's databases and many different forms of databases. And then there's a file system. So we focused on a subset of these. With a Nimbella account, developers can build essentially a front end and a back end application that's stateful. And what that means is every Nimbella account right out of the gate, you sign up within 60 seconds, you can build an application that allows you to upload assets to a CDN, be able to take advantage of an object store, and be able to take care of transient state and streaming data through a key value store. We are working on a similar kind of technology to EFS, where we have a file system abstraction that's backed by object store. And there are applications for which this makes sense. For example, if you're doing machine learning, and you have a model that you've trained offline to be able to recognize and label images, loading that image loading that model could be very expensive. You store it in an object store, for example, and lots of examples today do that. And if every lambda and if you're using serverless with functions to do this, then every function has to load this model. That's an expensive operation. Because you're using serverless, you don't know where your functions run. You have no notion of locality. And that's where something like EFS actually comes in, in that now you can store it and share those across functions. This is an optimization we've been working on at Nimbella, where, you know, you can have thousands of functions running. They all share essentially, this reference to the object store that has your, your, your model that you've pre trained, but you don't have to load it repeatedly, because the system has taken advantage of caching the file and mounting it inside every container that's running your function. And so it's a file system abstraction over object store. And you can say, you know, in large parts, what we're doing is we're storing data locality, to compute. In serverless and in containers as a service, you don't have locality. You don't know where your functions are running. You don't know where your containers are running, but you need access to data. And so if you can compute if you can co locate compute and data close together, then you have sub millisecond latency. You can take advantage of system level caching to help you reduce costs. And what that translates to is better application performance. New capabilities, lower costs. And there's value in doing that. And that's what we set out to do in Nimbella and what we've been able to do. And the way we're doing it is a combination of commoditizing the underlying clouds that we run on. We are running on Amazon. We are running on Google Cloud. And we're taking advantage of the services that they provide. We're not trying to recreate those services. But in some cases, we deploy, you know, a key value store that's unique to a particular tenant, because the performance characteristics required. And so functions and key value store like Redis, for example, are co located very low access latency, and that gives you new capabilities that you could do. And if I get back to sort of what serverless promises, which is, you know, freeing the developer from having to think about various things. If you just want the concept of a key value store, you should just be able to use it. Not think about where it's provisioned, how it's provisioned how it's backed up. And that's part of what we're trying to do. It's provide this programming model backed by underlying cloud technology that allows us to sort of broaden the set of capabilities that not only functions could do, but serverless programming in general allows you to do. That's not to say you're going to take a database and build it in this way, right? There are fundamental technologies that are sort of just primitives that the platform has to provide. And then there are capabilities that you can't do at user level. You can't optimize, you know, your cache, and your compute, because Amazon doesn't give you access. These are things that the underlying platform has to do, and that's what we are doing at Nimbella. Did I answer your question?

Darin Pope 30:47
Yes. I have one more question. So this this is gonna be a very pointed question, and you can choose not to answer it and that's okay. If I sign up for a Nimbella account, I create my front end app, I create my back end app. If I understood correctly, I have no idea where that is running. I could figure it out based on IP address when I hit endpoints and stuff like that. But, you know, besides that, there's no way to know. And based on what you're saying, I should not care.

Rodric Rabbah 31:20
You should not care. I think that's if we can deliver on that, then we've succeeded. The underlying cloud is completely commoditized. It's democratized. And we've made the cloud accessible.

Viktor Farcic 31:31
Theoretically, I, as a developer, I wouldn't even necessarily need to know whether it's Amazon or Google or Azure, theoretically. Not necessarily today, but I could even say run it wherever it makes the most sense,

Rodric Rabbah 31:47
Right. And today, if you create a Nimbella account, you'll be able to quickly tell where we're running. We're primarily running on top of Google Cloud. We are live in two clouds today. Amazon and GCP for various reasons. We tend to favor GCP at this point. Largely, it's a cost optimization. But that's the cost optimization is precisely why as an end user, you shouldn't care. There's lots of things you could do at the low level to figure out, you know, should you run on this cloud or the other cloud and take advantage of different arbitrage, spot instances, etc. for different workloads. It's not the kind of thing you want developers to worry about. That's what the system providers should should offer to you. As an end developer, I deployed my application, whether it's a Jamstack application, or a chatbot, or mobile application, and I just want it to run. I want it to be available. I want it to scale. I want my cost to be well bounded and defined so I can budget. And so how the underlying architecture is running, where it's running, how the data is backed up, etc. These are all the things we're aiming to essentially save developers from. And I think that's part of you know, what offering a serverless cloud and serverless experience is all about.

Viktor Farcic 33:00
So what is cloud? Just to clarify, Rodric`, when you say cloud, what do you mean by cloud?

Rodric Rabbah 33:07
I mean, I mean, the public clouds. I mean, running on somebody else's machines as opposed to your own data center. I think if you've already moved to the cloud and you're running in a VPC, you're a step ahead. But there's lots of organizations that still believe in operating and running their data center that have their own workstations. And I think part of the migration that needs to happen for the cloud era is moving a lot of that. The other is could mean sort of looking at adopting more and more of the native services that exists in the cloud. But I think that's a digression and goes towards, you know, portability and vendor lock in where Kubernetes really starts to offer some some advantages.

Darin Pope 33:51
My company will not go to cloud, because fill in the blank

Rodric Rabbah 33:55
right

Darin Pope 33:56
We can't because we're regulated,

Rodric Rabbah 33:57
right

Darin Pope 33:58
We know that's false, but we'll go there for a minute. So how can Nimbella help me there?

Rodric Rabbah 34:04
So Nimbella is built on open source technology. And we have actually had conversations with regulated industries, for various reasons. They are at different points in their cloud transformation. And what's resonated for them about our technology is that we can essentially replicate much of that experience with respect to the developer experience in their organizations on their infrastructure. And we can do it in two ways. One, if they've already adopted Kubernetes in house, then we just extend their Kubernetes clusters, essentially, with that developer experience. It adds on top. Or if they're still on VMs, we can deploy Kubernetes for them, and then lay out a Nimbella stack on top of it. And that's part of essentially a gentle migration strategy of modernizing the development stack for an organization on prem. And it has to continue. I think it's more important for those use cases to deliver that gentle migration approach. Because if you haven't even adopted cloud, all of this is not just transformational, it just looks impossible. And, you know, part of what we've been trying to do is say, well, we can extend that experience for you onto your infrastructure. We can train you on how to operate it. And because we ourselves are a small company, we've built incredible automation systems self healing, you can operate it with a small team. And now you can free up you know, large parts of the infrastructure team to now go and become developers or innovators that add value to your organization. So there's a number of possibilities there with respect to Nimbella and I think this is where you know, a lot of the interest in private cloud or in hybrid cloud really comes in you know, with OpenShift, Knative etc, is really about doing some of that.

Darin Pope 35:51
So basically, now this may be oversimplified but it's basically if I'm on prem with my approved version of Kubernetes I'll throw that in there, at least one that's you at least tested. It's basically nothing more than a Helm install. Is that it?

Rodric Rabbah 36:07
We don't use Helm. We use kubectl and we built our own Nimbella administrator CLI for that. There's there's a number of reasons technical reasons for why we didn't do that. And being able to address all the variabilities between different Kubernetes installs that we've had to do, dropping down and just using the underlying kubectl commands directly was necessary. So it's not it's not as easy a Helm install, but we do have a one click install. You install the Nimbella admin CLI, you point it at your Kubernetes cluster and you just say deploy. And off it goes. It takes about 15 to 20 minutes depending on various setups, and then you have the exact experience of a Nimbella cloud that we host available to you. That's part of where we are on on on prem strategy.

Darin Pope 36:59
So if people wanted to find out more about Nimbella, what's the best, best way to find out?

Rodric Rabbah 37:06
Go to our website, https://www.digitalocean.com/products/functions . You can message me on Twitter @rabbah. We've been putting out a number of blogs. I think we're just slowly really starting to talk about the platform very publicly. So there's a lot of content that will be coming out over the next few months to show and showcase the value proposition of the platform. But our website is sort of the one place where you can sign up, you can register for our newsletter. We're on the second issue which just went out yesterday. You can get an account like I said, within 60 seconds. If you don't succeed deploying your first application within 60 seconds, I'll send you a hoodie that you can wear in the winter.

Darin Pope 37:45
I wear hoodies year round.

Rodric Rabbah 37:49
They're really nice hoodies because I wanted to wear one so I design really good ones.

Darin Pope 37:53
There you go. Well, you're you're based in New York. So you actually have real winters.

Rodric Rabbah 37:58
we do

Darin Pope 37:58
so you need a real hoodie.

Rodric Rabbah 38:00
Yeah, maybe we can get t shirts as well. I'm sure we have plenty of t shirts we can send out.

Darin Pope 38:04
Hoodies are always better. Because you can always take them off. Right? But you are at what is it? You can always put layers on but you can always take layers off. Right?

Viktor Farcic 38:13
Where I come from, you take off your t shirt without a problem.

Darin Pope 38:20
Okay, cool. Anything else that you'd like to sort of wrap up with today, Rodric?

Rodric Rabbah 38:24
No. This was really nice. Thank you for giving me the opportunity. You know, the way the way I I met Viktor was about I learned about the book that you both are writing. So I'll give you a shameless plug for your book. It's really good and especially the serverless chapter that is a work in progress, but I've read the early parts. I think I'd recommend it to everyone. It's really good stuff.

Darin Pope 38:44
Okay, so you're still here and we're sort of wrapping but I'm... You told us before we started recording that you disagreed with us on probably a few more than one thing, but what was the biggest thing you disagree on?

Rodric Rabbah 38:59
The Kubernetes aspect. I think there's no k in serverless. And that goes for anything Kubernetes related. And what I mean by that is I don't think developers should be exposed to Kubernetes in any way. That That doesn't mean, it invalidates what I just said, because I believe, as I, you know, we discussed in the podcast about gentle migration, etc. and Kubernetes is a fundamental part of that. But what I think is important is really raising level of abstraction. So you don't even have to think about Kubernetes. And, you know, in, in the book, and in a couple of your podcasts, you know, it's a lot about Kubernetes. And I think, if we're successful as an industry, right, that fades away. And I think that's really the part of what we should be striving for.

Viktor Farcic 39:47
Yeah. So the part that I care about, to be honest, I do believe that Kubernetes will one day become transparent. It will disappear. Actually, it will not disappear, right. But it will just not be something we think about. Now, the reason why I care deeply about Kubernetes is that it is the best path forward that we have as industry to establish some form of a standard, right? So for example, to me Knative, I love Knative. And not necessarily because I want to run Knative myself, but because it has a possibility to be some kind of standard. What I'm really trying to say that I would like to see the world where I say, Okay, this is let's say, this is my, this is my definition of serverless application, whatever it is, right? And then you and you and you compete, who is going to give me better service and all those things, but I will not need to design my application for lambda, or for Azure, this or for right, so I'm looking for some kind of standard that would become a common denominator right? So that everybody competes in who's going to give me a better service, not who's going to force me to do things in certain ways so that it fits a certain model.

Rodric Rabbah 41:10
Right. And I think that's going to be important. And I agree with that. I think the reason I don't view Knative as being able to succeed there is for them for Knative and the serving layer in particular is what I'm talking about, to be able to deliver the performance that's needed for short running functions, not long running, or even medium running functions. They have to push some of that technology into Kubernetes itself. I don't think Kubernetes was designed to be able to churn through millions of containers or billions of containers a day. That's just I think it's just not the right technology for it. And so Knative can't do that from the outside, it has to push in. And then within Knative itself, there are efforts to sort of look at, you know, what do you come up with in terms of standardizing at least on the function signature when you're talking about Knative serving for functions. What Kubernetes has done in my view is standardize the packaging and deployment model, right? You package a container, you deploy it. And now there's various things you can rely on. Where I see more to standardization that you're talking about being relevant is higher up the stack. It's something like the cloud event spec. It's here's how you consume and stitch together API's. I think we're still a bit far away from that before it happens. But when we succeed, you're right. I think Kubernetes fades into the background as well.

Viktor Farcic 42:29
Yeah, I mean, I use just to clarify I used Knative just as a first example that came to mind, it really can be whatever that it's like. That's why I see. That's why I'm much more inclined towards container as a service than function as a service model of serverless. Simply because at least I have that common denominator. Maybe I will need to do extra things. But my common denominator today is a container image kind of, that's some kind of standard, okay, I will need to write some JSON, Yaml, whatever depending on the provider, but at least we agree that container might be or not, right? It might change. But I like the idea that there is a certain, I'm very fearful of any type of lockin, you know, kind of like,

Rodric Rabbah 43:15
I think it's more than just a lockin right. There's important things that, you know, packaging as a container does for you. You know that when your code is packaged into container, it will run the same on your machine and in the cloud. You can't do that when you're packaging things into a zip file, right? You have to be ABI compatible. You have to write the right dependencies that, you know, the cloud providers runtime is giving for you. So it's more than just it's it's fundamentally more in my view. There's also the other aspect, which is debug ability, right? If you have a container you can attach, you know, your debugger to it and you can step through your code. When you're running as functions, debug ability is impossible and you're back to you know, printf being your way of debugging. There's innovation happening there. But there's a lot of tooling that has to happen. That's more mature. When you're talking about containers, than you're talking about than when you're talking about functions. And in the end, if you just focus on just a packaging format, I think it's still too low level. Right? You need to keep pushing up the stack. But I think you agree with that as well.

Viktor Farcic 44:20
Yeah, yeah. It is definitely to all levels of just referring. The other day, I was trying to imagine what is the highest possible common denominator today. And that's a container. It's not high enough. I do believe it's not high enough for but it's what we have today, in a way. And honestly, if somebody would convert my container image into a VM tomorrow to run because that's better, I don't really care anymore. I'm giving you an image, right, that that's what I'm giving you. It's your problem, how you run it.

Rodric Rabbah 44:50
And what's happening with you know, Knative, we've also built our own service on Nimbella, a build service is that if you are starting with functions, and you just want to you know reduced the users code to just their code, you have to be able to take that code and build it remotely for them. So you have to offer a build as a service. And so that's part of the tooling that has to come up and mature for, you know, the cloud vendors to be able to change the packaging format, from containers to something else that can become a standard. And then specify, you know, specify what are all the restrictions, etc, it just becomes harder. Container, in some ways solves that problem. I really like what Google did with Cloud Run, because it's kind of like the functions experience where you container starts and stops. You have per activation tracking, essentially. But it's a container which is nice and easy for people to get their head around with respect to packaging and what you have to do. So I like that model quite a bit. And that's more of container as a service, if you will, as opposed to functions as a service.

Darin Pope 45:52
Okay, let's stop there. Because we could go for another hour talking about those kinds of things. But I did want to I did want you to have your say of why you disagreed with with us. But in the end, we're I think we're more in agreement than we are in disagreement. You're future looking. We're 12 months looking. Right. So that's what I'm saying is I think further out, we're both in agreement. That, yeah, we shouldn't care about Kubernetes in five years. We shouldn't care about how it's packaged. What I care is, here's my code, go run. Right.

Rodric Rabbah 46:28
Right. On that note, I agree. Yep.

Darin Pope 46:30
Okay, cool. Thanks for hanging out today, Rodric. Talk to you again.

Rodric Rabbah 46:34
Yeah. Thanks for having me.

Darin Pope 46:38
We hope this episode was helpful to you. If you want to discuss it, or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.

GCP Podcast - Serverless Made Easy With Nimbella

Show Notes

Links from the episode

Guests

Rodric Rabbah

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript