Manage costs during large scale migration

Jon Spallone of XenTegra and Brian Schoepfle of AWS discuss a recent AWS Blog on Managing cost during a migration to AWS  

Topics we'll discuss are: 

• How to get started with a AWS migration
• How to manage costs during a AWS migration
  • Assess
  • Mobilize
  • Migrate & Modernize

Host: Jon Spallone
Co-Host: Brian Schoepfle

Transcript

WEBVTT

1
00:00:13.630 --> 00:00:42.540
Jon Spallone: Good afternoon, everybody. I want to thank you for our second episode here of in the Clouds with aws of that Brian here, who's going to. We're going to have a discussion today about some ah topics on migration. I'm going to be hosting everything at John Sloane here. I've been on a couple of the other podcasts. You've heard me as well as some of the Webinars. We host here at Santagra. But really what we're going to do here is really focus it around things that relate to compute, relate to

2
00:00:42.550 --> 00:01:10.259
Jon Spallone: business enhancements as far as it's concerned with the Aws, and how those benefits are presented for you. And again this comes to our sole factor of enablement, making sure that you're aware of what's out there, making sure that you're getting the latest and greatest updates of information to help you with those decisions, so we can work at those cloud solutions at our partners platform within Aws. So today's topic in migration, I think, is a is

3
00:01:10.270 --> 00:01:16.940
Jon Spallone: a good one. So, Brian, if you would please introduce yourself for first time here with one of our podcasts.

4
00:01:17.050 --> 00:01:36.210
Brian Schoepfle: Yeah, yeah, thanks, John. And Thanks. Tiger team for having me. My name's Brian Shuffle. I lead a team of solution. Architects here at Aws worldwide public sector in the partners organization, and my team supports partners in in almost every time. Zone we have

5
00:01:36.220 --> 00:01:54.460
Brian Schoepfle: uh, we have team members in the Us. We have team members in the Uk. We have team members in Singapore. Um. And although our team is public sector focused, I I think, everything that we're going to be able to discuss today is is universally applicable, and certainly not limited to any particular vertical or segment.

6
00:01:54.840 --> 00:02:15.289
Jon Spallone: Great thanks, Brian. So we're If you see down here, we've got our our screen shared up with this blog. This was posted out on the seventeenth of this month. Um and basically what we're talking about here is my large-scale migrations. Um, I know specifically. We just went through a project with one of our customers using the vmware

7
00:02:15.300 --> 00:02:32.710
Jon Spallone: on tap, migrating some of their their side of the house. So it is complicated, but it's got to be planned. And this is some of the things that we're addressing here. Really, what I like. Here is we're discussing about the methodology process. Would you agree, Brian, of at Aws

8
00:02:32.720 --> 00:02:44.600
Jon Spallone: more migrations? Now, when we're talking about this, what would you consider a scale large migration of what they're talking about within this blog here itself.

9
00:02:45.600 --> 00:02:57.230
Brian Schoepfle: Well, you know what's large to some, maybe maybe small, to some others. You know, certainly working in the public sector what what? Some of our Dod customers, who have,

10
00:02:57.240 --> 00:03:08.670
Brian Schoepfle: you know, ninety to two hundred thousand service members, you know, in a particular project working on something. What they do can certainly be considered very, very large.

11
00:03:08.690 --> 00:03:14.419
Brian Schoepfle: But if you are, if you're a customer or potential customer with

12
00:03:14.430 --> 00:03:32.970
Brian Schoepfle: with one hundred virtual machines, but as a small relatively small, it staff with with not a lot of you know, a lot of cloud or Aws skills that can seem very large and very daunting. So So what's large is, I think I think, certainly context-specific,

13
00:03:32.980 --> 00:03:47.529
Brian Schoepfle: but you know the best practices and the mechanisms that we employ after listening to thousands or tens of thousands of customers who have gone through journeys just like this, I think, are again are universally applicable.

14
00:03:48.200 --> 00:03:59.330
Brian Schoepfle: Yeah, I would agree. It does size matters to the person it's working with it, really. So when aws here, the approach here we're looking at is

15
00:03:59.340 --> 00:04:13.000
Jon Spallone: we think, getting started within the migration. A lot of what I'm seeing here is the same methodology and approach that we take of mobilized. So from the assessment side of the house. It's really

16
00:04:13.010 --> 00:04:19.970
Jon Spallone: getting a discovery when you say of what's out there in the organization from that on-prem side of the house.

17
00:04:20.890 --> 00:04:39.179
Brian Schoepfle: Yeah, Yeah, absolutely. You know, there there are some things that we can talk about in terms of Ah, a cloud to cloud migration. But I I think, predominantly. Ah, whether it's an organization or a company that's that's really just getting started with Cloud and and trying to get a production workload

18
00:04:39.190 --> 00:04:53.570
Brian Schoepfle: uh into the cloud for the first time, or uh, or somebody who's who's got, you know, Some some quick wins under their belt, and is now looking to migrate. You know more complex application. Architecture?

19
00:04:53.580 --> 00:05:11.170
Brian Schoepfle: Um, you know, when when we get started with a migration, you know one of the one of the things that we really want to try to account for, regardless of the workload, regardless of the customer type is, you know, reducing business risk, and

20
00:05:11.180 --> 00:05:21.060
Brian Schoepfle: one of the biggest places that business risk is going to come from in a complex project such as this is the amount of time

21
00:05:21.180 --> 00:05:24.650
Brian Schoepfle: uh that the project is going to take. You know, the

22
00:05:24.660 --> 00:05:48.410
Brian Schoepfle: typically the most expensive resource any organization has is not a a virtual machine with thirty two cores that's got to be on all the time. It's. It's a you know, a senior level engineer or architect who's going to be working on this project. So you know, when we talk about migrations, John, you know. I think it's important to zoom out and really consider

23
00:05:48.420 --> 00:06:06.790
Brian Schoepfle: um, or take a deeper dive, maybe, into what Aws considers to be like part of the customer's success journey in a migration. And as we're seeing in this blog post first, we're starting with assess. The migration itself does not begin with with, You

24
00:06:06.800 --> 00:06:22.610
Brian Schoepfle: you know, turning a virtual machine into a vmdk and importing it into an aws, am I? You know what the what the migration really starts with is the cloud adoption framework, and I think one area that

25
00:06:22.680 --> 00:06:25.930
Brian Schoepfle: you know some customers have really.

26
00:06:26.410 --> 00:06:27.470
Brian Schoepfle: I

27
00:06:28.140 --> 00:06:57.789
Brian Schoepfle: tripped in in the early stages is treating that cloud adoption framework or the the thought adoption, framework process as just a series of workshops that they need to get through. And and really the cloud adoption, framework, envisioning, or a line workshop that you would do with an aws solutions. Architect aws Proser, or one of our partners is meant to kick. Start these internal discussions. And so, um! You know one of the things I like to point out as as part of this process, We,

28
00:06:57.800 --> 00:07:12.110
Brian Schoepfle: you know, start to account for business perspectives, and we really want to make sure that the right viewpoints are represented in the room. It's kind of a a shift for a lot of it. Organizations to to be including folks like

29
00:07:12.120 --> 00:07:25.599
Brian Schoepfle: Hr in a discussion about a technology change. But you know, typically in an organization, if we're talking about adopting new technologies, adopting new processes, produce new business outcomes. We're going to talk about

