3. évad – 7. epizód –Migrease: Az AWS OLA új szintre emeli a felhőre váltást

00:16 Welcome everyone! This is Digit Podcast I'm László Személyi, Managing Partner of Future-NOW and my partner in crime, Zoltán Szekér, founding CEO of OD&IT Solutions and SailingHangar.

00:27 Hi, good day to you!

00:30 The Digit Podcast aims to bring those who are not satisfied with superficial articles and catchy slogans closer to today's key trends in digitalisation and IT.

00:41 Here we will dig deeper. Oláh!

00:47 It could be a friendly greeting to the Spanish, or it could be our theme today. Before migrating an application to the cloud, it's worth calculating the return on investment, and one of the providers has developed its own methodology for this, called Optimisation and licensing assessment, so olah. Our guests are Laca Cirok, Chief Cloud Architect at TC2 and Bálint Tukacs, Cloud Architect at TC2. Welcome to the Digit Podcast studio.

01:15 So it will be "Hola, ¿cómo estás?" in style?

01:18 Hello!

01:18 Welcome to the audience!

01:20 Hello!

01:20 Thank you for being here! Let's start from the stove! When did you first start working with cloud, who taught you and what was your first cloud migration experience like?

01:31 Well, I'll start. I started my cloud career with a cloud migration.

01:38 We had a startup 9-10 years ago called playlay.com, and it was actually a mobile app that was used mostly by young people to find each other at different festivals and all kinds of outdoor stuff, and we did drone maps and everything. It has been used in quite a few festivals in about 20 countries. We had tens of thousands of registered users, and all of a sudden Facebook bought the platform behind it, well they had bought it before, but all of a sudden they said they'd get out of it, and they shut it down, and they wrote, okay, here's the source code, put it in the cloud, what cloud? We were really just developing at the time, and we had to start learning this and eventually migrated our entire application in a serverless way.

02:43 And was there anyone else to learn from, or online forums like this?

02:48 Well, on the one hand, from forums, but on the other hand, our colleague Károly Sepsi helped me, I've known him for a very long time, he gave me tips like that, and yes, so I started out by specifically studying for this, and for example, I took the exam for the disassembly of Solution Architect.

03:12 Let me ask you a question on the education line. If you had to go somewhere to study now. So, okay, you go to your place as a trainee, you learn that. But where, which university, which course? What do you suggest to people starting out in their careers, where they should look, so that they don't go to forums, so that they don't get all their information from forums.

03:35 Well, it's a tough one, since I don't really have any university friends, and now my nephew has dropped out of university, but anyway, all cloud providers, including AWS, have a lot of material up there for free, available on the web. We're from TC2, so I can safely say, kielbilder, you can search for this with any excellent search engine, there's an infinite amount of material up there, you can register for free. There's a paid version, by the way, when you get cards and you can click through. And so AWS has its own qualification scheme that if you want to be very professional, you go through these trainings, you take these exams, but it's also pushing this skill builder, because you can get a lot of people involved.

04:28 In practice, it is the training of young people.

04:30 Absolutely, and it's really good anyway.

04:33 And Laci, when did you start with the cloud?

04:35 I don't have a past like Bálint's. Just as a matter of interest. I'm a little bit from the other side, the side that doesn't know, just teaches. There really is one, my career in IT has always been about education alongside work, and you'll like this because I taught Ethyl for eight years, and then I did the other technical stuff as well. And then, for example, Agere came along, I started my career with Agere, and the first migration of this kind is linked to it, in a classic way. Here's a monolithic application, let's do it at the same time, let's wrap the monolithic application so that it's containerized, and otherwise let's throw it up in Agere, because why not? I think one thing Microsoft did very well, by the way, was to add to your various Microsoft subscriptions the $150 a month that you could spend on anything, and then you couldn't overspend, and it would refill the next month, so I started my cloud career with $150 on top of MSDN, and I was successful, so I was able to move that monolithic, political application to the Kobernetic Cluster, and then AWS came along.

