BMK Lakshminarayanan & Neil Cresswell – Cloud-Native Challenges in Traditional Enterprises

Hello all and Welcome to Cloud native Days by Textron group on B. Both are excited to be here with you sharing our experiences and perspectives on cloud native challenges in traditional Enterprise. Of course.

Yes, you did hear the correctly because cloudnative similar to Agile methodologies develops and brought a lot of challenges for traditional organization when I mean traditional organization organization who are exist in the market for a while. It could be a government agency a bank or maybe a financial organization. It could be anybody like a retail e-commerce you name it and everybody is trying to come to this journey and the party of cloud native.

So what we do and Waters of a driver what challenges we have in this space from a traditional Enterprise point of view. That's what we are going to share. The primary driver for adopting agile methodologies devops microservices containerization Cloud adoption is to provide value to our end users and customers.

And of course, you know the Speed and Agility matters for us time to Market is critical for business to stay ahead of competition retaining existing customers and onboard new ones in recent years. We are seeing a rapid technological changes and entry for new products tools practices architectural pattern modern engineering for solving various problems that we have in front of us. Continuous integration and country is delivery have accelerated business processes reduced operation costs and Amplified return on investments.

The Enterprise agility is the new mantra for Enterprises if they want to shake up the entire Market landscape effect substantially and cultural change Embrace new ways of working align the goals with various business units departments teams to achieve the design outcomes. So with that and let us kick it on. This is our Cloud native day with text on group and I'm with you.

My name is bmk Lakshmi Narayan and I'm a values team architect. I'm also a cncf Ambassador and devops and student continuous delivery Ambassador for New Zealand. My passion is devops Valley Stream and developer experience and community over to you.

I think you my name is Neil Criswell. io. I'm a longtime technologist consultant engineer entrepreneur and I like to make hard things simple through technology.

Okay, so this brings us to the unique core presenting opportunity for Neil and for me I am an developer engineer spend some time on operations. I'm an architect now and Neil also has been been in the end user Community for a while and now he's supportiner and see your portion. So he's going to bring the perspective from a leadership point of view and I'm going to bring it from the engineering and architecture point of view and agenda for the today the traditional Enterprise Cloud native Journey or challenges from day Zero to day one.

So Neil what we mean by day Zero today one two Well that day Zero is when you're just considering embracing or adopting Cloud native takes so this could either be from a Bottoms Up standpoint. We are a developer has been assigned a challenge to get a new application Live and they need to try and figure out how we're going to do this having an integrated into our stack. How's it going to be supported or top down where you have an executive or an Enterprise architect saying we want to move to a cloud native first architecture.

How will we do this? So it's it's more around the the Enterprise planning for the adoption of the Technologies not actually deploying anything at the stage. Yes through the day one day to Absolutely.

So that's spot on because Cloud native is not actually a destination Cloud native is actually a journey. So it is a continuous Journey where you start from your strategic alignment how you align your organizational goals and why you want to you know, embrace the the cloud native architecture and modern engineering practices and day one about your bill and day to about your operational. The one thing to share though having Cloud native architecture for apps gives the business the ultimate flexibility for scale cost optimization and always unavailability the code badly in codecraft from the book called Cloud for CEOs.

It is ultimately A great asset for anybody from a leadership point of view to understand why your organization needs to take upon a journey on cloud native architecture and let us be clear. We are not just talking about Cloud. We are not talking about Cloud native architecture, which is more to do with architecture and also engineering.

So Neil over to you about the Strategic alignment, what risk are we solving and what business drivers involved for us from a strategic alignment point of view? And there's actually a couple of things right? So so Cloud native brings about a lot of differing value statements from traditional monolithic applications, right?

So it's it's far easier to to bring new services to markets when they're they're microservices. It's it's substantially easier to do things like like MVP and ongoing iteration and and service quality improvement. It's far far cheaper to bring these type of services to Market potentially because the because of patency gain, so there's there's a lot of business value of why you at Wade Embrace Cloud native Tech really underpinned by microservices.

And so yeah really early on it's like, okay. So if we're going to embrace this technology stack, it's quite monumentally different from a virtual machine or an infrastructure traditional infrastructure standpoint. So if we're going to embrace it how will the it organization embrace it as a whole Having having just one or two people.