30
00:07:25.610 --> 00:07:36.789
Brian Schoepfle: um upscaling existing employees like giving them new skills or going out of the market and finding these folks that that do have these skills. And of course Hr. Needs to be involved in this.

31
00:07:36.800 --> 00:07:49.589
Brian Schoepfle: So you know, beginning a beginning of migration by reading up on the cloud adoption framework which was recently adopted for are updated for Now, Cap three,

32
00:07:49.600 --> 00:08:06.020
Brian Schoepfle: where we released an ebook which just released an audiobook. The cap is available now in in twenty languages, so if English is not your primary language, it's a pretty good chance that you're going to be able to find some resources in your language. And of course there's a kindle version so like getting a good understanding of

33
00:08:06.030 --> 00:08:34.720
Brian Schoepfle: connecting um. These desired business outcomes with the technology that we're going to be embracing is is really really critical. So before we start to do anything about application life cycle, certainly before we start to migrate any kind of data virtual machine. We want to make sure that we're connecting what we're doing in the technology organization with the outcomes that the business needs, so certainly the cloud adoption framework is probably the best place

34
00:08:34.730 --> 00:08:44.330
Brian Schoepfle: for any customer to start, and what's great about the cloud adoption framework is, We have so many partners like Zantebra, who who have this ability to lead these discussions with customers?

35
00:08:44.340 --> 00:09:01.280
Brian Schoepfle: That's great, I mean it really is the fundamentals of cloud, and that's when you talk about fundamentals. That's that first step. And you know, because you are going to have that change. But you said, Bring in an Hr. The change of the staff, not in a bad way, but just in an upscale way.

36
00:09:02.130 --> 00:09:11.040
Brian Schoepfle: So from that next step we're taking, looking at from that approach of mobilize. And basically what we're talking here is

37
00:09:12.260 --> 00:09:18.319
Brian Schoepfle: starting to build that plan as far as the migration is concerned. Is that is that what i'm saying, Right?

38
00:09:18.330 --> 00:09:27.489
Brian Schoepfle: Yeah. So we talked about reducing business risk and obviously like we're talking about controlling costs during a migration. We'd like that. The whole migration process start to finish, to be

39
00:09:27.500 --> 00:09:55.559
Brian Schoepfle: as short as possible, or as short as is reasonable, because we want to avoid stallouts. So what are some of the ways that that customers kind of get stuck if they haven't done the best job possible, or or have forgotten to account for certain things as part of the early stages we see kind of three different kinds of of stalls in them in a migration effort,

40
00:09:55.570 --> 00:10:25.169
Brian Schoepfle: and the first is is what we call pilots all. So we've got a lot of energy in the organization. A lot of enthusiasm about getting things into follow. We've got a lot of pilot projects. Um, but because maybe there's no top-down control or top-down strategy being set, you know. We've got a lot of projects and pilot. There's not a lot of formation between these things. And so we're just perpetually experimenting, which is great, but struggling to get out of the gate in terms of putting together a coherent

41
00:10:25.180 --> 00:10:55.150
Brian Schoepfle: strategy is how we're going to migrate these applications into the cloud. The second type of stall comes from what we call cloud gridlock. So when organizations embark upon a cloud migration. You know typically what's you know what's become kind of I don't know. Almost cliches is to talk about, lift and shift, right? What are the workloads that are not going to require any kind of refactoring, and they can kind of just be re-hosted right out of the gate. Well, there's what's been described in by others much smarter.

42
00:10:55.160 --> 00:11:05.990
Brian Schoepfle: The me is a lift and ship shot clock, so we get those we get those early wins by doing the lift and shift, but the clock starts ticking at that point,

43
00:11:06.000 --> 00:11:32.190
Brian Schoepfle: you know. Certainly we're able to. You know. We're hopefully able to take advantage of some kind of return on investment just by getting out of the blinking lights business. But if there isn't a plan to reinvest those savings, and there isn't a plan to kind of detail like, do these retrospectives? What did we learn? How can we apply this to more complex workloads? And then also, you know, as we talk about. You know It's not just the technology that's changing. It's the process that's changing

44
00:11:32.200 --> 00:12:02.190
Brian Schoepfle: and one thing you know, I I've been helping a customer to get to the clouds of two thousand and fourteen. I work for cloud providers. Um, you know I I work for a a partner before it came to aws is, you know, one of the things I would always try to impress upon folks is, if you're kind of bringing your own Bs into somebody else's square footage. That's not making it any more efficient, right? And it may even make it less efficient. So if our operating model has not adapted to the new technology

45
00:12:02.200 --> 00:12:14.520
Brian Schoepfle: platforms that we're using. We're still using these legacy methods. Then we kind of get into this cloud gridlock where all we've really done is maybe turn down a couple of racks in our data center. But we haven't really

46
00:12:14.530 --> 00:12:31.780
Brian Schoepfle: it's not what I would call you know a with next-generation infrastructure next-generation process. We haven't really started to even, you know, modernize, really, which is the next days that we're going to talk about, and the third type of style of chaos, and this is where certainly there's not been a lot of core

47
00:12:31.790 --> 00:12:59.969
Brian Schoepfle: uh planning. The The Ogo organization may have kind of paid lip service to establishing a crowd enablement engine or a cloud center of excellence. But there's really a lot of lack of coordination. And um, you know, if we thought we were going to break down a lot of silos by moving to the cloud, but but have not embraced really what that new operating and model is going to be these new silos arise. And so we've got, you know, different parts of the organization.

48
00:12:59.980 --> 00:13:27.170
Brian Schoepfle: Uh, with different standards as far as how they're going to the cloud, and then they get kind of stuck, because there's just there's so many things going on in the cloud, and there's no there's no management and governance strategy. So when we set all that up in the assessed phase, Then when we get to the mobilized phase hopefully, we've built a business case and we're going to start to learn from experience. So before even we start to mobilize,

49
00:13:27.180 --> 00:13:38.370
Brian Schoepfle: there are some. There are certainly some steps that we would recommend, and some customer and partner facing programs from Aws that that customers to really take advantage of to help

50
00:13:38.380 --> 00:13:51.809
Brian Schoepfle: to help make that mobilized phase as easy as possible, and and one of the things one of the tools that I come back to all the time in. This is the the optimization and licensing assessment.

51
00:13:51.820 --> 00:14:11.009
Brian Schoepfle: So you really can't effectively plan for a cloud migration without an assessment. Right? I think that makes a lot of sense to polls. But where a lot of folks have gotten kind of sticker shock and said, Okay, maybe Cloud is not right for us, because they've run some assessment tools, and there are great tools out there, both from aw

52
00:14:11.020 --> 00:14:19.150
us and from our partners to help, you know, just to help understand the landscape of the it. Environment like, What do we have out there what's running.

53
00:14:19.160 --> 00:14:31.919
Brian Schoepfle: But if if the plan is to do this, lift and shift migration, I think it's important for customers to understand that even in a so called lift and shift migration. You're not going to lift and shift everything

54
00:14:31.930 --> 00:15:01.270
Brian Schoepfle: right. Um. So assessment tools may pick up things like uh zombie machines. They may pick up things like Vm. Like Uh templates template Vms. Um: Certainly in a on premises environment customers are provisioning more infrastructure. Then they really need to support their workloads for high availability, disaster, recovery, redundancy, that sort of thing. So when we talk about a lift and shift migration, it's important to kind of narrow the frame a little bit, and really try to explore. What is it actually that we're going to listen?

