Learn from SAP Experts to Level Up Your Engineering Skills - AD202v
Hello everyone, and welcome to my session. And before we start with the session, I want to give you a small reminder. I was asked to do that so that you can really use the chat for questions, which we will later answer in the Q&A.
And the topic today will be Cloud Transformation. That's what I want to talk with you about. And I will start by explaining why confidently delivering changes daily is a better model for the cloud than never change the running system. And then I will introduce you to our core beliefs for a successful cloud transformation.
I will explain those beliefs in detail and how they form a paved road of tooling. And I will also have a demo in the end. And important to say is the tooling I will show there cannot be used outside of SAP, but the core beliefs can. And the question in the beginning is, of course, why is someone from SAP in the position to talk about cloud transformation? And SAP turned 50 last year, as you may know, and we started as a true on premise software development company in case of SAP, on premise in the beginning literally meant developing on the premises of the customers. Until 1980, much of the development of applications happened directly in the data centers of SAP customers, and imagine the way from there over software delivered to install via CDs on premise, into the data centers to true cloud software, and operated by SAP. And today SAP has more than 230 million cloud users.
And to move away. So and the question is, of course, what does it need to be able to serve 230 million cloud customers? And to get there, it requires really to move away from a mantra like never running, never run, never change running system, and never change running system can actually be a good thing, because it can be good if you have stable processes and long innovation cycles. But it's not appropriate anymore today, because today innovation is expected quickly, which means changes happen quickly.
And to embrace these changes and do them as often as needed make them also less disruptive. And in the cloud native world, change is normal because innovation is expected quickly and therefore confidently deliver changes. Daily is also therefore a good mantra for the cloud. But if you just tell that to an organization or prescribe that to an organization, that will not make it work, of course, because it needs culture to be successful with such a thing. Why specifically, those four words confidently delivered changes daily. Why not confidently deliver biweekly? In short, it summarizes our three core beliefs for a successful cloud transformation.
Confidently, confidently summarizes our belief of single trunk development. Deliver changes for us. Stands for feature driven development process, and daily is our belief that you should deploy daily to production environment. And if you ask what Cloud Native is, we believe exactly this. In our opinion, Cloud Native is not about tools, about using certain tools, about using Kubernetes or any other technology, because these technologies, they can really only act as an enabler, but just using them doesn't mean you are cloud native and also vice versa. And therefore also the focus of the talk will not be about technology, but about the culture which the culture for building cloud native applications.
And this culture is suitable for single microservice as well as for multi microservice based applications. And having said that, I also said it in the beginning. We will also have an outlook into the tools at the end of the session, also including a demo. But before we do that, let's talk more about these three core beliefs. And let's fill these buzzwords with some content. And we will start with single trunk.
Single trunk trunk means that features patches and also fixes are done in the same main branch. There are no long living feature branches. There are no release branches. There's just one version of each microservice. And if you look at the traditional approach of development like git Flow, they have a lot of branches.
You have long lived feature branches, you have release branches, you have hotfix branches, you have release preparation branches and so on. And even for one microservice that's fairly complex, to keep track of all the different branches and to test all of them, and it becomes unmanageable. And I speak here out of experience, if there are several microservices or a lot of microservices with, with, with dependencies among each other and, and other stuff, and because you really have an explosion of combination which you have to test, and the only way to manage this complexity without stressful code freezes is single trunk per microservice. And the benefits, I mean, they are quite obvious. The benefits are you have no testing of combinations of different versions, and you also don't need to do double maintenance, and you have less context switches for the developers.
And how how can you achieve that? There are two things which are important. There are also other things, but two things are important. One thing is that engineers merge their work at least daily into the main trunk, and with that you have smaller merge event, you have smaller code reviews. And the second thing is that as all work happens on main, you should be possible to deliver emergency fixes very quickly from dev to prod it after merge to main. It should not take longer than about 60 minutes.
Me and my unit we accompany. We accompany many products in their journey to the cloud, and a lot of these products are changing. What we experience are changing the development frequency. So they move from a maybe five month development two phase to a 11 days development phase. But what they don't do, they don't change their behavior.
So they still have test phases and so on. And what they are doing is they are they are doing on premise development in the cloud because they they are combining the disadvantages from both world. They have the pressure to release more often because management and customers expect that, but they still have the processes and the mindset from on prem and do a lot of manual things.
And in the end, they just I mean, you see it here on the slide, they just implement a smaller waterfall. And to step away from this approach, we believe you need to take a radical step. You need to mandate daily deployment to production. And if you choose daily deliveries as a goal, you have to combine the development and the test phase. And because you cannot repeat manual things or a lot of manual tests every day, and that means that you completely have to automate everything. And if you completely automate everything, you really can then deploy, deliver and activate features any time. You may have heard of the Dora company, which is part of Google Cloud today, and what they are doing is they regularly publish a DevOps state of DevOps report, and they identified four key metrics with which you can measure the software delivery and operational performance of an organization.
And deployment frequency and and change lead time are two of those. And so and you can say that with daily deployments you're really on the track to achieve elite status in the industry to Dora. And the benefit of that is that Dora found out that if you are in the lead, if you have that elite status, then you are twice as likely to meet or even exceed an organizational performance goals like productivity, like profitability, and also customer satisfaction. And leaving this waterfall style development behind has also other direct benefits. For instance, it reduces the complexity because if something fails in production, it comes from a small area which has been touched since yesterday. And the question is, of course, now how to deal with unfinished work, because as an engineer, you cannot finish each feature with all tests on a day.
Right? And if you have only one branch and you have to deploy data to production, you have of course you have to. You need to hide unfinished work behind feature toggles and which is part of our next belief. And yeah, the concept of a feature really determines the whole feature driven development process or cloud development life cycle we call it, which spans from customer requirements, which you see on the left side on the slide over build and test to operation and observation in production. And the process always starts with the definition of a feature which is developed.
Then a set behind the feature toggles and the definition of the feature also includes a strict definition of done. A feature needs to fulfill before it can get activated in production, and the definition of that normally also includes how the how the feature will be measured in production, so how the success will be measured in production, and these dodds the feature need to fulfill before they it can get activated for the customers. And yeah.
Why is that. Why does that make sense and why is that, why is that not only a technical vehicle. And because it's important because it it decouples the deployment of new software versions in production from the release or activation of new functionality for customers, because with that approach, engineers can develop their new functionality in their microservice, and they can deploy this microservice, including the unfinished functionality to production without customer impact as they are developing the feature behind the feature toggle, and you can then activate the feature once the feature is when the feature is ready, and also, of course, when it's best for the customer, or if you have a customer campaign or so or so on. And with that you have no stress quality first, and after the feature is activated, you can then set, you can measure the success and the usage of the feature and the value that feature brings to the customer. And with that, you can then close the feedback loop, because this then also determines how you then what you build next for your customers. Of course. Just go back a second to introduce the next slide. So of course it's important that you.
Now the question is of course now which tools do that. You or what you have now to talk about is about the tools you need. And to live such a feature driven development process and a good starting point to find the right tools is the cloud native landscape of the Cloud Native Computing Foundation, and what the Cloud Native Computing Foundation does is they regularly release a cloud native landscape, and in that landscape, they they map the different cloud native technologies which can be used for the different steps of the development lifecycle. And what you see on this slide, here is the version of 2016 and the number of tools which you see on that slide, which is already quite high number has grown over the years. So if we compare that with 2018 and the version of 2022, you could even argue the number of tools has exploded.
And so the question is, so what tools should your engineering teams choose for the feature driven development process? And you may say let them choose, let them decide. And that's a sensible answer. Of course, if you have well experienced teams that know the latest and greatest, but if all teams are doing that and in SAP we are a big company, and if all run POCs to find the best tools for them, a lot of time is spent choosing the right tool set and who ensures then that those tools work well together. And in the feature term development process, and where all the different phases of the feature driven development, where all the different phases of the feature driven development process have to be nicely aligned and work well with each other. So we in SAP did not let the teams decide to choose the two, to choose the to choose the right tools, we instead offer the teams a paved road. And what is a paved road? A paved road means a suggested and a well supported path of tools.
In our case, along the different along the different phases of the feature driven development process. And the paved road which is depicted on that slide was built for microservice based cloud applications, and we called it deploy with confidence. And it's not for monolithic applications.
This kind of applications need a different kind of paved road. And the goal of that paved road is really that the teams using that paved road can concentrate on what matters most, which is creating customer value. And at the moment in SAP, about a four digit number of developers are using this paved road. And for microservice based applications, this is really the the standard way of developing software at SAP. And what you see in the middle of the of the slide is the delivery management dashboard, which acts as a central place for coordination and as a visual integration point for the different tools of the paved road.
And I said in the beginning, I do not only want to show slides and share stories, and this is the reason why I also want to do a demo of that delivery management dashboard. And the context of the demo will be the application SAP cloud, which is a B2B based application, which is which has the purpose, the product. The purpose of that product is to help SAP's customers to implement and operate SAP cloud products. And they are more than two and a half years on the market. They have more than 4000 customers, did already more than 770 deliveries, and they really went they successfully went through a cloud transformation, and they also used the paved road.
And I will show their tenant and I will show their tenant of the delivery management dashboard. So let's jump to the tool. So I hope you can see it I'm sure you can. So this is the delivery management dashboard. And I said I'm in the in the tenant of SAP cloud.
And I've already clicked on the on the feature cockpit here. And what you see here is and I pre-selected this this feature toggle which, which you see here. And this feature was really developed by SAP cloud and activated for all their customers three days ago. And if I click on the detail view of that feature, I see that I see different informations here. And one thing is, for instance, that I see here in the upper right corner, I see the link to JIRA and which is used by SAP cloud as a backlog management tooling.
And and if I click here I'm directly redirected to Jira. And where I see the definition of the feature which is the. Which is really the starting point of the feature driven development process. So this feature definition here and there, everything is defined what is in scope, the user story feature toggle name and and all of that stuff. And if I, if I go back and now to the detail view of that
feature, I see also what I directly see here is in in which places in the code. This feature toggles this feature toggle is being referenced and once as the feature is already activated for all customers. So if all this references are are deleted, then I can click on that link here and directly delete from here the feature toggle from the system.
And if I now click here on the on the overview of the feature cockpit, you have the overview page. I can here click on the release tab. And what you see here is that SAP cloud has already released more than 1300 features to their customers, and this is a big number. And this is also the reason why you need such a cockpit, where you have an overview of which features are in which phase and and to to really to really have there.
Because otherwise it ends in chaos because you have no overview. And if I now click here on the landscape tab, what you see here is you have the different the different let's say development phases or dev test performance and production. And what you see here is that there are a lot of landscapes here.
And the reason is SAP cloud is really seeking a global scale out. And on the right hand side you see the all the data centers where SAP cloud is deployed. And here and this card here is the the the AWS Frankfurt data Center. And if I click here on that link, what I see here then is the service mesh which is deployed in Frankfurt. And what we talked about was the core belief of deploying of daily deployments to production. And if you do that, if you deploy daily to production, you of course need to do that in a in a zero downtime way, right? Because you cannot if you deploy daily, you cannot interrupt customers every day.
They would they will not like that. And so therefore you have to do that without disrupting any, any customers. And you have also to do that for the database changes. And we did that. So if I click here on that link I'm here in the migrations tab.
And what you see here is that are all the migrations or database changes which were applied with the last delivery to production, which was a day ago, which was yesterday, and they were applied without to all customers. So to all of these, almost 3000 tenants without any disruption of any of any customers. And yeah, I said we SAP cloud tries to achieve daily deployments to production and and to have an overview where you stand with your development and delivery process. We also have a view for that. And you see that here and.
Yeah okay. And you see that here that so you have here that delivery overview where you see okay different things. First of all you see okay one the last delivery was and you see that how the how long the delivery took. And also you can also see for a certain time frame how you did there.
As you can see how many deliveries you did for a certain time frame and also other information. And I can select here the time frame of October just to check if they were able to achieve their goal. Yet to deploy daily in October.
And let me just select here October time frame and I see okay. Are they were able to deploy more than 50 times in October to production, which means yeah, they really achieved their goal of deploying daily to production. Yeah. And with that, I'm already at the end of my session with my content. Of course, I could talk way more about cloud native development. There's much more to say, but I hope I really it really gives you a good introduction into what it means to do a cloud transformation.
And with that, we are at the Q&A. If you have any questions, I'm really happy to answer them. If there are no questions in the chat, then I would. Yeah. Then I would say, yeah, have a good weekend to everyone who joined in and talk to you soon.
2023-12-17 00:58
