>> From The Cube Studios in Palo Alto, in Boston, connecting with thought leaders around the globe. These are Cloud Native Insights. >> Hi, I'm Stu Miniman the host of Cloud Native Insights where we're talking to companies and practitioners about how they take advantage of the innovation and agility of the cloud. Happy to welcome to the program I have first time guests, you know, Ido Safruti he is the co-founder and CTO of Perimeter X going to talk him in a dual role, both as a practitioner and their adoption of Cloud Native Technologies serverless specifically as well as they are a Cloud Native supplier in the security realm. Ido thanks so much for joining us. Nice to have you on the program. >> Yeah, good to be here. Thanks. >> All right. So Ido, if you could, you're co founder of Perimeter X, give us just, if you would, a little bit of your background and you know, what Perimeter X does and we'll, go into it from there. >> Sure. So as CTO, I'm in charge of the research, engineering, and product team at Perimeter X, we are a vendor, a Cloud Native vendor of web application security protecting all kinds of different business logic abuses for our customers, mostly large websites that are in demand of web-scale. So not only doing the protection or the application, but also integrated into multiple infrastructure and running at scale. We're solving problems like account takeover, carding, a major card data skimming and so on. >> One of the conversations we've been having the last couple of years from security is, you know, there's no shortage of new threats, the surface area of attack, keep getting more here in 2020, everybody's working from home more, the people that are doing attacks didn't stop working. So if you could just, you know, how long has Perimeter X been around? And I want to lead up to the discussion of serverless, you know, what was the architecture considerations before? And what started leading you towards making a change architecturally? >> Yeah, so Perimeter X was founded almost six years ago, a little less than six years ago. And we were a Cloud Native Solution to begin with. We identified the challenges of where the gap security in native cloud application is. For in many cases, security solutions are not leveraging the breadth and the new architecture of where applications are built. And we're more of trying to slap in a standard enterprise security and on other cloud infrastructure. When we started, we wanted to integrate and adopt the cloud and adopt the flexibility of the specificity of the edge to help enhance our customer's infrastructure by adding security onto that versus forcing them to rearchitect it when they integrate security into it. >> Well, it's addressing, you say six years ago. I can't remember hearing the term Cloud Native that long ago. Obviously Cloud has been around for a while, but when I started this one of the discussions around Cloud Native was, Oh, people were talking about adopting containers and Kubernetes. And I said, they're great tools to help from, you know, the infrastructure standpoint, but you're talking about right, living in the Cloud, taking advantage of cloud services, you know. That's where we really see the opportunity in Cloud Native. So, you know, when you say you were built for the cloud, but you know, things like containers, server lists probably weren't doing those six years ago, maybe, or were you? >> Actually, yeah, so we started early versions of obviously all dockerized Grenades was not that great back then. So we were orchestrating some things on our own and gradually adopting other orchestration and mesh for our own service that is obviously running on multiple cloud vendors. But from us, from our point of view, the key for cloud was how can we enable our customers, and how can we integrate better with them in a way that enhance their infrastructure versus add friction? Because the challenge usually with security, is that security in most cases or traditionally, was adding friction and delays and complexity to developer process. And we're designing our solution to begin with on how can we leverage these new technologies? How can we leverage the fact that CDNs and edges are becoming smarter and can, you can start deploying your own payloads and logic to make our logic integrated with them and to partner with this cloud players in order to enable our customers to add these additional tiers. And I think this is from my point of view, one of the key capabilities of having the capabilities of computed edge and serverless, is making a lightweight integration and making your existing infrastructure smarter by making it easy to incorporate third party vendors or other solutions or more logic without forcing a wholly architectural solution. >> Yeah, no, no. You bring up some great points. I remember back the early days of Docker, it was, can we get the atomic unit to be closer to what the application is. But you know, my background is in infrastructure and it was okay, It went from the server to the VM, to the container. Yeah, there's an application that sits on top of it, but I don't think about it as opposed to serverless starts with the developer first and you know, how I build my application and then there are certain things that I have to worry about the platform. So, help us understand doing containers, looking at serverless, was it okay, we're going to completely overhaul and throw out what we had because there's something new and better. Are you doing still some containers and some serverless? Help us understand, you know, what drove that transition and what the outcomes were? >> Yeah, so our infrastructure our machine learning algorithms, the data processing that the heavy lifting that we're running on our own infrastructure, which is again, Cloud Native Infrastructure. But something that we're managing in many cases is using containers is using other environments because we were running heavy payloads. We're not fully relying on some other platform to run for us. We're leveraging a lot of these technologies to run it and run it in a more efficient way. Where we're adopting serverless is both in some of the front end decisions. So making smarter load balancing decision integrating with some other cloud vendors to help make sure that requests are coming in the right view, and things like this, but where it is more important even then is how can we make ourselves relevant for customers to adopt serverless and how can we help introduce security into these environments? Because, if you're looking at traditional security, if you're, if you're so it's more about, if I go to that one, how can I enable our customers adopt serverless? How can I enable our customers adopt new technologies into cloud? Because it could be a limitation if you're, if you're a security policy or if your architecture is such, that requires everything to go through a specific security proxy or some firewall, it may force you to utilize very limited architectures. If you want to deploy now with payload on some, on Lambda or on, on your CDN, it typically will be way in front of your traditional enterprise security solutions. How can you make that application smarter? How can you make that application sort, self-sufficient by connecting modules, by making sure that you're including modules that integrate security, and bring the security with you everywhere. So, so this is the motion that we're trying to define here. >> Well, and I'm sure you've got a really interesting viewpoint that I'd love to hear on this, Ido. So if you look at, you know, most new technologies, especially in the cloud space, serverless specifically, you know, costs that should be less expensive, you know, flexible. I should be able to, you know, make changes, and speed. I should be able to do more faster, but always when you look at those, you say, well, but what about security? Can I do all of those things, you know, be faster, better, cheaper, more agile, and not be less secure? So I'd love to hear any thoughts you have on kind of the, you know, the typical things, but also your security angle on them? >> Yeah. So one of the benefit of using serverless, and I think there are two types, initially thinking of serverless one is running your code in some, backend application, that may access different things, but you don't need to manage for scale because there is some platform that manage that. Which is one great option, what you're seeing more and more, and we're working in collaboration with Fastly and where you can see that on other edge platforms is having this notion of serverless, How can you deploy code to the edge? And the benefit there is that you can mitigate a lot of the risks outside your data center, outside of your cloud, that if there is, and this is where security plays so well with that, because you want to mitigate the risks and the attack as far away from your application as possible. So if you can deploy the logic that is doing that, or making decisions at the edge, it helps you improve your infrastructure cost. It helps you improve some of the applications that are still in the backend, so you can gradually forward deploy some of the logic that is relevant at the edge and getting the scalability, getting this ability to scale without limit, because a CDN or edge vendor, he has a lot of capacity and withhold if it's a denial of service attack, or if it's any other type of attack, weigh this logic in hand. Or even, sometimes it's just skill. Maybe you had a very good marketing campaign and you were having a lot of traffic. If you can deploy this skill somewhere that can handle that in a distributed, efficient way, you are having even better. >> Well, and it sounds like that that fits into what Perimeter X does. You know, when I think about edge, you know, scale concerns, security concerns are, you know, some of those top of mind as are just, you know, how. You know, can automation things like machine learning or AI help me? Cause usually that scale or a distributed nature of it means that it's not necessarily something that people alone could take care of themselves. Am I getting right, a little bit where Perimeter X is helping their customers? >> Yeah, yeah, yeah. And the idea is to connect, to help and to help offline offset some of the logic or some of the capabilities that, that you don't want your business to be an expert in. So if you're a retailer, you want to be able to sell the best to optimize accomodation for your customers and to handle that you don't want to be an expert in detecting bots or in identifying malicious code or things of that sort. And if you can offset that and with a lightweight, easy integration that does not limit your ability to innovate and adopt new technologies, this is what we're trying to help. Let us focus at this. But by integrating the edge by integrating with partners like Fastly and so that we can help enhance the infrastructure and add more capabilities, where you can focus on doing your own business and we can help allow and enable additional technologies. >> Along your serverless journey, what partners, what other vendors were helpful along the way? As I've looked at it, it's a relatively young ecosystem, but it's robust. So, you know, I'm curious who, some of the companies that have helped along the way? >> Yep. I think Fastly is definitely one that is from their earlier infrastructure. They always had the component of exposing their edge and making it more programmable via configuration and setting logic. And now rolling out a computed edge that is giving even more flexibility. Other CDNs are opening their edge as well with all kinds of tools, again, Lambda from AWS and other services. So this is one component of how do you manage that? How do you always read that? There are issues of how much state can you manage their access to data? And there are different services that allows that. Other platforms, which are more of the platform as a service that are not traditionally considered serverless. And you can think of it as eCommerce platforms helps you deploy your logic and some sometimes go to application into their ecosystem and helps you focus on again, managing your application. So think of Magento, think of a Salesforce cloud, these kind of commerce applications that you can deploy your logic. They're all fit into that ecosystem of help you. You want to write your code to that, your key on and let someone else manage the scale, let someone else manage some of the things that are common tool. >> Well, yeah, that's definitely one you see diversity of solutions at edge. You know, very different from if you were thinking kind of their traditional enterprise data center. Any, you know, as a CTO, when you look at edge, you know, where we were the maturation of this whole solution, or are there areas specifically that you expect in the next, you know, six, 12, 18 months that we will see some things solidify, mature down the line. >> Yeah. Yeah. So I think that the state where the edge compute is at now is more about deploying logic that is remote from the data center. So there is a limit. And if you look across different vendors to the more IO or data access capabilities of these loads. So if you can write the code and make it self sufficient, it's easier and it's more common to find platforms that will love it. What you're starting to see is how you add the data layer into that tier and making it more accessible. And that opens the gate for many more reach an interesting reputation, because once you can have a key value store, and once you can manage a state and modify configuration, you can then start deploying more complex applications and make more decisions. Do I see the billing system running entirely on the edge? probably not. There are things where you want to store it in the database. There are things that make sense to have it in some backend infrastructure, but a lot of payloads more and more environments are going there. And I think these additional services of queuing services, data services, database like services. So can, can I run a transaction on the edge? These kinds of technologies are currently emerging and you can see them in different levels for different vendors. And they will definitely open the gate even further for more and more patrons will be adopted at the edge. >> All right. Well, Ido last question I have for you, What advice would you give for your peers out there? as you said, you know, you were early in Docker adoption. You've done serverless adoption, you know, Edge is something that is gaining a lot of attention. What advice would you give to people here in 2020 as they look at, you know, the variety of Cloud Native options out there? >> I think the easy one is anything new that you build look around and figure out what is the best technology that can help you get there faster? And how can you build in a more strategic way for C-suite executive, if it's the CTO, CIO, CSO, think on how can you enable your team to move faster? How can you enable your team by the solutions and technologies that you select to have the flexibility of moving faster? how can you enable them to, to adopt new technologies and make it available? How can, and this is, you need some practices because you need to make sure that you are getting the right metrics. So whenever that you're using vendors that will help you collect and monitor the services and get the insights, because suddenly if anyone can deploy anything anywhere, then there is some concern about loss of control. So finding the right vendors that can help you or adopting the right processes that helps you gain this visibility while still enabling them to go anywhere. This is key. At least for us, it was key. And this is from wearing my product hat when we're building our services, this is what we're trying to enable our customers to do with this security. >> Well, Ido Safruti, thank you so much for sharing your journey, really appreciate you having on the program. >> Sure, thanks. >> And if you have people we should talk to, I would love hearing the stories of Cloud Native, how those adjustments are going and sharing your information with your peers. I'm Stu Miniman and look forward to hearing more your Cloud Native sites. (Calming music)

(bright upbeat music) >> Announcer: From theCUBE studios in Palo Alto in Boston, connecting with thought leaders around the globe, these are Cloud Native Insights. >> Hi, I'm Stu Miniman, the host of Cloud Native Insights. We talk about cloud native, we're talking about how customers can take advantage of the innovation and agility that's out there in the clouds, one of the undercurrents, not so hidden if you've been watching the program so far. We've talked a bit about serverless, say something that's helping remove the friction, allowed developers to take advantage of technology and definitely move really fast. So I'm really happy to welcome to the program, for coming from Fauna. First of all, I have the CTO and Co-founder, who's Evan Weaver. And also joining him is the new CEO Eric Berg. They said, both from Fauna, talking serverless, talking data as an API and talking the modern database. So first of all, thank you both for joining us. >> Thanks for having us Stu. >> Hi, good to be here. >> All right, so Evan, we're going to start with you. I love talking to founders always. If you could take us back a little bit, Fauna as a project first before it was a company, you of course were an early employee at Twitter. So if you could just bring us back a little bit, what created the Fauna project and bring us through a brief history if you would. >> So I was employee 15 and Twitter, I joined in 2008. And I had a database background, I was sort of a performance analyst and worked on Ruby on Rails sites at CNET networks with the team that went on to found GitHub actually. Now I went to Twitter 'cause I wanted Twitter the product to stay alive. And for no greater ambition than that. And I ended up running the back end engineering team there and building out all the distributed storage for the core business objects, tweets, timelines, the social graph, image storage, the cache, that kind of thing. And this was early in the cloud era. API's were new and weird. You couldn't get Amazon EC2 off the shelf easily. We were racking hardware and code ancient center. And there were no databases or platforms for data of any kind. They really let us the Twitter engineering team focus on building the product. And we did a lot of open source work there. Some of which has influenced Fauna, originally, Twitter's open source was hosted on the Fauna GitHub account, which predated Twitter like you mentioned. And I was there for four years build out the team, basically scaled the site, especially scaled the Twitter.com API. And we just never found a platform which was suitable for what we were trying to accomplish. Like a lot of what Twitter did was itself a platform. We had developers all over the world using the Twitter API to interact with tweets. And we're frustrated that we basically had to become specialists in data systems because there wasn't a data API, we can just build the product on. And ultimately, then data API that we wished we had, is now Fauna. >> Well, it's a story we've loved hearing. And it's fascinating one, is that the marketplace wasn't doing what we needed. Often open source is a piece of that, how do we scale that out? How do we build that? Realized that the problem that you have is what others have. And hey, maybe there's a company. So could you give us that transition, Fauna as a product, as a company, where was it understood that, hey, there's a lot of other people that can take advantage from some of the same tools that you needed before. >> I mean, we saw it in the developers working with the Twitter platform. We weren't like, your traditional database experiences, either manage cloud or on-prem, you have to administrate the machine, and you're responsible for its security and its availability and its location and backups and all that kind of thing. People building against Twitter's API weren't doing that. They're just using the web interface that we provided to them. It was our responsibility as a platform provider. We saw lots of successful companies being built on the API, but obviously, it was limited specifically to interacting with tweets. And we also saw peers from Twitter who went on to found companies, other people we knew in the startup scene, struggling to just get something out the door, because they had to do all this undifferentiated heavy lifting, which didn't contribute to their product at all, if they did succeed and they struggled with scalability problems and security problems and that kind of thing. And I think it's been a drag on the market overall, we're essentially, in cloud services. We're more or less built for the enterprise for mature and mid market and enterprise companies that already had resources to put behind these things, then wasn't sort of the cloud equivalent of the web, where individuals, people with fewer resources, people starting new projects, people doing more speculative work, which is what we originally and Jack was doing at Twitter, it just get going and build dynamic web applications. So I think the move to cloud kind of left this gap, which ultimately was starting to be filled with serverless, in particular, that we sort of backtracked from the productivity of the '90s with the lamp era, you can do everything on a single machine, nobody bothered you, you didn't have to pay anyone, just RPM install and you're good to go. To this Kubernetes, containers, cloud, multi site, multi region world where it's just too hard to get a basic product out the door and now serverless is sort of brought that around full circle, we see people building those products again, because the tools have probably matured. >> Well, Evan, I really appreciate you helping set the table. I think you've clearly articulated some of the big challenges we're seeing in the industry right now. Eric, I want to bring you into the conversation. So you relatively recently brought in as CEO, came from Okta a company that is also doing quite well. So give us if you could really the business opportunity here, serverless is not exactly the most mature market, there's a lot of interest excitement, we've been tracking it for years and see some good growth. But what brought you in and what do you see is that big opportunity. >> Yeah, absolutely, so the first thing I'll comment on is what, when I was looking for my next opportunity, what was really important is to, I think you can build some of the most interesting businesses and companies when there are significant technological shifts happening. Okta, which you mentioned, took advantage of the fact of SaaS application, really being adopted by enterprise, which back in 2009, wasn't an exactly a known thing. And similarly, when I look at Fauna, the move that Evan talked about, which is really the maturation of serverless. And therefore, that as an underpinning for a new type of applications is really just starting to take hold. And so then there creates opportunities that for a variety of different people in that stack that to build interesting businesses and obviously, the databases is an incredibly important part of that. And the other thing I've mentioned is that, a lot of people don't know this but there's a very good chunk of Okta's business, which is what they call their customer identity business, which is basically, servicing of identity is a set of API's that people can integrate into their applications. And you see a lot of enterprises using this as a part of their digital transformation effort. And so I was very familiar with that model and how prevalent, how much investment, how much aid was out there for customers, as every company becoming a software company and needing to rethink their business and build applications. And so you put those two trends together and you just see that serverless is going to be able to meet the needs of a lot of those companies. And as Evan mentioned, databases in general and traditionally have come with a lot of complexity from an operational perspective. And so when you look at the technology and some of the problems that Fauna has solved, in terms of really removing all of that operational burden when it comes to starting with and scaling a database, not only locally but globally. It's sort of a new, no brainer, everybody would love to have a database that scales, that is reliable and secure that they don't have to manage. >> Yeah, Eric, one follow up question for you. I think back a few years ago, you talked to companies and it's like, okay, database is the center of my business. It's a big expense. I have a team that works on it. There have been dealt so much change in the database market than most customers I talked to, is I have lots of solutions out there. I'm using Mongo, I've got Snowflake, Amazon has flavors of things I'm looking at. Snowflake just filed for their IPO, so we see the growth in the space. So maybe if you could just obviously serverless is a differentiation. There's a couple of solutions out there, like from Amazon or whether Aurora serverless solution but how does Fauna look to differentiate. Could you give us a little bit of kind of compared to the market out there? >> Sure, yeah, so at the high level, just to clarify, at the super high level for databases, there tends to be two types operational databases and then data warehouse which Snowflake is an example of a data warehouse. And as you probably already know, the former CEO of Snowflake is actually a chairman of Fauna. So Bob Muglia. So we have a lot of good insight into that business. But Fauna is very much on the operational database side. So the other half of that market, if you will, so really focused on being the core operational store for your application. And I think Evan mentioned it a little bit, there's been a lot of the transformation that's happened if we rewind all the way back to the early '90s, when it was Oracle, and Microsoft SQL Server were kind of the big players there. And then as those architectures basically hit limits, when it came to applications moving to the web, you had this whole rise in a lot of different no SQL solutions, but those solutions sort of gave up on some of the promises of a relational database in order to achieve some of the ability to scale in the performance required at the web. But we required then a little bit more sophistication, intelligence, in order to be able to basically create logic in your application that could make up for the fact that those databases didn't actually deliver on the promises of traditional relational databases. And so, enter Fauna and it's really sort of a combination of those two things, which is providing the trust, the security and reliability of a traditional relational database, but offering it as serverless, as we talked about, at the scale that you need it for a web application. And so it's a very interesting combination of those capabilities that we think, as Evan was talking about, allows people who don't have large DevOps teams or very sophisticated developers who can code around some of the limitations of these other databases, to really be able to use a database for what they're looking for. What I write to it is what I'm going to read from it and that we maintain that commitment and make that super easy. >> Yeah, it's important to know that the part of the reason that operational database, the database for mission critical business data has remained a cost center is because the conventional wisdom was that something like Fauna was impossible to build. People said, you literally cannot in information science create a global API for data which is transactional and consistent and suitable for relying on, for mission critical, user login, banking payments, user generated content, social graphs, internal IT data, anything that's irreplaceable. People said, there can be no general service that can do this ubiquitously a global internet scale, you have to do it specifically. So it's sort of like, we had no power company. Instead, you could call up Amazon, they drive a truck with a generator to your house and hook you up. And you're like, right on, I didn't have to like, install the generator myself. But like, it's not a good experience. It's still a pain in the neck, it's still specific to the location you're at. It's not getting utility computing from the cloud the way, it's been a dream for many decades that we get all our services through brokers and API's and the web and it's finally real with serverless. I want to emphasize that the Fauna it technology is new and novel. And based on and inspired by our experience at Twitter and also academic research with some of our advisors like Dr. Daniel Abadi. It's one of the things that attracted us, Snowflake chairman to our company that we'd solve groundbreaking problems in information science in the cloud, just the way Snowflakes had. >> Yeah, well and Evan, yeah please go on Eric. >> Yeah, I'm just going to have one thing to that, which is, in addition, I think when you think about Fauna and you mentioned MongoDB, I think they're one of a great examples of database companies over the last decade, who's been able to build a standalone business. And if you look at it from a business model perspective, the thing that was really successful for them is they didn't go into try to necessarily like, rip and replace in big database migrations, they started evolving with a new class of developers and new applications that were being developed and then rode that obviously into sort of a land and expand model into enterprises over time. And so when you think about Fauna from your business value proposition is harnessing the technological innovation that Evan talked about. And then combining this with a product that bottoms up developer first business motion that kind of rides this technological shift into you creating a presence in the database market over time. >> Well, Evan, I just want to go back to that, it's impossible comment that you made, a lot of people they learn about a technology and they feel that that's the way the technology works. Serverless is obviously often misunderstood from the name itself, too. We had a conversation with Andy Jassy, the CEO of AWS a couple years ago, and he said, "If I could rebuild AWS from the ground up today, "it would be using all serverless," that doesn't mean only lambda, but they're rebuilding a lot of their pieces underneath it. So I've looked at the container world and we're only starting the last year or so, talking about people using databases with Kubernetes and containers, so what is it that allows you to be able to have as you said, there's the consistency. So we're talking about acid there, not worry about things like cold starts, which are thing lots of people are concerned about when it comes to serverless and help us understand a little bit that what you do and the underlying technologies that you leverage. >> Yeah, databases are always the last to evolve because they're the riskiest to change and the hardest to build. And basically, through the cloud era, we've done this lift and shift of existing on premises solutions, especially with databases into cloud machines, but it's still the metaphor of the physical computer, which is the overriding unit of granularity mental concept, everything like you mentioned, containers, like we had machines then we had Vms, now we have containers, it's still a computer. And the database goes in that one computer, in one spot and it sits there and you got to talk to it. Wherever that is in the world, no matter how far away it is from you. And people said, well, the relational database is great. You can use locks within a single machine to make sure that you're not conflicting your data when you update it, you going to have transactionality, you can have serialize ability. What do you do, if you want to make that experience highly available at global scale? We went through a series of evolutions as an industry. From initially that the on-prem RDBMS to things like Google's percolator scheme, which essentially scales that up to data center scale and puts different parts of the traditional database on different physical machines on low latency links, but otherwise doesn't change the consistency properties, then to things like Google Spanner, which rely on synchronized atomic clocks to guarantee consistency. Well, not everyone has synchronized atomic clocks just lying around. And they're also, their issues with noisy neighbors and tenancy and things because you have to make sure that you can always read the clock in a consistent amount of time, not just have the time accurate in the first place. And Fauna is based on and inspired and evolved from an algorithm called Calvin, which came out of a buddy's lab at Yale. And what Calvin does is invert the traditional database relationship and say, instead of doing a bunch of work on the disk and then figuring out which transactions won by seeing what time it is, we will create a global pre determined order of transactions which is arbitrary by journaling them and replicating them. And then we will use that to essentially derive the time from the transactions which have already been committed to disk. And then once we know the order, we can say which one's won and didn't win and which happened before, happen after and present the appearance of consistency to all possible observers. And when this paper came out, it came out about a decade ago now I think, it was very opaque. There's a lot of kind of hand waving exercises left to the reader. Some scary statements about how wasn't suitable for things that in particular SQL requires. We met, my co-founder and I met as Fauna chief architect, he worked on my team at Twitter, at one of the database groups. We were building Fauna we were doing our market discovery or prototyping and we knew we needed to be a global API. We knew we needed low latency, high performance at global scale. We looked at Spanner and Spanner couldn't do it. But we found that this paper proposed a way that could and we can see based on our experience at Twitter that you could overcome all these obstacles which had made the paper overall being neglected by industry and it took us quite a while to implement it at industrial quality and scale, to qualify it with analysts and others, prove to the world that it was real. And Eric mentioned Mongo, we did a lot of work with Cassandra as well at Twitter, we're early in the Cassandra community. Like I wrote, the first tutorial for Cassandra where data stacks was founded. These vendors were telling people that you could not have transactionality and scale at the same time, and it was literally impossible. Then we had this incrementalism like things with Spanner. And it wasn't till Fauna that anyone had proved to the world that that just wasn't true. There was more marketing around their failure to solve the information science problem, than something fundamental. >> Eric, I'm wondering if you're able to share just order of magnitude, how many customers you have out there from a partnership standpoint, we'd like to understand a little bit how you work or fit into the public cloud ecosystems out there. I noticed that Alphabets General Venture Fund was one of the contributors to the last raise. And obviously, there's some underlying Google technology there. So if you could just customers and ecosystem. >> Yeah, so as I mentioned, we've had a very aggressive product lead developer go to market. And so we have 10s of thousands of people now on the service, using Fauna at different levels. And now we're focused on, how do we continue to build that momentum, again, going back to the model of focus on a developer lead model, really what we're focused on there is taking everything that Evan just talked about, which is real and very differentiated in terms of the real core tech in the back end and then combining that with a developer experience that makes it extremely easy to use and really, we think that's the magic in terms of what Fauna is bringing, so we got 10s of thousands of users and we got more signing up every day, coming to the service, we have an aggressive free plan there and then they can migrate up to higher paying plans as they consume over time. And the ecosystem, we're aggressively playing in the broader serverless ecosystem. So what we're looking at is as Evan mentioned, sometimes the databases is the last thing to change, it's also not necessarily the first thing that a developer starts from when they think about building their application or their website. And so we're plugging into the larger serverless ecosystem where people are making their choices about potentially their compute platform or maybe a development platform like I know you've talked to the folks over at JAMstack, sorry at Netlify and Purcell, who are big in the JAMstack community and providing really great workflows for new web and application developers on these platforms. And then at the compute layer, obviously, our Amazon, Google, Microsoft all have a serverless compute solution. CloudFlare is doing some really interesting things out at the edge. And so there's a variety of people up and down that stack, if you will, when people are thinking about this new generation of applications that we're plugging into to make sure that the Fauna is that the default database of choice. >> Wonderful, last question, Evan if I could, I love what I got somebody with your background. Talk about just so many different technologies maturing, give us a little bit as to some of the challenges you see serverless ecosystem, what's being attacked, what do we still need to work on? >> I mean, serverless is in the same place that Lamp was in the in the early '90s. We have the old conservatives ecosystem with the JAMstack players that Eric mentioned. We have closed proprietary ecosystems like the AWS stack or the Google Firebase stack. As to your point, Google has also invested in us so they're placing their bets widely. But it's seeing the same kind of criticism. That Lamp, the Linux, Apache, MySQL, PHP, Perl, it's not mature, it's a toy, no one will ever use this for real business. We can't switch from like DV2 or mumps to MySQL, like no one is doing that. The movement and the momentum in serverless is real. And the challenge now is for all the vendors in collaboration with the community of developers to mature the tools as those the products and applications being built on the new more productive stack also mature, so we have to keep ahead of our audience and make sure we start delivering and this is partly why Eric is here. Those those mid market and ultimately enterprise requirements so that business is built on top of Fauna today, can grow like Twitter did from small to giant. >> Yeah, I'd add on to that, this is reminiscent for me, back in 2009 at Okta, we were one of the early ISVs that built on in relied 100% on AWS. At that time there was still, it was very commonplace for people racking and stacking their own boxes and using Colo and we used to have conversations about I wonder how long it's going to be before we exceed the cost of this AWS thing and we go and run our own data centers. And that would be laughable to even consider today, right, no one would ever even think about that. And I think serverless is in a similar situation where the consumption model is very attractive to get started, some people sitting there, is it going to be too expensive as I scale. And as Evan mentioned, when we think about if you fast forward to kind of what the innovation that we can anticipate both technologically and economically it's just going to be the default model that people are going to wonder why they used to spend all these time managing these machines, if they don't have to. >> Evan and Eric, thank you so much, is great to hear the progress that you've made and big supporters, the serverless ecosystem, so excited to watch the progress there. Thanks so much. >> Thanks Stu. >> Thanks for having us Stu. >> All right and I'm Stu Miniman. Stay tuned. Every week we are putting out the Cloud Native Insights. Appreciate. Thank you for watching. (bright upbeat music)

