Monolithic to Microservices

ABOUT THIS EPISODE

Technology modernization requires patience and time. Without appropriate planning, thoughtful deployments, and a measured approach, customer experience can suffer when the inevitable occurs. The goal is to avoid that experience altogether.

Peter Mourfield, Chief Technology Officer at TaxSlayer, LLC, has the answer. Peter’s team has worked to create a system for testing to consistently ensure their applications are seamless both at a security level and a functional level. Because it has to - even when there are millions of users accessing it.

Join us as we discuss:

  • How to be disciplined in the tech hype cycle 
  • Leveraging modern approaches at the right speed
  • Testing practices for the enterprise

You're listening to application modernization, a show that spotlights the forward thinking leaders of high gro software companies. From scaling applications and accelerating time to market to avoiding expensive license and costs, we discuss how you can innovate with new technology and forward thinking processes and save some cash in the process. Let's get into it. All right, Peter, thanks for joining the podcast today. How are we doing? I'm doing great, Nick, how are you? Very good? Looking forward to the weekend, but looking forward to this conversation more well. Thank you. I appreciate you having me on. Thanks for making time for us. So, for our listeners, I wanted to go ahead and get an introduction to you. So typically we like to hear about maybe where you started, what got you into what you're doing today, what you're doing today, that kind of thing. Just feel free to take us on that journey. Yeah, sure, thanks again, thanks for having me. Um, my name is Peter Moorefield. I'm currently the chief technology officer for tax slayer Um. But going way back, sort of how this journey started. Um, when I was ten years old, my dad was an officer in the in the army, and the army was experimenting with Um, some Um, I guess, combat simulation sorts of things, and he was fortunate enough to work on a project that does that. And so in nineteen one he brought home an apple to E. I was ten years old and I was hooked from there on out. So started, uh, just hacking away at the apple to e Um, and then sort of just progressed, you know, learned a lot on my own. I went to school, Um, you know, became a developer and kind of progressed through the ranks, I guess, so to say, to the to the role I'm kind of sitting in the day a tax L Gotchas. So you've been a tax layer quite a while. If I I think this coming tax season will be my seventeenth tax season. and Um, before tax there I was with a couple of other companies. Um, I don't know, we go back a little bit, but a company called Ip switch. They wrote software called like W S FTP, and what's up? I was with them a good while too, and then just a few other companies sort of here and there. got so seventeen tax season. That's uh, that's better than most of our s agents. That's what I'm hearing. Apparently there's gonna be Seventy Tho more of them. So we'll I'll be much more better for it. Awesome. Well, for those that I know, a tax layer is I'm in Georgia, Um, so I'm familiar with you guys. But for those that may not know, tell us kind of where you guys fit, how you help customers, you know, give us your your advertised and for the work. Sure, sure. So tax layer Um has been around quite a while. We actually started as an income tax preparation company back in the nineteen fifties. Um In nineteen eighty nine, company president at the time, um saw the need or the desire to want to start developing tax software. So they started developing tax software for tax professionals, people who do your tax returns for you, maybe accountants or just income tax folks. UH, in nine eight we started working on tax or dot com, which is the online consumer version of income tax preparation, which allows customers to come in and individually prepare and defile their their tax return. You know, since then we've we've moved to Um, you know, adding different features and functionality. Obviously, throughout the throughout all that time, we've added a web based portion of the tax layer pro products,...

