Tiempo Talks Episode 2 – Microservices Are Here… Are You Ready?

Enjoy this episode? Subscribe to our podcast on your favorite platform to be notified when a new podcast goes live:

Apple Podcast
Spotify
Podchaser
PodBean
Castbox
Castro

Published Fri, 2/21 7:59AM • 38:06

SUMMARY KEYWORDS

microservices, system, devops, product, business, organization, approach, monolith, team, understand, application, call, micro services, development, customer, challenges, building, service

SPEAKERS

Angel Almada – SE Tiempo, Sean Sullivan – CTO CBT Nuggets, Perla Gomez, Mike Hahn – COO Tiempo

Perla Gomez  00:05

Hello and welcome back to Tampa tux. I’m your host, miss. Today we have a very special episode in which we will be discussing one company’s CBT nuggets transition to microservices. We have with us today nuggets, city, ocean, Solomon, temples, see all my can and temple director of solutions engineering Akela. It will have their turn to discuss the ins and outs of 17 August transition, as well as their role they played. Some of the questions that will be answering this episode are are microservices referee company, how do you know you’re ready? I was ready look like why do so many companies fail? What are best practices and how can you hit a home run? So Mike, can you start off by explaining to our audience a little about what micro services are and what businesses can hope to achieve by utilizing this approach?

 

Mike Hahn – COO Tiempo  00:51

So we’ll take a quick stab here really defining what we look at as micro services and how this ends up working. Ultimately what this is about is a very flexible development environment that allows you to take features and develop them independently of one another, and then get them deployed independently of one another. So you can ultimately piece them together to make a large scale product. So some of the big advantages of moving to microservices in this world is really around leveraging multiple programming languages in multiple persistence layers, which is also known as polyglot programming to kind of get you to that point in time. So instead of sitting down and going, I want to do everything a.net core, everything’s got to live in. NET Core. One of the ways that micro services can kind of help you from that definition perspective, is you could potentially develop things in different different languages and different environments. And from this definition, around from the business perspective, Sean’s gonna tackle the technical stuff. But instead of large scale releases that potentially take you months to track requirements, develop and deploy the deployment and development In a microservices environments allows a business to generate revenue quicker from your investments in development. So instead of waiting and doing a quarter to release or up or at every six months release, you can develop and release every two weeks, every month, every day in some instances. So it really kind of helps you take advantage of the business requirements around that.

 

Perla Gomez  02:22

Mike, it sounds like there are several benefits to making the transition to microservices. Can any organization or application take this approach? Or are there some considerations that should be made before an organization decides to make this shift? When is microservices a good fit?

 

Mike Hahn – COO Tiempo  02:39

microservices are moving to microservices, really not the right decision for every business. So I want to really focus on the business objectives here. So the investment required to make this for an organization is significant. It’s not just Hey, I’m going to take this five person development team and move them over here and boom, they’re going to do microservices. requires an investment. In one of the overarching questions that you really have to understand from your business perspective is Will your customers see a benefit in this investment? And how will that translate into additional revenue for your company? just rewriting an old application may not make any sense. You might want to look at other performance or feature improvements that you can gain only through the microservices that you couldn’t do in your old monolithic application. And are there competitive advantages to doing it? Are there things that you could get to market quicker or their development processes you can get done faster that will help you get up in front of the competition?

 

Perla Gomez  03:38

Let’s jump over to Shawn real quick, Sean, can you tell us a little about CBT nuggets, why their organization decided to make the shift to microservices and how that must benefit the business.

 

Sean Sullivan – CTO CBT Nuggets  03:49

