The Hybrid Cloud Approach to Cloud-Native Computing | Cloud Native Now 2023

Welcome to this session on the Hybrid Cloud approach to cloud native computing, and I'm happy to join you today with Tom Wallace. Let me start with an introduction of who Im, and we'll get through this content. So I am Rosalyn Radcliffe.

I am an IBM fellow. I am the IBM ccio DevSecOps cto. So I am responsible to help drive the DevSecOps transformation within, within our CIO organization and our CIO organization provides the services, the capabilities for all of ibm.

Tom, why don't you introduce yourself? Hi, uh, my name is Tom Lawless. I am a senior technical staff member at ibm, and I work very closely with Roselyn and my re and I am responsible for our developer experience initiative.

A and as you can see, uh, uh, the CIO organization runs the IT for I B M. We have thousands of developers, hundreds of applications, tens of thousands of repositories. Uh, when we look at the scale, we do things such as run the financing for IBM financing.

We run the systems for mail for all the obvious things, but also for supply chain for our manufacturing systems, because we build hardware for the sales teams, for the consulting teams. So we're providing the underlying IT infrastructure for the organization of over 200,000 people. When we think about this, we have a number of services provided by standard capabilities.

So we use common platforms, but we also have unique requirements. And so we have a number of homegrown applications as part of our portfolio. It's this large portfolio that we are responsible for running and what we want to make sure we're doing the best with.

And that brings us to developer experience. As Rosen called out, we're a large organization, and you can imagine we, we have a fair amount of complexity in, in what we do. And with an organization of our size and the importance that we bring to our enterprise, a developer experience initiative can have a real substantial impact to our productivity, to how we are able to deliver enterprise IT to IBMers, to our business partners, and even in some areas to IBM clients.

So our approach to developer ex experience, we really look at it in terms terms of four categories, right? So the first is platform. And as Rosalyn just briefly talked about platform standardization or what we, we tend to call our enterprise platform, um, really is an opinionated approach to how we deliver our enterprise IT services.

And that opinionated approach has a substantial impact on areas of developer waste, which we would look at as like wasteful and redundant effort that teams would have to repeat across, um, enterprise services if they were to run their own platform. So this might be security and compliance, um, DevSecOps, automation, um, o other, other, uh, um, you know, observability. Think, think of everything that gets put into the platform.

Even developer tools, uh, source code management, um, ides, everything that we can standardize, we are working to standardize so that we can move, remove more and more waste from our system in how our, uh, developers deliver value through enterprise. It automation's another big area for us. So we wanna make sure not only are are services de built and delivered with Dev, so couples automation, but we wanna make sure that other types of developer-centric automation work their way into the platform.

So you can imagine, you know, we've had, we have some applications that have been around for a while. So modernization is, is a really hot topic for us, especially when we start talking about developer experience and how we can help our developers continue to be productive. So, modernization, there's multiple developer-centric automation opportunities.

When we look at things like automation, this might be through, uh, test case generation, through documentation generation areas where developers either struggle because those things are missing or it would take a substantial amount of time in order for them to create. Those are the areas that are, are an example of where we can also bring automation to bear. Now, advocacy is also very important, along with modernization, along with platform standardization.

Advocacy is where we focus our efforts to build community and then drive and enable collaboration across our, our organization. It's things like education and upskilling, community building, driving more reuse, driving more collaboration and contribution. All of these activities result in our developers being able to focus more on the unique value that their enterprise service brings.

Not on recreating the wheel by redoing, like repeating redundant effort across the board. Analytics is the last piece, and it, it, and we're positioning it to underpin everything that we do. We need to be able to measure where we are.

We need to, to be able to measure the improvements that our developer experience programs are, are bringing to our environment. And we need to be able to be in a position to celebrate the success of our teams as they continuously improve. Yeah, it is absolutely critical as we think about those metrics and the analytics that we think about it from an overall standpoint, and we help drive the behaviors we want to drive.