05:59 And the one I learned from, well the Asher I learned from no one, I taught the others after a while. The IBS is a different matter, because TC2 found me, and then here in TC2 we have, for example, the gentleman I mentioned, and there are others from whom we could learn a lot.

06:17 Now, we've asked TC2 colleagues here in the 200, and I noticed that they like to give apt names to their various services. Now I saw on your website that what AWS calls Oláh, that's what I started with, that's what you named it, or maybe not, but that's what I got. Can you please explain this to migraine sufferers?

06:39 Yes, so Migrise is basically a complex product, it has four pillars, oil is part of it, but it also has DRSIT, archive management, then migration business plan, application modernisation, and the Italian, and we're talking about Zola, and that's probably one of the most important parts of it.

07:05 Then I'll say again, for those who missed the beginning, it's the Optimisation and licensing assessment.

07:11 Yes, short for. Yes, yes, yes. Otherwise, we like to add such apt, easy-to-digest products to our services.

07:22 Here we have mainly tried to refer to oiliness. For example, we have a product called Lazy, which is such an apt name for one of our main products on Landings. The idea there, for example, was that we're trying to actually convey to the customer that we can give them a really hassle-free, easy-to-build solution that they can use to build a cloud infrastructure that's easy to audit, easy to replicate, easy to validate, and they don't really have much to do with it because what they're going to have, we're actually going to take.

08:02 He just lazily lounges in the hammock.

08:04 Yes.

08:04 This is how it works.

08:05 This is how it works.

08:05 This is how it works.

08:07 Yes. Now, coming back to migration, so the main backbone of this is an analysis, if I understand it correctly, a migration analysis. How many years in advance is it worth calculating, what aspects do you usually include in the analysis, like how can you even estimate the amount of data nowadays, and an important question for me is always, do you only look at the company's servers and applications, or do you also look at the people?

08:35 No.

08:38 No, are you not going to check?

08:39 No, no. No, you really have to look at everything. You know, this is the holistic approach category. You don't have to go very far here either, because it's in the interest of every cloud provider to make it easy for me to feel comfortable in the cloud, so AWS is also starting a little further, they have a so-called Cloud Adolphion Freemore recommendation, which is that if I as a company decide that I might be interested in the cloud as a tool, not as a goal but as a tool to extend my business services, I should look at myself and see how well I'm prepared for it. And then there are different areas, business areas on the one hand, technology areas on the other hand, and of course there's the human element.

09:34 It's the classic triangle, there's this triangle from the old days, the three P's, People Process and Product, and then it's extended, so that we usually break People into two parts, because we think not only about internal resources, but also about external resources, and of course we name it, depending on whether we're talking about AWS or IT or whatever, these four are the main points that we look at, depending on how we are positioned from a strategic point of view, how we are positioned from an organisational point of view and so on. And the way we do that is we build on that, AWS has basically two of these, and we look at the bottom and the top to see what they look like as an organization, Claude Redines' point of view.

10:27 This MRA, you can do it with a partner, with us for example, and if a company is serious about it, there's a simplified version of it, a self-declaration version, where you have questions based on the CAF, where one has a lot more questions and a little bit more depth, and the other one has less, so everyone can put themselves on the map, it comes up with this little spider web of what I'm strong in and what I'm not strong in, we can identify the cheeks, and then based on the cheeks it comes up with what you asked about, that otherwise, let's say technologically we might not be very far away from doing something like this, but let's say humanly we're not quite ready.

11:08 For me, the human part of it is always, I think, quite important. So I'm trying to ask, as the title of my last article started with Digital Passivity. And what do you see in this digital passivity? How do companies approach this question? Do they even understand? Okay, you're meeting IT, but I want to ask you at a company level. How much should you hold their hands?

11:34 To what extent do you need to be told specifically what is going to happen?