So with our business what drove us to move to microservices so to set the stage on that note is a monolithic application built on on.net with a very large Postgres database, there’s a lot of value into that, um, you know, the business survives quite healthily for many years with this, but what we saw was not just the expense of running this, you know, as we’re scaling out to more and more customers and learners, but also the way we wanted to scale the application for, for usage. And, you know, to, to scale, a monolith can actually be quite expensive, require a lot of horsepower when you’re looking at a lot of concurrent sessions and threads as experts in the same resources and what have you on scalability, and we’re also looking much at the key to growth that was before us. So, you know, around the time we undertook this adventure, we’re around a dozen developers, but we knew that we wanted to double triple quadruple in size of our development team to tackle the aggressive roadmap ahead, products benefit. And so with that, when we looked at A monolithic architectures, the cognitive overhead of working that system that was before us. And within that, you know, just the the issue of the touch code in one place, how’s that going to affect something another place in my career spoke to the ability to deploy frequently, and often. I’ve heard them or the technology selection. So dotnet is a technology that service quite well. Postgres is database persistent, where that serves quite well. But there’s other things that we knew we wanted to do and other technologies we want to take advantage of. So microservices could really offer a way for us to make that happen. Holy, just kind of bring it home was the roadmap and scaling the organization such a way where we can make that happen, so we could better the product called learning experience.

 

Perla Gomez  05:44

Thanks, john. Now, I know from our discussions before the show that one activities business goals was to move into more of an enterprise market. Did you move to microservices facilitate some of that feature development and help CBT meet those business goals?

 

Sean Sullivan – CTO CBT Nuggets  05:58

Yeah, you know, I would say so, you know, speaking back to the product attributes, the reporting aspect of our of our product was quite valuable in that when you’re spending money to train your team, you really want to receive some feedback on what they’re training on and how they’re benefiting from that. That aspect of our system was something that we knew we need to give a lot of growth to. And so by, by using this microservices approach, we were able to, kind of in quarantine, I’ll use that word work on this recording system off to the side. So it was not affecting the rest of the platform development. And then as we could start to derive value from from what we were doing on that side of things, we could start to take advantage of that on the problem. So looking into that. So that’s just one one example of how we found out to be advantageous.

 

Perla Gomez  06:48

Thanks, Sean. Now let’s talk a little about tivity nuggets and some of the challenges they were facing that led them to consider these migration. Now I am curious, Mike, what things do companies need to get right In order to make this transition a smooth one,

 

Mike Hahn – COO Tiempo  07:02

there’s three things that you’ve really got to nail to get this right. The first one is really around product management. So when you’re looking at prioritizing decoupling, you’re you’re looking at modules that you want to move first, or, or, or order, if you will, that you’re going to attack this monolith to move it to microservices, everything’s got to be driven around business value. And more so than that, it’s also got to be driven around the feature sets that are going to bring the most value to your customers. And then from the product management side, really setting the expectations of what that’s going to entail, getting the business buy in from the top of the organization all the way through the development team, and maintaining the discipline around that product management on how you’re going to execute that. The second thing you got to nail is really the architecture and the environments. And I’m only gonna touch on this very briefly because Sean’s gonna really hit on this, but you want to look at your capacity and your utilization, and really understand the desired effect. of where you’re trying to get with your product, and then look at the steps that you can take to get there. And then the third area is really around DevOps, continuous integration, continuous deployment, getting feature sets and getting product releases to market quicker to get the return on investment of your development dollars. This really has to be nailed. We’ve seen a lot of areas where we can get the first two, right, but then when it comes time to deploy and get it to AWS, or get it to Azure, or get it into a data center, private cloud hosting or what have you, the whole project stalls there. And then what ends up happening is you end up not being able to get it into production and get the business value, which then starts getting you questions up and down the organization about why you couldn’t get to that point.

 

Perla Gomez  08:44

You mentioned that many organizations struggle to get microservices to production because they couldn’t quite get the DevOps component in place. What are some other specific challenges you have seen organizations face that they should take extra care to avoid?

 

Mike Hahn – COO Tiempo  08:58