55
00:15:01.280 --> 00:15:12.929
Brian Schoepfle: Shift And as part of that, you know. Keeping in mind, we're not just lifting and shifting infrastructure. We're probably bringing some software, licensing around along with us. And you know the

56
00:15:12.940 --> 00:15:40.549
Brian Schoepfle: there's such a high degree, uh you know, across all customers, all segments of customers that are running Microsoft workloads um. You know Microsoft is certainly a first-class citizen on aws. But I don't think i'm breaking any news here by saying that Microsoft licensing can oftentimes be quite costly right. I think that Msrp. The last time I checked Msrp. On like a single four of Sql server. Enterprise for a year is like thirteen thousand dollars. So

57
00:15:40.560 --> 00:15:54.889
Brian Schoepfle: so it's important to understand what is my licensing landscape going to look like when I get into the Cloud and the Ola. The optimization and licensing assessment is really really important, because let's talk about

58
00:15:54.960 --> 00:16:04.350
Brian Schoepfle: What does that on-premise environment look like? How old is that hardware? Is that hardware? Two, three, four, five years old we may be able to get,

59
00:16:04.360 --> 00:16:22.639
Brian Schoepfle: You know the same performance, or better, on a smaller number of cores on modern infrastructure inside of aws. So if we can look at, you know, zooming out a little bit to look at. What is the total cost of ownership of this landscape? You know. There's

60
00:16:22.760 --> 00:16:31.399
Brian Schoepfle: there's just a a really really compelling business case here to take the time to really do it, to really try to understand

61
00:16:31.430 --> 00:16:59.780
Brian Schoepfle: what what are my costs actually going to be so? Um, you know, if it. We actually see, like from an infrastructure optimization perspective. When we do these assessments, a thirty six percent, you know, reduction in in infrastructure costs of thirty six percent in compute savings. And when we run these optimization and licensing assessments on average, we're able to produce a forty nine percent reduction in Sql course, and that's across standard and enterprise. And as I just mentioned, this

62
00:16:59.790 --> 00:17:22.310
Brian Schoepfle: this is not inexpensive licensing. So as you build that business case, it's important to understand What is it actually that I'm going to be bringing, and how much is that actually going to cost me? And that really helps customers build the business case, for when we are, we are going to start to recruit these savings a lot sooner than we thought we would, and therefore we might be able to accelerate the migration timeline.

63
00:17:22.319 --> 00:17:35.800
Jon Spallone: Yeah, we we use some tools ourselves to help with those costs, predictions from instances and their loads based upon, you know, grabbing within the environment. The other thing, too, that I like about a migration of cloud is,

64
00:17:35.810 --> 00:17:54.960
Jon Spallone: and you've brought up exactly like the Microsoft licensing cost side of the house. There are things that we can lead Microsoft out of when we bring it over and utilize native tools within aws such as our databases. We, you know our file services. You know. These are things that we can actually trim out that

65
00:17:54.970 --> 00:18:13.340
Jon Spallone: Microsoft overhead and go into a native um solution on aws that you guys provide the services for. So that's why I I definitely feel it's. It's always always best to do that cost analysis upfront and and see What? Where? We can trim the fact that it doesn't need to be there

66
00:18:14.200 --> 00:18:15.389
Brian Schoepfle: Now he's at me

67
00:18:15.400 --> 00:18:21.699
Jon Spallone: so it mentions this landing zone is that is, that along the lines of where some of these

68
00:18:21.780 --> 00:18:23.980
Jon Spallone: tools and utilizations are.

69
00:18:24.510 --> 00:18:42.579
Brian Schoepfle: Yeah. So the the landing zone is an architectural construct, you know, inside of the Aws environment that is built off of, informed by the aws multi-account strategy. And it's it's

70
00:18:42.590 --> 00:18:46.270
Brian Schoepfle: it's really the best way I feel to,

71
00:18:46.320 --> 00:19:03.500
Brian Schoepfle: you know, Get started with good governance from the very beginning. It is much easier to start with a great foundation than it is to try to implement better governance a better foundation. Once workloads have been migrated. So whether you know

72
00:19:03.510 --> 00:19:23.420
Brian Schoepfle: um customers feel like they already have a really strong understanding of You know what it means to to use Aws control tower what it means to use aws, organizations and the landing zone construct um. Oh, ah! Or you know, are working with a partner to help them do that.

73
00:19:23.430 --> 00:19:42.220
Brian Schoepfle: Um. This is. This is really like one of the first things that you should do right like before you migrate a virtual machine. Let's build out the environment that it's going to live in. And for Ah, for customers that you know are lacking the people, the tools or the processes to be able to do that effectively.

74
00:19:42.230 --> 00:19:49.190
Brian Schoepfle: They're going to see slow downs. They're going to see increased risk, because that risk is really going to come from a lack of cloud. Ready architecture.

75
00:19:49.200 --> 00:19:53.030
Brian Schoepfle: You know. Data breaches come from misconfigured resources.

76
00:19:53.040 --> 00:20:19.570
Brian Schoepfle: The the Aws manager services, or Ams, which is available through partners, is an Aws managed landing zone environment to help customers elevate their operational excellence with twenty, four by seven, by three hundred and sixty five proactive monitoring of all activities and incidents inside of their environment Aws. The Ams service will help customer configuration, compliance and auditing

77
00:20:19.580 --> 00:20:27.730
Brian Schoepfle: even for folks that that have real compliance needs like around Pci dss Hipaa High Trust Gdpr.

78
00:20:27.740 --> 00:20:57.549
Brian Schoepfle: Stock One, two, three, What have you um, and get customers started with? And you know, if we are going through a with and shift migration getting that centralized operations management getting the enterprise governance of controls right from the very beginning. Um! And we've had customers such as Sally May who use Ams, and and they reported back to us that they were able to develop and execute a disaster recovery plan that improved Dr. Simulation by more than fifty percent

79
00:20:57.790 --> 00:21:27.490
Brian Schoepfle: Um, and they've reduced overall costs by thirty percent and met their savings objectives within the first year, which is a really great story and just really speaks to ah getting, you know, performing, getting through that assessment phase. Um getting into the mobilized phase as quickly and safely as possible. Um and leveraging partnerships um to to get that done, and the partnerships part of it is so critical right like when I was on the partner side, and we were doing a lot of different kinds of migrations, a lot of different kinds

80
00:21:27.500 --> 00:21:49.930
Brian Schoepfle: of upgrades, you know it. It oftentimes would strike me as just like baffling to me, anyway. Why, Why, a business would want to, for example, send their people to a two week training to figure out how to upgrade from exchange two thousand and ten to two thousand and sixteen like. How many times in your life are you going to do that?

81
00:21:49.940 --> 00:21:50.780
Brian Schoepfle: You know,

82
00:21:51.490 --> 00:21:59.539
Brian Schoepfle: if you are going to, and I know this is a very popular phrase at aws. If you are going to shift that undifferentiated heavy lifting

83
00:21:59.550 --> 00:22:16.089
Brian Schoepfle: to aws and focus on your core competencies. You're going to get through that migration faster because you can focus your work on your applications and what's perfect for your construct and let a partner. Let ems build out this foundation for you That makes that migration so much easier.

