Welcome to What's Your (R)angle?, a podcast by Rangle that explores thoughts, ideas, and perspectives on the digital transformation space. Each episode will provide you with some key considerations for mapping your digital first strategy and our wrangle on how we look at challenges presented. Join the conversation by using the hashtag ask wrangle on Twitter or by emailing us at podcast@rangle.io.

Hello and welcome to What's Your (R)angle? I'm your host, Jennifer Shannon. And this season on the podcast we're talking about the core components of digital transformation and helping to demystify some of these innovation framework tools. On today's episode, we're looking at cloud native architecture, what it is, how it works, and what are the benefits of leveraging this platform to accelerate your digital transformation. With me today, are our two in house experts, Ditmar Haist and Suhanniyah Carpenter, welcome.

You're getting rid of your bare metal, you're reducing the administration costs, but you're not really unleashing the value you can get with a cloud native architecture. The key I think is the architecture of the system. It's using the value added native services that the cloud providers provide because they take care of the maintenance, they take care of the scaling, they take care of all that cost for us. Rather than us having our own teams managing that, and it gets ever more increasingly difficult to manage that on your own because of scalability needs. Because of the responsiveness and resilience you need in today's marketplace, you can't really afford to do that on your own. So the cloud native architecture is really the way of unpacking that and bringing that forward. I think the other big misunderstanding is people go, "Oh man, I've got all this infrastructure, I've got all these teams.

You know, how do you get started in something like this?" It's intimidating. You start small and you can literally start really, really small, right? And continue to work with your existing systems, your monolith, your big systems like SAP, Hybris, Adobe, AEM. So in a nutshell, it's a way of architecting new systems. So when we talked about cloud native, it's about starting small. It's about full stack cross functional teams, which is something that we do here all the time. However, you're starting to have the blend of the architecture in that team, right? Because now the infrastructure that used to be provisioned by people has an API. It can be provisioned by a cross functional team of developers, data analysts, scrum masters and product managers.

They are now empowered to build their own architecture and that gives you unbelievable scalability and response time because when the team is responsible from beginning to end, they can accomplish incredible things. It also gets you out of that big, we've got one giant thing, we deploy that one giant thing. You've got that sliver. You can deploy that on your own. And we can actually talk with the complexities of managing that because it brings new paradigms to the table. You get huge advantages but there's other things you have to consider.

So you only push performance limits to a certain extent. If you contrast that to cloud native, if you've done everything with the key architectures, you can now provision your own instance of production, 100% immutable copy of production, four chest, the load test, right? Then you can perform that load test, scale it up, it's elastic, you know, so it will already extend and expand to meet that demand. It's cost effective. You provision it for that one use and then you de-provision it. You dispose of the architecture, you only pay for what you're using. You have high confidence when you're done. Now the trick is people think, okay, well that's a good benefit. It compounds, right? So let's say two weeks before Black Friday, there's been a lot of code changes in the legacy environment. Oh do you want to run that expensive test? So close to Black Friday? You've probably locked down the environment. With the other one, provision it, run through the tests with all the changes, pass, we're confident we're ready to go for Black Friday. So these things have a scaling effect. The more you do them, you will where you realize the power that you get.

So now you can suddenly start to build that functionality in the cloud native environment and you can start to move fast on that important need and slowly move more elements out. Martin Fowler came up with a strangler pattern, which is just exactly that. It's named after an Australian vine that kind of strangles the tree branch it's growing from.

So it really needs to start with the shift in how you're designing your cross functional teams around your domain driven design principles of a domain team takes a microservice, they're autonomous, they have that service and they can go from code to deployment all on their own.

Yeah. And that leads to a lot of tension because if my module was not touched and I didn't have any feature changes, I still have to be on call and on support. Right. And this, this kind of alleviates that and it's just the team that worked on the-