So sometimes when you go to Through these journeys, you learn as much about what went wrong, as you did about what went right. And so, really taking a look at staffing, your current team, your your current processes, do you have an agile methodology? Do you have a waterfall approach? We really believe that the way to execute the microservices path is really to morph into more of an agile process and really be able to execute in a scrum agile environment. You know, ci CD, continuous integration, continuous deployment around the DevOps, a lot of organizations we see that sitting in their own little silo. And like you said, Shawn’s gonna hit on this a lot more about how that culture has to be integrated throughout the entire team. The decoupling side, we’ve worked on a couple of engagements where what to decouple first was an internal decision. And they went down a path and they started doing that. And then they brought it out to the business and brought it up to the user base, and said, hey, look at this great thing. We’ve got this new service. microservices, and everybody was kind of like, area, whatever, you know. So it wasn’t really driven from the outside and it was more driven from the inside out, which kind of gets me to the the internally driven requirements. We can’t stress enough that you’ve got to have a lot of market validation to understand what your customer stakeholder sees the most value in your organization. And then and executive management buy in to understand what the, what the cost and the investment is going to be to make this trance transformation. Because of either of those two are misaligned, you’re going to end up putting stuff in the market that people don’t care about, or you’re going to end up putting stuff in the market that costs you way more than what the business value derived from to get it there. So this thing can take a lot of a lot of looks a lot of fields and have a lot of different ways to approach it. But understanding your DevOps, your cicd your architecture and your product management. If you can nail those three things, you’re going to have a much more successful outcome.

 

Perla Gomez  11:04

Thanks, Mike. Now, Sean, let’s dig in a little into how civitate actually approached the migration and how you were able to conquer a lot of these challenges that Mike was talking about.

 

Sean Sullivan – CTO CBT Nuggets  11:16

