devopsy.kinsta.cloud

Category: Containers

  • Kubernetes and Service Mesh With StackRox

    Kubernetes and Service Mesh With StackRox

    DevOps and Kubernetes enable organizations to “go with security,” adding security to the code instead of on top of it. In other words, security is built-in rather than bolted on.

    This is one of the aspects of security in the DevOps world with a Kubernetes system that Ali Golshan, co-founder and CTO of StackRox, explained during this exclusive interview with Alan Shimel, Media Ops CEO and editor in chief. The other aspect is security has become continuous instead of snapshots, which provides “a lot more visibility into various stages, various deployments, as well as running environments,” he said.

    During the interview, he explored containers, orchestrations, Kubernetes and service mesh.

    “Leveraging this cloud-native infrastructure, Kube and service mesh the right way reduces your dependency on third-party tools, allows you to hand off things you typically handed off to vendors and does that inside your infrastructure, which makes it actually more secure and highly scalable,” said Golshan. “You can automate that and reduce your lock-in and your sort of dependency.”

    Check out the interview below to learn more about the best and emerging practices in Kubernetes, service mesh and the security feedback loop.

    — Veronica Haggar

  • DevOps Chat: Holistic Kubernetes and Cloud-Native App Security, With StackRox

    DevOps Chat: Holistic Kubernetes and Cloud-Native App Security, With StackRox

    More than ever, application security is a top priority. Beyond secure coding practices, a holistic app security strategy addresses the full application and infrastructure stack. This includes containers, microservices, orchestration, infrastructure software and the cloud. Bolting on the next security tool may not be the answer.

    Kamal Shah, StackRox CEO, joins us on this DevOps Chat, diving into the need for a systemic security approach across the life cycle of cloud-native, even “Kubenative,” applications. We explore how Kubernetes and cloud-native apps bring access to rich configuration information, usage visibility, runtime context, inherent security controls and compliance. It’s a fascinating conversation that will open up new paths to secure Kubernetes and cloud-native applications.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, this is Mitch Ashley from devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today I’m joined by Kamal Shah, who’s CEO of StackRox. Our topic today is security in a cloud-native world. Kamal, welcome to DevOps Chat.

    Kamal Shah: It’s great to be here, Mitch. Thank you for having me.

    Ashley: Well, I really appreciate you taking time out of your schedule. I know you’re very busy. Happy to have you on. Would you start by introducing yourself? Tell us a little bit about you and what you do. Of course as CEO we can imagine, but also a little bit about StackRox.

    Shah: Absolutely. So again, I’m Kamal Shah. I’m the CEO of StackRox, and StackRox is a leading provider of security and compliance solutions for your cloud-native infrastructure. So as you’re embarking on your journey towards microservices, containers and Kubernetes, we help you address your security and compliance requirements across the entire application life cycle from build to deploy to runtime.

    Ashley: It’s about secure software, especially in a cloud-native containerized world. That’s for sure. Well, tell us a little bit about how you approach this problem? You know, how do you think about security in a kind of contemporary app development world where you’re doing cloud-native applications? Kub-native, I know is a way that we like to talk about it. How do you approach this from a StackRox standpoint?

    Shah: Absolutely. And so the big trend that we saw when we started the company was that customers were, you know, shifting their monolithic applications built on traditional infrastructure to microservices and containers and as a result security also had to evolve to meet and secure this cloud-native infrastructure. And we saw an opportunity to build a new set of solutions that are purpose built for this cloud-native infrastructure, because when you really think about it there’s fundamental differences between traditional application and traditional security and cloud-native applications and cloud-native security, right? I mean you’re deploying containers; security then has to make sure that it understands the ephemeral and immutable nature of containers and security has to shift left and provide controls and guardrails for the build and deploy side of the application life cycle, not just at run time.

    And equally important, security now has to seamlessly integrate with DevOps processes, automation and workflow, because if you don’t then the DevOps organ is gonna reject—or sorry, the DevOps body is gonna reject the security organ.

    Ashley: [Laughs] I’m glad you talked about it in both ways because Kubernetes, containers, that obviously changed the architecture of software and how we’re doing that in the cloud. You know, it isn’t just about locking down servers anymore. It’s really app security level, but at the same time we’re creating software differently. Can you say some more about what maybe some of the unique challenges are that you’ve had to address for both cloud-native world and also shift left within DevOps?

    Shah: Yeah, absolutely. I mean the one big trend, people talk a lot about microservices and containers, but the other big thing that I would like to call out is that Kubernetes has emerged as the de facto standard for orchestrators, right? We did a survey late last year and again six months later and what we found is the adoption of Kubernetes as the orchestrator has grown from 57 percent of organizations using it to now, you know, over 86 percent of organizations using Kubernetes, right?

    Ashley: Wow.

    Shah: And for the right reasons, because it is really, really hard to scale, manage, and deploy containers in large environments, and Kubernetes was purpose built to help you do that. It was an opensource system developed by Google, and Google today uses Kubernetes or a version of Kubernetes, the internal version, to manage over 4 billion deployments at 4 billion containers at scale. So the first thing here is that you have to appreciate the importance of Kubernetes and you have to make sure that security is focused on not just the container but also at the orchestrator and specifically Kubernetes, right?

    Ashley: Sure.

    Shah: And that itself brings a whole new set of challenges because Kubernetes is a large system with significant operational complexity, right? And they just went through a security audit and the assessment team found that the configuration and deployment of Kubernetes is nontrivial, and I can get into the details as to what those challenges are, but the starting point is to make sure that you’re not just focusing on security at the container layer but also focusing at the Kubernetes layer.

    Ashley: Well, isn’t that the truth. We find so often even outside of the container world it’s oftentimes configuration issues, not just the software itself. And as you mentioned, Kubernetes, well as great as it is, it is very complex to set up and operate. It’s not a simple task. Maybe it is as a developer to get an environment running but not in a multi-cluster distributed environment in the cloud, et cetera, high bred, all that kind of thing.

    Shah: They highlighted, you know, the three reasons why it is nontrivial. The first reason was that there are certain missing operational controls, right? So you obviously have to make sure that you understand what those are and put guardrails in place for those controls. The second is that there are a lot of components that have ability to put controls in place but the default settings are confusing, and the big takeaway for me is that we need to distinguish between security controls being available by default and that doesn’t mean that they are configured securely by default, right? So the misconfiguration is therefore the number one concern that users have and it was expressed by two-thirds of the audience in the StackRox State of Container Security Report that two-thirds of the respondents were concerned about misconfigurations.

    Ashley: I believe you even have that report or some information about that on your website. I remember downloading some of that. It has some great information in it. Talk to us about then how do you approach that from a StackRox product standpoint? What parts of those issues does StackRox come in and really help you solve?

    Shah: Yeah. So, you know, what we have taken is really a holistic approach to container and Kubernetes security and we have focused on making sure that our approach is both container-native and Kubernetes-native. So what does that mean? It means two distinct things. First is making sure that we capture all the rich configuration data that is in Kubernetes and use that to address and improve the efficiency of all the use cases that we address in the product. So let’s take vulnerability management as a very simple use case, right? You can go scan images and say here are a list of all the images with a vulnerability score of seven or higher.

    Now imagine you have hundreds of images with vulnerabilities and you give them to developers. What are they gonna do? And I say, well, they’re gonna throw their hands up in the air and say, “Well, I can’t get to all of them,” and that’s where we had the Equifax problem. But by deeply integrating with Kubernetes and being Kubernetes-native, what StackRox does is takes the additional step of saying, “Hey, you know, it’s great that we have these images with vulnerabilities, that’s a good, important first step, but let’s take the second and third and fourth step to understand are those images even deployed anywhere in your production environment?”

    Ashley: Exactly.

    Shah: Right? And if they’re employed in production environment, what data is it accessing, what secret is it accessing, what’s the network configuration, is it publicly accessible, what behavior are we seeing at runtime? And by taking all this rich context we can t hen give you a prioritized list of risks in your environment so you can focus on the most important risks first as opposed to getting a laundry list of issues. So that’s an important—you know, that’s how Kubernetes-native solutions can help you prioritize risk and that’s precisely what we do at StackRox.

    Ashley: I was just going to say, I think this is an extremely valuable aspect of your product because so many security teams—and I’ve talked to even, you know, major online tech companies that say, “I don’t need more information; I need problems solved, right? Tell me what are the biggest, most important things to go after,” and I think that’s a huge part of what StackRox does.

    Shah: Exactly. And, you know, alert fatigue, as I’m sure you’ve heard, is a very common problem in the security industry.

    Ashley: That’s the nice way to say it. [Laughs]

    Shah: Yeah. And by leverage the context, the rich context available in Kubernetes, you can actually make that information more actionable for your development teams and your security teams. So that’s one example. The other example of what it means to be Kubernetes-native is really to leverage the built-in controls available in Kubernetes for policy enforcement, right? And so let’s take network segmentation as another use case where you want to segment your networks between—inside—so that not every container can talk to every container, and there are two approaches. You know, Kubernetes has something called Network Policies and you can leverage those, and it’s much more scalable and robust and it seamlessly deploys within your infrastructure, right?

    The other approach would be to go deploy a proprietary firewall, which is fraught with scale challenges and creates issues if it fails, right? And so a customer again says, “Hey look, when I’m talking about being Kubernetes-native I want to leverage Kubernetes for what it’s designed to do, leverage the native capabilities, because it’s much more scalable and robust, and I want to make sure that my controls are all in Kubernetes, have a central place for policy enforcement as opposed to multiple proprietary tools doing policy enforcement,” which is not the approach and not what Kubernetes recommends and that’s precisely why they have those built-in controls. And so that’s again another example of what—you know, the advantages of being Kubernetes-native and it allows for native enforcement of your policies.

    Ashley: Well, I think that’s another place where, you know, the DevOps intersects with other parts of the organization, DevSecOps, et cetera. You know, a security team might be used to locking down a server or at a massive application level, and as you’ve mentioned sort of outside of the Kubernetes environment locking something down at the firewall, that doesn’t deal with really what’s happening amongst all the clusters, all the containers, microservices. So you’ve really highlighted an important aspect of security, that once security teams get engaged and find out what’s possible now they can, you know, do that through StackRox. That’s gotta be a huge advantage.

    Shah: Yeah, and precisely the reason why we took this approach, because when we go talk to customers what we find is that there are security teams that care about the controls that we are talking about here and then there are platform and infrastructure teams that are responsible for the operationalization of these tools, right? They are responsible for SLAs. The SREs are the ones that have to operate these container and Kubernetes-native security solutions and, you know, they just prefer solutions that are more native to the infrastructure versus deploying proprietary third party tools. And so having a Kub-native approach also helps align security and DevOps teams, and what we are seeing now is as a result that this emergence of DevSecOps, which is all about bringing the two together and really being responsible for the security of your application and your cloud-native infrastructure.

    Ashley: I’m curious. Who is it usually that’s reaching out to you or showing interest in StackRox? Is it the developers, DevOps folks, is it security folks kind of figuring out how to talk to the dev teams? What do you see happening in the market?

    Shah: Yeah, and a great question. We typically see security teams or security architects or application architects reach out because they know they have to address it, and so that’s where the initial conversation starts. What we find is that when they involve the DevOps teams, because they have to get involved to do a proof of concept or even to deploy an operationalized solution, the DevOps teams actually much prefer a container and Kubernetes-native approach as opposed to a proprietary third party security tool because they often refer to proprietary tools as a root kit that they do not want to install in their infrastructure, right? And so it is—you have to speak to both audiences.

    You have to make sure that you cover all the use cases that security teams care about and you also have to make sure that from a day-to-day operationalization of the product it aligns with your DevOps teams, their processes, their workflows.

    Ashley: I have to believe that’s gotta be a big plus to the security team. It’s not another security tool that they bolt on to the network. It’s something that’s built into Kubernetes and managed through Kubernetes and StackRox. It’s also native to the application infrastructure versus something they have to integrate in or yet another tool to watch. It just seems to be much simpler, although it’s a complex topic, but simpler thing to implement as well as manage.

    Shah: Absolutely. I mean you said it spot on. This is security that’s built in versus security that’s bolted on, and if you think about where the security industry is headed it’s all about security as code, right? Where you built it into your applications. People talk about infrastructure as code, which is what we’ve been doing for the past five years, and now we are moving to this security as code where it presents us with a unique opportunity to address security from the very beginning and forever change the security equation in our favor.

    Ashley: I’m curious. When we talk about shift left for security, I think bundled inside that, really what’s also shifting left, is auditing and compliance. Are there things about a Kub-native environment that help us with that as well, the auditing and compliance aspects of security?

    Shah: Yeah. Absolutely. When we think about compliance and, you know, shift left you want to make sure that your Center for Internet Security benchmarks cover both your containers as well as your orchestrator in Kubernetes. If you’re doing any kind of PCI or HIPAA or NIST 800-190 compliance controls you want to make sure that you extend them not just to your containers but also to your orchestrator in Kubernetes specifically. The whole shift left movement is that if I can catch an issue early on and prevent it from being deployed in my environment that is 100 times more effective than deploying it in my environment and then catching it when something goes wrong, right? So the sooner—it’s more preventative as opposed to, hey, we’re gonna detect it—let anything run in the environment; we’ll detect everything bad that happens.

    And, you know, and as we know that’s not effective. You have to have preventative solutions, you have to have guardrails in place that harden your environment so you have fewer chances of things going wrong. And that said, you also need capabilities at runtime, so despite your best efforts, when things do go wrong, you can still catch them and prevent any damage from happening.

    Ashley: Well, that’s the whole observability tracing into microservice, et cetera, understanding what’s happening in the environment. You have to know what the environment is in the first place as well as tie it back to that data.

    Shah: Exactly. And I think what we’re going to see is logs and metrics and tracing forming observability as you point out; and similarly, you know, security is just the other side of the coin, right? So observability and security go hand in hand. What we are doing is leveraging all of that rich information that is available at the node level, at the cluster level, and leveraging that to protect your applications across the entire lifecycle.

    Ashley: Excellent. Well, we’re coming up on the end of our time here. One last thought. Is there a certain best practice or something that you’ve observed as you work with customers when they begin engaging with StackRox and see your technology and what it can do for them? What is the thing that they walk away saying, “Wow, this has really helped me and I’ve solved the following problem or knowing the following has saved me a lot from avoiding some problems”?

    Shah: Yeah. So there are a lot of, you know, great resources available on our website at www.StackRox.com, and we talk a lot on misconfigurations and we’ve highlighted some best practices. For example, making sure that you use a read-only root file system, right? Because that’s a very powerful mitigation against attempts to gain foothold in your infrastructure and the adversary’s job becomes that much more difficult. Or minimize the image contents, because a lot of file systems often contain bash or package managers which further enable an attacker to do bad things, and so remove all nonessential binaries or pay attention to your Kubernetes RBAC configuration.

    Why? Because Kubernetes API is a critical attack surface. It controls what happens in your cluster and it controls what security configurations are in your cluster, and so if you minimize who has access to that Kubernetes API it prevents—it again hardens your environment, and also upgraded to the latest version because Kubernetes, the community, is constantly adding more and more security controls, they’re constantly addressing vulnerabilities that are discovered, and so running on the latest version of Kubernetes is also an important step that you can take to secure your Kubernetes environment. So there are lots of other, you know, best practices that I would call low-hanging fruit that we’ve called out on some blogs that we’ve written about, and that’s irrespective of whether or not you’re using StackRox, right? These are just some good best practices as you embark on your journey to containers and Kubernetes.

    Ashley: You do have an excellent blog and I would certainly recommend that to our listeners. Well, it’s been great talking with you. Kamal, thanks for being on the podcast.

    Shah: Mitch, thank you so much for having me.

    Ashley: It’s definitely been my pleasure. So I’d like to thank Kamal Shah, CEO of StackRox, for joining us today. You, of course, have listened to another DevOps Chat podcast and I’d like to, of course, thank our listeners for joining us today as well. This is Mitch Ashley with devopsy.kinsta.cloud. Thank you for joining us. Be careful out there.

    — Mitchell Ashley

  • The New Era of Kubernetes, With StackRox

    The New Era of Kubernetes, With StackRox

    Orchestrators are becoming the operating systems of cloud for the future. Which one do you think has become the dominant one? Ali Golshan, co-founder and CTO of StackRox, placed his bet on Kubernetes right from the start.

    StackRox is a Kubernetes-native security platform that helps DevOps and security teams operationalize security, providing richer context, native enforcement and continuous hardening.

    During this interview with MediaOps founder and editor in chief Alan Shimel, Ali discusses the adoption of Kubernetes and its prevalence today. More companies are realizing they can’t use traditional security. The tooling has to be native to the infrastructure they’re using, it must integrate into the build and the deployment. And Kubernetes is the best solution available, he said.

    Check out the interview below to learn more about microservices, containers and Kubernetes.

    — Veronica Haggar

  • ASF Moves OpenWhisk Serverless Computing Forward

    ASF Moves OpenWhisk Serverless Computing Forward

    The Apache Software Foundation (ASF) announced today that the OpenWhisk serverless computing framework has now become a high-level open source project.

    Matt Rutkowski, CTO for serverless technologies and advocacy for IBM, said with this announcement, organizations looking to implement an open source serverless computing framework on-premises or in a public cloud now can have confidence the OpenWhisk project is sustainable beyond the handful of vendors, including IBM, that launched it.

    IT organizations of all sizes are embracing serverless computing frameworks as a way to invoke application programming interfaces (APIs) to make additional compute resources available on-demand based on an event. For example, rather than having to embed a lot of additional analytics code within their application, developers alternatively might invoke a serverless computing framework such as OpenWhisk to run analytics whenever necessary.

    The most widely used serverless computing framework today is the Lambda service from Amazon Web Services (AWS). However, rival cloud service providers have been embracing various open source alternatives to provide similar capabilities. At the same time, some internal IT operations teams are deploying serverless computing frameworks to provide similar capabilities within an internal IT environment.

    Regardless of the approach, Rutkowski said hooks to serverless computing frameworks soon will become ubiquitous hooks within continuous integration/continuous deployment environments. In fact, DevOps environments are likely to expose multiple hooks to different serverless computing frameworks as cloud computing becomes more hybrid, he noted. Plugging in multiple serverless computing frameworks should be relatively trivial because the difference in application programming interface (API) parameters between different serverless computing frameworks is minimal, he added.

    While interest in serverless computing has been running high, deciding which open source serverless computing framework to embrace has been something of a challenge. There are at least a half-dozen active serverless computing frameworks, with new ones being added regularly while other projects fade away. The Cloud Native Computing Foundation (CNCF) has made a point of not endorsing any one serverless computing framework in the expectation that many will be adopted for various use cases. Instead, the CNCF has thrown its weight behind a Knative project that provides the middleware required to integrate Kubernetes clusters with multiple serverless computing frameworks.

    Those serverless computing frameworks have already had a profound impact on containerized applications. The first generation of containerized applications was largely stateless. Now stateless functions increasingly are being processed via a serverless computing framework, while stateful applications based on containers that tend to run longer are just now starting to be deployed in production environments.

    Of course, the one fact many IT organizations fail to appreciate is that serverless computing frameworks are built using containers. A serverless computing framework is really a higher-level abstraction of a container platform. The challenge organizations will face now is teaching developers when to rely on a more traditional container platform versus invoking a serverless computing framework to run a child process, for example.

    Whatever path those developers choose, the one thing that is for certain is existing DevOps processes will need to be adjusted accordingly.

    — Mike Vizard

  • WSO2 Advances Microservices Gateway

    WSO2 Advances Microservices Gateway

    At the Open Source and Software Development Conference (OSCON), WSO2 this week announced it has updated an open source microservices gateway to make it possible to expose multiple microservices through a single application programming interface (API).

    Additionally, version 3.0 of the WSO2 API Microgateway now includes the ability to automatically discover microservices and transform legacy API requests into a more modern format. WSO2 also added support for the OpenAPI Specification (OAS), formerly known as Swagger, to make it easier for developers to collaborate on creating APIs, and has separated the WSO2 API Microgateway toolkit from the runtime to enable greater scalability and smoother upgrades.

    Ken Oestreich, vice president of product marketing for WSO2, said the WSO2 API Microgateway is designed to accelerate the convergence of application development and integration into a single team. As part of that effort, WSO2 has been advocating the adoption of Ballerina, a general-purpose programming language designed from the ground up to make it easier for developers to integrate distributed applications on their own. For example, Ballerina makes it possible for developers to create and embed their own micro-enterprise service bus (ESB) within a distributed application, he said.

    Those integration engines then could be deployed and updated within any DevOps processes layered on top of a continuous integration/continuous deployment (CI/CD), Oestreich added.

    A WSO2 API Microgateway is designed to boot up in less than a second and provides authentication, authorization, rate limiting, service composition, discovery, transformation and analytics capabilities. It is designed to be integrated with the WSO2 API Manager, an open source API management platform that can run on-premises or in the cloud.

    As the number of microservices being created within organizations increases thanks to the rise of containers, Oestreich noted there is now a critical need for organizations to find a lightweight approach to building and managing all the APIs required to connect thousands of microservices. WSO2 provides a flow diagram through which organizations can visually manage that process, said Oestreich. As part of its support for containers, the WS02 API Gateway provides built-in support for container orchestration tools such as Kubernetes, which makes it possible to generate artifacts that can be applied directly to Kubernetes clusters.

    Organizations of all sizes are clearly struggling these days with API management. In theory, APIs should remain stable as the software components they connect to are updated. The trouble is, each new microservice generates its own set of APIs, and before too long, organizations find themselves trying to manage thousands of APIs that are all dependent on each other. The removal of any one API might not crash an application, but it could adversely impact performance as API calls are re-routed around the application.

    It’s not all clear these days who inside most organizations is responsible for managing APIs. Developers certainly create the APIs. However, once they are deployed in a production environment, their care and feeding often pass over to an IT operations team. Regardless of whom, however, once any of those APIs break it’s not long before the entire DevOps team knows about it. The challenge now is figuring out how to make the management of all those APIs as natural an extension of a DevOps process as possible.

    — Mike Vizard

  • Growing Pains for Containers, Data Centers Call for Better Management

    Growing Pains for Containers, Data Centers Call for Better Management

    Containers have taken the tech community by storm with their ability to drive agile and effective innovation. Compared to the rigid nature of virtual machines, it’s no wonder developers and IT teams have flocked to containers and their flexibility. By dropping the strict hardware focus of virtual machines, containers are allowing teams to surface innovation into operating systems and create an elegant solution for moving code.

    As we continue to see the adoption of container-driven operations grow, the industry’s excitement for innovation is overshadowing a problem growing at the same scale: over-containerization. Whereas virtual machines traditionally provide a predictable understanding of hardware performance, containers are not in touch with the hardware native to their operating system. As a result, containers are often left to fight for control over one system. In these instances, data centers are inefficiently distributing energy as they experience drastic power pulls that drain energy and dollars.

    While this might sound like another bout of industry growing pains, without a proper reaction, this can cost companies millions of dollars lost to inefficiency. Just as teams are investing in the latest orchestration features to manage their virtual environments, it’s time to consider technology’s hardware roots and monitor containers’ effect on data center functionality. Data center management tools provide a simple solution to this problem by monitoring power usage, gauging utilization across data centers and presenting data needed to make a winning strategy.

    Monitoring Power

    Data center management tools provide granular insight into power consumption, with options to monitor per server, rack, workload and application. Given the hyperfocused, often greedy nature of containers, power monitoring allows data center managers to identify how much energy containers need and how to best allocate it across multiple containers. This gives managers the information they need to create a centralized management policy for server energy consumption and avoid power pulls from hungry containers in the future.

    Gauging Utilization

    While the industry’s initial concern is containers’ tendency to pull power away from the majority of an environment, there is an opportunity within this dynamic. Data center management tools offer visibility into uptime and cross-platform consumption levels, which presents a chance to identify underutilized servers that could support more containers. Given that containers are far easier to migrate than virtual machines, server migration is likely to occur more often and data center managers will need to provide a recommendation quickly. With enough insight into the long-term, low utilization trends, teams will be able to consolidate and balance workloads across existing devices.

    Adjusting the Data Center Strategy

    Data center management solutions solve an immediate power problem, but what are they doing to keep up with the ever-evolving enterprise space?

    Some data center management tools offer features that visualize power consumption and predictive modeling for efficient planning. With these insights, not only will IT teams be able to give power to containers across their environment, but they also will be able to save resources and lower operational costs for years to come. This presents a win-win situation for developers and managers, in which containers are given the energy to power innovation and data centers are operating at maximum efficiency.

    As we look to the future of containers and data center management, it’s in the best interest of enterprise companies to invest in their hardware just as they have invested in containers. As the industry continues to become focused on virtualization, a solid, foundational understanding of data center performance and capacity will be key to long-term success.

    — George Clement

  • Kubernetes Adoption: Are You Ready?

    Kubernetes Adoption: Are You Ready?

    Enterprises are rapidly embracing a cloud-first strategy and microservices play a pivotal role in this journey. But enterprises are achieving various levels of success, measured by many factors includingmaturity of DevOps in the enterprise, ability to identify the right candidates for microservices, selecting the appropriate container management platform, adequate tooling and, finally, cultural shift in design thinking.

    As there is plenty of material around microservices adoption and strategy, this article focuses on the container management ecosystem, which plays a critical role in the success of microservices adoption. Today, Kubernetes has become the de facto platform for container orchestration. Most public cloud providers offer Kubernetes as a service in some form to abstract the complexities of managing Kubernetes as a platform.

    Currently, we see three broad patterns of how enterprises are adopting Kubernetes within their organizations.

    Pattern 1: Kubernetes as a Managed Service

    While Kubernetes makes container management somewhat simple, it is still a complex beast to understand and manage as a platform. Enterprises that have already embarked on a cloud strategy find it easy to test the unchartered waters of Kubernetes by leveraging Kubernetes-as-a-service provided by their cloud providers. It enables them to understand the impact of Kubernetes on their respective application architecture strategy and identify the gaps in their systems (such as the maturity of DevOps management, security management and release management) as well as their monitoring capabilities.

    Pattern 2: Kubernetes as a Turnkey Solution

    Certain enterprises driven by industry regulations and are technology-focused (with considerable experience in other container technology solutions), have shown interest in setting up Kubernetes as part of a private cloud or on–premises with a view to avoid vendor lock-in and limited control associated with managed Kubernetes. There are many such turnkey solutions out there to choose from.

    Pattern 3: Self-hosted Kubernetes Platform

    This category is small compared to the other two categories. However, there are a few enterprises that fully embrace the open source software development model and contribute to Kubernetes community. There are tools and frameworks that can enable the enterprises to setup and manage Kubernetes on their own.

    There are advantages and constraints in adopting any of the above approaches. The decision regarding which strategy to choose depends on the maturity of the enterprise and their business strategy.

    Challenges in Adoption

    Some of the key challenges to be considered, irrespective of the adoption pattern selected, include:

    1. Namespace management: Namespaces play a key role in managing the isolation across application domains and environments, providing controlled management of resources and user management. Bounded contexts can be linked with namespace definitions and standards. It is important to define proper naming guidelines to drive namespace management across clusters.
    2. Resource management: It is necessary to define resource utilization (resource quota) guidelines to ensure the containerized applications co-exist without being eliminated due to resource violations at runtime.
    3. Policy management: It is critical to define appropriate policies including cluster access controls, service access controls, resource utilization controls and secret access controls.
    4. Audit and compliance: It is important to audit the platform for patch levels, secret stores, compliance against the security vulnerabilities, encryption of secret stores, storage volumes, cluster policies, role binding policies and user management controls.
    5. Chaos testing your platform: It is necessary to subject the platform to chaos testing to ensure the robustness of the cluster. It also helps to test the stability of the containerized applications and the impact of crashing these containers. It will also provide vital information about how the platform behaves during high loads or when resources are unavailable for the platform.
    6. Managing the deployment manifests: Kubernetes follows declaration-based management, which means that every object or resource instruction is described through declarative manifests. This leads to versioning complexities, prone to human errors and data corruptions. It is necessary to leverage tools or create custom utilities to manage these manifests.
    7. Observability of the platform: While Kubernetes provides various mechanisms to monitor its own internal components, it does not recommend a standard monitoring approach. It is necessary to introduce well-defined health management standards while designing the microservices. Include appropriate probes for liveness and readiness probes in every containerized application deployed on Kubernetes cluster. Integrate the probe-generated metrics and platform-generated metrics with an external monitoring platform to have comprehensive observability of the cluster.
    8. Continuous deployment of services: It is not recommended to use kubectl-based deployments in a large-scale production setup. Instead, use some of the established open source frameworks specifically built for Kubernetes (such as Helm or JenkinsX) to manage seamless deployments.
    9. Archiving and backup: Kubernetes uses etcd as its internal metadata management store to manage the objects across clusters. It is necessary to define a backup strategy for etcd and any other dependent persistent stores used within the Kubernetes clusters.
    10. Container security management: Kubernetes deploys the applications by downloading the respective images from a pre-defined image repository. It is the responsibility of the repository ecosystem to ensure the image provenance of the images being deployed. Continuous security must be included as part of DevOps pipeline to ensure containers are well-managed.
    11. Service mesh support: Service mesh plays a critical role in streamlining the service to service communication. It abstracts the service level access controls and security management between services through externalized policies. It also provides routing and load balancing features. It is necessary to choose an appropriate service mesh that is compatible with the Kubernetes cluster as well as the underlying infrastructure.

    Conclusion

    Kubernetes makes the container operational aspects simpler, but it requires a methodical approach and best practices to ensure smooth maintainability, as well as seamless developer interaction. For any enterprise which are in a transition journey toward adopting Kubernetes, it is imperative to have a strategy for Kubernetes adoption to ensure success.

    — Sreekanth Nyamars

  • Pivotal Software Previews Automation Framework

    Pivotal Software Previews Automation Framework

    At the North America Cloud Foundry Summit 2019 conference, Pivotal Software announced it is beta testing an automation framework that promises to keep its distribution of the platform-as-a-service (PaaS) environment continuously updated.

    In addition, Pivotal revealed it will be adding support for open source technologies including Envoy load balancing and Istio service mesh software developed outside the auspices of the Cloud Foundry Foundation (CFF) to its Pivotal Cloud Foundry (PCF) distribution. Envoy and Istio are being employed to add a new routing tier to tier to PCF to give developers more control over network traffic.

    Richard Seroter, vice president of product for Pivotal, said Platform Automation for PCF consists of a series of building block modules that will be applied to all the components of PCF as well as eventually the distribution of Kubernetes that Pivotal curates in collaboration with sister company VMware.

    Pivotal also announced that Pivotal Application Service (PAS), the runtime for PCF, will soon support Windows Server 2019 along with the ability to configure multiple custom ports per PAS container to make deploying containerized applications in a PaaS environment more efficient from a networking perspective.

    Finally, Pivotal is adding more descriptive metadata to the application programming interfaces (API) it exposes across the PAS runtime.

    Seroter said Pivotal continues to focus on automating as much of the IT operations pipeline as possible. Rather than allocating IT staff to create and manage these pipelines, Pivotal is making a case for relying on a set of managed services that span instances of Cloud Foundry and Kubernetes running on top of virtual machines deployed on either a public cloud or on-premises. That approach relies on a highly opinionated operational pipeline defined by Pivotal that IT organizations will need to adopt to benefit from a highly consistent and repeatable approach to managing IT operations at scale, he said.

    The need for a more structured approach to managing IT operations is only becoming more acute as organizations embrace Kubernetes platforms alongside Kubernetes, Seroter added. In fact, a survey of 501 IT leaders published by the CFF finds almost half of respondents (48%) report using some combination of PaaS, containers and serverless technologies together.

    It’s still unclear how much IT organizations will standardize on a particular application development platform. PaaS environments typically have a more robust set of application development tools, but they can consume tens of virtual machines to stand up. Development tools for Kubernetes platforms are still evolving, but the platform provides a more efficient way to consume both virtual machines and bare-metal servers. It is apparent that for some time to come that many IT organizations will find themselves managing multiple platforms. The challenge that creates for DevOps teams is finding a way to manage those platforms consistently using a common framework rather than having to deploy and master separate management. It may take quite a while for IT leaders to rationalize their management platforms, but with each passing day it becomes clearer that goal increasingly is within reach.

    — Mike Vizard

  • F5 Networks Acquires NGINX to Meld NetOps with DevOps

    F5 Networks Acquires NGINX to Meld NetOps with DevOps

    As part of an effort to better align DevOps and network operations (NetOps), F5 Networks plans to acquire NGINX, a provider of widely employed open source loading balancing software.

    The two companies revealed in a call with financial analysts that the primary goal of the $760 million deal is to meld the two companies’ combined expertise to develop application delivery controllers (ADCs) that are optimized for modern applications based on microservices.

    F5 Networks CEO François Locoh-Donou said F5 Network plans to continue operating NGINX as an independent brand in addition to maintaining support for the NGINX open source community. NGINX CEO Gus Robertson will become general manager of the NGINX business unit. NGINX founders Igor Sysoev and Maxim Konovalov also plan to stay on.

    Locoh-Donou also disclosed that while NGINX software is employed today at more than 375 million sites, the company only generated $26 million in revenue in 2018, mostly by providing commercial support to enterprise customers. F5 Networks will move to combine investments both companies have been making in containers to deliver a next-generation ADC optimized for microservices-based applications spanning multi-cloud computing environments, he said.

    As part of that strategy, however, both companies will need to come to terms with Envoy, an open source load balancing project led by the Cloud Native Computing Foundation (CNCF). Envoy is already providing the foundation for multiple service mesh projects that make load balancing a feature of a higher-level mechanism for managing services running on a Kubernetes cluster. Obviously, F5 Networks hopes to fulfill an opportunity to manage multiple instances of service meshes running on multiple Kubernetes clusters that.

    In fact, Locoh-Donou cited industry research that forecasts by 2022 there will be more than 198 million workloads running on some form of a microservices-based architecture. In contrast, 44 million workloads are expected to be running on legacy platforms.

    Locoh-Donou said F5 Networks also expects to leverage NGINX to expand its presence in application programming interface (API) management and associated web application services, which he noted collectively represent multibillion-dollar market opportunities.

    The decision to acquire NGINX reflects the inevitable melding of NetOps and DevOps, he added, noting that inconsistent approaches to managing application service across emerging microservices-based environments are a recipe for creating unstable IT environments.

    While it’s still a little too early to determine to what degree NetOps will be subsumed into DevOps processes, Locoh-Donou said F5 Networks plans to advance adoption of NGINX software by educating its core base of NetOps administrators on how microservices applications are deployed across extended networks and the rigors of the DevOps processes required to manage them.

    Both F5 Network and NGINX made a name for themselves by interconnecting IT environments made up largely of virtual machines. While virtual machines are not going away anytime soon, so-called cloud-native applications built using containers running on Kubernetes clusters require a different approach to delivering infrastructure services. The challenge facing the combined company is finding a way to deliver those services in a way DevOps teams want to consume.

    — Mike Vizard

  • DevOps Chat: Container Security and Aqua 3.5 with Rani Osnat and Andy Feit

    DevOps Chat: Container Security and Aqua 3.5 with Rani Osnat and Andy Feit

    In just a little more than three years Aqua Security has set its mark in the container security space. With its major new release of Aqua 3.5, the company has again raised the bar with serverless and container encryption upgrades and feature sets.

    I sat down with the Aqua Enforcer himself, Rani Osnat, and “Boston” Andy Feit to discuss the details of this major release. Rani and Andy give us an inside peek.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s chat is a little bit about cybersecurity, container security, Kubernetes and a major new release coming out of our friends at Aqua, Aqua Security. I’m happy to be joined with the dynamic duo of marketing at Aqua, Andy Feit and Rani Osnat. Andy, Rani, welcome.

    Rani Osnat: Hi Alan, thank you.

    Andy Feit: Hi Alan, good to talk to you.

    Shimel: And just so people know, Andy, you’re joining us from Boston today. And Rani, you’re out in Israel. Is that correct?

    Feit: Yes. Yes. Today I am in _____ _____ [Crosstalk].

    Osnat: Right.

    Shimel: Modern technology. We have a worldwide panel. But guys, the big news is, Aqua just announced version 3.5 of their platform suite of tools. And you know, Aqua’s not a company that every single new time there’s a new release, and the DevOps mantra, you can’t get too excited about any one release. Right? Because there’s always a next one and a next one and a next one. But this is one to get excited about, huh?

    Feit: Absolutely.

    Osnat: We certainly think so.

    Shimel: So why should we be excited?

    Feit: Rani, you want to take that one?

    Osnat: Yeah, I’ll take this one. So, with every release we make, especially, and in the beginning of course everything’s new. But we’ve been in this space now for three years. Which is not a long time, but in this space it’s a very long time. And so now we’re at the point where we have a lot of large enterprise customers using our product. And we have a market that’s looking for innovation.

    And with every new release we try to balance these factors of, you know, offering something new that the market wants. But at the same time ensuring that our enterprise customers can make use of our platform, as they themselves grow their cloud native container implementations. So there is a maturity factor here as well as an innovation factor.

    And so on the innovation side, we’re introducing a few significant innovations. First and foremost, risk assessments for serverless functions. Which is a, you know, a kind of a sideways expansion for us into the serverless technology space, in addition to containers. Thinking that you know, what we see as, it’s basically the same teams and the same benefits that are gotten from containers people expect to get from serverless, it’s just another means to get the same end.

    And so we want to provide our customers with all the controls they need to address any challenges they have around securing those technologies. And it doesn’t matter if they use containers or serverless or both, or any sort of mixed environment. We also added something that’s innovative in the space, which is container encryption, and we can talk about that.

    And then on the side of enterprise scalability and ease of use, we’ve added quite a significant I would say rearchitecting of how we manage both administrative controls on our platforms and what users can do in terms of access. As well as the policy engine to make it a lot more scalable for multicloud, multiteam, multiapplication use.

    Shimel: Got it. Got it. Andy, did Rani leave anything out you want to add?

    Feit: No, I mean, those are the big pieces that are in the release. As he said. I mean, it’s very much being driven by our customer base and where they’re headed. And you know, in some aspects, it’s the technology elements. Like adding serverless. And in other aspects, it’s really about living with the solution. You know, as our customers, we now have customers that are we think the largest container deployments in the enterprise.

    We have some very large users and span of different industries. As they look to roll out, they’re finding they have multiple teams working on these projects. And they need to implement different levels of security. And in many cases, they’re implementing that on different technology stacks. And some are using containers, some are using serverless environments.

    And they may be using even different underlying providers of some of the infrastructure. Whether that’s tools for development or the cloud provider itself. And so we’re really, we’re becoming very heterogeneous in terms of what we need to support. And for our customers who, on the security side, are trying to look at that whole context and manage that whole context and have consistent policies, all our consistent reporting across all of them, and not be monitoring 17 different dashboards. It’s important that it be easy to do, to be able to see that whole network of activity. And that’s really what a lot of this release is about.

    Shimel: So guys, one of the things that you mentioned, both of you actually mentioned, was the serverless piece. And this is something that we are, we’re hearing a lot about from our readers and from people we speak to. You know, how quickly, and we live in crazy times, right? So the whole container revolution, if you backed up on hypervisors. And now, how quickly serverless is you know, gaining a foothold and people are building around that type of infrastructure.

    Osnat: Right.

    Shimel: Let’s, just baseline, what are some of the security challenges that you guys are seeing around this?

    Osnat: Right. So I’ll preamble that, you know, just add one more thing. There’s, you know serverless has been around almost as long as containers have, in terms of the, you know, its current incarnation of the use in the cloud. But, the use cases is quite different. And while it is gaining traction, the use cases are much more limited than containers. There’s a whole kind of religious war, you know, between the proponents of containers and the proponents of serverless. Personally I don’t believe it’s a zero sum game. I think that both are going to end up being used, and both are going to end up being used in hybrid architectures.

    Shimel: Yeah, I don’t think it’s either or.

    Osnat: Yeah, I know, but some people would like you to think it is. I don’t think it is. I think it’s both. And so we, but there are some fundamental differences between containers and serverless when it comes to security. First of all, most of the serverless workloads that happen today are cloud based and specific to a cloud provider, right? Mostly Amazon, because Amazon is the larger cloud provider in general, as well as in serverless specifically with Lambda.

    But basically you run those functions and it’s quite cloud specific. That’s one area of difference. The other is of course that you know, these are very small single-function entities that can run for a fraction of a second. So when we talk about run time security for serverless, for example, there is a lot less to do there than you have with containers.

    Containers are, there are applications that can run, they could run for a minute but they often run for a lot longer than that. With something that runs for a split of a second, there is really only so much you can do when it’s already running. So a lot of the stuff you need to do is before it ever runs. You want to make sure that what you’re running is actually something that is secure, that passed your policy, and that you know about, right?

    So when you look at the challenges, one of those is actually discovery. What functions do you have in your inventory, and what are you using them for? The second is ensuring that what’s in them is secure and not vulnerable, configured properly. And that also includes permissions. So, when you define for example a Lambda function to run on AWS, there is a set of permissions you can give it.

    And depending on how you configure it, this can be very liberal or not. And of course you want it to be less, the least liberal you can. So as not to allow it to do anything outside the scope of what it’s supposed to be doing. So right now we’re primarily concerned, and that’s also where our customers are, with preventive controls. Basically ensuring that you are, that when you run something you actually know what it is. You know that you’ve approved it. And you can run it safely. That’s the first step in what we think is the right approach to securing serverless functions.

    Shimel: Fair enough, fair enough. And back to what you said kind of right at the get go with the either or thing. It was the same arguments about, would container replace hypervisor type of thing. And I think what we see is the majority of people want containers on hypervisor.

    Osnat: That’s true. It’s –

    Feit: Yeah, and I would also add that the data centers with lots of VMware and hyper-v haven’t gone away yet either. And they won’t. They probably will never entirely go away. New development today is cloud native development. Most of your mobile customer facing development.

    It makes sense to do that in the cloud and as long as you’re doing new development, why not do it on the latest and greatest. But, and the flexibility that you get from doing something on containers or serverless or a hybrid approach of those, makes it a lot smoother, easier, scalable. You get all these wonderful benefits. But we don’t see people going in wholesale and saying, I must clean out this data center now. So I think that –

    Shimel: _____ [Crosstalk] throw out the baby with the bathwater. And people –

    Feit: Yeah.

    Osnat: Yeah. So I think that’s one thing that we did. The other, I think very interesting and innovative feature that we’re announcing is container encryption. And I want to explain the use case. So we work with, you know, we work with many organizations. For example, we work, some of our customers are ISVs, who create software for customers to use.

    And that software is proprietary IP that they’ve developed and invested in. And they often want to make sure for those reasons as well as for reasons of governance, to make sure only the latest stuff is being used, et cetera, that they have some control over where it’s running and who’s using it. And so one of the things we provide here is an ability to encrypt, you basically encrypt the container image when it’s built.

    And then in order to run it, you need to decrypt all its contents, so there’s basically a key that the customer will have, the end user will have. And that will decrypt the image as it’s running. And if you don’t have that key, the image will not run. So the container itself once it’s running is not encrypted. But up till that point, it’s encrypted and you have to decrypt it in order to run it. And then of course this prevents the sort of, someone reusing or forwarding your software and you can imagine various use cases except the ISV one where companies would want this sort of deep security control over their containers.

    Shimel: Sure. Sure. And I think it’s just the, you know it’s funny, Rani. I think you said right in the beginning that over the last three years, you know, the progress that Aqua has made, and the progress the whole industry has made in securing their containers. Like everything that’s come before it, right, with each new release, with each light bulb, _____ security we see like more polish being applied.

    So, to me this idea of container encryption is you know, maybe first we have to concentrate on just getting the containers to work in a somewhat secure manner. But now we can start thinking about next level, next, you know, how do we turn it up a notch? Things like container _____. What’s the word I’m thinking. Like the standard, the, you know, the container encryption becomes ubiquitous over time?

    Osnat: I don’t know if it will become ubiquitous. I mean, certainly today you have a lot of encryption happening with TLS and all the stuff, all the pipes that handle containers. But as for the code itself, you know, even in highly regulated environments, I don’t necessarily see everyone encrypting everything. But certainly there are some crown jewels that you will want to encrypt.

    And it’s especially those areas where you’re not talking about reusable components, right? A lot of the containers that our customers use are reusable based on open source components, that’s fine. You don’t need to encrypt your NGINX webserver container, right? That’s, it’s identical to the same, other NGINX containers people use. But if you have proprietary stuff, that’s where you want to, or something that’s especially sensitive, whether it’s for any kind of security, confidentiality reasons, or for IP reasons. That’s when you would want to use something like that.

    But what you said actually, you know, brought me to the other topic I wanted to talk about, which is how the use of these technologies has matured with some of the more leading or pioneering companies that we work with, which is why we’ve invested in these scalability, manageability features. So I want to kind of explain what it looks like in a customer environment.

    So when we started out, and we started out kind of together with the market, the companies we were talking to, even larger companies, would typically have one or two teams that actually use containers, right? And so, you were talking about isolated projects. And that’s one level of doing things. But as we move forward, you know, now we have customers that have hundreds of development teams working with containers. They make thousands of images on a daily basis, because it’s all in a CI pipeline.

    And it all gets, it all goes into this large blender where it’s being spit out at the end, through Kubernetes or mesosphere, basically through an orchestrator to a variety of delivery platforms, whether it’s OnPrem or cloud or a mix of both. And if you look at it from an enterprise perspective, what they want is a way for them to apply security policies but maintain segregation of duties. Maintain compartmentalization and multitendency models that they have. So what we’ve done is really change both our administrative access model as well as the policy engine to enable that.

    So basically, you’re talking about people who use the Aqua platform. They have one installation of the Aqua platform. But they can basically distinguish between what different teams can see and do, what different roles can see and do, and how those policies apply.

    I’ll give an example. Let’s say that you have an application that is PCI DSS related. Handling credit card transactions. And so it has to comply with certain criteria that are requirements of the PCI DSS standard. You want, and you’re, but at the basis you’re using some basic elements like, I don’t know, MongoDB or MySQL. That same MySQL image that you apply a policy to within the PCI contexts will have a different policy than in non-PCI contexts. So having contextual policy is important.

    So that’s one area. The other area is who’s got access to what. So of course the people who handle the PCI application, the developers, the DevOps team, will need to handle certain aspects of this. But they don’t necessarily need to control the policy. That’s expected to be done by the security and compliance team. And the same token, they don’t need to access, or other teams don’t need to access that PCI application.

    So we’re talking about a matrix that really separates who’s got access to what and what they can do with that access, according to the specific application or geographic location, or what cloud it’s on or what registry it uses. All of these parameters. So you know, we’ve done this and we have, now both of these models combine to basically give you this matrix that is, that has you know, dozens of parameters on each facet to basically determine who’s got access to what, and who can do, whether it’s view access or edit access or only access to the logs, for example, for auditors and so forth. And so, it’s really a step up in terms of enabling these large deployments to work in an enterprise environments.

    Shimel: Absolutely. Good stuff. Guys, I want to _____ two other topics or areas I want you to hit on. One specific to 3.5, one specific to the market. And we’re coming up on the end of our time. So you know, we hear about immutable infrastructure, and you know one of the advantages of a container environment.

    So how do you deploy, you know, now you’ve got a bunch of customers. They want to upgrade to Aqua 3.5. Talk a little bit about how do you actually upgrade or run out this upgrade deployment. Is it a question of throw out what you have and just stand up new? Because Aqua itself is containerized. Or is, what, give us a little insight, nuts and bolts if people want to upgrade. Do you know what I’m saying.

    Osnat: Yeah. So our upgrade process is you know, it is simpler because we use containers, right? So there’s nothing to install. You simply run the new container. We do have backward compatibility with our previous versions, so when there’s an upgrade path for anyone using older versions of Aqua to this version.

    We actually, we’re the last, we don’t, I mean, we release software more often than what some of our customers would like to follow, in terms of their upgrade schedule, right? And we don’t force them to do that. But in the last version, the last major release, 3.2, we actually had a lot of customers move to that. So we’re in good shape from that respect.

    And they can of course upgrade to 3.5 when it becomes available at the end of the month. So there’s really no, there’s nothing in particular they need to do except of course, we always, always recommend doing it in a test environment first. And then once you see everything works, you move that to production.

    Shimel: Excellent. Excellent. So let me add –

    Feit: There’s one more thing now I was going to jump in with, which is, we’re sort of talking about as our organizations of scale and especially if they have multiple teams that are working on different platforms and policies that need to be implemented. In some of these larger enterprises, it’s become very hard to really even see everything and know about it and track, you know, who’s running what and where, and who are these owners. And so one of the things that’s new in the product is a pretty slick interface.

    Probably that’s the prettiest part of our product right now. The dashboard’s always looked great. But you can now go in and do what we call workload explorer. And visually view all of your running workloads, whether they’re on Kubernetes or Docker or OpenShift, and you can see everything that’s running across a large distributed runtime environment. And drill down into them, and you can start doing things like highlighting those that are vulnerable or high-risk, and those that are PCI compliant can be coded to jump out, and you’ll see that much more easily.

    You can then do tabular mechanisms. Begin to filter. Show them only those running on this platform. Let’s say that there’s a vulnerability that’s exposed in a certain component. You can show me just those, and start drilling down and looking at them, seeing where are they running? Is this one on-prem? Is this one on the cloud? Which cloud provider is it running on?

    So you know, as companies have become multiteam, multicloud, multistack, it’s the matrix of what you’re looking at has become pretty complex. And as workload explorers, it’s a great way to just sort of move around in a large enterprise. See what you have and understand what you need to work on right now.

    Shimel: You know, and let’s not trivialize it. Let’s not belittle. I’m having a tough time with the word. Let’s not belittle it. You’re a hundred percent right, Andy. Today’s organizations are multi everything.

    Osnat: I agree.

    Shimel: _____ _____ distributed on so many different levels, that really, having a 360 degree view of, just of the lay of the land, where all this, how it all plays together. That in and of itself, someone could make a product out of. I mean, it’s crazy.

    Feit: It’s eye opening for customers. Just in the last, we’ve been working with this product for about a month or six weeks, with some of our early adopter customers. And some of our sales engineers have been implementing it in proof of concept environments. And when the customers see this map, and they, you start drilling down, they say wait a sec – where’s that running? Show me that one.

    They’re finding things that they didn’t realize they had because you can now visualize it and see it. You know, when it was coming in as yet another alert or a text field or you know, something coming in to your SIM system, that was one thing. You had to look at the logs and know the query to type. But when you see it visually and you jump in and start looking around, and says wait, what’s that?

    And people were, it was eye opening. Okay, I need to go talk to that person. Literally, people were discovering things they didn’t know they had in their environments. And that’s exactly how, in a big environment, this tool can be very helpful in organizing things and showing you what’s out there.

    Shimel: Absolutely, absolutely. Guys, that last question for you is not really 3.5 related but more mark related. You know, we seem to be undergoing a, well, it’s constant. But recently we’ve seen just more and more consolidation in the tech vector general within containers, around Kubernetes, you know, IBM’s Red Hat –

    Feit: Cloud, right?

    Shimel: IBM’s Red Hat acquisition, $34 billion. I mean, is the king of it. But we saw for instance, CA or Broadcom CA, whatever they call it now, spin on _____ for near a billion dollars. To Tom or Bravo. We saw, who, someone just bought, was it _____ just bought a –

    Osnat: Later insight, yep.

    Shimel: Container something.

    Osnat: Right.

    Shimel: I mean, at some point, consolidation to what Aqua’s been out here preaching for three plus years. How do you think that affects, I mean certainly now, 3.5, you’ve raised the bar again. Let everyone else try to catch up. But in this atmosphere, talk to us a little bit. What does that mean around Aqua? Or do you just keep doing your thing?

    Osnat: Yeah, that’s a good question, Alan. I mean really, I think you keep doing your thing. Because your thing is understanding where customers are headed and building solutions that address what they really need. We’ve tried to keep our eye on that ball. And we’ve been big pushers of the concept of supporting multiple platforms, from the early days.

    We were Docker first, but today we support all kinds of things including things, less broadly used technologies. But pivotal, and Microsoft containers. Supporting all the cloud. So you keep your eye on that ball with the goal of building a customer base that is satisfied and loves your product, is excited about working with you.

    And one of the things that’s important to us is our customers are going to continue to renew with us and retain. You know, we’ve only been around three years. But we look at, our largest customers are very happy and using us, and expanding their use of us. They’ve put us in a pilot two years ago, and now they’re in production and they’ve put us in production with five applications. And now they’re on 50 applications. So this is all good. We’re not very focused on hey, we must be acquired by some time or we must be public by some time.

    It’s, let’s build the right products, continue to see adoption. We’re growing very rapidly, both within our base and customers deploying more, and new names, new logos, that are using our solution. And that’s what’s important to us. And the market, you know, the market will be the market. If somebody says wait, I can’t let these guys get that much bigger. I’m going to try to snap them up. That may happen. But it’s not something that we’re really focused on. We’re focusing on building the business organically in the right way.

    I have to say, we’re all old enough to have been through the dot com boom. And you know, the craze that went on back then. And I think it’s important to keep level headed. We’ve been around for three years now. We’ve just crossed the 100-employee mark. Celebrated that. You know, we work with our customers, we’re happy about that. We keep our heads, you know, leveled and we keep doing the work. You know, someone comes along and offers $35 billion to buy us, like Red Hat, I’m sure the board will approve.

    Shimel: They might think about it as –

    Feit: They’ll think about it a couple of days, you know. But in the meantime, we’re trying to keep things sane.

    Shimel: I hear you. Guys, just one last reminder while I have you both on. I’ll see you both out at the TubeCon Native, cloud native, Linux foundation event, along with Red Hat, right? Sponsoring a Monday conference on container security. I think we spoke about it last time. And I just, I don’t want to mess up the date, but I thought it was December 9th, or 10th.

    Feit: Nope, December 10th. So it’s the Monday right before KubeCon starts, and it’s collocated with the event in Seattle. And you can register on the CNCF site when you register for KubeCon, or if you already did you can go back there and add on one of these collocated events. Ours is very focused on enterprise security, so it’s called KubeSec Enterprise Summit.

    So for larger organizations, facing you know compliance requirements and deploying containers in production, it’s a great way to learn what others are doing. We have a great lineup of speakers. We have, JPNC is speaking. We have Tinder speaking. We have Starbucks talking about their journey towards secure containers. We have Liz Rice and Michael Hassenboss, who wrote the recent book on Kubernetes security. Which is not even published in paper yet, it’s still an eBook, but it will be first delivered in paper form at KubeCon. We’ll have them in our booth, and they’ll be signing books there.

    So it’s kind of a great event that people can get exposed to all of these technologies, and hear from a lot of different people. We ran an open call for presentations, so we have everything from technology to compliance to best practices. It’s going to be a great event. We’ve got a couple hundred people already signed up. We only have room for 300. So, if any of your readers do want to attend, they should do that soon.

    Shimel: Absolutely. Well, I’ll be there as well. We’ll be reporting for it. Andy, Rani, we’re way over time as usual. I ____ _____, we’ll need to call a wrap here. Congratulations on Aqua 3.5. I’m sure it’s going to be a great benefit, and the customer base will really appreciate it, and we’ll look forward to seeing you in Seattle.

    Feit: Look forward to seeing you, Alan. It’s always great to talk to you. And share what’s going on with your listeners.

    Shimel: Thank you. Andy Feit, Rani Osnat, Aqua Security. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

    — Alan Shimel