84
00:22:16.100 --> 00:22:28.540
Jon Spallone: Oh, definitely, no, I great cause I I, too, I came from both sides of the fence, and you know, like you were talking about the exchange side of the house, you know I did that one year, and then the next year, when it was the next upgrade, I was like, forget it. Let's just get it.

85
00:22:28.550 --> 00:22:46.920
Brian Schoepfle: It's it's not worth the time, and it really is, It's It's again allowing that customer the time to focus on their own business strategy, because going back to that mobileized side of the house, you know, crap in crap out, and if they're not focusing on that,

86
00:22:47.090 --> 00:22:56.210
Jon Spallone: and they're focusing on these other things where a partner in aws can help them out, then they can work on those processes that they have, and getting those fine tuned when they're in.

87
00:22:56.410 --> 00:23:12.119
Brian Schoepfle: So when we talk about on the migrate and modernize, we've seen here like the Application Migration service are we talking about? This is where we would actually start to do some application, mapping and understanding of that.

88
00:23:13.070 --> 00:23:42.140
Brian Schoepfle: So hopefully at the assessed phase. We've done a couple of different things, one we've Well, we've talked about like, what does my existing architecture look like, and what kind of architecture or infrastructure could I expect to have inside of the Aws. Pod. What's my licensing environment going to look like? And then, as as part of that. Hopefully, we're doing some sort of application, dependency mapping which makes it, which gives us ah, a better window into a plan for um. What What actual physical infrastructure that we own is responsible for

89
00:23:42.150 --> 00:24:11.890
Brian Schoepfle: um supporting these workloads. And what can we expect to be able to safely turn down after we've migrated without impacting the performance of other workloads. But you know, I really wish it was possible that we could just flip that toggle switch and get into the cloud. But you know, as you know, it's it's very much a Gemmer switch, and we've got all these different dependencies across the environment. And then, you know, lastly as part of that hopefully we're doing some some sort of application life cycle planning right? We're not going through like what's going to be re-hosted with the seven hours right re-host,

90
00:24:11.900 --> 00:24:18.110
Brian Schoepfle: re-platform, re architect, retire um repurchase

91
00:24:18.120 --> 00:24:46.390
Brian Schoepfle: ignore it's not an r but um, you know kind of going through, and you know it's part of an an interesting story about that, you know. Several years ago I was working with a partner as a big service provider to a lot of credit unions across the country. We were doing some some application dependency mapping and trying to go through an application life, cycle, exercise, and we we're going through like I mean It's hundreds of applications, right, and we get to one um The applications called life Seventy

92
00:24:46.740 --> 00:25:02.770
Brian Schoepfle: um, and you know it had some weird performance. It was on some really old hardware, and we're asking the the vp of it really brought into effect of migration like, What's the story with this life? Seventy application. What is that? And he just started laughing, and what he said to me was, Well,

93
00:25:02.780 --> 00:25:12.490
Brian Schoepfle: ah! Life refers to the type of product that it is, which is a life, and it's a life insurance management project, and seventy refers to the year that it was created.

94
00:25:14.230 --> 00:25:27.789
Brian Schoepfle: So So this is something that's literally been limping along, you know, on on legacy mainframe, hardware, since it's inception written in Cobalt, Pascal, or God even knows what.

95
00:25:27.800 --> 00:25:55.939
Brian Schoepfle: And I say Well, speaking of application lifecycle like, What's the What's the plan for this kind of applications? At the time It was very difficult to to modernize the mainframe application to bring it on to the cloud. And he said, Well, there's really only one thing that we can do, and that is basically wait until everybody who's purchased this life insurance product is no longer with us. Right? I mean It's kind of the ultimate. Ah, application, life, cycle, right and very black and white, bringing the bringing the life cycle conversation right to the forefront.

96
00:25:55.950 --> 00:26:13.299
Brian Schoepfle: Um, But it is important to understand and map out what you know. What When are we going to migrate these applications. What are we going to do with them? And what are we going to need to do with them once they get into the cloud, and there are a lot of tools from aws, and our partners that make

97
00:26:13.310 --> 00:26:18.319
Brian Schoepfle: initiating and orchestrating and scheduling these migrations

98
00:26:18.330 --> 00:26:39.799
Brian Schoepfle: much easier. Aws Migration Hub has been around for a couple of years. Now, what I love about the migration hub is that it can pull in data from the application discovery service. It can pull in data that we manually created as part of a migration readiness assessment. It can pull in data from a migration evaluator formerly known as Tsl logic, which is the same tool that we use to execute

99
00:26:39.810 --> 00:26:57.390
Brian Schoepfle: on Ola and then use migration, hub, orchestrator to actually automate a lot of the manual tasks that would normally be associated with migrating these resources into the cloud and the the application. Migration service is absolutely a part of that.

100
00:26:58.640 --> 00:27:05.970
Jon Spallone: So this the migration hub is that fall in here on the how to migrate area?

101
00:27:06.140 --> 00:27:08.670
Brian Schoepfle: Yeah, I would certainly say, like the

102
00:27:08.680 --> 00:27:32.650
Brian Schoepfle: yeah, the um we we would begin using. We start to feed data into migration. Um. As part of the assess process. We start to plan our migrations in migration, hub and migration Hub, orchestrator, as part of that mobilized process. And then, when we're ready to actually, in fact, a large-scale migration we would orchestrate that through migration, hub, orchestrator and Ah, the database application immigration service.

103
00:27:32.990 --> 00:27:48.730
Brian Schoepfle: That's great. That's great, I mean. And this is a huge benefit for a lot of people out there that are looking at these migrations. You know you guys pretty much have cookie cutters in to go through. However, like you and I both know There, there's always that boutique side of the house

104
00:27:48.740 --> 00:27:53.349
Brian Schoepfle: that every organization isn't aware of until they start going down This process.

105
00:27:53.360 --> 00:27:54.090
Brian Schoepfle: It's a

106
00:27:54.100 --> 00:27:57.390
Brian Schoepfle: the big part for me is really like How do we get out of click-ups

107
00:27:57.400 --> 00:28:02.690
Brian Schoepfle: right like um, You know it's we can. It's it's It's

108
00:28:02.700 --> 00:28:27.199
Brian Schoepfle: on a on a relativity scale is is It's much easier for us to test scripts and see where they have errors before we're ready to execute them. Then it is to kind of like I don't know what you're supposed to do like print out a pdf and laminate it, tape it to somebody's task. It says like click here, click there, um, you know. So to to be able to orchestrate these kinds of things validate that the data has been moved safely validated, the virtual machines

109
00:28:27.210 --> 00:28:48.140
Brian Schoepfle: an image correctly and imported correctly. And all this is going on, you know. Well, well, we're sleeping or not working over the weekend. Um, you know. Lets us feel much better about what's going on, because you know, any any time we're talking about the human element, we're going to slow things down and add additional costs and increase the likelihood of error.

110
00:28:50.040 --> 00:29:05.589
Jon Spallone: Definitely. So once we get out of this migration period, this is where we're going to start looking at costs. But but again, like the last note here is that, you know. If you're not following these steps, you're missing things, or you're

111
00:29:05.600 --> 00:29:22.260
Jon Spallone: and effective in this. You're going to have additional costs, anyway. So it's just better to do that due diligence ahead of time, you know. Again you came from. You know my side of the world beforehand. You know how difficult it is sometimes when you're teaching somebody and

