 From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020, virtual brought to you by Red Hat, the CloudNative Computing Foundation and ecosystem partners. Welcome back, I'm Stu Miniman and this is theCUBE's coverage of KubeCon, CloudNativeCon Europe 2020, the virtual edition. Of course, this ecosystem has been bustling a lot of activity in the five years that we've been covering it with theCUBE. We've watched very much the maturation of what's going on. I remember in the early days, it was open source projects, companies pulling all of the pieces together. Now, there's a lot more things to choose from lots of projects, not just Kubernetes, but all the other pieces and still lots of new innovations and new startups coming into the space. So happy to welcome to the program, I have two first time guests from SpectroCloud. First of all, we have the co-founder and CEO, Tenri Fu and also Tina Nolte, who's the vice president of product, Tina and Tenri. Thanks so much for joining us. Thank you for having us. You're welcome. All right, so Tenri, as one of the co-founders, I want to understand, you know, why SpectroCloud, why now, you know, many outsiders would say have said for a while, you know, Kubernetes, it's just getting baked into all of the environment. They looked at all the platforms, whether you're talking, you know, Google and AWS or VMware, they all have their platforms, they all have their managed services offering. So help us understand what your team does and how you differentiate from what's already existing. Absolutely, yeah. So I actually used to work at VMware, right? And that I saw clouds taking off, right? And then I left VMware, start my first startup called Liquid Technologies, which focused on multi-cloud management. But at that time, really multi-cloud management through a single pane of glass is the only thing you can, right? And then clicker later got acquired by Cisco. So at Cisco, I kind of witnessed the container and the Kubernetes taking off, right? And it makes a lot of sense, right? For the first time, both the application workload and the infrastructure become truly portable across multiple environments. But also very interestingly, at Cisco I observed, there are many developer teams, right? That does they adopting Kubernetes and everyone is doing a little bit differences that because different teams, they have a different stack and structure of common, right? Some for AIML, some, they need a different base OS, some they just don't want to have a different version, right? And a lot of existing solutions doesn't really provide this kind of a flexibility to satisfy all the different needs, right? One side fit all typically is one side fit for nothing. So we ask ourselves, why can't we try to create a platform that will give people the flexibility, but not turn it into a DIY project, right? Still have a full manageability so that user don't need to worry about the upgrade, data operations, governance, so on, so forth. Tina, I know when I've looked at your product, it's discussed as layers, which my background's in networking, so I love seeing things visually and understanding the pieces as they lay out the stack. So maybe help us understand a little bit as to, that flexibility that you give and how it's not just the paradox of choice, just too many options out there and developers left to create their own mess that they can't then support. Yeah, so, as Tenry mentioned, offering folks flexibility without turning into a do-it-yourself hot mess is what we're helping people do at SpectroCloud. The core of our solution, the core of the differentiation within our solution is around this concept of a cluster profile. And as you mentioned, cluster profile basically allows people to define in a layered fashion what's part of their Kubernetes infrastructure stack. So at the bottom, you're talking what's the base operating system? What's the version of Kubernetes that's gonna be part of clusters that uses profile? What's your networking and storage interface look like? And then on top of that, you have a number of optional layers. So again, back to flexibility and manageability, we give people options around what those other layers look like on top. They include everything from security, logging, monitoring, et cetera. Just anything that you want to go ahead and kind of bake into a definition, a profile of what a cluster should look like in one of your deployed environments. All right, want to make sure I understand when you talk about Kubernetes in there, can it be, say VMware with vSphere 7 now has Kubernetes support. Red Hat OpenShift is an option. All of the cloud players have their AKS, EKS and the like. Can I bake that Kubernetes in or are you taking a different approach? We're going with upstream vanilla Kubernetes today. That allows us to go ahead and provide what's newest within the ecosystem and let people go ahead and have a really open solution that they're applying. Okay, so when you look out there, a lot of companies are saying, how can I manage multiple clusters? So if you look at what Google, Microsoft and VMware, they're talking about we can manage our clusters and we can also help you with those other clusters. How does that impact, Tenry, your solution, does it need to be, it's just the upstream solution that I put into that cluster profile or can I connect to, say, a managed cloud solution? Yeah, so I think in terms of multi-cluster management, the consistency is really the key. So through this cluster profile concept, not only it can be used as the initial template to deploy cluster, but it can also use as a single source for truth to drive the cluster lifecycle management in terms of the upgrade. So right now, as Tina mentioned, we primarily focus on upstream whether we want to provide the maximum flexibility in terms of end-to-end Kubernetes stack. But we do also have a plan that down the road that we go into import Brownfield existing clusters so that enterprise existing investment to their Kubernetes infrastructure can be under managed by us as well. Well, there always reaches a time when the brand new technology gets called Brownfield. I think that's the first time I've heard something like EKS or the like referred to as Brownfield. Tina, when I think back to my history with integrated solutions, obviously if I have the various pieces, it should be easier for me to stand the latest, make upgrades, roll things forward or roll things back. But give us if you could some of the key values of building these cluster profiles, what that enables for your customers. Yeah, so the key around cluster profiles, we offer this policy-based management. So you describe as an administrator what it is that those clusters need to look like, right? And we adopt a declarative desired state, management approach along what Kubernetes does itself. And so what you're able to get through adopting, utilizing cluster profiles is this guarantee that from deployment and then into day two as well, what you've described in this profile winds up maintaining itself. It remains true of the clusters that have been deployed. So what it is that you require as far as the operating system, what it is you require as far as some configuration options, et cetera. So the profile itself winds up being ground source of truth around what it is that you've got running in all these various locations across clouds, across different clusters, et cetera. All right, Tenor, you mentioned that having things more standardized is going to help customers. Absolutely, we saw that in data centers for a long time and standardized. How do you help customers make sure that the configuration that they build are going to work or going to be stable if they make changes that they're not going to get things out of sync? Is there interoperability matrix or some other ways that we're trying to make sure that customers stay on the rails, if you will? Absolutely. So through our system, all the integration points, we carry the additional metadata to basically give the hint about the compatibility, resource constraints and also the upgradability in terms of moving from one version to another. So this way we can kind of give user some guidance when they initially construct a cluster profile on what will work together nicely and what will not. And then on top of that, when upgrading from one existing cluster to a newer version of a cluster profile definition, then we can look at the environment to understand if there's something that potentially incompatible with popping up. So we call that a pre-pilot integration check. And also post-deformant, we also allow user to run additional conformant tests so that make sure the cluster, everything is actually still acting as it's supposed to be. Another way to explain that is that the cluster profile concept has a lot of flexibility attached to it. That's a lot of power it can get you into trouble if you don't have the right safety nets and safety harnesses underneath you. So we have a multi-layered approach to helping make sure that people are getting benefit out of that flexibility. Wonderful, and I'm wondering when you've had more customers using this, is there shared information and their community guidelines that help understand when it's going to be okay, hey, 1.19 is out. We're looking at 1.20, you might want to do this, or hey, if you're using this piece of networking, you might want to wait a little bit before you go to the next version. That's definitely the idea over time. Folks that are engaging with us are very interested in the fact that because of the fact that we're a SaaS management platform, a SaaS based management platform at least today, that it offers up the opportunity to learn from their peers, if you will, right? And their peers' experiences. On top of that, we also have the ability to watch just what's been going on in other deployments in the Kubernetes ecosystem, and we can make sure that all that's available, as Tenry mentioned, in the form of the metadata that's on top of those packs. All right, how about, how do you price this solution? When I look out there, I talked about Kubernetes baked into all the platforms. Oftentimes it can be baked into an ELA. It's part of my just general cloud spend from that platform, so how do you do the pricing and are you plugged into any of the cloud marketplaces yet? Yeah, so flexibility is really part of our DNA, right? So even for pricing, we want to provide the maximum flexibility to our customer, right? So unlike some traditional solution, typically is priced based on number of calls, right? A per year or even number of nodes, right? So we actually price based on number of CQ calls of a worker node under management by hour. So what we call those are core hour under management, right? And then every thousand core hours as one unit, we call kilo core hours. So kind of similar to how electricity is consumed, right? So this way, based on these core hour consumption, we allow user to either pay as you go as a monthly under management plan or you can do an annual commitment plan. And we are in process on the marketplaces. Yeah. All right, how about, we talked about Kubernetes, I think service mesh are part of it. What in this KubeCon cloud native con ecosystem, which projects are the most tied into what you're doing? Anything that Spectre Cloud is particularly contributing to that you can share? Yeah. So our system is built on top of Kubernetes class API project. So we are one of the contributor to class API. We are actively adding additional functionality to enhance class API, especially, right? In some of the VMware environment for some customer use case, such as a static IP or some special placement behaviors. And also adding additional contribute different cloud support. Yeah. And as far as things that we're watching, and clearly we've seen a dramatic increase in the number of people on our customer front that are interested in actual deployment of service mesh now. So that's something that, you know, we're going to be more engaged in over time. And another one that we're hoping to see check out more talks around KubeCon is AIML, right? A lot of interest in the part of customers around AIML use cases. Yeah, absolutely. Edge and AI and ML, definitely very hot topics of conversation this year at the Europe show. I expect that to continue. Tina, I'm wondering, do you have any customer examples, maybe even anonymized that could kind of just explain the key values that your customers are seeing using your solution? Yeah, sure. So we've got one of our earliest customers is a Canadian financial who came to us because they were looking to figure out how to manage consistently at scale. And they had the problem that Tenorang described earlier around I've got different development teams, they have different needs and how do you satisfy all those guys without going crazy, right? So they've got an AIML use case. That's a special snowflake. They've got two separate teams in different groups that would like to be under an IT management umbrella. That's a convergence use case that they're looking at. So kind of a typical example of somebody that we think of as a really good set of people for us to be having conversations with. We've also been working with a telecom provider that's in a similar vein, actually. There's an AIML group, there are multiple teams of different infrastructure and they want to be able to consistently manage. It's a story that we're seeing over and over again, thankfully. Yeah, we also see, right, from I think at the individual group or gym level, right? There are a lot of kind of a product owner or data scientist, right? They really want to have a kind of an easy button to quickly be able to provision a Kubernetes cluster that suits for their needs, right? And a lot of these groups, their private focus is really their application, right? It's not their interest to spend a lot of time and resource on Kubernetes management into deploying, update, secure and operation. So through us, they can very easily spin up a Kubernetes cluster whether it's for AIML or for developer experiment, right? They can very quickly do that. But with the flexibility, right? Because a lot of existing solution, they may limit the version of a Kubernetes cluster, they may limit what kind of integration they can do. Yeah, Tenor, we talked a little bit earlier about potential integration down the road. I'm curious, just there's so many companies creating innovations out there. Say for example, one that I hear a lot of feedback on is AWS now has Fargate support for their EKS offering. Is that something down the line you should look at? Or do you have some guidance as to how customers should be thinking about that? And if they want that kind of functionality, how they would get that with a solution like yours? Yeah, actually we really share the same vision as AWS, right? So we believe ultimately the infrastructure really should be transparent to application developers, right? And it should be boundaryless. So our goal is not only manage Kubernetes of course multiple implement, but eventually we'll be able to link all these clusters together to make them acting as a single infrastructure. So developers they can still use their familiar Kubernetes interface to deploy and manage the application, but without worry about how infrastructure underneath is operated or managed, right? So this in a way will eventually become kind of a Fargate model, but across multiple cluster and multiple clouds. All right, Tina, maybe if you could give us the final takeaway, people attending KubeCon, CloudNativeCon, what's the one thing that if they have a problem, they should be coming to Spectra Cloud to hear more about? Yeah, sure. So what Spectra Cloud aims to do is help enterprises not have to trade off between flexibility and control of their infrastructure and manage a billion means of use. That's the main thing that we would like people to remember. All right, well, Tenry and Tina, thank you so much for sharing with our community a little bit about Spectra Cloud. Great talking to you and look forward to hearing more in the future. Thanks so much. Yeah. All right, and stay tuned more coverage from KubeCon, CloudNativeCon 2020. I'm Stu Miniman and thank you for watching theCUBE.