Be responsible for bringing Cloud native into the business is a terrible idea. You have to make an overarching decision to say we we as an IT organization are going to go all and on cloud native and we're going to bring a whole bunch of people up to speed with the technology. We're going to be aware of all the tools that we need to change.

We're going to be aware of our internal processes that need to change. We we have to go into it Eyes Wide Open knowing what's going to change and knowing knowing the benefits that we're going to get when we undertake those changes, but going into this Tech thinking we'll just throw it in because we've heard about kubernetes and containers and we want to just put the stuff in that's just destined to fail. So how do you do it?

Right and I think that the main the main question as well When you have this highly Dynamic environment. Are you going to be able to embrace it such that the business will be able to launch a lot of of new Digital Services either internal facing or external facing but launch a whole bunch of new Digital Services. That are there to kind of cast the net-wide so go out and and deliver a whole bunch of services to Market or internal and saying okay, which of these services offer us the most value iterate on those killer rest.

So it's a real enabler of fail fast development or fail fast Servicing. And and basically saying that we're gonna go all and embrace the stick. I think that's a great hint about what leadership need to think about the cloud native architecture because sometimes the organization leadership thinks that just buying a kubernetes platform make some Cloud native and then make some super awesome, but that's not the case be very of lot of things because if you have seen in the traditional Enterprises most of the Legacy application their it Investments always start from the top down approach so they go and buy a tool they bring something to the to the party and then the engineering team and the operational team started looking after it out building it or carrying for it.

Right? But whereas like the more and more the cloud native that we approach a lot of things is coming up from the bottom up, you know, because the engineers they are doing a lot of innovation work they are doing a proof of concept there and are playing and experimenting with this kind of a modern tools and open source tools. So be very of this bottom of production of this technology as it has an IT budget implications from the leadership point of view, but the same time you need to put your organization in In a place where it can respond to the market changes and keep your head off your competition and help using this technology to deliver value as soon as possible for your customer, but the same time securely and safely for your customer.

Now for the Strategic alignment point of view the challenges that we often see from our prospective is that do be asked the good questions. How can we leverage This Cloud native architecture to get the application to Market faster, but with the list risk, you ask questions like number one. How do we see this helps in delivering value for our customers?

Number two what business drivers behind this for us number? Three do we see Cloud native as a destination or as a journey because this is an important distinction for this and number four who is making the right decision. Okay, so somebody has to make decision about this.

There is no meaning in saying buying a kubernetes platform on calling that we are Cloud native, but you need to also address the other aspects of your architecture. Eating an operational things. So the recommendations from us ask quality questions.

And also understand how it is going to help you shift your focus not just from one tool one platform, but help you to look at the holistic perspective that is organization today. How you want to serve your customer what you need to give the business the agility it needs and the flexibility that it needs. Now.

The day Zero is all about strategy alignment now date one is an interesting fun for us, right? It comes to architecture Bill and Engineering so Neil, what do you see is a challenge for the the traditional Architects and Engineers that comes to embracing Cloud native architecture engineering practices. Yeah, I think that there's still a lot of confusion in the Delta between a traditional virtual machine infrastructure and a cloud native platform now, yeah cloud cloud native is an overall philosophy.

It's it's not it's not a tool. It isn't it isn't something you can just buy it's it's an overall philosophy of principle that you have to adopt and there's there's definitely still confusion from an architectural standpoint around how do I best architect my application landscape to run on a cloud native platform. And the reason being is, you know, platforms quite different, right?

They they are designed to fail as opposed to more Legacy infrastructure solutions that are designed not to fail or any of the fail and you have things like like high availability and other capabilities and the platform. So you replication can handle system failures. Whereas Cloud native.

There's no such thing the platform will shoot misbehaving containers or Pods at will and your application has to be able Like that. So from an articial standpoint, it's like how do I take? No, how do I change my thinking from a platform that should be delivering 100% availability to a platform that is really just developing maybe 50% availability, but I need I need to give the additional 50% in my app stack.

How do I do that? And that that's more of a challenge if you're trying to move a legacy monolith into Cloud native as opposed to designing something brand new or adopting something brand new, but still that that's still really the biggest challenge. The next thing is from outside of the architecture.

Of the application the architecture of the platform and that there are so many changes in regards to the platform. How do you how do you go about designing the platforms specification how you're going to handle all of the the traditional mechanics that that infrastructure operations team need to operate and deliver SLA to the business. How will you handle this stuff?