11:37 Or how much attention is paid to this?

11:41 I think you should tell them anyway. Very often we also perceive that we are going into a migration assassination, and not necessarily.

11:55 Not so oily.

11:55 Yes, it's not only not that well-oiled, but that there's not really a high-level cloud strategy, there's not even, and very often there are not even lower-level plans, of what's going to happen here and why we're doing this in the first place. So the Ola is very good for that, because it gives answers to that, for example, together with the MRA. So yes, we can help with that too.

12:25 While you started nodding and saying something.

12:27 Yes, yes, yes, because I think it's like that, it's always such a difficult question. Now, not just cloud, but I think we've been in IT for a relatively long time, we've been through a lot of things, a lot of changes in our lives. I used to say that we have chosen the right profession because we are going to study for the rest of our lives, but I'm sure we've all encountered, not just in the cloud, that someone is not understanding something new, and you have to overcome that passivity if you can overcome it. Obviously, you must have experiences like that, and I have a lot of experiences like that, for example, with agile, that suddenly you start working differently, and if you suddenly start working differently, then who can't understand it, why it's important, and can't pick up this pace of work, and can't understand that it's not part of a team now that I'm going to go to the basement and write something for three months and then come back, sooner or later they'll drop out of the story.

13:31 And I think the cloud is a bit like that. So obviously we are doing that, we are educating ourselves, we are interested in new things. It's a bit hard for us to imagine that someone who works in IT wouldn't be interested in new things, but it does happen. I would say that most of the companies, the big companies, where we work, there's a place for a person who's comfortable in a pianist environment, doing things that they've been doing for a year, two years, five years, you're not going to be able to force them into change. You can find your place, I think.

14:15 That's great, but when I look at the conferences of the leaders on the economic side, where the economic decision-makers are sitting, they jump on these very phrases. I don't understand why I have my system there, I don't understand why I have ten people running it, why I have to keep my on-premise infrastructure itself, and then we're doubling the cost now when we move to the cloud. Now, this idea, how do you, or do you, resolve this?

14:48 There is no universal truth.

14:49 Because there's that classic saying that no two companies are the same.

14:54 It depends on where you stand in this move to the cloud, I don't know, I don't want to use words like that, but Castle Medger is just going back to the idea that in Hungary I think there are few companies that say I'm starting now and then I'll move straight to the cloud, I'm talking about bigger companies, or who say I'm a big company, I'm an enterprise, I'm throwing everything away, everything on the ground and moving up. That's the kind of hybrid that's in the large corporations, and that's why I said what I said before, that it's going to be there for some time until the iron is obsolete, until you have to throw out that particular software, until there's room for legacy tools that you can't replace, for example, at least in the short term.

15:43 And then to operate and maintain legacy tools, you need people who have been there for a few years, and you don't necessarily want to get rid of them, because then you won't be able to operate your particular legacy product.

16:01 It is through you that I am now telling you what leaders should know. So, I'm very happy that you put it that way, because it's such a peaceful way of putting it.

16:12 This is what the punamatata is.

16:14 We will stay on this line.

16:16 What do you think about what Laci said?

16:19 I think it's very good that you've brought this agility in here, because very often this is one of the main questions why we should go to the cloud, and most of the time I think what is not necessarily so important in Hungary in most periods is scalability. Mostly on Black Friday, similar periods say in one of these webshops. That's actually why everybody loves the cloud, because you can suddenly buy a lot of resources and you don't have to buy practically any iron and store it there, and it was bloody expensive, etc. However, what I think is very often not taken into account is the agility that Laca mentioned, because let's face it, in the cloud we can much more easily develop this kind of mode of operation, so that we not only develop agile, but also diploy agile, collect a lot of metrics about the system continuously.

17:31 Everything can obviously be built on Earth, but we get a lot more tools for this from these public cloud providers, and it's easier and simpler to use them, and it's also very often the case that you don't have to buy it from a third party company, for example, and then you have to buy a separate support contract for it, but you get it in a bigger package.

