Keynote by Magnus Martensson at Software Architecture Conference 2023

Okay, it is brilliant. Brilliant to be back and talking at the Software Architecture Conference

And as you saw that, I had to make a, I had to add that to my slide just now, that wonderful hashtag Software Architecture Conv23

So if you use that on X, you're not going to be able to send a message at all because the tag itself takes up all the space of your message

So use that to ask questions to the speakers and see if you can

snag some swag. Brilliant. So here we are. Software Architecture Conference. And who am I

Well, I'm the guy that likes to run Global Azure. I love doing community things. And I had to call

that out to give a shout out now that we have a global audience to anyone who was attending any

of these events or any who were maybe even organizing one of them somewhere around the world

It is absolutely brilliant to see all of these people organizing Global Azure every year. And I urge you to

join in if you are part of a community or near a community that likes to learn about cloud

and Azure in specifics, then please join the Global Azure Initiative. So I'm going to talk about architecture, and the disclaimer is that I talk a lot about cloud

It's just the way that I work. If somebody wakes me up in the middle of the night, I randomly start talking about cloud

I kid you not. And I've been told that that's a little weird. But that's who I am and that's how I operate

but I will say that most of what I am saying about architecture maybe pulls in the word cloud

but it just works in general anyway, so no worries. I like to talk about cloud so much that I have my own show on the Csior Corner live stream

So Simon is my tech person for those, and he takes care of me and sets everything up

so that I can run the cloud show and talk to important people like Scott Hunter

This show is targeted and share the word, spread the word. This show is targeted to be bite-sized segments that are directed to the leaders of cloud projects

Maybe you don't know enough about technology yet, or maybe it's not your job to know technology

We're going to talk about all kinds of topics on the cloud show. So I'm also a Microsoft Regional Director, which is so funky

It means that I'm a friend of Microsoft. It means that I'm hanging out with Microsoft all the time

time, which many of us do, but please bear in mind that I am not employed at Microsoft

I'm not a Microsoft person. I don't also have a region, by the way, and I don't direct anything

but a Microsoft regional director is a close confidant of Microsoft who works with Microsoft at the highest

level. So I'm kind of all over the place and doing all kinds of things. I also like to get up and

talk on stage, and here you see from Tech Ed. I don't know how many of the audience are

of that age in this industry that you know or remember what tech ed was

If you go to find tech ed on wikipedia these days, it'll redirect you to ignite

They will explain that tech ed ignite used to be named tech ed, but Microsoft rebranded

So back in 2009, I gave this presentation, the role of the software architect

caring and communicating at tech ed in Berlin. So as you notice, I have been talking about cloud for a long time

And I have been talking about software architecture for a long time. This was even, you know, cloud was announced, but not really, you know, all the way to production yet

So I also write papers sometimes, and this is one that I wrote for the MSDM library

So there's another indication of just how old I am. because the MSDN library could be construed today as sort of a predecessor of Microsoft Learn

So 2008 I wrote the architect in the architect blog about capabilities

It's not even a blog. This was a page in their official documentation that I wrote

about the role of the software architect. And that's what I want to talk to you people about today

Before we dive into all the wonderful topics, topics that you saw Simon scrolling there just before

I am excited about all these topics about hues and about serverless and various things

I'm going to try to watch as much as possible of this. And yes, absolutely technology and wonderful architecture is so important

I want to talk about the responsibility that we have as software architects

So the software architect is the keeper of the flame. He is the owner, or he or she, the person is the owner of the principles that the project follows

So what does that mean? What is that about? Well, I'd like to dive into that given three quick topics, one after another here as fast as possible

One, the example of things that you are responsible for as an architect

is to not choose the cool path, and I will explain to you what that means

Also, you have to realize that architecture will change, you know, a difference from actual building houses architecture there or bridges

When you do software architecture, you know for sure that it's going to change

And then your behavior, as the architect, will reflect on the rest of the team

So you set the example. So if we talk about the not choosing the cool path

first or maybe not to succumb to the latest trend, if you will

I'll tell you what I mean about this. So as a software architect you know you can see things like this I just wanted you guys to have a moment to look at this wonderful wonderful comical drawing

but actually it's too close to truth. There are so many scenarios that I just look at this and I see more and more in this picture

and I laugh. There's the blame radius. There's the one tiny cron job that keeps everything from falling apart

There's the freaking slick reverse proxy that we implemented as architects. Yes, it's very cool

And containers. Oh my gosh. Look at all the containers. Right. So this is one of those satirical drawings that satire is good because it's usually close to the truth. Right

And so what's important when you architect something is that you can explain it to everyone

Everyone in the company should be able to stand up. and give an explanation of the architecture

If they can't, then it's too complicated. And so this reminds me of a thumper in Bambi

who is giving a little citation when he's being naughty. His mother says, you know, remember what daddy said

and he kind of stretches himself up, you know, and gives a little citation eating greens

And then he comes to the conclusion that the flowers are the best part

Right? So the flowers are the best part. And in software architecture, today, we all know that the flowers are, in fact, Kubernetes

That's the best part. I mean, everything should be containerized. Kubernetes is awesome

