Author: Mitch Ashley

  • KubeCon 2023: Developer Productivity and Platform Engineering

    KubeCon 2023: Developer Productivity and Platform Engineering

    Mitch Ashley: Hey everybody. Welcome back to KubeCon here in Chi-Town, Chicago, 2023. I am joined by Venkat Ramakrishnan. Welcome. With Pure Storage, right?

    Venkat Ramakrishnan: Yes.

    Mitch Ashley: Great. And you are in charge of product and engineering?

    Venkat Ramakrishnan: Yes. Yeah.

    Mitch Ashley: Cool. So you want to talk about something I want to talk about, and that’s platform engineering.

    Venkat Ramakrishnan: Yeah.

    Mitch Ashley: We’ve done some work in this area. And in my mind I think the timing for platform engineering is perfect because the focus on developer productivity and reorienting… DevOps is just about everybody else helping developers do their job. It seems like platform engineering has really been good at adapting in ways that organizations need that function in their company.

    Venkat Ramakrishnan: Yeah, absolutely. If you look at most of the modern enterprises, one of the most precious resources they have as a developer, they want to make sure the developer community is thriving, is able to move their products and the experiences forward, and are able to get the most out of the infrastructure without being slowed down by the infrastructure.

    And I always joke around, if data is the new oil, then developers or the new engines of the economy. So you really want… every enterprise out there is a modern software enterprise, a digital enterprise. And without the developers moving the business forward, they’re going to get left behind. So you have to look at it from that perspective as to why platform engineering is so critical in even the post-pandemic age. It has really accelerated it. We were all part of the Kubernetes container community.

    You could see some of the early adopters, innovators trying to drive a platform story, consolidate the services. But as more and more folks were remote, as more of the tasks had to be consolidated, and the more teams had to be consolidated across, we saw over the last couple of years, in the post-COVID era, the platform discipline. The platform engineering discipline has really taken a strong hold and we see a lot of customers run platform engineering orgs that centralizes all of the DevOps capabilities they had distributed before but also brings a lot of control over cost, security, governance, regulatory stuff, and all of that.

    So it gives them a one stop shop for everything that the developers need to build and run their applications. And that’s where Kubernetes really shines. If you really go back and look, the vision for Kubernetes and containers is that you enable developers to build, ship, and run anywhere. But now all the tooling has matured and all the organizations, many of the world’s largest organizations have embraced it. So we see a ton of adoption, a ton of growth there from the perspective of folks running their applications and building these internal developer platforms and everything. Yeah.

    Mitch Ashley: We abstract things, and containers simplify things to make parts of the pipelines more efficient and easier. That complexity goes somewhere else. Maybe it gets replaced by technology, but we still have to engineer the test, development, production environments we’re going to be in. We want those to be the same or as similar as possible. That’s one domain of platform engineering. There’s also developer portals and that kind of thing too.

    Venkat Ramakrishnan: Yeah, yeah.

    Mitch Ashley: Are you focused more on the platform in platform engineering, or do you expand into other parts?

    Venkat Ramakrishnan: No, that’s great. Our mission is to make the platform engineers’ life easy, but definitely our consumers are developers. See, the platform engineering team exists to serve their application teams and to help them build, ship, and run faster. But there are essentially two major personas that we build our products for. One, the top persona for us is a platform engineer, and they’re our superheroes, I call them. I just came off a customer meeting and they just told me they have about 6,500 to 8,000 developers on a platform which is building out about 100,000 builds a day, and their team size is only eight people.

    Mitch Ashley: Wow. That’s impressive.

    Venkat Ramakrishnan: That’s how lopsided the developer-to-platform engineer ratio is. There’s the large development teams, really small platform teams. So what they need is a lot of automation. They need a lot of observability. They need to be able to control or manage the platform through policies, through rules and rule-based automation and all of that. So our job is to provide that to the platform engineering orgs, the platform engineers so they can have a quality of life.

    But at the same time our customer’s customer is also very important to us, and most of the time or almost all the time it’s the developers who are the customers of the platform. They’re application users or the clients of the platform. So we build it so that these application teams have visibility into what happens to the infrastructure. They know how to manage the infrastructure without having to file tickets so they can even make the underlying infrastructure behave the way they want, for example, with respect to performance or how the data is placed, how it is all backed up, how you can do a DR across, or how you even migrate between versions.

    So there are a lot of these things we let our developer community be able to control and manage so they can get the most out of their platform. And we don’t just stop there. We have also let our developers, our platform teams protect the platform like at the data level, at an application level, but we have also surfaced those capabilities to the developers as well. So if you’re a developer using a namespace. You have your applications running in a Kubernetes namespace, you can back it up. Or as a platform admin you can back up the entire Kubernetes cluster and you can also restore just the namespace if you want.

    So we give different fine grain controls for both the users. And not just that. We didn’t stop there. One of the toughest workloads to run, any environment, is a database. And there was a lot of fear, uncertainty, and doubt about, can a database really run in Kubernetes? If you go back to the early days of Kubernetes. Portworx is one of the companies that emphatically said, “You can absolutely run databases on Kubernetes.” And they are actually best suited, especially the modern cloud-native databases, they’re best suited for running in Kubernetes because they need scale, they need agility, they need elasticity. And what better than a Kubernetes infrastructure to give you that?

    Mitch Ashley: Distribution. All kinds of things.

    Venkat Ramakrishnan: Exactly. So we have been shipping Portworx data services, which makes it so easy to automate about to 14 important databases, and we’re continuing to add more and to run these databases anywhere from day zero to day two ops. Install, upgrade patching, all the way to doing DR for databases. You can literally deploy a clustered Postgres in a matter of minutes and you can set a DR policy so if your entire AWS region goes down, you can spin up in another region again in a matter of minutes. In a few minutes RPO.

    Mitch Ashley: Let me ask you, and it may not be a fine line, but where does a platform engineer’s job start and end and a developer’s begin? What is that middle point where they intersect with each other? Because platform engineering isn’t just taking a bunch of stuff from developers and doing it for them. Developers still have to have their own way of… I might want to spin up an environment. “Create this for me. I don’t want to open a ticket.” Like the old days. So what does that middle part look like?

    Venkat Ramakrishnan: Yeah. I think this goes with the principle that if you build it, you own it. That means a platform engineer is not going to do the developer’s job for them, and neither is the developer is going to do the platform engineer’s job for them. Where the line draws is like a platform engineer looks… If you look at the platform engineer’s view of their day-to-day work, they are making sure their environment is up and stable, it’s able to serve up apps, people are able to deploy applications and get them running within the SLA they promised, and they are looking at it, the environment as a whole.

    But a developer’s view is they have a namespace or a few namespaces and a provision for them. They have authentication into that. Their view is very narrow. They’re focusing on their application. They’re focusing on how performing their application is. They’re focusing on the uptime of their application. They’re focusing on how they can do code patch updates and security updates to their application. They are making sure their application runs in compliance with the platform’s requirements. It is secure, it has all the latest CVEs patched, it’s able to get the performance it needs. It’s backed up at their level and all of that.

    So developer’s scope is very narrow to their set of applications, but a platform engineer… a developer doesn’t go tell the platform engineer, “You know what? You need to add more nodes in your Kubernetes platform.”

    Mitch Ashley: They don’t want to have to.

    Venkat Ramakrishnan: That’s the platform engineer’s job. Yeah. They don’t want to have to. They shouldn’t be because it’s invisible to them. So what Kubernetes essentially delivers is an invisible infrastructure to the developers. And for the platform engineer, the platform engineer is not going to go to developer to say, “You know what? You should rewrite your code because this is how this platform works-”

    Mitch Ashley: Won’t go over well if they do.

    Venkat Ramakrishnan: Exactly. And we all know the biggest inertia in enterprise, especially in software enterprises, that no developer wants to rewrite their application because it has to work for a different infrastructure. That’s what a lot of infrastructure companies think. Oh, I have a new API. All the application-writers are going to rewrite this applications to use by new API.

    Mitch Ashley: Good luck.

    Venkat Ramakrishnan: That’s why Posit still survives. We were having a raging debate yesterday in one of our community dinners we had. People were asking, “Why is Posit still around? Why is Block still around?” Because you have billions of apps out there that use these interfaces, and they work. And I guess object is a new interface, and we support it, but hey, I have seen-

    Mitch Ashley: And nobody’s going to pay to move it. Why? What’s the value?

    Venkat Ramakrishnan: So you’re going to see that the platform engineer cannot dictate the application developer to say, “Go change your app.” That’s whole reason I talk about databases. You could offer a bunch of data services, but a developer is going to come in, especially you’re building a new age app, you’re trying to bring in a new digital experience. They’re going to say, “Look, I’m going to use this high-speed database that can really do this many transactions or a few hundred nodes, or a few hundred or billions of users.” And the data service you offer may not be scalable to deliver that.

    That’s why we’ve built these Portworx data services, because we want to offer the most favorite databases for developers and make it easy for them to run so they don’t have to wrangle with platform and the team and all of that on which data services they need to run for them. Because again, platform engineers are not database experts. And DBAs are not platform experts. So we wanted to marry that together and offer this to database teams, application teams, how you can run these modern databases and how you can simplify it. Again, that is the clear separation of responsibility. I hope that answered your question.

    Mitch Ashley: Yeah. No, very good. Tell us a little bit about, what does your product do? What’s your approach to market? How do you help platform engineers do their part of this ecosystem?

    Venkat Ramakrishnan: Yeah. Our product, as I mentioned, we have a complete data platform. It has storage, backup, and data services. We continue to add and expand it so we can engage with our customers in pretty much any stage of the journey. For example, if your customer is starting out early, you have an enterprise customer, you’re running a bunch of workloads, but hey, you’re not ready to run data services. You’re not ready to run mission-critical applications, but you are running a ton of apps in your… so we can start you with data protection, or your Kubernetes data protection, like where you can back up and restore your Kubernetes clusters. You’re always compliant with your security policies. You’re protecting your Kubernetes or the platform operations against ransomware attacks, and all of the great stuff. But we can go from there and then say, “You know what? You could run all of your mission-critical apps, including your complete application stack, your databases, get back-up in DR with our Portworx enterprise data management software.”

    And the third thing is you can add to the platform and run any database of your choice from our catalog, that you can immediately spin it up and get your application teams to use it. Our primary mission is to serve the platform teams, as I mentioned. So we sell primarily to platform teams. If you look at all of our large customers that run thousands of nodes of Portworx installs, they’re all mostly platform teams. But almost always the developers are consuming that platform, the application. So we look at developers as a community of users that actually leverage the service that’s available to them or provided to them. We are the platform team.

    It’s kind of like if you’re in a company, the IT offers you a service and we as the employees of the company use that IT. For example, it could be email, it could be something like Slack. Same thing. A platform team offers a whole bunch of services to a community of developers who are building apps, and that’s what’s driving the business. Yeah. So we sell to the platform teams, but consumed primarily by the application developers.

    Mitch Ashley: Great. And Portworx, is that a SaaS cloud offering, or you on-prem as well?

    Venkat Ramakrishnan: We have on-prem as well as SaaS. Honestly we have seen explosive growth in both the deployments.

    Mitch Ashley: And you really have to be in both to serve the center parts, right?

    Venkat Ramakrishnan: Exactly.

    Mitch Ashley: Very good. Can folks kick the tires like with the cloud service? Or how do folks learn about what you can do with Portworx?

    Venkat Ramakrishnan: Yeah, they can go… for example, we have an Essentials version of Portworx. They can go to central.Portworx.com and download our Essentials version. We have backup as a service. There’s a free tier version of the backup that they can go play with. You can just sign up, self sign up. You don’t need to contact us. You can just come onto a portal, self sign up. Point it to your Kubernetes cluster, your namespace. You can back it up as much as… we have some upper limits, but it’s pretty liberal. Then we have a trial version.

    If they want to play with the enterprise, the entire suite of the platform, then they can download a trial. It’s unlimited from a features standpoint but limited by a certain number of days for you to play with and run. And then feel free to ping us, and we’re happy to always chat. We want to be partnering with our customers’ journey. Our mission is to make the platform engineer’s life easy. To give them the time back. To let them manage complexity at scale, and to be able to deliver these services and keep their SLAs but serve a large developer community. So again, we are on their side. They are our superheroes and we’re there to serve them.

    Mitch Ashley: I’m sure they appreciate the help. Tell us the URL again to go check this out. The web address. Where do they go?

    Venkat Ramakrishnan: Yeah. It’s ww.Portworx.com, ww.Portworx.com. They can go to central.Portworx.com as well to check us out. There’s a ton of help on docs.Portworx.com as well. So there’s a ton of resources. And we have our YouTube channel, which is Portworx. You can subscribe to it. There’s a ton of learning videos. If you go to Portworx.com, there’s also sandbox labs that they can play with as well so they can deploy immediately and run. So there’s a ton of resources to get up to speed. And you can always fight us on slack.Portworx.com as well, and come and ask questions also.

    Mitch Ashley: That’s always great, to get in there, try it, and see what it does. How it works. There’s nothing like hands-on. Well, thank you, Venkat. It’s a very pleasure talking with you. Hope you have a good rest of the show.

    Venkat Ramakrishnan: Yeah.

    Mitch Ashley: And if you’re talking Kubernetes, you’re at the right place.

    Venkat Ramakrishnan: Absolutely. I’m always happy and excited to be here. Thanks for having me.

    Mitch Ashley: You bet.

    Venkat Ramakrishnan: It’s always a pleasure to talk to Techstrong.

    Mitch Ashley: Have you come back again. Always.

    Venkat Ramakrishnan: Absolutely.

    Mitch Ashley: Yeah. It’s an evolving area, right?

    Venkat Ramakrishnan: It is. It is.

    Mitch Ashley: And fast moving, too. So it’s always good to keep up with what’s happening.

    Venkat Ramakrishnan: And this show has gotten so much bigger and so much busier, right? It’s an amazing show.

    Mitch Ashley: It’s pretty amazing. It really is. Well, thanks again.

    Venkat Ramakrishnan: Thank you.

    Mitch Ashley: We’ll be back with other great interviews, just like with Venkat, and talking about who knows what next. We’ll see, but I’ll bet it’s something to do with Kubernetes or cloud or both. So we’ll be talking with you soon. Don’t go away. We’ll be back in a few minutes.

  • KubeCon 2023: What’s Next for Managed Deployment

    KubeCon 2023: What’s Next for Managed Deployment

    Mitch Ashley: Hi everybody, welcome back to KubeCon here in Chicago, 2023. Lots of great conversations, and here comes another one with Adam Frank Armory, welcome, Adam.

    Adam Frank: Thanks for having me, pleasure to be here.

    Mitch Ashley: Always, we love having you on. So what’s happening in continuous delivery in this, I mean, it’s evolved so much just in the last even year or so, about how many environmists we’re deploying to and the mix of all that. Most of us don’t live in a greenfield, so we’ve got to deal with lots of variety of things.

    Adam Frank: That’s right, that’s right. And I think one of the biggest things that people are really starting to come across now is the fact that they are looking at multi deployments, multi cluster, multi environments, really trying to orchestrate all of that and coming around to manage delivery. Understanding that everybody from a seed stage to large, large enterprises, they all have at least three dev stage prod, right? So how are you going to orchestrate across that when that just grows to more and more environments, talking about global companies and things of that nature.

    So, I think that’s one of the big conversations that’s been happening around here is about the orchestration of that deployment. So it’s been exciting. It’s been exciting for us. That’s one of the things that we went into from the very beginning was understanding that the deployments have to be orchestrated. There’s a lot of things that have to happen, security scanning, integration, tests, you name it, throughout that deployment. So it’s been quite nice.

    Mitch Ashley: When you mentioned managed deployment, right, it’s not just press the button, everything happens. There’s a lot of variables, things have to be sequenced. Some environments require different things than other environments, some you can do is declarative, you can really build it from the ground up through automation and others. Maybe you can’t do that, you’ve got to work with infrastructure or apps or code that’s already there.

    Adam Frank: Yeah, whether it’s infrastructure, apps, or code, or whether it’s just policies that you have in place that you need manual approval before you go out to production. Or something has to happen in staging, like data. Data needs to be transferred from production into staging to do actual validated tests.

    We had a talk on Monday with Portworx actually, really fantastic use case that we’ve come up with them. There’s a use case with their largest customer where they are actually transferring live production data into staging environments to do real tests, because I know a lot of people today, the code’s the same, the configuration’s the same, the infrastructure’s all the same. Is the actual data the same? Well, not really. Okay, well, how do you know that what you’re actually about to change is going to inflict what you want to change? So the fact that we’ve worked a lot with Portworx to do the actual data transfer, to have real live production data in the staging environment to run those tests and things against, has been pretty cool for our customers.

    Mitch Ashley: That was always one of my biggest challenges, how do you get data, especially earlier in the development of an app or a product, is you don’t have a lot of access to a lot of production data unless you’re in a SaaS, and maybe you can then, but you have to worry about things of anonymizing. But you have data, but not necessarily the right data to test what you’re going to deploy so you’ve got to kind of match that all up. Is there anything in that demo that talked about that, sort of that part of the problem, how do you get the right data in the right environment?

    Adam Frank: Yeah, exactly. One of the big things that the security of data, the management of data, moving data around, and and Portworx has a great solution for it. So it’s nice to partner with them, given that we can do the orchestration of those deployments and have that as a check that’s within that deployment. It’s not going out to production before that data is moved into staging, and tests are run against that and validation has happened.

    So like I said, you can have the manual approval at that point if you want, if that’s a policy within your organization, or you can have that continue on automatically and go straight out to production, which is great. That’s the dream right there, is to have that end-to-end automation and have that deployment fully automated, which a lot of people work towards, which is great.

    Mitch Ashley: Well, let’s talk about that. Is there kind of a life cycle that people go through from, we’re not doing it at all now everything’s manual, and maybe it’s scripted, but it’s not automated in the same way they do through Armory. Is there sort of a step by step phases people usually go to get to a point where they might do some really automated through this?

    Adam Frank: There absolutely is. I mean, we talked to a couple of people yesterday from, I can’t remember what company now, but one of the first questions that we start to ask them is, what do you do for your organization? Okay, great. You’re a DevOps engineer, you’re a platform engineer, you’re an SRE, there’s loads them around. These two particular gentlemen said that they were just automation ninjas they didn’t really have specific titles or roles, and they just helped the organization automate everywhere they could. So the next question is then, “okay, well what are you doing to deploy your software? What are you you doing for deployment?” And they said, “Well, it’s manual right now.” Okay, that’s where most people are starting, it’s going to be manual.

    So, I think that one of the biggest things that we see is people start with CI. They’re going to automate the build and the test of that, and they’re going to have an artifact that they want to be deployed. The next thing they’ll start to do is exactly what you said. They’ll start writing some scripts and they’ll start extending some of that CI until that starts to become a little bit fragile and it doesn’t necessarily provide the developer experience that they’re looking for and enabling blue-green and your canary and things like that to protect your customer experience. So at that point, then they go out and they look for a continuous deployment solution that is going to actually meet that, and that’s where the evolution comes from.

    From that point, they’ll start to have some of the manual checks in place. They might not have integration tests all automated, that’s okay. You can have the deployment go out to dev, you can have deployment, go to staging, you can go run some manual integration tests if you need to, and then you can carry that deployment on. That would be the next piece of it, and making sure that all those pieces are automated that are being orchestrated. And then the final piece is, are you comfortable with all of this to remove that gate, to remove that manual approval to go after production and once people are, then you start to see that end-to-end automated deployment. And it’s really, really fantastic to see.

    Mitch Ashley: Really Cool. So, I’ll make a premise supposition you can tell me if it’s true or not, it seems to me that last step of getting into the, okay, yeah, we’re going to pull the pin and let it go and see and let it automatically deploy. A couple things I would want to have experience with one is, how often do we say no when we’re doing a manual decision about, okay, it’s time to release, and when we do, what are the issues? The other is, well, if something does happen, I want to be able to quickly redeploy a fix to whatever it is, and we might’ve put in production, so in minutes, an hour, hour, whatever, very quickly. If I can’t deliver code that fast then maybe I’m not ready to quite go to the automation fully onto production. Is that a good characterization?

    Adam Frank: That is, yeah. I mean, the fact that we’re talking about that as well, the rollback of that as well, are you comfortable rolling that back? Do you have the mechanisms in place that are going to allow you to roll that back? And that’s again, where a great CD solution is going to enable that both automatically or by a single click. You actually see that the baseline is off and this isn’t behaving the way that it’s supposed to be or the way that it’s expected to be, you can one click and roll that back to the last known working state, or you can have that automatically rolled back based on looking at some of that observability data that might be outside of the expected threshold.

    Mitch Ashley: Interesting. So we’re at KubeCon, let’s talk about Kubernetes, that holds another layer of complexity and technology and challenges. How does that roll into it? What are the things you need to consider about automated delivery deployment with Kubernetes?

    Adam Frank: Yeah, I think one of the big things is people have their repos structured in a way that makes sense for their business. People also have a couple of different choices in the way that they’re architecting Kubernetes, so they’re going single big clusters, are they going multi clusters, depending on what they’re doing there. And one of the mantras that we have at Armory is we’ll meet the customer where they are. So we don’t tell people to structure their repos in a certain way, we don’t tell people to architect Kubernetes in a certain way, we don’t tell people that you have to have a CRD written in a certain format. However you have your Kubernetes manifest today, we’ll deploy that.

    And I think that’s one of the beautiful things that alleviates a lot of that complexity of Kubernetes is giving people that flexibility that allows them to meet their organizational needs. We’ll deploy that, that manifest, we’ll deploy those containers any way that you need.

    Mitch Ashley: Yeah, it could be multi-cloud, could be out to the Edge and whatever regional center. I mean, it’s-

    Adam Frank: The Edge stuff is getting really interesting.

    Mitch Ashley: And multiple Applications. It is, it’s picking up. I hear a lot more about the Edge.

    Adam Frank: Yeah, absolutely. I mean, the fact that people are running pretty small clusters, but still Kubernetes clusters out in cars is a great example. That’s one of the big ones.

    Mitch Ashley: One of the people of the big manufacturers in Germany speak about that.

    Adam Frank: There you go. There you go. I know there’s a big American one that does that as well. And again, that’s one of those use cases, having that data on board, shifting that data back to a staging environment, testing with that, and then deploying back out.

    Mitch Ashley: Maybe that’ll be a light on our dashboard. You’ll see the little captain’s wheel. Kubernetes, come on you’re cluster running somewhere in your automobile.

    Adam Frank: That’s it, that’s it.

    Mitch Ashley: It needs a [inaudible 00:09:33].

    Adam Frank: Yeah, yeah. I was actually really surprised when I first started hearing about that, thinking like well that’s got to be pretty resource intensive in a car, we’ve got to figure out a way to do that without having clusters in every single one of these cars and Edge and things like that. But it seems to be working so far, and we’re talking thermostats and things of that nature as well with some of our customers. So, it’s pretty cool.

    Mitch Ashley: I heard someone describe automobiles now are becoming software platforms with wheels.

    Adam Frank: Oh, yeah.

    Mitch Ashley: I mean, essentially-

    Adam Frank: That’s exactly what they are.

    Mitch Ashley: How much of it is, it’s all software, right? With some electric motors or whatever kind of things. So what’s coming up next, the next six months where we’re going to be at re:Invent?

    Adam Frank: We are, we are.

    Mitch Ashley: Hopefully we’ll see you there. What’s on your mind about the next set of things you want to work on?

    Adam Frank: Yeah, so we’re at KubeCon, we’re talking a lot about Kubernetes, but every single person that we talk to also has something else. And whether they’ve found that Kubernetes is a little bit too complex for them and they don’t want to invest the resources in it, and they move to another container service like ECS or they’ve got some serverless. Everybody seems to have some level of serverless, whether it be Lambda or whatnot.

    So one of the things that we’ve really been working on that we’re going to be revealing pretty big at re:Invent is not only deploying to Kubernetes, but also being able to deploy to Lambda in a declarative way. Kubernetes brought us the world of declarative and gave us that abstraction layer above, the imperative nature of things. So we’re now bringing that to Lambda and full blue green, full canary, and being able to just share that declarative config between your Kubernetes or Lambda deployment, so you can actually deploy to both within the exact same deployment, which absolutely nobody’s doing right now. So we are very-

    Mitch Ashley: To both, but also in parallel, right?

    Adam Frank: Exactly.

    Mitch Ashley: Because apps maybe running in both environments, different parts of it.

    Adam Frank: Precisely. Precisely.

    Mitch Ashley: Well, sounds like you get a pretty good peek into what’s coming.

    Adam Frank: Yeah, we’ll have to get back together at re:Invent and sit down and showcase and discuss that a little bit.

    Mitch Ashley: Yeah, we’d love to hear a lot more about that. That sounds exciting. Well, good.

    Adam Frank: Yeah.

    Mitch Ashley: Well, congratulations. I said you and I have talked before the show seems really great. I mean, the buzz and the traffic and conversations-

    Adam Frank: Yeah, its always good.

    Mitch Ashley: And I’ve been to a session, I never get to go to sessions anymore we’re always talking-

    Adam Frank: Likewise.

    Mitch Ashley: Which is good, I’m good. But I’ve heard that they’re really good as well.

    Adam Frank: Yeah, most definitely.

    Mitch Ashley: Great. Have a good rest of the show and we’ll see you-

    Adam Frank: Appreciate it, thank you much.

    Mitch Ashley: In Las Vegas.

    Adam Frank: See you there.

    Mitch Ashley: Okay, re:Invent.

    Adam Frank: All right.

    Mitch Ashley: All right, man.

    Adam Frank: Cheers.

    Mitch Ashley: Say hi to Adam, stop by the booth, go visit Armory. Check him out online Armory dot… Is it io or .com?

    Adam Frank: .io, Armory.io.

    Mitch Ashley: I thought io.

    Adam Frank: You got it.

    Mitch Ashley: Okay, good. Definitely check them out and lots of good things coming too, as well as where we are today with Armory. Okay, talk to you again.

    We’ll be right back with our next great guest.

  • KubeCon 2023: Internal Developer Platforms and Developer Productivity

     

    Mitch Ashley: Hey there, everybody. Welcome back to Chicago to KubeCon 2023. We are on day two of our live-streaming on Techstrong TV across all of our sites, staging-devopsy.kinsta.cloud, Security Boulevard, Techstrong.TV, and Cloud Native Now. So, we’ve got more great interviews. Alan’s just finished a couple and I’m teed up now with Amit Gorvin. Nice to meet you.

    Amit Eyal: Very nice to meet you.

    Mitch Ashley: And you are with, say the name.

    Amit Eyal: Kubiya AI.

    Mitch Ashley: Kubiya AI, okay. That’s a lot of syllables there, but okay. I’m just kidding you.

    Amit Eyal: We do this on purpose to confuse.

    Mitch Ashley: You know what? Once you hear it, it’s unique, right? You remember those [inaudible 00:00:45].

    Amit Eyal: Hundred percent.

    Mitch Ashley: Exactly. Okay, so I know you’ve talked with this before and you’ve talked about IDPs. It’s a really fast-growing area, right? Everybody’s focused on-

    Amit Eyal: Absolutely.

    Mitch Ashley: How do we help developers, platform engineers, the people all working together to make lives easier, self-service, that kind of thing, portals and all of that. I know you had some announcements recently. Talk about that, but maybe set it up of what you all do and why that’s a little different.

    Amit Eyal: Sure. I think maybe to take one step back, one of the things that I think a lot of companies in the industry, including ourselves are doing is, how do you create a better exchange between the developers and the DevOps, the operators on one side, developers on another hand where you have the golden path towards productivity. IDPs, internal developer platforms, have been known backstage being the primary leader in this space to unlock lab productivity.

    One of the things that we, at Kubiya, have discovered, and this is what we’ve tried to essentially address, is the self-service is only as good as the interaction between the users and the tools. And where often it does break down is on the fact that it’s a one directional exchange between the user and the tool. If you fail on authentication, fail on permission, don’t know the variables you need to pass or anything just doesn’t work as expected, you have a question, you have to go back and do a Jira ticket queue in order to go and to essentially get assistance from a human being.

    So, what has come to fruition in the last year, obviously ChatGPT doing the market education for this, is conversational AI, having a two directional exchange between machines and humans. We’ve married these two worlds together. We’ve created that exchange between your users, developers, and operators with the tools in a way where you can have a full-on conversation with it.

    You can go and spin up a Kubernetes deployment, it will ask you how many you replicated. You can scale it up, scale it down. You can have for your Jira ticket queue, for example, and ask it questions about who owns what, where they’re assigned creation, notating, anything that you would be able to do as a human, only in this case, you’re just having a conversation. Because imagine having on the other side, someone like Fred, John, Bob on the on-call channel having a conversation with you. We’re replacing that with the virtual assistant.

    Mitch Ashley: Interesting. So, replacing the virtual assistant model. It sounds like also you were maybe describing, if I got this right, that the developer technical staff can interface through ChatGPT to say… I mean the nice thing about ChatGPT is you can talk to it like a programming language just in conversational logic, right? I want you to create this for me with blah, blah, blah. Is that part of what you’re saying? You can give it instructions or requests?

    Amit Eyal: One minor information, we’re not using ChatGPT. It’s a ChatGPT-like experience.

    Mitch Ashley: I see.

    Amit Eyal: It’s probably the best way to anchor people to-

    Mitch Ashley: I jumped that.

    Amit Eyal: Which is fine. We’re using about eight different language models, both large and small. We’re actually using conversational AI piece with GPT-4 for Azure, just a FYI, but that’s separate. The experience is ChatGPT-like. Only here, it’s your tools, your programs, your scripts, essentially a personalized IDP, if you may, for each and every persona in organization, each and every individual in the organization.

    Mitch Ashley: Okay. So, are you using generative AI large language models underneath, or that’s just the experience that you’re delivering with whatever technology?

    Amit Eyal: Certainly. So, large language models are giving that natural exchange, essentially the benefits of large language models and the generative piece we’re using. But we’re also harnessing and scaffolding it with rule-based systems, with sound engineering practices. So, that’s how you get the benefit of an expected outcome on one hand. Our users would expect an expected outcome. Essentially, it has to be deterministic what they’d get on the other end.

    Mitch Ashley: I’m glad you said that because I was thinking down the ChatGPT line. It’s nice, but you don’t get the same response, same outcome. It’s not necessarily guaranteed to be consistent, to be accurate. So, it makes sense on the backend scaffolding part.

    Amit Eyal: And there’s permissioning and rule-based systems in place to harness the LLM to function the way you would expect it to.

    Mitch Ashley: Very nice. So, you talked about the developer experience, and I totally get the cognitive dissonance between I’m working in my IDE and doing my developer thing, and then I got to go to this ticketing system or go to some weird operating portal that wasn’t built for developers, but I still got to use it in a huge sense.

    Amit Eyal: Maybe it is, but it’s only as good as how it’s been upkept, maintained or what you’ve actually input into there. So, you still have to go in to program it to act the way you expect it to.

    Mitch Ashley: And it’s part of the flow too, right?

    Amit Eyal: Yeah.

    Mitch Ashley: I might not know answers to all 10 questions at the start of the interaction, but I need to get it started, and then finish it at some point in the process. But it’s about in the flow of the developer work, not I’m a form, fill me out. Right?

    Amit Eyal: A hundred percent.

    Mitch Ashley: Great. So, the announcement then, summarize again for us because I stepped on it with the GPT stuff.

    Amit Eyal: Sure, yeah. No, it’s fine. So, we came out last year actually with our initial platform, which was more resembling next generation of workflow automation because it was more so to get people connected to the world of conversational AI into the world of IDPs. Where we took it from there, and especially with the evolution of large language models, is an agent-based approach where we’re using different models and different agents trained on different models in order to map out effectively different functions within a transaction, almost like the human brain and the lobes interacting with each other.

    So, when you go and interact with the system, depending on how you approach it, it could be, show me how I do something. Say, set up a VPN. That may be in your docs. So, we’re using RAG techniques obviously to go into a train on your knowledge base. But if you’re going to go and run a query against a data source or a database, or maybe show me all my Jira tickets for current sprint for certain… That’s a different language model that’s interacting with you.

    And then if you’re going to go and create a Terraform, create a Kubernetes deployment, destroy Terraform, that’s an action base that’s also needing to go into verify permissions. We’re using open policy agent. We’re also using all the techniques to or data masking, and then we obviously have the orchestration there, a state machine that will go in to orchestrate all of those with the business logic of the organization. So, there’s a lot going on behind the scenes.

    Mitch Ashley: There is. Well, a lot of different kinds of users’ requests.

    Amit Eyal: To the user, it’s seamless. You have a brain emoji thinking and then reading back to you what it’s doing. So, it’s actually very fun interaction, human-like interaction, but then behind the scenes, there’s a lot that’s going on.

    Mitch Ashley: Very cool. Do you integrate at all with IDEs and go that far with it or is it a separate portal?

    Amit Eyal: Users can integrate with their IDEs. They can go and plug in. We have a SDK and it’s all open API based. So, essentially, you can connect to any tool.

    Mitch Ashley: I think it’s really nice and important because for one, it’s right there handy. And also, if you’re delivering any information that you can deliver in the way the code looks like or structured or auto-fill, you can mimic the behaviors of what you do in an IDE that… Very natural. So, I don’t have to go look up an API or what that call is; it’s right there. Or I don’t have to go look up what that thing’s called on my request; it’s right there.

    Amit Eyal: Agreed. So, I think maybe the one call-out I would love to make is people are thinking about the co-pilot approach or ChatGPT approach as a code completion tool. What we’re doing is, we’re doing an operations’ completion tool. Essentially, all of the next step, what would you do, how would you deploy the code, run your CI/CDs and maintain it for day two operations, so that’s where you can think about us filling that gap.

    Mitch Ashley: Okay, interesting. So, congratulations on the announcement.

    Amit Eyal: Thank you.

    Mitch Ashley: That’s fantastic. And every time you come, you’ve got new, in progress and things happening. I’m curious, maybe you’ve talked to Alan about this or Mike, your backstory, you’re CEO, founder of the company. How did you get going down this path? Was that, I was doing this at a big company and this is like a huge need, I’m going to go forward or?

    Amit Eyal: It’s a great question. So, the first time we came on it was myself and my co-founder, who he himself is an operator who built a self-service platform for his platform team in his previous company at Bluevine, and I came from AWS where I was managing partnerships for all the DevOps and DevSecOps-

    Mitch Ashley: Nice couple.

    Amit Eyal: Tier one players. So, I saw where they were possibly struggling with some of this self-service, and where I was in the middle of trying to assist them. And that’s where the thesis on the business side, which is this is a much larger problem and how we’ve actually solved this ourselves came together.

    Mitch Ashley: Interesting. Talk a little bit about your experience in the partnership side of it. Has that come to fruition as an important part of the business? I would imagine when you’re integrating with lots of things, just to look up the API, you can do it. You want to build relationships, partnerships with other companies.

    Amit Eyal: So, we have a very strong ecosystem of partners really looking to have the conversation. I experienced essentially that assistant experience on top of their platform. And right now, we’re letting into queue a few of the strategic ones that we feel that we can both have a strong alignment with, but also maintain. As we grow our team, we’re going to have a much larger ecosystem. We’re already at probably 10, 15 very strong players in the industry who want to have a partnership in place. So, I feel it’s only going to grow from that point.

    Mitch Ashley: Good, good. Amit, you already know this. I learned that lesson on one of the products I worked on where you didn’t design it with you were going to have a partner ecosystem in mind. You get to a point like, okay, we can’t do what we want to do. We got to go back and add that in. So, having that perspective upfront, if that’s a place you’re going to want to go at some point in the life cycle, it’s-

    Amit Eyal: That’s exactly it. Our ecosystem is built to be two-way conversation with all tools. So, if our customers are asking for it, there’s no reason why the vendor on the other side wouldn’t have a stronger alignment so we can have a better user experience for both sides.

    Mitch Ashley: I’m curious, do you sell to the engineering development community? Do you sell more to the platform engineering, operational DevOps tool folks? Where do you tend to focus?

    Amit Eyal: I would say usually that decision is made jointly. The platform teams typically have to have a handshake with the engineering managers. So, whether it’s an engineering manager taking us to the platform team, platform team taking us to the engineering manager, typically, we see both sides involved at least in validating this. But the easiest way to get started is really with the platform teams because they’re the power users typically of the system. They’re the ones creating and scaffolding the configurations of these systems, so it’s easiest for them to get started, test it internally on themselves. And very easily, we usually see that they roll it out to the rest of the engineering team.

    Mitch Ashley: They already have a good idea of what kind of requests come their way.

    Amit Eyal: Precisely.

    Mitch Ashley: And it would make that easier for people.

    Amit Eyal: Otherwise, the other way around would be, let me go and bring in a platform team. So, it’s a more direct approach [inaudible 00:13:09].

    Mitch Ashley: That makes sense and it’s nice. I could totally see. It’s starting, “Well, hey, something might make it easier to take a load off-

    Amit Eyal: Precisely.

    Mitch Ashley: The platform engineering team” or them saying, “Hey-

    Amit Eyal: We’re here to augment them.

    Mitch Ashley: … that’s an easier way to work with this.” Right?

    Amit Eyal: We’re here to augment them. Not everybody has a luxury of hiring three to five more headcounts for next year, but if you could do so with one or two headcounts and then Kubiya, now you can scale.

    Mitch Ashley: Great. If you look forward a little bit, maybe this next six months or maybe 12 months, six months or so, what things are happening in the industry, maybe where you’re heading, what are you thinking about next?

    Amit Eyal: The most recent announcements by OpenAI have been very interesting, because from our perspective, it’s giving us even more tools in order to get to our end goal, which is, in my opinion, a self-driving operator. A self-driving operator that will be able to take end-to-end tasks away from human beings and really free them up to do the highest and best use of their time. It’s still going to require human-in-the-loop interaction and we don’t expect it to be overnight. But I think a lot of the things that was announced recently is already in line with what we’ve been doing, but it’s only making it easier and again unlock more and more use cases.

    Mitch Ashley: Seems like OpenAI have done a pretty decent job of, don’t throw it all out there, incrementally add capability when you’re ready to handle it.

    Amit Eyal: Yes. Because we’ve been in this space a couple of years, we’ve been thinking about, we’ve already been architecting our platform to be conversational native. That’s allowing us to move very fast in this space.

    Mitch Ashley: Great. Well, tell folks where can they go check it out?

    Amit Eyal: Absolutely.

    Mitch Ashley: Can they get a demo online or what can we do to help?

    Amit Eyal: That’s a beautiful part. We open our platform up for self-service. So, you could actually sign up at Kubiya.ai, www.kubiya.ai. Sign up for a free trial. We also have a sandbox where you could, without needing to put in organizations credentials, anything. It’s a gated experience. Obviously, it’s a bit more limited, but you could go and have that nice exchange with Kubi, our DevOps assistant, and really enjoy the experience before committing to going into a trial.

    Mitch Ashley: Appreciate the sandbox. You don’t want to quite turn it loose on your infrastructure quite yet. Let’s kick the tires and then get there.

    Amit Eyal: Mostly read only. We have a few write actions in there, but typically, we want to make sure it’s rated PG for what people can do.

    Mitch Ashley: Exactly. Exactly. Great. And it’s spelled K-U-B-I-Y-A.ai.

    Amit Eyal: Y-A.ai.

    Mitch Ashley: Great.

    Amit Eyal: Thank you very much.

    Mitch Ashley: It was on the… I’m sure on your title but-

    Amit Eyal: Yes, it would be there.

    Mitch Ashley: Amit, pleasure talking with you and congrats on the new progress, new release and capabilities, where you’re headed next. Great market to be in.

    Amit Eyal: I appreciate it and I appreciate your time here today.

    Mitch Ashley: Of course. Great to have you on. For our folks, for the people in the audience, Amit’s representative of some of the great things that are happening not just at KubeCon but in our industry, and progress that’s happening overall. So, stay tuned. We’ve got more great interviews coming back up. Don’t go away. We’ll be right here in a few minutes. So, we’ll be back.

  • Splunk: Creating a Resilient and Dynamic Organization

    Splunk: Creating a Resilient and Dynamic Organization

    Mitch Ashley: I have the pleasure of being joined by Ryan Kovar, Ryan is a distinguished tech security technologist and leader of SURGe with Splunk, and Cory Minton who’s field CTO for The Americas with Splunk. Welcome, guys.

    Ryan Kovar: Thank you.

    Mitch Ashley: Good to be chatting with you both. A topic that’s very top of mind for CISOs or IT leaders, of course, is how do we create a resilient and dynamic organization that can keep pace with the business and the change that we see in the technology landscape, whether it’s our own infrastructure, own application portfolio, cloud, et cetera, all of those things, but also, of course, the tax services that are evolving and changing as what the bad guys, the threat actors, are doing. We’ve also not only got to have a great and resilient technology stack, but organizationally, process-wise, all of those things have to fit together into a cohesive strategy.

    We’re here to talk about that, thinking about it as an IT leader, whether you’re in security or IT or combination of both, and discussing your all expertise experience, but also you talk to a lot of customers as leaders in Splunk and the kind of things that you do. Cory, it’d be great to have you kick things off. Maybe we should start with if you want to start with the people domain or maybe you want to set it up a little bit differently. I’d love to hear your initial thoughts on this.

    Cory Minton: Yeah. No people’s perfect. I think the people process technology lens on tackling any sort of problem for leaders today is an appropriate framework. I’m happy to talk about the people portion of building great cybersecurity and IT organizations that, like you said, deliver resilience.

    Ryan Kovar: For me, at least when we think about this, you said IT leaders, and I think one of the big changes I’ve seen across for cyber for CISOs is it’s no longer IT or security. It is business leaders. When we started talking about people, that to me starts resonating because that is a cognitive change in how CISOs think of themselves and they think of their value, which we often get stuck in the technology part of people process and technology because a lot of us are technologists at heart, but I think the big change that Cory and I have seen when we start talking to CISOs and CIOs is this convergence of skills and the need to support the business differently.

    Cory Minton: Yeah, and it’s an interesting sort of people market, too. I think leaders have to think about the fact that, yeah, in technology, there has been some turmoil in some of the big tech companies, but there’s still a lot of really great talent out there. I think that there’s choice. With unemployment so low, and there’s, what, like 16 million jobs unfilled currently in the US and a lot of those being in the tech sector, people have choice and they have a place where they can go.

    I think, leaders, if they’re going to build a talent pipeline and build a great organization, they have to find folks where they are and bring them in and connect them to a value, a mission and a vision that they get excited about. Certainly, securing digital services and protecting against bad actors is exciting in and of itself for many folks, but actually connecting those people to how it affects the outcomes that matter to the business and that whole value creation process, I think, is a real critical skill for folks to understand today as they, again, are out communicating and interacting in the network, building networks of talent pools. I think that clear vision of why it matters and why the work that somebody would do with you matters is critically important.

    Ryan Kovar: That reminds me of the cliche, of course, that people don’t quit jobs, they quit leaders. When you flip that around, one of my mentors, Susan St. Ledger, told me, you can evaluate the success of a leader by how many people follow them to another company. I know right now, in this market, what I’m finding is people are staying longer because they like the people they work for or they like their leadership team, they like the culture. The money, even if they’re not making as much as they were last year because of inflation, the people I know who stuck around longest are the people happy with the people that they work for and work with.

    Mitch Ashley: It’s interesting when we talk about people. I’ve worked in part of my career where the sort of higher the purple unicorn that doesn’t exist, that got eight skills, that needs 20 years of experience for things that have only been around for three. We set our subs up to hire these phenomenal people of which there may only be a few in the world that are like that, but it’s about growing our people, but also growing our organizations, developing them. It’s not just hiring people. It’s building a team. It’s building an organization that’s got the right talent at the right time at the right place to match with the business needs, and that changes. That means you can’t always hire for it. You’re partnering for it. You’re working with companies like Splunk to bring in skills and expertise maybe you need for the moment, you need for a project, you need for strategy, all of those things. Love to hear your perspective about broaden what we think about people and how we incorporate that part of it into our strategy.

    Cory Minton: Yeah. I’ll say, top to bottom, start at the executive level down to practitioners. Everybody has a partner. Everybody has a consulting partner typically that they bring in to, like you said, fill those gaps where it’s a new skill, it’s a new technology, it’s a new capability that they’re trying to deploy for the reasons that they’ve chosen to do so. They’re valuable, but you may not have those skills internally. Training takes time and, oftentimes, just finding that partner that can help you solve that particular problem is incredibly important. I think, as the security landscape and, frankly, the tools being used to deliver and develop the latest digital services continues to get more complex, expecting to hire that skillset completely, probably not realistic especially as digital transformation objectives have an ebb and a flow of momentum and the amount of work being done on particular projects.

    Yeah, I see it as one of the top areas where, when I’m talking to CIOs and CTOs and CISOs, when they think about, “Hey, we want to deploy this new capability within Splunk,” or, “We’re, frankly, trying to figure out how to integrate better with our observability and IT teams to derive more value from the tools we’ve already purchased,” it’s oftentimes that people conversation of, “How do I actually leverage your talent to show us what good looks like and bring the experience from other companies similar to us that have already been down this path to, call it the cheat code, how do I do the thing that you guys already know how to do? How do I buy that capability?” Oftentimes, it’s through people.

    Ryan Kovar: My experience, I’ll go the other side of the halo and horns there down to just the nitty-gritty hiring. Recently building out my team, I intentionally carved out three slots for entry level, early career folks into our cybersecurity team, which is pretty rare for Splunk and pretty rare for a lot of security research teams, but the way I did that was really rewriting the job description to be embracive of second-career people. I actually really dislike the term “there’s a problem with the pipeline for hiring”. I think that’s completely false. The problem is not in the pipeline. The problem is we have a valve on incredible talent and gate-keeping who actually gets into the pipeline. We do see a problem with the pipeline when I start looking for folks who are underrepresented in cyber especially 15, 20 years down.

    What I don’t see is a problem of, basically, the reservoir. The reservoir is healthy. The reservoir is huge, but people either don’t feel like they’re welcome or they self-select out especially of cybersecurity. For me, a lot of the people problems that we have, if we can start working on the problems of today, future us, as a security leader, will be very happy if present me can help unlock that reservoir by turning open the valve by creating job descriptions and roles that are less around years of experience and understanding technologies that I can Google or generative AI my way through today.

    I think there’s just a lot of flexibility especially for folks who have critical thinking and communication skills. I can teach you TCP/IP. I can’t teach you how to communicate. I can’t teach you how to synthesize information. I need you to walk in the door with that. Something for me around people and these hiring gaps that we see is really about being more embracive of nontraditional cybersecurity and IT roles and then also facilitating them in ways they can succeed.

    Mitch Ashley: Well, and it’s also about hiring for what we need today, but also where the ball is going to be downfield when the ball lands. Part of that is hiring people who have demonstrated their ability to learn, adapt. Yesterday, they were TCP/IP expert. Today, They’re the security threat landscape expert. How did they do that? How did they get there? They learned it. It may have been on the job, but there’s also a lot of self-motivation and just skill in that learning, and that repetitive learning skill is I think something you can harness or leverage to accelerate their career as well as what you need.

    Cory Minton: Absolutely. It’s one of those things that, always, some folks get turned off. As Ryan said, sometimes there’s a valve, and one of those valves is like, “You must have a college education.” While I don’t necessarily believe that a college education is always the right thing, I think what it proves if you have one is that, as you said Mitch, you’re able to go through a structured learning process in an organization that’s institutional, understand dynamics and things and achieve an objective which was set before you that had some measurable outcomes that you had to deliver, which I think is something true for all of us in a corporate responsibility job as we have to operate in an institutional environment. We have to consistently learn new things. We have to interact with people around us. I think college is a good measure, but, as Ryan said, oftentimes, a second career is maybe even a more powerful measure of somebody who’s done that successfully.

    Like Ryan said, the technical skills are learnable and, frankly, the fun part is some of the technical skills are actually getting obfuscated by advancements in technology. As we think about things like, Ryan, you mentioned, generative AI, we can make the joke, but, candidly, wouldn’t you rather hire somebody who’s got incredible cybersecurity skills and understands the landscape more so than somebody who’s just really good at crafting queries because then, if you have somebody that has that domain expertise as technologies like generative AI and other sort of assistive technologies continue to evolve, then the domain expertise becomes the most important because then you start interacting on a natural language way and you don’t have to have those same technical skills to get there, which I think is probably one of the most interesting uses for generative AI is actually bringing out the barriers for technical ability to execute in a job like security or IT.

    Ryan Kovar: Prompt engineering will be one of the most significant requirements for entry-level and mid-level jobs by next year, in my opinion, categorically.

    Mitch Ashley: We’ve already been through one generation. It’s called search engines. Now, we’re doing it with generative AI.

    Ryan Kovar: Yeah. Yeah. No. We’re talking about this, but the reality is I’ve been doing cybersecurity and IT since 1999. Cory, there’s enough gray there. I’m sure you’re about the same generation. When I started, there was no Google and you had to read the Microsoft TechNet documentation, and then there was Google, and I put 65 CD binder in the trash and said, “Never again.”

    The fun thing that I always tell people that I’m mentoring or advocating for in cybersecurity is I’ve been doing this for 24 years and, of the 24 years, I have about four years of knowledge that’s relevant. I have 24 years of wisdom, but four years of knowledge that’s relevant. Everything else, no one cares that I can fix Exchange 5.5 driven pub EDB and I know how to defrag a Windows NT 4.0 server. That doesn’t matter. That’s one of the great things about cybersecurity and IT in the general is that you can become a subject matter expert in something very quickly and not have the bias of age.

    Mitch Ashley: Well, let’s turn our lens to the process part of it, and we’ve talked a lot about people and we could talk a lot more about it. There’s some great conversations that we’ve had already about that. We’ve got to have processes that are well-oiled to highly tuned, but can be responsive of incident management when things happen. The organization now has to operate cross-functionally, the stove-pipes, the things that we’ve lived with for so long. Now, we have to operate cross-functionally. We’re trying to tear those down, but our processes have to work across those.

    I’m interested in your all thoughts about how are organizations, what do they best do to adapt to what we need today so we can be speedier, respond more quickly and more reliably to threats or incidents or needs of the business?

    Cory Minton: Yeah. Do you want to to hit it, Ryan?

    Ryan Kovar: No. Please, Cory, go ahead.

    Cory Minton: Okay. I was actually going to say it’s actually not even an option anymore. We talk about that they need to do it. It’s not an option. If you look at some of the SEC’s recent rulings on the disclosure of material and incidents that happen for publicly traded companies in the US, you have to report that. You have to have that cross-functional view of how if a cybersecurity incident happens or an IT sort of incident outage or breach, any of these categorical things that happen, if they have a material impact on operations that would affect shareholder value, then you must disclose those things, and so now the impetus is on every publicly traded company to get this figured out really well. It’s got executive buy-in now that we’re going to tear down the walls between security and IT operations and our engineering teams developing our next digital capabilities because, anywhere across that spectrum that we have a process breakdown, whether it’s externally caused or internally caused, if it’s material, we better report it.

    These are no longer like, hey, it’s a good idea. This is like “test that theory and report the results” kind of stuff that the SEC will send somebody to jail over. We’ve already seen some convictions on previously publicly traded companies on misreporting things. It’s no longer a game. We’re serious about this. I think, from a process perspective, one of the things I’m seeing is reaching across the aisle. CISOs are talking to CIOs and CTOs more so now than I’ve seen in the last couple of years because they have to understand those impacts and they’re looking to organizations that actually already do some of them within the company that are already being trusted by different pockets of the organization. They’re looking externally for that guidance and help, whether it’s from consulting partners that are, hey, advising on security operations or advising on software development capabilities or technology partners.

    I mean, even the CISA, the Cloud Infrastructure Security Agency, their recent strategy update talked about one of the key pillars of their annual strategy for resilience included technology partners that were going to help them achieve that resilience. I think we have the impetus. The measurement is required now. There’s no longer a game, and I think executives are starting to understand it and they’re looking external to say, “Who can help me deal with this?” No matter where we land on what is material and some of the legal questions on how it’s implemented, we still have to respond and we still have to report some of those capabilities. Now is the time to start reaching across the aisle and starting to ask questions of your partnerships that you have in the org on how can you help us solve this problem.

    Ryan Kovar: I look at things like DevOps which still today has a little bit of a carve out separate. In a lot of organizations, DevOps is a slightly different place than maybe traditional security and, well, certainly than security, and then possibly even different than traditional IT engineering or infrastructure. In today’s society or today’s world of technology, a lot of the security issues that organizations are facing are in their DevOps pipeline, and so I find it fascinating what Cory said. The SEC has this term, material finding. You have to report a material finding.

    Now, I as a security professional may very well know what that is, but, frankly, the DevOps world has gone feral to a point where the security organizations are not a part of it and so the DevOps team are the only ones who understand what the security implications are. They’re the ones finding it and, because they’re in a DevOps mind frame, they’re not stopping and saying, “Let’s create an incident. Let’s walk this through.” No. They’re just fixing it and they’re moving it on. That’s how the cloud works. That’s how DevOps works.

    There is this essential need for us as an industry to really start reaching more across because we are being outpaced by DevOps home growing their own SecOps without oversight, without the wisdom of the security world, but we can’t stay in the way of the business, which is why that’s so important for us to go across and understand this because now there’s regulatory requirements and the real world is people are going to move forward whether they like it or not, so get on that train.

    Cory Minton: Yeah/ it’s funny, Ryan, you say that. I was reading the SEC reports from JPMorgan Chase. Jamie Dimon, their CEO, said in the letter to shareholders he had two sort of funny juxtaposed statements that used the same phrasing, which I found interesting. He said two things he could not overemphasize, one was, “I cannot overemphasize the need for cybersecurity in our organization. Everything must be secure,” and then later in the letter he said, “I cannot overemphasize our need to deploy innovative technology,” which is exactly what you said. If my CICD pipeline is continuing to push updates, but I’m not applying those cybersecurity principles that, like you said, was incident review and forensics and actually looking into it, then we’ve missed the boat on this. One of the key parts of this SEC filing is you not only have to report the outage, but you actually have to from an annual reporting perspective talk about your processes that you’re using to ensure cybersecurity in those areas. That’s one of those that’s like the CEO is saying this to shareholders. We better pay attention.

    Ryan Kovar: The CEO of a bank that touches 20% of every dollar in the world every day, right?

    Cory Minton: We cannot overemphasize.

    Ryan Kovar: I love that example because I look at DevOps as a perfect world where I have no fear at all that the DevOps team will identify and remediate security issues very quickly and then continue to do so because they’re not looking at the larger picture. Why did this get ingested? Why do we have this happening? Why is this CRO a threat actor you may not know anything about a threat actor. You may not understand that Tampa strawberry as per Microsoft has a really significant interest in your organization, and one of their TTPs is actually moving up the chain and actually jumping ahead for software supply chain.

    That is something that I would not expect a DevSecOps engineer to understand, but that is where the context of a larger security world, and that’s why this resiliency message, this is why it’s working across aisles. It becomes so important for the process. I honestly think the technology is usually the easiest part of this. The people and the process to implement and secure the technology, way harder, way less interesting than most people, except nerds like me, but much harder.

    Mitch Ashley: Well, and what you really bring to light is that the security specialists are going to understand the threat landscape much better. DevOps developers, et cetera, know their environment focused on the things that they are. You mentioned Jamie Dimon. Those two things, he’s expecting us, our CEOs are expecting us to figure out how we bring that together, how we make that happen so we don’t have feral organizations, so we don’t have processes that are brittle when things really fall apart or our environments get more complex. I mean, that’s an obvious thing. They are complex and they’re getting more complex, and no one understands the whole thing, so we’ve all got to pull together and say there are three dimensions to this problem, not one, and here’s the steps. We together figure out how we fix this.

    Great. Well, let’s talk about the technology perspective then. Obviously, Splunk being a great technology company, have been around for a long time. I remember finding Splunk on the showroom floor in the early days still doing black T-shirts then just like they are today, a great company that you all work for. Let’s talk about some of the technology side of what’s important and, again, thinking about not just internal people and processes, but also third parties that we’re using like the Splunks of the world in our organizations and how you can help with this challenge.

    Ryan Kovar: I’ll start really easily on this one, and then Cory will actually say something much better. People buy software to solve their problems. That’s it. That’s the easiest way when I pay people. I didn’t come from a sales background. I was operational. I was a threat hunter for the government, threat intelligence at DARPA, places like this. I didn’t think about why I bought software until I worked for a software vendor. It’s very easy. You buy software to make your life easier, to solve a problem faster or to solve it better.

    When I look at what Splunk does, a lot of our recent efforts are really around this incremental growth of just making people’s lives better, making people’s lives easier, cutting down the barriers to do their job faster because that’s what people need, whether it be security, whether it be observability, whether it be traditional IT engineering, that to me is really what we focus on here at Splunk which is why I’m still here after nine years. We make people’s lives better and we allow them to fulfill the mission that they’re actually being paid for rather than fighting the software that they’re buying and paying money for. That to me really is at the heart of what we do.

    Cory Minton: Yeah, and I think, if anybody’s seen some of the Splunk messaging in the market, we’ve really rallied behind this idea of resilience, and I think it actually sums up nicely the things that we do which I think, based on the conversation we’ve just had about the people and process, things that are challenging organizations, I think we’re in a really unique place to be a partner, to be one of those partner organizations and be the software that people buy to make their lives easier because we sit in this unique place of being one of the few organizations that actually unify, tear down the walls between security, IT operations and those feral DevOps teams that are out there building the next digital services because our corporate mission is around resilience, and we think of that as a simple statement of, “How do you keep all this digital business secure and up and running?” Simple statement, but, secure, not a simple thing to do, and up and running oftentimes equally on simple thing to do.

    Ryan Kovar: Sometimes at loggerheads.

    Cory Minton: Yeah. Exactly, a pearl of either sort of objective. There used to be this term we called a MOM. We all love MOM, monitor of monitors. It sits above. It sits at an enterprise level, at a higher level to give you visibility. I think that’s what folks have maybe struggled with that we see. Hybrid cloud is reality, right? There’s lots of clouds, not one cloud. Clearly, there’s leaders in terms of revenue, and each quarter they grow at different paces, but candidly, even Michael Dell said some years ago, “The cloud is not a place. It’s more of an operating model.” As you see SaaS being part of cloud journeys, yes, data centers are still run by organizations. They just are run now in a much more orchestration pattern similar to cloud providers, and that reality of lots of silos across different landscapes is creating challenges.

    If you use one tool that’s provided by said provider, then, yes, you can secure and keep up and running that one particular cloud real estate, but what about how it’s connected across the organization? How about the ways that applications traverse deployment centers? I think that’s what we really see as interesting is organizations are leaning on Splunk especially in the macroeconomic conditions where everybody’s focused less on growth and more on profitability, so they’re looking at like, hey, how do I reduce the number of tools?

    Ryan Kovar: More out of less.

    Cory Minton: Yeah. Exactly. Do more with less. They’re looking at it and going, “Wait a second, so I have this network environ, this router, so my data center. I’m sending the logs from that thing to nine different tools. Why am I doing that?” That’s nine times I’m paying for that bit of data to be stored and processed and analyzed by some number of tools, and organizations are looking at it and going, “Maybe that’s not smart. Maybe that same piece of data has nine questions being asked of it, and is there may be a fewer number of tools that could answer those nine questions effectively to give me the outcome without having to have all this sprawl?”

    It’s a unique conversation that we’re in today. Candidly, the tools consolidation, that rationalization of tools is one, looking at data. The data deluge hasn’t stopped. As we talk about sending data to nine different places, well, as that data becomes richer, it’s no longer just logs. Now we’re looking at metrics for real time. We’re looking at traces for spanning. How does an application actually impact multiple sort of environments? The data is getting rich and large. Is it all equal? Should we all be sending it to the same place? Should we be treating it with some valuation?

    Those are conversations that I’m having today that technology is helping solve, and Splunk is doing some really interesting work in the data rationalization and in that tools consolidation area that’s making it easier for customers to do more. As Ryan said, you bought a piece of software to make your life easier. We’re trying to go out and help folks figure out how to make more lives easier with the software they already bought.

    Ryan Kovar: I’m just required to hit all the buzzwords, so I’ll say ransomware now. It’s fascinating to me. Resilience, as in the concept of business leaders and cybersecurity, CISO leaders having to come together, I think, partly is really being driven by this threat of ransomware because the first time a cybersecurity threat has consistently and continually impacted every aspect of a business where 10 years ago, 15 years ago, oh, APT1 from China, exfil data. Well, that was the big issue. Well, by the time you heard about in the news, it’s already done. It’s actually relatively small scale. The impact is we were compromised, there was a breach, and now we have to deal with the public relations fallout, the stock drop, and also we have to make sure this doesn’t happen again.

    With ransomware, it’s actually we’ve encrypted your critical business systems and you can no longer do business, and now you have questions of do we pay the ransom? Well, now you need to involve the finance or you need to involve your chief legal officer. Oh, it’s publicly out there that we have this security issue. You have to involve the PR team, the public relations team. Oh, it’s actually knocked out our core business. Oh, well, now you’re involving the sales org. Now you’re involving the IT org. It’s coming across all these different places, so it’s builds back into what tools do you have that facilitate this and then, going back to the people part that we touched on earlier, this is where someone needs to be across all of them because they need to understand the impact and actually drive those changes that are needed and, because of ransomware, we actually have to deal with it. We can’t just pretend it doesn’t exist. CISOs can’t just be nerds in the closet playing cyber. They actually have to be able to speak eloquently to their business leaders, to the board of directors and others.

    Cory Minton: Yep. I’m just going to jump on the bandwagon of buzzword bingo. One of the things we’re seeing a ton of, too, is we talk about new digital workloads constantly being brought in, new innovation, we’re hiring consultants to bring in and actually help generative AI get real in our organizations, there’s a lot of conversation about is generative AI threat versus risk? There’s a whole kind of conversation there, but one that actually, as we’re moving past the hype and the AI washing nonsense that’s happened in the market, once we’re getting to real, a lot of CISOs have been talking about or talking to are trying to figure out how do I deploy those technologies internally? How do I go find the models that I can train against my data sets that would actually go help my teams do their jobs better?

    What I would say is is that’s another one of those areas where, as you’re innovating and bringing in new technology, treat it like another digital workload. You’re still going to have to detect when something goes wrong. You’re still going to have to investigate when something goes wrong in that generative AI hallucinates, it has an outage, whatever, and you’re still going to have to respond to those outages and take those learnings and put it back into the operational process of how do you run that system more effectively.

    I think people need help oftentimes finding those consistent patterns that we have to deploy to just keep things securely up and running regardless of what the workload is under the covers, and I candidly see that as one of the greatest areas for leaders that are looking to partner with a professional services organization or an assay, those outside consultancies. There’s a lot of value there in having them help bring in the patterns especially on proven technologies to short cycle, increase your time to value or, excuse me ,shorten your time to value when thinking about those new digital workloads and making sure that they’re secure and up and running.

    Mitch Ashley: I like where you’re taking this, which is one I wanted to wrap with, which is our organizations are expecting us to innovate, not just ourselves innovate, but also support the rest of the organization to be able to innovate. You talked about Ransomware. The newest thing is they’re not encrypting your data anymore. They’re just threatening to release it, so it’s not a matter of losing the data. It’s losing control over it. AI is the next, maybe it’s the next boon to phishing. We may not be able to tell the difference between an email from a generative AI LLM that’s been trained on how our CEO talks versus a well-scripted, predefined email.

    These new kind of threat models as well as new technologies force us to innovate and find new ways to do things. We have to help our people with tools, technologies, processes. I’d love to hear some more thoughts about what do we do to set ourselves up for success to be able to innovate in a way that’s going to help support where the organization is today and where it’s going?

    Ryan Kovar: Well, I’ll make a slightly controversial opinion here. I don’t think there’s ever been a single technology that outweighs the benefits for the offense or defense. I look at generative AI as something that is going to liberate security organizations from the shackles of mundanity. It’ll democratize what we can do in terms of analysis. It will also do the same for the adversaries. The only people who will lose are those who are not taking advantage of this technology on either side.

    I really do believe that we can all up-level as we go through with different technologies just as the adversaries are. When we invented a trench or trench warfare in World War I, they invented the tank. When we invented an airplane, they invented anti-aircraft. This is a tit-for-tat thing, and there’s always a leap at some point. People created a star fortress and that stymied invasions until someone invented the cannon. Sometimes, defense beats offense and sometimes offense beats off defense, but it goes back and forth as you go.

    I don’t necessarily see anything that’s a semantic change in how organizations will defend, but I do believe, if you’re not paying attention, if you’re not innovating, if you’re not selecting vendors, if you’re buying software, if you’re not buying vendors who aren’t innovating, you’re going to have a very difficult time in the next five years because your adversaries absolutely are.

    Cory Minton: Yeah, and I would go maybe less digital and say we as leaders cannot underestimate and cannot undervalue investments that we make in our people and our business culture today that create space for the learning and the development and the skills attainment that Ryan talked about, being critical. Leaders must create space for technologists, for practitioners, for leaders to go learn and to go study and have a mantra of spending some large amount of time on a regular basis, on a cadence basis, investigating, whether that’s going and attending conferences and networking and starting to understand what’s happening in the industry or it’s partnering with a technology organization and doing more hands-on workshops and learnings or it’s going next, when you’ve got a consultant in, spending time with those folks in the office picking their brain on what are the skills that they’re paying you for? Why are you here? What is so unique about what you’re doing, and how do I learn more of that?

    It comes from leaders making that a priority. If we’re going to have an organization that has people, process and technology that’s actually going to be resilient, that’s going to be able to survive in this next epoch of technology innovation, it’s going to have to be led by the best intelligence, which is still human intelligence, and that requires investment, and I think you got to put a stake in the ground and make that a priority today.

    Ryan Kovar: I love that part because, going back to our previous discussions about leaders who often have 10, 20, 30 years of experience, none of it is relevant. When I started my career as CISO, my only half, well, first off, CISOs didn’t exist. Second, the CTO or the person in charge of technology at that company had to pay attention to desktops, printers and servers on-prem, and then 10 years ago, 15 years ago, it was laptops, desktops, printers on-prem, printers in the home offices, a data center that they co-located to in this little cloud thing that they’re trying out, and then five or 10 years ago, it was all those plus software as a service, and now it’s, okay, well, we have a CICD pipeline and we’re driving APIs and our entire business is dependent upon this one piece of open source software that’s maintained by three guys in a former Yugoslavian Republic and, if it has an issue, we’re going to be done.

    Also, we M&Aed a company out of China. Every time they develop a vulnerability, that has to go to the Chinese government along with us. It’s a lot more complex. For those who are just resting on their laurels of “I’ve been doing this for a while” and not up-leveling their own education and hiring people who are subject matter levels as direct lieutenants, you’re going to have a bad day.

    Mitch Ashley: Bringing it back to the thinking that got us here is not the thinking that will get us to the next place, I’m paraphrasing Einstein here, but it’s also our own thinking. That’s the value of bringing in perspectives like yours with your partners, your suppliers, companies like Splunk, professional services. There are a lot of ways. I think we’re at the same junction point where we were with the cloud. Where we’re like, “Here’s the cloud. Is it just somebody else’s computer or is it a new way of doing things?” But what is that new way?

    We’re kind of in that place today with AI. Okay. Right. We know we can do generative AI stuff, but what does it really mean? How do we leverage it, to your point, Ryan? You have to be a participant on the field to really figure that out. You don’t have to go spend crazy money on the latest thing just because that’s what was in the airline magazine, but it is about figuring out and learning what you can do with it and what’s possible learning by yourself, but also with others.

    Well, thank you to both of you, to Cory Minton and Ryan Kovar, for joining us, and thanks to the Splunk team for bringing us together to have this conversation. We hope it’s been really beneficial to everybody who’s listening in. I know it’s been great for me as well. Thank you.

  • Splunk Goes Azure With Microsoft Partnership

    Splunk Goes Azure With Microsoft Partnership

    It’s not every day that a well-established technology provider announces they are building their solutions on a new cloud technology stack, but that’s what Splunk announced at its .conf23.

    “…[O]ne of the most exciting [announcements] is Splunk’s new strategic partnership with Microsoft to build Splunk’s cloud solutions natively on Microsoft Azure. Together, our approach will enable our joint customers to migrate, modernize and grow their environments with end-to-end cloud and hybrid visibility at scale,” Splunk President and CEO Gary Steele said in a Splunk blog post this morning.

    Why such a bold move, might you ask? “Splunk’s strategic partnership with Microsoft to build Splunk natively on Azure demonstrates our commitment to advancing digital resilience and meeting our customers where they are…” Well, indeed, a big, big draw is the vast landscape of customers building and operating applications in Azure. While Gary didn’t share too many details about specific new capabilities or offerings yet, customers will get to use their Azure credits for Splunk offerings. I suspect two other important underlying factors made such a tech marriage happen: Open source and AI.

    First, Microsoft is far removed from the days of being viewed as a pariah by the open source community and is now a leader and contributor to well-known open source projects (OpenTelemetry, to name one); it abandoned its proprietary service mesh tech and got behind Istio (a recently-graduated CNCF project) and now owns the largest open source repository ecosystem with GitHub.

    While Splunk is by no means a noob when it comes to incorporating AI into products, the company continues to announce new AI capabilities, including a generative AI chat interface with a preview of Splunk AI Assistant, an improved version of the former SPL Copilot. Other AI-related announcements include Splunk App for Data Science and Deep Learning (DSDL) 5.1, which allows customers to leverage LLMs to build and train models with their domain-specific data for text summarization and text classification use cases. Stay tuned for more from .conf 2023!

  • PingCAP’s Innovative TiDB Database – Techstrong.TV

    PingCAP’s Innovative TiDB Database – Techstrong.TV

    PingCAP CEO Max Liu discusses PingCAPs innovative TiDB database and cloud technologies for OLTP + OLAP, and PingCAP’s commitment to open source going back more than seven years. Max shares some exciting news about the very first HTAP Summit, coming to the bay area soon. The video is below followed by a transcript of the conversation.

    Mitch Ashley: Well it’s a great pleasure being joined by Max Liu. Max is cofounder and CEO of PingCAP. Welcome Max.

    Max Liu: Hi Mitch, good to see you.

    Ashley: Good to see you, thanks for joining us. So, we’re gonna talk about database, one of my favorite topics. Before we do that, would you introduce yourself? Tell us a little bit about you and also tell us a little bit about PingCAP.

    Liu: Well, thanks for having me. I’m Max Liu, CEO and cofounder of PingCAP. And our product is TiDB, T-I-D-B which is an open source distributed database. You know, I’m a software engineer for more than 15 years and I still enjoy coding. Before I started PingCAP I spent lots of my time, you know, designing and table schema carefully and fixing those database scaling issues and trying to make coding faster. And since, so many engineers, no developers, wasting their time again and again doing the same thing.

    So, we started the TiDB project to build a dream database for engineers to handle scalability from terabytes of data to petabytes of data to let developers focus on C-code and SQL, sorry, and, for their business logic. So they can enjoy, you know, sleep so you can get more sleep. Not only, you can still keep your hair, not like me, right? So, enjoy or other fun.

    And, also, many people have found that our company name is interesting. PingCAP is actually composed by two parts, ping and CAP. So, CAP is the C-A-P theorem, you know? Standing for consistency, availability, and tradition tolerance. You know, it’s like an ideal case for distributive database, right? So, Ping is just the narrowed comment while you are trying to connecting to anything you will ping it, right? So, I love this theorem so much. And, we want to keep as close as possible approaching CAP. So, that is where we, you know, use the name PingCAP. That is where the name comes from.

    Ashley: Makes total sense.

    Liu: Yeah, it’s quite tactile, right?

    Ashley: [Laughs] well, you know, it cares meaning and that’s one of the great things. And, I can sense already about your story, Max is, it’s great to talk to fellow entrepreneurs who – you know, it’s one thing you would say, “That’s a great idea, let’s go build a product for that.” It’s another thing when you’ve experienced that challenge, you’ve lived this problem, you’ve spent maybe, many hours, maybe many years, right? Kinda, being the developer but, trying to be a DBA, and a developer, and a data analyst, and a data designer. But, you’re not really, you’re a developer, right? You don’t want all the hassles of all those other jobs. So, how do you make it easier, how do you make it better for people? Which, sounds like what you’ve tackled, what you’ve done with PingCAP and with TiDB. Am I on path here?

    Liu: Yeah, it’s not easy.

    Ashley: [Laughs]. Well, let’s talk about the database market in general and, as I mentioned to you earlier, you know, I started doing database work long long ago. It’s not a new topic by any stretch. And, of course, there’s a lot of database products in the market. So, what’s unique and different about TiCAP, TiDB, excuse me, and PingCAP that helps you stand out? So, why would the developers say, “Oh, that’s what I want. I’d like to use TiDB ’cause that does these things for me.”?

    Liu: Well, that depends on the values you provide for you customers or developers. So, there are many key values that PingCAP brings to our customers, users, and a wide range of the community and, of course, through open source. So, first of all, we are open source believers. Now, open source is the core philosophy of PingCAP which is always leading the wheel of TiDBs development. So, beside TiDB we also contribute a lot to the community.

    We have donate two open source projects to CNCF apps. One is TiPV as a distributed key value storage. And, the other is Chaos Mesh so, as a chaos testing platform. You know those projects can help other software developers to build a more scalable, more resilient system. While you’re building a distributed system you’re trying to, you know, simulate, kind of, you know, disk force and network down and network recover, things like that. So, that’s why we need, you know, a chaos testing platform.

    So, second, although we know the database market, you know, is so crowded, right? But, there is no such product can be used as a primary database to solve both, transactional processing and analytical processing like TiDB. Now as a foundation, TiDB is designed as a scalable, online transaction database. So, it can easily support hundreds of terabytes to, you know, petabytes of data while still serving millions of requests per second. So, what’s more you can even run realtime analysis on the same database without moving the data from, you know, TiDB to some other OLEP data warehouse.

    Let’s imagine if you are building a SaaS system, there is always a operational dashboard for your customer, right? While you’re logging into any sass system you got a summary, right? That is operational dashboard. You need to generate that dashboard, realtime, on the same database. It is more natural for developers to operate their data on the same source of code. So, this technology is called HTAP, hybrid transactional processing and analytical processing. So, the concept is not new but, the implementation in a cloud native way is fresh. I think it’s a disruptive trend in the database industry to make, you know, everyone’s life and work easier. 

    Ashley: That’s really interesting to combine those two things together because, often times you thought of the old data warehousing or data lakes or different environments to do analytics in. But, actually being able to do analytics on top of transactional applications and data on the same environment, what are some of the things you have to do to be able to handle those two different kinds of workloads? ‘Cause, they can be very different, right? We want really fast transactional responses.

    Liu: Yeah.

    Ashley: Sometimes, pretty complex analytical questions that we’re asking, right?

    Liu: Yes, you’re right. So, we basically have two different storage engine, a row store and a column row store but with the smart optimizer on top of both row store and column row store, right? So, if there is occurring the optimizer will predict is busy OLTP query or is busy OLEP query. Or, even better it can be a hybrid query we can query, you know, just this single row from a row store and do some, you know, aggregation on the column row store. It’s a little bit technical, you know.

    Ashley: No, no, I get it. So, I mean, I assume your analytical queries might tend to be more by column versus your transactional by row. Is that a good generalization? I mean, it starts there?

    Liu: Yeah, yeah, exactly.

    Ashley: Interesting. And, you can mix those and do hybrid or both. So, is it views into the data or is the data redundant so that they can handle different loads on the two types of storage or is it just views into the same data?

    Liu: So basically, we have a replication algorithm. It is called a raft. So, we use raft to replicate data and store them both as a row store and as a column row store so, you have two copy, right? So, then you can design a optimizer to choose what kind of data, which piece should I use, right? 

    Ashley: So that – 

    Liu: Just by, basically, replicating them, you know.

    Ashley: All that admin work to set up your analytics environment. Essentially, you get that with the database, right? It comes with it?

    Liu: Yeah, but – 

    Ashley: You’re doing the replication for them.

    Liu: Yeah. From the user perspective, they operate on the same database. There is no – I don’t need to build my skill set, you know? Like, I need to know how to do manual shouting for a OLTP database and using some kind of ETL tools to load the data to OLTP data warehouse. And, I need to learn different kind of cycle, different kind of, you know, query optimization, you know, for two database to optimize it, right? And, so many things you need a totally different skill set for it.

    Ashley: Tell us a bit about the cloud part of this strategy. So, are you primarily or only working in the cloud, do you also work on premise in customers own data centers? Where does TiDB live?

    Liu: This is a good question. We invest a lot into TiDB cloud. TiDB cloud is a cloud service on top of TiDB, which allows us to, you know, provide, you know, a faster attempt to value for our customers. And meanwhile, reduce the burden of maintenance. You know, maintaining a distributing system is kind of a pain, right? So, just like other open source infrastructure companies such as Elastic, Confluence and et cetera. So, as a team behind, you know, TiDB we treat the relationship between open source and cloud strategy seriously. So, I would say that PingCAP will ensure the core components of TiDB 100 open source. And, without any functional loss. We actually achieve this by three actions.

    First, we build an active open source community. You know, TiDB is backed by more than 800 contributors across multiple countries and industries. We actually built a demo on top of TiDB cloud which is called OSSinside.io. So, everyone can easily check any open source GitHub repositories with details of stats, contributions, commits, and you can even compare to different projects and so on and so forth. And, for the demo itself, it is open source too. You know, as I mentioned, you know, we are open source believers, right?

    So, the second, we make sure TiDB is environment agnostic. So, the goal of TiDB is to achieve consistent user experience and a multiple deployment form. So, basically you can deploy TiDB anywhere, in public cloud, in private cloud, in VNs, containers, and bare metal.

    Third, I think this is the most important one, TiDB is designed as an open system. So, we keep investing the integration with different other ecosystem such as Kafka, Link, Spark, Snowflake, Data dog, and so on. So, this openness in the capability are also work to our call service as well.

    Ashley: Very interesting. One of my questions is, are there different users for the analytics capabilities versus the high speed transaction or, do they tend to be the same groups of people? Is it primarily developers using both, or do you end up with different users for different capabilities?

    Liu: Well, they’re, kind of, different users. Database is so generic, you know, for any digital native business company they all have a database, they have different user scenarios. Not for those huge companies, big companies, they enjoy the scalability of OLTP features. So, they don’t need to worry about how to scale my system. Those big companies, especially for internet companies, they have a big dev team, right? They have a database team. So, the database team care about the scalability of the database but, the big data system team, they care about the analysis of big data.

    But, for those, you know, medium company and startup, they just want a single database and they can handle everything. So, I don’t need to, you know, hire more engineers, I have no resource, you know, for those small companies, medium companies. I have no resource to hire, to build to different large team for OLTP database for big data, right? So, they want a single technology, a single database to solve everything. So, it’s different.

    Ashley: Makes sense. You mentioned distributed database then also, since you can your own data replication across the environments, the column and row environments, I assume you can also do distribution across different locations in cloud providers or a cloud provider. So, if you want it distributed closer to the edge or, you know, closer to the data center or different geographic locations that’s also part of TiDB, is that correct?

    Liu: Yeah. You can deploy TiDB to different zones. In all this is basically a default capability for distributed database. If you don’t have this kind of capability nobody’s going to use it, right? But, for edge functions, edge scenarios, currently, we don’t have the ability to support that. It’s just the, everything on cloud or deployed by yourself.

    Ashley: I guess, as the cloud comes closer to the edge you can be on the edge that way, right?

    Liu: Yeah. The open source database TiDB chose to compatible with mass scale protocol. So, all of those mass scale users, they don’t need to, you know, do lots of migrations, right? They can simply, you know, just move the data to TiDB and everything just works. And you know, mass scale is a TCP protocol, right? So, usually if you are using some kind of scenarios, edge functions and they are talking about using a HTTP protocol. So, you need a kind of, proxy and to route the request into, you know, TiDB cloud.

    Ashley: Interesting work. Tell me a little bit about the open source versus the commercial version. What are the differences in the product? Are you doing newer features, kind of, things that are more experimental, you’re trying out a market first in the open source or, are there more management capabilities in the paid for version? How do you distinguish the two?

    Liu: Well, actually there are three different versions. Let me explain a little bit more. So, first one is TiDB community edition. So, it has all the core capabilities so that developers can enjoy, you know, the latest TiDB features and able to contribute back. So, you can even get a nightly version, every day to enjoy the new features, right?

    The second one, and for sure, it’s TiDB cloud. So, the new features are first released in the community version and after, you know, validation and polishing by a large number of community users they will come back into TiDB cloud. And then, what’s next is TiDB long term support version. So, this is kind of, our most stable features and professional service support by PingCAP provide for enterprise users. So, this kind of users they might not be interested in the new features immediately. I will wait, right, wait until it’s extremely stable. Maybe, a year later I will use it in production, right?

    Ashley: Makes sense for maybe a finance company, someone in finance industry or manufacturing.

    Liu: Yeah, you’re right. Especially for those banks. So, this release model actually helps us to get feedback faster from, you know, day to day operations of TiDB cloud by ourself and from, you know, the community. And, that also creates a faster loopback to TiDB’s roadmap. So, the verified and polished features will be posted to enterprise users through LTS release faster. This is kind of like, you know a flywheel, right? So, we can drive a faster time to value for both community users and enterprise users no matter how TiDB is deployed. So, to summarize, we have three release to different deployments but, a consist user experience in the process.

    Ashley: Excellent. Well, I wish we had more time, love to hear more about it. Hope you’ll come back. Where can folks find out more, download the open source, or try out the cloud version? How can they check things out with you?

    Liu: Well, thank you Mitch. Good to meet you, talk to you. Thank you.

    Ashley: You bet. And so, folks can go to what, PingCAP.com? That correct? Your website?

    Liu: Oh, oh, oh, one thing. So, I’m very excited to share that we will host the very first HTAP summit on November 1st. Yeah, you might be in the area. It’s very, you know, meaningful value computer history museum where I enjoyed a lot with so many historical moments and memories. So, at the summit we will, you know, be joined by many dev industry leaders and worldwide developers. And, also, includes some of important customers from Asia, for Europe, from the United States to discuss disruption and innovation. And, of course, all of you are more than welcome to check PingCAP.com on the HTAP summit page. And, I do look forward, you know, to connecting all of you in November.

     

    Ashley: Well, excellent. I hope you have a great conference on the first of November and folks head out.

    Liu: Oh, thank you very much.

    Ashley: As well as head over to PingCAP and check out TiDB. Thanks again Max, we appreciate you being with us. Max Liu who is cofounder and CEO of PingCAP. Thanks again Max.

    Liu: Thanks Mitch.

  • Transforming Observability

    Transforming Observability

    Walking into an unfamiliar operations center some time ago, I immediately noticed database error alerts racing down the primary monitor faster than a Matrix screensaver morphs letters. Strangely, no one seemed particularly excited about it. The situation was a head-turner for me, coming as I did from the “everything must balance” banking world.

    A senior ops tech quickly explained that airline reservation systems are highly optimized for speed and volume, sacrificing nearly everything else to meet peaks. “No worries; the agents just hit Enter again. Retry logic just slows us down,” they told me. The lesson here was removing constraints can profoundly change a system, much as Dr. Eliyahu Goldratt described in his game-changing Theory of Constraints.

    Today, cloud-native architecture, multi-cloud and hybrid cloud platforms, dynamic infrastructure-as-code (IaC), DevOps and our ability to store boundless amounts of data each change or remove constraints in their own way. Observability could be on this list, but I think observability’s transformation is still happening right in front of us.

    Observability and OpenTelemetry

    Through open source OpenTelemetry (OTel), highly competitive vendors collaborate to shift their offerings up the value chain by supplementing and replacing once highly-prized proprietary agents, interfaces and data specs. There’s no better example of removing a constraint than making these once proprietary agents with an open solution that will have profound effects across the industry.

    OTel is a thriving ecosystem of 11 tech companies participating on various boards and committees that also collaborates and integrates with open source projects such as Jaeger, Kubernetes, Prometheus and OpenMetrics. Over 20 observability companies natively support and provide OTel distributions. OTel continues to mature, reaching stability 1.0 release in 2021 and announcing its roadmap for metrics specifications in 2022.

    OTel-native support represents a significant commitment from vendors because it means rearchitecting products to distribute data via OpenTelemetry Protocol (OTLP) rather than using OTel SDKs and Collectors frontend internal interfaces. With SolarWinds’ October 2022 announcement, I suspect they will also join the ranks of companies supporting OTel natively in their commercial offerings. 

    Digital transformation, product and technology leaders see value in observability because of its potential to measure digital experiences and measure the performance of business and digital services. To do this requires observability to meet three significant challenges.

    First, observability must effectively cross the complex boundaries of microservices, containers, cloud and traditional applications, multiple cloud providers, database sources, SaaS services, infrastructure and internal and external APIs. Today’s challenge is far beyond the central aggregation of large volumes of log data and suppressing non-essential alerts. 

    Most enterprise architectures look eerily similar to a breadboard wiring project with applications, systems and data sources crisscrossing each other, representing the various pathways and interfaces across systems. Virtually any of these elements could contribute to the degradation of a digital experience, and observability must operate across these elements whether they live in our tightly controlled data centers or are distributed in microservices, cloud services or third-party interfaces.

    With this breadth and depth of visibility, we also need context to match and correlate what appears to be disconnected information and sources. Open source enthusiast Chris Engelbert describes this challenge well:

    “The data correlation, the knowledge of how the infrastructure and services are deployed, as well as the dependency tree of applications, services and (eventually) hardware, must be taken into account when providing hard evidence of what is going on in your system.”

    Following the Silver Thread

    With context and dependencies, observability can allow us to see what software developers call the “silver thread,” the ability to collect the components of systems involved in measuring an experience or triaging a performance issue. Then we can follow the pathway, or silver thread, across all the components, whatever or wherever they are, to find constraints or bottlenecks. For example, a particular API’s poor performance may be due to the location and traversal necessary to reach a needed data source rather than an issue in that API’s microservice or application.

    In summary, observability is invaluable to monitoring, operating and triaging modern applications and cloud infrastructure. The adoption and maturation of OpenTelemetry will deliver many benefits, including the removal (or, at least, greater transparency) of traditional boundary constraints. And with the context to understand and follow the silver thread, observability transforms beyond operations to measure digitally delivered business services and experiences.

  • Microservices Explained: Not Your Father’s SOA

    Microservices Explained: Not Your Father’s SOA

    Microservices are frequently referred to as a variant or derivative of service-oriented architecture (SOA), if not essentially the same thing. While there are similarities and both are designed around the concept of services, that’s where the similarities end. Each was created around a different set of principles and intended to address different problems.

    Microservices architecture is built around key concepts that, when applied, not only differentiate it from other architectures but deliver advantages that accelerate software delivery and help to scale large, complex applications. To deliver on the promise of cloud-native, microservices must be loosely coupled so that, ultimately, they are independently deployable. Any microservice can be updated and deployed—just that containerized microservice—without requiring changes to other microservice(s). Loosely coupled microservices mean they are not sharing databases or maintaining state, for example.

    How big should a microservice be? Or, in other words, how much should it do? The answers range from ‘a single thing’ to ‘a small set of related code with high cohesion’. Another factor is that getting too granular can overrun a microservices-based application with large numbers of microservices, increasing complexity and making triage through observability and tracing very challenging.

    Scaling microservices-based apps is another important factor. Autonomous microservices can be replicated and scaled for performance and workload using container orchestration tools such as Kubernetes.

    Microservice communications are achieved through well-thought-out APIs created around the business or operational capabilities the microservice provides to anyone or anything engaging through the API. The API, and data provided through the API, are often referred to as ‘technology-independent.’ It’s probably better stated that microservice APIs are built using approaches like RESTful and GraphQL over networks that are not tied to any one specific operating environment, technology or programming language. JSON, YAML and XML similarly represent data that is transferable across technologies.

    The following diagram of a media application demonstrates the principles of microservices architecture. Microservices for scheduling media, digital rights management, tracking impressions and adding new ad insertions are loosely coupled, autonomous and have well-defined API interfaces. Each microservice can be changed, enhanced and deployed rapidly and independently of other microservices.
    Microservices SOA

    Service-oriented Architecture, or SOA, emerged to solve a very different problem; the overwhelming size and complexity of monolithic applications. Monolithic applications have very large codebases that often don’t do a good job of compartmentalizing functional or business logic. This makes changes to the codebase challenging even to developers who know much of the codebase well.

    Services in SOA were often used to gather a collection of similar business logic together and then share them as a service with other parts of the application, as needed. Technologies like message buses are used to make requests of a service and operate as traffic managers for requests across multiple services and other parts of the application. While reusability was a critical design consideration, SOA services were still quite large, and deploying services at high velocity was not an important design consideration. SOA services often take considerable time to code and test the service including interdependencies across other parts of the application before deploying as part of a larger software release.

    One important note: There are benefits and drawbacks to microservices and SOA architectures; neither is ‘better’ than the other. Which architecture to use when mainly depends on the purpose of the application you are building. For larger, more complex enterprise application environments that require integration with many other applications, you might choose SOA. That’s a better fit than for smaller applications that don’t require middleware elements for managing the requests within the app or between other applications. Microservices, on the other hand, are better-suited for smaller and well-partitioned web-based systems. They are becoming the standard for today’s cloud-native applications, and also are a great fit for developing a mobile or web application because they give developers more control.

  • DevOps World 2022: A DevOps Retrospective

    DevOps World 2022: A DevOps Retrospective

    With the seminal IT conference DevOps World 2022 in Orlando September 26 to September 29 upon us, I think about the pivotal industry conferences and events critical to my path to the cloud, DevOps and cloud-native. It brings me to this brief retrospective, highlighting some of the most significant influences that still guide my path today.

    I highlight these for you as conferences, books, emerging development tools, and changes in infrastructure delivery all played critical roles in my completely rethinking of how we create software through DevOps.While leading IT for a global R&D industry consortium from 2010 to 2016, I was unknowingly in the middle of a significant shift from designing network protocols to entirely moving to the cloud, creating self-service development portals and automating the development process.

    This journey began partly when a friend and colleague, Alan Shimel, creator of the then-new staging-devopsy.kinsta.cloud site, said, “Check out this thing called DevOps … and you gotta read this book!” Looking back at my Amazon order history, I see I first purchased The Phoenix Project in November 2013. The book immediately became the main topic of discussion among my engineering team. While we didn’t label it as a DevOps tool then, Jenkins established the basis of our DevOps toolchain across multiple software-based research projects. Other technologies, including Artifactory, Maven, Git, GitHub, Bamboo and OpenShift, for example, quickly followed, enabling us to spin up development environments for many new software projects. In less than a year, we completely retooled IT from a significant bottleneck to becoming the easiest path to creating new software projects by equipping teams with DevOps, development tools, environments and cloud platforms.

    Jenkins World (now DevOps World) helped me understand the central roles CI and CD played in creating automated workflows and delivering software more quickly from development into test environments. The first AWS re:Invent helped me rethink the cloud, from a data center scarcity mindset to making compute, storage and bandwidth resources harnessed through automation and a credit card. I wrote my first post about DevOps in 2014, The DevOps Journey, where I did my best to make sense of precisely what DevOps is.

    As I go back and reread that post, I’m surprised how much of those thoughts still apply in 2022. Today, I continuously read many technical books, learn from thought leaders and attend influential conferences, including this year’s DevOps World. I wonder what will change how we think about and create software again in the next decade!

    If you can, join us in Orlando for DevOps World. Techstrong.TV will be broadcasting live from the event; if you can’t make it, we’ll keep you updated on all of the developments announced there. Also, join us in November for our own DevOps Experience virtual event, which will highlight DevOps Everywhere: The Edge and Beyond. Hope to see you soon!