112
00:29:22.270 --> 00:29:29.329
Jon Spallone: working with them, trying to help them understand It's not wasting cycles. It's making sure that

113
00:29:29.340 --> 00:29:54.709
Jon Spallone: we're not spending more for this type of implementation. Because if we don't do those check boxes before we go into this migration phase, it's a nightmare. It's a total nightmare, because then you find things as you're moving at the last minutes that you didn't know was there could change things, you know, licensing issues with it, You know, upgrading versions that need to be done. And so it can definitely again pointing back to your stalling standpoint, reintroduce that.

114
00:29:54.900 --> 00:30:12.609
Brian Schoepfle: Yeah, I think you know, professionally speaking, one of the worst days of anybody's life in an it operations department would be the day they have to go to their boss and ask for more money, because the project is is turning out to cost a lot more than they thought it would. And you know, taking the time, you know,

115
00:30:12.690 --> 00:30:23.080
Brian Schoepfle: you know the the older I get, the more I realized that my grandma was right about just about everything she said, and I think everybody's gram at one point and said, A stitch in time saves nine right? And so that,

116
00:30:23.090 --> 00:30:44.859
Brian Schoepfle: getting that understanding what you're going into will not only help you have a really accurate business case, but save a lot of pain down the road, like, you know, nobody wants to be halfway through a production migration, and then find out that some critical service is dependent on a Dns server that's running on a six-year-old power underneath somebody's best,

117
00:30:44.870 --> 00:30:53.389
Brian Schoepfle: or in a closet somewhere. So really understanding how traffic is flowing. How these services are being supported allows us to

118
00:30:53.400 --> 00:31:18.329
Brian Schoepfle: ah allows us to make the the actual migration element of the process one of the most pain-free ah processes as part of this, because we we did the due diligence upfront to understand what we were getting into. We planned appropriately, and whether we're using ams or landing zone. Or however, we're we're bringing things. We know where it's going to land, and we know where it goes.

119
00:31:18.340 --> 00:31:26.689
Jon Spallone: Yeah, When when we did the project on the Vm. That on top, you know, there was a lot of due diligence, and I worked with the

120
00:31:26.700 --> 00:31:56.269
Jon Spallone: some of your counterparts at Aws as we went through to do that discovery. You know where we're going, each step process and that successfully went from the Poc pilot. So now that project has grown to the next phases where we're going to start migrating additional services. So where we started out like you said, it's not picking everything up at once dropping in the cloud, we started out. One particular area that they saw as a business requirement, did all that discovery beforehand, and then actually

121
00:31:56.280 --> 00:32:06.259
Jon Spallone: migrated it. They validate everything with the technology. So now that production is starting to move, and now we can focus on the next stage of services that come into aws cloud,

122
00:32:06.370 --> 00:32:07.430
Brian Schoepfle: he's.

123
00:32:07.440 --> 00:32:15.059
Jon Spallone: So when we're talking about the the the costs on these vibrations, so that that's one of the things where

124
00:32:15.210 --> 00:32:22.930
Jon Spallone: you know. I think is key as well. It's not just. The cost system is a estimation on You know what that that

125
00:32:23.020 --> 00:32:41.590
Jon Spallone: the cost of the instance is running in there on a monthly basis. You know the consumption, you know there's There's additional costs that we have in there overhead as well, and and I don't know It's outlining some of it here, with the cost of productivity, general performance, reliance, and security, and business agility.

126
00:32:41.620 --> 00:32:52.629
Jon Spallone: So I I mean, I think, there's those non-technology cost factors that are in there that need to be taken into account as well, which a lot of people don't think about when we're going into cloud,

127
00:32:52.650 --> 00:32:53.190
Brian Schoepfle: it's

128
00:32:53.200 --> 00:33:11.910
Jon Spallone: one of the things that I love about using. Um the Aws migration, readiness, assessment, and this is something that that our our partners have access to, some that we run internally at aws is that it incorporates a lot of the things that are not going to come up on a a software-based assessment

129
00:33:11.920 --> 00:33:27.409
Brian Schoepfle: and and and one of the things that I've tried to impress upon folks, you know, going back all the way to two thousand and fourteen is. And this is, by the way, a great thing for you and I, John, from a job security perspective. But there is no software substitute for good judgment.

130
00:33:27.420 --> 00:33:51.900
Brian Schoepfle: And so um, you know, going through that assessment to understand. Okay, we're we've right-sized our infrastructure from a four account perspective. We've bright-sized our licensing. Um, You know We We've gone through those sort of mechanics. And what does the infrastructure look like? But this is where the the business needs to get involved and really coach people to zoom out and talk about what is the total cost of ownership of this solution,

131
00:33:51.910 --> 00:34:20.089
Brian Schoepfle: And the total cost of ownership is not going to be reflected entirely on the invoice that you get out of aws. Um! We got to talk about. What are we saving in terms of power and cooling? What are we saving in terms of outages? What are we saving in terms of um, you know, unused infrastructure? And that goes right back into that that modernized phase that you touched on, which is, you know, I think, that just about everybody when they get started with the cloud, you know, and they start taking those trainings, whether it's the Aws

132
00:34:20.100 --> 00:34:39.469
Brian Schoepfle: business, professional accreditation, or they're going all the way up to you know. Solution architect, professional, uh, you know, when they talk about the value of the cloud, like the person that everybody mentions, is well. You have this elasticity and this ability to only pay for the resources that you're using and be able to scale up and scale down on demand.

133
00:34:39.480 --> 00:34:51.749
Brian Schoepfle: Well, um! How many folks in a on-premise environment are really scaling up and scaling down infrastructure on demand. So this goes back to the processes discussion, right? So I've got all my stuff into the cloud,

134
00:34:51.760 --> 00:35:14.740
Brian Schoepfle: and one of the reasons I decided to go to the cloud was, I would be able to scale my infrastructure on demand, and only pay for what I use. But I haven't changed anything about my infrastructure. I'm running completely like for life, and i'm in a steady state environment all the time right? I'm missing out on those benefits. So that's once. I'm. There, now, I need to start talking about. How do I? How do I really start to

135
00:35:14.800 --> 00:35:43.339
Brian Schoepfle: get the extract value from this? I've got out of the blinking, wise business power, cooling all that stuff carbon footprint um and i'm i'm i'm hopefully putting together a plan where i'm taking that Ah, roi and and putting inertia back into that flywheel of success. Ah! To be able to fund these modernization efforts where I can start to maybe um change the way that I've deployed my virtual machine architecture. Can I go to containers? Can I use spot instances? You know

136
00:35:43.350 --> 00:36:01.399
Brian Schoepfle: what can I bring about a so-called serverless or event-driven environment, with Api gateway and and and and aws Lambda, and these sorts of things so Ah, you know when you talk about cost, I think well over what period and incorporating what data points right, because

137
00:36:01.410 --> 00:36:17.219
Brian Schoepfle: at any given point in time our perspective can be very, very different than where we're going to be a year from now or three years from now, and that's what the cloud adoption framework is all about is putting those pieces together

138
00:36:17.230 --> 00:36:29.129
Brian Schoepfle: to understand what we're going to do right so that we haven't affected this lift and shift migration where we've got everything in, and we've turned everything off in our data center, and everybody's standing around looking at each other, going Now what