Part of this effort and this opinionated platform is our view of the hybrid hybrid cloud. Making sure that we are providing the platform that allows our organization to drive true business value, as well as to be a showcase for what is possible with the hybrid cloud. Now, if you look at this picture, it looks relatively complex and you might look at it and go, wait, everything seems to be on it.

Well, you're right. Just about everything is on it. We run a very complex business, and yes, we are going to run multiple hardware types to take advantage of that hardware.

So we run our Z platform to make sure we provide the capabilities and optimize our workload around that platform, where it fits as well as power with I B M I for manufacturing, a common use case. And we run our own data centers co-located with b m Cloud. We also have resources and other clouds in the environment, but we want to take this platform, this opinionated platform, providing a set of capabilities for our business and expose it in ways that are easy to consume.

So we have our pipelines that allow the developers to do their job. They have their developer tools, they onboard into this environment via pipe pipelines, and this entire environment is being built in that infrastructure as code automated fashion. So not only are we helping our development organization, but also the infrastructure portion of our organization in a sense, as I like to say, everybody becomes a developer.

Everybody works like a developer. They work on code that gets instantiated as this platform. And we wanna provide this opinionated platform to help developers get the best capability at the right time for what they're doing, as well as allow us to build our systems.

So we're taking advantage of the hardware we have, the capabilities we have, and are making the best use of our systems. This is optimized on Red Hat OpenShift, where appropriate, as well as using pipelines to abstract out the differences so that developers don't have to worry about that. In here you see data capabilities, you see virtualization capabilities.

All of these are provided to the organization to allow all of i b M to take advantage of easily consumable data services, easily consumable capabilities. And by providing this platform and pipelines, we build security in from the beginning so we can build security into the infrastructure as appropriate and do the right security scanning, et cetera, as part of the pipelines. By building this infrastructure in such a way that the developers don't have to focus on what they're actually running on.

They focus on the business application that they are building, and the infrastructure is provided for them so that they just use it as part of the pipeline. And we really are working to remove the challenges, the day-to-day challenges from development teams by abstracting away the differences, removing the differences that don't matter, and making it easy for them to get to the resources they need appropriately. But this is an opinionated platform.

It may look like we run everything, but we are trying not to run everything. We are trying to bring more standardization to this, which is why we have the OpenShift environment across all of the hardware platforms to try and help standardize our container usage to help drive our use of OpenShift, as well as allowing those systems that should run on I B M I, for example, or on Z os to run on those environments as well. So it can all bring the brought together to provide that business value, this foundation for the platform that allows us to build the developer platform on top of it.

And our developer platform runs in this environment just for clarity. You know, we don't run it somewhere else. It runs in this in environment and provides the pipelines and the capability for our organization.

So if we move on into the capabilities that we provide, we want to work on this intelligent workload placement concept, we wanna make sure that we're using the right hardware to optimize the performance for that specific kind of work. We want to make sure we're taking advantage of the right location, co-locate work as appropriate and reduce the cost of our work by ensuring that we're using our hardware the most effectively and efficiently. And maybe one of the most important aspects of this chart is actually we want to make sure we're driving our sustainability goals.

I b M has some very strict, very, uh, hopeful, very focused, very driven sustainability goals. And our platform has to help us reach those. And so doing our workload placement, doing intelligent workload placement, ensuring that our workloads run in the most effective and efficient way from a sustainability and cost standpoint, we can help improve our capabilities.

And by allowing us to do co-location of resources, we can reduce network load, we can reduce overall cost, we can reduce transport costs, it helps facilitate this activity. And the developers don't have to worry about any of it because the platform provides this for them. They get to do their development activities and the platform then runs it for them.

So, Tom, You're exactly right, Rosalyn, I do not want developers to even worry about this a little bit, right? So what we're talking about is we're talking about a fairly complex approach to building container images that will run where we need them to run as an organization. And having our developers be responsible for doing that is, is the wrong way to approach it, right?