>> Presenter: From theCUBE studios in Palo Alto in Boston, connecting with thought leaders around the globe, these are cloud native insights. >> Hi, I'm Stu Miniman, the host of Cloud Native Insights. When we launched this program, we talked about, how do we take advantage of the innovation and agility that's in the cloud? And of course, one of the big components that we've talked about for many years on theCUBE is, how do we empower developers? and developers are helping change things, and I'm really happy to welcome to the program first time guests that helped build many of the tools that developers are very well familiar. So Tom Preston Werner, he is the co-founder of Chatterbug, he is the creator of redwoodjs, we had an early episode, the JAMstack Netlify team, he's also on the board for that, and we'll talk about those pieces. People might know him, if you check him out on Wikipedia, you know, GitHub, he was one of the co-founders as well as held both CTO and CEO roles there. I could go on but Tom, thank you so much for joining us. >> Thank you for having me. >> All right, so let's start there, Tom, you know, when I live in the enterprise space, how do you take advantage of new things? One of the biggest challenges out there is, let's go to something new, but let's do it the old way. And we know that that really doesn't take advantage of it you know, I think back to the oldest, some of the older technologies, it's like, well, you know, if I talk to people that are riding horses, what do they want? You know, well, I want faster horses, not the, you know, let's completely change things. I was hearing a stat that, you know, back in the early days of cars, we had like, 30% of them were electric cars, and now it's one. So what's old is new again, but I digress. One, as I mentioned, you know, GitHub, of course, is, you know, such a fundamental piece when we look at in the technology space over the last decade, you know, get in general, GitHub, specifically, of course, has created so much value engaged, you know, just millions and millions of developers and transform businesses. Take us back a little bit and you know, like to get your philosophy on, you know, building tools, how do you do it? How do you think about it? And what's inspired you? >> Yeah, I think it goes a long way back to just wanting to build things for the community. One of the first big projects I worked on was called Gravatar, and I remember laying in bed staring at the ceiling, just trying to think up some idea that that would contribute to what we then called The Blogosphere, and I came up with an idea for avatars that would follow you around and I coded it up and I got it out to a few bloggers and they started using it, and it caught on and it was really, it really introduced me to this idea that no matter who you are, where you come from, or what your background is, you know, I grew up in Iowa, things are very different there. And with with the Internet, and the ability to code, you can impact the world in really significant ways. And so it follows on from there, and I think GitHub is an extension of that desire to really put things into the world that will be useful for people, and knowing that, if you have the ability to code and especially with the advent of web applications as a common tool, there's such power in that you have global reach, you just need a computer and the ability to code and you can create these things, and GitHub kind of became that. It was just, it started out really as a side project, and I hoped that someday it would be able to support me to work on it full time. But I, we started building it just because we wanted it to exist. And that's most of what I work on is, is just ideas that I want to exist in the world. >> Yeah, it's been one of those great trends to watch at, you know, there were certain technologies that used to have to be a nation state, or, you know, one of the one of the global 50 companies to take advantage of it. Now, tools like GitHub, making it so that, you know, the smallest company or even the individuals can participate in communities, can create and build you know, the building is such an important theme. So Maybe, let's fast forward a little bit if we would, I mentioned Netlify and JAMstack, you talked about the blogosphere, that team is helping to really reinvent how we think about the web, you know, it's real time, It's high performance, and you know, we need to be able to get that to where everybody is. So, you know, back in the early days, web pages, you know, relatively static and, you know, had certain criteria, and now, of course, you know, edge devices and the global population change things. So, you know, you, you've been engaged in a, you know, huge supporter of that project, and that'll lead us towards the redwoods discussion, but maybe bring us as to how you got involved there, and what got you excited? >> Well, like you said, Everything old is new again and I think that's true in fashion. It's also true in technology, in a lot of ways, and the JAMstack really is taking these old ideas where the web started, taking files and just serving them as static files and it's super fast, and it's extremely secure. This is how the internet started, and now we've sort of come full circle. But we've added a lot of really nice things and workflows on top of that. And so my journey into the JAMstack, I suppose, started more than a decade ago, when I started working on a project called Jekyll, that's a, I called it at the time, A Blog Aware Static Site Generator. So you would write your blog articles, and you would run it through Jekyll, and that would take your markdown, you'd write your articles in markdown, and it would combine them with a, some kind of a theme that you would have, and that would output static pages that represented your blog, and then you could serve those from any kind of static blog serving system. GitHub had has one built in called GitHub Pages, and so we ended up adopting Jekyll for GitHub Pages. So everything that you put up on GitHub Pages. would be run through Jekyll, and so it was a really natural place to put your blog. And so I had a blog post, one of my blog posts using Jekyll was called Blogging Like A Hacker. And it was this idea that you don't need WordPress, you don't need to have a database somewhere that's, that's hackable, that's going to cause you security problems, all the WordPress admin stuff that constantly is being attacked. You don't need all that, like you can just write articles in flat files, and then turn them into a blog statically and then put those up to serve them somewhere, right? And so when I say it like that, it sounds a little bit like the JAMstack, right? That's not how we thought about it at the time, because it was really hard to do dynamic things. So if you wanted to have comments on your blog for instance, then you needed to have some third party service that you would embed a component onto your blog, so you could receive comments. And so you had to start gluing things together, but even then, again, that sounds a little bit like the JAMstack. So it's all of these ideas that have been, evolving over the last decade to 15 years, that now we finally have an entire tool chain and adding Git on top of that and Git based workflows, and being able to push to GitHub and someone like Netlify can pick those up and publish them, and you have all these third party services that you can glue together without having to build them yourself. All of the billing things, like there's just the ecosystem is so much more advanced now, so many more bits are available for you to piece together that in a very short amount of time, you can have an extremely performant site capable of taking payments, and doing all of the dynamic things that we want to do. Well, many, I should say many of the dynamic things that we want to do, and it's fast and secure. So it's like the web used to be when the web started, but, now you can do all the modern things that you want to do. >> You're giving me flashbacks remembering how I glued discus into my Tumblr instance when that was rolling out. (laughing) >> That's what I was referring to, discuss. >> Yeah, so absolutely, you talk about there's just such a robust ecosystem out there, and one of the real challenges we have out there is, people will come in and they say, "Oh my gosh, where do I start?" And it's like, well, where do you want to go? There's the Paradox of Choice, and that I believe is one of the things that led you to create Redwoods. So help explain to our audience you know, you created this project Redwood, it related to JAMstack, but, but I'll let you explain you know, what it is in life needed? >> Yeah, Redwood is a response to a couple of things. One of those things, is the JavaScript world has, as everything has evolved in tremendous way, in all kinds of ways and almost entirely positive I think. The language itself has been improved so much from when I was a teenager using view source and copy pasting stuff into you know, some random X Files fan site. To now it's a first class language I can compete with with everything, from a ergonomics perspective. I really enjoy programming in it and I come from a Ruby, Ruby on Rails background and now I'm very happy in JavaScript that was not true even five, seven years ago, right? So JavaScript itself has changed a lot. Along with that comes NPM in the whole packaging universe, of availability of modules, right? So most of the things that you want to do, you can go and you can search and find code that's going to do those things for you, and so being able to, to just pull those into your projects so easily. That is amazing, right? The power that that gives you is tremendous. The problem comes in when, like you said, you have the Paradox of Choice. Now you have, not just one way to do something, but you have 100 ways to do something, right? And now as a as a developer, and especially as a new developer, someone who's just learning how to build web applications, you come into this and you say, all you see is the complexity, just overwhelming complexity, and every language goes through this. They go through a phase of sort of this Cambrian explosion of possibilities as people get excited, and you see that the web is embracing these technologies, and you see what's possible. Everyone gets excited and involved and starts creating solution after solution after solution, often times to the same problems. And that's a good thing, right, like exploring the territory is a good and necessary part of the evolution of programming languages and programming ecosystems. But there's comes a time where that becomes overwhelming and starts to trend towards being a negative. And so at Chatterbug, which is a foreign language learning service, if you want to learn how to speak French or Spanish or German, we'll help you do that, as part of that work, we started using react on the front end, because I really love what react brings you from a JavaScript and interactivity perspective. But along with react, you have to make about 50 other choices of technologies to use to actually create a fully capable website, something for state management, you got to choose a way to do JavaScript or sorry, CSS. There's 100 things that you have to choose, and it's, it seems very arbitrary and you go through a lot of churn, you choose one, and then the next day an article comes out and then people raving about another one, and then you choose, you're like, Oh, that one looks really nice. You know, grass is always greener, and so Redwood is a bit of a, an answer to that, or a response to that, which is to say, we've learned a lot of things now about what works in building with react, especially on the front end. And what I really want to do is have a tool that's more like Ruby on Rails, where I come from, having done years and years of Ruby on Rails, what GitHub was built with. And Ruby on Rails presents to you a fully capable web application framework that has made all the choices or most of the choices, many of the important choices. And the same is kind of missing in the JavaScript TypeScript world and so, when I saw Netlify come out with their feature where you could commit the code for a lambda function to your repository, and if you push that up to GitHub, Netlify will grab it, and they will orchestrate deploying that code to an AWS lambda so that you can run business logic in a lambda but without having to touch AWS, because touching AWS is another gigantic piece of complexity, and their user interfaces are sometimes challenging, I'll say. That, that then made me think that, here finally is the ability to combine everything that's awesome about the JAMstack and static files, and security, and this workflow, with the ability to do business logic, and that sounded to me like the makings of a full stack web application framework, and I kept waiting for someone to come out and be like, hey, tada, like we glued this all together, and here's your thing, that's rails, but for the JAMstack, JavaScript, TypeScript world and nobody was doing it. And so I started working on it myself, and that has become Redwoodjs. >> It's one of the things that excited me the early days when I looked into Serverless was that, that low bar to entry, you know, I didn't have to have, you know, a CS degree or five years of understanding a certain code base to be able to take advantage of it. Feels like you're hoping to extend that, it believe it's one of your passions, you know, helping with with Chatterbug and like, you know, helping people with that learning. What do you feel is the state out there? What's your thoughts about kind of the future of jobs, when it when it comes to this space? >> I think the future of jobs in technology and especially software development is, I mean, there is no, there is no better outlook for any profession than that. I mean, this is the, this is where the world is going, more and more of what we want to accomplish, we do in software and it happens across every industry. I mean, just look at Tesla's for instance, right? You think about automobiles and the car that you owned, you know, 10 years ago, and you're like, I don't know, I know there's a computer in here somewhere, but like, I don't really, you know, either the software for it is terrible, and you're like, who, when was the last time you actually use the navigation system in your car, right? You just like get like just turn that off because it's, it's so horrible. And then Tesla comes along and says, hey, what if we actually made all this stuff useful, and had a thoughtful interface and essentially built a car that where everything was controlled with software, and so now cars are are basically software wrapped in hardware, and the experience is amazing. And the same is true of everything, look at your, look at how many things that your phone has replaced that used to be physical devices. Look at manufacturing processes, look at any any element of bureaucracy, all of this stuff is mediated by computers, and oftentimes it's done badly. But this just shows how much opportunity there is speaking of like governmental websites, right, you go to the DMV, and you try to schedule an appointment, and you just have no confidence that that's going to work out because the interfaces feel like they were written 15 years ago, and sometimes I think they were, written that long ago. But there's so much, there's still so much improvement to be had and all of that is going to take developers to do it. Unless, you know, we figure out how to get AI to do it for us, and there's been some very interesting things lately around that angle, but to me, it's, humans will always be involved. And so, at some level, humans are telling machines what to do, whether you're doing it more or less directly, and having the ability to tell machines what to do gives you tremendous leverage. >> Yeah, we're big fans, if you know Erik Bryjolfsson and Andy McAfee from MIT, they've, you know, are very adamant that it's the combination of people plus machines that always will win against either people alone or machines alone. Tom, what, you know, right now we're in the middle of a global pandemic, there're financially, there's a lot of bad news around the globe right now. I've talked to many entrepreneurs that said, well, a downturn market is actually a great time to start something new. You're an investor, you've helped build lots of things. We talked a lot about lowering the bar for people to create and build new things. What do you see are some of the opportunities out there, if you know, you had to recommend for the entrepreneurs out there? Where should they be looking? >> I'd say look at all of the things in your life that have become challenging, because where there's challenge, where there's pain, there's opportunity for solutions. And especially when there's a big environmental change, which we see right now, with COVID-19, obviously has changed a lot of our behaviors and made some of the things that used to be easy. It's made those a lot harder, and so you see, certain segments of the economy are doing extremely well, namely technology and things that allow us to do interviews like this instead of in person, and so those industries are doing extremely well. So you look at the you look at the stock market in the United States, and it's it's very interesting, because while much of the country is suffering, the people that are already wealthy are doing very well, and technology companies are doing very well. And so the question for me is, what are the opportunities that we have, leveraging technology in the internet, to where we can create more opportunities for more people, to get people back to work, right? I think there's so much opportunity there. Just look at education, like the entire concept of educating kids right now and I have three. So we feel this very much, it has been turned on its head. And so we so you see many people looking for solutions in that space, and that's, I think that's as it should be. When things get, when things get challenged when our, our normal daily experience is so radically changed, there's opportunity there, because people are willing to change more quickly in a crisis, right? Because you need, you need something like any solution. And so some choice is going to be made, and where that's happening, then you can find early adopters more easily, than you can under other circumstances, and so in economic downturns, you often see that kind of behavior where these are crisis moments for people, you have an opportunity to come in and if you have something that could solve a problem for them, then you can get a user where that may have not been a problem for a person before. So where there is, where there is a crisis, there is always opportunity to help people solve their problems in different and better ways to address that crisis. So again, it goes back to pain, you know, and it doesn't have to be the pain from a crisis. It could be a pain from from anything. Just like with GitHub, it was, it was hard to share code as developers like it was, there was too much pain, and this was, we started it in 2008, right after the housing crisis. It was unrelated to that, but it turns out that when you start a company, when the economy is depressed in a certain way, then at least you can look forward to the economy getting better as you are building your company. >> Oh, Tom, Preston Werner, thank you so much for joining pleasure talking with you. I appreciate all of your input. >> Absolutely, thanks for having me. >> I'm Stu Miniman, thank you for joining this Episode of cloud native insights. Thank you for watching the theCUBE. (light music)

