Hi. Today I'm going to talk about why the future is cloud native and why your organization should be too. Today we're going to be covering what a cloud native system looks like, why enterprises are making the move to cloud native and why not. I'm then going to look into a case study in the banking sector and their cloud transformation. Then I'm going to talk about the benefits of adding cloud native package repository like cloudsmith to your tech stack. Then I'm going to look into what you should consider when selecting cloud native tools. Hey so I'm Kira Carey. I work in developer relations in Cloudsmith. I'm nearly there a year and before this I was a software engineer for over ten years. I worked on web services and web apps, in printing, in security products and in computer vision applications. The biggest change I've seen in software development over the last ten years has been the availability of cloud infrastructure and that move away from data centers. It's changed how we develop software and what we develop. I worked on cloud transformations and had to really skill up on all that cloud stuff on Docker, microservices, event messaging and changing those config code. It was a huge learning curve for me and has given me a lot of empathy for developers going through the same cloud transformation. So before we go on, I want to talk about Cloudsmith. Cloudsmith is a cloud native fully managed package management as a service. We host and support over 28 different types of package formats and we securely store your packages in a private artifact repository and we make it easy for you to automate and integrate your artifact registry with your existing CI CD tooling. So what does it mean to be cloud native? Cloud native systems are architectured and developed to take advantage of the latest cloud technologies infrastructure provision and configuration is automated. Resources are dynamically allocated and reallocated at deploy time based on the needs of the application. Cloud native software development usually needs microservice architecture. You expose functionality via restful APIs. You probably use containers with Docker, you have some sort of container orchestration software like Kubernetes, youre use messaging systems like Kafka and RabbitMQ, and you probably automate your CI CD process to build your software into the cloud and to deploy to cloud infrastructure. You're probably building and releasing code multiple times a day and you probably also have a cloud made of tech stack to help you with your build process for your CIC details for your package management tools, your observation tools, and your security tools. In Cloudsmith we've seen a huge increase in the number of packages stored on Cloudsmith associated with cloud native technologies like helm and Docker. From 2020 to 2021, new helm packages are up 271%. New docker packages are up 236%. And from today to the started of the year, new ham packages are at last year's 70% level, even though we're just a quarter way into the year. So if cloud is so amazing, why isn't everybody just hopping on that bandwagon? Well, this is not just an engineering decision, it's an executive level decision. The big boss man upstairs. There's huge upfront costs. Rearchitecting your systems is a huge undertaking, especially if you have a lot of legacy code. It's likely to take up many engineering hours, changing from a monolithic application to microservices. You need to update your tech stack, getting rid of your on prem systems and moving to their cloud offerings, or maybe changing supplier. You need to renegotiate these contracts, review new products. Your build processes are likely to change with new tooling and increased automation, there's probably going to be personnel changes. You need to train up your developers and your it team job does may change. You may need to hire in new developers and maybe even a consultancy team. And you possibly need to train up your customers as well. So there's risks and security issues also associated with moving to the cloud. At cloud service providers, issues become your issues in December last year AWS had an outage in us eastern region and it affected loads of sites and applications like Tinder, IMDb being Netflix and Disney. So it's no joke moving to the cloud. So this seems pretty tough. Why would anybody do it? Well, there's loads of really good reasons. Reduced overall cost. I mean for businesses it's the bottom line. Improved performance, enhanced security, it's brilliant for distributed teams and customers. And bit also facilitates innovation in your product. Let's go into these reasons in more detail. Let's start with cost. Oh, it didn't change over cost, so running data centers is costly. They require a lot of electricity for all that air conditioning and people need to run it. Infrastructure and cloud native services are fully managed. You don't have to worry about maintaining your on prem software or infrastructure. No updates, no security patches, no replacing obsolete hardware. There's economies of scale to consider. Third party providers like AWS, Google Cloud and Microsoft can offer economies of case that a single organization could not realize on their own. It's a price thing. And we should also consider opportunity costs. Every dollar youre invest in an engineer not working on your core competency youre core products has an opportunity cost associated with it and also there's clearer pricing. It's generally you pay for what you use in some sort of subscription model. There's performance benefits. Cloud native software can quickly scale and readjust its resources to meet demand. A company experiencing rapid growth can use the cloud to expand its infrastructure and computing power. In contrast, the same company using on prem infrastructure would have to quickly invest in more hardware, software and engineers to keep up with this rapid growth. Cloud native applications arent bit to run the cloud and they're designed with redundancy and high availability in mind. High availability is made possible by redundant and failover systems. Data and services are spread across regions to avoid that single point of failure. So let's talk about security with cloud native systems, people are afraid of the loss of control and security risks in using cloud infrastructure. A secure system needs a secure building, training, constant security updates, high availability monitoring and disaster recovery infrastructure. Although many companies that host their software on prem take security very seriously, it's expensive and requires many working hours. You can actually raise your security posture using cloud infrastructure and cloud native services. There's 24/7 monitoring. Security expertise is beyond the reach. Expertise is available that is beyond the reach of most in house teams. Cloud infrastructure can provide you with internationally recognized accreditations. Your HIPAA, your isos, your fips, your sock two. And they can also help you achieve those third party accreditations for youre products. I know being cloud native helps cloudsmith achieve our ISO 27 and one last year. It made the process much faster and more streamlined. Cloud infrastructure providers have security and compliance services to help you manage, access, analyze data for irregular activity, and they can also tap into machine learning capabilities. Developers can then use these services to automate security. They also provide services to prove your compliant relations. This is really important to those highly regulated industries like insurance, banking, pharmaceutical, that kind of thing. Security is definitely a risk when moving to the cloud, but designing a system with security in mind and by incorporating security into youre build and deploy process, your system can actually be more secure than a traditional on prem system. Let's talk about how cloud native systems can really benefit distributed teams and customers. Well, first off, Covid has really supercharged the rise of the distributed teams. Many teams are remote bursts and have members that reside around the world. I'm a remote employee myself. Our head office is in Belfast and I'm in Dublin on Prem. Software solutions tend to be faster the closer you are to the infrastructure. So if you have a team in the US and a team in Europe and you only have one data center, one of them is bound to experience lag. Cloud native services are multi region and provide consistent response times no matter where you are in the world. This helps with collaboration and productivity on distributed teams. Cloud software can use techniques like content delivery networks and edge caching to further improve performance on their cloud native systems. Cloud native systems can also accelerate innovation in products. Modern DevOps process make it easy to release and build code multiple times a day. Deploying new product can take weeks instead of months. Also, you can tap into that data analytics that's really associated with cloud native systems. Data aggregation is made more efficient in cloud native systems. You can actually build products and gain insights powered by this data. Another thing to consider is you can plug into the world's innovation. You can buy cloud native tooling that can bring you instant and continual benefits with features getting added without needing any upgrades. The next section I'm going to talk about this case study into the banking sector and their cloud transformation the banking industry has been pretty slow to adopt to the cloud and update their systems to be cloud native. Banks have long understood that using cloud infrastructure has cost benefits, but they didn't feel like it was worth the risk. There's loads of understandable reasons for this, including they're in a highly regulated industry and they're reluctant to move from their on prem systems due to privacy and regulatory reasons. Banks arent reluctant to move away from their legacy technology, especially their Carey tech systems that do all those millions of transactions every day. Because it works. It's familiar. If it ain't broke, don't fix it kind of thing. Banking executives have conflicting priorities, making it difficult for them to prioritize a major huge it project, especially one associated with such so we've noticed in cloudsmith over the last few months that financial institutions have been interested in cloudsmith because we are a cloud native SaaS product, they're not asking for our on prem version anymore, which is great because we don't have one. I've being looking into reasons for why there's been an increased interest in our product, and I found that several banks have undergone a cloud transformation during the pandemic. Capital one announced in November 2020 that it was going all in on the cloud by closing all its data centers and migrating everything over to AWS. JP Morgan, HSBC helps Fargo, and also there's been comments about it in the New York Times and Forbes talks about bank's great core to the cloud migration. Why did this happen now? Well, it's not all banking cloud infrastructure offerings have matured. They have services that helps provide to help meet security and compliance standards in banking. Regulatory agencies in the US, the UK, the EU and others are now more open to cloud only banks. Several larger banks have undergone a cloud transformation during the pandemic. This is not a coincidence. Customers aren't going into banks and they're demanding services and real time results that require bank systems to undergo a cloud transformation. There's also market pressures that banks have to consider. They're worried about these young pups, the fintechs of the world, revolut and big techs even like releasing financial products, and that in order to keep up with the competition, they need to evolve. There's also staffing reasons. The pool of technical talent that understands these legacy systems is shrinking and aging as the technology ages. Alan McIntyre from banking, a senior director for banking at Accenture, talked about the causes for the core to the cloud and how it's reached a tipping point. Now the journey has been worth the effort. Well, what do the banking sector get out of this cloud transformation and these cloud native systems? Well, all the stuff I talked about before, reduced cost, performance improvements, security improvements and security province, that these cloud services can now prove that they're compliant to the regulations that banking have to, that's important to banking. It's really helped distributed teams and distributed customers, and it's also facilitated innovation. So maybe youre see new features in your banking application. Maybe you're able to access all your banking products from a single application now, your mortgage, your credit card, your savings accounts, they're no longer stored separately. There's fraud detection features. And also we're now seeing real time results where before youre might have to wait a few days, a few days to see your real balance while it's doing all this batch processing in the background. And now you're instantly seeing real time results. Ok, the next section I'm going to talk about how adding Cloudsmith's cloud native package repository to your tech stack can really help your build pipeline. Hey, so Cloudsmith is a cloud native, fully managed package management as a service. We host all your packages in any format, just in case you were wondering about what a package was, because not everybody is like 24/7 talking about package management. A package, an artifact, an image or a binary groups together files containing your software along with metadata about the software dependencies, those third party dependencies, maybe open source dependencies or in house dependencies, all in a well defined format in that package. So maybe it's a maven package or a Nuget package or NPM or a docker, a package repository, a registry or feed. It's a place to store all your packages. If you have adopted DevOps practices, you'll be building your packages a few times a day and pushing them to youre package repository. So your package repository is at the heart of your software pipeline and has the potential to be a real bottleneck. You can see here an example of a build pipeline where you're building a few times a day you're pushing your package to Cloudsmith. We're hosting it for you to be available to deploy to cloud infrastructure. So one of the key benefits to our customers is that our cloud native service means that you can push your packages up and deploy them anywhere in the world. Scaling is handled by us, distribution is handled by us. Maintenance and upgrades, that's us as well. 24/7 report support and we can provide a service level agreement guaranteeing of times. I think it's like 99.5 but it's generally 99.9, something like that. It's good. And how are we able to achieve this? Well, Cloudsmith is designed from the ground up as a cloud native application. We don't offer an on Prem variant. It means that we arent multiregion, globally available and scalable. We're a fully managed package management. As a service, we're built on top of a content delivery network with over 225 points of presence, allowing us to efficiently distribute and deploy software artifacts globally. Another huge benefit that our customers get from using a cloud native packages manager is that we provide simple pricing. You pay for your usage and your storage, your bandwidth and your storage. Efficient and simple access and analysis of data is part and parcel with being cloud native. We're also able to provide our customers with detailed analytics about their repositories about who has downloaded what and where. We also provide information for you to monitor your storage, your bandwidth and your token usage so you won't be surprised by an unexpected overage and it'll give you a bit of time to change youre settings before you reach your limits. Support is really important to Cloudsmith, but I have to say it's actually easier for Cloudsmith and cloud native tools to provide quality support. We support one tool running on our infrastructure, other tools, other on prem tools have loads of different versions out there running in the wild on customers'hardware. The permutations involved in supporting that make it very difficult to provide quality support. We value support at Cloudsmith, but we also benefit from being cloud native. There's actually a lot of innovation happening in the space of securing your supply chain and package management. It's really hard for people to keep up with all the advances in package management. But because Cloudsmith is cloud native, youre are always on the latest version with the latest features. And it's great because our cloud native architecture and DevOps processes allow us to build and release code several times a day. We can also release versions of features behind feature flags, which allows us to kick the tires and reduce our risk in launching features. We actually have a lot of stuff coming up in quarter two. We have new formats like Conda for those data scientists out there. We have support for software bill and materials. We have support for new ways to sign packages, more logging and service accounts, and more. And once they're done, youre customers get those features straight away. So cloud native engineering teams need a cloud native tech stack to help them build their software. It facilitates increased automation and stability. I'm going to talk about what a cloud native tech stack can look like for building, testing, packaging, securing and monitoring your software pipeline. And then let's talk about what to look out for when adding a cloud native tool to your tech stack. So what would a cloud native software pipeline look like for building and deploying your software? You'll need some source code management. You'll need CI CD for automatically building and testing your code anytime a new commit is made. You need a package management tool in the center there for hosting your packages and making them available to deploy wherever you are or to cloud infrastructure. You have monitoring tools or observability tools like your datadogs, your splunks. You have security tools for scanning your packages or scanning your code. You have tools for deploying to infrastructure like Ansible, terraform, all that kind of jazz. And cloud native engineering teams need tools that are stable, that are highly available, that encourage you to automate your software pipeline, and tools that are easy to integrate together. Because you can see here from this image, there's so many permutations when you're building your software pipeline. All these tools need to play well together so that you can have the setup that you want. So what should you look out for when youre adding a cloud native tool to your software to your tech stack? It should be easy to sign up and you should get immediate access to the tool. No waiting for accounts to be provisioned or permissions to be granted. It's frustrating to use and maintain a tool with no does or poor docs. Features should be well documented, and also your APIs should be well documented as well. There are so many permutations for building your software. Your tooling should provide robust APIs, nice integrations, and webhooks to allow you to automate your software pipeline to suit your organization. When something goes wrong, you want to be able to speak to someone quickly about what's going on and know that they will help resolve the issue. So I think there's things that you should consider and thanks for listening to me. So the cloud has been around for over ten years, is matured enough so that even highly regulated industries like banking are moving their core systems to the cloud. Cloudsmith is a package management as a service, and can be part of your cloud native tech stack. I think the journey is now worth the effort. Thanks so much for listening and I hope to see you again.