17:57 So in English, it's not only interesting because of the development process, but if I'm a decision maker, I can deliver something new to my customer sooner, which may pay, if it pays sooner, it's a quicker cash flow. On time, while we're on the subject, I have a time-related question. There was a question about the timeframe for such an analysis, how many years ahead it looks, say, in the life of the company and IT, and then I would also add the question of how long the analysis itself is, what is the ideal period, the timeframe to calculate with, how patient or impatient should a customer be, and on the other hand, if he becomes a bit of a whiner, because there are no real answers, as you said, there are companies who don't know where they are going, or at least why, how long do you spend on such an analysis?

18:49 What we used to say is that it's worth considering a 3-5 year plan.

18:58 So a timeframe, sorry, because if it's less, you can't really make the right strategic decisions, and if it's more, it's just unpredictable what the technology trends will be in the future, or there might be organizational changes within the company.

19:21 The 3-5 years for hybrid, or just cloud, if you said that version.

19:26 Basically, we work in such a way that the client takes the red marker and draws a sketch of the area, and we start to think together that this might be the scopes to be migrated.

19:40 I see.

19:40 Is that or how many times you hold hands with the red marker?

19:45 Well, we'll talk you through it. It depends on a lot of things.

19:47 It was an important question.

19:48 Yes, it depends, I can obviously give you examples now. We've done the business stage analysis, I mean, not me obviously, but the client next to him knows his own business well and says let's start from the back, let's say we get to know this whole methodology and then based on the business sympathy analysis we score the least critical applications. Let's say a Deb system or a test system. Here, we'll see how things are done, learn well how this migration works, get to know AWS, and then we can go from there. Or the other way round, when the saying goes, as Bálint mentioned, that it's your top 1 or top 2 business service that falls at a time like this, it's the other way round in terms of business, it's the most important thing to start with.

20:37 So we can only really give advice, but he has the felt.

20:40 The reason why this question is important is because I'm going to add to the thinking for a moment, because we have this thing called Compliance, if I'm going to use very bad words, we don't have two Dora. Okay, so it's bound to come up with the geppelendesis that has to start all this. Do you work with cybersecurity companies that do this survey? Or has there been a question about this in general? Both can be true.

21:06 We work with the information security team who is the information security team for that company, and there is no such thing as not working with us. So I prefer to take a turn at it, but you can never miss it.

21:19 Not only because the processes are usually such that the infobizti team would like to know, but also because security by design is how we build the system, and therefore it is important to comply with the rules there. And it's good that you mentioned Dora for example, so obviously in that respect it's even more difficult in an FSI environment.

21:44 Well, I don't have much to say about that, but otherwise, yes, so regardless of that, with Nis 2, with Dora, even within the company, we have experts who are taking this forward. So, yes, unfortunately, you can't miss this.

21:57 What's good about this conversation is that it doesn't sound trivial to us and to ourselves, but that a lot of the listeners don't necessarily know, or get it from us, and that's why it's interesting to go off on a tangent or in a direction. Then Laci pulls us back in, because we're very lucky to have him.

22:19 You need a cod weight. Coming back to the timeframe, I think that the 3-5 year timeframe is very practical, a lucky thing if it is professionally justified, because the economic decision-maker can do a lot with it, because all the specifications are three or five years.

22:35 Well, yes, that's how we count Roy, so I mean, there's not very much.

22:40 It's just that, let's say, the alternative of buying, I don't know, a laptop, buying a server, buying this and that, whatever physically gets there, has to be calculated with that kind of amortization by Royal. Now, returning to the analysis itself, we have now gone round and round what aspects are involved, we have gone round what other aspects are involved, see information security, and we have also gone round and round the fact that there is a parallel process going on with the client's business and IT decision-makers, but how long does it take to start, or from where you start, and until the analysis is finished and a decision can be made on it?