So there's these these two Dimensions. So either way It should not be accidental design and built there. Should there should be for thought in regards to?

How am I good? How am I going to design a build my app? How am I gonna design build the platform and more importantly for day day two how well how will we operate the platform?

Exactly. So Cloud native brings actually a new paradigm shift to everything from architecture design build test and validate deploy and operate the problems that we see in the space is actually people think that they could run a monolith which runs on a virtual Mission assets on containers and Cloud, which is actually in a funny thing when I talk to, you know, the other Architects and Engineers with that and buying a cloud or container orchestration platform. Does it solve or problems and issues are create further kios for us right just buying a products that on containers example, like, you know, when we were interacting you were talking about buying a Core Business application which runs on a Content a platform, you know, you never know what complexity that you're buying into and you know, you're investments in the space right and be able to talk about that one.

Like you know how it helps you from the platform perspective. Yeah, I mean when you obviously with with a platform there are there are a bunch of things. You have to consider, right?

So say that the logging and the monitoring the observability to think of a more macro Cloud native term. And and all the security and so when you're when you're looking to adopt an application if you don't have any prior experience in Cloud native. You really will struggle to bridge that Gap.

And so one of the things that I see quite often is organizations are coming coming into Cloud native with a new systems view. So they're saying we're going to put all of our existing systems in a car park. It's going to sit over there and we're gonna we're gonna change trees them and lock them all new innovation is going to happen in a cloud native world and it's going to sit over here and they really just put this wall between there too systems and that's well and good and what we see when that happens is you end up with with fundamentally two it teams.

You've got the IT team managing the old and you've got an IT managing than you so that's quite a cost increment and again exit into architecture, you know be very careful and less unless you are They are going into this thing knowing that you're going to build a Shadow or a secondary it team to manage this platform. Then then you've got these costs that you didn't the next didn't anticipate. So that's why I'm more of a fan of all you should look at this thing in more macro level and say well actually, how can we migrate some of our Legacy systems into this thing?

How can we bring the entire team up to speed so that you don't have to have a second team dedicated to manager. Exactly. So device in containers strategy and Cloud native.

We thought evaluating our current state example, like what kind of tools what kind of practices that we have our capabilities and schools. It's it's like of no use so our Solutions and recommendations in the space invest on your people upskilled them because you are entering the new territory where the people learning curves very steep number two, understanding our current state of architecture and plan. What is our targets to architecture and what and keep the cloud native in mind and what it actually brings to our our game number three investing on right tools because just buying an investing at Cloud native your orchestration platform doesn't solve your problem.

You need to also invest on other capabilities in your organization as Neil touched upon monitoring. Testing capabilities devops tools automation all this matters maturing our technical practices unlikely devoting to more modern ways of operating example, like your devops and cacd. It's actually fundamental tenants of going to Cloud native and finally monolith to microservices.

Please do not just think about application but also think about your databases also think about the the network and latency related to that. Like is it a microseconds to milliseconds, you know in Nils own word. Now this brings to an important thing, which actually I bumped into this court by our good friend Kelsey height over give a man a container.

You keep him busy for a day and teach a man kubernetes and you keep him busy for the lifetime, which is absolutely right. But if you don't teach your organization about this kind of a modern tools and Cloud native architecture and you know, the the practice is an opposition platform. You keep everyone in your organization busy in solving technical problems, not delivering the business value that you want to What you want to offer and this takes us to the third pillar of this talk, which is actually more around operational challenges.

So Neil, what do you see the distributed architecture brings challenges to the traditional Enterprises? You almost most Legacy Enterprises have an investment in what I would consider more traditional monitoring tools management tools alike. So they've they've they've got they've got their negios or other other types of solutions and they've got really really yeah dialed in processes and tooling to manage virtual infrastructure.

The original infrastructure has been with us now for I don't know 20 years, maybe 15 15 years. It seems like forever and we went through multiple multiple life a life cycle iterations with virtual machines and we got very very good at deploying and managing virtualized infrastructure. Very good.

The tools got incredibly incredibly short mature and so as a large it organization delivering virtual machines as a service for internal business units is excellent. Excellent SLA, excellent everything. And so the business expectations are very very high from that.

