Why Cloud Native is the New Standard

A few years ago, cloud native was viewed by many as a buzzword or just a developing trend. Today, it has become the standard for companies seeking to boost team efficiency and reduce costs. To fully realize its benefits, a comprehensive understanding of both its capabilities and costs is essential. AWS and Microsoft are two big players on the market and Tibi Covaci, from Microsoft Azure, and Eric Johnson from AWS Serverless, are advocating for cloud native as a default characteristic of any organization, no matter its size.

Intro

Eric Johnson: Hi, I'm Eric Johnson. I'm from AWS Cloud, and this is...

Tibi Covaci: Tibi Covaci and I'm from Azure.

Eric Johnson: Wow. In the same room. We're pretty excited. We're here at GOTO Aarhus, did I say that right? This is "GOTO Unscripted" and we're gonna chat cloud.

Tibi Covaci: Yes. We're gonna talk about the cloud.

Eric Johnson: Yes. What's your role at Azure?

Tibi Covaci: So my role is application innovation lead. So that means I'm helping customers to innovate our applications. And one of the things that it's indispensable in your innovation journey is the cloud. So that's what I'm trying to convince them about the need for the cloud. And, you know, trying to understand what my role actually was, I started to look around and see what actually up innovation is. And I can find, you know, many definitions, which makes it a little bit difficult for people to know what is all about. And I say, oh, you need to use DevOps. You need to talk about doing cloud-native things. That's how your innovation journey would be much better. And I tend to agree with that. But then you start to dissect that and look into details. Cloud Native, if you look for the definition, you get hundreds of them.

Eric Johnson: Yes. You do.

Tibi Covaci: Again, what does it mean? For DevOps again you have 100 people, and 110 definitions of DevOps. So that makes it interesting and challenging at the same time, I would say.

Eric Johnson: So it sounds like you have the same challenge I do in that, well, I mean, you asked my wife what I do. What is his role? I don't know.

Tibi Covaci: Yes. Exactly.

Eric Johnson: I'm not sure what he does. He travels, he speaks, he goes to a lot of whatever. But I agree with you. My role I'm a developer advocate for serverless at AWS. But before that, I spent a lot of time with a partner company as a solutions architect and spend a lot of time doing what you're talking about in understanding or helping customers understand why the cloud, and understanding the advantage of just starting with the cloud itself and then climbing into cloud native. Yeah. I do like what you say because I say the same thing. If you put 100 people in a room, you'll get, for serverless specifically, you'll get 110 definitions because someone will go, oh, I like that. I'm changing mine.

Tibi Covaci: Exactly.

What is cloud native?

Eric Johnson: All right, so let's put you on the spot. How do you define cloud-native?

Tibi Covaci: So cloud native is actually not only moving your stuff into the cloud because that's not native at all. A lot of customers are doing say, yeah, you know what? We did lift and shift to allowing the cloud, so we are a 100% cloud company. I'm like are you really? Like, are you? So cloud native is actually using the bare bones of the cloud, whatever the cloud has to offer. And that includes the serverless part. But that includes as well, like if you need a messaging infrastructure, why would you do it yourself?

If you need logging, why would you do it yourself? If you need identity and security, why would you do it yourself? I mean, of course, if you have a thousand people working for you with developing that and making sure you do the right thing, that makes perfect sense. But when you have not so many, but few companies that are hiring 1,000 people, literally more than that, even to actually do those things and making sure they're doing a very good job, then I think, you know, you are better off starting to look into the cloud native. What are the cloud services that are already there? And I'm not talking, oh, yeah. I can put the virtual machine that's a cloud service indeed.

Eric Johnson: But it's not.

Tibi Covaci: But it's not, it's not what it's all about like storage. Do I really wanna go and map it to a discourse? Should I understand an S3 bucket or an Azure storage? What do I want? What is...

Eric Johnson: Well done by the way.

Tibi Covaci: Yes. What am I trying to do? That's the whole thing.

Eric Johnson: I love that. I've had that same conversation many times in that it's a, you know, you lived here earlier, it's like, all right, I've lifted and shifted. I have, you know, 300 C2 instances or Azure, you know, I do not know the Azure name for it. And so it should be free, right? We should see massive cost savings. We see, no, no, no. Giving the cloud, you take, you know, the low-hanging fruits are things like, you know, the scalability. And as an essay, I spent a lot of time saying, don't stop at the lift and shift. You might see some advantage running it, but not a great advantage. You're still up at night when something goes down. You're still managing databases, things like that. So I agree with you. Cloud-native is really the use of...and this may be too broad a stroke, but it's almost, it's the use of services over you coding for it.