So when we look at our DevSecOps automation, that is, as Rosalyn said, built into the platform, runs in the platform, there's three areas that that we have to make sure that we can address. So the first is to build multi architecture container images. Um, and we wanna make sure that every service that we deliver to the enterprise is built on every supported C P U architecture so that we can decide over time where it runs the most optimally, chances of getting it right the first time are, are probably not great, right?

Like it, it'll take a little bit of trial and error, it'll take a little bit of, um, understanding, um, you know, how the workload runs on each platform so that we can start to build a better understanding across our organization about where each, each workload chew on based on its characteristics. Now that from a C I C D perspective can bring complexities into how our developers have to approach, um, constructing their applications and packaging them and, and working towards deployment. And as a dev, you know, as from our developer experience point of view, I do not want them to worry about that.

I want them to focus on the value they bring through, through their applications and through their services, not on how they're going to build and deploy them. So there's a few different approaches to building multi architecture container images and, and they, they come down to emulation. We're either gonna emulate the c p architecture or we're going to, we're gonna do it on platform, right?

And we're, we're gonna use native C P U support. Emulation works to a point, but there are severe performance impacts when we run pipeline. Every minute pipeline runs is a minute that we're, we're kind of delaying that value to, to, uh, you know, that we could be bl bringing to our, to our enterprise.

So we want to make sure that we are continuously improving the performance of our pipelines, and in order to do that, we need to run the builds on platform. And then of course, there's a bunch of fringe cases that we have to be aware of as well. So our build environment needs to expand to, to be able to build our container images on X 86 on, you know, uh, uh, um, s three 90 on power so that we have those images available for us so we can run them where they need to run.

And we want all of that to be transparent to our developers, but also not something that they worry about. Once the container image is built, then we move into platform selection and, and deployment. Deployment, as you can imagine, is, is, you know, probably fairly standard in, in the grand scheme of things, but platform selection is much more interesting in the way that we're envisioning this and, and, and working with it now is it's, it's fairly simplistic.

It, you know, and, and we are positioning as so that we can get hints from the developer hints about where the application should run best, as well as backing that up with data, um, about, um, observability data, uh, for example, um, build data, like did the container image successfully build on one of those platforms? Well, if it didn't, we can't run it there, right? So that, that part of the selection criteria that, that we have to bring into play.

And we really want to automate and continue to automate that across all the platforms that we support. And then finally, security and compliance. Um, as we scale out our build environment to support multiple CPU architectures, we have to make sure that we do that in a secure way and that we can prove the security of our software supply chain as we have, um, you know, various processes running on, on different areas of the platform.

And security and compliance, again, is another area where we, we want developers to be aware of what changes they may need to make in order to make their, their, their service more secure, more compliant with industry and corporate standards. But we do not want them to have to implement this on their own. We, we want them to get the visibility into what our pipeline provides, areas of, of improvement, um, and, and really just be able to benefit from the end-to-end automation that the platform provides.

Then advocacy, um, as we continue to work towards removing waste from our system, and we make these changes, right? You know, we're, we're driving the changes to the way that our teams work. We need to be able to advocate for the needs of our developers to ensure that, one, they understand what we're doing and why we do it right.

Education, we need to be able to reach every developer in the organization, provide them with the education and upskilling that they need to maximize their use of, of new tools, maximize their use of our opinionated workflows, and really make sure that we're removing as much waste from, from our system as possible. Community. Let's bring our developers together.

Like any large organization, we are organized based on product lines. Um, that doesn't mean that our developers need to be siloed in those product lines, though community, as part of our advocacy helps bring our developers that work on common platforms, uh, work on common programming languages, help us bring them together so that they can benefit from each other's work and each other's knowledge, feedback, what's not working? What is painful?

Uh, there can never be enough automation. That automation can never run fast enough. Where is the friction in our system?

Where are the pain points? Where are the bottlenecks? Some of that we do get from analytics, but user feedback can never be underestimated in the value that it brings.