...so you can professionals can prepare taxes on either a desktop application or on the web. And then, of course, we have taxire dot com where, Um, folks from all over the world can come on and find their taxes and get their refunds. So tax preparation for all anyway. You can handle it. However you want to slice and diise that, we can handle it. Very cool. So, obviously, being in an organization that's been around a long time, um kind of broadened its customer base. UH, later on, MHM, dot com boom probably been through a lot of transformation over the years. Yeah, to say the least. We it's it's been through a lot. Um, primarily really when we started to pick up market traction in the early two thousand's and Um, you know, we saw tremendous growth over all those years and continue to see tremendous growth. Were very blessed in that regard. But sort of to bring things home, probably in nineteen we started to sort of wonder if our current online application architecture was going to kind of keep up with the growth. You know, at the time we were running sort of uh, monolithic architecture. Um, client server in data centers, Um, you know, three level architecture, meaning, you know, there's a front end, there's some business logic and then there's data access. So sort of what was uh, state of the art, you know, in the two thousand's? Well, with any monolith or so sort of what we began to to discover was, you know, if you want to scale, you know, a big Web web application out, because one component of that web application starting to get used more and more and more and more, because it's just one thing, you have to scale the entire thing and so you start to get a lot of sort of resource under utilization and you can just create bloat also, right. So around that time we started to really think about that and we we kind of all got together and put our heads together and we decided we're going to run a proof of concept around micro service architecture, and so we were able to kind of uh cobble something together that worked well for us, UM, prove it out and then go to the business and say that. Next year go to the business and say hey, this, this is really working for us and sort of here are the problems that it solves. You know, Um, it gives us, UH, greater resiliency potentially, it gives us the ability to sort of scale those components that need to scale and it's a better utilization of sort of the infrastructure that we have. About what time was that kind of change that you guys were considering? Was that recently? Was that a number of years ago? Just trying to set the table timetable for the listener. That's twenty nineteen. Is We were really starting to get into this. Okay, so, you know, we settled on architect sure that you know it was micro service based. We were considering cloud adoption at the time, of course, but so we wanted to think about ways we could architect the application so that we we weren't necessarily tied to one cloud provider over another. So we we looked at doctor and KUBERNETES and sort of settled on that as an environment to run in and, you know, are continuing, even to this data to sort of go through that migration process, just, you know, pulling off components sort of one at a time, knocking them out, converting them to modernizing those application components and then, Um, moving on to the next one. So we're getting very close to sort of wrapping that whole thing up. But the more and more we do it, the more and more we learn and we get better at it and Um, it's starting to work really well for us. So I think what's great about what you just said is he started this process in two thousand nineteen. We are heading towards very quickly. Things like this take time. What would would that be? A A wise bit of advice...

...for someone he's Kinda but I think absolutely. We we needed to take time to one prove out the concept, and so we picked a small component and around a proof of concept, Um, and we did that. You know, our business, as you can imagine, tax season is very seasonal and we have a lot of spikes in our traffic, in demand over that season. So tax season is really, you know, January to mid April, and the rest of the year we don't see a ton of volume. So we needed to take that time to sort of run our proof of concept. So the way we did that and sort of the way we continue to run is in a hybrid mode, meaning we have components that have been modernized and so those things run Dr Kubernetes and then we run hybrid in the sense that we still have things that haven't been modernized and those are traditional sort of monolith things. So we we sort of run them both at the same time now, you know, because of the seasonality of our business and how that affects our revenue cycle. When we were running the proof of concept, we basically had to run both and so if we found that our PSC was going to fail, we had the ability to feature flak, turn it off and go right back to what we had and then we would have to regroup. Fortunately we didn't have to do that. We're very lucky, you know. It's just we've proved it out. We learned a lot. We continue to learn a lot in the progression continues. Oh, that's interesting to hear. I think you know somebody, somebody organizations struggle with the path. Right was you're learning new things. The team is probably operating outside of the comfort zone, Um, at least initially, right and Um, you know, I think it's what's interesting for tax layer is that you kind of have this unique time to load test and production because of the amount of volume that comes in and you probably have a peak probably later in the year for all of his late filers as well. The little up there right we we get a peak sort of around when folks um get their W two's and they're ready to file early, and then we get a peek right at the end of the season, right for for all of us who procrastinate. Very good. Um. So, while you're what are your teams going through this journey? Um, what was a unique challenge that you ran into other than the seasonality of, you know, the workloads coming in? I mean the fact that you were able to kind of do this this hybrid approach is pretty cool, but I'm sure there were a couple of things that maybe we're stumbling blocks where you you got to spend some time on the white board. For sure, one of the most important things that we needed to make sure is a part of the transformation that was a challenge to us to get right, because we had to get it right the first time, was really integrating our security environment into the net new code that we were writing. So, you know, we we really dug in on Dev sec ops and sorted to storted to implement a lot of that stuff into our pipelines very early on so that we could ensure that we were being, you know, as judicious as we can in terms of you know, our security requirements. Um. So that that was a challenge. It was a lot of learning, Um, and so there was that really also running the h this hybrid model that you know, I mentioned on our operations side. There was a lot of learning that needed to happen around the doctor and Kubernetes because, nick, I'm sure as you know, you just don't spin up kubernetes and it just runs right. There's things that you have to do to it to uh, to make it run efficiently, to make it scale the way you expected to. So you can't just, you know, coupe cuddle something up and it's just gonna work perfect. So so. So I say that because we had to start to build that expertise and we brought in some folks to help us build that. But we also had to maintain the legacy also, so we had to split our infrastructure teams so that they could folk hasn't really kind of become, you know, either a devops...