Tibi Covaci: Yes, exactly.

Recommended talk: Cloud Native Progressive Delivery • Matt Turner • GOTO 2022

Eric Johnson: We pay developers a lot of money to reinvent the wheel. And I really encourage folks to get away from that. At AWS I know, especially in service to… are you writing your own authentication? Why? And secondly, that's scary. We have experts underneath that answer the same way, experts who are working with identity and access management and building that and testing it and hardening it, and really, it makes more sense to take advantage of those services and really turn your developers' attention to what differentiates you from your neighbor, you know.

Tibi Covaci: Exactly. And I think that's, that's the problem because we as developers sometimes tend to forget what is it the business value that we are trying to bring. And it's not only the developer's fault, I would say, you know, but sometimes it's our fault too as developers, but, you know, the business does treat us like we are a commodity, I think, and we are. We are the guys in the basement. But now they start to realize, actually those are the guys that keep the lights on. Those are the guys who, not only make sure that we have a computer to run with our applications, our business systems are working and they're up and running. So more and more depend on technology and more and more companies are actually realizing that this is not a joke anymore.

And if you look out there, every company out there wants to be a software company. I would say Amazon was opening the door for that because everybody uses Amazon as an example. Oh, they used to be a book company, and now look, they are the biggest, the biggest cloud provider. Why is that? Because they saw a need for something and they start to use that. They had people with visions that made it possible. That's why I think the cloud is a very important aspect of any innovation journey. And again, looking into cloud-native that…

Cost of ownership vs the cloud

Eric Johnson: Yes. I don't disagree. I really struggle with the, well, we do our own data center. We know better. And there are people just gonna shock you. There are people smarter than me out in the world. But I think it's always interesting to me that where it makes more sense and I hate saying this word but I'm gonna say it anyways, that total cost of ownership and you really struggle to get people to understand how much time are you spending managing your data center, building data centers, patching, power building, know all those things? When you can roll all that off to an Azure, to a GCP, to an AWS.

Tibi Covaci: Yes. But it's a different call center. That's the thing. For them, their IT cost is how much do we pay for the machines? Now, we rent them for three years or lease them for three years. We have them, we can use them. And that's it. And that's the end of the story. But is it really? Because you have the people, you need to think about the insurance of the building, you need to...

Eric Johnson: The applications, the machines.

Tibi Covaci: Energy bill, all those things. Like now more and more people are talking about sustainability. Are you really having people on your payroll that do the sustainability journey on your data center?

Eric Johnson: That's right.

Tibi Covaci: Are you sure that you are actually using renewable energy? I mean, I don't know what stories about that at AWS, but at Microsoft, we can at least show you exactly where the energy comes from. We started to do that because we see people like, oh, we have accountability when it comes to sustainability. So how can we account for that kind of thing? And that makes it very, you know very interesting for a lot of people. And looking at the way, you know, things are shifting because now with the cloud, everything becomes OpEx or most of it is not the CapEx anymore.

You don't have to have capital expenditure, you pay for what you use. And what you say, yeah. You move it to Azure. Azure and then, or to AWS. And then you are in the cloud and then you've done it, not really, but there are some advantages as well. I can look at how much I spend. I can optimize. I can have my operations optimized as well. If I'm using a machine only 5% of the time, or 10% of, you know, their resources we are moving down. Yeah. But you don't have that on your own data center...

Eric Johnson: When you go CapEx, like I haven't used CapEx in a while because I worked in serverless, right? So it's one CapEx, but when you're CapEx, you're in. You can't go back to the bank and go, I'm or the vendor, I'm not using 50% of this. I'd like 50%, do you know, whereas every month, even when you're doing, VMs it's okay, let's reduce that. There's an adjustability that's built in there. But then when you go the cloud native and you go serverless and y'all are the same way, then you get into only pay for what you use. And I love watching the light go on. But you go, wait a minute, wait a minute because, of course, there are servers and serverless.