Containerize all the apps. Or should we really containerize all the apps

I'm not calling Kubernetes a fad or something that will go away. Not at all

It's going to stay forever. And it's great technology. Kubernetes is great technology

what I find so many times is that it seems that the architectural decision was based on popularity

Kubernetes is cool, it's hip, it's hipster, it's fresh. We got to use that because, you know, because reasons, because it's cool, right

And I've seen, unfortunately, on many occasions, how that leads to problems

It leads to scenarios we cannot handle. And one thing that you have to understand is that you have to take care of a

Kubernetes set up. If your organization does not have a team that is already very skilled at this

please don't try to start using Kubernetes just because you think you should

because that's going to lead to so many problems that you are not equipped to handle

Scaling and maintaining and fixing up and securing and all the things that you need to

understand how to do with Kubernetes is super important. otherwise just don't do it

And far too many who are, you know, going down that path really are not aware of what they're

getting themselves into. And they should have maybe used another approach instead

For example, using cloud native platform services. So rather than spinning up your own cluster with machines, you know, your instances, your scale

sets and various things that you might use to envision that or to make, to realize that

then maybe just deploy the application to a platform service, maybe use an app service

So, but what about vendor locking? If you're using all the services in the platform

aren't you going to be locked in by the vendor? Well, I mean, the vendor is going to say

we don't want to lock you in because, you know, we don't want to lock you into using our services

because it's really easy to re-host to another vendor, right? It is, it is, it is, it is, it is

easy to re-host to another vendor. Well, yes and no, right? I want to share a piece of information with you that I don't know if everybody knows

but statistically, the platform vendors have figured out the answer to the question

how many cloud platform services does it actually take for a customer to choose to never leave

So if you start to use services, maybe start using an app service, a database

some storage, you know, how many of these platform services do you have to begin to use

from a vendor like Amazon, like Azure, whoever it is, before you decide you will never leave

The answer is five. Five is the answer. And that's an amazing number. You would think it's more

but it's not. After that, you're definitely not going to leave. So for myself, the vendor lock-in

question is super uninteresting. If you really want to leave, then do. It's going to cause you

a lot of pain and then go somewhere else and see if you're happier there. But what I think as an

architect is much more interesting is to realize that whether you deploy your application to a

virtual machine to an app service or a container or any other method, hosting is just a deployment

concern. Ask the architect, you decide if your company is vendor locked in. That is your

responsibility. As the architect, you decide if the application is portable using responsible

abstractions like interfaces, proxies, dependency injection, isolating a reference to a specific

service to just one component, using a sidecar pattern. All of these things and more are

tools of your trade and you decide how much your code, the code that is in the app that you have

architected will tie you to a specific underlying solution or service. That's you who decide that

And the architect like we said before as we know is the owner of the principles that the project follows Okay I said that at the beginning That what the architect is responsible of handholding and taking care of

And then I had to use AI to generate a photo of the elephant in the server room

which is this picture here. I'm not going to talk about AI a lot here

AI certainly is all the rage and everybody wants to use AI

We want to have the same application as before, except now with AI. And AI is the holy grail

Oh, my goodness, it is the best. Now, I'm not suggesting AI, same as I said with Kubernetes

is something which is a fad and is going away. AI has the potential and it's probably definitely changing our entire industry

We just need to figure out how. When you have the responsibility of architecture

at a higher level, we have to think about the Kwan, that Cuba Goody, Cuba Goody Jr. said in Jerry McGuire, which is like all of it, everything, that it works

Like, it just comes together and everything is cool, everything is great, because you have to be concerned with, show me the money

So I want to give you a quick, quick example. I saw it not just two hours ago, and I just added this slide in, where AI is amazing

AI has been used in a food, a grocery store, to reduce

food waste in the store by 40% by in fact keeping a living like an ongoing track of how much

stock is on the shelves and what are the dates of these produce. And so being able to alert the

shopkeepers to say, okay, you need to put a, you know, you need to put a discount on chicken

chicken breast because otherwise some of that chicken breast is not going to be sold and it's

going to go spoiled. So put a discount on it now and make sure that you sell it before it's waste

And oh my God, that is an amazing example of how to save the world. But too many people are just

saying, oh, I want AI in my app. And to that, I just say, show me the money. Because you have to

understand that when you jump on the bandwagon of a cool trend, please be responsible. That's your

job as the architect. So don't be afraid to change. So this is a business fable of some characters

who are living in a labyrinth where there's cheese. And suddenly one day the cheese gets moved

And the rest of the book is about how these different types of personas handle change. You will have

the people who are resisting the change. You will have the ones who are afraid of the change. You

will have the ones who are excited about it. And then the ones who are carefully seeking out the landscape

and figuring out where to where in the labyrinth did the cheese actually move

And I think, that's the little blue mouse to the left there called sniff

I think the architect should be like that. Curious about finding new solutions and ways

but not jumping head first in and certainly not resisting it. Because resisting changes, it's going to be the end of you

So the architect, again, like I said in the intro, is the keeper of the flame

The architect should be the person that holds up the flame high and goes through the labyrinth

and leads the others for them to find a way to understand where the new cheese is