...kubernetes person or sort of a legacy person, and then as we transition more towards one side, we can move folks over, but we really needed them to focus and have that specialization. So that was another challenge that we had and then really nick you know, you know, kind of like in the in the programming language wars. There's some more sort of around cloud technologies too, and you know, we had to really dig into some of them and, you know, not believe the hype or at least sort of validate some of the hype on our on our own and sort of picked the technologies that were best for our use case. Um. So, yeah, those are sort of the three big ones that we ran into. There were, you know, hundreds of little challenges daily, but Um, those are huge things that we really wanted to focus on. This is a been a rabbit trail a little bit. But so when you have to go through the evaluation of the hype cycle in Tech, which is all the time, do you all have a access for that or do you you have maybe a personal approach that you like to take to try to validate something's real and and then, Um, probably label it correctly, because I think a big challenge in tech today that we all deal with and Um, you know, organizations like mine trying to be very conscious of the next hype cycle. You know, we're into customer outcomes, so the latest and greatest you know, we're just as suspicious. So so what? What? How would you apply that Um discipline to how you evaluate technology? Great question, Nick. I don't know that I've ever thought of a specific process around that. And then, just to take a little bit of a step back, I think this just sort of goes to, you know, advice I would give to sort of anybody, and it's always sort of validate your assumptions and and that can apply sort of at any level. Right. So tech changes so fast. We might have tested something yesterday that didn't work the way we expected it to and had to adjust. But when we face that scenario again, you know the tech may have changed, there may be a new offering, there may be an update. That happens that we need to go and test against to sort of make sure that our validated, that our assumptions are validated. So always sort of question what you think you know is true, because everything moves so quickly. You know, it's changing all the time. Um, in terms of sort of picking one technology over another, it really comes down to and I think for anybody there's no golden rule there. You have to test it sort of in your use case, meaning how we use certain technologies. It's going to be different than how other folks use certain technologies and those products will react differently to the different workloads. And so, you know, testing it sort of against your use case, I think, is also very important. So having your use case well defined might be a good starting place. Oh, absolutely, if you don't know what you're testing for, then you know, it's funny. I heard quote earlier today and it says, well, I'M gonna get it wrong now since I brought it up, and says is if you aim for nothing, you'll hit it a percent of the time. So you know, yes, you need to define your goals and sort of set where you're going for. They don't have to be raised or sharper, you know, pinpoint goals, but you have to have something you're you're going after, right. Yeah, the you know, it's funny. The I had a discussion with a developer a couple of weeks ago about about requirements just around a project and they hate requirements gathering and I understand that because that that process from a project management perspective can be a little arduous um maybe even stifle some of the creativity around that. But if you don't have maybe a couple of requirements. It's pretty hard to build stuff. Last time I checked. Well, no, absolutely. You've got to know what the finish line is and you know, as a a developer myself, you know I I trend whenever I have...

