Breaking Bad Code: Automating the Strangler Fig Pattern
AWS Migration Hub Refactor Spaces | vFunction
In this webinar, learn how vFunction + AWS Migration Hub Refactor Spaces automate the strangler fig pattern for modernization of complex and legacy .NET and Java monolithic applications.
Other Recommended Resources
Trend Micro Uses vFunction to Refactor Critical Monolith for AWS
Research Report: Why App Modernization Projects Fail
Analyst eBook: Application Modernization Patterns & Anti-Patterns
0:00:25.3 Samantha: Can you guys see my screen, okay?
0:00:31.4 Amir: Yep, looks good.
0:00:49.9 Samantha: Hey, everybody joining, I see a few people trickling in. We’ll give it a few minutes before we get started.
0:02:26.6 Samantha: Alright everybody. I know there’ll still be a few people trickling in, but we can go ahead and get started. So first off, welcome to our webinar. This is hosted by vFunction and AWS and I’ll be your host today. My name is Samantha Cartwright. I run the Global Alliances for vfunction and I will be your host today. We’ll do a few intros with the other people in a second, but today’s webinar is about breaking bad code. So how with vfunction and Amazon, we’re able to actually automate the strangler fig pattern, enabling you to really modernize your applications faster and with less risk. So many of you are looking to take advantage of a lot of the compute services that Amazon offers, and we are an enabler of that with refactor spaces.
0:03:13.7 Samantha: So let’s go ahead and get started. I’ll go ahead and kick off with just a brief agenda to get everybody in context of what we’re gonna be talking about today. So first off, we’re gonna talk about automating application modernization with vfunction. So vfunction CTO, we’ll go through this and we’ll introduce them in a second. Using the strangler fig approach to modernize complex apps, we’re gonna talk a little bit about one of our customers, Trend Micro and how they actually broke a monolithic app that was already living on AWS. The AWS Refactor Spaces team is gonna go through a demo and the services that they offer, and then at the end, we’ll do a Q&A with everybody. So with that being said, I’m gonna go ahead and let everybody introduce themselves. Amir, why don’t you start on our end.
0:04:00.0 Amir: Hi everyone. My name is Amir. I’m one of the founders and the CTO of vFunction.
0:04:07.2 Samantha: Steven.
0:04:09.2 Steven Dolan: Great, thanks Samantha. Steven Dolan, I’m technical business development, been with AWS for about three years and I work with customers on modernization and resilience.
0:04:17.8 Samantha: And Sashank.
0:04:21.9 Sashank: Hi, this is Sashank and I’m a modernization solutions architect here at AWS. Been here for around two years now helping customers go from monolith to microservices, move to containers, move to serverless, and so on. Thank you.
0:04:38.0 Samantha: Awesome. So I’m gonna go ahead and hand it over to Amir and let’s get it kicked off.
0:04:45.3 Amir: Thanks Samantha. So let’s start by talking about modernization in general. So modernization of course is one of the key initiatives today. Driving IT investments. Modernization is a new, more mature way of looking at cloud migration. So you see, before cloud migration was a number three, now modernization kind of surpassed cloud migration ’cause now clients have began being a little bit more cloud savvy. And now when they want to gain more from moving to the cloud, they understand that at least for some of their system, they really need to modernize them before just in order to really gain most of the value from the cloud. But modernization is you do that for business reasons mostly that’s the next slide. And it ’cause it solves freely business paying points. So what happens with an application as it gets bigger, it starts to accumulate technical debts. So you start by having those long test cycles which lead to long release cycles, you’re really unable to meet your business requirements quickly enough so you’re not able to innovate fast enough. It’s very hard to ramp up new developers to a monolithic application as it gets more complex.
0:06:12.6 Amir: We’ve heard stories from companies that, it takes them sometimes even up to a year to fully ramp up a developer on a large monolithic application. And that company that told us that story said that their average tenure of a developer in that company is around two years, which means that half of the time the developer was in the company he was just ramping up. And I think that the reason that a tenure for developers wasn’t very high is also because when you work on monolith, it’s actually quite discouraging. So developer morale and developer satisfaction developer experience is also very important and also stems from technical debt.
0:06:55.6 Amir: Everything I just described leads to also some to poor customer user experience ’cause again, you can’t really innovate, you can’t take advantage of the new technologies and your customers are not getting what they want at the end of the day. But although it’s so important, 79 of the modernization projects fail. So according to a recent survey by Wakefield, 79% of all modernization efforts fail after about $1.5 million on average being spent on these projects. And these projects taking an average of 16 months. So after 16 months and $1.5 million, 80% of them fail. So there’s a lot of money wasted, and you can ask yourself why. And the controversial slide, the next controversial slide that I’m gonna present is that modernization is actually done the wrong way.
0:08:05.3 Samantha: So with that being said, I think it’d be good to pull the audience to see how many applications have you actually successfully refactored. So I just launched the poll, hopefully you see it in front of you. We’ll give it about 20 seconds, but if you could just vote quickly and then I can share results at the end. I think we have a few still coming in. Alright. Give it another five seconds and then I’ll end the poll. Alright. So I’m gonna go ahead and share results and then we’ll go to the next screen. So here are the results. Alright, let’s keep going.
0:09:07.3 Amir: Okay. So what I wanna tell… What I want to tell you is that modernization is really done the wrong way. And what you see in the photo in front of you is the common way we do modernization today, it’s architects sitting in front of a whiteboard with sticky notes, doing a top-level domain-driven design. But the problem with top-down design is that although it does show you what the application was supposed to do or is supposed to do, had you just started to build it with all of the information, it doesn’t take into account how the application is currently built.
0:09:48.2 Amir: So that means that an average process would look like architects describing a domain to a developer. A developer takes the task of trying to unravel that domain from the current code, goes back and tells the developer that it’s the architects, that it can’t really be done that way because this class is actually connected to that class, and that domain is actually talking to that domain, and that that whole process can just go on for a year.
0:10:17.4 Amir: So out of those 16 months that the average of 16 months, a full year can be just this, just back and forth between architects and developers not really deciding on the right architecture. And the reason is not only that it doesn’t take into account how the application is built. There’s no real tools to support the design process. And without these tools to support the design process, these architects have no way of understanding of what they’re describing or asking the developers to do is actually the right thing to do.
0:10:48.3 Amir: Lastly, there’s no automation around extracting services from a monolithic application. And that means that developers end up, instead of focusing on refactoring work and on developing, they focus on menial tasks like making the application compile, adding a source from here, and a dependency from here, and understanding where to take that library and where to take that library. And that’s what they spend their time on.
0:11:20.1 Amir: So here comes vFunction is, that’s why we built vFunction, it’s really to tackle this problem of the growing gap between enterprise reality and the ability to let enterprises innovate with new innovation that comes from the cloud. So vFunction is an intelligent and a metric space and a bottom-up design platform. So it uses AI and machine learning in order to assess and analyze it and design your microservices or mini-services architecture and to find that code and that dependencies within your application. It’s also an interactive tools for developers and architects, because at the end of the day, architects are the ones that really know what they want to do with the application.
0:12:04.9 Amir: It’s not necessary that you have to do whatever is possible with the current application. You do want to get to some result that also reflects what the application is gonna be in the future. And for that, the platform has to be interactive and allow the architects to impose their own view on the architecture, but it does provide immediate feedback so you can really merge that top-down requirements from the architect with the bottom-up data that comes from the AI and the machine learning.
0:12:39.8 Amir: Another thing that the vFunction does is automates and accelerates all those error prone menial dev tasks, like to copy sources, remove dead code, minimize property files, take only the right configuration files. That’s actually that… Just that can save you a month on a big project. And because everything is automated and gives you the right feedback, it’s also repeatable and scalable. So even if you have a significant portfolio, or especially if you have a significant portfolio, this can really help you build a factory model in order to modernize many applications.
0:13:14.0 Amir: The way it works is this way. So vFunction is a platform that uses both dynamic and static analysis. The static analysis we use initially for assessment and then we use it further on also in the modernization, the assessment is a tool that calculates the level of technical debt within the application to allow you to build the right business case to modernize the application.
0:13:40.3 Amir: And if you decide to modernize the application, then you engage with the dynamic analysis to install something on a running JVM or a running CLR for a.Net application. And that collects information about how the application is currently running or how the application is currently built. So whatever is running it sends data to our AI server that’s installed on premise. The AI server then calculates what is the best architecture for that application, a mini-service or a microservice architecture, the best one for this application by optimizing for a few key metrics to build the right microservices.
0:14:26.3 Amir: So those metrics are exclusivity of classes, exclusivity of constraints, simplicity of topology, etcetera. But then as part of the modernization hub, the architect also can interact with this interactive platform as we described before, up until they get to a point where they’re happy with the architecture, and then you can extract those services, compile them and then deploy them to your cloud. And I’ll show you a demo of this in a second. So this is vFunction.
0:15:02.5 Samantha: Yeah. With that being said, let’s do a quick poll. So if you have a monolithic application, is it living on public cloud already? So I’ll give you guys about 15 seconds to answer that.
0:15:31.8 Samantha: Alright, I’m gonna go ahead and end the poll. I think the answers have stopped coming in. I’ll share results quickly and then we will move on. Alright.
0:15:45.4 Amir: Interesting results.
0:15:47.2 Samantha: It was.
0:15:50.4 Amir: So now that we talked a little bit about vFunction, let’s talk about the right methodology to modernize. So I want to describe to you the Strangler Fig Pattern in case you don’t know it. So the strangler fig tree is a tree that starts to grow on the, on another tree. And it slowly kind of grows around the trunk of the tree up until it strangles the tree, and then the tree in the middle kind of dies. So that pattern, when you think about it as a modernization strategy, so instead of completely decomposing the monolith, you start to build around it. So you can start extracting services or rebuild new services around that monolith up until that monolith simply doesn’t need to work anymore. And at that point, it’s completely strangled. And what you have is microservices architectures. You can also think about this it’s like an iterative modernization strategy. What it looks like in real life is this.
0:17:00.0 Amir: You start with a monolith, you strangle a service, you extract a service, and you have one new service running alongside a monolith. And then you use vFunction in order to extract those services, but you use AWS Migration Hub Refactor Spaces as your strangler facade. So that’s like whatever drives traffic not to the monolith anymore, but towards, to the new service. And you can do that gradually up until the point that that specific service is completely strangled and it’s not in the monolith anymore. And by that, you’re also reducing the size and the complexity of the monolith. So with that, you do this in an iterative manner, you extract more and more services, so you have more strangled services, up until you get to a point where there’s basically nothing left up on the monolith and you have just a good number of microservices and your distributed application.
0:17:58.2 Samantha: Okay, well, let’s do I think one last final poll. So I’ll launch it right now. So have you actually used a Strangler Fig Pattern in any of your current modernization projects? So you have another 15, 20 seconds to answer. Alright. It looks like most people have answered. Alright, let me share results. So some of you have, and I think majority of you haven’t or are just learning about it. So interesting results. Alright, let’s keep going.
0:18:50.0 Amir: Okay, so I want to tell you one story about one of our clients that used this approach in order to modernize their monolith. And more information about this use case is also available on the vFunction site. And that client is Trend Micro. So Trend Micro used vFunction to refactor a critical monolith for AWS. So it was running as a monolith on AWS, but then they used vFunction in order to extract services from it. So what we did with Trend Micro is a bottom-up analysis using vFunction. What we found in this very large application, which was over 10,000 classes, that there were a lot of circular dependencies. So they refactored those dependencies up until the complexity of the application wasn’t very high. That allowed them to extract a common library and extract major services from… Like major as important, from the monolith and basically strangle the monolith with that service. So that service was deployed alongside the monolith, and then they started to work with that service, and just left that code in the monolith in the initial phases.
0:20:07.6 Amir: So what was achieved? So the refactoring with vFunction instead of a year that they already spent on it went down to under three months. Deployments are now… Went from… To deploy the monolith, so to deploy the application used to take at least one day, now it takes one hour. Developer satisfaction is up. They now can quickly validate their hypotheses on developing for that new service. And they are ready to scale their modernization to more and more monoliths that Trend Micro use. Next slide is a nice quote from Trend Micro. I’ll just read it. “So without vFunction, we would never have been able to manually tackle the issue of circular dependencies in our monolith system. The key service for our most important product suite is now entangled from the rest of the monolith deployed. Deploying on AWS just takes one hour compared to nearly a full day in the past.” So it’s a really neat project that has really improved life for the developers at Trend Micro.”
0:21:17.0 Samantha: Okay, great. Yeah.
0:21:17.1 Amir: With that, I think I’ll pass to Sashank.
0:21:25.1 Sashank: Thanks. Thanks Amir. So we just saw with vFunction, how we’re able to decompose the monolith. So now essentially you have the monolith, you have a microservice, and how do we, so how do we get from the monolith to a microservice architecture and how do we get there safely? That is sort of the question right now. Next slide.
0:21:56.0 Sashank: So this is where we introduced our AWS Migration Hub Refactor Spaces. We launched this in February of 2022. So there’s a lot of undifferentiated heavy lifting that goes into sort of preparing the right environment so you can move from a monolith to a microservice, things like routing, how can you incrementally refactor and so on. So with Refactor Spaces, what we’re helping you do is helping you provision that multi account refactor environment so that you can have a cross account network bridge between your existing applications and your new microservices.
0:22:38.1 Sashank: Next slide. So we identified two primary patterns that our customers use when it comes to refactoring, and with Refactor Spaces, these are the patterns that we enable you to do. One is the leave-in layer pattern, where you can enhance or extend an existing application without changing the existing model. The other pattern, which, Amir just spoke about was refactoring in incrementally, which is basically the strangler fig pattern, where you are basically peeling off different, feature sets into new services. Vfunction helps you identify the domains and you can create these microservices from your existing monolith. Right?
0:23:21.8 Sashank: Next slide. So when we introduced Refactor Spaces, these are some of the primary benefits that we saw. We are helping reduce the time to set up a factoring environment, reduce that complexity of refactoring monoliths by iteratively extracting capabilities as new microservices and routing that traffic between old and new. So essentially the idea here is that you extract the microservices from Vfunction and then use Migration Hub Refactor Spaces to iteratively move or reroute traffic from your monolith to the microservice. We also help with simplifying management of the existing applications and microservices. We give you that, single pane of glass view with Migration Hub Refactor Spaces, and we help with the orchestration here as well. In terms of orchestration… Next slide, please.
0:24:26.7 Sashank: So we orchestrate several AWS services here for you. We’re helping you set up a Transit Gateway. We help a Resource Access Manager or RAM, which you are probably currently using for shared VPCs, and so on, to help bridge networking across accounts to simplify the communication between old and new right. And we are also helping you use API Gateway to incrementally to help with incremental changes that are shared from application consumers. I’ll go into a little bit of depth with the architecture here, and we’ll see a little bit more of this in the demo as well. So essentially with Refactor Spaces, what you’re doing is you’re creating a Refactor Spaces environment. You’re sharing that environment with another account where you’re going to create your microservices, and then what you’re doing is you’re creating an application inside of the Refactor Spaces, and then you’re creating your services, whether that’s gonna be in lambda, Fargate, any modern compute that you want.
0:25:38.3 Sashank: And then you route your actual microservice itself. In terms of what we are provisioning, and helping you with the routing and enabling and automating that strangler pattern where automating the creation of the API Gateway, the NLP, the Transit Gateway so that you can have this orchestration between the monolith and the microservice here. And then as you extract more code from the vfunction, more microservices from vfunction, all you have to do is pretty much just create a new service and create a route once you have this sort of platform enabled and established. So you’ll see here that we are using three separate accounts for the refactoring here. And I wanna go a little bit into the advantages of using a multi-account architecture here too. Next slide sir.
0:26:40.9 Sashank: So we recommend using a multi account architecture as a best practice here, whether that’s reducing blast radius, which is a big concern. We use accounts, used as boundaries in terms of that, so we are reducing the blast radius, you get resource isolation, security isolation when you’re running microservices, you need to know how much these microservices are costing you exactly. So you get that cost and billing clarity. Another reason we see our customers… We’ve seen from our customers is resource limits. Once you start having your monolith and your microservices in the same account, you’re gonna reach some of these limits fast. Some limits can be increased, some limits cannot. So we strongly recommend doing this as a best practice, to spin up your microservices in a separate account all by itself. And then of course, you can automate connectivity, have enhanced routing rules when you do this with Refactor Spaces as well. Next slide, please.
0:27:46.5 Samantha: Actually, before we go to next slide, let’s launch a quick poll. So do you plan to use multiple AWS accounts when refactoring your application? I’ll give everybody about 15, 20 seconds. All right, I’ll go ahead and pull. So, 30% yes. 13% no, and 57% aren’t sure. So, okay, let’s move on.
0:28:35.0 Sashank: Yeah. And go to the next slide, please. Yeah. So, in terms of pricing, you can run three Refactor Spaces environments free for three months. Beyond that, it’s gonna be 0.028 cent per environment per hour. We’ve sort of calculated this out to be $20 per month per environment if it’s run continuously. The metering begins once you launch your first environment in Refactor Spaces. Right now, Refactor Spaces you can use through the console, we do have Cloud Formation support, AWS SDK, you can bring any application that is targeted for a refactor or rewrite or rearchitecture and so on. As long as it has path based routing based on the HTTP protocol, we can bring that application. So, absolutely, get started with Refactor Spaces today. We have a whole bunch of blogs and so on with this as well. Steven is gonna run through a quick demo of Refactor Spaces and there’s gonna be a demo of the vFunction platform here as well.
0:29:48.1 Samantha: Yep. So, with that being said, I’m gonna go ahead and pass it over to Amir to start a demo of vFunction.
0:30:03.2 Amir: Thanks. Can you see my screen. Okay?
0:30:08.1 Samantha: Yep.
0:30:10.6 Amir: So, this is the VFunction application what you’re seeing in front of you. This is a demo application. And what I’m gonna show you is how to quickly strangle a service from this demo application. So this demo application is a small application as you see here, it’s just 55 classes, but it’s still enough to show you the capabilities of the platform. What you see in front of you here, this is the architecture view and as part of the analysis screen. Each bubble here is really a service. The color indicates the metrics of that service, so how easy it is to actually extract that service, or how much value you gain from extracting it. So, green is high value, low effort to extract, or good metrics like what we call a high exclusivity for the service. And these dotted lines are calls between the services and this black hole in the middle is what used to be the monolith. Okay?
0:31:05.2 Amir: So really anything stemming from the center are new endpoints of the system. So these can be strangled pretty easily. And here we see some service-to-service calls. So this is really the architecture view. Obviously, when you have service-to-service calls from this service to this service, can’t be strangled before these services are available. Okay? So this is one thing to remember and that’s also why we look at a simple topology. So let’s see what we can do with vFunction. Just… So this application is like a… It mimics a retail application. We call it an order management system. So you’d expect things like payment and orders and inventory and vFunction, gets to this topology completely automatically based on how the application is run with its CI. And you see the names of the services that it finds here. And we can review each and every one of the services. So let’s look at this modified fulfillment controller, the big one. It has two entry points, so two methods that virtually invoke this service. And we can also hide third party classes and common classes in order to really focus in on the business logic of this specific service.
0:32:24.4 Amir: The platform allows us to see which classes we see as part of the dynamic analysis, which classes we saw running as part of the dynamic analysis. And it splits them up based on exclusivity. So we saw four classes that were exclusive to this service. So these four classes were only used within this service and nowhere else. It means that if we extract this service, these four classes will go away, basically. The platform determines that one of the classes that we saw should be in a common library. In this example, it’s the logger class. There’s actually an interesting technology around understanding what classes should be in a common library and are not domain specific. And we find a non-exclusive class. This non-exclusive class is a shipping class… Shipping service, sorry. The shipping service class. And we can look at the details to see where it’s used.
0:33:20.3 Amir: So we see that this class is used in two different places. Now, this is very common, of course, in an application. And the larger the application, the more non-exclusive classes you’ll find, and then an architect needs to go over these classes and decide what to do about them. So, the decision is of course, something that our architect needs to do, but the feedback is completely automatic. So here I can look and see, Okay, what can I do with this class? Should I refactor it? Should I duplicate that code or should I maybe add an API in order to make sure that this class is used only from one place and make it exclusive? So let’s make this shipping service class exclusive to the shipping price controller service that we see here. So we click here on these calls, it takes us to the right place in the call tree where the modified fulfillment service is calling the shipping service class.
0:34:17.5 Amir: And what the platform allows us to do is to replace a method call with an API call. So instead of a method call to the shipping service class, we’re going to call the shipping service. Click make. This is now an API. If we go back to the services, the analysis is recalculating all the metrics so it can provide us with feedback. We see that the exclusivity is now up to 100%, and we see that as part of the… This architecture view we now have an added service-to-service call between this modified fulfillment controller and the shipping price controller. So, here we paid by adding an API call in order to increase the exclusivity of the system.
0:35:03.2 Amir: We can also look at resources. So VFunction allows you to also look at resources and constraints and access to database tables and database transactions. And we can see, for instance, this an order line database table. And we can see where it is used. And we can see that this table is also used in the modified fulfillment service and in the order controller. Let’s assume for a second that it’s very important for me to make this, every access to these order database tables only from the database for… Only from the order service. So I’m gonna do the same thing again as I did before. I’m going to jump to the right place in the call tree where I can replace a method call with an API call completely logically at this point, make it an API to the order controller. So I now added this entire flow to the order controller.
0:36:00.2 Amir: Click back to services, wait for the analysis to complete. And now I have this added call here and now these database tables are now gonna be exclusive to this order service. So what I showed you now in just a couple of minutes is really how an architect interacts with VFunction in order to determine the right architecture or the right microservice decomposition for his application while providing full observability and full visibility into what it means to decompose a service in a specific way, which classes are gonna be part of that service, which classes will be needed because of compiled independencies. You can mark dead code. And when you’re happy with this architecture, you can simply extract those services. So let’s mark this service for extraction. So I click, so just in case you didn’t notice.
0:37:02.9 Amir: So I selected this service, the order controller. There’s a blue plus sign, I click save. I have service creation type lighting up. If I click download, it’ll download 3000 now… I think that I may have… Okay, now I’m sharing my entire screen. So these three files are recipe files on how to create a service. They are inputs to one of our other tools that’s called code copy, but I’ll show you in a second. And there’s also a YAML file and it’ll open up the YAML file. This is really an open API file describing all of the APIs and… That will be generated in order to extract a service. So this is your open API file or your swagger file. So you can then use this to build your client libraries and test the service that we’re going to extract and strangle out.
0:38:08.1 Amir: Now I’ll go here to this terminal here and I already copied the service specification file that I downloaded for the common library ’cause it got also the recipe for the common library and the recipe for the order controller. So I see both of them here. And what I’m gonna do now is use the code copy tool provided with the specification file from the service, pick the common library, Jason pointed to the original sources of the project, and tell it to create a new service under a new directory that wasn’t here before OMS services/common. And this will now copy the original sources, only the ones that are required with the minimized configuration files into a directory for the new service. And it’ll create a POM file for that service. I’ll do the same for the order controller. And now I can go into these directories. It’s called the common file. I see the POM file here. And then just doing Maven Clean Install.
0:39:37.6 Amir: So now we have that common library. It just has one class, the logger class, so that’s why it didn’t take so long. But also the order controller itself, we can just build it with Maven just the same way. And it’ll compile obviously for a more, for an enterprise application. This might take some time. There might be some test classes that you’ll need to move or some constraints around constant files, but also just extracting the services we reassess. So what we saw now in just a few minutes is how I determined the microservices architecture from a demo application, extracted the service and got it to compile, I’ll stop sharing and move it over to Steven.
0:40:25.2 SD: All right, awesome. Thanks, Amir. Can everyone see my screen? Yep. Looks good. Awesome. So I’m in the console here. As Sashank mentioned, you can use refactor spaces with the CLI, cloudformation, SDK, but for now, I’ll show you the console on what this looks like. What I’ve created, and I’ll dive into it, is a Refactor Spaces environment, consisting of three accounts, sort of, what’s similar to what you saw on the slide deck that Sashank presented. And we’ll just dive in. We’ll take a look at the pieces here and what it looks like. So to access refactor spaces, we’ll go to Migration Hub. You can simply type Migration Hub at the top if you like, you will access it and then go to Refactor Spaces down here.
0:41:11.2 SD: Awesome. So this is the single pane of glass that Sashank was mentioning before. You know, from here we call this account the environment owner account. That means that’s the account essentially, where we created the refactor spaces environment. You see my name is 123 of just the environment as a test, and it shows me here, right? I have one application in this environment. You can have multiple applications in one environment if you’d like. A good way of thinking of an application divider is an API gateway, right? So each application is gonna have its own front door, its own facade, its own API gateway. We see there’s two other accounts in this environment, and we see there’s a few services and routes. So let’s take a closer look here, going to the environment and we’ll see similar visibility into what’s going on.
0:41:54.3 SD: So going to shares here, we’ll see the principle, like these are the account numbers of the other AWS accounts in the environment. The sharing process is similar to… Or it is using RAM. If you’ve used that in the past, essentially it sends out an invite to these other AWS accounts. They have to accept it. And once that’s done, the status here will turn to associated. So nothing here is automated to a sense where you can’t approve it, right? You have to approve these accounts first to get them in the environment. And so once they’re in, and I’ve already added a few services into this environment you’ll see this networking field populate, and these are all the VPCs that are involved in this refactor spaces environment. Sashank mentioned that refactor spaces network fabric, right? From re-routing traffic from old to new.
0:42:37.6 SD: This just shows you, these are the, all the VPCs in play, right? We obviously wanna make sure we don’t have any overlap here, but it shows me the accounts and the VPCs that are incorporated with this. Awesome. So there’s the shared accounts. We see a little bit of the networking. We also see here in the environment the transit gateway provision, right? So when you first create the environment, if you remember those steps, step one, is you create the environment that stands up a transit gateway just to show you, right? You’ll be able to see all these resources in your console as if you created them yourself. So it’s not something that’s under the hood that you don’t have any control over, right? If you wanted, you could peer this transit gateway with another one. So essentially you’ll see it here as if you created it, right? You’ll see in the description created by Migration Hub, refactor spaces also gives you the environment. We also tag these things too, right? For identity purposes and for deleting the environment, right? So it knows what to delete. Great. So we have our transit gateway. Let’s take a look in the application now. So I have one application here. It has two services and two routes inside of it. Let’s click inside.
0:43:42.3 SD: Great. So creating the application creates API gateway the network load balance too, if you remember that too, from the diagram. We also have our proxy URL, right? This is the new path, that new front door, this is what application consumers are gonna hit. That’s gonna make everything transparent behind it, right? The modernizing going on behind it. The re-routing of traffic, they’ll continually hit this one new front door and all that can take place without affecting the users, right? So essentially this is the path to that API gateway. Just to show you that too we’ll climb in here, we’ll see our API gateway and some of these methods that were created are from the paths and routes. I’ll show you in a second what were created. So all this is created for you by configuring these routes and these paths in refactor space without even touching the API gateway. For authorization, other things you like to customize with API gateway, you wanna put a WAF in front of it. You can still do that, right? Again, to kind of like the transit gateway you’ll see this resource in the console as if you created it. You have the standard, right options as you would if you, you’d made this yourself. You have resource policies you can apply to control access and other things.
0:44:48.1 SD: Great. We also see our network load balancer. What that’s for is for something called private integration. Let’s say users hit that API gateway and they need to route traffic from that point to a private resource, right? Private IP address that allows you to do that routing from within any of those VPCs in the environment. So what we’re doing here, we’re not recreating the wheel here. This is a pattern we’ve seen other customers do. The benefit here, is automating all this. VPC link network, load balancer, API gateway, all this is stood up for you in just a few minutes in creating the environment in the application. Great. So we have our application, we have our new front door, you see, I have a few services in here. The next steps to create your service, right?
0:45:27.0 SD: And the the first service you’re gonna create is your monolith. So step one is create that path to the monolith. Make sure you can access the monolith as before through that new front door, and that will be the first step. So in this case we see our monolith here. We see the endpoint HTP endpoint I provided in the account it resides in. I’ll show you what creating a service looks like. So when you create the service, you select the environment in the application that’s related to, you name it. And then you have two choices here. You can use VPC. An HTTP endpoint. You can also use Lambda if you wanna use serverless there. But we have our two endpoint options. We select our VPC. Putting that VPC here adds that VPC in the network fabric as I showed you on the previous dashboard. And then we could select that route. So your first route will be that slash, right? That default route, all traffic is gonna go to that monolith as step one.
0:46:22.6 Samantha: Awesome. So once the route to the monolith is in place, you’ve tested that, you can hit that monolith. Now it’s time to test that first microservice. So let’s say you’ve extracted code from V function, right? Let’s say you provision this on a container any EAD Bus compute you’d like, right? So you’re gonna have an endpoint to access that new compute. What you do is you create a new service, right? Put in that HTTP endpoint and select the path that, the route that we like to use. So we’d love to use the e-commerce example of a store online that’s easy to relate to. Let’s imagine we extracted that shopping cart functionality to a new microservice in this case, I created a new service called microservice 1, the path to that service, and then the route as /cart, right?
0:47:08.5 SD: So application consumers are hitting that front door. All traffic continues to go to the monolith except for that /cart traffic that’s now being routed to the microservice. Awesome. And something else I’ll show you here for communication to make this little easy to get you started a security group’s also created by refactor spaces. It’s important to know this is not attached to resources automatically. So by configuring an environment and application, things just aren’t automatically gonna start talking to each other, right? The fabrics there in place the route tables are modified, that’s all in there. But you still have to ensure these security groups are in place to lock communication. So this is creative but not associated with anything. But it’s created in all those accounts in the environment, and it allows inbound rules as we’ll see here. Got it.
0:47:58.6 Samantha: All right. Make sure I can see the proper screen here.
0:48:06.0 SD: Great. In any case, looks like I modified. There you go. I modified this a bit, but essentially the rules will be in place to allow inbound communication across all VPCs in the environment. You can modify this security group if you’d like. But I think that’s important to note, right? Some customers they say, right, we have security considerations, which is understood, but just know, right? They still takes some action on you to allow that communication, but the fabric is in place, along with those VPC attachments. So just to show you one more thing here, we’ll go back to the transit gateway attachments. So as mentioned, we have a transit gateway that stood up, and we also have these attachments that were automatically created for us, right? So those are attaching all those VPCs in that refactor spaces environment to the transit gateway, and the route tables are also updated accordingly, right? So any traffic can cross over, through these VPCs. Great. And Samantha, that’s my demo.
0:49:06.5 Samantha: Awesome. Okay. So I’m gonna go ahead and share my screen again really quick. And we’re also gonna answer some questions, so give me one second. Let me launch this. All right. So, first off, thanks everybody for attending. If you wanna get in touch with us, we’re happy to do a joint demo session. So scan the QR code. I’m also gonna launch a poll really quickly that I won’t share with everybody, the results. But if you would like a demo, just go ahead and vote yes, and we will get in contact with you ASAP. With that being said though, there was a few questions. If you have any, please type them in now and we’ll try and get to them. So just a few here. So, Amir, maybe you can answer this one. What languages does a vFunction platform support?
0:49:56.4 Amir: Java and document.
0:49:57.6 Samantha: All right, perfect. Another one is, is the monolith already within the cloud environment containerized, or could it be a bare metal VM application? I don’t know who wants to answer that.
0:50:11.2 Amir: Sashank.
0:50:14.6 Sashank: Yeah. So it could be a bare metal or VM application. It doesn’t need to be containerized. Essentially by moving to microservices where we’re helping you optimize containerization of the microservices well, right. So there’s no need for an app to be containerized. It can be a bare metal or VM application. From AWS what we recommend our customers to do is to migrate and modernize, if it’s possible to do that at the same time, do that or migrate to AWS quickly. We offer, tools like, application migration service called AWS MGN, which does block cloud application. We have app to container where you can move your entire application to container with just a few clicks. So there’s a lot of tools where we’re helping customers accelerate migration as well.
0:51:11.1 Samantha: Okay, great. A few others, from the audience. So how are the on-premise infrastructure configuration usages, say by some example, if on WebLogic, JBoss, Apache or other, will that be provided equivalent, the equivalent of that on refactor spaces hub? Or will it be a custom build out on cloud?
0:51:35.1 Sashank: Yeah, I’m not sure of what exactly this question, Amir go ahead if you have some insight on this.
0:51:42.6 Amir: Yeah. So when you take a monolithic application that is running on, more traditional application, server, like a WebLogic then many times when you want to extract services out of it, you don’t necessarily want it to the services to run on WebLogic, although it’s completely possible for you to run on a containerized WebLogic as well, and by the way, I think there’s a YouTube video of us actually running WebLogic 14C on Oracle Cloud, showing how to do that. But the right way of doing that, if you have like a lot of like EJBs and traditional, more traditional Java enterprise, applications, extract that functionality, run it in the beginning on the same, frameworks or the same infrastructure. Like, it’ll be a, if it was a WebLogic application, it’ll be a smaller WebLogic application, but now that it’s small, refactor it, change it to, whatever modern framework you’d like, I don’t know, spring, spring boots, serverless infrastructure and then move it to the cloud. That would be my recommendation.
0:52:56.5 Samantha: All right. Just a few other questions. So, does vFunction support different types of communication beyond traditional rest based services?
0:53:11.3 Amir: So I think that’s, both a question for vFunction and for refactor spaces. I would say it’s actually a similar answer to what I just said. VFunction creates, RESTful APIs instead of, what was before, method calls. But at that point, just make sure that it’s working and then change it to whatever you want. I’m not sure if it’s, if about refactor spaces though, Sashank or Steven.
0:53:38.8 Sashank: Yeah, so I mean, with vFunction, again, we’re helping create that rest endpoint where we’re helping create those, that are strapped around the code, which you currently may not have, today, right? With refactor spaces, we do help you do the path based routing from old to new as well. If you wanna go to something else like GRPC or maybe GraphQL, I don’t think that is something that we can do very easily today. Again, with things like GraphQL and so on, the complexity again increases. So the idea here is to get it out of your existing monolith in a more simpler fashion, and then go for more complicated protocols like GraphQL and all of that if needed.
0:54:30.9 Amir: But… And a little tip is don’t go more complex than what you know. I mean, if you’re currently using a monolithic application, start with RESTful API services. I mean, no one goes from a monolithic application to like 10,000 microservices running on mesh. So just take it one step at a time.
0:54:57.4 Samantha: Cool. We have some… We have time for a few other questions. So how does vFunction deal with transactions? So classes living in the same memory space or interacting via JTA can participate in ACID transactions. If I refactor those classes, I fall in eventual consistency.
0:55:18.2 Amir: Yeah. So first of all, that’s true. VFunction does track JTA transactions and XA transactions and it allows the architects to see whenever they’re breaking the transactional boundary. Now, sometimes when you decompose an application, you need to break the transactional boundary and that of course requires changing the business logic. Many times what we see is that developers are too quick to start a transaction when an API starts, when a request starts and to close them when the request ends. And it doesn’t mean necessary that a transaction is required. But anyway, what you get with vFunction that you don’t get with anywhere else is really that observability. That by breaking the application this way, that you are breaking at that transactional boundary. So, at least, it’ll allow you to know that you need to deal with it. But sometimes dealing with transaction is something that you simply have to do when breaking a large monolithic application, so there’s no way around.
0:56:26.5 Samantha: All right, a few others came in. Can vFunction be applied to complex enterprise, enterprises with many monolithic applications? So question really is can you analyze multiple monoliths at the same time?
0:56:43.5 Amir: VFunction is focused on one JVM at a time. So with one JVM at a time, you can see especially for larger monoliths, how to break them apart. Now with distributed applications or with applications that are already distributed. The question that arises is what is really the business need to review the entire application? If it’s too many services, then maybe different tools exist that are not vFunction in order to start and understand how to merge that functionality. If you see that you have like God services or after you distributed the application, you see that there are services that kind of started to grow and become a monolith in their own right, then analyze those monoliths first and then talk to us afterwards. With vFunction we also have our own solution architects and AWS, of course has their own solution architects. So our field architects can definitely help you to figure out how to plan those projects with vFunction as well.
0:58:06.0 Samantha: I think we have time for maybe one more question. How efficiently can vFunction handle the generation of code for applications with transaction requests which will span into multiple microservices once moved into a new architecture?
0:58:22.3 Amir: So actually I’m not sure I understand that question. Exactly what was meant. We don’t generate code in general. We generate code around the services. So we could create the controllers in order to create the RESTful APIs, but we don’t mess around with the actual. And we can split up classes, but we don’t mess around with the actual business logic. So whatever you need to do to handle transactions, you need to do it manually. If you need to use like a distributed cash or distributed transactions in some way, then it’s something that you’ll need to write yourselves. I would suggest to do this in a later stage. So first, find a way that you could create a distributed application and then start to modify individual services that you can test individually and then start to modify the code to use a distributed cash, etcetera. But, if I got the question wrong, feel free to reach out directly, please.
0:59:31.9 Samantha: Okay. I think we’re at the top of the hour. Thank you everybody for joining. If you wanna reach out, please do. We’d be happy to get in touch with you. So hopefully you scan the QR code or took the poll, but we’re happy to be in touch. So thank you everybody have a great day.