for questions so if you have any burning questions please interrupt me if it can wait later and if we don't have time you can talk to me just just after the session there were just outside one minutes okay so it starts again thanks everyone for joining me in this talk today both online and physically and the topic for the next 40 minutes is going to be developing cloud native application with containerized database I'm going to be focusing on the developer experience and the tool sets that is required to do this kind of stuff with a more practical approach where I would go through a demo of the you know let's say Kubernetes specific pipeline right and when I say Coup native this is a talk about Kubernetes like I breathe Kubernetes every day I've been working with it for about six years both on the CNI when I was working at Cisco and CSI more recently I've joined a company called on that where we provide distributed storage for communities so sort of a hyperconversion environment for communities with additional capabilities like replication encryption all this kind of stuff but everything I'm trying to do is always with a developer in mind in particular the DevOps tool sets so I'm not going to be talking about how to build you know the best possible Docker images or using cosine this kind of you know security is much more about the DevOps experience in the tool sets that you can use without leaving Kubernetes but first let's define what is a cloud native application you know quite often we heard we are hearing that cloud is just running stuff on someone else's computer and if you do things like lift and shift well in the cloud that doesn't necessarily mean that your application is cloud native so cloud native means a lot of different things but mainly a cloud native application is an application that is aligned with the 12 factor apps so I don't know if you guys already familiar with this hopefully you are some sort of familiar with that you have the link there and in the context of Kubernetes there are a couple of you know patterns or principle I want to highlight so cloud native application you need to stall the configuration in the environment so we all know bad practices how many developer in the room so some of you are developers right so bad practices in development is hard coding variables or anything you need configuration environments as part of your code right so the idea of a cloud native application is to store configuration in the environment and well with communities we have a lot of option to do so there's config maps there are secrets etc so the first thing to you know to to build to do to build a cloud native application is to remove all the hard-coded stuff from your existing app if you want to walk to build a new one and have this principle that is applied and of course the configuration needs to be separate from from the code then a second principle is to treat the backing services as attach resources loosely coupled with your application or with your code so that means that you should be able to swap quite easily for example if you want to talk to another database using another mailing service another you know another bucket or another other external APIs you should be able to to be you should be able to swap fast and without any consequences in your code right so your code should be implementing the necessary abstractions to enable that then there is this principle which is about executing the app as one or more stateless processes and this talk is also about integrating stateful application stateful components and one of them which just appeared earlier was database so effectively a database is a stateful components of the application but here we are really talking about the expectation in terms of the application itself which is if you do things like you know caching for your sessions this is not a line as part of the application not as part of an external or attached service it's not part or you know you're not aligned with the 12 factor apps patterns this should be part of a external components so it's really about the app itself the core app should be stateless running potentially as you know Kubernetes pods communities deployment this kind of things but however and this is where I want to go database can be run in communities we're gonna see how and what are you know some of the best practices to do so but there are a couple of reasons to do it first well it's collocated with your application so in terms of latency well you're inside the same cluster so potentially same host or worst case scenario same availability zone or potentially same region and if you are in the same data center maybe like a different rack so super fast the other reason may be that you want to leverage the or you know leverage the embedded quality I mean I would say the features of communities things like resiliency the fact that it's completely distributed so highly available all that's our features that are present natively in Kubernetes so as soon as you put a workload in communities you can also with the benefits of the same features another one which is really key is dev prod parity and the idea here is to reduce the gap between dev and prod in terms of multiple angle multiple layers so first people where for a clownative application you should have the same person that's are who are deploying the application in development and in production right this is basically the principle of DevOps it's not like the operational team deploying production and the dev deploying in the dev or staging environment that should be the same you know set of people then also a gap in terms of time changing the code in you know as a developer in your development environment should and then having a lag to production of several months this is not how you build a clownative application this should be more in terms of hours and if you really want to go while it can be minutes with a continuous you know deployment kind of life and then the last one is of course reducing the gap between the environment and this is really related to the notion of shifting left so I don't know if as anyone heard about this term shifting left yes some of you so the idea of shift left is to bring testing as close as possible to the early development stages so it can be test driven or have your own driven as well sync type to check a spot of your pipeline very early potentially involving QA in the design session which may be hard but they may require two very early to test very early so that may be part of the design as well and a good benefit of communities is that you can build on the de facto characteristics of communities and communities the way I like to see it is as a as a platform of course but where you can represent your infrastructure requirements as code or today say as Yama right and then you can use technology like github to even increase the level of security and to have better control to just get as your single source of truth and but it is not limited to Kubernetes objects so I mentioned you know I'm working for on that which is distributed storage company and but there are other open open source solution that provide this kind of features as well and the idea is really to use the CSI driver remember we're in the context of stateful workloads right stateful workloads their properties is really to persist data to disk and what is important is that in case of a node failure the data is not scratch the problem is if you use like a traditional you know basic CSI driver in Kubernetes you attach a PVC to your pod if the node fails where there's no replication for your data so of course this is at the storage layer you will have probably if you're building an application or a database let's say a stateful component you would have replication at the application level right you like for example MongoDB you will have multiple replicas so for sure you can you know base your high ability of based on that but the reality is if a node fails and if you have more let's say if you have a three node MongoDB cluster you lose one replica one MongoDB replica then you need to rebuild the new MongoDB database or the replica you need to rebuild it create a new pod that would be created and then MongoDB has to rethink the data right and this depending on the database size they can take this can take hours and during that time you're essentially running in a degraded mode right so a better ID is to implement as part of the CSI like you will do in your you know very expensive storage array right back in the days you had synchronous replication you had encryption all those features for your most critical mission critical application and stateful application or mission critical so the idea is to bring this into Kubernetes this replication this encryption but because Kubernetes has this notion of infrastructure requirement as code embedded the ID is for this extra features also represent them as YAML as code you want to enable replication it's just a label you want to enable encryption another label right that's the idea and of course if you want to shift left it means well just using YAML for that so as you you're developing the Kubernetes application on your local laptop well you can still use this YAML file you can still have the software that is running in production in your local Kubernetes cluster including this DSI drivers for example and so once this is done once you have an idea of how to implement this you have to define where you want to do it right so if we're not using Kubernetes you can also use cloud native services of course to build a cloud native application right that's the principle so if one moment we don't consider probabilities well you can build things in Google cloud AWS you can build things on-prem with your own toolset but the reality is probably I don't know if your different companies are running workloads in depth so who has always running working in different clouds the different public clouds a couple of just one some so you are for other people it's just single cloud so who's running workloads single cloud okay no cloud at all still a couple okay so the way I see it talking to communities and users is most of the time large companies whether it's because of a merger acquisition or to use a specific feature like if you are a Oracle customer you're probably better run Oracle database in OCI right in Oracle cloud so what I see is more and more there is a multi-cloud strategy not necessarily for higher the ability but for you know more tactical or strategical approach because of all those things that happen in your in your enterprise and that you don't control and it means that in terms of skill sets you have to learn once you have learned how to do it in Google and now you have to do it all over again in AWS well it's you have to learn more stuff so the idea is really to use Kubernetes as a standard or as a cloud agnostic operating system to build your cloud native application regardless of the location can be on premises can be in public cloud it doesn't really matter and the way I like to see Kubernetes because it's this foundational layer I would say it's equivalent to the modern gipsy right infrastructure requirements or application requirements that are common across the board and yeah that's basically it but now in terms of the stateful component why could the real question is can you really do it in communities and what is the trend so if you listen to Gardner by 2023 you will have 75% of all databases that would be migrated to a cloud platform but it it's both a mix of DPS a service like RDS and also using Kubernetes to run databases because it's running in the cloud but the big difference trust me will be cost if you use RDS you will have tremendous cost in terms of you know EBS provisioning and in terms of availability as well remember most of the cloud disks they are contained the higher ability is limited to availability zone if you need to recover across availability zone there is downtime you need to script something you need to restore from snapshots all that right so you have to be careful with communities and the right tool sets you don't have to do this you can use local NVMe drives even in your instance using your own instance store as long as you have the right CSI drivers and you can have basically you can build on your knowledge which is Kubernetes and spread it across all the cloud and build databases in the cloud and here this is an example of the most popular images container images the source is a data that was late 2021 so there are 14 of them and most than half of them are stateful anyway right and what is really enable us to run databases and other stateful component in communities this is the operator so for those who are not familiar with the operator pattern it is a way to encapsulate some knowledge into a Kubernetes controller and customer resource definition so it's extending the Kubernetes API to represent anything as a Kubernetes first class citizen including database right so you will find a lot of different databases operators that allows you to do things like build a database because if you deploy a stateful sets which is the Kubernetes native object to deploy stateful stateful workloads well it just build the container does nothing on the app level but how about if you want to build a MongoDB database automatically as the stateful set is scaling up and down this is where the operator comes in it will detect that's the pods the number of pods are growing and then it will increase the size of the cluster do the replication you can do backup restore all these kind of things it's encapsulated in the operator and represented in the end as YAML again so we are back into our favorite format which is the YAML that's great it's love of hate in general with the YAML but again this is YAML it can be committed to Git it can be deployed via GitOps you can use police as code with it so it has all those benefits right so here a couple of examples before jump into the demo here is a data services requirements so I took on that as an example but it's valid with open source one and any other CSI who support this feature you can see here this is just saying I want two replicas oh yeah it's not it's two replicas encryption is true topology aware which is this ability to detect multiple availability zone and spread your replicas across different availability zone to true so it's as easy as this so remember the shift let's paradigm you can already simulate all the production environment in your on your local laptop because all of this is available as software and defined as YAML same thing with policy requirement this is an example of kevernal which I'm gonna I'm gonna have in the demo as well so the idea of police as code extended to the operator pattern for example for databases is to say imagining that in that particular case this is you we require more than two replicas so this is a two here it's a bit light so that means that if the number of replicas that you have sets in the previous YAML file is less than two then you are there are different way that kevernal is implementing the control can be an admission controller in that particular case when you're going to deploy that application in the cluster this state full set is going to be denied in the cluster so it won't be deployed or kevernal which is I'm going to show you also has a command line that is taking as an input all those policies return as YAML but not in communities just YAML taking this matching against your application manifest and as part of a command line result will tell you fail or pass which mean that you can include this into your global pipeline to deny or accept a merge for example right before even deploying into the cluster so that if you have a github's process in the end can only be triggered if the different tests including this has passed so you can do it's like number of replicas but imagine things like size of the database which is another parameter of the custom resource for your database you know for your database custom resource if you're using the database operator things like things like permission if you need to create a user with specific permission you can also check it and validate it with a cluster policy using kevernal everything in YAML so of course there are other tools you can use all-pocket keeper if you want to learn Rigo but this this is kubernetes this is only using YAML probably a bit less flexible than than Rigo but in to my knowledge like 80 percent of the use cases can be managed by using kevernal and again the ID is a couple of things checking this as early as possible in your dev environment and making sure that's in when you go to production you have all the compliances all your complaint compliance rules that can be applied into your different application manifests so I'm 25 that's 15 minute left so I have to go very fast now to explain the pipeline so as you can see there's a lot of moving parts but we can divide it in two section the first one is the top line here from left to right this is Sue our developer she is developing an application which is based on the Marvel API storing Marvel requests into a MongoDB database I'm sorry I know the the abstract mention sequel and the Zellando operator but this is gonna gonna be MongoDB with the community operator but that's basically the same principle so the ID is to have the application a flask application that is going to perform requests to the Marvel API store them into a MongoDB and then the application will be displayed in the front end with sort of Marvel cards so this is our application for today which hopefully is better than just another hello world sort of application and then for this we're gonna use our laptop where we have a local K3S cluster running which is common and what I want to do is to show you like a couple of tools that the first one is going to be a scaffold so scaffold is a software from Google that allows you to build a push and manage the life cycle of your application without committing anything to git and to deploy it into your local K3S cluster you can store the images locally it has policy based image tagging as I said you can choose to keep the image local or to put them on the remote registry in our case they will be stored on Docker Hub anyway but I just put it there but I could have chosen just to keep it locally and so scaffold embed a scaffold file that allows you to define to express environment requirements using customized so customized for people who don't know is basically a way to customize your Kubernetes environment where you have a base of your Kubernetes manifest and then you can build different overlay that are gonna change the base with your specific requirements so typically you don't use customize as a command line except when I'm going to show you with with the police as code but it's supported by scaffold locally on the laptop we're gonna be using tecton in production which is a CI pipeline tool that is staying that is living in Kubernetes where every task is represented as a part as a container and it's of course compatible with customized just you have another task that is going to build the manifest using customized and so we have a novel a4 prod we have a novel a4 dev of course as I was mentioning before we will have some on that file like Yamlify to specify replication well I'm just testing it in my local laptop so I don't need any replication don't need any encryption and then it's going to be de scaffold is going to manage all this part here from there to the end including the deployment as soon as soon as I change the code locally on the file system when I save on my local file system scaffold is going to monitor the folder the directories without committing to get it detects a flat file system change is going to push a new version of your application automatically in your cluster in your development clusters without committing the code to get yet and of course once you're happy with the code you you do pull requests and probably I'm just going to save it anyway and once the pull request is done you can trigger your pipeline there and this is what we're going to do with tecton so now it's we are the bottom we want to do tecton to deploy the application in production so because we are now using communities we don't want to use Docker of course to build the image because you need to mount the Docker I mean now it's been deprecated anyway but you don't want to mount the Docker socket in communities because you need real privileges which is bad right so there's a great tool again from Google which is called Kaniko that allows you to build container images in communities without using Docker at all and without mounting any containers the socket and so that's that will be our first task in tecton so the the role of tecton is going to be to build it so the same thing as scaffold build the image build the application manifest using customize so our second task will be to use customize with tecton to build a manifest push the manifest on a repository here so again build the image image is also uploaded to the registry and the manifest use using customize we generate the file push them to git and we will have flux which is a CD so continuous delivery GitOps tool that will monitor that particular repository and every time it's going to see the modification in the manifest it's going to update what is running in the cluster so no Coup CTL to deploy the application is basically you have single source of truth and you have this is the intent and the intent is reconciled with the states that is in the cluster and finally I'm going to show you Qverno as part of a just manual action so that you can see how to validate or not if your manifest are compliant so I've got 10 minutes for this this is going to be challenging okay so now let me switch to the other environments I need 15 minutes okay okay so now the cool stuff okay so the idea we're going to start with scaffold right so this is my application this is my application there right so on the left you have the different components so this is a flask application so template page dot html this is where I've got my front-end let's say code where I'm just displaying you know the cards I want so here you appears in comic this is the part I want I will want to change in just after to change it to come mix with a with a mess just as modifying the code right let's go cheap to modify the code you see also the docker file that is going to be used by by kaniko by scaffold by all the tools to build the application container image I'm using genic G unicorn as the web server and I've got my main dot P my Python code that is basically connecting to the DB and again displaying some of the or putting together some of the content connecting to the database and finally remember I told you when you deploy you create an application in communities you want to use communities native components to help you do this so originally the idea here is to start with empty database empty application nothing is working and I've got a Kubernetes job to basically if you look at the job made on py is to realize the the API request to the mobile API and store them in the database to prepare the application and that one of the property of communities job is that is going to continue trying I think by default up to 10 times until it succeeds once and you know communities is mainly a highly asynchronous system with eventual covert convergence this is the same ID here where it's gonna I'm going to go deploy the application including the database but the job will only succeed once the database has been completely created and healthy then Python requirements so Docker file for this is for yes the same thing actually yes not using that Docker file so it's using that particular Docker file is the same thing defining some environments variable and the main thing I wanted to show you is the scaffold scaffold file but meanwhile I'm just gonna launch it because so dev mode means that is going to monitor dynamically the file that you are modifying so it's going to be like a demon sort of mode that is going to build everything so just to check here this is my cluster you can see I don't have I don't have like the dev namespace or anything but it's gonna appear as soon as scaffold yes creating stuff already so it's preparing basically the environment for that and you have the good thing is it also logs all the container that are part of the scaffold configuration so you don't have to go into individual container to see what's happening so back to our scaffold content so again it's yamal like you define what builder you want to use so you can use Docker I think I still have like the documentation open there scaffold so for building it supports Docker Maven custom scripts build packs a lot of different things right here I'm just using a custom script I can show you the scripts quickly it's because I'm running on M1 which is an ARM processor so I need to use Docker build X to cross compile on x86 right this kind of things but yeah this is why it's what I want to show you is that X you can extend it's custom is able you don't have to use Docker you can use custom script as well and then you can say if it's image local or here I'm just deploying creating and pushing the image on the Docker registry registry you just need to do to have Docker running on your laptop which I've got locker desktop here and then customize and the path this is the path to my dev overlay this is all you need and then you're on scaffold there and so now I think it should be ready let's check yeah okay here so that now we see error because the MongoDB database was not ready yet when the first job has run so now we need to wait for this job here to be completed and normally we should see so you can see like here you that's the the community's job error miss the logs saying that well I cannot run because it's failing because I cannot connect to the database it's not there yet so we're gonna wait normally it should take maybe another minute me yeah so now it's I'm just displaying all the JSON payload that I'm requesting from from the the Marvel API which is about like 800 different entries when it's done I'm gonna show you what is the application and we're gonna change it so it is there let's just do a pull forward it's running on port 80 t okay now if we go local host okay so this is our application displaying some of the characters there you can reload them so we are happy but here there's a there's a typo in comic we want to put comics with an s well now that's easy the only thing I need to do for this I go to my code I'm just gonna look for all the comic into iteration so that's coming and I want to replace with come mix like this replace everything I'm just gonna kill forward there and go back to my scaffold here so I've replaced everything just double-checking that everything has been replaced comics there everywhere now I'm gonna save just command s and now it detected this is gonna build not rebuild everything just the front-end container that is you know coming from the code I've modified so if I go back into my environment here you can see my DB is still there right if you see the DB didn't change right still like four minutes just those three container the front-end has been updated and so now if everything worked I should go there and pull forward again and if I go back here just back you can see now the code has been modified I'm happy with this in production now I want to go in dev I want to go into production so this is the cluster this is the other cluster I've got nothing running it will be in the default namespace and I'm gonna be using tecton this time to deploy into production so for this let's go first we're gonna kill everything here and when you're done with scaffold just press Ctrl C it's gonna delete all the component for you right and you're back to a to a healthy and minimalist cluster deleting your without your application so now for tecton let's first I want I wanted to show you customize customize which is there so you have the base here that is defining all the job the deployment for my the communities deployment that's representing the wrapper around my container the service to deliver my front-end and this is my database custom resource where I can define the size which is one gig etc etc this is the base and this is the overlay where I'm gonna apply different qualities so here for example in the depth overlay I've got replicas zero encryption false so now let's check to check out master okay and you can see that's now I've got prod there and here replicas encryption my in terms of my CRD for my database I've got two volumes one gig I've got user with permission all of that is just representing my environment for production and now tecton is gonna use customize to build the production application so now tecton so just to put it like very quickly tecton will run all the task so building the image and from one task to another you can also share information in the form of config maps secrets or storage and PVC's if you want to use more than one then you have to have a solution that eliminate the requirement to run a pod and the volume on the same node which on that can do and others as well but by default you won't be able to do that so this is a way to optimize tecton as well using the right CSI so for tecton again same thing what we're going to do is like everything in Kubernetes to trigger the pipeline we can we can create just push the manifest into Kubernetes just by doing this is gonna trigger the whole pipeline that we can monitor using a tecton command line here is gonna run monitor the whole pipeline and same thing as Caffold but now except that it's gonna be in production and I'm gonna also monitor things with flux so flux is monitoring at the end of the tecton pipeline what I'm doing is remember using customize build the manifest push the manifest to a particular repository tecton is gonna pick it up sorry flux is gonna pick it up here you will you're gonna see one line that is basically saying I'm reconciling the state of the cluster waste the intent that is resigning in my github repository and in no time we should see here so you can see here this is the different this is the the the pipeline running in Kubernetes so again this tecton software is basically using Kubernetes to run the pipeline itself so you can run it in a different cluster probably not your production cluster maybe your staging cluster or your DevOps cluster but it allows you to consume communities even I mean also to build your pipelines which is I think a great idea if you want to do everything into Kubernetes again you don't have to use cloud specific tools on AWS and code pipelines all that you can keep everything into communities so now we are it's done one time for every task you will see a new pod that is gonna pop up okay so in the meantime while it's probably like another two minutes which will be the end so if there is any question you can shoot them now I know that was a lot but hopefully that was interesting yeah okay now it's like so I'll go quieter now so my question was to extend on the example that you showed the change to your I think it was a web app you changed some text which rebuilt just the specific portion that you changed I'm gonna give another example like let's say you changed your I made a change to your database model with the same effect that it would only change to the database structure as well yeah so no it will so scaffold will just monitor the directory that you set up in terms of what is deployed in communities right so basically if you change something that is not in that directory and that doesn't affect communities it won't redeploy anything so it means that the only thing it will be able to redeploy for the database is that if you change the custom resource for the database not like the model itself or something that is deeper more than infrastructure one more question if I could it's real quick for the deployment of this could this be done locally as well so you mentioned running it on your local laptop this will work there is also it can be extended to on-premise Kubernetes deployments and so forth yep thank you okay so just to finish you can see that it's been reconciled and you can see that on my github repository now the manifest has been populated by the pipeline so all the manifest done by customized populating like the new image with a new digest all the policy that you have sets everything is there and yeah flux has just picked this up and just we're gonna the application is there just to show you that the application is working now if I go back into here and so the pipeline has finished like again you have all the logs and if I do pull forward this time in production in my cluster I should see that once again yeah it has pick up of course the changes from the code and now it's running in production right if we have maybe time is there any other questions maybe one okay if not maybe online there's no question okay perfect so just to finish this is what we have been talking about today as a sum up so take away for today stateful workloads in communities are possible if you deploying or if you want to create a cloud native application you can collocate your stateful component with the stated stateless components as long as you provide the right additional data services like replication encryption mobility my company of course provide this but this is not the only solution you'll have a lot of open-source solution Kubernetes is great to use it as a cloud operating system as a standard across all different clouds but of course it has a learning curve but once you learn communities it's just enough to deploy your application and create your application anywhere and finally there is a lot of ecosystem tools right now that run in communities I've showed you tecton I've showed you scaffold so the developer experience is getting better better and better and better every day so don't hesitate to check them out if you want to get linked to the repo that I've used I can post them you can find me on Twitter I've put it in the presentation first in the first slide you can just contact me and I can try to find a way also to post it somewhere that you can access so thank you very much for listening to me hopefully it was a cool day thank you