>>from the Cube Studios in Palo Alto in Boston, connecting with thought leaders around the globe. These are cloud native insights. Hi, I'm stew Minimum and the host of Cloud Native Insights. And the threat that we've been pulling on with Cloud Native is that we needed to be able to take advantage of the innovation and agility that cloud in the ecosystem around it can bring, not just the location. It's It's not just the journey, but how do I take advantage of something today and keep being able to move for Happy to welcome back to the program one of our regulars and someone that I've had lots of discussion about? Cloud Cloud. Native Serverless So Cory Quinn, the Keith Cloud economists at the Duck Bill Group. Corey, always good to see you. Thanks for joining us. >>It is great to see me. And I always love having the opportunity to share my terrible opinions with people who then find themselves tarred by the mere association. And there's certainly no exception to use, too. Thanks for having me back. Although I question your judgment. >>Yeah, you know, what was that? Pandora's box. I open when I was like Hey, Corey, let's try you on video so much. And if people go out, they can look at your feet and you've spent lots of money on equipment. You have a nice looking set up. I guess you missed that one window of opportunity to get your hair cut in San Francisco during the pandemic. But be doesn't may Corey, why don't you give our audience just the update You went from a solo or mentor of the cloud? First you have a partner and a few other people, and you're now you've got economists. >>Yes, it comes down to separating out. What I'm doing with my nonsense from other people's other people's careers might very well be impacted by it considered tweet of mine. When you start having other clouds, economists and realize, okay, this is no longer just me we're talking about here. It forces a few changes. I was told one day that I would not be the chief economist. I smile drug put on a backlog item to order a new business cards because it's not like we're going to a lot of events these days, and from my perspective, things continue mostly a base. The back. To pretend people now means that there's things that my company does that I'm no longer directly involved with, which is a relief, that absolutely, ever. But it's been an interesting right. It's always strange. Is the number one thing that people who start businesses say is that if they knew what they were getting into, they'd never do it again. I'm starting to understand that. >>Yeah, well, Corey, as I mentioned you, and I have had lots of discussions about Cloud about multi Cloud server. Listen, like when you wrote an article talking about multi cloud is a worse practice. One of the things underneath is when I'm using cloud. I should really be able to leverage that cloud. One of the concerns that when you and I did a cube con and cloud native con is does multi cloud become a least common denominator? And a comment that I heard you say was if I'm just using cloud and the very basic services of it, you know, why don't I go to an AWS or an azure which have hundreds of services? Maybe I could just find something that is, you know, less expensive because I'm basically thinking of it as my server somewhere else. Which, of course, cloud is much more than so you do with a lot of very large companies that help them with their bills. What difference there differentiates the companies that get advantage from the cloud versus those that just kind of fit in another location, >>largely the stories that they tell themselves internally and how they wind up adapting to cloud. If the reason I got into my whole feel about why multi cloud is a worst practice is that of you best practices a sensible defaults, I view multi cloud as a ridiculous default. Sure, there are cases where it's important, and so I don't say I'm not suggesting for a second that those people who are deciding to go down that are necessarily making wrong decisions. But when you're building something from scratch with this idea toward taking a single workload and deploying it anywhere in almost every case, it's the wrong decision. Yes, there are going to be some workloads that are better suited. Other places. If we're talking about SAS, including that in the giant wrapper of cloud definition in terms of what was then, sure you would be nuts to wind of running on AWS and then decide you're also going to go with codecommit instead of git Hub. That's not something sensible people to use get up or got sick. But when I am suggesting, is that the idea of building absolutely every piece of infrastructure in a way that avoids any of the differentiated offerings that your primary cloud provider uses is just generally not a great occasionally you need to. But that's not the common case, and people are believing that it is >>well, and I'd like to dig a little deeper. Some of those differentiated services out there there are concerned, but some that said, You know, I think back to the past model. I want to build something. I can have it live ever anywhere. But those differentiated services are something that I should be able to get value out of it. So do you have any examples, or are there certain services that you have his favorites that you've seen customers use? And they say, Wow, it's it's something that is effective. It's something that is affordable, and I can get great value out of this because I didn't have to build it. And all of these hyper scaler have lots of engineers built, building lots of cool things. And I want to take advantage of that innovation. >>Sure, that's most of them. If we're being perfectly honest, there are remarkably few services that have no valid use cases for no customer anywhere. A lot of these solve an awful lot of pain that customers have. Dynamodb is a good example of this Is that one a lot of folks can relate to. It's super fast, charges you for what you use, and that is generally yet or a provision Great. But you don't have to worry about instances. You have to worry about scaling up or scaling down in the traditional sense. And that's great. The problem is, is great. How do I migrate off of this on to something else? Well, that's a good question. And if that is something that you need to at least have a theoretical exodus for, maybe Dynamo DV is the wrong service for you to pick your data store personally. If I have to build for a migration in mind on no sequel basis, I'll pick mongo DB every time, not because it's any easier to move it, but because it's so good at losing data, that'll have remarkably little bit left. Migrate. >>Yeah, Corey, of course. One of the things that you help customers with quite a bit is on the financial side of it. And one of the challenges if I moved from my environment and I move to the public cloud, is how do I take advantage not only of the capability to the cloud but the finances of the cloud. I've talked to many customers that when you modernize your pull things apart, maybe you start leveraging serverless capabilities. And if I tune things properly, I can have a much more affordable solution versus that. I just took my stuff and just shoved it all in the cloud kind of a traditional lift and shift. I might not have good economics. When I get to the cloud. What do you see along those lines? >>I'd say you're absolutely right with that assessment. If you are looking at hitting break even on your cloud migration in anything less than five years, it's probably wrong. The reason to go to Cloud is not to save money. There are edge cases where it makes sense, Sure, but by and large you're going to wind up spending longer in the in between state that you would believe eventually you're going to give up and call it hybrid game over. And at some point, if you stall long enough, you'll find that the cloud talent starts reaching out of your company. At which point that Okay, great. Now we're stuck in this scenario because no one wants to come in and finish the job is harder than we thought we landed. But it becomes this story of not being able to forecast what the economics are going to look like in advanced, largely because people don't understand where their workloads start and stop what the failure modes look like and how that's going to manifest itself in a cloud provider environment. That's why lift and shift is popular. People hate, lift and ship. It's a terrible direction to go in. Yeah, so are all the directions you can go in as far as migrating, short of burning it to the ground for insurance money and starting over, you've gotta have a way to get from where you are, where you're going. Otherwise, migration to be super simple. People with five weeks of experience and a certification consult that problem. It's but how do you take what's existing migrated end without causing massive outages or cost of fronts? It's harder than it looks. >>Well, okay, I remember Corey a few years ago when I talk to customers that were using AWS. Ah, common complaint was we had to dedicate an engineer just to look at the finances of what's happening. One of the early episodes I did of Cloud Native Insights talked to a company that was embracing this term called Been Ops. We have the finance team and the engineering team, not just looking back at the last quarter, but planning understanding what the engineering impacts were going forward so that the developers, while they don't need tohave all the spreadsheets and everything else, they understand what they architect and what the impact will be on the finance side. What are you hearing from your customers out there? What guidance do you give from an organizational standpoint as to how they make sure that their bill doesn't get ridiculous? >>Well, the term fin ops is a bit of a red herring in there because people immediately equate it back to cloud ability before their app. Geo acquisitions where the fin ops foundation vendors are not allowed to join except us, and it became effectively a marketing exercise that was incredibly poorly executed in sort of poisoned the well. Now the finance foundations been handed off to the Cloud Native Beauty Foundation slash Lennox Foundation. Maybe that's going to be rehabilitated, but we'll have to find out. One argument I made for a while was that developers do not need to know what the economic model in the cloud is going to be. As a general rule, I would stand by that. Now someone at your company needs to be able to have those conversations of understanding the ins and outs of various costs models. At some point you hit a point of complexity we're bringing in. Experts solve specific problems because it makes sense. But every developer you have does not need to sit with 3 to 5 days course understanding the economics of the cloud. Most of what they need to know if it's on a business card, it's on an index card or something small that is carplay and consult business and other index ramos. But the point is, is great. Big things cost more than small things. You're not charged for what you use your charger for. What you forget to turn off and being able to predict your usage model in advance is important and save money. Data transfers Weird. There are a bunch of edge cases, little slice it and ribbons, but inbound data transfer is generally free. Outbound, generally Austin arm and a leg and architect accordingly. But by and large for most development product teams, it's built something and see if it works first. We can always come back later and optimize costs as you wind up maturing the product offering. >>Yeah, Cory, it's some of those sharp edges I've love learning about in your newsletter or some of your online activities there, such as you talked about those egress fees. I know you've got a nice diagram that helps explain if you do this, it costs a lot of money. If you do this, it's gonna cost you. It cost you a lot less money. Um, you know, even something like serverless is something that in general looks like. It should be relatively expensive, but if you do something wrong, it could all of a sudden cost you a lot of money. You feel that companies are having a better understanding so that they don't just one month say, Oh my God, the CFO called us up because it was a big mistake or, you know, where are we along that maturation of cloud being a little bit more predictable? >>Unfortunately, no. Where near I'd like us to be it. The story that I think gets missed is that when you're month over, month span is 20% higher. Finance has a bunch of questions, but if they were somehow 20% lower, they have those same questions. They're trying to build out predictive models that align. They're not saying you're spending too much money, although by the time the issues of the game, yeah, it's instead help us understand and predict what's happening now. Server less is a great story around that, because you can tie charges back to individual transactions and that's great. Except find me a company that's doing that where the resulting bill isn't hilariously inconsequential. A cloud guru Before they bought Lennox, I can't get on stage and talk about this. It serverless kind of every year, but how? They're spending $600 a month in Lambda, and they have now well, over 100 employees. Yeah, no one cares about that money. You can trace the flow of capital all you want, but it grounds up to No one cares at some point that changes. But there's usually going to be far bigger fish to front with their case, I would imagine, given, you know, stream video, they're probably gonna have some data transfer questions that come into play long before we talk about their compute. >>Yeah, um, what else? Cory, when you look at the innovation in the cloud, are there things that common patterns that you see that customers are missing? Some of the opportunities there? How does the customers that you talk to, you know, other than reading your newsletter, talking Teoh their systems integrator or partner? How are they doing it? Keeping up with just the massive amount of change that happens out >>there. Get customers. AWS employees follow the newsletter specifically to figure out what's going on. We've long since passed a Rubicon where I can talk incredibly convincingly about services that don't really exist. And Amazon employees won't call me out on the joke that I've worked in there because what the world could ever say that and then single. It's well beyond any one person's ability to keep it all in their head. So what? We're increasingly seeing even one provider, let alone the rest. Their events are outpacing them and no one is keeping up. And now there's the persistent, never growing worry that there's something that just came out that could absolutely change your business for the better. And you'll never know about it because you're too busy trying to keep up with all the other number. Every release the cloud provider does is important to someone but none of its important everyone. >>Yeah, Corey, that's such a good point. When you've been using tools where you understand a certain way of doing things, how do you know that there's not a much better way of doing it? So, yeah, I guess the question is, you know, there's so much out there. How do people make sure that they're not getting left behind or, you know, keep their their their understanding of what might be able to be used >>the right answer. There, frankly, is to pick a direction and go in it. You can wind up in analysis paralysis issues very easily. And if you talk about what you've done on the Internet, the number one responsible to get immediately is someone suggesting an alternate approach you could have taken on day one. There is no one path forward for any six, and you can second guess yourself that the problem is that you have to pick a direction and go in it. Make sure it makes sense. Make sure the lines talk to people who know what's going on in the space and validate it out. But you're going to come up with a plan right head in that direction, I assure you, you are probably not the only person doing it unless you're using. Route 53 is a database. >>You know, it's an interesting thing. Corey used to be said that the best time to start a project was a year ago. But you can't turn back time, so you should start it now. I've been saying for the last few years the best time to start something would be a year from now, so you can take advantage of the latest things, but you can't wait a year, so you need to start now. So how how do you make sure you maintain flexibility but can keep moving projects moving forward? E think you touched on that with some of the analysis paralysis, Anything else as to just how do you make sure you're actually making the right bets and not going down? Some, you know, odd tangent that ends up being a debt. >>In my experience, the biggest problem people have with getting there is that they don't stop first to figure out alright a year from now. If this project has succeeded or failed, how will we know they wind up building these things and keeping them in place forever, despite the fact that cost more money to run than they bring in? In many cases, it's figure out what success looks like. Figure out what failure looks like. And if it isn't working, cut it. Otherwise, you're gonna wind up, went into this thing that you've got to support in perpetuity. One example of that one extreme is AWS. They famously never turn anything off. Google on the other spectrum turns things off as a core competence. Most folks wind up somewhere in the middle, but understand that right now between what? The day I start building this today and the time that this one's of working down the road. Well, great. There's a lot that needs to happen to make sure this is a viable business, and none of that is going to come down to, you know, build it on top of kubernetes. It's going to come down. Is its solving a problem for your customers? Are people they're people in to pay for the enhancement. Anytime you say yes to that project, you're saying no to a bunch of others. Opportunity Cost is a huge thing. >>Yeah, so it's such an important point, Cory. It's so fundamental when you look at what what cloud should enable is, I should be able to try more things. I should be able to fail fast on, and I shouldn't have to think about, you know, some cost nearly as much as I would in the past. We want to give you the final word as you look out in the cloud. Any you know, practices, guidelines, you can give practitioners out there as to make sure that they are taking advantage of the innovation that's available out there on being able to move their company just a little bit faster. >>Sure, by and large, for the practitioners out there, if you're rolling something out that you do not understand, that's usually a red flag. That's been my problem, to be blunt with kubernetes or an awful lot of the use cases that people effectively shove it into. What are you doing? What if the business problem you're trying to solve and you understand all of its different ways that it can fail in the ways that will help you succeed? In many cases, it is stupendous overkill for the scale of problem most people are throwing. It is not a multi cloud answer. It is not the way that everyone is going to be doing it or they'll make fun of you under resume. Remember, you just assume your own ego. In this sense, you need to deliver an outcome. You don't need to improve your own resume at the expense of your employer's business. One would hope, >>Well, Cory, always a pleasure catching up with you. Thanks so much for joining me on the cloud. Native insights. Thank you. Alright. Be sure to check out silicon angle dot com if you click on the cloud. There's a whole second for cloud Native insights on your host to minimum. And I look forward to hearing more from you and your cloud Native insights Yeah, yeah, yeah, yeah, yeah.

>> From theCUBE's studios in Palo Alto, in Boston, connecting with thought leaders around the globe. These are Cloud Native Insights. >> Hi, I'm Stu Miniman, the host of Cloud Native Insights. And when we talk about cloud native, we're talking about how do I take advantage of the agility in innovation, in cloud and the ecosystem out there? And a big question is if I'm a company that's not born in the cloud, or if I'm person that's not steeped in the knowledge of leveraging and using all of these wonderful tools out there, how do I get there? To help us dig into the people and company moving to cloud and adopt the use of these technologies, happy to welcome to the program, Forrest Brazeal. He is a senior manager with A Cloud Guru is his official title, but he is the cloud bard, as many people know in a bard, of course, an oral transition. He creates poems, he sings, he's got a book coming out to illustrate the cloud and really great to be able to talk to you Forrest. Thanks so much for joining us. >> Hey, it's great to be on the show, Stu, thanks for having me. >> All right, so first if you could just share a little bit about your background. So you joined A Cloud Guru, you know, relatively recently, I'd seen some of the cartoons and videos you've done in the past. You've got kind of a renaissance man look, you're not just a tech guy, as I said, you do have some of those musical pursuits also. So I'd love to hear a little of your background. >> Yeah, so I've been an engineer for a long time. I've been an engineer, been a manager of engineers, a consultant, and that's from, you know, startups ranging all the way up to the fortune 50. So I've seen a lot of enterprises in other companies at various stages of their cloud journey. From, you know, just trying to figure out how to get to the cloud out of the data center, all the way to being very cloud native. As you were saying in your intro, you know, figuring out how to build directly on cloud services. I'm very passionate about that. Very passionate about helping people figure out how to take that next step. Not to be a stucker, to get into a state where they are, but to figure out how to get, as I say up the Serverless ladder, right to that next stage of cloud native adoption. And I've realized that, you know, a lot of these technologies and a lot of these concepts, these practices are very abstract. And sometimes what helps the most is to put that in a format that people can engage with. And so I draw and I sometimes sing and I write all sorts of things just to try to help people understand. You know, even though these technologies and practices, these ideas are abstract, they don't have to be difficult, right? Everybody's got some intuitive understanding of why a doctor exists or why a lawyer exists. It's a little bit harder to get your head around, you know, why does a cloud architect exist? What do they build, right? And that's what I try to do with things like the book, The Read Aloud Cloud, that's coming out in just a couple of months. >> All right, so I love that, you know, helping companies understand these things because, you know, for so many years it was like, ah, well we need a mandate for the cloud. You know, cloud, cloud, cloud. When I started this, it was, you know, cloud is not a destination. There is how do we really take advantage of cloud? And there was one post that you wrote talking about lift and shift. And it was one of those things that we've seen for years, there's arguments of, you know, is lift and shift good, if it's bad? And of course the reality is sometimes lift and shift is needed, but it is step one of what you need to do, because if you're not taking advantage of the cloud, the rift reaches a certain point that you say, oh my gosh, maybe I'm not taking advantage of it, maybe the cost don't make sense, and therefore we scrambled and we pull things back and we celebrate repatriation, which to my mind was always, oh, geez, we kind of didn't understand it, we failed. And then we kind of went back to doing what we didn't want to do. So walk us through, if you could, we've even got an illustration of yours that we'll talk about, but you know, give us, you know, what is the proper way that people should think about lift and shift? >> Yeah, exactly. And to be clear, I'm not dissing lift and shift as a concept. It's very necessary in a lot of cases and you can reel off a bunch of reasons why lift and shift would be an important stepping stone in a cloud journey. And of course, that could be just, you know, I've got to get out of the data center, right? Because my lease is expiring or, you know, my servers are haunted and the whole thing is on fire. I've talked to people who, you know, have fireworks stored in their data center, literally that they're afraid are going to go off, right? The roof is leaking. It's time to get out of there and just get to someplace that's professionally managed. You could be using a lift and shift migration almost as like a financial engineering tactic to go from a CapEx to an OPEX model, right? And tie what you're doing a little bit more closely to what you're spending. There's several other reasons that you might choose to have lift and shift is that first stage you might want just to get your feet wet a little bit in cloud. You know, you might not have the confidence or the expertise in-house to build on fully cloud native services right now, you've got to go in and get your Ops teams hands-on right with the technologies and with the tooling so that they understand a little better, how to get you to that next step. But the really, really key thing is lift and shift is a phase you've got to get through it, you've got to keep innovating. And a lot of people don't realize that they think they can go to the cloud, pick up their servers, run them pretty much as they did in the data center, they can stop there, and they're going to get longterm benefits from cloud. And over time, that gets less and less true. Because as I say, once you move that first VM into EC2 or whatever the case may be, you've started a shot clock on your chances for success in the cloud. That clock is ticking cause your initial benefits are very front-loaded. You're potentially getting some initial cost wins as your, hopefully matching your usage a little bit better to what you're spending on infrastructure, right? You're potentially getting some time to learn and plan for version two of your cloud infrastructure. But the longer you stay in that lift and shift states, some dangers are going to start compounding. Because in the absence of a true cloud native strategy, your teams, your Ops teams, your governance teams, if you have those, right? They're going to continue to do things the way they did it in the data center. Because they don't have true SRE, they don't have true automation, they're going to build manual slow error-prone processes that are going to drag down your time to value your MTTR, all those operational metrics at you look at. You're going to see those costs winds actually start to evaporate because you know, you're still running that legacy monolith, You can't effectively charge back spend to different units inside of your business, you realize you're not getting that value, you thought you were running. You know, because you're running the cloud like a data center, and let's be honest, that's super expensive. And then unfortunately over time, and usually you start hitting this threshold 18 months, two years out, your best people, the experts who were bringing you to the cloud in the first place, they get disillusioned because they're not seeing the continued forward motion that they'd been led to believe was going to happen. And so they start moving on, you get brain drain, and now you've created this new legacy swamp of poor procedures and practices, the very thing that you were hoping to avoid. And so at that point, the negative side effects of the lift and shift have overwhelmed, the benefits you thought you were going to get. That's when you're lift and shift shot clock has expired. And that's what you want to avoid by continuing to innovate and continuing to refactor towards a true cloud native deployment. >> Yeah, well, again, I thought that the visual was excellent and it's so good to explain, you know, what is the journey we're going through? What are the decision points? You might look through some of these and say, oh, well, you know, these three definitely apply to my business, some of the others I might not be concerned about, but I can take that and apply it to what I'm doing. So that that's the company side of things. You know, Forrest, you're an AWS Serverless Hero, and also in your day job, your company helps people with the training. So let's talk about people. You know, when it comes to, you know, how do we get involved? One of the things I loved about the Serverless community from the early times that I met it, was, it seemed that the bar to enter was relatively low. So many of these things, it's like, ah, well, do I have the basic skill set? Do I understand how to get there? How do I actually get to where I need to be? And that so many people are hesitant to start that journey, cause it just seems so daunting. So what are you seeing out there? You know, give us the landscape in 2020 as to, you know, how we move forward. And I know you've got a project you've been doing called the cloud resume challenge. So, you know, definitely talk a little bit about that too. >> Yeah, for sure. So look, even going beyond 2020, I think the numbers I've heard, we're looking at potentially a hundred million software developers being added to the workforce over the course of the next decade and change. That's a lot of people who are going to have to interact with these services who are going to have to build and create value on top of cloud infrastructure. And so there's a huge need for us to continue to create abstractions and to create guided, you know, best practices and principles that will help people get where they need to be with as little unnecessary work as possible. And really that's a lot of what underlay the Serverless community and the ideas behind that. I've been involved in Serverless for a long time, going back to when I was, you know, building on Serverless inside of large companies early on in that revolution. And I've carried that forward now with my work as an AWS Serverless Hero, even the work that I'm doing at A Cloud Guru. And really the bar to entry, as you mentioned, is so low, because you're cutting out a lot of things that were seen as sort of gate keeping mechanisms in the past. You know, oh, if you haven't learned this underlying protocol or whatever, then you don't qualify as a real developer. Serverless turns out on its head and says, no, I'm providing you with abstractions that you're going to be able to build on top of. And you're going to be able to focus so much more of your energy on things that actually provide value for the business. And yeah, that kind of started as a very leading edge, early adopter thing, but we're seeing more and more even large enterprises. We're seeing that start to click and they're realizing, you know, wherever I can, wherever I'm not potentially constrained by legacy practices or other code bases, I do want to explore, you know, seeing how quickly I can turn a prototype around, how quickly I can A, B, C, D, E, F, G test something if you will, by spinning up these low cost prototypes in the cloud, right on infrastructure, that's just costing me fractions of a cent to run. There's some really, really compelling avenues that even larger businesses can explore. But taking it back to the individual for a second, Think about, you know, I'm in the middle of a global pandemic, okay? And potentially I'm looking for a career switch now more than ever, I'm thinking, you know, I'd like to get into development, I'd like to get into IT. And it's so close to me now. You look at these services out there, like Networkify which you and I were talking about before the break, right? Talking about how easy those technologies make it for someone to get out there and actually we do web development. But you still need someone to kind of step alongside you and say, you know, these are the things you need to care about, these are things that might be irrelevant. There's an explosion, almost like an infodemic, if you will, of information out there that makes it really hard for folks who are trying to actually skill up, and who're trying to make that transition into tech and into code. That's what A Cloud Guru does of course, which is that the company I work for. We've got about 2.2 million learners on our platform right now that we're helping to scale up and take that step toward the modern tech skills that they need to succeed. The cloud resume challenge, which you mentioned is something I've been doing kind of on the side. And that's a project-based approach that compliments a lot of the additional training that I was talking about. Where we say, you know, I'm going to give you a project, it's going to have some sort of spec based steps to it. So you're going to create a resume, but it's going to be deployed, you know, in the cloud, you're going to have to do some source control, some CICD, some, you know, all these other things that are going to be built into a basic DevOps competency. You're going to have to go away and do some Googling and open some tabs, in order to figure this out on your own cause the project doesn't tell you exactly how to do it. So you actually wind up with some kind of some pain. There's some failure involved there, and that of course is what makes the learning stick. And so we've got people working this on every continent now, we've had many people that have completed it, we've seen people get interviewed. We've seen people get hired coming out of a totally non tech background. So that's really exciting. And you know, those stories, aren't going to be unusual forward. We're going to see more and more of this, and really that's what these cloud abstracting technologies have allowed us to do. Probably it wouldn't be possible to do something like the cloud resume challenge 20 years ago, the barrier to entry with, you know, even just procuring the infrastructure you'd need to be successful in a reasonable amount of time, you know, was accessible to everybody, but now we're there. Those services are at your fingertips. You just need a little bit of guidance, a little bit of curation to get you down the right path. >> Well, yeah, it was actually, you know, what excited me when I first met the ACG team was the bar to entry was so low. In previous decades, you talk about, you know, how much time and how much money I needed to spend just to get some of these courses, even if they were online. And it was just order of magnitudes easier and, you know, built for that cloud environment that I can start I can pause, I have learning resources, and it's been really impressive to watch the expansion of the team there. I'm curious, when you look at, you know, certifications out there, when you look at the need for jobs out there, if I'm not, you know, if I'm in the tech industry, what are some of the things that you think that people should be learning moving forward to? Where would you recommend people start looking there? >> Yeah, absolutely. So I think one thing, a lot of people miss is, you know, it's a good idea to get started with technologies that are new, if you're new. Because let's be real, you can't ask for five years of experience in a technology that's only been around for 18 months. So it's really smart to major on something and get good at something that not a lot of people are good at yet. And you say, well, how do I know that technology is going to take off and succeed? Well, the fact of the matter is even if that specific technology doesn't, you still have a much greater understanding of the problem space, and you'll be right at the cutting edge, ready to jump in on, you know, whatever the next thing is. So I always recommend that people look at things like Serverless and the managed services that are coming out. Get really good at automating, you know, services on the major cloud providers pick AWS, Azure, GCP, right? And just make that your thing, don't specialize in too niche of an area, you know, especially if you're very new, but especially pick a cloud provider, get good at working with the basic services, you'll find that that sets you apart more than, for example, I don't know, going after a certification that's been around for 20 years, that tons and tons of people in the job market have, right? That doesn't necessarily set you apart as much as some of these modern skills do. So I definitely recommend that. >> Yeah, it's funny for us, actually, I laugh a little bit. You mentioned that you've been doing Serverless for a long time, and I'm like, well, okay, I remember sitting in the audience at 80 bus Re-invent when Lambda was unveiled, I think it was re:Invent 2014. So, you know, there's nobody out there that's been, "Oh, I've been doing this for a decade." We always laugh, when there's a job applications out there and say, oh, okay, you know, I want 10 years of a technology that's been around for five years. But yeah, maybe there's one other, a cartoon that you brought along talking about the difference between transition cloud, excuse me, cloud translation and cloud fluency. Maybe just walk through that difference. And especially people that have been in the industry for awhile, how do we make sure that we're actually embracing and understanding and moving to that cloud world, not just, you know, cloud washing? >> Yeah, that's a good word. You know, something that struck me, I think a bit of an epiphany that I had around the time that I started at A Cloud Guru and keep in mind, I'm coming out of years of having worked with these large organizations and try and help them figure out how to migrate to cloud. And what I had seen is there's a lot of these kind of central cloud teams, if you will, that get established right at the beginning of an organization's cloud adoption. And that's a well known pattern, you know, this "cloud center of excellence", if you will, that people establish. A lot of times, those are small teams. You take your best cloud people and you say, okay, you define the standards and the processes that are going to get us to cloud, and they do that. And then they're shocked when nobody adopts the standards, right? And the migration sort of stalls, and they're not having the impact that they expected to have. And what turns out is going on is just having that small group of people who understands cloud, surrounded by this huge legacy, diaspora of legacy, you know, product and engineering teams that don't speak the language of cloud, if you will. Means that anytime you want to innovate, or anytime you want to make a move, you've got to go through this process of translation. You've got to go to those legacy teams who were saying, what's EC2 instance again? You know, how do you spell S3? I thought that I wanted to log into the AWS Console, but this access and secret key, isn't going into my password box, right? You know, they have that low level of competency. And so you're constantly having to explain everything you're going back and forth, and that of course leads to kind of less sophisticated architectures that leads to poor outcomes, and it takes you much longer to get where you want to go. That's that process of cloud translation. That's an anti-pattern. So instead of that, what we try to advocate for is what we call cloud fluency. Just like with any other language you want your entire organization as much as possible to speak the language of cloud at some baseline level. We do that through a couple of things. Of course, obviously through training and certification, cloud certifications can be a great proxy to measure how well your organization's cloud competency is improving. But also through taking those cloud experts, those central experts that previously were kind of in their ivory tower doing their own thing and embed them as much as you can in a roving fashion with these legacy product teams and help them to improve, right? Sort of teach them to fish so that you're not putting all the weight on that central team to be the only experts. Because that doesn't scale, those people are going to burn out. They're going to get overwhelmed with support tickets, we see that over and over again. So you want to empower those teams. And we want to actually talk a little bit less about a cloud center of excellence sometimes, and a little more about a cloud center of enablement, right? Where we want to, instead of knowing the most about cloud, we want to show the most about cloud to those other teams. That's a sustainable pattern for success. That's what we try to do through A Cloud Guru, and that's what I try to advocate for individually, wherever I can, because I've seen people burnt out. I don't want that to happen. >> Yeah, for those of us that have been through a few of these waves here, it's something that you're right, you need to actually be involved in embracing these technologies. You don't have a center for internet usage anymore. If you think about, you know, everybody now for the most part has used the internet, understand some of pieces, it needs to be the same way when it comes to cloud. It just becomes the underlying substrate and, you know, bring forward the innovation and agility that people are looking for. All right, Forrest, last thing we talked about, you've got a book coming out a little bit later this year, The Read Aloud Cloud, give us the quick thing, you know, love, it's visual, is very accessible and definitely looking forward to hearing about that. >> Yes, yes, exciting. So it'll be out in September from Wiley. And basically you've seen a couple of the cartoons over the course of this time here. But, you know, I've been drawing for a long time trying to help people get a sense for what the cloud is and in a way that they can understand and get a grasp on. And so what The Read Aloud Cloud is, it's the history and practice of cloud computing. And it takes you from the mainframe days through artificial intelligence. And along the way, we talk about the basics of cloud architecture, we talk about security, We talk about resilience and all those important things. But it's written and drawn in a way that can be accessible even to a nontechnical person. So the person who's never been able to understand what it is that you do. And I include, you know, potentially your CEO in that conversation, right? This is a book you can hand to them that you can put on your desk, it'll give you a chuckle. But I think there's actually some really strong ability for you to gain actually a concrete visual understanding those really abstract terminologies that float around with cloud. Again, what we're doing is not necessarily complicated, it's just really abstract, it's really arcane. So let's put it in a format where we can get our heads around and hopefully have a good laugh while we're doing it. That's what The Read Aloud Cloud is, and you can check that out, wherever books are sold. >> All right, well Forrest Brazeal. Thank you so much for joining us, real pleasure talking with you. And absolutely we need to make sure that "cloud" becomes as ubiquitous as computers and the internet have before us. Really pleasure chatting with you, thanks so much for joining. >> Awesome, thanks so much Stu, it's great to be here. All right, and I'm Stu Miniman, looking forward to hearing more about your Cloud Native Insights. (bright upbeat music)