And so when you're when you're transitioning to a new Cloud native, most of the tooling is still not as mature because it's simply haven't had long enough. It's not it's not as mature yet. And so you end up having to do a lot of custom integration and you have you have to buy new tooling to deliver similar levels of service that you had with virtual infrastructure.

But one thing is certain you can't take your legacy virtual infrastructure management tool sets and apply them to Cloud native. They're just different things and they need managing in a different way. Exactly.

So the problems and challenges that we see in this space from an architectural engineering point of view distributed systems are hard. No, we can bootstrap something so quickly on cloud, but it's really going to take time and investment to understand how these things are working and I often say that if managing monoliths running few hundreds of systems to keep the lights on for your business is is hard imagine running thousands of containers and distributed architecture microservices, and it's going to create you know at your complexity. So the challenge that we see number one using existing tools and attempting to manage highly Dynamic Cloud native workloads.

It's going to be really really challenged for your organization. Number two. What are you monitoring and measuring or you're measuring performance memory CPU storage?

So you need to change your mindset from traditional Enterprise monitoring aspects of your physical work, I mean physical missions or virtual missions to a container world. So what are you listen is what are yourselves? And how what is that you need to know about it and number three how good our systems are designed to be observable because traditionally the systems that we built in the past like, you know for 10 years before they are not observable in nature and as more and more we Embrace This Cloud native architecture and engineering and we need to be aware of that.

We need our system to be more observable because your systems are designed for failures and the design to self heal and come up if something goes wrong in a traditional world like your virtual machine you take Time down for 30 minutes and you switch from one mission to another mission example, like you are active data center to a secondary data center. So you will have a down kind of 30 minutes but container will things are still feeling they come up on their own. So how do you manage this from an architecture and also from an operational perspective so Neil, I want you to touch on some of the other challenges of operational in challenges in the container and Cloud native world.

Yeah, so there's this a couple of things here, right? So there's the platform challenges and application challenges and I'll start with a platform challenges first because the relatively easy to go through so once once you're actually built yourself a platform and let's let's just use kubernetes as a standard for that. Now again, as we said at the start kubernetes is not a platform.

There's a bunch of stuff needed around it. But let's just use it as a standard so you actually build your kubernetes platform. How are you going to manage it?

So there are there are CVS, you know released all the time for kubernetes and because of that the product is is being life-cycled at a relatively quick release quickly release Cadence, which means that you also need to keep that same Cadence up in your infrastructure. So how would you update the platform? Would you update the platform, you know, there's also a question.

Also, there are a lot of moving Parts underneath kubernetes things like like Coop DNS and all of the underlying Etsy system that that controls or the state across across the platform. How are you triage that when when things go wrong? And I've also seen and I often recommend considering your platform as a single use or throw away system.

So you actually deploy a cluster you deploy your application into that cluster, but you actually leave it alone should something go wrong with that cluster or you want you want to upgrade it because you should have automation for your applications and I'll talk about that in a minute because you should have automation. Then you should not need it necessarily to update the platform. You should be able to deploy a brand new cluster with the latest versions and and any issues result and redeploy your application update your load balancer and fail across and you have this constant cycle of Simply replacing your clusters.

So it's the whole, you know, pets versus Kettle discussion that was around your virtual machines. Do you treat your virtual machines and containers versus cattle will the same thing happens with with the underlying, you know cluster as well. Should you consider upgrading it or not throttle right away and replace it.

But then it comes to things like sla's and Olas the operational level agreements. So how are you going to ensure that you have adequate storage performance? And this is this is one of things that I see trips up a lot of newcomers quite quickly.

Yeah in a virtual machine world. We became very very good at calculating iops and throughput and designing a storage subsystem that would deliver. Yeah awesome levels of performance for the Oracle database or SQL database or whatever else and then when we've moved into Cloud native World, we've seemingly forgotten how to do that or forgotten the need to do that and quite often.

You just see people deploying staple services against some backend storage driver and it's just not delivering the right levels of performance that the database needs for highly transitional workloads again oltp workloads versus not So, how are you going to monitor and and ensure acceptable levels of storage performance. How will you handle CPU contention? Again, drinking a virtual machines had very nice constraints that you could apply to ensure that CPU contention was minimized how you're going to handle memory pressure how you're going to stop Noisy Neighbor.