From theCUBE Studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. Hi, welcome back. I'm Stu Miniman, and this is a CUBE Conversation. Digging in with Pensando, talking about what they're doing to help people, really bringing some of the networking ideals to cloud native environments, both in the clouds, in the data centers. Happy to welcome to the program, Krishna Dota Penny. He is the vice president of software with Pensando. Krishna, thanks so much for joining us. Thank you, Stu, for talking to me. All right, so Krishna, the Pensando team, very well known in the industry, innovation startup, especially in the networking world, gives a little bit about your background specifically, how long you've been part of this team and what helped you and the team start Pensando. Yeah, so I'm VP of software in Pensando, before founding Pensando, I worked in a few startups in CMA networks, newer systems and Greenfield networks. All those three startups have been acquired by Cisco. My recent role before this company was I was VP of engineering in Cisco. I was responsible for a product called ACI, which is Cisco's flagship SDN product. So I mean, when, why did we find or found Pensando? So when we were looking at the industry the last few years, right? The few trends that are becoming clear. So obviously we have a lot of enterprise background. We were watching ACI being deployed in the enterprise data centers. One sore point for customers from operational point of view was installing service devices, network appliances or storage appliances. So not only the operational complexity that this device is bringing, it's also, they don't give you the performance and bandwidth and PPS that you expect for traffic, especially from East-West. So that was one major issue. And also if you look at where the intelligence is going has been, this been the trend, it's been going to the edge. The reason for that is the routers or switches or the devices in the middle, they cannot handle the scale. I mean, the bandwidths are growing, the scale is growing, the stateful stuff is going in the network and the switches and the appliances are not able to handle it. So you need something at the edge, close to the application that can handle this kind of services and bandwidth. And the third thing is obviously, X86, few years back, every two years you're getting more transistors. I mean, obviously the Moore's Law ended and we know how that part is going. So the X86 cycles are more valuable and we don't want to use them for all this network services including SDN or firewalls or load balancers or NVMe virtualization. So looking at all these trends in the industry, we thought there is a good opportunity to do a domain specific processor for IO and build products around it. And that's how we started PenSyndall. Yeah, so Krishna, it's always fascinating to watch. If you look at startups, they are often product of the time that they're in and the technologies that are available. Sometimes there are ideas that it takes a few times and maturation of the technology and other times, I'll hear teams and they're like, oh, well, we did this and then, oh wow, there was this next new innovation that came out that I wish I had had that when I did this last time. So we do a 2.0 or 3.0 generation. We've been talking about distributed architectures for well over a decade. It's been a long time now. In many ways I feel edge computing is just the latest discussion of this, but when it comes to, you've got software under your purview, what are some of the things that are available for PenSyndall that might not have been in your toolkit five years ago? Yeah, so the growth of open source software has been very helpful for us because we built a scale out microservices based controller. The last time around when we were building that, we had to build our own consensus algorithm. We had to build our own distributed database for metrics and events and logs. So right now, we have, because of open source thing, we leverage at CD, Elastic, Influx, in all this open source technologies that you hear, since we want to leverage the Kubernetes base ecosystem, that helped us a lot. At the same time, if you think about it, the even the software which has not open source, closed source thing, are maturing. I mean, if you talk about SDN, seven, eight years back, it was like, there are N versions of doing of SDN, but now the industry standard is on EVPN, which is one of the core pieces of what we do. We do a SDN solution with EVPN. So it's more of, the industry is coming to a place where these are the standards, and this is open source software that you could leverage and quickly innovate, compared to building all of this some scratch, which will be a big effort for a startup to succeed and build it in time for your customer success. Yeah, and Krishna, you talk about open source, not only in the software, it's in the hardware standpoint. I think about things like open compute or the proliferation of GPUs and PPUs and everything along that. How has that impacted what you've built? So I mean, it's a good thing you're talking about. For example, we are working in the future on OCP card. It's a good thing that OCP card goes into a HPE server, it goes into a Dell server. So pretty much, we want to, I mean, see our goal is to enable this platform that what we build in all the use cases that customer could think of. So in that way, hardware standardization is a good thing for the industry. And then same thing, if you go in how we program the ASIC, we are about standards of this P4 programming. That's an industry consortium led by a few people. We want to make sure that we follow those standards so that for the customer who's coming in, who wants to program it, it's good to have a standards-based thing rather than doing something completely proprietary. At the same time, you have to enable innovations and then those innovations, you have to push it back to the open source. That's what we're trying to do with P4. Excellent. I've had some real good conversations about P4 and the way Pensando is leveraging that, maybe a little bit differently. And that, you talk about standards and open source, oftentimes it's like, well, is there differentiate? There are certain parts of the ecosystem that you say, well, it's kind of been commoditized. Obviously you're taking a lot of different technologies, putting them together, help share the uniqueness of Pensando, what differentiates what you're doing from what was available in the marketplace, where that I couldn't just cobble together a bunch of open source hardware and software together. I mean, if you look at technologies like the, I think the networking that both of us are very familiar with it, if you want to build an SDN solution or you can take OBS or you can use X86 and take some match and silicon and cobble it together. But the problem is you will not get the performance and bandwidth that you're looking for. So let's say, if you want a high PPS solution or you want a high CPS solution because the number of connections are growing for your IoT use case or 5G use case, right? If you cobble together with an open source thing without any assist from a domain specific processor, your performance will be low. So that is the, I mean, that's one enterprise side in the cloud use case, right? As you know, you're trying to pack as many VMs as containers in one server because you know, you get charged. I mean, the customer, our customers make money based on that, right? So you want to offload all of those things into a domain specific processor that what we built, which we call the TSC which will do all the services at pretty much no cost to X86. I mean, X86, you'll be using zero cycles for doing features like security groups or VPCs or VPN or encryption or storage virtualization, right? That's where our value comes in. I mean, if you count the TCO model, using bunch of X86 cores or in a bunch of in ARM cores or AMD cores, compared to what we do at TCO model works out great for our customers.  Excellent. I'm glad you brought up customers. Krishna, one of the challenges I definitely have seen over the years with networking is it tends to be, you know, a completely separate language that we speak there. It's, you know, a lot of acronyms and protocols and, you know, not necessarily accessible to people outside of the silo of networking. I think back to, you know, SDN, you know, people on the outside would be like, that stands for still does nothing, right? Because it's like networking, you know, mumbo jumbo there. For people outside of networking, you know, when I think about, you know, if I was going to the C-suite of an enterprise customer, they don't necessarily care about those networking protocols. They care about the, you know, the business results and the productivity. How do you help explain what Pensando does to those that aren't, you know, steeped in the network? The way I look at it, right? What is customer looking for? Yeah, you're right. Customer doesn't need what in-cap you use. Customer is looking for his operational simplicity and then he wants looking for security, right? You know, and if you look at it sometimes, you know, both are like in orthogonal. If you make it very highly secure, but you make it like 10,000 operational procedure before you deploy a workload, that doesn't work for the customer because the operational complexity increases tremendously, right? So where we are coming in is that we want to simplify this for the customer. You know, there's a very simple way to deploy policies. There's a simple way to deploy a networking infrastructure. And in the way we do it is we don't care what your physical network is in some sense, right? So because we are close to the server, that's a very good advantage we have. We apply the policies before even the packet leaves the server, right?  We have this product called PSM, which manages all the servers from the central place. And it's easy to operationalize a fabric whether you talk about upgrades or you talk about deploying new services. It's all of driven with REST API and you have a GUI. So you can do it single place and that's where a customer's value is rather than talking about, as you're talking about end caps or exactly the raw throughput, that is not the main thing that, I mean, they wake up every day. They wake up every day thinking about it or do I have a security risk? And then how easy for me is to deploy new services or bring up new data centers. All right, Krishna, you're also spanning with your product a few different worlds out there. Traditionally, if I think about an enterprise data center versus a hyperscale public cloud and edge sites, it comes to mind very different skillsets for managing them, different types of deployments there. If I understand right, you were going to play in all of those environments. So talk a little bit about exactly how you do that and just where you sit in that overall discussion. Yes, so I mean, number one rule inside the company is we are driven by customers and obviously our customer success is our success. So, but given said that right, what we try to do is that we try to build a platform that is kind of programmable, obviously starting from before that we talked about earlier, but it's also from software point of view, it's kind of pluggable, right? So when we build the software, for example, our cloud customers and they use DSC, they use the same set of APIs or GRPC or SAPIs that DSC provides with their controller. But when we ship the same platform for enterprise customers, we build our own controller and we use the same DSC APIs. So the way we are trying to do is think there's fully leverage in what we do for enterprise customers and cloud customers. We don't try to reinvent the wheel, obviously. At the same time, if you look at the highest level constructs from a network perspective, right? Or even storage perspective, what are you trying to do? You're trying to provide connectivity, but you're trying to provide isolation and you're trying to provide security. So all these constructs we encapsulated in APIs, which in some mostly like cloud-like APIs and those APIs are used for cloud customers and enterprise customers. And the software is built in a way where any layer can be removed or any layer can be added, right? Because it's in our interest, we don't want to build multiple different softwares for different customers, right? Then we will not scale. So the idea when we started the software architecture is that how we make it pluggable and how we make it programmable so that customers say, I don't want this piece of it. We can put the third-party piece on it and still integrate at a common layer with using REST APIs. Yeah, well, Krishna, I have a little bit of appreciation for some of the hard work that goes through what your team's been doing, a couple of years in stealth, but really accelerating from the announcement coming out of stealth at the end of 2019 to just about half a year, you're a GA with a major OEM of HPE, definitely a lot of work that needs to be done. Bring us, what are you most proud about from the work that your team's doing? We don't need to hear any major horror stories, but there always are some of the not holes or challenges that often get hidden behind the curtain. Personally, I'm most proud of the team that we've built. So obviously, our executives have a good track record of disrupting the market multiple times, but I'm most proud of the team because the team is not just worried about technology, that even there are very senior technologists and they're great leaders, but they're also worried about a customer problem, right? So it's always about getting the right mix of execution combined with technology is when you succeed. That is what I'm most proud of. We have a team with independent leaders running all these projects independently and then releasing almost, we have a release every week if you look at all our customers, right? And then being a small company, doing that is pretty challenging in a way, but we came up with methodologies where we fully believe in automation, everything is automated and whenever we release software, we run through the full set of automation so that we are confident that customer is getting good quality code. It's not like, you know, we cooked up something and they should be worried when they need to upgrade to this software. So that's, I think that's the key part if you want to succeed in this day and age, developing the features of the velocity that you would want to develop and still support all these customers at the same time. That's cool. Well, congratulations on that, Krisha. All right, final question I have for you. Give us a little bit of guidance going forward.  You've got a very flexible architecture, a lot of different types of solutions. What kind of markets or services, you know, might we be looking at from Pensando, you know, down the road a little bit ways? So I think we have a long journey ahead. So we have a platform right now. We already, I mean, we have a varied baby, we are shipping, the platform is already shipping in a storage provider. We are integrating with the premier clouds, public clouds, and, you know, enterprise market, you know, we already deployed distributed firewall, some of our customers deployed distributed firewall. So, you know, so if you take this platform, it can be extendable to add, you know, all the services that you see in data centers on clouds. Right? But primarily we are driven from our customer perspective to a customer priority point of view. So where we will go is we will try to add more edge services. We'll try to add more storage features. And then we are also this initial interest in service provider market, what we can do for 5G and IoT, because we have the flexible platform. We have to see, you know, how to apply this platform to this new applications. That's where probably we'll go in future. All right, well, Krishna Dutta Penny, Vice President of Software with Pensando. Thank you so much for joining. Thank you, Stu. It was great talking to you. All right, be sure to check out thecube.net. You can find lots of interviews from Pensando. I'm Stu Miniman, and thank you for watching theCUBE.


The line just kept coming into my mind that so little is asked of you, and yet I offer you everything. And so basically that's why we're joining together again to remember that everything, heaven, is offered us. And in exchange we're asked for our willingness to open up and to expose and to let go of the ego. So that's not really, it shouldn't be a difficult trade, the trade of death wish for eternal life. You might say within the dream, to the dream characters this is a frightening proposition because the dream characters don't really know this, but unconsciously they believe that heaven is death and it's the end of the mini-me. And that's why a whole life dedicated to survival seems to be threatened by heaven because heaven is perceived as death. When actually it's the death wish of the ego and the false identity that is the death and very little is asked of us to remember the truth of who we are.