Transcript
Speaker: Hello, Basement Programmers. Welcome to this episode of the Basement Programmer Podcast. This month, I've got my colleagues, Renee and Craig, to talk about the new technical guide, monolithic to microservice, the journey of a .NET application. Full disclosure here, both Renee and Craig work for AWS, as do I, obviously.
Speaker: As always, the opinions expressed in this podcast are my own or our own and not necessarily those of our employers or any other organizations we may be associated with. Hi, guys. Why don't you introduce yourselves? Ranit. Hey, Tom. Hey, Craig. Hello, everyone. My name is Ranit Beshish. I'm a Principal Solutions Architect in AWS. I'm on a team called Microsoft Workloads on AWS where we help customers
Speaker: migrate or optimize their Microsoft technology -based applications on AWS. I've been with AWS for around six years now. Happy to be on this podcast, speaking with you, Craig and Tom. And Craig. Hey, everybody. Rene, Tom, our live studio audience. My name is Craig Bossi. I'm a Microsoft Specialist Solutions Architect also at AWS. And I've been with the company for
Speaker: coming up on two and a half years at this point. I've been doing .NET application development and AWS for 10, 15 years at this point. And I'm always really excited to work with customers and other developers to really help them to optimize what they're doing on AWS and in their applications. So I'm super excited to be talking today. And I'm also really excited about this technical guide and how it can help our listeners
Speaker: Okay, great. So Craig, what is this technical guide all about? So this technical guide that we worked on and collaborated on is really a guide that covers the process of turning a monolithic .net application into a microservices based architecture. It really, it covers some of the best practices and a lot of considerations that teams need to take into account
Speaker: when they're undertaking this journey. So our guide here is really aimed mostly towards a .NET oriented ecosystem. However, the information contained there is applicable across many different technology stacks also. So hopefully it'll have wide appeal for folks. Monolith. So we're really talking about really large apps here, right?
Speaker: So no, monoliths actually come in various shapes and sizes. Some are large, but some are small too. The main characteristic of a monolithic application is really that they have a single code base and all of the functionality is built into really one solution. And a lot of times there's one database for most or all of the data for your application.
Speaker: We actually see a lot of .NET framework applications that were built using monolithic architectures. Because when people first started building applications using .NET framework, that was the common way that people did stuff. But many of these monoliths that companies have built in the past are still alive and well today. And as I said, they're all shapes and sizes. And I know personally that some of the monolithic .NET framework code that I've worked on in the past
Speaker: is still an operation. Rene, why would a customer want to go down this path of breaking up their applications? Good question, Tom. So there could be multiple reasons why anybody would consider breaking a monolith into microservices. The larger point or the biggest reason why anybody would do that is when they have to separate out functionality of their application,
Speaker: into smaller components where each component can be deployed, it can be developed and tested, and then scaled separately from rest of the application. The point with microservices is when you have smaller units of deployments, you limit the scope of change, which automatically should reduce the risk which comes with making a change and testing that change separately from rest of the application.
Speaker: Also, when you have different components or different services inter -communicating with each other, each service can be developed separately by a team, which can develop that service on its own pace at its own cadence of deployment and testing. And since services are loosely coupled and exposed by standard interfaces, developers can even use programming languages of their own choices, which means
Speaker: services in a single application could be developed using different programming languages. So Craig, why not just rewrite the application or parts of the application from scratch? Well, in theory it would be nice that if we could always just start over from scratch and have a clean slate. However.
Speaker: As anyone who's ever been involved in a software rewrite can attest to, myself included, there are a lot of challenges of application rewrite. First of all, the cost alone is something that is really hard to estimate and budget overruns in rewrites are pretty common. One of the reasons for this is that when you have older software products applications,
Speaker: there's really years of team efforts that have gone into adding features and customizing it and building it to really do exactly what the business needs. But it's easy to underestimate the amount of effort that has gone into the application and how much will be required to reproduce that functionality. And if the effort is correctly estimated, then the ROI may actually not be there.
Speaker: And another challenge comes from not being fully aware of all these requirements. So the business requirements are generally pretty well understood, but the requirements for the new written system could be, it has to work the way that the old system does. So duplicating functionality like this can lead to risk of missing features, a poor user experience in the end product, and really long development cycle times.
Speaker: So being able to address the functionality that you want to update one small section at a time, let's accompany look at these bite sized pieces of the application, make course corrections where needed by being using an agile process and overall being more intentional and outcome focused when refreshing the application rather than just rewrite the whole thing at once.
Speaker: Yeah, and also this is sort of a proven theory. Like if you have an existing application, imagine which has been built over many years. And if you decide to rewrite the whole application, you have to make sure that you understand how different layers or modules of the application talk to each other before you're starting like rewriting the whole application.
Speaker: That's where the concept of organically breaking your application into smaller parts, maybe having some kind of a front -end or facade layer, which makes sure that the users are never interrupted and the user experience is never affected, and use architecture patterns like Strangler fake pattern to break parts of the application into smaller components. This has been proven to work just well. You can start small and iterate on top of it and keep on making changes.
Speaker: And don't forget that if the person or team who originally wrote the application is no longer with the company, it becomes really difficult to even understand which part of the code and why does that even exist in first place? Yeah, well, I mean, I can barely understand the code I wrote last month. So true. And, you know, and as Raneet said, as these applications have grown organically, usually things like documentation
Speaker: have not grown with them. The people that have built the applications sometimes really have the entire structure of the applications contained within their head and decoding why and how something is coded in a way that it does can lead to confusion and misinterpretation, et cetera. We talked about if the people that wrote the code left the company, but I've come across situations, even with code that I've written,
Speaker: in which, as you mentioned, Tom, the author of the code can't really remember what it was used for because it was so long ago. So we have to keep the code as is, and people are kind of afraid to touch it. And that could be a barrier for developing new features that are actually needed. And the time taken to develop those features is extended because of the overhead of figuring out what that code does. So why do we say this? Well, when we're talking about refactoring code into microservices,
Speaker: then careful planning can not only address some of these problems, but also put you in a position to prevent this situation again in the future. If we're in a brain drain situation, when we're creating our microservices, we're going to have to figure out in our application how we might isolate this code for a certain set of business functionality or a domain. There's going to be some effort there and some elbow grease, but
Speaker: by isolating that code into single microservices or by isolating, for instance, a single domain to a single microservice, we're going to be able to limit the scope in the future of what this code actually does, even though the overall code base from many microservices may still be very large, like a monolith.
Speaker: the individual pieces of functionality will be smaller, more targeted, and independent of each other. And this not only organizes our application more understandably, but in addition, it provides a blueprint for growth of our applications. And then worrying about who knows what about a certain application or who owns it, or who owns a certain portion, teams could just quickly step into a function area of the application
Speaker: and make the updates as needed. Yeah, I'm laughing as you guys are talking, because I can remember an application I was working on that had a comment that said, don't change this value, it works. So Riddhi, how does this guide help out? So the idea behind this guide is to introduce developers to things which they should be considering.
Speaker: when they are thinking about going to microservices. For example, even before developers start the journey, they should first think about whether microservices is going to solve their problems or not. Think of it like this, that as a developer, you are not just breaking a monolith into microservices just because it's a cool thing. There should be a business reason, perhaps, that we should justify taking on an initiative like this.
Speaker: For example, if your application is not getting updated frequently, if there is only very small team or a single person working on application at any point in time. For example, if you're just deploying the application maybe once in a month or once in every couple of months, and maybe scaling is not an issue with the application because this application is a legacy application in sunset mode. Well, in those cases, maybe microservice architecture is not a great architecture candidate for this application.
Speaker: But if this is something which makes sense for the business, if your application is frequently getting updated, there are multiple people making changes. The adoption of application is going upwards. There are parts of application which needs to
Speaker: be scaled and deployed differently than the rest of the application, then absolutely microservices is the right way. So the guide goes into all of these aspects which developers should think about. Then we go to the next level of what are the operational considerations to keep in mind. For example, what are the things to keep in mind when you are going to monitor a distributed application based on microservice architecture?
Speaker: What are the deployment best practices? And then we also talk about compute considerations. For example, containers today are synonymous with microservices. Developers might be compiling their application and then creating Docker images. A lot of developers may like to go to Kubernetes by default, but there could be more than one way to run containers in cloud, in AWS. So the guide talks about some of those services.
Speaker: Then serverless architecture paradigm is becoming more and more popular, both with containers as well as with serverless functions. So the guide talks briefly about serverless architecture when it comes to microservices.
Speaker: Then important aspects such as security, which is probably the number one thing you have to think about. But the monolith application, it is very easy to have security sort of cutting across all the modules. But when you're distributing your application, you have to think about authentication and authorization very differently than how you would do about monolithic application. So the guide goes into some of the aspects that you have to think about.
Speaker: In the end, we cover different strategy to break your monolith application into microservices. I briefly mentioned the strangler frick pattern, which is the most common one. So we talk about this pattern a little more in details with a sample application and some reference architecture diagrams as well. And also, when moving to a microservice architecture from a monolith, it's really not just a coding exercise. In our guide, we put forward
Speaker: some considerations for teams to think about really within their own operations about microservice adoption. An example might be adopting a mature stance on the build and deploy automation and their development process. Since microservice architectures include a lot more moving parts than their monolithic counterparts, it's important for teams to be able to keep the complexity at bay and by managing it so that they can reduce the risk
Speaker: and focus on the value added parts of their jobs. Sounds complicated. Yeah, I mean, when you think about it, I mean, if you're just getting started with it, it may look very complicated. But the complexity of breaking an application into smaller services really depends on factors such as the size of the application,
Speaker: whether application is already built into modules or layers. Do you have clear domains in your application or not? Once developers understand the journey to microservices, there are multiple tools which can help them expedite this process. For example, an AWS tool called Porting Assistant for .NET. It is an analysis tool that can help developers scan their .NET framework applications,
Speaker: and generate assessment which can tell them what are the changes required to take that application to the latest version of .NET. If you have dependency on .NET Framework APIs or NuGet packages, which you may or may not be aware of, by using Porting Assistant, you will get assessment or insight into what are those APIs and what are those NuGet packages which needs to get updated.
Speaker: Speaking of porting assistant, why would you use that? If you have an application which was built over the period of many, many years, very likely this application was built to target Windows operating system, which is a great operating system. But if you're thinking about microservices, you're most likely thinking about scaling your application very, very fast, distributing your application and then packaging into containers.
Speaker: And it would make sense to then start considering latest version of .NET, which is a cross -platform version. And what it allows you to do is package your application, your .NET 6 or 7 applications into really small containers, which can run on platforms like Linux. And because these are small containers as compared to what you would do with Windows containers, these containers can go up and they can scale out in a matter of few seconds as compared to Windows containers, which can take slightly longer period of time.
Speaker: And with Boarding Assistant, you can run it as a standalone tool on Windows Machine. Or if you prefer to stay within Visual Studio, we recently launched AWS Toolkit for .NET Refactoring or Refactoring Toolkit for .NET.
Speaker: This extension is for Visual Studio. Just like Boarding Assistant, the toolkit can also assess your application source code and recommend modernization pathways such as Boarding to .NET 6. It can also identify your dependencies. For example, if your application depends on IAS or Active Directory, the toolkit can perform modifications wherever possible. It also assist you in validating the refactored application,
Speaker: we're running them on AWS services. And with this extension, you can perform all of these tasks from within Visual Studio. So you, as a developer, never have to leave your IDE. And the cool thing is both this toolkit and porting a system for .NET, it is available at no additional cost to our AWS customers. And also another tool that we talk about in our technical guide is the AWS microservice extractor for .NET.
Speaker: This is an additional tool that AWS provides at no cost to customers also. And its focus really is to assist in the process of helping two customers to migrate their monolithic applications to a microservice -based architecture. It scans your application and helps you to visualize the components and modules contained within it.
Speaker: This shows the different types of components as well as the dependencies among them. Then you can use that tool not only to understand the internal structure of your application, but also to help you group the functionality into candidates for different microservices. It helps you to not only understand the dependencies in a code, but also the libraries.
Speaker: that you have in dependencies and libraries that you have in your monolith also. And you can even use runtime data to understand how frequently the components invoke each other to help you make decisions on extracting the microservices. And as the name implies, microservice extractor also includes a feature that allows you to extract functionality into a separate functional microservice.
Speaker: and it will bundle not only the code, but also the libraries and dependencies. And when you do the extraction, you can even include a Porting Assistant assessment using that tool that Ronit just talked about, Porting Assistant. And then you can understand not only the effort that would take to convert your code to a microservice, but also to
Speaker: convert the code to .NET 6 and to understand what that's going to look like. So this extraction piece is not meant to be the end of the road, but instead give you a starting point to see and understand what an extracted microservice might look like from your code and as a result help you to reduce the heavy lift so that you can actually focus on the parts of the process
Speaker: that requires your team's expertise and knowledge of the application. Cool. So this guide is pretty much a one -stop shop, right? Well, our goal with the guide is to create a template or sort of a reference guide for developers who get started with, but there are definitely additional things that developers may want to do after they have gone through all the steps that we have mentioned in the guide.
Speaker: For example, consider similar approach for database decomposition. Microservices are incomplete unless you have decomposed your databases for each services. We could not go into database decomposition in details due to limitations of the scope of the guide, but we would suggest readers to think about their databases as well before they start breaking their application into smaller services. So next, so once the teams have really used our guide and kind of understood
Speaker: this beginning part of the process and started to consider things like database decomposition. Again, one of the things that they might want to be looking at is to consider how to streamline their processes and to be able to improve and automate things like testing.
Speaker: to be able to improve and automate things like deployment. Because what they're gonna find is that once they're operating microservice architectures, that the way that they've been doing things in the past is gonna change. And for teams to really be able to speed up deployments, to be able to deliver those features faster, having a fully automated system
Speaker: is going to really be the, having a fully automated mechanism is going to be a way to have success. And this is going to include say, being able to use things like infrastructure as code or some of the other types of automation features that are available to teams. So where do you guys go from here? Well, for me,
Speaker: It's off to reinvent when I'm delivering two sessions, one with you, Tom, where we are talking about refactoring .NET applications. And for me, so I'm headed off to the past summit.
Speaker: in Seattle where I'm going to be talking to folks about refactoring .NET applications also. Then after that, it's off to reinvent where I'm going to be having a chalk talk with you, Renee, or we're going to talk about how we can use purpose built databases in our modern .NET applications. And this really fits exactly into what we've been talking about in this guide.
Speaker: All right, Craig, Renny, I want to thank you both for being part of the Basement Programmer podcast. It's the first interview I've done, so really cool there. Been a pleasure talking with both of you, as always. As far as listeners, as always, if you have any feedback on this podcast or have any suggestions on topics you'd like to cover, please drop me a line. It's Tom, that's T -O -M, at basementprogrammer .com. I'd love to hear from you, and be sure to
Speaker: subscribe to the podcast so you can get your monthly updates.