23:21 If we look at the methodology, it can be divided into three main sections. The first stage of such a SS went. And at the end of the SS Band phase, this is what Bálint was talking about, there will be a business hand, and based on the business hand the client will be able to decide whether or not to actually start the migration. This is to give them as accurate a picture as possible. Obviously, part of this is a task of mapping the area outlined in red marker, and we usually do that with discovery tools like this. AWS has its own discovery tools, there are certified partners, AWS certified partners who have discovery tools, and if it happens that from the point of view of information security, nothing could be decorated in the area marked with a red marker, then there is the possibility that if there is, say, a properly built CMDB, which is not very often.

24:26 If they show the part where it had to come from, it's easy to come from that.

24:30 For the benefit of the students, this is the customer database, the Customer Master data, where we store the master data of a customer, and up to a myriad of systems can communicate with the customer's master data in this system.

24:44 That's right. We're talking specifically about technical data, so configuration management, if you can give an output of that, if you can give it to them, that's just as great. When we do discovery, there's an important part of it that we strive for accuracy, so it's no good to have a snapshot of how busy the servers are, for example, if we're talking about technical things like that, but we should look at it in progress, so the recommendation is that a discovery should run for 3-6 weeks, and then we can draw an accurate picture. Peaks, not peaks, so then you have an average usage, and based on that you can say, you know, you have to replace that in the cloud provider. So, to come back to your question, this includes even then we'll talk, we'll do this redinen survey.

25:38 This is a 2-3 month phase, this is the SS Band.

25:43 Here, students should be told that usually a survey is a minimum of three months everywhere. So anyone who can't take this into account, that he's giving the opportunity to anybody for three months, will have problems, because in three months he'll get an image that is not a snapshot, and I'll give you a very illustrative but simple example. Without the survey, it was impossible to know whether the rescue would actually run. And with the help of the survey, this tool was on it for six weeks and started to survey, it turned out that the backup itself to the start of the business didn't run down, but it could be restored from the backup, it just wasn't looked at to what depth. So that's what makes it interesting, and in the cloud, when you're storing data, it makes a difference how many forints you have before and after and during.

26:33 This is the addition.

26:35 Yes, by the way, that's another very good example, but another one we've seen several times, by the way, is the end-of-month closures. So that also takes a lot of resources from the servers, and then all kinds of queries are running through and through, and if the period is shorter than that, maybe only one lock can fit, maybe, or even none, because the client would think that we should finish as quickly as possible, but really, the best thing would be to include a year-end closure, but I think not everyone is so lucky.

27:16 But at least you get it that way.

27:19 Yes.

27:19 So, yes, if I say that if it is really a company where this is a central thing, for example, that such an ERP system is also involved, then I think that two or three closures like this is not bad.

27:39 So these two or three months are necessary, on the one hand, to be able to talk back and forth with all the actors several times, but also because you are monitoring the systems, and there are some acts that are not done every day. This is just for the benefit of business leaders. However, I think it's time to relax, because I feel I'm overdoing the microphone test here. So summer is about to burst. I think the current issue is beaches. I would like to ask for your expert advice for the benefit of our students, which is your favourite beach on Lake Balaton, whether there are any secret, lesser-known bathing places here in Hungary, or even abroad, if you go abroad, how much of a deciding factor when looking at where to go, whether there is a beach and what kind of beach.

28:24 Anyone can start.

28:26 I'll start, because I'll be the negative example. We need one of these. We practically don't go to the beach. I will clarify a little. We don't have children, we have dogs. So we go to a beach that is not a real beach, but a quasi-free beach, where dogs can be taken into the water.

28:48 So two questions immediately arise here.

28:50 What dogs, and please give me some ideas where.

28:53 So the Russian black terrier. It's good if you nod, because many people don't usually know and Barbet.

28:59 Barbet.

28:59 I wish I could have said.