139
00:36:29.140 --> 00:36:58.839
Brian Schoepfle: right? And we should know we should know what now, what is, and whether that's something as simple as starting to use um, you know, auto scaling groups to to add a little bit of elasticity to our infrastructure, or really start to embrace some of those more modern things that we talked about, and i'm sure uh in in future conversations we'll talk about the different classes of Aws storage, and making sure that i'm I'm using the right type of storage for my workload. That's going to be that's going to give me the performance that I need. But i'm not spending more than a dial

140
00:36:58.850 --> 00:37:08.099
Brian Schoepfle: to, and and that's on everything from object storage file storage block storage, and so many of the purpose-built databases that we have, so it's

141
00:37:08.520 --> 00:37:27.100
Brian Schoepfle: it's never ending um, but that shouldn't be daunting to folks, because um those of us that would like to continue to be employed would like to have jobs that continue to go on right. But it's just we'll have to. We'll have to treat our our knowledge, base our our basic skills, our education

142
00:37:27.110 --> 00:37:55.489
Brian Schoepfle: ah! More like milk than life. Wine, um! Which which which which mine, of course, ages a little bit more gracefully than milk on the shelf and um, and continuing to learn right. The The Aws leadership principle of learning to be curious applies so perfectly throughout this entire process, and having a cloud enablement engine or a cloud center of excellence, puts the organizational framework in place for folks to be able to take their learnings from each stage of this process and

143
00:37:55.500 --> 00:37:57.089
it to what they're going to do next.

144
00:37:57.600 --> 00:38:12.029
Jon Spallone: Yeah, And you bring up a good point. I mean, when we talk about that rubber band Effect of environments in the cloud. The only place I really see that is, is Euc, and that that's about it. But when when we're talking about the infrastructure I mean

145
00:38:12.040 --> 00:38:27.939
Jon Spallone: up a great point. I mean, we're never really bursting services from the infrastructure. It's not like all of a sudden I need to toss in another Dns server, because there's a load of Dns Look ups It's just something that doesn't happen, but it's funny because it

146
00:38:27.950 --> 00:38:39.469
Jon Spallone: it keeps on time back. That methodology, you know, when you bring in Hr: you know your it support staff there. Their focus is now going to be changing and be different like you said, bringing up the point of one.

147
00:38:39.570 --> 00:38:49.109
Jon Spallone: You know. How do I make this environment more optimized to save on those costs? And what services again. What are native to aws that I can

148
00:38:49.120 --> 00:39:12.900
Jon Spallone: flip out from just running a virtual machine, or you know a networking device. How how can I do those things differently, and that's where you enable that that it team to support this environment to take that next step in their knowledge. It's not. You know It's a lot of. I remember when Cloud for, sir, coming around. Everybody's like Oh, everybody's going to lose a job because putting everything in a cloud. No, It's

149
00:39:12.910 --> 00:39:19.219
Jon Spallone: shifting your knowledge. You you have to evolve. I mean, that's been in technology for so long. Now,

150
00:39:19.230 --> 00:39:48.609
Jon Spallone: you know, I around a bbs system way way back in the day with a couple of friends in the basement. So if the technology is worth to change as we go wrong, so these are things that you evolve with it, and that's what Cloud does ground now takes that that knowledge level to it. Another way of thinking things. Another way of of addressing the services you're providing to your business users and to the corporation itself. Make sure you're You're in that right strategy and aligned

151
00:39:48.620 --> 00:39:57.899
Jon Spallone: with your management and business goals to be able to provide them the success they need at the business level, just within the services you're given in their cloud infrastructure.

152
00:39:58.200 --> 00:39:59.290
Brian Schoepfle: Absolutely,

153
00:39:59.300 --> 00:40:03.899
Brian Schoepfle: absolutely, you know it's. And we we look at like

154
00:40:03.910 --> 00:40:23.100
Brian Schoepfle: all these factors that go into what could potentially be the total cost of ownership of a solution. And there are certain things that are. They're very, very concrete, which, like what are we spending for a month? And then there are certain things that are much more ephemeral right like. What is the value? Can we put a monetary value on agility? Can we put a monetary value on security?

155
00:40:23.110 --> 00:40:52.049
Brian Schoepfle: Um, you know, I I think. Ah! Ah! Many organizations probably do not have the level of of visibility and kind of self-knowledge about their own operations; but if they if they dive a little bit deeper to understand what some of these legacy practices, what some of this tech debt is actually costing the business in a real dollar's perspective. These migrations become like a no-brainer. It's it. It it goes from I'm: not sure. If the cloud is right for us to

156
00:40:52.060 --> 00:40:53.970
Brian Schoepfle: how soon can we get started.

157
00:40:54.760 --> 00:40:59.099
Jon Spallone: Yeah, And I mean, and honestly, too, from a cloud standpoint

158
00:40:59.160 --> 00:41:17.600
Jon Spallone: that that investment and that savings you don't see that day one. You know those are things, and that's that's the other thing I try to help. Customers understand is, you do see it as you evolve within the cloud. You're not going to see it in day one, so everybody goes. Stick your shock and freaks out, but it's like. Look

159
00:41:17.740 --> 00:41:37.219
Jon Spallone: once you compare this again from the cost standpoint. What you're running today, and how you're operating. You're going to see that over year. One, two, three, You're going to see that cost savings. And again to your point. You're morphing those services on your infrastructure side of the house where you see additional savings on it. So it's there.

160
00:41:37.230 --> 00:41:41.679
Jon Spallone: It's just not the immediately from day one that people need to understand

161
00:41:41.800 --> 00:41:46.780
Brian Schoepfle: that all nearly every single one of our customers like to the one, the

162
00:41:46.790 --> 00:42:07.029
Brian Schoepfle: reports being more our by the longer they're in the cloud, and the more work that they're doing right so exactly to your point. Like day one it, it. It may be more costly than you expected. But day three hundred and sixty six. Hopefully you're You're already starting to recruit some of that value. So it's it's It's about like.

163
00:42:07.040 --> 00:42:08.330
Brian Schoepfle: Ah, you

164
00:42:08.340 --> 00:42:37.649
Brian Schoepfle: where you fix your eyes to the horizon. Right are they, you know. Is it going to be six centers in front of your toes, or is it really going to be on the horizon, and it's important to fix your eyes, I think, on the horizon. And you know one of the things that that Andy Jassy has said so many times, and it it rings. So true, is like the number. One factor that he sees in successful problem migrations is a top down. Executive mandate to say, we must do this like we're going to do this, and I don't care it's time to go

165
00:42:37.670 --> 00:42:54.400
Brian Schoepfle: um. So you know, with with this kind of stuff, and if you really even just getting started like um, the best time to start was yesterday, and the second best time is right now just to get started on. You know the clot adoption framework to get started on on doing some of these assessments, and

166
00:42:54.410 --> 00:43:01.749
Brian Schoepfle: and but don't be afraid like Jump in with both feet. Rip. That Band-aid off start learning, because

167
00:43:01.950 --> 00:43:06.489
Brian Schoepfle: the faster you move the better off you are long term

168
00:43:06.500 --> 00:43:07.299
Jon Spallone: it's

169
00:43:08.480 --> 00:43:18.899
Jon Spallone: So let's see if there's some examples of defining those success metrics. I'm. I'm a huge person. It loves the metrics. I want to know

