Migrating a Monolithic Application to Cloud-Native using Google Cloud Platform Tools
Transcript
(suspenseful music) >> Hey, it is Keith Townsend, Principal of the CTO Advisor and I'm joined today with Alastair Cooke who has served as both my developer and my operations team on this Google Cloud Adventure, Alison welcome. >> Thanks Keith and it's been a fun little project we've been working on. >> It has been a fun little project. Let's recap what this kind of is and is not. Google cloud reached out to us to take a look at their automation tools for automating or assessing your environment, and then moving your on-premises environment into the public cloud in a way that makes sense and I think I'll leave the why is this important part up to you?
You've had years of experience in public cloud providers such as AWS, Google Cloud, et cetera. Why is this even important? >> I think the most fundamental thing is that we built IT on-premises with trying to change applications as little as possible and we've got virtualization that allowed us to keep these same applications for a long time unchanged. When we take those same applications and try and move them onto the public cloud, it mostly doesn't make sense to leave them unchanged. The best economic outcome and the best business agility outcome is driven by using the cloud native services, not using cloud services as if they're on-premises and so fundamentally, this is where applications need to be changed to greater or lesser extent as you move from on-premises onto public cloud if you want to get the best benefits, you can certainly just evacuate your data center and not change anything, but that's going to still cost you quite a lot and not give you this all of the cloud benefits.
>> So all of the both economic benefits in the physical benefits, a aha moment for me throughout this whole process has been, even if we don't change a monolithic application and we're able to put processes into containers that gives us the ability to auto scale, a service that couldn't be auto scale before, we could only vertically move it up. There's some work to be done. It's not magic, but it gives the base capability and gives the SRE team the ability to do this.
So, overall let's kind of put it out there. I think I've painted this picture that we have this capability potentially take a monolith, put it into components of it and into a container and auto scale. It's not that easy, right? >> No, and generally, something that was built to be a monolith, there's a whole lot of assumptions about everything running on one machine and so generally, that monolith still has to continue to vertically scale when you move it across. Now, vertically scaling on a container is very similar to vertically scaling on a virtual machine, but you can take away some of the other operational processes around the virtual machine like having to maintain the operating system when you move across into a container, and so, it's another level of abstraction of handing over that the same task that everybody does, right?
Everybody patches Windows Linux using the same processes. That sounds like exactly the thing that should be done at an industrial scale rather than being done by every customer, every tenant and so, that's where some of the containerization gives you some benefits around reducing those operational tasks, handing them over to a specialist who does nothing else. >> So, we had a couple of different applications to choose from. We actually ran the Google tooling on both. There's the Obsidian application and the Granite application, essentially the same app, right?
>> Yes, so I developed originally Obsidian, sorry, Granite. I originally developed Granite to be a distributed application that ran and generated workload in our data center and so, its objective was just to generate workload across multiple virtual machines, across multiple types of resource and that's a good sort of conceptual idea of this distributed application you want to migrate, but we wanted to reflect a monolithic application as well, so I basically consolidated all of those pieces that previously had run across six different virtual machines.
I consolidated them all down to a single virtual machine and that's what Obsidian is and that was the primary focus in this migration because we wanted to look at monolithic applications not moving cloud native applications. >> Now we're showing the workflow of this app. Now, can you just basically tell what it does? >> So within the application, there's a MySQL server that hosts a large collection of tables. There's a group of workers that essentially do lookups against the table, order products out of a catalog so there's an automated process of randomly generating orders and place those orders into a queue to be serviced.
That queue also resides inside the database. There's a bunch of other processes that then read that queue and either request manufacturing of some components or order components, or if we've got all of the parts assemble it, and so, these are just a series of worker tasks that run and try and look like a real business process with clients connecting in and placing orders and having those orders fulfilled. >> So, even with our monolithic version of the app, it's fairly a clean app. It is a well, I think developed app kudos to you and if you go back to an unsponsored video that or content that I did with Miles Ward, I'll link it in the show notes below, we talked about, he has a team of 402 sole consultants that have seen 3,300 different use cases and variations.
So, this isn't meant to be a absolute roadmap to how you modernize an application. I don't think there's such a thing exists. This is more of an effort to show you that Google's tooling either works, doesn't work or something in between. It's just a level of effort. It's what is insight into our application that we completely understand, and the value that mfit and the other tooling brought to the CTL Advisor Hybrid Infrastructure. So Al, tell me what is your expectation or was your expectation for mfit and well, I guess a step back, what is it?
What does it do? >> So, the objective with mfit is to look at your on-premises environment, discover what you have in terms of virtual machines and physical machines and discover what's installed, and then do the mapping analysis of what you've got might work on these Google Cloud services and it produces a couple of reports. One is the one that Keith had hand to you which says out of our estate of however many hundred servers that we have, this many of them are going to be easy to move and these many are going to be harder to move.
That's the bit that I give to my executive and say, this is the scale of project we're working on. And then, there's a second report that it produces which says, this particular candidate for movement, this Obsidian virtual machine, here are the platforms you could migrate to and here's the amount of effort required. Take a VMware virtual machine, put it onto the Google VMware engine, very little effort required. It's just a migration across, whereas taking that Obsidian machine and putting it onto Google, the Kubernetes engine right into containers.
Well, there's a blocker on that. The original report said there are about four different blockers you need to fix before it's ready to go onto GKE, and I really like that, and it said, here are the blockers and it assesses if you're going to go to this platform, it's this amount of work. If you're going to go to cloud run, well, actually it's not going to fit on cloud run because that big monolithic machine is too large to run in cloud run. So, it gives you this collection and I really like that this collection of different locations that you could migrate this application to, and an indication of the effort and the specific items and that report is the one that goes to the engineering planning team who are saying, "We're going to migrate these applications in this order.
We know the dependencies between our applications, so we're going to get them in the right order," and Keith, I think this starting to get complicated is a really important aspect here. We've got large numbers of applications. This is going to be complicated. You're going to need to slowly build the expertise. So the sorts of things that we are showing in this migration of Obsidian, and when I do the Granite migration, these are the beginning steps as you build some knowledge and expertise inside the organization that's migrating, you should expect to have to walk before you run, but progressively you build out these skills and these processes that help you migrate the application.
Using some of the migration tools that Google provides, but potentially also using application migration tools that doesn't have to be Google provided tools, but this report gives you that structure around how difficult different things are going to be to move to different platforms and you'll probably choose different platforms and different changes for each of those applications. >> So, this is the meat kind of the project, what we described or what we talked to Google about was how do we get to factory mode? Basically, the ability to alleviate one of the biggest challenges and this is what I headed to in the introduction video of developers.
I can't take my developers off of building net-new capability to go back and retrofit legacy applications for the public cloud, so that IT infrastructure, IT platform can save money or better run legacy infrastructure. That's not typically the big business value of cloud, not initially, at least. We eventually get there, but the problem has to be solved. So for me, this project was a question of, is this something that I can eventually prototype to get to a factory mode? That process you just talked about of building the muscle, building the capability within my engineering op scene to manage the migration of, let's be realistic.
You're not going to migrate every app without developer assistance, but can we knock out a good chunk of it? Can we make a difference? And I think we got some insights to share, so let's talk about that migration process. What was day two after running the mfit assessment from the engineer perspective? >> So, coming off the mfit assessment, the logical first thing to do is pick an app that's going to be require some effort to migrate onto a more native platform and we knew we were choosing Obsidian beforehand, the monolithic one.
And out of the mfit report, it said, "Here are some changes that need to be made to make it suitable," and I looked at the set of changes and some of them, I decided to make in place before migration. So for example, because the application had been migrated from a distributed application to a monolithic application, it previously used an NFS share for some of the distributed processing. Well, the migration tool said, "This is a red flag for several of the platforms. It'll require additional configuration.
I just looked at well, let's resolve out that technical debt of having taken a distributed application, made it monolithic, and let's just use a symbolic link instead of doing a loopback NFS mount. And so, there was that, and there was a, I made a change to the SQL configuration, the MySQL configuration in order to enable replication later on, so there was some small changes that I made before migrating. And then, I used the migrate tool that once you replicate your virtual machine, so replicate from on-premises vSphere it directly into the Google compute engine, so the first proof point for me was completing that replication and standing up a copy, a test copy of Obsidian on Google compute engine while the production copy was still running on-premises, so that was my first proof point of the migration process.
Now, if we're getting to factory mode, that test is probably going to be redundant if we've done sufficient previous processes successfully and of course you can always fail back so at production line, you're just going to go straight through and stand it up because it is nice-- >> If we have our traditional V2V processes, we're strongly in them. The only thing that, and I would argue that we're not even adding anything new here when we did P2Vs, we run assessments to find out what would break if there was any hardware drivers or things, not even just hardware drive is integration into hardware like compact tooling installed on a server that would get migrated.
We knew to run some process that would remove or deactivate those services, move them over V2V or P2V and now V2V. This is a solve thing. We know this part of the process from historically migrating tens of thousands of physical or virtual machines to either the cloud of virtualized environments. Let's talk about that next step. What's different? We've taken that application. We've moved it to our virtual private cloud or private cloud network, public cloud network. What's next? >> So, the next flag that mfit had brought up, and I actually ran mfit again to do an assessment of what I'd migrated onto a Google compute engine and you can use it again.
" It said, "It was absolutely in several of the destinations that said, one of the things you need to do is migrate the database to Cloud SQL," so that was the next thing I did. Cloud SQL is SQL database server as a service that GCP provides, and so, this is why I'd made a change to the database engine before I started the replications because I needed the database engine to be configured for replication as well. And so, I used the migration for Google cloud engine, sorry, Cloud SQL.
I used that migration tool which essentially sets up active standby replication, so, my replicated SQL engine inside my Obsidian machine was replicated to Cloud SQL, and then, I just pushed a button to switch it over, changed the DNS record that told my application where to find its database and the application was then running on Cloud SQL, so that took the database engine app. >> That's actually pretty cool. I mean that in itself, how many times have we gotten into problems with ownership of a monolith where the DBA said I needed to do something and the app owner said, there's no way you can do that or vice versa, and now we've literally separated that responsibility in an automated way.
>> And we've taken away the requirement to manage an operating system and a database engine, and when just now managing the database. And so, I like moving to some of these as a service delivery. This is how even without changing my monolithic application, we could get some of the benefits of being on a cloud platform because we don't have to manage as much. Again, we hand over that regular routine work to somebody who's turned it into a manufacturing process. >> And this is where I talked about, well, we're not nearly to auto scaling.
We're starting to lay that infrastructure for auto scaling. We've removed the dependency that mapping of the monolith of the database being in VM, if you've managed the production environment at any scope, we typically almost always have to increase the resources given to a monolith because of the database. Now, we can right-size the infrastructure and this is where we're starting to see some of the cost savings, even though we're still running in a VM, we can shrink the size of the VM and now start to use the need of cloud services.
>> Yeah, and this is the idea of you move the application and then you improve the application and the simple migration into places sell them the best solution. Usually, there is some way to improve the application and your best value and business value comes from that improvement but also, as you start looking at your application, you may be saying, "Well, we've got to add on to our existing monolith. Our existing monolith isn't good for mobile and web applications, but it's where all our data is, and so, you may not actually plan to change the monolith, but you're moving to cloud because you need the agility to build all of the other support components around it and you're probably going to build those support components in a way that is, or these new platforms in a way that is cloud native, even if you leave the monolith in place that may be where the business value is from that agility around the monolith.
>> So, let's finish talking about the migration of the monolith, what was next? >> So, the next thing was to take a look at moving the monolith from a virtual machine into a container using the Google Kubernetes Engine. And I did this two different ways because there's two different flavors of the Google Kubernetes Engine. The first thing was that it said that building your own compute hosts, your own worker notes will let you have the most flexibility about resources because this is a big monolith.
Even taking the database out, it's using a lot of memory and a lot of CPU and so, I did that migration into a GKE cluster that was built inside my account and that I was managing, and that went really nicely and then the team at Google, who we were working with said, "Well, why don't you try GK autopilot? Actually, somebody tweeted the same thing at me so okay, try that. And now it's a cluster that's this Kubernetes cluster that I don't have to care so much about and the resources underneath are much more automatically provisioned.
Now, this is where the resource constraints became an issue because initially the recommendation was don't take this to autopilot because it needs more resources than autopilot likes to deliver. And so, taking the sequel engine out, reduces the resource requirements. Now, I'd need to do some testing to make sure I'm getting enough performance out of autopilot, and that I've completed things correctly and there was just a little space for improvement on that process of mfit going through to the autopilot migration was that there wasn't quite enough information being passed on in particular, the amount of resources that I needed on the container running in GKE hadn't come through from mfit.
It would be nice to have a little bit more integration where it says at source site, it uses this much resource, how much resource do you want to have at the destination site and the product teams have now started talking 'cause I suggested that. >> I love one of the things that we wanted to probe in our experience is that we've heard big that Google Cloud and Google in general, doesn't listen to feedback from their customers and I think we've found quite the opposite.
They were very anxious to hear our feedback. I don't know if that's unique because we're doing this sponsored project and that we're putting it out there, but in general, when I talk to their evangelists and their advocates in general, they seem to really want to make the product and tools better. >> Yeah, absolutely. I definitely see people who are enthusiastic and excited about what their products do and that are realistic. So, one of the comments I made is I found that the documentation is difficult because it's documentation written so that a single document covers every possible use case and I find that really hard because you've got to identify the track that actually maps to your path and when there are so many different ways you can use these tools, the documentation gets to be a little cumbersome with that, and so, this is a little bit why I've been starting to write up procedurals of this is the exact path to follow up.
This is your very common start point and this is your very common endpoint. >> We sometimes forget that we're in a fast moving part of the industry. We have the conference me and you have been in the enterprise data center side of the house for years and there's very prescriptive recipes for almost every use case, whether it was created by the vendor that's products that we're using, or if it's simply community driven content and we can just find a recipe. You're famous for your recipe for building and tearing down VMware vSphere environments is kind of a solve solution.
We haven't gotten to that point yet. >> I think there's on public cloud, there's much more of an expectation. There'll be expertise in building and understanding your uniqueness, and I think that's one of the things that hooks back to that podcast that you did was that there was that 3,000 plus snowflake items that had all been moved, right? Expect that you'll have snowflakes to move and moving snowflakes is perfectly normal as you migrate onto Google. >> So, we've talked a lot about what we've done technically in the process.
I think people are getting the gist of what the tooling enables you to do, but let's talk about subjectively. Subjectively, is this something that can be come a factory like what's the level of skill that I need operating at this level when we're doing the assessment of applications, do I need somebody with deep development expertise or given the application state that we, or slate that we worked with? Is this something that the SRE type of resource can do? >> So I think the phase of discovering the information is very simple.
The knowing what to do with that information and do the migration is the place where you're going to need to build some skills and expertise. And so, a large organization is either going to build it in-house or buy it in, but there needs to be that ramp up in skills and experience. You are going to be using pretty skilled engineers to work out a good path to migrate without large outage and impact, and this is the sort of place where if you start doing things wrong, things will go very badly for you.
If you don't identify that there is a critical dependency between different applications that you're using and you migrate one and haven't identified how the other one is going to talk to it. Those are the kind of enterprise architecture and enterprise connectivity, or at least that the technical architecture levels that you are still going to need. Moving to the cloud doesn't remove the need for both enterprise and technical architecture. It just makes application architecture even more important. >> When I was talking to Miles Ward, I get that impression that, yes, this is something that enterprises can tackle on their own.
The tooling really helps, but this is a problem of scale and availability and experience. You were extremely experienced in both the Obsidian and the Granite app, so you, when the report ran and it said to change these things, you knew exactly where to go and where the change and had an ideal of the impact. I think organizations won't initially be able to move that fast because they don't, or at least they're trying not to use developer resources so there's a lot more testing.
There's a lot more validation. There's a lot more steady state moving. Let's talk about the future in a couple of ways, we can't talk about public cloud without talking about serverless and cloud run. Did we get to play with serverless and cloud run at all? >> So, I haven't yet played with cloud run because Obsidian is this big monolithic application doesn't suit that, but Granite with its distributed nature, some of the virtual machines that make up Granite were recommended for migrating to cloud run.
So, the smaller, more transient workloads that suit serverless platform zone in particular, I could see some real benefits as the developer of the application. I can see some real benefits of moving towards serverless and just having to have there's a scheduler component in there and actually using a pre-built scheduler rather than having to write my home, that is really appealing, and so, I think in terms of future, this path from having separate operations team and development team is really at odds with the DevOps movement that we are seeing where those two teams come together and they look after a particular application.
This is the thing that really is important towards enabling this public cloud use case in use of these cloud services is the operations and the development teams coming together and that's essentially what SRE and DevOps is about is holistic ownership of the application from development to operations rather than these siloed teams where the developers throw the application code over the cliff and the operations team really aren't very involved in the development. >> You're kind of exploding my mind right now because there's a ton of things we haven't talked about.
We haven't talked about observability. We haven't talked about break fix, so that SRE model, we haven't talked about application life cycle development, CI/CD processes, all these new technologies and processes and people skills that's needed to manage cloud that's at odds with how we've managed applications in the past, and this whole transition from one model to another and in some cases, if we're being honest, we're going to have both. It may not be a transition. It may be that we have this legacy monolithic approach because we deemed it too hard or not worth the efforts even use these tools to migrate.
>> Absolutely, so that, that idea that you're going to put the effort where there's business benefit, that's absolutely fundamental. And so, there will be times when you'll just pick up your monolith and move it and say, "I need it close to the new stuff where there's business benefit to me spending that money, but I don't get a lot of benefit out of changing this, right? It still runs my manufacturing plant, the way it has run my manufacturing plant for the last 20 years.
I don't need to change that. I need to change the way I take my orders in and drive that manufacturing plant, but I don't need to change how the manufacturing plant runs, so, absolutely, there will be this coexistence until there's some mass extinction event and the last one was Y2K. These things are going to hang around. They're not going to go these applications that we've sunk a lot of effort into building business processes into code. They're not going to go away just because there's a new way of building business process into code that's quicker and better.
>> So, I always love teaming with you. You're the brain behind my marketecture and you really help put meat behind this. For those who want to find your organization's content, where can they do that? nz like the small cup of coffee that I drink from, but I put content out in a variety of different places. com where I work with yourself on some projects as well as with Jeffrey Powers and that's the hands on technical procedural stuff, whereas on my Demitasse blog, you're more likely to see the more conceptual components.
I did a series recently on how to think differently about building applications on public cloud. It was targeted at a different public cloud, but the learnings are exactly the same. com is another place to go and find lots of content, not so much of mine, but content that I've enabled other people to create. That is again, targeted at the hands-on engineer. >> And if you want to find out more about the CTO Advisor or this project that we want, if this is the only video that you've seen from the session, there's two other ones, and there's some great references that we're building.
It is a living page. We eventually will put out a sort of runbook or framework for cloud migration to basically open source and give to the community. com and I'm sure Al will link it on his various channels as well. You want to find out more about me? You can find me on the web or on Twitter @ctoadvisor. Stay tuned for more content where it is constantly coming out. Thanks!