29:04 This is not the name of the beach.

29:04 The Barbet is a French, basically a water hound, the only funny thing about it is that there are three of them, the two Russians are great swimmers and the Barbet I'll show you how to swim.

29:20 And in theory, he should be the best swimmer. We usually go to the Danube anyway.

29:24 Danube.

29:24 Beach. We used to have a ferret, we don't have a dog, and by the way, that's what reminded me that we don't go to Balaton, we don't go to the beaches of Balaton, but it stuck in my mind so much that now it was either at Balaton, but now I'm not sure, maybe in Venice, but we went to a beach with a ferret, and it was such a great experience for us, I think it's fun to go there with dogs. Obviously there were a lot of dogs, a bit of crazy dogs, but absolutely, I didn't mind at all, I love animals. Well, abroad we like Albania very much, so the Albanian people are very friendly, and the part next to Xiaomi, that's what we really like. So there's a very fine white sandy beach there, it's Europe after all, so we really like that.

30:28 Thanks.

30:28 Thanks.

30:29 Laci?

30:29 Well, if Balaton, then Zamárdi, the heart of Lake Balaton and its surroundings, is a very nice place for me on the south shore, and I really like the shores with the pine trees, Földvár too, but Zamárdi is more complete. And if the north coast obviously, then Csopak, so mainly because of the family, we have older children now, but they have been younger for years, and the beach in Csopak is so compact, that there is everything, but also clean, but you can fit in most of the time, and even delicious, we liked it very much. It was also where we first came across this long-running cool on the beach thing. We have a very serious role for music, classical music in the family, and these little classical music evenings of half an hour, three quarters of an hour, they're very atmospheric, and there's a little water stage where it works very well.

31:24 And when abroad, we don't look at beaches as much nowadays, we're more of a sightseeing family, but my favourite holiday as a teenager was in Rafina, north of Athens, where a friend gave us a house for two weeks. It's not a beach for him, but Rafin is practically a holiday village for Athenians, and the house was on the hillside, and we walked down there, and it was full of Greeks, so it wasn't a tourist spot. There was a pebbly beach and a sandy beach. It was very good. Zoli?

32:01 Well, what can I say now that you've packed this thing off?

32:06 I love the beaches of Balatonalmád, and sometimes I go to Csopak, but just for the adventure.

32:15 Just to invite people you know over.

32:17 Yes, so that I can meet them there.

32:22 Rolling on from today's discussion, I'd like to tell you a story. He once moved into a big banking office building in Budapest, and of course the original building had a server room. Incidentally, I saw with my own eyes how the servers were later moved by hand to the new site not far away, but in one of the preparatory meetings the IT manager was found to say to the bank's management, The Disaster Recovery City The Disaster. It's hard to translate that into English, but I don't think it should be. That wasn't today, and I think that today this so-called DR site, this disaster site, it's almost always a cloud, isn't it?

33:08 Well, I don't think it's always the case, but more and more often it's practically step zero. That's what companies are moving towards cloud solutions, because it's relatively easy to set up, and the costs are usually much lower than having to put up a second slide of quasi-extra hardware resources, and then have servers on standby waiting to be switched over, yes.

33:43 The difficult thing is that in theory you shouldn't use exactly the same ones in the disaster recovery part, but it's good for the budget to have exactly the same ones. So, there are two schools, and I'm asking you now what you think about the two schools. One is to have exactly the same tools, even on the Disaster site. The other one says that under no circumstances can the Disaster site have the same tools, because it is a disaster, not even by accident, so like the pilots on the plane, they cannot eat the same food.

34:16 Yes. I have a favourite answer to that again, it depends. Yeah, we've talked a lot about business services, we've talked about business benchmarking, and we can also say, we can add RTO, RPO, how quickly you have to recover, if there's a problem, how much data you can lose, etc.