So going back to kind of where I left off the, the system as a monolith, it was just too complex to manage. And that comes down to I spoke to cognitive overhead and the scaling of the application. But let’s talk about deriving business customer value from what it is a building software you’re building. And to me that begins with how often are we able to deploy and actually shifted that product enhancements or additions. And what we found was with this monolithic application that deploys were sometimes a tightrope back you were concerned about, Okay, I’m going to ship what we think change with a see seemingly innocuous change could have ripple effects. We’ve all seen that happen before where you know the payment systems roxxon And nothing’s really changed with that for four to five months, you know, does adding a feature over here need to affect that? And the answer is, well, ideally it shouldn’t, because we don’t want to have that in our head when we’re pushing it out the door. And so with that, that’s why we call it the impact of stigma to change being widing. You know, sometimes often unknown. So the product, you know, we need, we need to be able to scale this in such a way as well with both the team and the, the technology to standpoint that we can, we can get that value and we can anticipate the product growing with the customer base. So how do we how do we begin? How do we start to really look at this transformation? How can we move a monolith to microservices? To me, it starts with understanding the system and knowing where those true pain points are. And then we keep talking about scalability. But in our case, the pain points where we had certain systems that designed the way they were in this three tier architecture going to coupled to a single database, the, we were having some opportunities around stability. And with that, we looked at certain aspects of our system. So when we were to break this out, do this in a new tech stack, we can do this in a more effective way. And if that were to continue to encounter opportunity to after it gets split out, that’s not gonna affect the other parts of the system. And so starting to kind of look at those pain points, where are the places where we’re kind of falling short of where we want to be from a stability and experience standpoint, and really going after those three ARCHICAD. With us, we really began with our authentication authorization system, because we knew that was a critical piece that we needed to calibrate correctly to the way we want to build our future systems. So we tackle that we went after some systems around our digital rights management and how customers, you know, the licensing of their subscription, that sort of thing. And started to break those out and put those in way where we could, you know, evolve those on a totally different trajectory than the rest of the core business systems that were already well established. You know, one of the ways that you can do this, you hear commonly microservices something called the strangler pattern. And the idea there is you don’t have to wholly cut off the systems that are within your monolith that you build, these ancillary systems are starting to, will say, starve the oxygen so they no longer having value they once had. And so you start to kind of tease those out. Another way that you can really get this going is to establish what are the contracts and protocols going to be for communicating with these services, really make sure that those are well defined. You don’t necessarily need to be too concerned as a team working with a another service of what’s happening within the confines of that service. But as far as how do you how do you communicate with that? What is the API and what is the protocol is HTTP, etc, and How’s it going to work, make sure those are well documented. So moving on to the best tool for the job, part of the conversation here. So this is, to me, this is one of the major benefits of microservices. And that’s, you know, kind of going back to that statement of, if you have, if you have a team that really knows a technology strongly, and you want to take advantage of them, you can do such you don’t, not everybody has to play necessarily in the same pool. In our case, we had a dotnet application, but we also had access to a lot of really strong JavaScript developers. And at that point time, excuse me, no JS had really come on the scene as a really strong application language for for doing these types of services. And we didn’t have to, as Mike mentioned, we didn’t want to go off and go dark and rewrite this whole application come out a year later without here’s our whole new, new and improved CBT nuggets platform. No, we wanted to go on an evolutionary journey. And by taking a microservices approach, we To build that off system or that license licensing system by spoke to and do those in a completely separate language, albeit with a very defined protocol and specification for how to communicate with that service, but the.net stuff can move on, we can still be deriving value of that day to day and continue to evolve that the same time be leveraging other expertise and knowledge to build these other systems. That when we asked about, you know, why no JS? So I already have an expertise thing, and everything with no, that’s very valuable as the concurrency model with the event moving for anybody who doesn’t understand, understand or no the technology there The idea is, is notice and create for CPU intensive operations, but but when it comes to stitching together a lot of disparate sources doing that, that I owe, it really exceeds that at making that happen in a very effective, efficient, scalable manner. So we saw a lot of benefit to that. Going back to the data store, End of this, you know, CBT nuggets were very much a right tool for the job kind of shop. So when we look at what we need to build a solution Well, now not everything is going to fit in the same database. Some things are great for relational models, some things are great, more than NO SEQUEL, you know, is it something that we can write those records and perform those right intensive operations ahead of time kind of had that materialized views approach? Or we could potentially, you know, put everything in a relational model and then let the database you know, handle the normalization of all that for us. And microservices, the point being here. microservices gives you the opportunity to make those decisions on a case by case basis. From the outset of your you’re designing your architecture, designing your system, you don’t have to just lock into one technology and just cling to that all the way through you can be evolving. Evolution is a very mature evolutionary architectures had become the perfect Wisdom of the day. And that is from the outset, we’re not going to try and get 1,000%. Right, we’re going to put ourselves in a position to take advantage of the things as they emerge and, and leverage those. Another important thing to speak to here is obviously, when we talk about three tier architecture, the view view, where is a very important part of that with us as we’re moving to the services and kind of getting away from the old model of what the dotnet model with a given us with a view where we really wanted to take advantage of, you know, more of a pure client side approach with our web side of our platform. This is not speaking to the mobile mobile end. So with the website of that we looked at react GS, as a clear winner for a few reasons, and we vetted a lot of other different approaches here. But, you know, first and foremost is the fact that react offers these really nicely encapsulate components that allow you to, first of all, you’re gonna hear me say this again, reduce the cognitive overloaded working on a piece of code, but also gives you some code reuse capability. So, for instance, that CBT nuggets that calm, we have a common component library, we’re able to really kind of leverage those two different applications or different product aspects. The Dom abstraction is something that’s important to point out, you know, anybody who’s done web development for a number of years knows that the browser’s come with their own interesting things when it comes to compatibility and performance. And in a lot of ways, this helps alleviate that. And in addition to that, you know, frameworks are always a really hard thing to select, because all of them want to do different things have different ownership, some of them take on everything. Some things don’t take on the things you would want here. I know throughout that quote, give them the finger that take your arm. I think that’s very apropos. React doesn’t do that kind of lets you make decisions down the road.

 

Perla Gomez  19:55

Shannon, let me step in here real quick with a question. Just just covered a lot about how job decoupling the application and some of the technology decisions that you have made. Earlier, Mike indicated the DevOps was a really critical piece to this puzzle, and that the whole thing falls flat if you can get this part, right, was DevOps a big part of your success? And if so, what was cbts approach?

 

Sean Sullivan – CTO CBT Nuggets  20:18