I always, what do you mean there's no server? No, we're running it on my mom's microwave. Yes. There are servers and serverless, but you don't pay for them. You don't use them. And the same with the services like storage, Azure storage, and the S3 just what you use. But S3 was one of the first to do this. To come out with the idea of object storage versus, you said earlier destorage. I have to provision 20 gigs or a petabyte or whatever. Versus I have seven gigs, 7.2 gigs, that's all I'm gonna pay for. Oh, someone one away. That's what I'm gonna pay for. What a difference in how you look at that.

Tibi Covaci: I think one of the biggest problems is that serverless season is no more. Because like you said, it's not that there is no server, I would call it a server…

Recommended talk: Expert talk: Cloud Native & Serverless • Matt Turner & Eric Johnson • GOTO 2022 

Eric Johnson: You stop talking.

Tibi Covaci: Exactly. I would say server, I couldn't care less, you know about the server.

Eric Johnson: That's right. That doesn't fit on the card.

Tibi Covaci: No. Exactly. It's much shorter and feels more...

Eric Johnson: Serverless. Yeah, exactly.

Tibi Covaci: But one of the things that serverless actually does is like, okay, what's your code? Do you really care about the machine? As a developer, you care about the laptop, you care about the machine. We used to call them server huggers, you know, like people that really want to embrace the servers and the machines. But think about it now if I have a piece of code and I don't really need to worry about it, as a developer, I usually send it to operation and they put it on their own machines. I still don't care about the server. I know there is a server there. Why would I not abstract that away?

Understanding serverless

Eric Johnson: That's the question I have. I think a lot of it is just awareness and understanding. When you get into cloud-native you talk about understanding how, and for us also, we've started building out these different services, like a step function or, you know, where it's now we're even saying, let's reduce the code and move to configuration. So I can do some things in the configuration that are automatically gonna, and where this really becomes beneficial is I can say, okay, it's gonna handle my error handling, it's gonna handle my retry, all those things. And I'm not writing a line of code, and developers are going, oh, hold on.

But when they kind of get that, you know, now it's not just, just code. You worry about the service, now it's only the time I have custom logic. Now I can start farming even lines of code off to services. And that's really service full is almost, I dunno if it's a better name, but it's another name for serverless, you know.

Tibi Covaci: If you look at Doppler that, you know, which is actually the sidecar for, you know, for Kubernetes clusters. Right.

Eric Johnson: Sidecar, love that name.

Tibi Covaci: Yes. You can actually pull it in there and you make sure that if you have service-to-service communication, I don't have to remember where you are. I just register that and I put another head on my call and then, you know, Doppler takes care of that retry logic. No problem, we got you covered. Why would I put the wild loop and try and leave the configuration from here and there and just do it?

Did we say three times or five times? Or did we say five minutes? What did we say? So that's the whole thing. And even looking at databases, for instance, talking about several serverless databases. A lot of people are like, how does it work? Simple. A database, at the end of the day, it's storage plus a computing resource. And if you don't make any calls, you still use the storage, which you pay for. But you don't need to provision any computing. You might have a small instance running, so you wanna have the speed of it, and also it's already provisioned. But you have a lot of people asking, you know, submitting queries to your database or, you know, the cost to your database, then you can actually scale up. And your wallet is the limit. How much am I ready to pay for it? I put a cap on that and that's it.

Recommended talk: Thinking Serverless: From User Request to Serverless Solution • James Beswick • GOTO 2022

Eric Johnson: That's interesting, so we have DynamoDB is ours, kind of serverless. It was one of them. But that you can say, look, I'm gonna give you three, how are we doing Eric? Three reads per second, three writes per second, and we can burst that if we need to or I can cap that and say, let's 429 that if there's a problem, hey, you're out of, out of those.

And that allows me to go, okay, I can grow but I can monitor that spend and I can monitor that control. But at night when it's shut down, I'm not paying for those reads and writes. And I think I'm just repeating what you're saying, but it's getting your head around the idea because it changes the way you develop too. It changes.

One of the things we talk about a lot is moving from synchronous to asynchronous. How much can you do without the customer going, I'm waiting, I'm waiting, I'm waiting. How much can I say? All right, we've got your request, we'll get back to you versus wait, wait, wait. You know I built a translation app that we use for some of our services, some of the AIML and it was kinda interesting.