34:39 Now I'm sorry for interrupting you. I would like to ask that when you RPORTO, and let's say the restore, at the restore let's say the pitfalls, because you think you're doing an F5 copy restore, but you don't always have an F5 copy restore. So, that's where I don't know, I have to set it up a bunch of things, or reconfigure something, or a little bit of the pitfalls I've highlighted, if you'll allow me. OK? So that would be really important, because that's how IT always gets overlooked. And the economic part doesn't understand, but if I have half a clock and a three-second window, why didn't it switch over?

35:20 This is a good question. It depends. The reason there is no clear answer to this is that it depends on the way a particular customer does business. So let's say that it's possible to spend a day or two days in the case of a tariff system, not restoring your entire business service, but the most important parts of your business service, even with reduced resources, just so that your customers can then start receiving services, and then we can bring it up to the right level, or we can't do that.

35:58 There are our favourite examples of this, you don't have to go far, 112 or air traffic control.

36:05 Or online cash registers. Actually, I'm not going to tell you any big secrets, students always see their own system best, but it's worth looking at the bigger picture sometimes, and as we move forward in innovation and as the world moves faster, there are fewer and fewer business processes that can fit in a day or two. I think this will slowly disappear.

36:27 You are probably right about that.

36:29 We are now discussing the 3-5 year strategic plans, as this is our topic today.

36:34 However, there should be a category of cutting through the Gordian knot, and then we can turn to the cloud.

36:42 If we imagine all of this in AWS, we can kill two birds with one stone, because we can say that if we have that architecture, we can run our disesterich warry site quasi on the cloud, making sure that of course all the data is up, so that if there is a disaster, we can recover. And the resources really operate at such a low level, and in the case of a disaster, when it comes to suddenly releasing a million users, either manually or by using elasticity and scaling, the right resource will scale up by itself, and then supply and demand can move together very well. So here, if we use such tools, we can safely say that we don't have to choose between the two, we just have to make sure that we don't lose data and that we have it available in the cloud for a given diesel.

37:41 Obviously, this requires that the right data transfers are in place and that they are continuous.

37:45 Now, to Zoli's question, I could very well tie the following to the fact that we have the same tool or not the same tool, there is also the same cloud, and we have three or four options from the cloud.

37:58 Between these cloud platforms, do you see a difference in how to do such an analysis? For example, is it even possible to do this migraine-like methodology by including not just one cloud, say not just AWS or not just Agent, but two or three, and see what it would look like here and there. Do you do that, do you undertake that, or on the contrary, do you actually have to do it one by one with all kinds of separate partners? What is the expert opinion here?

38:28 I don't think there's any big secret that I said 38 and a half minutes ago that all the cloud providers are interested in making it easier for their customers to move to the cloud, so just like AWS, the other big cloud providers have their methodology, and that methodology includes, of course, not only looking at the technical aspects of a survey like this, but also looking at the ability of the customer to continue to run their own services with a cloud provider. So there is no difference in that respect. We, as TC2, we don't just deal with AWS, but of course it's absolutely a real example of a particular customer asking us to do this operation, and if nothing else, it's really not a common but it happens, when we put it on the table how much the amount of hardware and software that's drawn around in red marker would cost in IBS, they'll look at how much it would cost in other cloud providers.

39:38 He doesn't go through the methodology, but it's reassuring to him that I then checked how much it would be in Agere and how much it would be in GCP, and it came out that it wouldn't be cheaper there, so AWS would be fine.

39:52 Yes, we have the tools to do that. So we can use them, and we can take GCP and jury into account, so we have them anyway.

40:04 It is also often said that cloud migration is not only prone to technical pitfalls, but also to licensing errors. I'd actually like to hear from you what these mistakes are, but let me give you an example of someone who thinks they can just repackage everything, and then when they start doing that, it turns out that they don't buy a license, but if they buy it, it doesn't cost as much as they think it does. So that or, God forbid, you bought something you didn't use because you didn't think it through. Is this a very practical situation, or is it the exception, because it is sometimes more often the case that you have heard that XY has made a mistake. Or whether the methodology you are following is how to avoid these non-technical, but licensing or configuration problems.

