devopsy.kinsta.cloud

Category: DevOps Practice

  • Is SASE the DevSecOps of Infrastructure Management?

    Is SASE the DevSecOps of Infrastructure Management?

    DevOps gained traction when IT and Ops (operations) teams recognized that traditional silos and handoffs were leading to inefficiencies and delays in software delivery. While DevOps enabled seamless collaboration and delivered on its promise of speed and efficiency, security remained an afterthought. To overcome the security loophole, DevSecOps emerged, proposing a shift-left approach to security. It emphasizes conducting tasks like security scanning, vulnerability assessment, and compliance checks all throughout the CI/CD pipeline.

    With DevSecOps, speed no longer comes at the cost of security.

    The DevSecOps approach has helped organizations strike the right balance between security and agility in software development. As the infrastructure landscape continues to evolve with the rise of cloud and edge computing, resource-intensive AI and ML initiatives, and distributed workforces, organizations must establish a similar balance between security and ubiquitous connectivity. This is where secure access service edge (SASE) comes in.

    SASE’s Philosophy is Similar to DevSecOps

    As legacy networks — characterized by rigid hardware-based infrastructure — struggled to keep pace with the demands of modern business, SD-WAN emerged as a solution, providing flexibility, centralized management and dynamic traffic routing. However, when distributed computing and remote work virtually dissolved the corporate perimeter, perimeter-focused security tools were no longer sufficient either. Today, enterprises must extend their security capabilities to almost unlimited network access points.

    SASE addresses this challenge by merging networking and security into a single cloud-native framework. It integrates the entire security stack across all edge locations, ensuring secure connectivity between users, applications and resources no matter where they are. Just as DevSecOps shifts security to the left, making it an inherent part of the entire SDLC (software development lifecycle), SASE shifts security to the network edge, making it an inherent part of network connectivity.

    The strategic resemblance between the philosophy behind SASE and DevSecOps is uncanny.

    1. Breaking Silos

    DevSecOps breaks down the silos between DevOps and security teams, promoting collaboration and shared responsibility. In a similar vein, SASE unifies all network and security functions into a single architecture, effectively dismantling the conventional boundaries between the networking and security teams. It allows both teams to jointly manage, monitor, and secure the infrastructure and network traffic through a unified management dashboard. SASE also effectively breaks the data silos that leave security teams with no insights regarding the networking conditions. SASE’s single pane of glass visibility enables networking and security data correlation, broadening each team’s perspective and eliminating tunnel vision for accurate and robust threat detection and an enhanced security posture.

    2. Embracing the Cloud

    DevSecOps aligns perfectly with cloud-native technologies like infrastructure as code (IaC) and containerization technologies like Docker, making it imperative for cloud-first and cloud-ready organizations. On the other hand, SASE is inherently cloud-native. It delivers network and security services from the cloud, providing organizations with the agility and scalability needed to meet the dynamic demands of a distributed environment.

    Traditional back-haul-based connectivity and perimeter-based security solutions introduce latency and coverage gaps. SASE performs network and security functions at the edge, closest to wherever resources and users are. This eliminates the need for disparate on-premises point solutions and extends corporate security perimeter to match the cloud’s global reach.

    3. Agility Through Automation

    DevSecOps emphasizes automation of security tasks, such as security checks, scans and compliance assessments, within its continuous integration and continuous delivery (CI/CD) pipelines. SASE also leverages automation for networking and security tasks, such as dynamic policy enforcement, AI-driven threat detection and response, and network optimization through dynamic routing and self-healing properties. Automation reduces the need for manual intervention, bolsters security, simplifies operational tasks and enables organizations to respond to evolving demands and circumstances faster, crucial for agile environments.

    SASE as an Enabler for DevSecOps

    Just as DevSecOps enhances security within the context of application development, SASE enhances security and efficiency within the realm of networking and infrastructure management. Both approaches share the common goals of integrating security, promoting automation and ensuring scalability. They may apply these principles to different aspects of IT and cybersecurity, but DevSecOps and SASE can work together seamlessly to support modern IT environments.

    Many organizations adopting DevSecOps realize that they lack the necessary infrastructure to support this approach effectively. DevSecOps demands seamless global collaboration and the integration of security controls across the entire IT environment. This is something SASE can help with. It can simplify infrastructure management and enhance security for DevSecOps in several ways. It offers ubiquitous connectivity for seamless collaboration, provides built-in security measures for faster incident response and ensures reliable infrastructure. As such, these are all crucial aspects for achieving the ultimate DevSecOps goal of delivering secure and high-performance applications at speed. With SASE, organizations can set their DevSecOps up for success.

  • 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, 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.

  • Three Strategies for Reducing MTTD and MTTR as Outage Costs Spiral

    Three Strategies for Reducing MTTD and MTTR as Outage Costs Spiral

    According to a New Relic survey of IT professionals, the median annual cost of IT outages has reached an astronomical $7.75 million. Over one-third of the 1,700 respondents said critical business application outages now cost more than $500,000 per hour. In a business environment where most interactions with customers, suppliers and business partners are conducted digitally, downtime has become a problem and an existential threat.

    Most IT organizations carefully monitor two key metrics — mean time to detection (MTTD) and mean time to resolution (MTTR) — to track their success in identifying and remediating critical systems issues. The figures represent, respectively, the average time it takes administrators to identify that a problem has occurred and to remediate the underlying issues. They serve as a benchmark for understanding the organization’s level of awareness of the status of its systems and the speed with which problems can be diagnosed and acted upon.

    There are many ways to improve performance against these metrics, but three stand out as the most effective, as evidenced by New Relic and the survey results.

    Monitor Everything

    The less you know about a problem, the longer it takes to diagnose and fix. The New Relic survey measured 17 different observability categories, such as network monitoring, alerts, log management, browser monitoring and distributed tracing. Across the board, about two-thirds of the companies that used even one of those monitoring tools reported reduced MTTR, with many saying resolution times had fallen by more than 25%.

    One-third of respondents whose organizations implemented full-stack observability—which is the ability to see everything in the tech stack that could affect the customer experience—reported the fewest outages, fastest MTTD and MTTR, lowest outage costs and highest median annual return on investment compared to all respondents. For example, those who have full-stack observability experience a median outage cost that is 37% less than those without.

    As the complexity of enterprise technology stacks increases, so does the difficulty of pinpointing the root cause of an outage. Any monitoring is better than no monitoring at all, and the more visibility you have into applications and infrastructure the faster you can identify and resolve incidents. Strive for full-stack observability around integrated observability data and a comprehensive dashboard.

    Have an Incident Management Action Plan

    The worst time to figure out how to resolve a problem is when you’re in the midst of a crisis. Organizations with mature observability practices also have extensive and documented response plans.

    Your incident plan will be unique to your organization. Small companies and startups tend to have ad hoc response strategies based on the skills within the organization. Large enterprises may use a more formal methodology like IT service management that defines strict procedures and protocols. Companies that have embraced modern DevOps and Lean principles often use a hybrid approach that depends heavily on teamwork and collaborative problem-solving. All of these approaches can work if the team fully understands the chosen strategy.

    Document your IT architecture, identifying known vulnerabilities and outlining procedures for responding to the most common types of incidents. Plans should cover obvious disruptions like fires and power outages, but you should also think about “unicorn” scenarios such as a rogue query that ties up a database server or a communication outage at a key supplier. Mature observability teams devote a portion of their resources to constantly testing new and unpredictable scenarios and use chaos engineering to randomly inject problems in a controlled manner to see if systems respond as expected.

    As you develop incident response procedures, document the processes in runbooks, which tell responders exactly what to do when a specific problem occurs. This not only creates a database of organizational knowledge about response strategies but also helps with onboarding new employees and covers for skills gaps that occur when team members are unavailable or leave the company.

    Fix for the Future

    Technical debt is a long-term obligation that is created when a short-term – and incomplete – solution is applied. You should aim to minimize it in your observability operation.

    When a problem occurs, the temptation is to fix it as quickly as possible. Human nature is to move on to the next task without taking the time to go back and understand why a problem occurred. “Quick and dirty” fixes are an invitation to larger problems in the future. Your observability plan should include a forensics stage that documents root causes and the fixes that were applied. Even if it isn’t convenient to implement a long-term solution immediately, the documentation serves as a guide for implementing a permanent fix down the road.

    Building a resilient IT architecture is a marathon, not a sprint. The more rigor you apply to identifying and resolving problems when they happen, the better prepared you will be to prevent their reoccurrence and the more informed your team will be about the resources they manage. Reducing your MTTD and MTTR will not only improve the bottom line of your business, it will ensure that your customers have an amazing digital experience.

  • Observability: The Central Watchtower Your All-Seeing IT Needs

    Observability: The Central Watchtower Your All-Seeing IT Needs

    If there’s something you need to keep secure, it’s natural to want to keep it sealed away under lock and key. However, even keeping something in a vault, far from prying eyes and ill intent, may not be enough to offer peace of mind. After all, how can you have the peace of mind of knowing it’s safe if you don’t regularly check to ensure it hasn’t bolted, been burgled or broken down?

    Now, multiply the volume and value of things being monitored tenfold — and you get a sense of the daily inefficiencies and anxieties IT professionals battle.

    Instead of jewels, these teams safeguard, manage and maintain something far more valuable: The data that underpins everything from business transactions to system performance to threat detection to service delivery and beyond. To make matters more complicated, today’s digital ecosystems are more complicated, distributed and disparate than ever before.

    Databases are critical to managing a successful IT department — and it’s time to discard the widespread industry’s perception of them as an unknowable black box. To be sure, databases represent the most difficult component of the IT ecosystems to observe, tune, manage and scale. But the database isn’t a Magic 8 ball in terms of its internal processes; We no longer have to shake the mystery toy and accept one of the six answers it’s designed to spit out.

    The fact of the matter is that database specialists and IT teams need a clear view of database performance telemetry if they want any hope of maintaining the health, stability and scalability of their services.

    Observability Tools

    This is where observability tools can play a transformative role. Taking its cues from the all-seeing panopticon watchtower, observability eliminates the dark corners of the database dungeon by providing a comprehensive view across the full cloud-native, on-premises and hybrid technology stacks.

    The word panopticon derives from the Greek word panoptes, or “all-seeing.” The panopticon model features a central, lighted guard tower at the center of a circular room — allowing 360-degree lines of sight that allow the guards to observe every surrounding cell from a single, centralized vantage point.

    English philosopher Jeremy Bentham had no way of foreseeing the challenges of today’s database professionals when he first conceived of the panopticon in the 1700s. The concept would lay the blueprint for a prison system designed around one core concept: Enabling the minimum number of guards to effectively monitor the maximum number of inmates. Bentham’s system also works as a strategy for ensuring the health and performance of your organization’s critical databases.

    The panopticon was designed so that every cell could be monitored from one central point — ensuring not only better and more straightforward security but preserving resources in saved time, manpower and effort expended. Think of your ITOps, database, DataOps and DevOps teams as the wardens of your IT performance. Traditional monitoring can be likened to patrolling a traditional prison: Rows of cells facing out into a hallway that is patrolled on a schedule or used to spot and address misbehavior as it’s noticed.

    How can they be sure they’re focusing their efforts in the right place? Or trust that Cell Block A won’t stage a breakout while they’re breaking up an argument in Cell Block B?

    In short: They can’t. Odds are, the team is either running from outage to outage in an everlasting firefighting mode or relying on random spot checks for something as vital as the health of our IT systems.

    Observability, as opposed to monitoring, puts teams into that central panopticon watchtower, allowing them to not just see everything, but to see it within the context of the bigger picture. This comprehensive visibility and always-on observation enable IT teams to identify critical issues as they occur, even those caused by complex dependencies between the database, operating system, storage subsystem and network.

    Database Performance Issues

    Furthermore, database performance issues are a starting gun for costly bottlenecks or serious outages that can handcuff your company’s ability to compete or grow. Without complete and precise database monitoring and observability, IT operations struggle to accurately determine an application’s root cause of performance issues. This increases the risk of downtime, data loss and poor customer experiences.

    Discovering the root cause of performance issues is quite literally a system-critical undertaking, whether you’re simply running your enterprise, scaling your operations or deploying new code. Observability also offers teams the rare opportunity to get ahead of performance issues since you can see performance anomalies in advance of a service disruption rather than relying on real-time remediation.

    With traditional methods, DevOps and IT teams must manually analyze the data presented to them, correlate it to the problem, and locate the error before they can finally begin addressing it. In contrast, observability collects data to provide information on what’s not performing as expected and why. This allows teams to take a proactive approach to solving downtime and bottlenecks and proactively preventing them.

    In the software world, that translates directly to more time spent where it matters: Developing new business value within your applications and infrastructures, fueling innovation and exceeding customer expectations.

    Given how complicated the modern database has — and continues to — become, arming your enterprise with the right observability solutions can provide a boost to efficiency and performance and pardon your teams from a sentence to time-consuming, mundane and error-prone work.

  • Bitrise Tightens Mobile DevOps Integration With AWS Cloud Services

    Bitrise Tightens Mobile DevOps Integration With AWS Cloud Services

    Bitrise this week will tighten integration with its DevOps platform for building and deploying mobile applications and the application development services provided by Amazon Web Services (AWS) cloud.

    Announced at the AWS re:Invent 2023 conference, the goal is to provide easier access to automated building, testing and release management capabilities provided by AWS as part of an effort to increase overall efficiency.

    Bitrise CEO Barnabas Birmacher said those capabilities will streamline workflows for a Bitrise Mobile DevOps platform that has been specifically designed for building and deploying mobile applications that typically need to be updated frequently.

    Based on a continuous integration/continuous delivery (CI/CD) platform developed by Bitrise that can be deployed in an AWS cloud computing environment, the integrations will make it simpler to build and run mobile applications at scale, noted Birmacher.

    The goal is to reduce the total cost of building mobile applications while at the same time improving developer productivity for mobile applications that have to be thoroughly tested before being made accessible via an application store, he added.

    It’s not clear how many organizations will prefer to have a dedicated CI/CD platform for building and deploying mobile applications versus using the same CI/CD platform they might already be relying on to build and deploy other applications. Bitrise claims to have more than 6,000 customers, including Reddit, WISE, Equinox and Philips Hue.

    As the percentage of mobile applications that make up an organization’s portfolio continues to increase, the pace at which those applications need to be updated lends itself better to a CI/CD platform optimized for those types of applications, said Birmacher.
    In fact, a recent survey conducted by Bitrise found 62% of respondents have been adversely impacted by manual processes that slowed the rate at which mobile applications were deployed and updated. The survey also found (44%) of respondents reported their release approval process is mostly or entirely manual, with only 9% having fully automated application releases.

    The survey also found that nearly two-thirds of organizations (66%) have deployed applications that can’t be opened in two seconds or less, which is widely considered the accepted level of performance required for mobile applications. In addition, three-quarters of organizations (75%) required more than two days to address bug fixes.

    Many mobile apps have become increasingly mission-critical thanks to digital business transformation initiatives. Consequently, the amount of focus on them within most organizations is high; any issues that arise are likely to be noticed at the highest echelons of an organization. That level of attention can easily put pressure on DevOps teams, mainly because the general expectation among end users is that mobile applications will be regularly updated with new functionality. However, if release processes are largely manual, regularly improving the user experience can become problematic.

    Each IT organization will need to decide for itself how best to go about building and deploying mobile applications, but the one thing that is certain is adjustments to DevOps workflows will need to be made as a lot more of these applications are continuously built, deployed and updated.