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. Um, why not? I'm then going to look into a case study in the banking sector on 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 Ciara Carey. I work in developer relations in CloudSmith. I'm nearly there a year.

And before this, I was a software engineer for over 10 years. I worked on web services and web apps and printing and security products and in computer vision applications. Uh, the biggest change I've seen in software development over the last 10 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, uh, microservice architecture. You expose functionality via RESTful APIs. You might use, you probably use containers. With Docker, you have some sort of container orchestration software like Kubernetes. You use messaging systems like, uh, Kafka and MQ and you probably automate your CICD 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 tech stack to help you with your build process for your CICD tools, for your package management tools, your observation tools and your security tools. In Cloud Smith, we've seen a huge increase in, in the number of packages stored on Cloud Smith 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 start of the year. New hand packages at are at last year, 70% level, even though we're just a quarter way into the air. So if cloud is so amazing, why, 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. Re architecting 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 roles 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, Ring, 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 it also facilitates innovation in your product.

Let's go into these reasons in more detail. Let's start with cost. 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 24 7. Cloud 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 scale that a single organization could not realize on their own. It's a price thing. And we should also consider opportunity cost. Every dollar you invest in an engineer not working on your core competency, your core products has an opportunity cost associated with it.

And also there's clearer pricing. It's generally, um, you pay for what you use in some sort of subscription model. There's performance benefits. A 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 are built 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 SOC2, and they can also help you achieve those third party accreditations for your products. I know being cloud native helped CloudSmith achieve our ISO 27. 1 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 compliance regulations.

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 your build and deploy process, your system can actually be more secure than a traditional on prem system.

Let's talk about how, uh, um, um, 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 versed and have members that reside around the world. I'm a remote employee myself. Um, 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 processes 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, 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. And 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 are reluctant to move away from their legacy technology, especially their core 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 risks.

It's, yeah, 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 been 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. J. P. Morgan, HSBC, Wells Fargo, and also there's been comments about it in the New York Times, and Forbes talks about banks 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 help provide, to help meet security and compliance standards in banking. Regulatory agencies in the U. S., the U. K., the E. U. 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, the FinTechs of the world, the Revolut, and big techs even, like, um, releasing financial products.

And that in order to keep up with the competition, they need to evolve. There's also staffing reasons. Um, the pool of technical talent that understands these legacy systems is shrinking and aging, uh, as as the technology ages. Um, Alan McIntyre from ex banking at from a senior director for banking at Accenture talked about, uh.

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 did, um, what do the banking sector get out of this cloud transformation and these cloud native systems? Well, all the stuff I talked about before, reduce cost, performance improvements, security improvements and security improvements that they can, um. Security can now prove, these cloud services can now prove that they're, uh, they're compliant to the regulations that banking have to, that's important to banking.

Um, it's really, really helped distributed teams and distributed customers. And it's also facilitated innovation. So maybe you 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.

Um, there's fraud detection, um, features, and also we're now seeing real time results where before we would, um, 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.

Okay, the next section I'm going to talk about, um, how adding CloudSmith's cloud native package repository to your tech stack can really help your, um, 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 contained in 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, all in that package. So maybe it's a Maven package or a NEWA package, or MPM, or a Docker, a package repository, or a registry or feed.

It's a place to store all your packages. If you have adopted DevOps practices, you'll be building, um, your, your packages a few times a day and pushing them to your 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 all your, you're building a few times a day. You're pushing your package to Cloud Smith. 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. Um, we can provide a service level agreement guaranteeing uptimes.

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. Um, it means that we are multi region, 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.

Another huge benefit that our customers get from using a cloud native package manager is that we provide simple pricing. You, 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 could also, um, we also provide, um, 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 your settings before you reach your limits. Support is really important to CloudSmith. But I have to say, it's actually easier for CloudSmith and, um, CloudNative 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, you are always on the latest version with the latest features. And it's great because, um, our cloud native architecture and DevOps processes allow us to build and release code several times a day.

We can also, um, release versions of features behind feature flags, which allows us to, like, 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 Condev for those data scientists out there. We have support for software building materials.

Um, we have support for new ways to sign packages, more logging and service accounts and more. So, and once they're done, our 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 CICD for, um, automatically building and testing your code anytime a new commit is made. You need a package management tool in the center there for, um, 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, um, security tools. Uh, 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, um, 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, um, 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 you're adding a cloud native tool to your software? To your, um, 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 docs or poor docs. Features should be well documented and also your API 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 are things that you can, should consider. And thanks for listening to me. So the cloud has been around for over 10 years is matured enough. So, 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.