I think, to me, this is probably the most one of the most critical things to get right that you’re going to do Mark microservices. Right. And that is we hear this term DevOps, what does it mean? Now for me, it’s, it’s a cultural shift. So DevOps means no longer living in the days of a developer writes code, throws it over the wall, and an operations team shifts it. The idea here is that the developers not only build it, but ship it and also monitor and observe it while it’s out in production. And so it’s their baby their babies from birth, island to the wild and they are Understand the way of operating top to bottom. And that just provides so much value because you’re no longer having this. This idea of ownership going to ownership going to the operations team where they’re on pager duty that some people are actually writing the code who are responsible for the understand that application. Going back, take a step back here, the the shipping aspect of this is very important, Mike talk about ci CD. And the point here is, as we’re building systems and we’re adding value continually, we want to be shipping that continually we don’t want the lapse in time where if something has been built and hasn’t been brought out to, to the customer. So the idea here is by putting smaller changes into production more frequently, we’re going to decrease the volatility of the hesitancy. Now, we’ve all been we’ve all seen before, where there’s two weeks where the coach ages back up in a branch to get that out. There’s a little bit of trepidation. Because while there’s all these things have changed well, that you can reduce that cognitive load, shifting a change to just a minimal piece. And it’s less likely something’s going to not be optimal once it gets out there, because you’re going to get to know exactly what changed, it’s gonna be a smaller thing to have to, you know, digest, and the customer gets it sooner. So we all win. In order to do this, really, there’s this this undertaking of building, you have to build a pipeline, you have to build a really solid pipeline where the cultural change of maybe a master branch that everybody’s continued emerging into. There’s other philosophies on how to manage your code versioning around this. But the fact the matter is, is as developers are checking in code, and we’re executing tests against them to make sure everything is rock solid, going from that moment of checking to that moment of shipping is seamless. It’s a continual pipeline. happening. And then here again, we kind of hit on the, you know, the engineering organization how, you know, I’m gonna harp on this again. But it’s not just the ops team to keep it up and running. Now upstream is not the ones who should get the call at 2am. In our organization, our DevOps team is really responsible for building this platform that the developers are using to, to publish their applications onto. So a little bit of a shift of the days of emailing a artifact to a member of the ops team. And then they SSH into a server and push it up there to more of this pipeline of checking code to GitHub, and then have that go through a peer review, have some tests executed against it, and then it makes it way out to production for the customer.

 

Perla Gomez  23:45

Thanks for going into that Chan. In addition to DevOps, based on C which is experienced through this process, what wisdom would you impart to others looking to take on their own monolithic to micro

 

Sean Sullivan – CTO CBT Nuggets  23:56

service journey? So you know, coming out of all this to where we are now in our journey, which is painfully close to being done with the migration out of the monolith. I just wanted to kind of call out some things that going into this had been had been spoken to me as requirements that we need to take seriously. And what we have found really, truly should be considered requirements. And person foremost is don’t start chopping up a monolith until you absolutely understand the domain problem. So, in order to build a service, there’s a lot of decisions are going to be made around where the boundaries are, what entities live in what service, there’s a fantastic book called domain driven design that speaks a lot to this. And you have to really look at your product and look at how you’re going to divvy up the aspects of it into the services. And that could have to do with a number of things. It could be team organization, it could be geographical, potentially, it could be let’s say The way it needs to scale or even looking at the roadmap ahead and what the evolution is going to be like. So if you have one aspect of your product that’s going to be changing a lot over the next year, you’re probably going to want to consider getting that into its own isolated service. So that the changes that happened in there only happened within that and are exposed to that nice clean protocol and contract that I spoke to earlier. Furthermore, that we might get on this a little bit earlier, but we have to get away from architecture being this ivory tower, you know, we’re going to plan out with UML diagrams, what we’re going to do for the next two years, send it off to a team and build it. No, we have to take the approach of getting the right personnel onto our team. So that we can allow an evolutionary architecture we can allow the use cases and the product needs to emerge over time, and really take that agile approach to what it is that we’re building. Let’s not try to plan the whole thing out advanced, just cut it to make sure that we don’t get backed into a corner, we’re always able to absorb the needs of the business and make sure that the capabilities can be a good place to build up a product that way we want. Conway’s Law, something that you’ll always hear brought up was about microservices. And the best, most terse way I can explain that is if you ask three teams to build a compiler, you’re going to end up with a three phase compiler. And really, it comes down to the way that teams naturally communicate and once again, go to that protocol and those channels through contractor which they’re communicating. And so we really, microservices is a cultural thing. It’s an organizational thing. It has to do with the way the teams like divvied up the way that the personnel works together. Obviously, we spoke about the CI CD pipeline That it’s Paramount that that is in place and is correct. And DevOps cultures understood from the top, from the executive suite all the way down to the people working in the trenches day in day out to make it all happen. And it’s that ownership the empathy of being bought in on it together. observability is something that is absolutely critical. And the reason why is because in a lot of ways, we were making our system so much more complex. You know, we were giving up the benefit of having a singular application with perhaps a singular database. And we’re moving to a whole network of communication and systems that are going to have their own their own behaviors, they’re going to fail in different creative ways that we’ve never seen before. And so observability means making sure you have the right probes and the right monitoring notifications in place so that you can under Standard system. And this is one place where you will see cognitive load spike with working on your system is if you don’t understand that we are changing one system in a way that that addresses information how that affects downstream systems. If you can’t pull that picture up quickly and easily, your developers, your team will be spending a lot of time tracking down data flow and error logs trying to understand what happened downstream and who’s responsible where the bug really is. So, you know, for us, we use mechanisms like distributed tracing, and to put together a logical stack of data flow and how the system works together. So we really end up with this interesting graph network of, of your, you know, your bytes in your request and how things working together. And finally, the resilience against network failure. It goes without saying as you’re spreading things out there to communicate somehow that’s going to be the network and network is unreliable. Always remember that that’s why I call it the CAP theorem that always comes up here. And, you know, in some cases, you’re going to choose consistency. So the data needs to be consistent or available. You have to choose within the light of a network partition how you’re going to make that happen. And that’s absolutely important. Keep in mind that’s going to play into the observability. And you have to make choices as you’re building your system, how you how you react with different types of

 