I built one synchronous where you send it a string of text and then you send it an array of cultures. You say I want to translate it to this many things. So it takes it and then synchronously, what we would do is in a Lambda function, we would call, we'd do the transaction, get back, then we'd do the next one, get it back to the new next one or you could get an array of 'em back. But it's all synchronous to customers waiting. And that's fine if the string of text is, you know, 50 characters, something like that. But what if it's the first three chapters of War and Peace? And so then it's like, okay, what's that gonna take? How long am I gonna sit?

And in Lambda functions, we have a 15-minute timeout. Yeah. That's by design you know, there are some obviously reasons for that, but the idea is hopefully you're thinking more asynchronously. So I also do an example where in this one instead, you make the request in response to the customer and say we've got your request, we're working on it. And then in parallel, I can say, okay, fire up, you know, 30 Lambdas to do it, whatever, 30, you know, whatever step functions as you well know in cloud native, it's like, how are you gonna do? It depends. There are multiple ways of doing it. I mean, that's the development way, right?

Tibi Covaci: Yes.

Eric Johnson: And then we can notify the customer. I can either pull from the client, just pulling, or more, I'll use web sockets to notify them. Then they're not waiting and it's done. Then I have some parallel processing I can use. And so that's what we talk about. You know, how are you architecting when you think about only paying for what you use, are you using it in the most efficient way? Would a batch of events make more sense than firing on every event? So, yeah. It changes how you develop.

Tibi Covaci: That's the thing, it depends, but you need to test it You need to try it. And a lot of people are saying, but you know what, when you say it depends, it's actually you are blowing me off. Actually, no, I'm not blowing you off. I don't know your problem well enough to be confident enough to tell you this is the best solution. I can give you a first solution, which you can try out, but I don't know the implications. I don't know all the corner cases and whatever we are developing, we're developing for 80% of the cases, we are not in the business of silver bullets, although a lot of people are thinking, so now if I move to the cloud, all my problems are solved? I don't think they're solved. You still have to do a lot of work, but you have a lot of solutions to your problems and you still have to make the choice.

The advantages of being cloud native

Eric Johnson: That's right. Coming back to cloud-native on that idea and services if I have to try again on, oh, we got the wrong computer, we need more scale, we need whatever, or we need to upload code. I can change my architecture in minutes. It's just a redeployment of architecture, right? And the same with y'all. So that proof of concept, is this what you wanted? No, that's not what I wanted at all. Okay. No problem. Is this what you wanted? And you can iterate so fast with cloud-native that it just makes sense.

Tibi Covaci: You can do that on your data center too. You need to create a purchase order and you need to wait for the servers. You need to put them in there and then connect them. Oh, that was the wrong server. We need more, we'll need bigger...another month of waiting. You know, so we can do that in a data center too.

Eric Johnson: You can. But it was expensive. And that's one of the things we talk a lot about is that provisioning process in the, who's building it? If Eric Johnson's building it, he's gonna get wrong the first three times minimum, so...

Tibi Covaci: You had said you don't know too much about Azure, but when Microsoft started with Azure, we had a different model of working, which was called Azure Service Model which was very transactional. And back in 2013, 2014 some smart people realized that actually, that's the wrong way of doing things, so let's move into what we call now Azure resource, you know, resource manager model. But that was one of the examples that we were starting to use back then like you can deploy a SharePoint infrastructure in less than two hours and that's the thing.

Press the button, it gets deployed. But of course, the idea is, you are still in your data center, you still wanna move things back and forth so that's how you do it and, of course, you have to deploy them. Now, I used to call all those things that we are doing now when we talk about infrastructure and that's why like, even your VM, it should be a serverless kind of thinking at the end of the day because it's a disposable infrastructure. You know, if for five years ago, or five years ago, we were bound to a certain platform, to certain machines that were already in production, running other things.

Eric Johnson: We named them after our family.

Tibi Covaci: Picking them and stuff like that. We were always dependent on the version of the framework that we were using, on the patching level of the operating system. And we couldn't do anything about it because IT was in charge. And they were controlling that. And they were having their process of making any upgrades or anything. Now, I don't care, like, oh, I have version one running in production, now I can look at version two. What changes do I need to make to the infrastructure? Let's go into the code, let's change something, commit, and then try to see if the deployment works. That's fine, no problem whatsoever. Put them side by side, and it works. Switch to that one, and well, you are done.