We want application can impact another. Hey gonna do that. So you got to have the right kind of tooling to to ensure this can happen and the tooling lets you set policies in the underlying platform to to ensure, you know, fair share of resource, but also to monitor breaches of Security is another big thing here products, like kubernetes are not secured by default.

They expect you to go and apply security policy to them. And in this you don't know how to it that means you know how to do that. Sorry.

Then quite often you are deploying systems that are insecure and that's dangerous if you have Services exposed to the internet, and we I think we just saw a survey. There are some 100,000 kubernetes clusters exposed to the internet in an insecure manner. So don't don't be one of those kind of victims.

Make sure you understand how to secure your your underlying platforms as policies and controls and Audits and everything. and so then we moved to application challenges and you'll are we just going to the use stateless Services inside our Cloud native so things that simply transacting data through to a back end state will store that has held somewhere else. So like a database service that's in some some Cloud database managed service or are we actually going to try and move our mission critical database workloads into Cloud native framework as well.

Are we going to do that? And and if we if we are how we gonna how are we going to handle these? And I often say people asking questions.

How do I back up my containers? Well, he you don't there if it's a container probably at stateless probably it's defined by code. And so you should be able to recover.

The the actual runtime state of that application from code. You shouldn't need to backup a container you back up the config for or how to spin up the container a yaml or a Helm chart or something else. That's probably held on to get repo.

So you back up that you you need to back up any any persistent storage if you're deploying state for labs, but the containers themselves. Nope. Drbcp, you know we've gone from active passive data centers to active active self-healing environments where a an application runs on nodes in a cluster.

Should that fail its instantaneously? -spun up somewhere else in the cluster or if you have multiple clusters or model pool multiple regions. You can actually automatically balance your load across it so you have to make sure that your application.

Can support active active workloads as well? Again, we've said but sit on the past, you can't use traditional monitoring tools and a cloud native World it breaks. So you have to say well, how am I going to have tools that can handle the highly Dynamic nature of a cloud data platform the fact that your workload is running on a node right now link three times a certain node blink.

Again. It's another note. It's moving around dynamically be yeah because of of the nature of load balancing that's native to this platform.

Have you going to handle that? You can't just pick up any application and put it in a containers. You have to make sure you've got isv support.

So, you know, you don't have the luxury of just saying. Oh, I'm just gonna pick up my model and put in a container. Okay, cool.

How do you get support for that? And again as we've said in the past this this kind of platform is designed to fail. It's expected to fail.

And so how how we deal with that if your organization is still has cardboards the the change advisory boards and every single change has to go through a board. Mmm. You're gonna you gonna begin for a bit of a shock when you look at this new Cloud native world.

So the whole Cloud native word is highly Dynamic. It doesn't doesn't hear to to change advisory boards and change Windows. It just it just changes when it needs to itself.

That's that's what it's designed to do. So need to make sure that you've got you've got agreements or tolerances in place to say this platform is self-healing self managing. And then how how you prevent outages through through better better load balancing of application.

So these are the type of operational challenges. And again, this is because a cloud native infrastructure is quite different from a legacy virtual infrastructure and you can't accidentally assemble one or you shouldn't you have to go into this into this world with these operational challenges and mind make sure you've got the right tool sets the right mindsets and and careful consideration for all of these complexities addressed in tooling and process. Exactly.

I think that that's the reason why the day two is always longer than day one so friends. This is the reason why in a real traditional Enterprises, we start seeing challenges and shift in the momentum. Like, you know, there is no just an application architect who just thinks about application and infrastructure architecture two things just to put infrastructure.

So we see that common it's emerging like, you know, it's there's no longer an eye-shaped engineer or a t-shape engineer. Now, it's all e-shaped engineer. So by the engineers, they have a fair amount of understanding about the complexity the infrastructure the operational requirements.

And what does it mean for Designing application for our distributor architecture on a cloud native wall. And with that we would like to leave you with one thought the most critical metric is how long it takes for Innovative idea to reach your customer. So regardless of what you're doing like it's a traditional your modern stack your your container World your Cloud world and whatever.

You're doing you're helping the business for their agility. And with the note my friends. Thank you very much for the opportunity and me and Neil would like to thank you take strong group for providing the great platform for us to come together learn together and grow together Cloud native challenges and traditional Enterprises our topic and my name is bmk.

Thank you.