>> Narrator: From theCUBE Studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE conversation. >> Hi, I'm Stu Miniman, the host of Cloud Native Insights. And when we kicked off this program, Cloud Native Insights, we wanted to talk about the innovation and agility that's happening, not just Cloud as a location. We're going to draw down a little bit into one of the very important pieces of a company and that's their websites and their applications, that live in that environment. And of course, that comes from a lot of changes over the years. Any of us that have been in tech for a couple of decades have worked from the early days, to of course today's multimedia globally distributed environment and everyone during the global pandemic, of course, has been (indistinct) straining their use of the internet. So really excited to welcome to the program the two co-founders of Netlify. I have Matt Biilmann, who is the CEO, and his co-founder Christian Bach, who is the president both of Netlify really the company behind Jamstack, which we're going to explain and talk about a bit. Matt and Chris, thank you so much for joining us. >> Thanks for having us. >> Thank you for having us >> All right so, let's start with just some of the basics. I expect that some of our audience is not familiar with Jamstack. You do a quick Google search and it's JavaScript, its APIs, its markup. And you say, okay, I understand what a bunch of that means. But, yeah, if you could give us kind of a compare contrast to what web development was before and how Jamstack's really helping to revolutionize what's happening in this space. >> Yes, so for many years, we built websites and web applications with an application based architecture, where every website or every application would be this monolithic application with typically like a load balancer, a set of web servers, application servers, and that database and every request through a page would go through this whole stack it would pass through the application layer, talk to the database, fetch template, merge data and template, build HTML on the fly and send it back to the user. And basically what we saw happening and what's been happening with the Jamstack is this decoupling of the actual front-end presentation layer of the websites and web applications and then the back-end layer. And the advantages there is that if you can really pre-build the front-end application layer, you can take the actual HTML, or an application shell and distribute it across a globally distributed network, you can get it into the hands of the user's browser very quickly. And then the back end, what we've seen happening there is that it's split up to all these different APIs and services you no longer have your one monolithic back end you have all these different services. Where some of your own but a lot of them are other people's services like Stripe or Twilio or Algolia or Contentful. So we've seen this shift to this architecture, where we're considered in a way that the stack has moved up a little from the old tooling where something like the LAMP stack would be common in really naming the programming language, the specific web server, the Linux server, the operating system, and so on right? And then up to a level where it's really about getting an application into the browser, using JavaScript as the runtime and talking to this whole new economy of APIs and services. >> Yeah, Chris I wonder if you could bring us inside your customers and the companies that you talk to. I think about for the longest time it was, maybe I just outsource my web development, but website is one of those key components that I share my value, I share what's going on, I want to be able to change it pretty often and there's so much more that I can do today than I could have done 10 years ago. We've watched that mark. So, help us understand, what skill sets do people need to have? what type of companies are using Jamstack? And, bring in if you can, Netlify. How is this a business and not just, an open source standards movement, that's helping to revolutionize what's happening? >> Absolutely, I mean, First of all, people using this and companies use this is extremely wide. Wide vertical, right? Its very horizontal. This is anyone with a digital property basically, right? I think what we've seen all the time is that, that we have a lot more channels than we used to have, right? So we started off just maybe having the one dot com, right? With limited functionality. And today, you have a multiple channels, right? You have the landing pages, you have the domains, you have lots of activities online. You have mobile apps and commerce is often a big part of it, and I would say especially the last few months, there's a lot of people that had the digital convergence points as one of many. And now it's the only ones, right? So I think it's become extremely important. I also think that when you look at your web infrastructure in general, it has been very complex, right? And you need a lot of different people, right? And you need to maintain staging environments, production lines, development environments. You need to, have a wide set of skills to maintain these things, right? And if a web developer wanted to do a lot of things, right? They have to go and tap DevOps and so on on the shoulder, right? And I think what the Jamstack is about saying, hey, you can get so much further as a web developer. Now, if you take the modern built tools, you can take the Git workflows, and you wrap around the browser that has become a full-fledged operating system and the API economy as Matt was just talking about. You have these workflows, or you potentially have these workflows, where you can get so much further, right? And that's very much Netlify submission. So Netlify saw this opportunity of decoupling the front end from the back end of the building from the hosting of creating an approach to making websites that would be many times faster, 'cause you have multiple points of origin and you don't feel fredurous. It's many times safer. There's not that huge surface area of attack. It's much more scalable, and so on. It was sort of a win-win-win. But the problem was, there was no viable workflow. If you take a traditional CDN, and you put it in, it doesn't matter really, if it's one or the other. As good as they (indistinct) services, they're all meant to sit in front of an origin, right? They're meant to buffer something. And if you have the gems, there's no origin in that way, right? The network in itself has to be an origin so it has to be architectured quite differently. And then there's a lot of things around CDCI and how you server lists and so on. That all had to be sort of re-merged . And Netlify is that glue, it is that platform that takes you from local development all the way out to edge nodes. But allows you to mix and match any tool. So it's not program independent. So you can say, well, we use a build tool, and that's PHP or Ruby or JavaScript, the react or Next or whatever it might be, right? And we use these APIs for this server, for this property. Over here we have a commerce site. Over here, we have a dotcom, that needs a huge enterprise CMS with tons of stakeholders. But the thing is that all of those now becomes something that plugs into your website. Rather than have to drive the website itself. And that's sort of frees up the silos. So when we see people using Netlify, we have companies using Netlify. Big Fitness Company, for example, that own fitness company that uses us for developer documentation, or their marketing sites, but also for their dotcom. But even if you go to the equipment that people have at home, and you log in, that's actually using some very nifty identity and remote based access control for Netlify and if you watch the video there, it's also going through a Netlify player, all right? We have fast food chains that has their dotcom and their marketing sites, but also the kiosks down in the store like the menus, the screens there. Rather than being an old Windows NT server running some .NET application in a dusty corner, why not have it like that? And so, both the category but also Netlify sort of brings in a solution and because it's decoupled from all those architectural choices, that means that you can now use the solution in a much, much wider setting. And we were sort of first to market doing this. They get serverless approach where you just push your serverless functions to get better Netlify. First Feature Deploy Previews Were invented by us and so on. So the Jamstack is an extremely wide fundamental architectural approach that matches basically anyone that wants to build web properties. Netlify is the segnostic wide platform that just makes it possible. >> Yeah, good Chris actually, I saw the Peloton use case up on the website and you're right, a very different experience rather than I bring my device, is it synced? Does it work with it? Really integrates those solutions. And you just brought up serverless, which is actually how I got connected to talk in Netlify. So, Matt, sorry, I think you wanted to jump in there but I was wondering if you could help us. I've looked at serverless and what the promise of serverless of course, is that I don't need to think about that underlying infrastructure. I just like developers build our applications. Well, feels like that's really the same mission that you have. And they're serverless is a piece of your story. So, maybe explain (indistinct) that out a little for us. >> Absolutely, I think it ties in, right? Basically, what we saw just from a architectural perspective was this approach of really decoupling front end and back end and so on and working in a new way that gave a lot of benefits to the inducers in performance and security and so on right? But on the other hand, early on, what we saw was that to adopt that approach, like developers had to deal with lot of different moving pieces like CICD, CDN. What to do about the API endpoints that didn't need to be dynamic, and so on. And as Netlify, what we saw was that we could give one intro and workflow for all of this and make it extremely easy for developers to work with this thing. And serverless plays a really important piece there, right? Because when Amazon pioneered AWS Lambda and took it to the world, right? I think the promise also for the front-end web developers of being able to simply write code and then not have to worry at all about where is it actually running? How are we scaling it? How are we operating it and so on, right? That's a really powerful promise, right? But at the same time, in the same way, what we saw earlier on was that for a front-end team to actually adopt serverless functions as part of the Jamstack, it introduced another level of complexity of now having to manage your serverless functions independent from your front end figuring out API Gateway endpoints for every one of them. And how about deployment pipeline for your functions layer versus deployment pipelines for the actual front end layer that's supposed to talk to those front ends. How about staging environments versus to production environments? How do you manage all that, right? So we saw that there was this inherent incredible potential, but also a lot of complexity, right? And as Netlify we saw that if we could give front end developers a web developers in general, an ene-to-end workflow, where they can work both with the front-end framework, write the code that will get deployed into the browser, but also just have a folder where they can write this serverless functions and then know that Netlify will take care of all of the wiring, right? When you open a pull request and get with new function we'll give you a URL on our globally distributed CDN where you can view both the whole front end, but also the function and sidestep sort of all of the complexities of linking together API Gateways, to functions of managing CICD pipelines and test environments and so on. And in the end, the serverless functions starts becoming a really important part of this Jamstack approach, right? Because you have this world where you have a front end that's often talking to many different APIs and services where again, some of your own and some other people's services. But really often you need some place to glue those together or to build your own custom API endpoint that talks to a couple of them and it has access to server site secrets and so on, right? And this idea of not having to suddenly operate and manage a whole set of servers and infrastructure just for that part of it, but simply just writing the code and then knowing, that you don't have to worry about the operation scalability or anything around that code. That's a really powerful paradigm. >> Yeah, that's one of the real challenges of the Cloud as you talk about the Paradox of Choice. There's so many ways to do things. Not necessarily... It's simple anybody... I was a blogger for many years and it was like, well, I'll just use the self-hosted WordPress, because I don't want to have to worry about that piece of it. Matt, I watched it you did a presentation talking about if I wanted to do WordPress hosted in a AWS that absolutely is not simple. I heard a podcast from one of your board members, Tom Preston Werner, talking about we need to be more opinionated. We need to be able to give more guidance to developers, maybe Chris if you could, how are we when the proliferation of choice, keeps increasing, making sure that people can... How do I make that decision tree? And how do we try to keep it simple? >> Absolutely, I mean, and I actually think that, that's a super relevant question, because you have a lot of choice as a web developer today. Front-end developers used to cut out Photoshop files and turn them into HTML, right? Now with the new advanced markup, and they have all these frameworks and flavors of JavaScript to choose between and there's these powerful build tools, And all those workflows and the browser can do everything you can imagine, right? And so yeah, there is a lot of choice out there, right? And I think, for Netlify what's extremely important is that we are opinionated in the right places. And so when it comes to, for example, a front-end tool and built tools and these things that web developers often face with having to choose between. Our role is to make it as simple as possible to use any of them. But also give you the opportunity of saying, well, this new paradigm allows you to actually mix and match, right? It allows you to use this tool for this property and this tool for this property and gives you a ton of flexibility. But still, come under one roof of a platform like Netlify. And I think that is very powerful. And so we also don't want to choose for you, we want to inform your choices and we want to make it as easy as possible to go and say, hey, these are my needs, what direction should I be going? And of course, we work with enterprise clients, so on migration services, and so on, right? And where we help them a lot with that. But if we locked down on a single flavor, or a single bill tool or a single front end framework, then we also limit the application of what we bring to market and we want to remain a little more open-ended there. But I think there's a lot complexity, a platform like Netlify is all about simplification. So all that wiring that Matt just mentioned, that at least goes, right? You don't spend hours configuring bondage caching and trying to find those edge cases, it just works. And that's a huge game changer for a lot of people, right? But there's definitely parts of the ecosystem that has a lot of choice. And we do our best to inform. And I think, under hand holding part, adjacent to that is the story of, well, do we then start using content management systems? Is this a whole new? Is it out with the old and in with the new? And I would say, you still have a lot of those needs, right? You still have non-technical people, for example, that needs to be able to update and create moves and content, and so on, right? And create content. And so you very often will need and an E-commerce solution or content management systems and so on. But what we're seeing there, is that we're speaking basically with every single major CMS out there. That are saying we're working on a headless system, or we already have a headless version, or we just gone full headless, that means that we work decoupled. So we don't no longer need to build the site. But we just provide like an independent source of content. And then it plugs into a platform like Netlify. So that can bring a lot of simplicity. And now you just have to maintain your content, but you don't have to worry about all the different environments and what is up to date and how does some of the infrastructure look like you press a button that commits to get a default preview, and it looks the same everywhere. >> I'm curious, what impact the current global pandemic has had on Netlify, and your customers. I saw you've got a COVID tracking project that you've done. But also now just there's different considerations when I think about what services I need to access from the web and what kind of connectivity the ultimate end user would have. So, what learnings have you had? What's involved there? >> In, obviously we, it depends a lot on, as Chris mentioned, right? The game circus is adopted horizontally across all kinds of areas and businesses and so on, right? So, we've of course seen businesses in sectors that are having a hard time and on the other hand, we've seen businesses and sectors that are exploding, right? We did immediately when the lockdown started happening and the pandemic started happening we set aside like a free plan for projects working in the space of tackling the information sharing around COVID and finding solutions and so on. And that was really interesting to see you mention the COVID tracking project, right? Which was a project like built a short time by small group of distributed incredibly talented front end developers and scientists and so on, right? And I think it was interesting to see that, how the Jamstack and our tooling and so on also really made it possible for them to build as a small distributed team the set of data information and tooling to a global audience, right? Seeing huge traffic peaks at time and just knowing that their architecture and our infrastructure could handle it for them. >> All right. Chris, I've got one, a little bit off to the side here. When I look at what Netlify is doing, you talk about having an open and independent web. And while we are fully supportive of that, we're a little concerned sometimes. If you look at what's happening across the globe, there's a lot of discussions. Will the internet actually fragment? Will certain countries wall off certain environments? Any concerns there? What do you look at? What are you hearing from your customers when you talk about that mission? >> It's one of the big challenges of all time, right? I think we all maybe took for given the Internet as the standard it became right? The way that you can publish without permission is pretty magnificent, right? And it would be indescribably painful for civilization if we lost that, right? And I think fragmentation is something that we all have to sort of worry around. From the way we see it, is that the web, the traditional monolithic approach, right? To which led to as a web that wasn't secure enough and wasn't scalable enough and wasn't performing enough and that's, for example, what opened the door for mobile applications, right? Where it just didn't make sense to pull in the UI every time you turn the page. So we ended up with a form that's it. We prebuilt the application, you download it, and then you speak to service for anything then atmosphere come up with it, right. And that makes perfect sense. That's basically the same architecture that we're bringing to the web a very large scale. Of course, the problem is that now there are gatekeepers there, right? There people, you have to ask for permission to publish and so on. And, and there are other attempts to say, "Hey, we need a performing web." And there's a very big players out there that say, "Let's come over and just..." Do we even need to call it the Internet? Can we just call it our company website? I'm not going to name any names here, right? But leading down, it's what we've called walled gardens, that are great for absolutely no one except for the company. And what we believe is that if you have a web that is secure and is scalable, and it's performant enough to justify at least the architecture maintaining and not having to run into any walled gardens and still say no, you don't need to use a handful of commercial platforms if you want to be heard rather than have your own web properties on your own custom domains, right? I think that's the part of the open independent viable web that we're fighting for. Basically, one that adopts and keeps adopting an architecture that is something that levels the playing field. And then they would also say, why Netlify? I mean, a few years before we started, like, try configuring your own CDN. And like that was reserved for the very, very large tech players. Now you can comment, you can literally click a button on Netlify, you get custom domain and ACS post process site that's globally distributed, automatically integrated into get. And that's on the premium plan. And so as a startup, you can level set together with everyone else and be available widely across the globe without performance issues, immediately. And so in that way, I'm also seeing that's a democrat sensation of performance, right? That means that, that's great. And for places where you see developing economies, where you often have brownouts, where you often can't depend on having viable services and is locally and so on, this idea of having he cover that and having something that's just automatically, you know what, don't even worry about it, because it's already ready to go in all these packets all around the world. That's a huge game changer. That's actually what we see a lot of adoption of the gems they can never find in those places as well. Guess that's just such a promise to the architecture. So, I hear what you're saying and I'm also very concerned about a fragmented web for political reasons as well across the globe. And from our angle, the way we fight for this is to make sure that it retains using an architecture that makes it accessible for me. >> Yeah, I heard many years ago, a friend of mine said, if you're a technologist it means that in general you are a technology optimist, which I definitely try to be. So, I love Chris how you've just brought in some of the potential opportunity Matt, I want to give you just... People out there they hear like oh, 5G is coming, it's going to completely change the world. Anything that you're seeing on your side as to real opportunities that we will see, just a step function in what your company is using. Jamstack, partnering with Netlify in your ecosystem. What are some of the early things that you see that are exciting you down the line for this? >> Part of it is simply like the whole ecosystem around the gem stalk growing up and the tooling, the APIs, the frameworks available around it, and the level of innovation that's triggered. And especially how it's triggering in... Especially how we're seeing like the potential for small, distributed teams to work together and build things with a global impact in a short time. And I remember a couple of years ago, we did a hackathon with together with freeCodeCamp. And of course, like since it was with freeCodeCamp, it was mostly like teams were mostly fairly new to programming and so on, right? It was pretty amazing to see what over a weekend with this architecture and with this tooling, with the vendors that were present there and helping out and so on, what the small teams could actually get done in a weekend, right? Like I remember the winning team had an app where the whole room would see an image on the main stage screen and then on their phone, try to place that image on the map and you would real time see how people ranked, how close they got and get a winner and so on, right? And that was all just from combining APIs and tooling, like history, like Netlify, like Honor Bee, like Google Maps, and so on, right? And I think, in some way we shouldn't forget just how much this kind of ecosystem of readily available APIs and services around this front end stake. It's allowing people to build things that years ago would have taken a very big team probably like a year to build, and suddenly you can have a relatively small group of relatively new programmers built something really impressive, right? So I think that's a trend we'll see continue accelerating And me and Chris are personally involved in advising and helping out a lot of these new startups in the space that are trying to bring new tooling to the world that makes more and more of these things possible and accessible. >> Well, Chris and Matt, I really appreciate you both joining such an exciting space. Talk about the cloud, agility and innovation, such a robust ecosystem. Thank you so much for joining. >> Thanks for having us. >> Thanks for having us. >> And I'm Stu Miniman. Thank you for joining and look forward to hearing more about your CUBE insight. (soft music)