...to take my hands off the keyboard and go do something else like, you know, talk to customers or gather requirements or whatever it is. But you know, I come back to you've got to know what the finish line is and, Um, you know, requirements are a part of that. It's kind of like paying your taxes, Nick. You know, it's just something we gotta do. Yes, that's right. Um, what is something you found useful along the way? So it could be related to something with your team, maybe a practice or discipline. Um, it could be anything really, but something that might be useful and sharing. Really two things, Nick. The first one I would say is, as you're sort of operationalizing your application modernization effort, whatever it is, you need to make sure you have a robust monitoring and observe ability platform sort of in place, because you need to know what's going on. You need to know what your metrics are, you need to know sort of what the air rates are. You want to know those before the customers start calling customer support, and so having visibility into the production environment is key, and that that takes some some tweaking to do. It's not easy. It's not just, you know, UH, spinning up a monitoring pod and then having it just sort of dump everything on the screen. You've got to really know sort of what you're looking for and you've got to keep an eye on it. So setting those metrics is key. Also, the other thing, and I've I've kind of alluded to it a few times, is man you gotta test, test, test and test the more and when you think you've done all the testing you want to do, you got to test it even some more, Um, and that's everything. That's, you know, functional testing, that's testing the infrastructure, that's performance testing. You want to make sure the scale, you know, things scale the way you want them to. So test, test, test. Those are probably like the hugest things that we're sort of takeaways that we had sort of as we began to operationalize this. Yeah, I've I've seen that the honoring and observe ability space is troubling for customers. Um, there's so many options. Um, a large variance of degrees between best to breed and just good enough, free, expensive, and then you have to sometimes you've got a cobble together three or four things to get the results or, I guess the unit's measure that you need and then you gotta put it somewhere, which is often another system. So you know, it's funny. I should I should have you talked to one of my customers now about the importance of that. You know, I've got a customer that they don't have any of this and I'm just like how do you troubleshooting? They're like, Oh, you know, we just we just work on it until it goes away, and I'm just like, Oh my God. So and some people may have that, that luxury to be able to do that, but when you've got millions of customers on your website and things just aren't quite tracking the way they should and you know you've got to have that Raiz or sharp sort of focused on what's happening in production real time right now what we need to do to deal with it. Yeah, absolutely curious. Do you guys um? Do you guys do like application performance, um monitoring in and tracing in like Qua, for example, even before it gets to prod trend I'm seeing. So yeah, so we do it in our staging environment right now, which is, you know, where we go right before we go to production, and that's after Qa sort of done their functional sign off on it, and we'll we'll run stress tests and whatnot against our staging environment, you know, then look at the performance metrics of that before we sort of go to Praud with it. Gosh, it okay, yeah, that's that. That was a hot topic a couple of weeks ago around here, and that's why I figured someone who's got, you know, so many customers relying on and, you know,...

...your application to work when they go there. It needs to work, that you were probably doing something like that, because we're seeing that trend. You know, it's it's important as as as these applications become services to consumers, it needs to work. Brian, they expected to work. Yeah, otherwise they'll go somewhere else. Right. Absolutely, they expected to work and they expected to work the first time. What's Um something you're excited to see in the future of technology? You know, this cloud migration that we're seeing of all these applications as they sort of moved to, you know, whatever their cloud provider choices. Is really sort of exciting because the cloud providers are learning sort of as the customers moved to the cloud, like what do we really need, what we really care about, and just there's so many new offerings coming out of all the different cloud providers that there's just, you know, just really exciting stuff there. Also, you know, there's sort of the the democratization of cloud to you know, prices are coming down. Um, it's going to continue to come down and it's gonna make it easier and easier to sort of just be in the cloud and, you know, have all of your infrastructure out there. So I'm not saying data centers are going away or data centers are dead by any stretch of imagination. I'm just saying that, you know, as the cost comes down, that barrier to entry to move off of a data center, the Calculus starts to look a little more interesting for some folks. Those are things that are exciting me. You know, price coming down, the offering sort of maturing and really sort of Um, getting better. Some some cool stuff coming Gotcha. Yeah, I was I was really hoping you wouldn't Um appease me with the joke and like. I can't wait to see what you know, tax layer looks like in the metaverse. Put on your VR goggles and we'll do your taxes virtually across from you, just for just for fun. That's man, that's what we're doing on a Saturday night. That makes sense, I think. I think the you know, to your point, data centers aren't going away. They're just there's gonna be three or four companies that own them. So they're gonna unify and make that a little accessible, hopefully over time. But I don't know. Last time I checked, the day center practice is doing okay. Yeah, I think they're doing just fine, but you know, they're having to adjust too and, you know, make sure that they can connect to the cloud, whether it's things like express route or whatever they're they're in this business too. Yeah, absolutely, because it's I think it's pretty if you're starting a business now, it's very easy to go we're gonna be cloud first. Um Our organization had the benefit of that. You know, when we started back in what your whatever year that was, oh eight, we we didn't need a data center. The services we needed were already kind of SAS based or Um. I mean even like the you know, the what cloud we have today was not m it was kind of just starting. But basically, you know, all the things that we'd use, like a salesforce email platform, all that was available to us somewhere else. So as that started to grow and we'd build out our own applications, our own pieces of infrastructure for whatever we were doing internally, we did it on the cloud and that was pretty cool, but to the point that we'd end up hiring people that Um and never seeing a physical server, and then we'd be like, Hey, this is what a server looks like. We actually bought a rack of equipment and said, you know, this is how this works, and we set up a little lab, you know, in case you ever have to go somewhere where, Um, you know, some Hotshot Tech Grad comes and starts working here and they're like Hey, never everything I've done is an aws. Well, that's weird, because the world doesn't completely work like that. Anyway. This is a SN trade, not a cup holder's right right,...

