The Critical Role of Architects and Engineers in Reducing Cloud Computing Costs – André Christ, LeanIX

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Andre Christ to CEO for leanie x and we're gonna be talking about the role Enterprise Architects should be thinking about playing to help contain costs, which are as we all know, we're all a little bit more sensitive about that these days but we've kind of allowed them the spiral out of control for a wide variety of reasons that we're about to jump into Andre welcome the show. Thank you so much for the invitation the pleasure to be here. We have been consuming resources in the cloud with abandoned over the years.

We've always gave developers free reign and now it seems like we're talking about finops and there's this whole effort to shall we say in Jack a little more adult supervision into how these resources are consumed. What is the role of Enterprise Architects and what kinds of processes should people be looking at putting in place because for a while there was just well, it was easy to spin up resources and nobody ever looked at the bill and now they are Yeah, you're right. I mean a lot of the companies have decided on a cloud first or migration to the cloud.

And as you described it was probably all in moving applications over and the priority was like adopting it as fast as possible and it was not really thought about much is it really optimized for the cloud and unlike some of the cloud native born companies who have actually optimized their application natively for the cloud many cooperations and Enterprises were more busy with demonstrating their shifting or lifting and shifting their workloads into the cloud. And what is the result of that? Well, you're moving an inefficiently running application on a server into like it's gonna still run inefficiently in the cloud and consume a lot of a lot of the resources and energy.

So unless you optimize it it's it's not going to be really great in the cloud and this is where Enterprise architect. Can come in and help to understand looking entirely on the portfolio. So before you move just stuff into the cloud and the lift and shift understand.

What should you actually re-architect? What can you actually retire even before you moved into cloud or where do you go and shifting over to a software as a service? So repurchasing instead of actually re hosting or re-platforming?

Seems like a lot of people are caught up as to where and when to do that. Some folks are saying you should do that before you move other people tell themselves that they'll move the app and then they'll start refactoring into a bunch of microservices over time. Is there a pattern is there a better way to go or is it up to each individual organization depending on whatever deadlines they got to face?

Yeah, I believe that it's in general. There's great systematic approaches around one of those is leveraging the aws-6r method to systematically assess the portfolio. So going through some of the ours it's re-hosting re-platforming re-architecting retiring repurchasing or even retain what you have and keep it on the in the data center how you're running it.

So and I think that is first of all the method which is helpful just to avoid your just doing busy work and moving things into the cloud on the timing. So do you optimize first and then move or do you move and then optimize? Well, I think it depends a bit what you want to achieve if there's the need for the business for scalability.

Of course, you can go in certain areas and say like, okay I'm accepting inefficiency because I'm gaining scale, but I would argue that this is a business. Fit then so if you identify there's a benefit for your consumers or for your employees to have something in the cloud where you can probably compromise a bit on inefficiency. However, if there's just a technical aspiration, we're going to move it one to one into the cloud to to checkmark it off.

I would argue you're much better off systematically assessing it first and then moving into a better option because many in many cases you can actually save 10 to 20% of the of the immigration effort by just sun setting what is anyhow not needed so you can focus your energy around selecting better Solutions or optimizing for the cloud in the first place. So if there's immediate business benefits, I would opt for accepting inefficiencies. If it's not I would systematically assess the portfolio ahead of it.

One of the benefits of cloud native is it allows you to scale up resources up and down more dynamically than you can with a monolithic application. Do you think as we become more cost sensitive that we'll see both accelerate the transition the cloud native where they're using kubernetes and some of these more Advanced Technologies things kind of contain those costs. Of course, I think it's the beauty about some of the now Diversified Services where we're not talking just about a virtual machine which is in the cloud which is probably now more and more understood as well.

This is the last resort of running stuff in the cloud. The more intelligent things are kind of Leverage a managed service. Can I use a managed database which is optimized by one of the hyperscalers for specific usage or do I use functions in in the cloud or or kubernetes as a platform to spin up things and and to scale up notes as you need it, so I think If you look at devops teams right now, they have a variety of options at hand.

And this is I'm just talking about compute. Now if you look at storage, it's similar. I mean, you can go from like SSD storage for workloads, which need to be accessed fast to to completely different block storage when it's it's not it's not needed to access it.

It's on a short latency time and I think what comes in again is the understanding of what are the options you have and what are from and from an architecture perspective. What are where are you going and I think what we will see is there's gonna be another dimensions in the years to come which is to hold discussion about sustainability. It will be the question.

Does it make sense to consume resources or consume storage, which is not optimized for for the for the workload and I can already see the demand of Business Leaders increasing to understand. What's actually my sustainability footprint because as we know by now the the energy consumption by all the data centers around the world is becoming more. Than all the all the flights we are doing around the world.