Eric Johnson: That right there is a key point, before side by side. I'm buying a whole copy of everything versus even, you know, in the instance world, I'm gonna spin up Blue/Green. There you go. You know, however, you wanna do it. Canary however and the same with the, you know, the cloud-native, we do the cloud native deploys, but the ability to move and I think that to me, I mean, cost obviously is huge. So it depends on who you're talking to. You know, C-level cost. But developers have the ability to move so fast. And that's important to C-level too. When I say time to market, I'm cutting time to market by hundreds, you know, that's huge.

Tibi Covaci: So I will call that time to value.

Recommended talk: Cloud Chaos & Microservices Mayhem • Holly Cummins • GOTO 2022

Eric Johnson: Time to Val... Okay. All right.

Tibi Covaci: So you know what, because marketing is one thing.

Eric Johnson. That's what I meant. Tibi, come on.

Tibi Covaci: I know, I know.

Eric Johnson: Just kidding.

Tibi Covaci: No, but that's the thing. Because once I got an idea, how long does it take for me to see value in that idea? And I mean, with the cloud, that business agility that you get makes it much, much, much better for a lot of people. That's what I really like about, you know, having access to the cloud. I used to work for a company that went up 21, or 22 years ago. We were actually one of the very first companies to offer reservations via the internet. Internet was not the thing back then.

The name of the company was Book Visit. So like, you know, very catchy. The domain is sort of available, we could buy all of them. No problem whatsoever. We got $2 million. We spent 90% of the money on infrastructure. We had servers, you know, like all of them connected, like clustered, with licenses full-blown, licenses for Azure...for Oracle databases, for some VM. Like you need it to run. And we needed to run, you know, a Java application. And the problem was that we had only about 100 queries in our database because we were still at the beginning. But because we spent some money on the servers.

Eric Johnson: No money for development.

Tibi Covaci: No money left for development for anything. So we went belly up. If Azure would've, or AWS would have been a thing back then, I could have actually done that and not spent the money on the infrastructure, but just running my application, then I would've been much happier. Not only that, running the same application with this full database on my machine, you know, which was, you know, a $2,000 laptop was much quicker because I didn't have to do all the load balancing, I didn't have to talk between machines, everything was on one machine. It was just working.

Eric Johnson: Yes. It just worked. Works on my machine.

Tibi Covaci: Exactly.

Eric Johnson: So, you know, one of the things I've always said is the cloud is a great leveler in that it allows two developers in a garage to have the same power that the enterprises have. When I had a talk earlier, one of the fun things I like to say is I always make the joke is, has anybody ever heard of amazon.com? You go, ah ha, they all raise their hand. So the same database that they used to power amazon.com, I'm using in this little coffee shop thing. And it's like, whoa, I have access to that. You do have access to it. And you're not going to probably pay the same bill that amazon.com does. You probably have a little less data, but you use what you get, but you have it and you have it today without having to spin up anything and so, yeah, it's a powerful thing.

Tibi Covaci: And all the things that you get, like, you know, if you want to email. Oh, before you had to install a whole server or go to, you know, now you just go there and pay...

Eric Johnson: 365. Yes, that's right.

Tibi Covaci: $5 a month and then you got it, you know, you have access to [crosstalk 00:23:58.283].

Eric Johnson: That's what my family runs on. Yeah.

Tibi Covaci: This makes perfect sense at the end of the day. So that's why I'm like, you know, why not tap into it?

Eric Johnson: Yes. Well, great conversation. I really appreciate it. I know people are gonna go, oh there they are, same room. Yeah, I really appreciate getting to chat with you, and getting to be here live from GOTO Aarhus. Wow, man, I just destroy, you make me sound cool when you play that back and stuff. Yeah. So Tibi, I appreciate your time.

Tibi Covaci: Likewise Eric.

Eric Johnson: It's great to meet you. With that, do you have anything you wanna throw out before we say goodbye?

Tibi Covaci: Maybe they can add some thunders here in between us when we are talking.

Eric Johnson: Exactly. Exactly. So people are gonna be, that was disappointing. There's nothing thrown there.

Tibi Covaci: Yes. Nothing like in the demo.

Eric Johnson: Yes exactly. It's a SmackDown!, but not really. So bottom line, get cloud, people.

Tibi Covaci: Yes. Go to the cloud. Yes.

Eric Johnson: That's right. All right, well, we'll say goodbye and thanks.

Tibi Covaci: And thank you.

Eric Johnson: See you next time.

Tibi Covaci: Bye.