Perla Gomez  29:32

activity. Now let’s partner with temple development to assist you through this process. Could you tell me a little about the role table played and what was your against decision criteria for specifically selecting tempo as a partner?

 

Sean Sullivan – CTO CBT Nuggets  29:45

Yeah, absolutely. I mean, I mean for us it really writing down the talent. You know, we were great at building CBT nuggets and are we were finding a lot of challenges when it kind of came to Our team finding the personnel that can really help make this happen, the expertise as well. So without the, you know, the appeal of having a team that was in the same time zone, if not one or two time zones off which anybody who’s worked with teams on the other side of the world, that can always be the challenges, you know, they’re awake when you’re not in that sort of thing. And so we found a great partner with tampo and effective provement. And the ability to listen to where we wanted to go with our roadmap, the technologies, we wanted to adopt the expertise we needed. As we started to scale up those teams, we really started to see it become evident that we needed more senior leadership with tempo. That’s really when the architecture position came into light with us in that partnership. As I mentioned before, the architecture, we’re growing an evolutionary approach, right, we’re not we don’t just have some master plan that we’re looking to implement. So we need people in those teams on the ground. So that they can make decisions in the moment, keep us moving faster. We don’t want to create bottlenecks. We want to create more autonomy to these teams and rip samples apart. We really found that possible.

 

Perla Gomez  31:12

Thanks, Sean. I’m interested to hear about this engagement from Tampa’s perspective. So, from what I understand during churches leading the engagement and bringing together cities, internal teams, with temples on scrump teams, what were some of the primary challenges that you helped overcome to bring both of these groups together?

 

Angel Almada – SE Tiempo  31:30

Absolutely. Well, the challenges were all I talk about a prerequisite to engage into into this type of relationship, which is having a cultural affinity between the both companies. Once we are on the same page about this cultural affinity I’m talking about from the way we engage with our employees up until the way we execute on our in our operation with a coding standards and all that once we have that affinity In a sure agile based software development process, everything else is very similar to any other challenge of having a distributed team all within the US. And those are mainly on communication. And the communication comes from the strategy to the execution. Communication comes from being on the same page about the Strategic Initiatives from the from the company, up until the execution of each one of the stories. And one of the easiest ways to solve these challenges is to have a product representative in your band, or in this case in T Mo. And that helps to translate those initiatives into the actionable backlog for the teens and also being on the same page about the practices on product management, such as having a robust acceptance criteria as we start talking about the same language between those two things.

 