God forbid. You know. The thing also sort of with the cloud, migration and data center sort of conversation. You know, there's millions of businesses out there that have their applications running in data centers and you know, no matter how much sort of the cost comes down, it's not necessarily going to make financial sense for them to move. And then, you know, that's fine for them. But, you know, I think it's worth you know, companies who are, you know, very active sort of in in that space to to sit down with some pricing calculators and do the math and see if the cloud migration makes sense for them. We do that, we we and then we go back and Redo the math because that stuff changes all the time. So, Um, that's that's also sort of a piece of advice I would give us. You know, don't think the math you did three years ago on the pricing calculator is the same as it is today, because the offerings changed in the pricing change. That's that's a good point. There's a and also, you know, the labor market changes, right. So as as we as we continue to become maybe younger over time. Um, those those folks coming out of university, they're just going to be very comfortable with public cloud resources and that's gonna that actually be a thing and they're going to attract people to come work for your organization. Hey, we're doing things in the cloud. Oh, it absolutely is. You know, we have conversations with candidates now and, Um, you know, they want to know sort of where we're going with the tech stack and what the technology wrote map looks like and sort of where we think it's going to be in three years. And, to be quite honest with you, nick, if I knew where it was going to be in three years, Um, you know, I'd have some investments in the stock market to back that up. But, although not this week, but you know, yes, well, actually, maybe maybe this week is the week to get in everything right. Um, you actually kind of jumped into my next question, which is great, but let me let me if it's slightly so we'll wrap up with this one. What's something that you look for in a candidate to add into your at your engineering team? What's it? Maybe a quality, it could be it could be a technical thing, or it could be, um, like a soft skill. Sure. Um, what I like to see in candidates, and this goes back to something Joel Spolsky said many years ago, Um, I like to to get folks who are smart and can get things done. And and what that means is is do they have the technical basis, the technical understanding to sort of work through problem sets. Does that mean I ask them Trivia questions about trains coming in from California in Chicago and when? Do they mean? No, but, you know, can they work through a problem? Can they think through a problem? Um. And the second part of that kind of to get things done is is we are. We live in a world of trade offs, and I this a lot. You know, perfect software never ships. Good enough software makes trillions of dollars every year, right. Um. So we live in a world of trade offs and learning to sort of balance those trade offs, you know, is key, I think in this field too. So strong technical ability, ability problem solving skills and the ability to kind of recognize and work through tradeoffs. It sounds sounds like a good formula. Well, Peter, absolute pleasure on my side. Thank you for, you know, taking thirty minutes to talk about tax layer and what you guys are doing over there and what you see in the marketplace and your journey and I think it's going to be really helpful for our listeners. Well. Great, Nick Again, I appreciate you and listeners sort of having me and and making it to the end like this and not turning it off before. So thank you so much for thanks so much. Application modernization is sponsored by Red Hat, the world's leading provider of enterprise open source solutions, including high performing Linux, cloud, container and kubernetes technologies. Thanks for...

...listening to application modernization, a podcast for high growth software companies. Don't forget to subscribe to the show on your favorite podcast player so you never miss an episode, and if you use apple podcasts, do us a favor and leave a quick rating by tapping the stars. Join US on the next episode to learn more about modernizing your infrastructure and applications for growth. Until next time,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (29)