What's life going to be like now that the cheese has moved? That's what the architect does

It leads the path. He's the keeper of the flame. So everything was fine and then people, right

Technology can be advanced, but it is commonly straightforward. While humans are never straightforward, never, or in other words, humans have more issues than any repo

And it's true. It's true that this is a problem that people are the ones that are difficult

Technology is usually, you can usually overcome it. You will in your company have, you know, the person who will, you know, the person who will

resist change. And while this picture is funny in the cloud context that somebody is not willing to

change anymore, I don't want any cloud, we got to remember at the same time that these people

have every right to be respected and remembered as the proud IT architect that they probably are

Maybe they don't want to change to cloud, but at least they should be respected and their

experience should be valued in the company when you transform into this new architecture that

maybe is using a cloud platform. And I think that's important to remember as well. So if I could

ask you a question, that would be good, but I can't, not in the time that we have, because you're

not a live audience, you're a virtual one. What is the number one threat that your beautiful

software architecture will ever face. I'll tell you right now that it is success. That's the number

one threat. Hopefully your business will be hugely successful. You'll make all the money in the world

and have lots and lots of millions of global customers and so forth. Yes, brilliant. Except that your

software architecture was never architected for that scale. It was not financially viable at the start to

create a global, redundant failover, something something architecture, you didn't have the money for that

And quite frankly, you also didn't have the customers for it. So you start by building something else

And the software is adapted to that reality. And then you know yet here we are now losing customer opportunities when we become a big hit And our business is booming and we need more power and the architecture at that point cannot be rigid right it has to be flexible enough to

manage such a scenario so you have to architect with change in mind because change is inevitable

change is always going to happen and you have to also be responsible and not to like throw in

something that is 10 times the capacity that you need in the beginning, because if you do

you're going to waste a lot of money. So a battle plan or architecture is only perfect until the

fighting starts. Planning, architecting is everything, but following a plan is useless, as in you have

to be able to adapt when reality actually starts to happen. So again, at the end's here

the end here you set the example as the architect you set the example here is an estimation an

estimation of cloud users cloud consumers company leaders that have estimated guesstimated i don't know how

they came up with that but have figured out that they think that roughly a third of their of their

cloud bill the spend that they have running their their application is waste rest is cool but

The third is waste. That's literally, if you have a $1 million enterprise agreement with Microsoft

that's taking $333,000 and just burning them on the lawn. That's what that equates to, which is crazy

And I'm going to tell you a very, very quick story about a company that was growing like crazy

They were hitting it. They were moving their things to Azure. They were booming. They had lots of customers

They had lots of demand for their services. Brilliant. So they were feeling some pressure, tension on their IT department

They had problems keeping up. And the customers began to call in with complaints about their application performance

And that, of course, can be a very, very dangerous thing. So as the CTO of this company said, okay, we have an application which is auto-scaling

So when the demand is high, we use a lot of instances. it's more expensive, but you know, that's okay, because a lot of customers are using the service

And when demand is small, then we scale back in and we use few resources

So they had a brilliant setup with the replication, but he said, let's turn that off

We have to turn off auto scaling while we do the troubleshooting. Oh my God

Okay. This, I have to say, was against my recommendation. So five months later, they were still troubleshooting

They still didn't have control of the situation. And their Azure Enterprise Agreement, which was for 12 months

I believe it was a million euros over 12 months. They had spent those million euros in seven months

And that's a lot of money, kind of wasted, because they couldn't find the problem of performance

They couldn't rectify or fix the problem of performance. So they had to set their scaling to a real

rigid maximum and just spend a lot of money extra. And that's just an architect who didn't foresee that this was going to happen

And also maybe didn't have the appropriate monitoring and things in place at the same time

And then they had to have this conversation. You know, you have the development department where everybody's wearing sneakers

And all of a sudden you hear fancy dress shoes coming clank, clang, clank, clank down the hall, right

and it kicks in the door and he says, can someone explain to me how the heck the cloud can be this expensive

And my conclusion here in this story is that a bad architecture can fail

you know, a whole business. I don't think they failed, but they certainly were not

they were slowed down to a crawl, and that hurt the business something awful

just much more than that money wasted on the cloud spend. It hurt them even worse

So your architecture can save the jobs and the future happiness of everyone you work with

That is the responsibility that we have. And so the architect is the owner of the principles that the project follows

And she is the keeper of the flame. That is what you have to remember

You have a leadership responsibility as architects. So don't choose the cool path

Stay away from that or at least motivate. Ensure that you know exactly why you are on the cool path

and that it is the relevant right thing to do. Whether that is Kubernetes, could be

whether that is AI, could be, or anything else. Do not also be afraid to change

because change is inevitable. Change is always going to happen. And the worst thing that can happen to your architecture is huge success

You have to plan for that. you have to be able to change. And then with your behavior, don't be the CTO who burns money

on the law and doesn't care. You set the tone, you set the example for the entire company

and you and your architecture can break the company, but it could also save the company and save

your jobs and save the future. That's all I have time for today

Ladies and gentlemen, I'm going to hand it back to Simon, who is going to continue with

our wonderful presentations for the Cloud Software Architecture Conference