>> Narrator: From theCUBE Studios in Palo Alto in Boston, connecting with thought leaders around the globe, these are Cloud Native Insights. >> Hi, I'm Stu Miniman the host of cloud native insights. And when we started this weekly program, we look at Cloud Native and you know, what does that mean? And of course, one of the most important topics in IT coming into 2020 was security. And once the global pandemic hit, security went from the top issue to oh my gosh, it's even more important. I've said a few times on the program while most people are working from home, it did not mean that the bad actors went home, we've actually seen an increase in the need for security. So really happy to be able to dig in and talk about what is Cloud Native security, and what should that mean to users? And to help me dig into this important topic, happy to welcome back to the program one of our CUBE alumni Dan Hubbard, he is the CEO of Lacework. Dan thanks so much for joining us. >> Thanks Stu. Happy to be here. >> Alright, so we don't want to argue too much on the Cloud Native term, I agree with you and your team. It's a term that like cloud before, it doesn't necessarily have a lot of meaning. But when we talk about modernization, we talked about customers leveraging the opportunity in innovation and cloud security of course is super important. You know most of us probably remember back, you go back a few years and it's like, "Oh well I adopt cloud. "It's secure, right? "I mean, it should just be built into my platform. "And I should have to think about that." Well, I don't think there's anybody out there at least hopefully there's not anybody out there that thinks that anything that I go to will just be inherently fully secure. So give us a little bit if you would, you know where you see us here in 2020 security's a complex landscape. What are you seeing? >> Yeah, so you know a lot of people as you said, used to talk about what's called the shared responsibility model, which was the cloud provider is responsible for a bunch of things. Like the physical access to the data center, the network, the hypervisor and you know that the core file system and operating system and then you're responsible for everything else that you could configure. But there's something that's not talked about as much. And that's kind of the shared irresponsibility model that's happening within companies where developers are saying they're not responsible for security saying that they're moving too fast. And so what we are seeing is that you know, as people migrate to the cloud or of course are born in the cloud, this notion of DevSecOps, or you know SecDevOps whatever you want to call it, is really about the architecture and the organization. It's not just about technology, and it's not just about people. And it's more about layer seven and eight, than it is about layer one to three. And so there's a bunch of trends that we're seeing in successful companies and customers and prospects will be seeing the market around how do they get to that level of cooperation between the security and the developers in the operation teams? >> Yeah Dan, first of all fully agree with what you're saying. I know when I go to like serverless.com they've got everybody chanting that security is everyone's responsibility. You know I think back to DevOps as a trend, when I read the Phoenix project it was, oh hey, the security is not something that you do bolt on, we're looking at after it's something that you need to shift into everyone thinking about it. Security is just going to be baked in along the process all the way. So the DevOps fail us when it comes to security, why do we need DevSecOps? You know why are you know as you say seven and eight the you know, political and organizational challenges still so much of an issue you know, decades into this discussion? >> Yeah. You know I think there's a few moving parts here and kind of post COVID is even more interesting is that companies have incredibly strategic initiatives to build applications that are core to their business. And in post COVID it's almost existential to their business. If you think of you know, markets like retail and hospitality and restaurants you know, they have to figure out how to digitize and how to deliver their business without potentially physical you know, access to two locations. So as that speed has happened, some of the safety has been left behind. And it's easy to say you have to kind of you know, one of our mantras is to run with speed and safety. But it's kind of hard to run with scissors you know, and be safe at the same time. So some of it is just speed. And the other is that unfortunately, the security people in many ways and the security products and a lot of the security solutions that are out there, the incumbents if you will, are trying to deliver their current solution in a cloud way. So they're doing sometimes it's called Cloud built or you know what I call Cloud washing and they're delivering a system that's not applicable to the modern infrastructure in the modern way that developers are building. So then you have a clash between the teams of like, "Hey I want to do this." And then I'd be like, "No you can't do that get out of our way. "This is strategic to the business." So a lot of it has just been you know, kind of combination of all those factors. >> Alright so Dan, we'll go back to Cloud Native security, you talked about sometimes people are Cloud washing, or they're just taking what they had putting it in the cloud. Sometimes it's just, oh hey we've got a SaaS model on this. Other times I hear cloud native security, and it just means hey I've got some hooks into Containers or Kubernetes. What does modern security look like? Help us understand a little bit. You mentioned some of the you know, legacy vendors what they're doing. I see lots of new security startups, some in you know specifically in that, you know, Kubernetes space. There's already been some acquisitions there. So you know, what do you see out there? You know what's good, what's bad in the trends that you're seeing? >> Yeah so I think the one thing that we really believe is that this is such a large problem that you have to be 100% focused on it. You know if you're doing this, you know, securing your infrastructure and securing your modern applications, and doing other parts of the business whether it's you know securing the endpoints of the laptops of the company and the firewall and authentication and all kinds of other things you have competing interests. So focus is pretty key. And it's obviously a very large addressable problem. What the market is telling us is a few things. The first one is that automation is critical. They may not have as many people to solve the problem. And the problem set is moving at such a scale that it's very, very hard to keep up. So a lot of people ask me you know, what do I worry about? You know, how do I stay awake at night? Or how do I get to sleep? And really the things I'm worried most about in the way where I spend most of my time on the product side is about how fast are builders building? Not necessarily about the bad guys. Now the bad guys are coming and they're doing all kinds of innovative and interesting things. But usually it starts off with the good guys and how they're deploying and how they're building. And you know, the cloud providers literally are releasing API's and new acronyms almost weekly it seems. So like new technology is being created such a scale. So automation the ability to adapt to that is one key message that we hear from the customers. The other is that it has to solve or go across multiple categories. So although things like Kubernetes and Containers are very popular today. The cloud security tackle and challenges is much more complex than that. You've got infrastructure as code, you've got server lists, you've got kind of fragmented workloads, whether some are Containers, some are VMs, maybe some are armies and then some are Kubernetes. So you've got a very fragmented world out there, and all of it needs to be secured. And then the last one is probably the most consistent theme we're hearing is that as DevOps becomes involved, because they know the application and the stack much better than security, it has to fit into your modern workflow of DevOps. So that means you know, deep integrations into Jira and Slack and PagerDuty and New Relic and Datadog are a lot more important in integrating to your you know, Palo Alto firewall and your Cisco IDs system and your endpoint you know antivirus. So those are the real key trends that we're seeing from the customers. >> Yeah Dan, you bring up a really important point, leveraging automation. I'm wondering what you're hearing from customers, because there definitely is a little bit of concern, especially if you take something like security and say, okay well, automation. Is that something that I'm just going to let the system do it? Or is it giving me to getting me to a certain point that then a human makes the final decision and enacts what's going to happen there? Where are we along that journey? >> Yeah, so I think of automation in two lenses. The first lens is efficacy, which is you know do I have to write rules? And do I have to tune train and alter the system over time? Or can it do that on my behalf? Or is there a combination of both? So the notion of people writing rules and building rules is very, very hard in this world because things are moving so quickly. You know, what is the KMS you know threat surface? The threat attacks are just changing. And typically what happens when you write rules is they're either too narrow and you messed up or they're too broad you just get way too much noise. So there's automating the efficacy of the system. That's one that's really critical. The other one that is becoming more important is in the past it was called enforcement. And this is how do I automate a response to your efficacy. And in this scenario it were very, very early days. Some vendors have come out and said you know, we can do full remediation and blocking. And typically what happens is the DevOps team kind of gives the Heisman to the security team it says, "No, you're not doing that." You know this is my production servers, and my infrastructure that's you know running our business, you can't block anything without us knowing about it. So I think we're really early. I believe that you know we're going to move to a world that's more about orchestration and automation, where there's a set of parameters where you can orchestrate certain things or maybe an ops assist mode. You know for example, we have some customers that will send our alerts to Slack, then they have a Slack bot and they say, "Okay, is it okay that Bob just opened "an S3 bucket in this region, yes or no?" No, and then it runs a serverless function and closes it. So there's kind of a what we call driver assist mode versus you know full you know, no one behind the steering wheel today. But I think it's going to mature over time. >> Yeah, Dan one of the other big challenges customer has is that their environments are even more fragmented than they would in the past. So often they're leveraging multiple cloud providers, multiple SaaS providers then they have their hosting providers. And security is something that I need to have holistically across these environments but not have to worry about okay, do I have the skill set and understanding between those environments? Hopefully you know that's something you see out there and want to understand, you know how the security industry in general and maybe Lacework specifically is helping customers, get their arms a little bit more around that multi cloud challenge if you will? >> Yeah. So I totally agree things are you know, I think we have this Silicon Valley, West Coast bias that the world is all you know, great. And it says to utopia Kubernetes, modern infrastructure, everything runs up and down, and it's all you know super easy. The reality is much different. Even in the most sophisticated sets of infrastructure in the most sophisticated customers are very fragmented and diverse. The other challenge that security runs into is security in the past a lot of traditional security mindsets are all about point in time. And they're really all about inventory. So you know, I know used to be able to ask, you know a security person, how many servers do you have? Where are they? What are they doing this? They say, "Oh, you know we have 10 racks with 42 servers in each rack. "And here's our IP addresses." Nowadays, the answer is kind of like, "I don't know what time is it you know, "how busy is a service?" It's very ephemeral. So you have to have a system which can adapt with the ephemeral nature of everything. So you know in the past it was really difficult to spin up, say 10,000 servers in a Asia data center for four hours to do research you know. Security probably know if that's happening, you know they would know through a number of different ways could make big change control window would be really hard they have to ship the units, they bake them in you know, et cetera. Nowadays that's like three lines of code. So the security people have to know and get visibility into the changes and have an engine which can determine those changes and what the risk profile of those in near real time. >> Yeah it's the what we've seen is the monitoring companies out there now talking all about observability. Its real time, it's streamings. You know it reminds me of you know my physics. So you know Heisenberg's uncertainty principle when you try to measure something, you already can't because it's already changed. So what does that mean-- >> Dan: Yeah. >> You know what does security look like in my you know, real time serverless ever changing world? You know, how is it that we are going to be able to stay secure? >> Yeah, so I think there are some really positive trends. The first one is that this is kind of a reboot. So this is kind of a restart. You know there are things we've learned in the past that we can bring forward but it's also an opportunity to kind of clean the slate and think about how we can rebuild the infrastructure. The first kind of key one is that over time security in the traditional data center started understanding less and less about the application over time, what they did was they built this big fortress around it, some called it defense in depth you know, the Security Onion whatever you want to call it you know, the M&M'S. But they were really lacking in the understanding of the application. So now security really has to understand the application because that's the core of what's important. And that allows them to be smarter about what are the changes in their environment, and if those are good, bad or indifferent. The other thing that I think is interesting is that compliance was kind of a dirty word that no one really wanted to talk about. It was kind of this boring thing or auditors would show up once every six months go through a very complex checklist and say you're okay. Now compliance is actually very sophisticated. And the ability to look at your configuration in near real time and understand if you are compliant or following best practices is real. And we do that for our customers all the time. You know we can tell them how they're doing against the compliance standard within a you know, a minute timeframe. And we can tell that they're drifting in and out of that. And the last one and the one that I think most are excited about is really the journey towards least privileges and minimizing the scope of your attack surface within your developers and their access in your infrastructure. Now it's... We're pretty far from there, it's an easy thing to say it's a pretty hard thing to do. But getting towards and driving towards that journey of least privilege I think is where most people are looking to go. >> Alright Dan, I want to go back to something that we talked about early in the conversation, that relationship with the cloud providers themselves, so you know talking AWS, Azure, Google Cloud and the like. How should customers be thinking about how they manage security, dealing with them dealing with companies like Lacework and the ecosystem you mentioned in companies like Datadog and the New Relic? You know how do they sort through and manage how they can maintain those relationships? >> So there's kind of the layer eight relationships, of course which are starting you know in particular with the cloud providers, it's a lot more about bottoms up relationships and very technical understanding of product and features, than it is about being on the golf course, and you know eating steak dinners. And that's very different you know, security and buying IT infrastructure was very relationship driven in the past. Now you really especially with SaaS and subscriptions, you're really proving out your technology every day. You know I say kind of trust is built on consistent positive results over time. So you really have to have trust within your solution and within that service and that trust is built on obviously a lot of that go to market business side. But more often than not it's now being built on the ability for that solution to get better over time because it's a subscription. You know how do you deliver more features and increase value to the customer as you do more things over time? So that's really, really important. The other one is like, how do I integrate the technology together? And I believe it's more important for us to integrate our stack with the cloud provider with the adjacent spaces like APM and metrics and monitoring and with open source, because open source really is a core component to this. So how do we have the API's and integrations and the hooks and the visibility into all of those is really, really important for our customers in the market? >> Well Dan as I said at the beginning, security is such an important topic to everyone out there. You know we've seen from practitioners we talked to for the last few years not only is it a top issue it's a board level discussion for pretty much every company out there. So I want to give you the final word as to in today's you know modern era, what advice do you give to users out there to make sure that they are staying as secure as possible? >> Yeah so you know first and foremost, people often say, "Hey you know, when we build our business, "you know, it'd be a good problem to start have to worry "about customers and you know, "all kinds of people using the service. "And you know, we'll worry about security then." And it's easy lip service to say start it as early as possible. The reality is sometimes it's hard to do that. You've got all kinds of competing interests, you're trying to build a business and an application and everything else depending obviously, the maturity of your organization. I would say that this is a great time to kind of crawl, walk, run. And you don't have to think about it. If you're building in the cloud you don't have to think of the end game you know right away, you can kind of stair step into that. So you know my suggestion to people that are moving into the cloud is really think about compliance and configuration best practices first and visibility, and then start thinking of the more complex things like triage alerts and how does that fit into my workflow? How do I look at breaches down the line? Now for the more mature orgs that are taking, you know an application or a new application or Stack and just dropping it in, those are the ones that should really think about how do I fit security into this new world order? And how do I make it as part of the design process? And it's not about how do I take my existing security stack and move it over? That's like taking, you know a centralized application moving to the cloud and calling it cloud. You know if you're going to build in the cloud, you have to secure it the same way that you're building it in a modern way. So really think about you know, modern, you know new generation vendors and solutions and a combination of kind of your provider, maybe some open source and then a service, of course like Lacework. >> Alright well Dan Hubbard, thank you so much for helping us dig into this important topic Cloud Native security, pleasure talking with you. >> Thank you. Have a great day. >> And I'm Stu Miniman your hosts for Cloud Native Insights and looking forward to hearing more of your Cloud Native Insights in the future. (upbeat music)

>> From theCUBE studios in Palo Alto in Boston, connecting with thought leaders around the globe, these are cloud native insights. >> Welcome to another episode of Cloud Native Insights. I'm your host Stu Miniman and of course with Cloud Native Insights will really help understand you know, where we have gone from cloud, how we are taking advantage of innovation, a real driver for what happens in the spaces of course developers. You think back to the early days, it was often developers that were grabbing a credit card, using cloud services and then it had to be integrated into what was being done and the rest of the organization saw the large rise of DevOps and all the other pieces around that, that help bring in things like security and finance and the like. Happy to welcome to the program first time guest, William Janssen. He is the CEO of DeltaBlue. Deep in this discussion of cloud native DeltaBlue is a European company helping with continuous deployment across cross cloud providers in the space. William, thanks so much for joining us, nice to see you. >> Glad to be on the show, thank you Stu. >> All right, so one of the reasons I'm glad to have you on is because of some of the early episodes here, you know we were discussing really what cloud native is and what it should be. I had my first interview on the program, Joep Piscaer, who you know, had given the analogy and said when you talked about DevOps, DevOps isn't something you could buy. But it's something that lots of vendors would try to sell you. And we're trying to dispel, lots of companies out there, they're like, "Oh, cloud native, well we support Kubernetes. "And we have this tool and you should buy our cloud native, "you know, A, B, C or D." So, want to start a little first with what you see out there and what you think the ultimate goal and outcome of cloud native should be? >> I think cloud native, to start with your last question, I think cloud native should make life fun again. We have a lot of technical problems, we solve them in technical things. You mentioned Kubernetes but Kubernetes is solving a technical problem. And introducing another technical problem. So what I think cloud native should do is focus on what you're actually good at. So a developer should develop. Someone from the infrastructure, an operator, should focus on their key points and not try to mix it up. So, not Kubernetes, Kubernetes is again introducing another technical issue. Our view on cloud native is that people should have fun again and should be focusing on what they're good at. And so it's not about technology, it's about getting the procedures right and focusing on the things you love to do. And not to talk to the cross border, talk to a lot of developers and solve operational kind of things. That's what we try to solve and that's our view of cloud native. >> Yeah, I'll poke that a little bit because one thing you say, people should do what they're good at. It's really what is important for the business, what do we need to get done? There's often new skills that we need to do. So it's really great if we could just keep doing the same thing we're doing. We know how to do it. We optimize it, we play with all of our geek knobs. But the drumbeat that I hear is, we need to be agile, we need to be able to create new applications. IT needs to be responsive for the business and rather than in the past it was about, building this beautiful stack that we could optimize and build these pieces together. Today, the analogy I hear more is, there's layers out there, there's lots of different tooling, especially if you look at the developer world. There is just too many options out there. So, maybe bring us a little bit as to you know, what DeltaBlue does. How you look at allowing developers to build what they, new things that they need but not be, I guess the word, locked into a certain place or certain technology. >> Yes, I've been on IT for 20 years. So I've seen a lot of things go around. And when we started out with DeltaBlue, the only thing we had in mind is how could we make the lifecycle of applications and all the things you had to do, the government around applications way more easy. Back in the days, we already saw that containerization solved some of the issues. But it solves technical issues. So like when you start coding, you don't need to go to the network card anymore. We took the same approach to our cloud native approach. So we started on the top level. We started with applications in mind. And the things back in the day you had Bitnami already had the option to have a VM or standard installation of an application. So what we see is that nowadays, many developers and many organizations try to focus on that specific part, how to get your code into some kind of under configuration solution. We take that for granted. There are so many great solutions out there, already tried to solve that problem. So instead of reinventing that wheel again, we take that for granted. But we take another approach. We think that if the application is there, you need to test it. You need to take it into production. You want to have several versions of a specific application into the production environment. So what we've tried to solve with our platform is to make that part of the life cycle, let's call it horizontal version of your application lifecycle, not getting an application built or running up different stuff, we take that for granted. We take the horizontal approach. How to get your traditional application from your development environment to your testing, acceptance. That's a different kind of people test your application, security testing before you take it into production. And that should be all be done from a logical point of view. So we built one web interface, a logical portal. And you can simply drag and drop any type of application, not just a more than micro service oriented or Kubernetes based application but any type of application from your acceptance environment to your production environment. That's going to solve the real problem. So now, any business can have 10 different acceptance environments for even your old legacy SAP or your Intershop environment. That's going to get your business value. So going back to your definition of cloud native, getting that kind of abstraction between getting your and code your application and get it get somewhere up and running and all the stuff that's needs to be done from your development environment into the production environment. That's going to add to your business value. That's going to speed up your time to market, that's going to make sure that you have a better cloud quality because now you can test even your legacy application from 10 different points of view and 10 different types of different branches, all in a parallel environment. So, when we started with DeltaBlue, we took a different approach, took the technical stuff for granted, and focus on all the government around applications and the governance that's the thing, I think that's the most important part in the cloud native discussion. >> So governance, especially in Europe, has a lot of importance there. If you could, bring us inside a little bit, customers you're talking to, where they are in this journey. If you've got an example of something you're doing specifically we'd love to hear how that happens in real world. >> Yes we have many different customers but I think one of our best examples, for example is Wunderman Thompson, a big eCommerce party across the globe but also here in the Netherlands. And we made a blueprint of their development environment the way they develop application and the way they host applications. So, now they started a new project, 40 developers go to the new big eCommerce application. In the past, everyone had to install their own Intershop environment on their own laptop, Java, Oracle, that kind of stuff. It took me a day and a half. Since we abstracted that into like a simple cell, like you would do in any serverless environment nowadays, they can now simply click on a button. And since they made their laptop or their development environment part of our platform, they can now simply drag and drop the complete initial environment to the laptop and they can send development in 10 minutes instead of a day and a half. That's just the first step that makes their life easier. But also imagine, we have an application up and running for two, three months and our security patch, we all know the trouble of getting a patch installed in production but also then install it into the acceptance environment, test environment, development environment, all those kind of different versions. With our platform, since we have the application in mind, we can, with simple one simple click of the button, we can propagate that security patch across all the different environments. So from a developer point of view, there's no need to have any kind of knowledge of course they need to configure a port or something like that but no need of knowledge of any type of infrastructure anymore. We have made the same blueprint for the complete development environment. So with a single click of the button, they have a complete detail environment, known over the need to go to their infrastructure to get the service to their operating guys, they have them installed, industrial Nexus, very book of repository, all that kind of stuff. It's all within one blueprint. So again, we think that the application should come first. That should be abstracted, and not abstracted just in a single spin up a container or spinning up a VM. Now, the complete business case, application, complete environment should be up and running with a single click of a button. So now they can start if they have a demo tomorrow, for example, and they want to have a demo setup. With a single click, they have a complete environment up and running, instead of having to wait three weeks, four weeks before they can start coding. And the same comes with a production environment. We now have an intelligent proxy in front of it. So they can have three different versions of the same shot in their production environment. And based on business rules, we can spread the load against the different versions of a business application, eCommerce application. We signed a new contract with New Relic last week. And the next thing we're going to do, and it's going to be there in two weeks, is fit New Relic data, I mean, an eCommerce application is about performance. A longer response time of a page page load time will drop your drop your revenue. So what we're going to do with New Relic is feed it's performance data back into that the intelligent proxy in front of their application. So now they're going to drop the new version of their intershop application on a Thursday evening, they go to sleep. Friday morning, they wake up and from the three versions, and the best performing website will be up and running. That's the kind of intelligence and that's the kind of feedback we can put into our platform since we started with applications in mind first. It's getting better quality, because you can do better testing. I mean, we all want to test, but we never want to wait for those different kinds of setups, they want to have fast development cycles. That kind of flexibility where you do the functional deployment, the functional release, not the technical stuff. What we now see in the market is that most people, when they go to the cloud, try to solve the technical release problems of getting the application up and running in a technical way into the production time, we try to focus on the functional level. >> So, William, being data driven, a very important piece of what you talked about there. What I want to help our audience understand is concerns about if you talk about abstractions, or if you want to be able to live across different environments, is can you take advantage of the full capabilities of the underlying platform? Because, that is, one of the reasons we go to cloud isn't just because it's got limitless compute Pricing comes down. But there's only new features coming out, or I want to be able to go to, a cloud provider and take advantage of some specific feature. So help us understand how I can live across these environments, but still take advantage of those cloud native features and innovations as they come out. >> Great. There are actually two ways. For most alternatives, we also have an alternative component in our platform as well. We have complete marketplace with all kinds of functionality like AWS has, but I can imagine that people want to develop an AWS and get our AWS lambda functions or s3 buckets or that that kind of specific functionality. And going back to the Intershop example, they run their application as a CaaS solution on Azure. So when you went to Azure DevOps, or that kind of specific functionality included, our platform connects over 130 different data centers across the globe and Azure and AWS, and Oviedo Digital Ocean are all part of the huge mix of different cloud providers. For every provider, we have what we call gateway components. We deploy natively, mostly bare metal or equivalents of bare metal within those cloud providers. And we made an abstraction layer on the network layer. So now we can include those kind of specific services like they were part of our platform natively. Because if we would have just build a layer and couldn't use the specific components of an AWS or an Azure or that kind of stuff, we would just be another hosting provider. I haven't liked VMware. So that kind of stuff. We want to and we are aware that we need to include a specific stuff, functionality. And what we do with this with what we call gateway components. So we have AWS, gay components, educators, but also for IBM, or Google specific environment. So we can combine the network of AWS, with our specific network. And that's possible, because we made a complete abstraction layer between the network of the infrastructure provider and our network. So we can complete IP subnets DNS resolver as if it was running on their local environment. And thereby, since we have that abstraction layer, we can even move the workloads on AWS to Azure. And since we have the abstraction layer network, we can even make sure that you don't need to reconfigure your application. I think that's the flexibility that people are looking for. And if they have a specific workload and Azure and it's getting too expensive, for the ones that includes AWS stuff, they want to shift the workload to different kind of cloud providers based on the characteristics of a specific worker, or even if you want to have the cheapest option, you can even use your on premise data center. >> William, do that there absolutely is interest in doing that. One of the barriers to being able to just go between environments is of course that the skills required to do this. So, there's something to be said about, if I use a single provider, I understand how to do it, I understand how to optimize it, I understand the finances of it. And while there may be very similar things in another cloud, or in my own data center, the management tools are different and everything. So how do we overcome, that skill set challenge, between different environments. >> We had a different approach the same as we do it on application level, we took it also in data center level, so we're going to handle most cannot say all because there's always specific components. But from our interface, you can simply go to a specific application and select the type of data center you want to run on your application. And if your application is running on an AWS, you get the gateway components with the components, like an s3 bucket or a lambda or an RDS, based on the data center you're running in. So we took that abstraction layer even on that level. But I got to be honest, I think 80% of our customers is not interested in the data center, they run their application in unless they have specific functionality, and which is not available on our platform, or they have a long running application, or use a specific or they bought a specific application. Otherwise, they don't care. Because from a traditional application, there is no difference between running on Azure or Google Cloud or an IBM cloud or whatever. The main difference is that we can make a guarantee about the SLA. I mean, IBM has a better uptime guarantee. A better performance and a better network compared to let's say, digitalocean. Kind of set this up. But there is a huge difference. But it's more like the guarantee that we can give them. So we have this abstraction layers, and we try to put as many as possible as much as possible into our portal interface. There will no way that we're going to redesign and we work about the complete AWS interface, or we're not going to include 100% of their functionality. That's not possible. We're, small company. AWS is somewhat more developers in place. But the main components and people are asking for like RDS or these kind of specific setups, that's where we have the gateway components for available and they can include them into their own application. But we also going to advise them why they were looking for those specific AWS components. Is it within the application architecture or is it something gauges right? Isn't there a better solution or an other solution? And I think, since we have that objection that one of the biggest benefits is, and what we see our customers also do is we incorporate that data center into our platform. And we have one huge network across all the cloud providers and including their own data center. So in the past, they had to have two different development teams, one specialized in AWS development, with all that kind of specific stuff. And all one development team which had more like a traditional point of view, because their internal system and data which was not allowed to go outside the company or had to stay within the firewall. And since we have now one big network, which is transparent to them, we can make sure that their code for their internal systems stays internal and is running on internal systems. But we could still use some kind of functionality from the outside. We do it all unencrypted today, and we have one big platform available. So with our gateway components, we can make sure that that data and application data is really staying internally. And only is allowed to grow internal data access and that kind of stuff, but still use external functionality or price. But again, I would say 80% of our customers, they don't care because they just want to get rid of the burden. I think going back to what we think cloud native means is just getting rid of the burden. And you shouldn't be concerned about what type of cloud we're actually using. >> Absolutely, William, the goal of infrastructure support, my applications and my data and we want companies to be able to focus on what is important for the business and not get bogged down and certain technical arguments introduction. So William, thank you so much for joining us. Really great to hear about Delta blue. Looking forward to hearing more in the future. >> Thank you. >> I'm Stu Miniman. And look forward to hearing more of your cloud native insights.