So sometimes this feedback is done through formal surveys. Sometimes this feedback is through, through ad hoc channels. Um, sometimes this feedback is one-on-one.

Um, but it is all important and, and we, we take it all very seriously and work to address it. And then finally reuse, um, in the, the amount of time that we can save our developers by driving more reuse across our environment, whether that's libraries or APIs or even patterns, best practices, lessons learned that come out of our communities. Reuse has a substantial impact on, in, in or organization of our size.

It helps us make sure that our developers are maximizing the use of the platform that's provided them to be as productive as possible. A and I think it's absolutely critical to understand that developer advocacy, helping our developers up skill and or current skill and or whatever the right word is to really drive this continuous improvement methodology should not be understated. It is absolutely critical that we all help all of our organizations change the culture to this continuous improvement, continuous learning culture.

This change significantly improves developers lives all of our lives, but it also helps improve our excitement, our drive. It can help remove drudgery from the challenges and, and this idea of education and driving awareness, making sure we're helping teams with the best practices on how to do things today, as well as helping make sure that we're not causing the opportunity for rework where we can avoid it. For example, in the pipeline that Tom was talking about, the automation, instead of directly coding into every GitHub repository that we have, pipeline kind of things, we use configuration so that tomorrow if some other pipeline tool comes out, that is something we should move to.

The development teams don't have to do that. It can be handled by the plat, the platform itself, the developer experience team doing things such that we're helping teams abstract themselves from the particular tooling to allow things to change underneath them with without causing impact. Absolutely critical.

The same reason we're doing multi art containers, so that we can make a conscious decision about where that should be run. And it may be based on sustainability and what hardware is currently available, or it may be based on performance, and I need this next to the user or next to the application. There are all sorts of questions that can be answered as part of the automation and the capability to remove that challenge from our developers.

But we want to learn from everyone. Everyone has feedback, and we need to make that channel extremely open, making sure that we are open to feedback and open to learning, getting teams to say, Hey, oh, by the way, I've figured out a great way to do this and have an inner source contribution model to our pipeline itself. Mm-hmm.

So it's not just we have a central, we're controlling the world and team. We have a community of people help bringing everyone up. And that concept of inner source with this pipeline and with this platform helps us improve by getting the best from everyone, allowing them to contribute the pieces that they've developed, the automation that they've created, or the ideas that they have to help bring the organization forward in this continuous learning model.

And by having this inner source concept, which some of which actually will end up in open source with Red Hat probably, or other methods, but it, it really is driving this collaboration and this community and really driving that community and that collaboration across our business lines to help make sure we're having people come together is a key piece of this transformation that really helps us take advantage of capability and help our environment, um, be better for everyone. Mm-hmm. And it's really important, hopefully recognized in our platform picture, really our developers don't have to worry as, as development models change, as someone comes up with the latest, greatest way of doing something.

Let's think about corcus. You know, we've had large WebSphere applications, we've had smaller applications, we have corcus. The idea in making it easier for teams to adopt to the latest capability is the latest ideas without a lot of work is a key critical component of this.

I like to look at inner sources, how we empower our developers to have an ownership stake in our platform, right? Ma many developers are happy to, you know, produce great high quality services that meet the need of our business. Many developers are also interested in, in expanding into other areas.

And then this is a, a mechanism. While we still are driving abstraction of the plat, uh, of the platform, we're still driving, um, you know, standardized, centralized C I C D automation. It, it's a, it is a mechanism for them to contribute for our organization to continue to leverage their skill and expertise and for it to really be a developer platform, right?

And with that, we want to say thank you. Hopefully this has given you a perspective of how we are transforming and changing to really provide that cloud native developer experience for everyone. Whether or not they're doing scale one COBOL on Z os, they're working with Z B M, or they're building containers that will run in an OpenShift environment.

Really bringing that same developer experience, really bringing that simplicity and ease to everyone while providing our business the best environment, the best availability, the best cost solution, and improve our overall sustainability footprint. Thank you.