40:59 I think that's one of the really important and best parts of the cloud, by the way, is that we're not only looking at what virtual machines those workloads or applications are going to run on in the cloud and scaling them, but we're actually going to have data on, say, what Windows servers, SQL servers are in the background and what licenses they have, because as you said, these cannot be automatically transferred to the cloud, and this, by the way, yes, this is part of our survey, to highlight how these can be transferred with extra software, or if it is really completely impossible, then we have to use a solution that we run the software quasi license included, so it covers, and I will go further.

42:08 OLA is also very strong in that, because it's the compliance part. But there's also the part where we buy a lot of licenses from these big companies, and we may not necessarily need to use a lot of that, and if we move to the cloud and scale the applications properly, then we could even abandon licenses, and we would not even necessarily have to use SQL Enterprise, but could use SQL Standard, because in the cloud we can develop the kind of operation that we can achieve a similar operation without any serious loss of functionality. So here we can even talk about licence optimisation. This is part of the Lord's work, by the way.

43:08 I have to add that licensing is a separate science, and I'm reminded of an old story, when I was at Microsoft, holding a Please raining for Microsoft and Microsoft partners, and there was talk of licensing, and Microsoft colleagues said that at some point they didn't understand it either.

43:32 Do you think these companies are doing this on purpose?

43:35 No, I think it's Kunamata.

43:39 Kunamata.

43:39 I think that they always want to optimize in a way that's good for them and good for the client, but too much name changing, optimization, etc. Changing it every year to make it as optimal as possible is so easily confusing, I think.

43:55 I can take one more question, can you?

43:57 Yes, of course.

43:57 Smoothly.

44:00 We wouldn't really be a Digit Podcast if we didn't also look at the wallet, and I'm wondering why you as TC2 are worth doing this level of migration analysis? One of these analyses, you said, is at least two or three months, it's not easy, it's probably not even a win-win situation with the client, so that he feels that he's won and it's good for you, but anyway, not even a brother has moved because we're just analysing, so how is it?

44:27 We are a TC2, AWS partner, our business model is to track the complete Claude lifecycle of a customer.

44:39 This means that we are at the very beginning, the very beginning of exactly what we are talking about here, when we look together at the business service stack that is outlined in red marker as worthwhile or not. Obviously, we can put in these three months of work in the hope that in the end it will be good for him, and we can continue to work with him. And then if we can continue to work with him, then this will become a project, then the client will move up to the cloud, and I said that we will accompany the whole thing, because our colleagues told us the other day that we, MSM partners, will stay there, so we will continue to support the client, and then we can continue this classic PDCA cycle that you mentioned in one of the broadcasts, because it's constantly an on-going activity, so that if we just look at the migration, and this migration was successful, then we can move more and more workloads, more and more services into the cloud in this small migration factory, we can expand in a multi-cloud direction, so that we are there, and we know the customer better and better, he knows us better and better, and I can scale.

45:53 That's right. So for us this is the use case, so everything, this is the beginning of the beautiful franchise.

46:01 Yes, and here we can refer back to what we talked about a few sentences at the beginning, that there is no strategy, there is no real plan, and there is not even a business case, which is usually created in the meantime, and without it, it is not really worth tilting the one byte further, because it will not be. Actually, I think it's a successful project.

46:29 Customer sculpture. I could translate this to myself now, that these two or three months for you are preparing a multi-year contract for a client sculpture. Without just the brick and mortar, there is no customer.

46:44 That was a good analogy.

46:44 But time has passed. So we're lucky because I think we've given our listeners enough ammunition to think further. Something to think about. Bálint Lacza, thank you for your help with the cloud migration design solution.

46:59 Thank you for having us here.

47:01 Thank you very much. Thanks.