 Well, the biggest difference with cloud native applications is they're deployed in microservices and smaller components. Traditional applications were deployed inside of a data center where they were protected by the firewalls and the perimeter. Cloud native applications, they live in the cloud. They have to be secure and protected from all sorts of threats that aren't normally associated with the traditional application. Cloud native applications are different in cloud native apps because the cloud native apps tend to have a lot more components, they have microservices and those are spread throughout the cloud and different cloud providers, which means you have a much wider area of security that you need to pay attention to, where traditional apps are typically more contained with fewer components. When you think about cloud native applications and microservices, they have to be able to connect with each other and identify who they're talking to. Their APIs have to have the ability to authenticate and to secure the transactions that they're making with each other. A traditional application never had to worry about what component is calling search or what component is initiating a transaction. In a cloud native application, there are so many different attack surfaces and ways an application has to be safe that it makes it much harder to develop and deploy and to manage it from a security perspective. So cloud native apps tend to run on Kubernetes, which is a layer that orchestrates the containers that they run in, and that adds a whole other layer, effectively, in an operating system that has to be secured with a whole new set of vulnerabilities that can happen and that have to be bound and cured for. Well the software development life cycle is a critical component of developing secure applications. All too often, traditional application development has left security to the end of the life cycle. It's been something that development teams wait for security to demonstrate and approve that their application is safe to deploy. What you have to do in the software development life cycle is you have to move security earlier. Security has to be a key requirement and it has to be tested for every commit. One of the things I recommend teams to do is to incorporate security testing as a part of their pipeline so every commit is tested and validated for security. That way no new vulnerabilities are introduced as you develop new code. Yeah so when you're thinking about security, you want to get that as far left as you can in your processes of developing the software. You don't want to wait until you're about to release it to then say let's check it and make sure it's secure because if that happens and you find problems, now your release is stuck and you've got to go all the way back and have it developed again or looked at again and it's a lot more expensive to find problems the further into production or past production that they get. So what we want to do is do security testing, scanning, all of that is part of the development process and enable the developers to fix the problems so that they don't end up in the hands of operations to do it. Well digital transformation is an incredibly important trend that's happening and touching every industry. Digital transformation means moving faster and accelerating delivery of value to both meet the customer's expectations but also to be able to keep up with the competition. Software development has to change in order to go faster and I think there's three or four key things to do to go faster. You have to enable teams to collaborate across silos, to collaborate and share information. You have to think and change the way we develop to go from large releases to smaller and smaller, more granular changes. I think of it like this in making very small steps to reach your goal. You can react to how the goal is changing and this is a mindset change that teams have to go through. We call it minimum viable change and it helps us to go amazingly fast. The third thing I would add is automation, building a pipeline that automates the manual tasks and the manual tasks that go into delivering software. Automation is a key driver to enable teams to go faster. Teams that are adopting digital transformation should be focusing on how efficient they are at getting their software ideas, their ideas into software and actually out into production so that they can get feedback and they can continue to make adjustments. So one of the really good advice is to think small and iterative rather than doing a big, large development process and then only getting something out months later or weeks later even to find out that it's the wrong thing. What we recommend is doing what we call minimally viable change, which is if it's better, what you've done is better than what you have now, get it out there. Because then it's live, you can get feedback from the world, you can learn and adjust and make sure that you hit the target.