>> Narrator: From theCUBE studios in Palo Alto in Boston, connecting with thought leaders around the globe, these are Cloud Native Insights. >> Hi, and welcome to another episode of Cloud Native Insights. I'm your host, Stu Miniman. And when we talk about Cloud Native of course, it's not just moving to the cloud as a location, but how do we take advantage of what's happened in the cloud of the changes that need to happen. And this is not only from a technology standpoint, it's an organizational standpoint. And we're also going to touch on the financial implications and something you've probably heard about FinOps, relatively new last couple of years as a term. Of course, the financial engineering cloud has been around for many years and how that ties into DevOps and to help us understand this movement, what's going on really thrilled that we have a practitioner in this space. I want to welcome Sasha Kipervarg. He's a head, the head of Global Cloud Operations in special projects with LiveRamp. Sasha, thanks so much for joining us. >> Thanks very much too, happy to be here. >> All right, so why don't we start off first for those that don't know LiveRamp, I'm sorry, you're in the ad tech space. Maybe just give us a little bit about, you know, the organization and what your team does there? >> Sure, so LiveRamp is in the advertising technology space, and we help connect companies to their customers and send targeted advertising to them. We're based in San Francisco and have engineering teams across the globe, primarily New York, London, China, all over the map, really. And we're a fast growing company, we've gone from perhaps 400 to maybe 12, 1300 employees over the last year and a half. >> Well, you know that whole space is a whole separate discussion. I like when I looked up a little bit about LiveRamp the discussion point is, you know, cookies for eating not for following you, in looking where are you going all over the company. So your role inside LiveRamp, though. Tell us a little bit... You know, we're cloud bits in New York? >> Sure, so I'm responsible for the engineering teams that help other development teams operate in the cloud. So whereas on premise, it would have been a traditional operations team in the cloud. It's basically an engineering team that are experts in all the different areas that other engineering teams need us to be in so that we can express good practices and help them deliver products. >> Great, you actually had a real forcing function for cloud. You know, right now during the global pandemic we've seen lots of acceleration of people looking at cloud, if you could briefly just bring us back as to one of the things that helped push LiveRamp, you know, to go much heavier into cloud. >> Yeah, so we had some initial plans and we were exploring. But what really pushed us over the edge was we had a three to four day outage at our data center here in San Francisco during a heatwave. And during that time, the data center couldn't control their temperature. We had unusually warm temperatures in San Francisco, they weren't that warm. It was like maybe in the, you know, mid 90s. But for the Bay Area in the summertime, you know, where it's usually 70, it was a big deal. And so we had racks of servers going down because it was too hot. And so if we weren't quite convinced before that we certainly were after that, and that made us realize that there were lots of good reasons to be in the cloud. And so we did it. We put together a migration and over the course of a year, we not only containerized but we migrated our environment into GCP. >> I wonder if you could just bring us inside a little bit that move to the cloud, you talk about adopting containerization. You know, your applications, you know, how much of it did you just kind of move there? How much did you build new? Where there some things that you just said, hey, I can kind of, you know, adopt a SAS equivalent, you know, how did your application portfolio look? >> Yeah, so it's probably good to think of them in terms of the infrastructure services that we use in the cloud, and then the customer facing applications themselves. And what we try to do is essentially containerize all of our infrastructure applications. Actually, let me rephrase that. We took the customer facing applications, and we containerize those. Now the applications themselves, did not change but they swapped out their underlying infrastructure for containers, running on the GCP native container service. On the back end of things we use the native services in GCP up as much as possible. So if we were using a database on premise, we tried to use the native database service in the Cloud with Google. I think the one interesting exception to that which we're changing now, in fact, was we decided to run our hundred petabyte Hadoop cluster in the Cloud using our own native service because of some price concerns. Those price concerns have gotten better since time and we're now migrating to Dataproc, which is Google's native Hadoop service. >> Yeah, it's fascinating when you think about just how fast things change in the cloud, new services can become available and as you're alluding to the finances can change significantly over you know, a couple of months or a quarter. Overall, how's the experience been? You know, moving to cloud, though? >> Well, it's been fantastic in some ways, painful in others because, you know, you discover and maybe this is begin to touch on the FinOp stuff like, you discover that you've gone from quarterly planning cycles where you opt to purchase a whole rack of servers, and you implement them over the next quarter or something like that, to making by the second decisions, to spin up resources via command line by developer and spend unlimitless operating expenses. So, it's quite a big shift. And I think a lot of companies are caught, you know, flat footed by it. We certainly work for a little bit. And there's some financial pain that gets expressed. And you know, the question that I would pose to the audience when they think about the cloud is, you know, we think of the migrations and we only think about their technical success, but if you migrate to the cloud and you do it technically and you containerize and it's on schedule, but then you blow your budget, was it really a success? Because ultimately, you know the business needs to be profitable in order for things to work. >> Yeah, absolutely Sasha. So what I've heard you talk about this before is in the pre-cloud model, you met with the budget team quarterly, and it was mostly a look back function. And of course, when you think about leveraging the cloud, things are changing on a fairly regular basis. And are you able to understand what decisions you're making and what the impact will be on you know, next month and next quarters, billing? So bring us inside a little bit as to, you know, that interaction and what that meant to your teams and how they had to think about you know, engineering and finance together? >> Yeah, it's a fantastic question. So, I guess the first thing is, let me let me zoom out for a moment and just make sure that the audience understands that you know, typically it's just engineering leadership, and a fairly small number of maybe high level developers, maybe an architect that get together with finance once a quarter and have a conversation about what they want to spend and how much they want to spend, and where it should be implemented. And that is a fairly regular thing that's been going on for many years. When you move to the cloud, all of a sudden that decision needs to happen on a real time basis. And typically, companies are not set up for that kind of a conversation. There's usually like a large wall between finance and engineering. And it's because you want the engineering teams to be engineers and the finance folks to be doing finance related things. And the two don't really mix all that often. But when you give a developer an API to spend money essentially right, that's what you've done. They don't just spend up resources, they spend money by API. You need to have a real time conversation where they can make trade offs, where you can track the budget, and those expenses shift from something called CapEx to OpEx. And that's treated in a very different way, on the books. Where we are today is we've created what a team, we call it a FinOps practice. But it's a team that's cross functional by nature that sits within engineering that's made up of a FinOps practitioner, person dedicated to the role. And then members of the finance team. And then many other members of engineer and they work together to first, express the cost by helping developers understand what they're actually spending and where they're spending it. And then the system also makes, recommendations about how to optimize and then the developers absorb that information and figure out what they should optimize, do that work. And then the system re-represents the information for them, and lets them know that their optimizations make sense or not from a financial perspective. The way that we've talked to developers, we've discovered that they care about efficiency. They care about efficiency in different ways. They care about CPU efficiency, they care about RAM efficiency. And it turns out, they care about how efficient their application is from a cost perspective to, right? And you can either tell them directly to care about it, or help them become aware. Or you can use proxies, like what I just mentioned about CPU, RAM, disk, network. If they understand how efficient their application is. They have a natural instinct to want to make it better on a daily and weekly basis. It's just sort of baked into their deep engineering persona. And we try to harness that. We try to position things in such a way that they can do the right thing, because most developers want to do the right. >> Yeah, it's really interesting to me Sasha I remember back, you know you go back seven, eight years ago and I looked at cloud models, and how cloud providers were trying to give more visibility and even give guidance to customers as to how they could adjust things to make them more financially reasonable. I've come from the infrastructure side, when I think about you know, deployments in a data center. It was very well understood you had systems engineer work with a customer, they deploy something, they understand what the growth of is expected to be, and if you needed more, more computer, more storage, what the cost of that would be, you understand the you know, how many years you will be writing that off for, but everything's well understood, and as you said, like developers often they've got, n minus one technology, okay, here's some gear you could work on. But finances were clearly written, they were put into some spreadsheet or understood as opposed to the cloud. There is much more burden on the user to understand what they're doing. Because you have that limitless capability as opposed to some fixed asset that you're writing it off. We're huge proponents of ledger than the cloud. And often there are, cost savings by going to the cloud. But it feels like they're also some of this overhead of having to do the financial engineering is an overhead cost that might not be considered in the overall movement to the cloud. >> Yeah, and maybe now is a good time to swing back to the concept of DevOps, right? Because I want to frame FinOps in this concept of having the budget overhead and I want to link it to the Agile, okay. So, part of the reason we moved to DevOps which is an Agile movement that essentially, puts the responsibility of owning infrastructure and deploying it into the hands of the engineers themselves. The reason that it existed was because we had a problem deploying, we had two different teams typically operations and engineering. And one of them would write the code, and they would throw it over the wall to the operations team that will deploy the code. And because they were two different teams, and they didn't necessarily sit together or sometimes even report into the same leadership, they had different goals, right. And when there was a problem, the problem had to cross both of the team boundaries. And so it was slower to resolve issues. And so, people had the bright idea to essentially put the teams together, right. And allow the developers themselves to deploy the code. And of course, depending on the size of the company was structured--or it is structured slightly differently this idea of DevOps. And, essentially what you had was a situation that worked beautifully because if you had two separate teams that all of a sudden became one team that was fully responsible for writing the code, writing the tests and deploying the code, they saw each other's pain, they understood the problem really well. And it was an opportunity for them to go faster, and they could see the powerful thing. And I think that's essentially what made the DevOps movement incredibly successful. It was the opportunity to be able to control their own destiny, and move faster that made it successful. I view FinOps in a similar fashion. It is an opportunity for developers to understand their cost efficiency and deploy in the cloud by API, and do it in a fully responsible way. Everything that we've been talking about related to DevOps, there is a higher goal here. And that is the goal of unit economics, which is figuring out precisely what your application actually costs being deployed and used by the consumer on a unit basis, right. And that is the thing we're all trying to get to. And this FinOps gets us one step closer to that sort of financial nirvana. Now if you can achieve it, or even if you can achieve the basics of it. You can structure your contracts in a different way, you can create products that take better advantage of your financial model. You can destroy certain products that you have, that don't really make sense to operate in the cloud. You can fire customers. You can do a whole variety of things, if you know what your full costs are, and FinOps allows us to do that. And FinOps allows developers to think of their applications in a way that perhaps they never have in a fully transparent, holistic way. Like there's no sense to build a Ferrari, if it costs too much to operate, right. And FinOps helps you get there. >> It's such an important point Sasha. I'm so glad you brought that up, back in the traditional infrastructure data center world, we spent decades talking about Showback and Chargeback and what visibility you had? And of course for the most part, it was, oh well you know, that sunk costs or something that facilities takes care of. I'm not going to work at it and therefore, we did not have a clear picture of IT and how it really impacted the bottom line of business. So FinOps as you said, help move us towards that ultimate goal that we know we've had for years. I want to tease on that thing that you mentioned there, speed. We understand that, absolutely speed is one of the most important things, how do we react to the business? How to react to the customer, as close to real time as possible? How do you make sure that FinOps doesn't slow things down? If I'm an engineer, and I need to think about oh, wait. I've been told that, the best code to write is no code. But, I have to constantly think about, am I being financially sound? Am I doing that? How do we make sure that this movement doesn't slow me down, but actually enables me to move forward faster? >> Yeah I mean, let me mention a couple of things there. The first is that, what I alluded to before, which is that if you don't think about this as a developer, it's possible that the finance folks in the company could decide well hey, operating the cloud doesn't make financial sense for us. And so we're not going to do it and we're going to go back to data center and you maybe that's the right business move for some businesses who aren't growing rapidly, for whom speed and flexibility isn't as important. Maybe they stay in the data center or they go back to a data center. And so like, I would think a developer has stakes in the game, if they want to be flexible, if they want to continue to be flexible. And from a company perspective, like we... You know, this idea still being sort of fleshed out and even within the FinOps movement, like there is a question of how much time should a developer spend thinking about costs stuff? I'll tell you what my answer is, and perhaps I can touch on what other people think about it as well. My answer is that it's best to be transparent with developers as much as possible and share with them as much data as we possibly can, the right kind of data, right? Not overwhelm them with statistics, that help them understand their applications and applications efficiency. And if when you are implementing a FinOps practice within your org, if you get the sense that people are very touchy, and they're not used to this idea of talking about cost directly, you can talk about it in terms of proxies, right. And as I mentioned before, CPU, RAM, disk, network. Those are all good proxies for cost. So if you tell them hey, your application is efficient or inefficient on these different dimensions, go do something about it, right. Like, when you build your next architecture for your application, incorporate efficiencies across these particular dimensions. That will resonate and that will ensure that developers don't feel like it's hampering their speed. I think the cultural shift that FinOps emphasizes is key. This, helping developers get the high level understanding of why we're doing what we're doing and why it's important and embedding it into their not only their architectural design, but their daily operations. That is the key, like FinOps has multiple pieces to it. I think it's successful because it emphasizes a system that's made up of governance practices, rules that tell you how you should behave within the system. Tools like a CMP, and we can talk about that in a bit. But essentially, it's a cost management platform which is a tool that is designed to figure out what you're spending and express it back to you. It's designed to create anomalies and there's a whole segment in the marketplace of these different kinds of tools. And then of course, the cultural shift. If you can do all three at your organization whether you want to call it a FinOps or not, you're going to be set up for success and it will solve that problem for you. >> So Sasha, one of the things I've really enjoyed the last decade or so is it used to be that IT organizations thought what they were doing was, the differentiator and therefore, they were a bit guarded about what they would share. And of course, these days leveraging cloud leveraging open source, there is much more collaboration out there. And LiveRamp, not only is using FinOps, but you're a member of the FinOps Foundation, which has over 1500, individual members participating in that oversaw by the Linux Foundation, maybe bring us in a little bit as to, why LiveRamp decided to join this group. And, for final word on really kind of the mission of the FinOps Foundation. >> Yeah, I mean as members of the audience might know, the FinOps Foundation recently moved to the Linux Foundation, and I think part of that move was to express the independence of the FinOps Foundation, it was connected to a company in a CMP space before and I think J.R and the team made a wonderful decision in doing so. And I wanted to give a shout out to them. I'm very excited about the shift, and we look forward to contributing to the codebase and all the conversations. In terms of how we discovered it. I was feeling the pain of all these different problems of being, over my budget in the cloud. And, I had arrived at like this idea of like, I needed a dedicated person, a dedicated team that was cross-functional in order to solve the problem. But, on a whim, I attended a FinOps course at a conference and Mike Fuller, who was the author or one of the authors of the FinOps book, along with J.R. was teaching it and I spent eight hours just in like, in literal wonder thinking holy crap this guy and whoever came up with this concept put together and synthesized all of the pain that I had felt and all the different things I thought about in order to solve the problem in a beautiful, holistic manner. And they were just presenting it back to me on a platter, back to everyone on a platter and I thought that was beautiful. And the week that I got back to work from the conference, I put together a presentation for the executives to position a FinOps practice as the solution for LiveRamps budgetary cloud pain. We went for it, and we... It's helped us, it's helped lots of other companies. And, I'm here today partly because I want to give back because there's so much that I learned from being in the Slack channel. There's so much that I learned by reading the book, things that I hadn't thought of that I hadn't experienced yet. So I didn't have the pain. But you know, J.R and Mike, they had all interviewed, hundreds of different folks for the book, got lots of input, and they were talking about things that I hadn't experienced yet, that I was going to. And so I want to give back, they clearly want to give back. And I think it's, a wonderful, a wonderful practice, a wonderful book, a wonderful Slack channel. I would recommend that anyone facing the budgetary challenge in the cloud, join the organization There is a monthly conversation, where someone presents and you learn a lot from doing it. You learn problems and solutions that you perhaps wouldn't have thought of, so I would highly recommend it. >> All right, well Sasha thank you so much for sharing your story with our community and everything that you've learned and best of luck going forward. >> Thanks very much Stu. It's great to talk. >> Alright, and if you want to learn more about what Sasha was talking about, Linux Foundation it is this finops.org is their website. Linux Foundation, of course theCUBE. Cloud Native, big piece of what happens and what we're doing will be at theCUBEcon, CloudNativeCon shows this year. Look for more interviews in this space. I'm Stu Miniman. And look forward to hearing more about your Cloud Native Insights. (upbeat music)