The other aspect is ultimately when you're building software solutions, you are binding into something, right? Right. And it's always a cost benefit analysis. The power and the speed you get by bringing these native services together are just incredible. Even if you look at, let's say we're going to pick Amazon, you look at their product page and now if you compare a open source solution versus the Amazon equivalent. If you run with the open source, your team is responsible for managing it, for scaling it, for work, dealing with security, all of these really difficult concerns. Whereas when you go with the cloud native, they work together, they scale together, they go across availability zones. So the question about locking is really, it depends. If you're a gigantic $50 billion bank, well yeah, then it's a big concern. You probably want to spread that workload across multiple clouds. If you're a small startup, that is the last of your concerns. Get the benefit and run. If you're in between, you have a conversation and it's the business drivers that ultimately determine that.

So that gives you ability to do data analysis and machine learning, all sorts of great things. So work with those providers, work with those solutions, integrate around them and pull the data out and centralize that and then build around it. I think in time you'll be able to make that decision. Do you stick with that? Because you have proprietary versus open source on top of it. So to get development resources to work on a proprietary solution versus an open source solution. You have a huge developer pool sharing knowledge around the globe moving this forward versus the one where you're spending for a contractor that knows that domain. So there's a lot to that. It's a very difficult question. I think it depends a lot on your business and where you're going. But if you want to be digital first, I would start to move some of that data outside so you can use it for everything else, machine learning and so forth. So I think those are some of the keys.

So now I can think about how do I build what I need to build? What services do I need? So you can leverage everything that's out there such as your message queues, event driven architecture patterns with serverless patterns that are out there that we didn't really touch on like functions as a service. AWS Lambda is commonly known for that where you're running server side, computational logic in an event driven kind of architecture where it's kind of a stateless container that's running your code, but it doesn't need to be running all the time. You just spin it up as you need it. So you're also saving on computational kind of hardware at a time that needs to be there to constantly run your application that's not there anymore. Just spins up when you need it. It does the work for you, it gives you your output and you move along.

So there's a lot out there that you can leverage to solve your problem. But what's key is knowing where it falls short. So whenever you have something like this where it's a distributed architecture, latency and eventual consistency are key players in that. So knowing where your hardware or sorry, your solution fall short is important to how you design your architecture. So knowing your use cases upfront, does my use case allow me to have this latency? Is it okay for me to process this data behind the scenes or does the user need feedback right away? Right? So knowing all these things up front, will let you know which services are actually available for you and which ones you kind of have to pass on.

Because conceivably you're leveraging technology that exists now that is already sort of like plug and play. Right or wrong?

Before it was just, okay, we know we need events, so we have this piece of code that works on events. We know we need a queue, this piece of code, but now we're refining each and every one of them and says, okay, if this is the your use case, then you need to use x and if this is your use case, you need to use y. It's getting more refined and I feel like we're just going to get more and more efficiency out of this but we're also going to understand that there might be drawbacks to it. And I think we need to be very careful with like the new shiny technology that's out there. Understanding its drawbacks and architecting that into our solution is going to be very important.

You need to start small. So you need to start early and start experimenting with the technology. Find out what works for your company, find a partner that can do this work for you and kind of train your staff up. There's ways to get started. I think delaying the start is going to be the critical path in your business. So I think fundamentally, even though there's a lot of technical depth here, it comes down to business decisions and making them at the right time. Earlier on, maybe it wasn't mature enough, it's hitting that maturity level that now is the right time to get into it. So I think that's the key for this space.

But that gives your company the ability to move forward. People lose resources all the time and that knowledge doesn't just disappear. It's all in the source code itself. So there's big impacts like when you look at these decisions, that's what I said. It's about starting. You have to weight all this as an organization to say, does it make sense? And we're thinking at this point is a very good time to make that shift.

Thanks for listening to What's Your (R)angle? We hope you found some moments that made you think, taught you something new or sparked a conversation. Follow us on iTunes and Spotify to get notifications for all future episodes. We'd love to hear your thoughts on what we discuss each week and hear your point of view on the topics. So be sure to let us know what your (R)angle is, by using the hashtag askrangle on Twitter or by emailing us at podcast@rangle.io.