Perla Gomez  32:52

Great, thanks. I’m here. Now back to Mike and, john. I want to direct this question to both in hopes of capturing both of your perspective. Tips for our audience today. How is the to see microservices being applied during a transition from a legacy system.

 

Mike Hahn – COO Tiempo  33:09

So a lot of that to me or I see it from from my seat calotype right back in with the business requirements and in what you’re trying to accomplish as a company and what you’re trying to accomplish as a, as a providing value to your customers. You’ve heard a lot of stuff today, what I always say is developing software products, getting them into production, and getting people to buy them is hard work. And and so this transition has to be applied to that legacy system that you’ve been generating revenue from, how do you continue that and what’s going to be the business value that you’re going to be driving from it? Yeah, absolutely. I know, with any transition, what you’re going to find is you have, you know, some parts of your system are just there, they everything’s solid, it’s humming, well oiled and the Things that you want to evolve on, you can really start to leverage microservices to make that possible. Like you said Mike sooner faster, and without volatility to the existing system. And so that’s really what we’ve employed a lot of at our organization. You know, anytime you’re looking at legacy code or legacy systems, I always speak to the stories behind if statements. And as any developer knows that when you’re fixing bugs, there’s all kinds of just little nuances to that, that throughout that system that have been accounted for, is to take all that and throw it out the window, just because its legacy is the wrong approach. Because there’s so much inherent value and that’s meant to ride through time. So we want to continue leverage that but continue to evolve the system quickly, and allow ourselves to be agile. So it’s really about finding the right way to draw those boundaries.

 

Perla Gomez  34:50

So I think I just have one more question for you before we call this a wrap. After your experience going through this transition, I’m curious what’s your recommendation for organizations that are really just getting started. Would you recommend beginning with a microservices approach? If say they were developing a brand new application if it was relatively complex?

 

Sean Sullivan – CTO CBT Nuggets  35:12

Yes, it’s really a it’s really a challenge, because as I just mentioned, the challenge is drawing the boundaries, right. So micro services as it is, I think a service oriented approach to building a product was definitely the way I would go. What I what you would probably find with my recommendation would be the services would end up being a little bit more encompassing than it would be in a place where you absolutely know what your business cases are. So in the case of CBT, CBT nuggets, we have a 20 year old organization with all these processes and entities and systems. So it’s going in and becoming domain expert understand how that works together. Once you put in that investment, you really it presents itself how that needs to be split up. But when you’re building something and say you only have yet kind of your core systems around user identity, then maybe some payment systems, and maybe, you know, whatever the couple features a few features are your organizational originally having that new product? You know, I would, I would say, in that case, you’re going to end up with fewer, larger services. But you’re going to build it in such a way that over time that can start to, you know, think of think of like, cells in a petri dish or something starts up split apart or something, you know, and that’s what’s going to happen, as as things evolve, and as the patterns emerge, now, so you use like the example. So you do build a payment, larger payment service, but then there’s certain parts of it that are not scaling as well as others, or you’re seeing a little bit interesting patterns around volatility or fault faults happening there. You may decide to kind of split that piece off to be its own thing. So that that can be So with that in a different way, and it really all just comes down to just kind of letting the patterns emerge and reacting to them. But all while creating a system such where you can do that, with those defined contracts and protocols, it really makes it easy to to play in the system as a product developer.

 

Perla Gomez  37:20

I would like to thank all of our guests for coming on the show today. I will also like to thank you, our audience. We have enjoyed today’s episode. If you would like to receive updates for future episodes, subscribe on Apple podcasts, Spotify, Google podcasts, or most of the major podcast platforms. Each episode will also be posted on our website, temple dev.com, and each new episode will be announced on social media at Temple software on Twitter and a temple development on LinkedIn and Facebook. You can also email us to podcast at Temple dev.com. If you have any questions, comments, or you have a topic you would like us to cover next. Please tune in next month, where we’ll be discussing cloud infrastructure and agility with our guests. Call him again. Until next time, polygamous and you’ve been listening to Tampa tux