(upbeat electronic music) >> Narrator: From theCUBE studios in Palo Alto and Boston, connecting with thought leaders all around the world, this is a CUBE conversation! >> Hi, I'm Stu Miniman, your host for Cloud Native Insight. When we launched this series, one of the things we wanted to talk about was that we're not just using cloud as a destination, but really enabling new ways of thinking, being able to use the innovations underneath the cloud, and that if you use services in the cloud, that you're not necessarily locked into a solution or can't move forward. And that's why I'm really excited to help welcome to the program, I have the co-founders of Vendia. First we have Dr. Tim Wagner, he is the co-founder and CEO of the company, as well as generally known in the industry as the father of Serverless from the AWS Lambda, and his co-founder, Shruthi Rao, she is the chief business officer at Vendia, also came from AWS where she worked on blockchain solutions. Tim, Shruthi, thanks so much for joining us. >> Thanks for having us in here, Stu. Great to join the show. >> All right, so Shruthi, actually if we could start with you because before we get into Vendia, coming out of stealth, you know, really interesting technology space, you and Tim both learned a lot from working with customers in your previous jobs, why don't we start from you. Block chain of course had a lot of learnings, a lot of things that people don't understand about what it is and what it isn't, so give us a little bit about what you've learned and how that lead towards what you and Tim and the team are doing with Vendia. >> Yeah, absolutely, Stu! One, the most important thing that we've all heard of was this great gravitational pull towards blockchain in 2018 and 2019. Well, I was one of the founders and early adopters of blockchain from Bitcoin and Ethereum space, all the way back from 2011 and onwards. And at AWS I started the Amazon Managed Blockchain and launched Quantum Ledger Database, two services in the block chain category. What I learned there was, no surprise, there was a gold rush to blockchain from many customers. We, I personally talked to over 1,092 customers when I ran Amazon Managed Blockchain for the last two years. And I found that customers were looking at solving this dispersed data problem. Most of my customers had invested in IoT and edge devices, and these devices were gathering massive amounts of data, and on the flip side they also had invested quite a bit of effort in AI and ML and analytics to crunch this data, give them intelligence. But guess what, this data existed in multiple parties, in multiple clouds, in multiple technology stacks, and they needed a mechanism to get this data from wherever they were into one place so they could the AI, ML, analytics investment, and they wanted all of this to be done in real time, and to gravitated towards blockchain. But blockchain had quite a bit of limitations, it was not scalable, it didn't work with the existing stack that you had. It forced enterprises to adopt this new technology and entirely new type of infrastructure. It didn't work cross-cloud unless you hired expensive consultants or did it yourself, and required these specialized developers. For all of these reasons, we've seen many POCs, majority of POCs just dying on the vine and not ever reaching the production potential. So, that is when I realized that what the problem to be solved was not a trust problem, the problem was dispersed data in multiple clouds and multiple stacks problem. Sometimes multiple parties, even, problem. And that's when Tim and I started talking about, about how can we bring all of the nascent qualities of Lambda and Serverless and use all of the features of blockchain and build something together? And he has an interesting story on his own, right. >> Yeah. Yeah, Shruthi, if I could, I'd like to get a little bit of that. So, first of all for our audience, if you're watching this on the minute, probably want to hit pause, you know, go search Tim, go watch a video, read his Medium post, about the past, present, and future of Serverless. But Tim, I'm excited. You and I have talked in the past, but finally getting you on theCUBE program. >> Yeah! >> You know, I've looked through my career, and my background is infrastructure, and the role of infrastructure we know is always just to support the applications and the data that run business, that's what is important! Even when you talk about cloud, it is the applications, you know, the code, and the data that are important. So, it's not that, you know, okay I've got near infinite compute capacity, it's the new things that I can do with it. That's a comment I heard in one of your sessions. You talked about one of the most fascinating things about Serverless was just the new creativity that it inspired people to do, and I loved it wasn't just unlocking developers to say, okay I have new ways to write things, but even people that weren't traditional coders, like lots of people in marketing that were like, "I can start with this and build something new." So, I guess the question I have for you is, you know we had this idea of Platform as a Service, or even when things like containers launched, it was, we were trying to get close to that atomic unit of the application, and often it was talked about, well, do I want it for portability? Is it for ease of use? So, you've been wrangling and looking at this (Tim laughing) from a lot of different ways. So, is that as a starting point, you know, what did you see the last few years with Lambda, and you know, help connect this up to where Shruthi just left off her bit of the story. >> Absolutely. You know, the great story, the great success of the cloud is this elimination of undifferentiated heavy lifting, you know, from getting rid of having to build out a data center, to all the complexity of managing hardware. And that first wave of cloud adoption was just phenomenally successful at that. But as you say, the real thing businesses wrestle with are applications, right? It's ultimately about the business solution, not the hardware and software on which it runs. So, the very first time I sat down with Andy Jassy to talk about what eventually become Lambda, you know, one of the things I said was, look, if we want to get 10x the number of people to come and, you know, and be in the cloud and be successful it has to be 10 times simpler than it is today. You know, if step one is hire an amazing team of distributed engineers to turn a server into a full tolerance, scalable, reliable business solution, now that's going to be fundamentally limiting. We have to find a way to put that in a box, give that capability, you know, to people, without having them go hire that and build that out in the first place. And so that kind of started this journey for, for compute, we're trying to solve the problem of making compute as easy to use as possible. You know, take some code, as you said, even if you're not a diehard programmer or backend engineer, maybe you're just a full-stack engineer who loves working on the front-end, but the backend isn't your focus, turn that into something that is as scalable, as robust, as secure as somebody who has spent their entire career working on that. And that was the promise of Serverless, you know, outside of the specifics of any one cloud. Now, the challenge of course when you talk to customers, you know, is that you always heard the same two considerations. One is, I love the idea of Lamdba, but it's AWS, maybe I have multiple departments or business partners, or need to kind of work on multiple clouds. The other challenge is fantastic for compute, what about data? You know, you've kind of left me with, you're giving me sort of half the solution, you've made my compute super easy to use, can you make my data equally easy to use? And so you know, obviously the part of the genesis of Vendia is going and tackling those pieces of this, giving all that promise and ease of use of Serverless, now with a model for replicated state and data, and one that can cross accounts, machines, departments, clouds, companies, as easily as it scales on a single cloud today. >> Okay, so you covered quite a bit of ground there Tim, if you could just unpack that a little bit, because you're talking about state, cutting across environments. What is it that Vendia is bringing, how does that tie into solutions like, you know, Lamdba as you mentioned, but other clouds or even potentially on premises solutions? So, what is, you know, the IP, the code, the solution that Vendia's offering? >> Happy to! So, let's start with the customer problem here. The thing that every enterprise, every company, frankly, wrestles with is in the modern world they're producing more data than ever, IMT, digital journeys, you know, mobile, edge devices. More data coming in than ever before, at the same time, more data getting consumed than ever before with deep analytics, supply chain optimization, AI, ML. So, even more consumers of ever more data. The challenge, of course, is that data isn't always inside a company's four walls. In fact, we've heard 80% or more of that data actually lives outside of a company's control. So, step one to doing something like AI, ML, isn't even just picking a product or selecting a technology, it's getting all of your data back together again, so that's the problem that we set out to solve with Vendia, and we realized that, you know, and kind of part of the genesis for the name here, you know, Vendia comes from Venn Diagram. So, part of that need to bring code and data together across companies, across tech stacks, means the ability to solve some of these long-standing challenges. And we looked at the two sort of big movements out there. Two of them, you know, we've obviously both been involved in, one of them was Serverless, which amazing ability to scale, but single account, single cloud, single company. The other one is blockchain and distributed ledgers, manages to run more across parties, across clouds, across tech stacks, but doesn't have a great mechanism for scalability, it's really a single box deployment model, and obviously there are a lot of limitations with that. So, our technology, and kind of our insight and breakthrough here was bringing those two things together by solving the problems in each of them with the best parts of the other. So, reimagine the blockchain as a cloud data implementation built entirely out of Serverless components that have all of the scale, the cost efficiencies, the high utilization, like all of the ease of deployment that something like Lambda has today, and at the same time, you know, bring state to Serverless. Give things like Lambda and the equivalent of other clouds a simple, easy, built-in model so that applications can have multicloud, multi-account state at all times, rather than turning that into a complicated DIY project. So, that was our insight here, you know and frankly where a lot of the interesting technology for us is in turning those centralized services, a centralized version of Serverless Compute or Serverless Database into a multi-account, multicloud experience. And so that's where we spent a lot of time and energy trying to build something that gives customers a great experience. >> Yeah, so I've got plenty of background in customers that, you know, have the "information silos", if you will, so we know, when the unstructured data, you know so much of it is not searchable, I can't leverage it. Shruthi, but maybe it might make sense, you know, what is, would you say some of the top things some of your early customers are saying? You know, I have this pain point, that's pointing me in your direction, what was leading them to you? And how does the solution help them solve that problem? >> Yeah, absolutely! One of our design partners, our lead design partners is this automotive company, they're a premier automotive company, they want, their end goal is to track car parts for warranty recall issues. So, they want to track every single part that goes into a particular car, so they're about 30 to 35,000 parts in each of these cars, and then all the way from manufacturing floor to when the car is sold, and when that particular part is replaced eventually, towards the end of the lifecycle of that part. So for this, they have put together a small test group of their partners, a couple of the parts manufacturers, they're second care partners, National Highway Safety Administration is part of this group, also a couple of dealers and service centers. Now, if you just look at this group of partners, you will see some of these parties have high technology, technology backgrounds, just like the auto manufacturers themselves or the part manufacturers. Low modality or low IT-competency partners such as the service centers, for them desktop PCs are literally the IT competency, and so does the service centers. Now, most of, majority of these are on multiple clouds. This particular auto customer is on AWS and manufactures on Azure, another one is on GCP. Now, they all have to share these large files between each other, making sure that there are some transparency and business rules applicable. For example, two partners who make the same parts or similar parts cannot see each other's data. Most of the participants cannot see the PII data that are not applicable, only the service center can see that. National Highway Safety Administration has read access, not write access. A lot of that needed to be done, and their alternatives before they started using Vendia was either use point-to-point APIs, which was very expensive, very cumbersome, it works for a finite small set of parties, it does not scale, as in when you add more participants into this particular network. And the second option for them was blockchain, which they did use, and used Hyperledger Fabric, they used Ethereum Private to see how this works, but the scalability, with Ethereum Private, it's about 14 to 15 transactions per second, with Hyperledger Fabric it taps out at 100, or 150 on a good day, transaction through, but it's not just useful. All of these are always-on systems, they're not Serverless, so just provisioning capacity, our customers said it took them two to three weeks per participant. So, it's just not a scalable solution. With Vendia, what we delivered to them was this virtual data lake, where the sources of this data are on multiple clouds, are on multiple accounts owned by multiple parties, but all of that data is shared on a virtual data lake with all of the permissions, with all of the logging, with all of the security, PII, and compliance. Now, this particular auto manufacturer and the National Highway Safety Administration can run their ML algorithms to gain intelligence off of it, and start to understand patterns, so when certain parts go bad, or what's the propensity of a certain manufacturing unit producing faulty parts, and so on, and so forth. This really shows you this concept of unstructured data being shared between parties that are not, you know, connected with each other, when there are data silos. But I'd love to follow this up with another example of, you know, the democratization, democratization is very important to Vendia. When Tim launched Lambda and founded the AWS Serverless movement as a whole, and at AWS, one thing, very important thing happened, it lowered the barrier to entry for a new wave of businesses that could just experiment, try out new things, if it failed, they scrap it, if it worked, they could scale it out. And that was possible because of the entry point, because of the paper used, and the architecture itself, and we are, our vision and mission for Vendia is that Vendia fuels the next generation of multi-party connected distributed applications. My second design partner is actually a non-profit that, in the animal welfare industry. Their mission is to maintain a no-kill for dogs and cats in the United States. And the number one reason for over populations of dogs and cats in the shelters is dogs lost, dogs and cats lost during natural disasters, like the hurricane season. And when that happens, and when, let's say your dogs get lost, and you want to find a dog, the ID or the chip-reading is not reliable, they want to search this through pictures. But we also know that if you look at a picture of a dog, four people can come up with four different breed names, and this particular non-profit has 2,500 plus partners across the U.S., and they're all low to no IT modalities, some of them have higher IT competency, and a huge turnover because of volunteer employees. So, what we did for them was came up with a mechanism where they could connect with all 2,500 of these participants very easily in a very cost-effective way and get all of the pictures of all of the dogs in all these repositories into one data lake so they can run some kind of a dog facial recognition algorithm on it and identify where my lost dog is in minutes as opposed to days it used to take before. So, you see a very large customer with very sophisticated IT competency use this, also a non-profit being able to use this. And they were both able to get to this outcome in days, not months or years, as, blockchain, but just under a few days, so we're very excited about that. >> Thank you so much for the examples. All right, Tim, before we get to the end, I wonder if you could take us under the hood a little bit here. My understanding, the solution that you talk about, it's universal apps, or what you call "unis" -- >> Tim: Unis? (laughs) >> I believe, so if I saw that right, give me a little bit of compare and contrast, if you will. Obviously there's been a lot of interest in what Kubernetes has been doing. We've been watching closely, you know there's connections between what Kubernetes is doing and Serverless with the Knative project. When I saw the first video talking about Vendia, you said, "We're serverless, and we're containerless underneath." So, help us understand, because at, you know, a super high level, some of the multicloud and making things very flexible sound very similar. So you know, how is Vendia different, and why do you feel your architecture helps solve this really challenging problem? >> Sure, sure, awesome! You know, look, one of the tenets that we had here was that things have to be as easy as possible for customers, and if you think about the way somebody walks up today to an existing database system, right? They say, "Look, I've got a schema, I know the shape of my data." And a few minutes later I can get a production database, now it's single user, single cloud, single consumer there, but it's a very fast, simple process that doesn't require having code, hiring a team, et cetera, and we wanted Vendia to work the same way. Somebody can walk up with a JSON schema, hand it to us, five minutes later they have a database, only now it's a multiparty database that's decentralized, so runs across multiple platforms, multiple clouds, you know, multiple technology stacks instead of being single user. So, that's kind of goal one, is like make that as easy to use as possible. The other key tenet though is we don't want to be the least common denominator of the cloud. One of the challenges with saying everyone's going to deploy their own servers, they're going to run all their own software, they're going to build, you know, they're all going to co-deploy a Kubernetes cluster, one of the challenges with that is that, as Shruthi was saying, first, anyone for whom that's a challenge, if you don't have a whole IT department wrapped around you that's a difficult proposition to get started on no matter how amazing that technology might be. The other challenge with it though is that it locks you out, sort of the universe of a lock-in process, right, is the lock-out process. It locks you out of some of the best and brightest things the public cloud providers have come up with, and we wanted to empower customers, you know, to pick the best degree. Maybe they want to go use IBM Watson, maybe they want to use a database on Google, and at the same time they want to ingest IoT on AWS, and they wanted all to work together, and want all of that to be seamless, not something where they have to recreate an experience over, and over, and over again on three different clouds. So, that was our goal here in producing this. What we designed as an architecture was decentralized data storage at the core of it. So, think about all the precepts you hear with blockchain, they're all there, they all just look different. So, we use a no SQL database to store data so that we can scale that easily. We still have a consensus algorithm, only now it's a high speed serverless and cloud function based mechanism. You know, instead of smart contracts, you write things in a cloud function like Lambda instead, so no more learning Solidity, now you can use any language you want. So, we changed how we think about that architecture, but many of those ideas about people, really excited about blockchain and its capabilities and the vision for the future are still alive and well, they've just been implemented in a way that's far more practical and effective for the enterprise. >> All right, so what environments can I use today for your solution, Shruthi talked about customers spanning across some of the cloud, so what's available kind of today, what's on the roadmap in the future? Will this include beyond, you know, maybe the top five or six hyper scalers? Can I do, does it just require Serverless underneath? So, will things that are in a customer's own data center eventually support that. >> Absolutely. So, what we're doing right now is having people sign up for our preview release, so in the next few weeks, we're going to start turning that on for early access to developers. That'll be, the early access program, will be multi-account, focused on AWS, and then end of summer, well be doing our GA release, which will be multicloud, so we'll actually be able to operate across multiple clouds, multiple cloud services, on different platforms. But even from day one, we'll have API support in there. So, if you got a service, could even be running on a mainframe, could be on-prem, if it's API based you can still interact with the data, and still get the benefits of the system. So, developers, please start signing up, you can go find more information on vendia.net, and we're really looking forward to getting some of that early feedback and hear more from the people that we're the most excited to have start building these projects. >> Excellent, what a great call to action to get the developers and users in there. Shruthi, if you could just give us the last bit, you know, the thing that's been fascinating, Tim, when I look at the Serverless movement, you know, I've talked to some amazing companies that were two or three people (Tim laughing) and out of their basement, and they created a business, and they're like, "Oh my gosh, I got VC funding, and it's usually sub $10,000,000. So, I look at your team, I'd heard, Tim, you're the primary coder on the team. (Tim laughing) And when it comes to the seed funding it's, you know, compared to many startups, it's a small number. So, Shruthi, give us a little bit if you could the speeds and feeds of the company, your funding, and any places that you're hiring. Yeah, we are definitely hiring, lets me start from there! (Tim laughing) We're hiring for developers, and we are also hiring for solution architects, so please go to vendia.net, we have all the roles listed there, we would love to hear from you! And the second one, funding, yes. Tim is our main developer and solutions architect here, and look, the Serverless movement really helped quite a few companies, including us, to build this, bring this to market in record speeds, and we're very thankful that Tim and AWS started taking the stands, you know back in 2014, 2013, to bring this to market and democratize this. I think when we brought this new concept to our investors, they saw what this could be. It's not an easy concept to understand in the first wave, but when you understand the problem space, you see that the opportunity is pretty endless. And I'll say this for our investors, on behalf of our investors, that they saw a real founder market-fit between us. We're literally the two people who have launched and ran businesses for both Serverless and blockchain at scale, so that's what they thought was very attractive to them, and then look, it's Tim and I, and we're looking to hire 8 to 10 folks, and I think we have gotten to a space where we're making a meaningful difference to the world, and we would love for more people to join us, join this movement and democratize this big dispersed data problem and solve for this. And help us create more meanings to the data that our customers and companies worldwide are creating. We're very excited, and we're very thankful for all of our investors to be deeply committed to us and having conviction on us. >> Well, Shruthi and Tim, first of all, congratulations -- >> Thank you, thank you. >> Absolutely looking forward to, you know, watching the progress going forward. Thanks so much for joining us. >> Thank you, Stu, thank you. >> Thanks, Stu! >> All right, and definitely tune in to our regular conversations on Cloud Native Insights. I'm your host Stu Miniman, and looking forward to hearing more about your Cloud Native Insights! (upbeat electronic music)