170
00:43:18.910 --> 00:43:47.119
Brian Schoepfle: how I can measure these things. I do it across the board for everything. I've learned that when I work for a software partner a long time ago Um, you need to see that business value side with. So I need to have measurements as I go along to make sure i'm hitting that value, and if not, it gives me a pivot point, and I know why i'm pivoting because I have those numbers to back up what i'm doing. Um! I also know there's some freedom to it. But it's nice having those metrics out there. And then there is

171
00:43:47.520 --> 00:44:13.369
Brian Schoepfle: There's There's no Cio on the planet who at the end of the year gets to go into executive order, and they're like, What did you do? And he or she just puts speed up on the desk and goes well. We went to the cloud. Right like it has to be connected to something so define it, connecting those metrics, whether they are observable or measurable, connecting those metrics to everything that we do,

172
00:44:13.380 --> 00:44:17.790
continues to help us go back and revise that business case.

173
00:44:17.800 --> 00:44:41.450
Brian Schoepfle: That business case, you know, should really be like a living document because we're going to learn things about ourselves, and we're going to learn things about the cloud that's going to adjust. You know what our business plan is what what we're actually going to be saving, the more that we learn. So um! You know the the metrics need to be said at the beginning in terms of what's the business value that we're expecting to get out of that. And then the dimension of those metrics, I think, will change over time.

174
00:44:41.460 --> 00:44:42.679
Jon Spallone: Oh, yeah, it's actually.

175
00:44:43.610 --> 00:44:54.520
Jon Spallone: And there's There's the additional tools here that help out with that like I was just showing you the qualifying some of the cloud benefits here, going through some additional stuff.

176
00:44:54.660 --> 00:45:06.090
Brian Schoepfle: Now, we're talking about improving migration costs visibility and predictability. And this is in the mobilized phase. So what we're really talking about here is

177
00:45:06.190 --> 00:45:13.920
Jon Spallone: making sure that we're aligning. Am I correct with our migration, and what what we saw in the beginning and where we're going?

178
00:45:14.830 --> 00:45:18.029
Brian Schoepfle: Yes, Yes, you know, we were

179
00:45:18.160 --> 00:45:31.160
Brian Schoepfle: one of the things that we're going to realize as a benefit as soon as we start moving into the cloud. Is we are going to have a level of observability and granular level detail into

180
00:45:31.390 --> 00:45:33.989
Brian Schoepfle: what certain things are costing us

181
00:45:34.040 --> 00:45:39.390
Brian Schoepfle: that will help us modify our roadmap like. I don't think that there are many

182
00:45:39.400 --> 00:46:07.739
Brian Schoepfle: it organizations, especially in the Smb. Space or the K. Twelve Space, or the State State and Local Government space. Who could tell you like, what is the cost for database transaction that we have in a on premises Environment? What is the cost for Dns? Look up that we have on our on Pns server, but we are going to be able to see that um inside of aws. Well, that's going to give us a lot more data that we'll be able to use to, to to continue to fiddle with those knobs

183
00:46:07.750 --> 00:46:24.509
Brian Schoepfle: and tweak our architecture, tweak our application deployment strategy to do this really cost effectively. And so we have, you know, things like aws, budgets and cost anomaly detection to alert us when when things are gonna be, you know,

184
00:46:24.520 --> 00:46:41.439
Brian Schoepfle: perhaps costing more than than we had anticipated. But we also have things like the cost, intelligence, Kpi Dashboard, trusted adviser. These other things that will point out opportunities for us to save additional money, one of the next reserve instances and saving plans, or or unused resources, or things like that.

185
00:46:41.830 --> 00:46:53.739
Jon Spallone: And this also helps out with another thing that I think a lot of people don't understand about Cloud when they're moving into it from from an it Management standpoint is you now get to

186
00:46:54.740 --> 00:46:56.020
Jon Spallone: build out

187
00:46:56.030 --> 00:47:24.479
Brian Schoepfle: um buildback charge back to departments for those it costs where today, you know, a department comes in and says, sales says we need this solution. You got to implement it, you know It's got to find a budget for it. We're going to stand it up. We're going to set it up, and you know we're going to incur the cost to support this environment. And then that's silo. But let's say marketing comes in, and they need the same solution, but marketing needs their requirements. And now that's silo. So now, when i'm at a cloud side of the house,

188
00:47:24.670 --> 00:47:37.480
Jon Spallone: being able to track these costs I can now turn around and say, Yeah, we can provide you those services. And here's what your charge is going to be. And now it starts to become a money making machine internally to the company.

189
00:47:38.430 --> 00:47:41.900
Brian Schoepfle: Yeah, And that's why it's really important. During the

190
00:47:42.290 --> 00:47:48.769
Brian Schoepfle: later stages of the assessed phase. And in that mobilized phase to come up with the

191
00:47:48.780 --> 00:48:18.609
Brian Schoepfle: a good cost, allocation, strategy, and a good tagging strategy. Right? What are the metrics? What are the metrics that we want to try to derive from our resource consumption inside of aws. Is it a scenario similar to what you describe right, which is like? We would really love to be able to report back to the organization what each new demand generation campaign that marketing runs actually puts up as a cost, for on it. We would love to be able to tell what what each new micro site that we stand up that is actually um driving out of our or driving our

192
00:48:18.620 --> 00:48:38.289
Brian Schoepfle: and increased it cost, and it's It's not only going to help the the Information Systems Department optimize their own performance and their own resource consumption. But it's going to provide an incredible level of detail back to the organization, to really start to understand. Where can they be most profitable? And where do they need to invest

193
00:48:38.320 --> 00:48:48.220
Jon Spallone: definitely. Beverly I and I'm a huge proponent for that, too, because it always gets kicked around this Redhead stepchild because they're the ones that cost the most money.

194
00:48:48.230 --> 00:49:00.290
Jon Spallone: I mean, back in way way back in the day it was associated with the accounting department. And so there's that natural marriage of money and technology together, and it's always been that way.

195
00:49:00.300 --> 00:49:12.090
Brian Schoepfle: So it's sort of like looking at your car payment every month and seeing that as a true cost without incorporating the fact that you're also an Uber driver and extracting some value back out of it. Right?

196
00:49:12.100 --> 00:49:15.740
Brian Schoepfle: Yeah, it's not secure cost. It's driving business value.

197
00:49:15.750 --> 00:49:18.969
Jon Spallone: Yeah, definitely, it's a good point. I like that analogy there.

198
00:49:18.980 --> 00:49:34.800
Jon Spallone: So from there, once we've gotten that visibility into predictability within it. Now, we can start optimizing and maximizing our roi, which you know we've pretty much been discussing here, and being able to utilize some of these additional tools

199
00:49:35.070 --> 00:49:39.399
Jon Spallone: again. I do find it funny, you know, until you've brought it up.

200
00:49:39.820 --> 00:49:45.789
Jon Spallone: You know I never really associated, you know i'm not bursting. I'm not, you know,

201
00:49:46.020 --> 00:49:58.029
Jon Spallone: ballooning up and down on the infrastructure side of the house. And again, that comes from a lot of my experience with the you see, it is natural for people just to say, Oh, we're going to be able to handle that

202
00:49:58.540 --> 00:50:00.630
Jon Spallone: fluctuating the

203
00:50:01.990 --> 00:50:11.889
Jon Spallone: the infrastructure costs as users demand. Come up, you know, like season and stuff, but the infrastructure side from that is never really going to change.

204
00:50:11.900 --> 00:50:21.279
Jon Spallone: You know that's always there. So that's why you've got to evaluate what other solutions are out there, and again that helps to maximize that roi for the organization.