So it's it's becoming a significant portion of energy consumption. Do you think devops teams are prepared today to manage? All these different kinds of applications that they're going to be running because they'll have the Legacy monolithic ones.

They'll have the cloud native ones that are running on kubernetes and then they'll have extensions to those running on serverless Computing Frameworks. So are things getting more complicated than we can handle. Yeah, I think that becoming incredibly complicated because there's increasing tool chains.

The abstraction layer has become so much better. Right? So it's it's no longer that you have to manually deploy something to the cloud you use Technologies like terraform and the like to actually abstract it and then and then you can deploy into into different targets, which is great.

It makes you independent but it also increases the requirements on what teams need to understand to do it and I think you you touched a bit on the on the on the whole Space of finops before which is a whole you could probably argue science or category to understand what's actually a way to cost efficiently run like workloads in the in the clouds and and demonstrate the cost footprint of it and I think what we are seeing right now, we see a trend that if you look at the whole value stream of creating a digital solution starting with the requirement in the Thing and then with monitoring the performance and the customer satisfaction like in the end of this then there's a lot of tools involved. So there's there's tools where you gather requirements. There's tools where you gather NPS feedback.

So the net promoter score their support tickets, there's deployment platforms Performance Management and it's difficult for for product teams to keep a consistent overview of this. So this is why we're seeing a bit this discipline of value stream management emerging where where product teams get a bit of a single pain of glass where they can see their services. They can understand in one area.

Like how often are they deploying? How well are their services set up what dependencies does have and then from there jump into the more details? So yes, I see it's it's becoming on the one hand more complex, but on the other hand, it's a great opportunity to leverage this this Foundation of of tooling we have but I think you need to to wisely pull it together and leverage leverage that toolchain.

Well, otherwise, you're you're wasting a lot of time. Do you think this will force us down the path towards higher levels of automation, whether it's AI or whatever it may be but it seems like we're reaching a point where it's too complex for mere mortals to manage themselves. So how augmented can we help these folks get?

Well, I mean, I'm I'm all for the the part of Automation in here. I'm still skeptical to what degree Ai and and those technologies will actually be helpful to do that. I'm I'm equally skeptical on the contribution on the on the co-development side.

Honestly, I think there's a good opportunity for assistance and and helping to with with pattern recognition helping teams to identify security issues or typical flaws in it while coding. I I still see there's so much potential for getting a better visibility on the data instead of getting lost in in AI or ml conversation so visibility and having good analytics in place and connecting the data. This is what we at least see in many of our customer situations where there's like different data sources and people waste time linking.

Thinking those together. So you have like your stories in jira and your epics and then in like another solution you have actually in the understanding about what services you're running in the next you get a feedback by customers on their priorities and so it's that that was time. So I think until reaching the point where we can actually really get to leverage from like machine learning and AI I would argue there's a lot more efficiency and if automation gains to be captured by getting the foundation, right and so that's my my personal View.

So once your advice to folks when the CFO shows up and just randomly says we're going to cut spending by I don't know 20% because CFOs will manage with blunt instruments. Um, and yet I am trying to maintain agility and reliability and a lot of reliability sometimes is tie the over provisioning. So how do I kind of balance these three things now where I'm trying to rain in cost and maintain agility and reliability Yeah, I mean to go even further we in the last couple of days witnessed that even CEO start now to ask the product teams to shut down microservices.

So I think we're getting in times to a point where it's important to continue working in a data driven way. So that's why I mean you you can't you can actually go into Landscapes and and shut stuff off. I think the first step is having a good Baseline in place that you understand.

What is what is a certain service contributing to what is the what is like the business impact of it? What what is the game? So if I shut down a service or if I optimize if I optimize the service and and all in all this requires to stay data driven.

So the requirement towards the product teams will be that they have good instrumentation in place, which they shouldn't build on their own. So I consider this to become really a commodity thing. Because we have to make sure as as product teams that we're not starting now to engineer our platform.

So in the early days people have invested time in building. org or or others now we should now waste time in and start building tooling for understanding what services we're running and I think this is where vendors can come in and help help those companies avoid that their product teams get busy with like too much of that automation. I think this is always like a pendulum, right?

So until there's great Solutions around you actually optimize yourself, but my advice to engineering leaders or technology leaders is to actually continuously observe and see what are the capabilities really where which you want to invest in and and where you need to develop stuff versus where you can put where you You like use commodity Solutions on the market. And so again something like value stream management becomes more and more an established established topic and and therefore helps organizations to avoid that. They spend their important resources on building internal tooling.

All right. Well, it's always tempting for folks to do with themselves. But the reality is it's probably better to use tools that are created by somebody else has times get more challenging.

Hey Andre. Thanks for being on the show. Thank you so much.

All right back to you guys in the studio.