>>from the >>Cube Studios in Palo Alto in Boston, connecting with thought leaders around the globe. >>These are cloud native insights. Hi, I'm stupid, man. And welcome to Episode one of Cloud Native Insights. So this is a new program brought to you by Silicon Angle Media's The Cube. I am your host stew minimum, and we're going to be digging in to cloud native and, of course, cloud native like cloud before kind of a generic term. If you look at it online, there's a lot of buzzwords. There's a lot of jargon out there, and so we want to help. Understand what? This is what This isn't on And really happy to welcome back to the program to help me kick it off you piss car. He is an industry analyst. His company is T l A Tech. You. Thanks so much for joining us. >>Thanks, Dave. Glad we're >>all right. And one of the reasons I wanted you to help me kick this off. Not only have you been on the Cube, you know your background. I met you when you were the cto of a service provider over there in Europe, where you're Netherlands based. You were did strategy for a very large ah, supermarket chain also. And you've been on the program that shows like docker con in the past. You work in the cloud native space you've done consulting for. Some of the companies will be talking about today. But you help me kick this off a little bit. When you heard here the term cloud native. Does that mean anything to you? Did that mean anything back in your previous roles? You know, help us tee that up. >>So, you know, it kind of gives off a certain direction and where people are going. Right. Um so to me, Cloud native is more about the way you use cloud, not necessarily about the cloud services themselves. So, you know, for instance, I'll take the example of the supermarket. They had a big e commerce presence. And so we were come getting them to a place where they could, in smaller teams, deploy software in a faster, more often and in a safer way so that teams could work independently of each other, work on, you know, adding business value, whatever that may be for any kind of different company. That's a cloud native to me, Connie means using that to the fullest extent, using those services available to you in a way organizationally and culturally. That makes sense to you, you know, Go wherever you need to go. Be that release every hour or, you know, transform your s AP environment to something that is more nimble, more flexible, literally more agile. So what cloud native means so many things to so many people? Because it's immediately is not directly about the technology, but how you actually use it. >>Um, and u Pua and I are in, you know, strong agreement on this thing. One is you've noticed we haven't said kubernetes yet. We haven't talked about containers because cloud native is not about the tooling. We're, you know, strong participants in you know, the CN CF activities. The Cloud Native Computing Foundation, cube con and cloud native is a huge show. Great momentum one. We're big fans of too often people would conflate and they'd say, Oh, cloud native equals. I'm doing containers and I've, you know, deployed kubernetes one of the challenges out there. You talk about companies, you know? Well, you know, I had a cloud first initiative and I'm using multi cloud and all this stuff. It's like, Well, are you actually leveraging these capabilities, or did I shove things in something I'd railed about for the last couple of years? You talk about repatriation, and repatriation is often I went to go do cloud. I didn't really understand what I was doing. I didn't understand how to leverage that stuff. And I crawled back to what I was doing before because I knew how to do that. Well, so, you know, I think you said it really well. Cloud native means I'm taking advantage of the services. I'm doing things in a much more modern way. The thing I've loved talking to practitioners and one of things I want to do on this program absolutely is talk to practitioners is how have you gone through things organizationally, there are lots of things right now. Talk about like, thin ops. And, of course, all the spin off from Dev Ops and Dev SEC ops. And, like, how are we breaking through silos? How we're modernizing our environments, how we're taking advantage of new ways of doing things and new services. So yeah, I guess you You know, there are some really cool tools out there. Those are awesome things. But, you know, I love your viewpoint. Your perspective on often people in tech are like, Hey, I have this really cool new tool that I can use, you know? Can I take advantage of that? You know, do I do things in a new way, or do I just kind of take my old way and just make things maybe a little incrementally better? Hopefully with some new tooling. >>Oh, yeah. I mean, I totally agree. Um, you know, tooling is cool. Let me let me start by saying that I You know, I'm an engineer by heart, so I love tinkering with new new stuff. So I love communities I love. Um, you know that a new terra form released, for instance, I love seeing competition in the container orchestration space. I love driving into K native server lists. You know, all those technologies I like, But it is a matter of, you know, what can you do with them, right. So, for instance, has she corporate line of mine? I work on their hashtag off. Even they offer kind of Ah, not necessarily an alternative, but kind of adjacent approach to you what the CNC F is doing, and even in those cases, and I'm up specifically calling out Hashi Corp. But I'm kind of giving. The broader overview is, um, it doesn't actually matter what to use, Even though it'll help me. It'll make me happy just to play around with them. But those new tools have to mean something. They have to solve a particular problem. You have either in speed of delivery or consistency of delivery or quality of service, the thing you are building for your customers. So it has to mean something. So back in the day when I started out in engineering 15 years ago, a lot of the engineering loss for the sake of engineering just because, you know you could create a piece of infrastructure a little faster, but there was no actual business value to be out there. That's a lot of the engineering kind of was stuck inside of its own realm, or as what you see now is, if you can use terraform and actually get all of you know the potential out of you, it allow you to release offer more quickly because you're able to stand up infrastructure for that software more quickly. And so you know, we've kind of shifted from back in the in the attic or in the basement doing I t. Stuff that no one really understands. The one kind of perceives the business value of it into the realm of okay, If we can deploy this faster or we don't even need to use a server, we can use server lists. Then we have an advantage in the marketplace. You know, whatever marketplace that is, whatever application we're talking about. And so that's the difference to me. And that was that. You know, that's what CN CF is doing to me. That is what has she Corpus is helping build. That is what you know. A lot of companies that built, for instance, a managed kubernetes service. But from nine spectral crowd, all those kinds of companies, they will help, you know, a given customer to speed up their delivery, to not care about the underlying infrastructure anymore. And that's what this is all about to me. And that is what cloud native means use it in a way that I don't actually have to do the toil off the engineering anymore. There's loads of smart people working for, you know, the Big Three cloud vendors. There's loads of people working for those manage service providers, but he's used them so that you can speed up your delivery, create better software created faster, make customers happy. >>Yeah, it's a lot to unpack there. I want to talk a little bit about that landscape, right When you talk about, you know, cloud native, maybe a little compare contrast I think about, you know, the wave of Dev ops and for often people like, you know, Dev Ops. You know, that's a cultural movement. But there's also tooling that I could buy to help me along that weighs automation, you know, going agile methodology. See, I CD are all things that you're like. Well, is this part of Dev Ops, isn't it? There's lots of companies out there that we saw rows rode that wave of Dev ops. And if you talk about cloud native, you know the first thing you know, you start with the cloud providers. So when I hear you talking about, how do we get rid of things that we don't need to worry about? Well, for years, we heard Amazon Web services talk about getting rid of undifferentiated heavy lifting. And it's something that we're huge fans off you talk about. What is the business outcome? It's not. Hey, I went from, you know, a stand alone server to I did virtualized environments. And now I'm looking container ization or serverless. What can I get rid of? How do I take advantage of native services and all of those cloud platforms? One of the huge values there is, it isn't Hey, I deployed this and maybe it's a little bit cheaper and maybe a little better. But there's that that is really the center of where innovation is happening not only from the platform providers they're setting themselves, but from that ecosystem. And I guess I'll put it out there. One of the things I would like to see from Cloud Native should be that I should be able to take care of take advantage of innovation wherever it is. So Cloud Native does not mean it must live in the public cloud. It does not necessarily mean that I'm going, you know, full bore, multi cloud everywhere. I've had some great debates with Corey Quinn, on the Cube Online and the like, because if you look at customer environments today, you know, yes, they absolutely have their data centers. They're leveraging, typically more than one public cloud. SAS is a big part of the picture and then edge computing and pulls everything away into a much more distributed architecture. So, you know, I'm glad you brought up. You know, Hashi, a company you're working with really interesting. And if you talk about cloud native, it's there. They're not trying to get people to, oh, use multiple clouds because it's good for us. It's they. Hey, the reality is that you're probably using multiple clouds, and whether it's one cloud or many clouds or even in your data center, we have a set of tools that we can offer you. So you know, Hashi, you mentioned, you know, terra form vault. You know, the various tooling is that they have open source, you know, big play in this environment, both under the CN CF umbrella and beyond. Give us a little bit as to, you know, where are the interesting places where you see either vendors and technology today, or opportunity to make these solutions better for users. >>So that's an interesting question, because I literally don't know where to begin. The spectrum is so so broad, it's all start off with a joke on this, right? You cannot buy that helps. But the vendors were sure try and sell it to you. So it's kind of where you know, the battle is is raging on its getting foothold into an organization. Um, and you see that? You know, you see companies like, how is she doing that? Um, they started out with open source tooling that kind of move into the enterprise realm. Um, you solve the issues that enterprises usually have, and that's what the club defenders will trying to you as although you know, the kind of kick start you with a free service and then move you up into their their stack. And that's you know, that's where Cloud native is kind of risky because the landscape is so fragmented, it is really hard to figure out. Okay, this tool, it actually solves my use case versus this one doesn't. But again, it's in the ecosystem in this ecosystem already, so let's let's still use it just because it's easier. Um, but it does boil the disk a lot of the discussion down into. Basically, it's a friction. How much effort does it take to start using something? Because that's where and that's basically the issues enterprises are trying to solve. It's around friction, and it used to be friction around, you know, buying servers and then kind of being stuck with him for 4 to 5 years. But now it is the vendor lock in where people in organizations have to make tough decisions. You know, what ecosystems am I going to buy into it? It's It's also where a lot of the multi cloud marketing comes from on the way down to get you into a specific ecosystem on your end companies kind of filling that gap, helping you manage that complexity and how she corpus is one of those examples in my book that help you manage that multi cloud ah challenge. So but yeah, But it is all part of that discussion around friction. >>Yeah, and I guess I would start if you say, as you said, it is such a broad spectrum out there. If you look in the developer tooling marketplace is, there's lots of people that have, you know, landscapes out there. So CN cf even has a great landscape. And you know, things like Security, you no matter wherever I am and everywhere that I am. And there's a lot of effort to try to make sure that I can have something that spans across the environment. Of course, Security, you know, huge issue in general. And right now, Cohen, 19. The global pandemic coming on has been, you know, putting a spotlight on it even more. We know shared responsibility models where security needs to be. Data is at the center of what we're talking about when we've been talking for years about companies going through their transformation, I hadn't talked about, you know, digital transformation. What that means is, at the end of the day, you need to be data driven. So there's lots of companies, you know, big movement and things like ml ops. How can I actually harness my data? I said one of the things I think we got out of the whole big data wave. It was that bit flip from, Oh my God, their data everywhere. And maybe that's a challenge for me. It now becomes an opportunity and often times somewhere that I can have new value or even new business models that we can create around data. So, you know, data security on and everyone is modernizing. So, you know, worry a bit that there is sometimes, you know, cloud native washing. You know, just like everything else. It's, you know, cloud enabled. You know, ai ready from an infrastructure standpoint, you know, how much are you actually leveraging Cloud native? The bar, we always said, is, you know, if you're putting something in your data center, how does that compare against what I could get if I'm doing aws azure or Google type of environment? So I have seen good progress over the last couple of years in what we used to call it Private Cloud. And now it's more Ah, hybrid environment or multi cloud. And it looks and acts and is managed much more like the public cloud at a lot of that. Is that driver for developers? So you know Palmer, you know, developers, developers, developers, you know, absolutely. He was right as to how important that is. And one of the things I've been a little bit hardened at is it used to be. You talked about the enterprise and while the developers were off in the corner and, you know, we need to think about them and help enable them. But now, like the Dev Ops movement, we're trying to break down those silos. You know, developers are much more in the workflow. When I look at tools out there not only get hub, you know, you talked about Hashi, you know, get lab answerable and others. Often they have ways to have nothing to developers. The product owners and others all get visibility into it. Because if you can get, you know, people in the organization all accessing the same work stream the way that they need to have it there. There's goodness there. So I guess final question I have for you is you know, what advice do we have for practitioners themselves? Often, the question is, how do I get from where I've been? So where I'm going, This whole discussion of Cloud native is you know, we spent more than a decade talking about cloud, and it was often the kind of where in the movement and the like So what? I want to tee up with cloud native is discussion, really for the next decade. And you know, if I'm, you know, a c i o If I'm in, i t how do I make sure that I'm ready for these next opportunities while still managing? You know what I have in my own environment. >>So that kind of circles back to where we started this discussion, right? Cloud native and Dev ops and a couple of those methodologies they're not actually about the tooling. They are about what to do with them. Can you leverage them to achieve a goal? And so my biggest advice is Look for that goal. First, have something toward towards because if you have a problem, the solution will present itself. Um, and I'm not saying go look for a problem. The problems, they're already It's a matter of, um, you know, articulating that problem in a way that your developers will actually understand what to do. And then they will go and find the tools that are needed to solve that particular problem. And so we turn this around in a sense that so finally, we are at a point where we can have business problems. Actually, solved by I t in a way that doesn't require, you know, millions of upfront investment or, you know, consultants from an outside company. Your developers are now able to start solving those problems, and it will maybe take a while. They may need some outside help Teoh to figure some stuff out, But the point is, we can now use you know, these cloud resource is these cloud native services in such a small, practical way that we can actually start solving these business problems in a real way. >>Yeah, you actually, earlier this year I've done a series of interviews getting ready for this type of environment. You know, one of the areas I spent a bunch of time trying to dig in. And to be frank, understand has been server lists. So, you know, people very excited about server lists. You know, one of the dynamics always is, You know, everything we're talking about with containers and kubernetes driving them to think about that. I always looked as container ization was kind of moving up the stack in making infrastructure easier. The work for applications, but something like serverless it comes, top down. It's it's more of not the tooling, but how do I build those applications in those environments and not need to think at least as much about the infrastructure? So server lists Absolutely something we will cover, you know, containers, kubernetes what I'm looking for. Always love practitioners love to somebody. You you've been, you know, in that end, user it before startups. Absolutely. We'll be talking to as well as other people you know, in the ecosystem that you want to help, have discussions, have debates. You know, we don't have, you know, a strong. You know, this is the agenda that we have for cloud native, but I really want to help facilitate the dialogue. So I'll give you a final word here. Anything You know, what's exciting you these days when you talk to your peers out there, you know, in general, you know, it can be some tools, even though we understand tools are only a piece of it or any other final tips that you have in this market >>space. Well, I want to kind of go go forward on on your statement earlier about server lists without calling, You know, any specific serverless technology out there specifically, but you're looking at those technologies you'll see, But we're now able to solve those business problems. Um, without actually even needing I t right. So no code low code platforms are very adjacent to you to do serverless movement. Um, and that's where you know, that's what really excites me of this at this point, simply because, you know, we no longer need actual hardcore engineering as a trait Teoh use i t to move the needle forward. And that's what I love about the cloud native movement that it used to be hard. And it's getting simpler in a way also more complex in a way. What we're paying someone else Teoh to solve those issues. So I'm excited to see where you know, no code low code survivalism those the kinds of technologies will take us in the next decade. >>Absolutely wonderful. When you have technology that makes it more globally accessible There, obviously, you know, large generational shifts happening in the workforce. You Thank you so much for joining us, >>actually, Sue. >>All right. And I guess the final call to action really is We are looking for those guests out there, so, you know, practitioners, startups people that have a strong viewpoint. You can reach out to me. My emails just stew Stu at silicon angle dot com where you can hit me up on the twitters. I'm just at stew on there. Also. Eso thank you so much for joining us. Planning to do these in General Weekly cadence. You'll find the articles that go along with these on silicon angle dot com. Of course. All the video on the cube dot net I'm stew minimum in and love to hear more about your cloud Native insights >>Yeah, yeah, yeah, yeah, yeah

(soft music) >> From theCUBE studios in Palo Alto, in Boston, connecting with thought leaders all around the world. This is theCUBE Conversation. >> Hi, I'm Stu Miniman coming to you from our Boston area studio here for a CUBE conversation. Really like when we can dig into help some of the nonprofits in our industry, going to be talking about, training, helping other people lift up their careers. Happy to welcome to the program, first time guests, Jerome Hardaway. He's the founder of vets who code coming down from Nashville, Jerome, I seem to remember a time where I was able to travel. I did some lovely hiking even saw bear last time I was down in Nashville. Thanks so much for joining us. Roger that. Thank you, a funny story. I saw a cow on the loose while driving on the highway yesterday. So not much has changed. (Jerome laughs) Thank you guys for having me. >> Yeah, it is a little bit of strange times here in the Covert area. I live kind of suburban Massachusetts area. One of my neighbors did report a small bear in the area. I'm definitely seeing more than just the usual, what kind of wild turkeys and the like that we get up in New England, but let's talk about Vets Who Code. So, you're the founder, the name doesn't leave much up for us to guess what you do, but tell us a little bit as to the inspiration and the goals of your organization. Roger that, Vets Who Code is the first veteran founded, operated and led, a remote 501 C three that focuses on training veterans regardless where they are and modern age of technologies. Our stack right now, I would say is focused more towards front-end DevOps with a lot of serverless technologies being built-in. And that's pretty much what exactly what we do well. >> Well awesome, I had been loving digging into the serverless ecosystem the last few years. Definitely an exciting area, help us understand a little bit, who comes and joins this? What skill set do they have to have coming in? And explain a little bit the programs that they can offer that they can be part of. >> Yeah, cool. So we run Vets Who Code like a mixture between a tech company or a tech nonprofit, I guess, using those practices while also using military practices as well. And the people that come in are veterans and military spouses. And we try to use what we call a pattern matching practice, showcasing like. Hey, these are the things, he's been in military. This is how it translates to the tech side. Like, our sit reps is what you guys would call stand up. Kanban is what we would call like systems checks and frag orders, Op orders, things like that, or, our SLPs. So we turn around, we just train them, retrain them. So that way they can understand the lingo, understand how things, how you code, move and communicate and make sure that these guys and girls, they know how the work as JavaScript engineers and a serverless community. As of right now, we've helped 252 veterans in 37 States get jobs, our social economic impacts, then I think it's at 17.6 million right now. So it all from the comfort of their homes, that's like the cool and free, and those are like the coolest things that we've been able to do. >> Wow, that's fascinating. Jerome, I heard something that you've talked about, leveraging the military organizational styles. I'm just curious, there's in the coding world a lot of times we talk about Conway's law, which is that the code will end up resembling the look of the organization. And you talk about DevOps, DevOps is all about various organizations collaborating and working together. It seems a little bit different from what I would think of traditional military command and control. So is that anything you've given any thought to? Is there some of the organizational pieces that you need to talk to people about? Moving into these environments compared to what they might've had in the military. >> Negative, I think the biggest misconception that we have is that people, when you're talking about how the military moves, they're thinking of the military of yesteryear of 20, 30, 40 years ago. They're not thinking of global war on terrorism veterans and how we move and things like that. We understand distributed chains. We understand cause we call, that's what we've done at CENTAF and CENTCOM in Iraq and Afghanistan. So we honored, like we are already doing a lot of this stuff, we just naming it different. So that's part of the thing that we have as an advantage as the, cause all the people who are educators, there are veterans who learn how to code and they've been working in industry and they know. And so when they're teaching, they know the entire process that a veteran's going to go through. So that's how now we focus on things. And so the organizational structure for us first term to second term veterans is pretty normal. If you're coming out within the last, heck 10 years. (Jerome laughs) >> Yeah, absolutely. That's wonderful. And I I've had the opportunity to work with plenty of people that had come from the military. Very successful in the tech industry, definitely tend to be hard workers and engaged in what they'r doing. Curious, you talked about being able to do this remotely and then it is free. What's the impact of the current global pandemic? Everything that's happening here in 2020 been on what you're doing in your resources. >> Of the impact, unfortunately, I mean, not unfortunately, fortunately it has been nothing but positive. It's been crazy, we've gotten more applications. We have people are seeing that during, I was the crazy person in the room, when in 2014, when I was saying nonprofits should move to remote first protocols. So that way they could have greater impact for less, with less financial resources. And back then I was the, like what are you talking about? This is the way we've always done. Well now everybody was scrambling to try to figure out how to help people without being in same room with them. We were like, Oh, okay, lt's do today. So we got an influx of people applying, influx of people, sending me, trying to get into our next cohort in August. It's just, the biggest thing that has happened for Vets Who Code is yet, it's been a really positive experience for us, which is really weird to say, but I think it has, my doomsday Murphy's law style of preparing, I assume that anything that can go wrong will go wrong. So I try to prepare for that. So being open source, being serverless, being having everything in a manner to where--in case I was out of the pot, out of the situation, other people operate having this distributed teams, or there are other leaders that can take over and do things. It's all stuff that, I guess I got from the military. So, we were know we were prepared because there was absolutely zero pivot for us. If anything, it has been more resources. We've been able to dive deeper in more subjects because people have had more time, but, we can do, we can dive deeper into AWS. We started a lunch and learn every two weeks. We actually have a lunch and learn next week with Dr. Lee Johnson. And she's going to be talking, we open that to it by all juniors and entry level devs, developers, regardless of whether you're a veteran or not, we just throw it on Twitter and let them get in. And the focus will be on tech ethics. We all know, right now we've been leading the charge on trying to make sure people are supercharging their skills during this time frame. So that's what, it's been very positive. I've been working with magazine, front-end masters. It's been awesome. >> Well, that's wonderful. Wish everyone had the mindset coming into 2020, because it does seem that anything that could go wrong has, (both laugh) I'm curious, once people have skilled up and they've gone through the program, what connections do you have with industry? How do you help with job placement in that sort of activity? >> That is the most asked question, because that is the thing that people expect because of code schools, because of our educational program protocols. We don't really need that issue because our veterans are skilled enough to where to hiring managers know the quality that we produce. I live in Nashville and I've only been able to place one veteran that I've trained locally in the community because of fame companies have snatched up every other veteran I've ever trained in the community, so things like that, it's not a problem because no, a usually 80% of our veterans have jobs before they even graduate. So you're literally picking up, picking people who, they know they have the potential to get a bit companies if they put the work in and it's just as they come, we actually have people. I think a company reached out to me yesterday and I was like, I don't even have people for you. They already have jobs. (jerome laughs) Or I'm in a situation now where all my senior devs are looking for fame companies. Cause that's one of the things we do is that we support our veterans from reentry to retirement. So we're not like other code schools where they only focus on that 30 to 60 to 90 days, so that first job, our veterans, they keep coming back to re-skill, get more skills, come up to the lunch and learns, come to our Slack side chats to become better programmers. And once they're, so we've helped several of our programmers go from entry-level dev to senior dev, from absolutely zero experience. And so, I think that's the most rewarding thing. When you see a person who they came in knowing nothing. And three years later, like after the cohort safe they got their job and then they come back after they got the jobs, they want to get more skills and they get another job and then they come back. And the next thing, my favorite, one of my favorites Schuster, he starts at a local web shop, a web dev shop in Savannah, Georgia. And then next thing, oh, he's on Amazon, he's at Amazon three years later and you're like, Oh wow, we did that, that's awesome. So that's the path that we do is awesome. >> I'm curious, are there certain skill sets that you see in more need than other? And I'm also curious, do you recommend, or do you help people along with certain certifications? Thinking, the cloud certifications definitely have been on the rise, the last couple years. >> I feel like the cloud, the cloud certifications have been on the rise because it's expensive to like test for that stuff. If a person messes up, unless you have a very dedicated environment to where they can't mess up, they can cost you a lot of money, right? So you want that certain, right? But for us, it's been, we just focused on what we like to call front-end DevOps. We focus on Jamstack, which is JavaScript, APIs and markup, also along with a lot of serverless. So we're using AWS, we're using, also they're, they're learning Lambda functions, all this stuff. We're using a query language called GraphQL. We're using Apollo with that query language. We're using some node, React, GET, Speed. And a lot of third party API has to do like a lot of heavy lifting cause we believe that the deeper dive that a person has in a language and being able to manipulate and utilize APIs that they can, the better they will be, Right? So, same way that colleges do it, but a more modern take like colleges, they give you the most painful language to learn, which is usually like C right? Where you had to make everything a very low-level language. And then you're going through this process of building. And because of that, other languages are easier because you felt the pain points. We do the same thing, but with JavaScript, because it's the most accessible, painful language on earth, that's what I called it with Wire magazine last year anyway. (jerome laughs) >> So Jerome, you've laid out how you you're well organized. You're lean and financially, making sure that things are done responsibly. We want to give you the opportunity though. What's the call to action? Vets Who Code, you're looking for more people to participate. Is it sponsorships? Work in the community, look to engage. >> Roger that, we are looking for two things. One, we're always looking for people to help support us. We're open source, we're on GitHub sponsors. Like the people who we we're up, we're open source. But the people that do most of our tickets are the students themselves. So that's one of the best things about us. there is no better move, feeling that having something in production that works, right? It actually does something right? Like, Oh, this actually helps people, right? So we help have our veterans like actually pull tickets and do things like that. But, we also, we build, we're building out teams that they're on all the time as well. We have our new tutorials team or veterans. They literally built front facing tutorials for people on the outside. So that way they can learn little skills as we also have podcasts team and they're always podcasting, always interviewing people that in community, from our mentors to our students, to our alumni. And so just, let's throw our podcasts on Spotify. Let's do some codes, the best Code podcast and sponsor song get up. >> Wonderful, Jerome. We want to give you the final word. you're very passionate. You've got a lot interested, loved hearing about some of the skill sets that you're helping others with. What's exciting you these days? What kind of things are you digging into, beyond Vets Who Code? >> Oh man, everything serverless dude. As a front-end, as a person who was full stack and move to front-end. This has never been a more exciting time to learn how to code because there's so many serverless technologies and is leveling the playing field for front-end engineers, just knowing a little bit of like server-side code and having DevOp skills and being able to work in a CLI, you can do like Jamstack and the people that are using it. You have Nike, you have governments. It's just, it's such an exciting time to be a front-end. So I'm just like, and just seeing also how people are like really turning towards wanting their data more open source. So that's another thing that's really exciting for me. I've never been a person that was very highbrow when it came to talking about code. I felt like that was kind of boring, but seeing how, when it comes to like how code is actually helping normal, average everyday people and how the culture as a whole is starting to get more hip to how, API is like our running the world and how tech is being leveraged for. And it gets them, I'm on fire with these conversations, so I try to contain it cause I don't want to scare anyone on TV, but we could talk like, we could talk hours of that stuff. Love it. >> Well, Jerome, thank you so much for sharing with our community, everything you're doing and wonderful activity Vets Who Code, definitely call out to the community, make sure check it out, support it. If you can and tie so much in Jerome, I've got a regular series I do called Cloud Native Insights that are poking at some of those areas that you were talking about serverless and some of the emerging areas. So Jerome, thanks so much for joining, pleasure having you on the program. >> Roger that, thank you for having me. >> All right. Be sure to check out thecube.net for all of the videos that we have as well as Siliconangle.com for the news an6d the writeups, what we do. I'm Stu Miniman and thank you for watching theCUBE. (soft music)