205
00:50:21.800 --> 00:50:25.810
Brian Schoepfle: So you can't from an on-prime perspective like you can't

206
00:50:26.200 --> 00:50:32.089
Brian Schoepfle: take a pizza that's been caught into eight slices and cut it into sixteen slices, and and expect to feed more people

207
00:50:32.100 --> 00:50:44.410
Brian Schoepfle: right? So on the on the infrastructure side We've got like a set amount of resources. But that's not the case inside of aws right in an on-premises environment. If you want to add another writer, node to your database, because you've got a lot of

208
00:50:44.420 --> 00:51:01.619
Brian Schoepfle: right intensive workloads, or you're writing the reader note because you've got read and tens of workloads that's going to be a slice out of the same pie that you're already operating out of. But that's not the case with aws. So it's time to start thinking about. What do I actually need to provision as a bare minimum. And where am I able to burst?

209
00:51:01.630 --> 00:51:16.200
Brian Schoepfle: Um! And And and one thing that I like, I as we're talking about modernization that I I I really feel remiss if we didn't talk about one of my favorite things. Um! That that that a of us has released in the past. Probably a year and a half is of a service called Babelfish

210
00:51:16.210 --> 00:51:31.929
Brian Schoepfle: and Babelfish. Is this intermediary database translation layer that will natively take sql queries from your windows application and convert that to my sequel.

211
00:51:31.940 --> 00:52:00.270
Brian Schoepfle: So now I can get out of costly proprietary database licensing without making any changes to my application code like That's one of the easy like turn key ways that I can start modernizing my infrastructure. Now i'm turning down the amount of proprietary database licensing that i'm paying for, and again taking that roi using that to add additional inertia into the flywheel. And now maybe I can go start to look at re architect, or modernizing my applications, taking that and that stuff off.

212
00:52:00.280 --> 00:52:28.230
Brian Schoepfle: I got that, and in the dot net four and the more Linux workloads I have the more i'm able to take advantage of of graviton, which is going to give me incredible price. Performance versus x. Eighty, six architecture. I'm. Going to give me incredible price performance versus the amount of proprietary licensing that I was paying for. And oh, by the way, with the with the reduced amount of power that i'm actually consuming. If my organization has Esg goals,

213
00:52:28.240 --> 00:52:32.399
Brian Schoepfle: my carbon footprint for my workloads has decreased dramatically,

214
00:52:37.900 --> 00:52:39.840
i'm gonna have to take a look into that one.

215
00:52:39.980 --> 00:52:40.589
Brian Schoepfle: Um:

216
00:52:40.600 --> 00:53:08.429
Jon Spallone: yeah. So what we've got into here now is once we get into that migration phase and take a look at it. And you know, like you're saying here with babel-fitch-side mouse storage life, cycle policies, you know being able to optimize some of that. Ah, really, we go into a graphic here where it discusses those phases, the assessment rise, migrate, modernize, and you know I I think it's. It's pretty simple, I mean, I know there's a lot of words at what we started out with here, but

217
00:53:08.440 --> 00:53:23.440
Brian Schoepfle: I think this sums it up really nice. As far as you know. These are these three approaches we're going to take. And then within there, there's those four different types of items that we need to punch down within those, and that's, you know, c. Save plan and run,

218
00:53:23.450 --> 00:53:47.930
Jon Spallone: and we want to make sure that we don't stay in a planning stagnant in a planning phase, and we don't want to stay stagnant in that run phase. We we want to get out of those to be able to take those next steps. So I definitely like this as far as the methodology and approach here of what we're looking at. So I mean when we talk about these solutions and getting into the cloud,

219
00:53:47.940 --> 00:53:54.980
Jon Spallone: I don't think you can get much easier than breaking it down. How you guys have specifically in this blog here, too.

220
00:53:55.220 --> 00:54:07.149
Brian Schoepfle: Yeah. And you know, as we close out here, One thing I want to impress on the audience is another thing that Andy, Jessie said in a couple of interviews, which is, there is no compression algorithm for experience.

221
00:54:07.160 --> 00:54:36.479
Brian Schoepfle: Aws and its partners have been doing this for a very long time. And, John, you and I, as technologists, we'd love to dive into technology and and talk about how sexy it is, but really like we're talking about business value outcomes and let aws and its partners figure out like what's of the you know, two dozen different storage options that I might have in aws What's right for me like you don't have to

222
00:54:36.490 --> 00:54:52.789
Brian Schoepfle: about that. And because so much of this is delivered as a managed service. You will never have to think about it, and and really focus on what's driving value for your business or your customers, and oftentimes that's not, you know, monitoring your storage architecture.

223
00:54:52.800 --> 00:54:53.290
Brian Schoepfle: Yeah,

224
00:54:53.300 --> 00:54:54.490
no, definitely.

225
00:54:54.500 --> 00:55:18.800
Jon Spallone: And and I mean it's a great point to close it out on here. I do appreciate your time today, Brian, discussing this, and I want to open it up to anybody. If you have any questions, please feel feel free to respond online. You know we'll get those address as they come up. I know some of the stuff we'll be posting this later to our Youtube page. So once we get that up there you can comment,

226
00:55:18.810 --> 00:55:46.989
Brian Schoepfle: give us some feedback, and then we'll make sure we can get it back, and I think this is going to be really fun. I'm looking forward to this. I know this is our first time working out on this, but we're looking at a regular cadence of about every two weeks for posting. I think there's a lot of good information out there that can be shared with the community, especially around. Aws like you said, You guys have been a workforce. You've been out there longer. You were the model that everybody else built off of. And now

227
00:55:47.000 --> 00:55:50.619
Jon Spallone: it's kind of it's, you know. It's like um

228
00:55:50.630 --> 00:56:15.260
Brian Schoepfle: remembering that really cool toy when you were a kid, and it was, you know. Was it the the toy story, you know he loves woody. And then all of a sudden, buzz, light! Year comes in, and he's now the cool toy, and and all of a sudden I realized. Hey, you know there's a lot of good memories here with Ah, Woody, Let's go back to that. So I I think people are starting to come back to aws for that understanding that you guys know what you're doing. I mean this isn't

229
00:56:15.440 --> 00:56:25.390
Jon Spallone: this isn't a no-brainer. It's not like you guys just built out a cloud and pushed out yesterday. It's it's been around for wrong proven technologies. So what we'll do here is we'll

230
00:56:25.700 --> 00:56:33.090
Jon Spallone: continue on. I mean, I would like to, maybe have one session where we cover some of these things like Babel fish and go through that it.

231
00:56:33.100 --> 00:56:33.790
Brian Schoepfle: You're here

232
00:56:33.800 --> 00:56:43.499
Jon Spallone: thing to cover those. But again, Brian, I appreciate your time, and I look forward to our next one and everybody else. I appreciate you for listening in with us today.

233
00:56:43.720 --> 00:57:00.459
Brian Schoepfle: Yeah, there's there's so much here to unpack, and you know we could do a deep dive on just about anything that we discussed, and um, you know, would love to hear audience feedback on anything that you'd like us to dive deep on out of anything that we covered today, or or anything that we didn't so lots of cool stuff to talk about on the look forward to doing this with you.

234
00:57:00.470 --> 00:57:01.970
Jon Spallone: Gosh, thanks, Brian.