Microservices are coming, and the reasons are becoming increasingly clear: Companies are eager to decouple their monolithic applications in the name of improved flexibility, increased scalability and quicker deployments.
However, like many new disruptive technologies, there are reasons to be skeptical. Are microservices right for your company? How do you know you’re ready and what does ready look like? Why do so many companies fail? What are best practices and how can you hit a home run with microservices? These questions and more will be answered in this special webinar.
This exclusive event, originally live on Nearshore Americas, features Michael Hahn, Chief Operating Officer of Tiempo Development, a recognized leader in nearshore software development and Sean Sullivan, CTO of CBT Nuggets, a leading online learning company that recently underwent a major microservice migration.
This is a transcript of the original webinar. For the video version, please go here:
Introduction to Tiempo Development and CBT Nuggets
And with that, let's go ahead and begin today's event. It is my pleasure to turn today's call over to our moderator for today, and that is of course, Kirk Laughlin, managing director with nearshore America's Kirk. Without, I'll turn it over to you.
Thank you so much Aaron, and really glad everyone could be on the call today. It's a fantastic topic and we've got some fantastic speakers. So we're going to get right into it. As most of you probably know, Nearshore Americas is a partnering with Tiempo Development for this program and we'll learn a little bit more about Tiempo throughout the program. We are aiming to go about 45 minutes and to reiterate what Aaron spoke about a minute ago, we do have a really neat feature here where we can take your questions at anytime or if you have a comment, don't hesitate to use that feature, uh, that Q and A feature. And you know, my responsibility, will be later on when we have a panel discussion, we'll address your questions, uh, and get into it. So microservices, a very, very interesting topic. There's a lot going on, a lot of, uh, I think what we really gained from today is not just learning about what microservices are, but how it's really worked in the real world. Uh, one of our key speakers today is Sean Sullivan, CTO at CBT nuggets. He'll be joining us along with Michael on the COO of tempo and also Angel Almada, who I believe is in Guadalajara today at Director of Software Delivery at Tiempo as well. And of course I'm your host and Managing Director at Nearshore Americas. All right, good. So I think we're set and a Michael, I'm going to turn it over to you.
Three Phases of a Microservices Journey
Okay, excellent. Thanks. Kirk. The agenda today is we're going to cover really, yeah, three phases of, of the microservices journey and the three people that we have, myself, Sean, and Angel, kind of all represent all three of those phases. So I'm going to focus a little bit at the beginning around the business side. You know, some of the business decisions, the aspects that you have to consider to make a move like this make sense for your business. Sean's going to step in and kind of talk about the technical implications, the decisions around CBT that drove some of the technical decisions that led them down this path to get this microservices transformation complete. And then to tie it all together, we've got somebody from the delivery side Angel, who led the engagement and lead the work from Tiempo's perspective with CBT nuggets to get this done. So when you're really looking at pulling this together, all three of those have to come together. It's gotta make sense for the business, the technology decisions, they've got to make sense, and you've got to be able to execute. And those are kind of the three areas that we're really going to tackle on this today.
So were don't we take a quick stab here, really defining what we look at as microservices and how this ends up working. Ultimately what this is about is a very 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 and 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 in .net core, everything has got to live in .net core. One of the ways that microservices can kind of help you from that definition perspective is you could potentially develop things in different languages, in different environments.
And from this definition around, from the business perspective, like I said, Sean is going to 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 environment, allows a business to generate revenue quicker from your investments in development. So instead of waiting and doing a quarterly release or a 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.
Microservices Work When You Focus on Business Objectives
The other thing you've got to consider around this is that microservices or 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. It 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 are there 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? Are there development processes you can get done faster that'll help you get out in front of the competition? So I'm going to ask Sean to kind of step in here and what I want him to touch on here kind of outside his technical world is to give us a background on CBT's business, what they do and how this move to microservices, benefited the business and some of the decisions that they made around that.
Absolutely. Thank you. It's my pleasure today to be speaking with you and sharing the story that we've been on for a number of years here around us moving to services. So first of all, set the stage with CBT nuggets. You know, we're an online learning platform for IT professionals. That's our bread and butter, helping the individual to continue to level up their career and the continuing education journey. And the business has been around since 1999 it was established as a physical product actually. So sold on EBay by our founder and eventually moved into a full on streaming platform wholly by 2012. So over that course of time, what you end up with is a lot of legacy systems that were built with a physical product in mind. But then moving to a more subscription based streaming product with that, you know, we're not just about serving videos online for, for learners to train on.
CBT Nuggets Makes Their Case For Microservices
We're also about helping them validate and ensure that they can first of all prove that they're learning something and also share, um, you know, some acknowledgement of that, that learning, that validation. We do that through mechanisms such as quizzes while you're training on the videos, practice exams towards certifications as well as getting that hands on experience with virtual labs. If anybody is interested in learning more about this, we have a free week that you can engage with at www.cbtnuggets.com. So with our business, what drove us to, you know, move to microservices. So to set the stage on that, you know, it was a monolithic application built a wholly on .net with a very large PostgreSQL database. There's a lot of value into that. Um, you know, the, the business survived quite healthily for, for many years with this. But what we saw was not just, uh, 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 and require a lot of horsepower when you're looking at a lot of concurrent sessions and threads.
I see exits in the same resources and what have you. On the scalability end, we were also looking much at the team team growth that was before us. So you know, around the time we undertook this adventure, we were around a dozen developers, but we knew that we wanted to double, triple, quadruple the size of our development team to tackle the aggressive road map ahead for our product's benefit. And so with that, when we looked at the monolithic architecture, is the cognitive overhead of working in that system that was before us. And within that, you know, just the, the issue of; you touch code in one place, how's that going to affect something in another place? And Mike, he spoke to the ability to deploy frequently and often. Uh, furthermore the technology selection, so .net is the technology that served us quite well. The PostgreSQL database persistent where that service quick well but there's other things that we knew we wanted to do and other technologies that we wanted to take advantage of. So microservices could really offer a way for us to make that happen. Wholly, just kind of bring it home. It was the road map ahead and scaling the organization in such a way where we can make that happen so we could better the product for our learning experience. I'll turn it back over to you Mike.
Yeah, and as a follow-up question on that. So I know one of the, one of the markets from, from working with you all over the last couple of years that you were looking to get into was kind of more of an enterprise type market and there was a lot of features that kind of came around and around that, around, you know, management of learners and everything like that, the microservices move, was it, did it facilitate some of that feature development for you all as well in terms of kind of driving the business value for the platform?
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 needed to give a lot of love too. And so by, by using this microservices approach, we were able to, um, kind of in, in quarantine, I'll use that word. Work on this reporting 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 from the product. So looking into that. So that's just one example of how we, we found that to be advantageous.
Three Keys to Getting Microservices Right
Yup. That's cool. So as you're looking at this move. Thanks Sean, we'll come back to you in a second, on the technical side. So as you're looking to make this move, so we see this transformation taking place across a lot of different companies and across a lot of different industries. And 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 or you're looking at module that you want to move first or an order, if you will, that you're going to attack this monolith to move it to microservices. Everything's gotta 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 gonna 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 environment, and I'm only going to touch on this very briefly because Sean's going to really hit on this, but you want to look at your capacity and your utilization and really understand the desired end state 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, and continuous integration, continuous deployment. As we talked in the last slide about 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. So that kind of leads me into what can go wrong. And uh, and so sometimes when you go 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 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. Um, 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 I said, Sean is going to 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 implemented in microservices.
And everybody was kind of like, all right, yeah, whatever. You know. So it wasn't really driven from the outside in, it was more driven from the inside out, which kind of gets me to 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 in executive management, buy-in to understand what the, what the cost and the investment is going to be to make this transformation. Because if 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 feels and have a lot of different ways to approach it. But understanding your DevOps, your CI/CD, your architecture and your product management. If you can nail those three things, you're going to have a much more successful outcome. So what's that? We're going to start by tackling the architecture considerations and Sean's going to give us much more depth in much more detail around the CBT nuggets approach and how they were able to execute this.
Absolutely. Thank you Mike. So, 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 you're building, the software you're building. And to me that begins with how often are we able to deploy and actually ship that product's enhancements or additions. And what we found was with this monolithic application, the deploys where sometimes a tight rope act. You were concerned about, okay, I'm going to shift what we think changed, with a seemingly, seemingly innocuous change could have ripple effects. We've all seen that happen before where you know, if the payment systems rock solid 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 that out the door. And so with that, that's why we call it the impact of single code change being widened. 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 the standpoint that we can, we could 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 have certain systems that designed the way they were in this three tier architecture, going to a, coupled, to a single database, the, we were having some opportunities around stability.
And with that we looked at certain aspects of our system. We said, well now if 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 opportunities after it gets split out, that's not going to affect the other parts of the system. And so starting to kind of look at those pain points, where are the places where you know, we're kind of falling short of where we want to be from a stability and experience standpoint and really going after those three architects 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 wanted to build our future systems. So we tackle that. We went after some systems around our digital rights management and in how customers, you know the licensing of their subscription, that sort of thing and started to break those out and put those in a way where we could now 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 is microservices is 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, but you build these ancillary systems that are starting to, we'll say starved the oxygen so they no longer have the 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 protocol is going to be for communicating with these services and really make sure that those are well defined. You don't necessarily need to be too concerned as a team working with 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 that each HTTP, etc. And how's that going to work and make sure those are well documented.
Choosing a Platform For Microservices
(Mike Hahn and Sean Sullivan)
I'm going to jump in, I'm going to steal a question from the Q and A panel real quick. As you're looking at kind of your architecture considerations and some things around the streaming architecture. So you guys ended up picking, there's a question about a cloud provider. So you end up picking Amazon Web Services. Can you talk a little bit about, you know, what drove that decision and kind of why you pick that over some other options that you had?
Absolutely. Yeah. And that's actually a really good question as a leads into the kind of next part of the conversation here. And that is, um, you know, these technology decisions are not wholly technology decisions within these organizations. You have, you have to look at the landscape of what your current team is and for us, you know, hiring potential. As we're looking to build our business and scale out, we need to, to find the places where we know that the expertise is going to exist. We can find people to help and the training materials are available as well. So when we look at Amazon web services, the talent pool for individuals that understood, understand, and at that point I understood that Amazon Web Services, was overwhelmingly there before us. We felt that we could take that technology and really have a strong command over it and, and use it to our advantage. And you know, without revealing myself as too much of an Amazon fan, I really, we, we see a lot of value in the products. They're building the road map and there's just, there's some, some wrinkles that they offer that the other cloud providers had not yet provided to us at that point. So we could get more into that later on.
Choosing a Technology Stack For Microservices
Perfect. 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,
But that the .net stuff could live on, we could still be deriving value of that day to day. They continue to evolve that, but at the same time be leveraging other expertise and knowledge to build these other systems. And when we ask about, you know, why NodeJS, um, so I already hit on the expertise thing and another thing with, Node, that's very valuable is the concurrency model with the event looping. For anybody who doesn't understand or know the technology there, the idea isn't great for CPU intensive operations, but when it comes to stitching together a lot of disparate sources, doing that IO, it really exceeds that making that happen in a very effective, efficient, scalable manner. So we saw a lot of benefits to that. Going back to the data store end of this, you know, at CBT Muggets 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 no, not everything is going to fit in the same database. Some things are great for relational models. Some things are great with you know more the NoSQL, you know, is it something that we can wipe those records and perform those right intensive operations ahead of time, kind of had that materialized to be used, uh, approach. Or we could potentially put everything in the relational model and then we'll 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 designing your architecture, designing your system. You don't have to just lock into one technology and just cling to that the way through.
You can be evolving. Evolution is a very um. You know you hear evolutionary architectures kind of become the prevailing wisdom of the day and that is, you know from the outset we're not going to try and get it 1000% right. We're going to put ourselves in a position to take advantage of the things as they emerge and leverage those. Another important thing to speak to here is obviously when we talk about three tier architecture, the view 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 .net monolith had given us with the view air, we really wanted to take advantage of 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 a website of that we've looked at ReactJS has as the 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 nice to encapsulate components that allow you to, first of all, you're gonna hear me say this again. Reduce the cognitive overload of working on a piece of code but also gives you some code reuse capabilities. So for instance, at cbtnuggets.com, we have a common component library. We were able to really kind of leverage those through different applications or different product aspects. The DOM abstraction is something that is important to point out, you know, anybody who's done web development for a number of years knows that the browser has 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, frameworks are always a really hard thing to select because all of them wants 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. You know, that quote, "give them the finger, they take your arm." I think that's very appropriate. React doesn't do that, and kind of lets you make decisions down the road.
DevOps is Critical to Getting Microservices Right
So moving out to the DevOps piece of this, you know, I think to me this is probably the most, one of the most critical things to get right that you're going to do microservices, right? And that is, we hear this term DevOps, what does it mean? Now for me it's a cultural shift. So DevOps means no longer living in the days of the developer writes code, throws it over the wall and and operations came, ships it and there was a responsible point of the management of production environment. 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, it's their baby from birth out into the wild. And, and they, they understand they way their operating from top to bottom and, that just provides so much value because you know, no longer having this, this idea of um, ownership going to, yeah, excuse me, ownership.
Going to the uh, operations team where they're on pager duty, and it's the people that are actually writing the code who are, you know, responsible for understanding the application. Going back and taking a step back here, the, the shipping aspect of this is very important. Mike, talked about CI/CD, and the point here is as we're building these systems and we're adding value continuously, we want to be shipping that continuously. We don't want a lapse in time where, you know, something has been built and it 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 and the hesitancy. You know, we've all been, we've all seen before where there's two weeks where the code changes backed up in a branch. But to get that out, there was a little bit of trepidation because while there's all these things that have changed, well if you can reduce that cognitive load of shipping a change to just a minimal piece and it's less likely, something's going to not be optimal once they get out there, because you're going to know exactly what changed.
It's gonna be a smaller thing too, to have to digest and the customer gets it sooner. So we all win in order to do this. Really there is this, this undertaking of building, you have to build a pipeline, you have to go to a really solid pipeline where, you know, the cultural change of maybe a master branch that everybody's continuing merging into. There's other philosophies on how to manage your code versioning around this. But yeah, the fact of the matter is, as developers are checking in code and we're executing tests against them to make sure everything is rock solid. You know, going from that moment of checking in, to that moment of shipping is seamless. There's a continual pipeline happening. And then hearing it down and we kind of hit on the, you know, the engineering organization, how, you know, I'm going to harp on this again, but it's not just the ops team to keep it up and running.
Now ops team is not the ones who should get the call at 2:00 AM and our organization are, 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 an artifact to a number 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, then it makes its way out to production for the customer.
We could probably do a whole hour webinar just on CI/CD and how it would all come together. So, hey, out of curiosity, how big is your DevOps team now, and what's the mix that you look at as kind of optimal for the number of developers versus the number of DevOps people you need to kind of help drive that?
Yeah, that's a great question. So our DevOps team, so today we're, we're sitting at roughly 70 developers and a dozen or so DevOps team members. And that to me currently feels like a very, very healthy mix. The reason why is because we have undergone a serious evolution as an engineering organization. CBT Nuggets where it used to be where we would, uh, need to stand up a new service and that would require some manual work of someone having to provision that infrastructure, having to stand up those servers and make that possible for the developer to get that code out there. But as we were going to speak to in a minute here, um, we've really adopted the infrastructure as code approach. Whereas when I say the DevOps team was responsible for building a platform, now they're developing just like a developer would. What they're developing is the layer on top of the metal on top of the cloud. And then that platform, the developers are then taking advantage of to use that and make that possible. So I, yeah, I, I couldn't give you a real strong ratio that what's going to be perfect. But you know, right now we're sitting at probably half dozen this seven to one and, and that's feeling pretty good, developer to DevOps team member.
Understand the Domain Problem Before Decoupling the Monolith
So, you know, coming out of all of 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 to me as requirements that we need to take seriously. And what we have found really truly should be considered requirements. And first and 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 that are gonna have to be made around where the boundaries are, what entity's 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 an inch of the services.
And that could have to do with a number of things. That could be a team organization, it could be geographical, potentially, it could be, um, let's say the way it needs to scale or even looking at the road map 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 it's own isolated service so that the changes that happen in there, only happened within that, and are exposed in that nice clean protocol, um, and contract that I spoke to earlier. Furthermore, and Mike hit 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 in the product needs to emerge over time and really take an agile approach to what it is that we're building. You know, let's not try to plan the whole thing out in advance, just cut it. Make sure that we don't get backed into a corner and we're always able to absorb the, you know, the needs of the business and it makes sure that the capabilities can be put in place to, to build out the product that way we want. Conway's law, It's something that you'll always hear brought up when speaking 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, that protocol and those channels through the contract through which they're communicating. And so you really, microservices is a cultural thing. It's an organizational thing. It has to do with the way the teams are divvied up, the way that the personnel works together.
DevOps Should Be Understood Throughout the Organization
Obviously we spoke about the CI/CD pipeline. 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 brought in on it together. Observability, is something that is absolutely critical. And the reason why is because in a lot of ways we're making our system so much more complex. You know, we're giving up the benefit of having a singular application with perhaps a singular database, and we're moving to a whole-on network of communication and systems that are going to have their own behaviors. They're going to fail in different creative ways that we'd 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 understand your 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, you know, a change in one system in a way that that egresses information and how that affects downstream systems. If you can't pull that picture up quickly and easily, your developers, the 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 and where the bug really is. So, you know, for us, we use mechanisms like distributed tracing 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 you know, your bytes and your requests, and how everything's working together. And finally the resilience against network failure. It goes about saying as you're spreading things out, they have to communicate somehow.
That's going to be the network and network is unreliable, you know, always remember that, that's why I call it the cap theorem that always comes up here. And in some cases you're going to choose consistency. So the data, you know, needs to be consistent or available. Um, you have to choose within the you know, right on the network partition, how, how you're going to make that happen and yeah, so that's absolutely important. Keep in mind that's going to claim to the observability and then you have to make choices as you're building your system, how you, how you react to the different types of failure. You will see.
Microservices Q & A
Kick it back to Kurt to go through a couple of the questions I wanted to bring Angel in. But yeah, this was good stuff. But so Sean this is a couple just briefly as we're going to transition, Angel is going to talk about kind of the challenges of meshing the teams together. Um, what, what drove you to kind of pick the nearshore provider and then I guess Tiempo specifically to kind of help you build out the people, not only from the development teams, but obviously the architecture and the, um, and the DevOps side too because we, we've, we've been working together on that very closely as well.
Choosing the right Software Development Partner for Microservices Migration
Yeah, absolutely. I mean, I mean for us it really came down to talent. Um, you know, we were great at building CBT Nuggets and are, we were finding a lot of challenges when it kinda came to scale out our team, finding the personnel that can really help make this happen, the expertise as well. So with that, the, you know, the appeal of having a team that was in the same time zone, if not one or two times zones off, which is, you know, 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 Tiempo, and the fact that recruitment and the ability to listen to where we wanted to go with our road map, the technologies that 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 Tiempo. And that's really when the architecture position came into light with us in that partnership. As I mentioned before, the architecture, we're going to 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 in these teams, and the Tiempo as a partner. We really found that possible.
So Angel we're going to bring you in here then. So you were the, you were the person that kind of led the meshing of the team. So we had a handful of scrum teams within CBT Nuggets office and then a handful of scrum teams, which basically became the Guadalajara Office of CBT Nuggets. So kind of what were some of the primary challenges that you helped overcome to kind of bring both of those groups together?
Tiempo 's Approach to Integrating with the CBT Team
Sure Mike. Thank you for, for uh, this audience. Absolutely. Uh, well the challenges were, uh, I'll, I'll like talk about a prerequisite to engage into this type of relationship, which is having a cultural affinity between both companies. Uh, once we are on the same page about this cultural affinity. I'm talking about from uh, the way we engage with our employees up until the way we execute in our operations with the coding standards and all that. Once we have that affinity and in a mature Agile based software development process, everything else is very similar to any other challenge of having a distributive team within the US. And those are mainly on communication, and the communication comes from the strategy to the execution. And communication comes from being on the same page about the strategic initiatives, from the company up until the execution of each one of the stories. And uh, one of the easiest ways to solve these challenges is to have a product representative in your partner, in this case Tiempo, and that helps to translate those initiatives into a actionable backlog for the teams, and also being on the same page about the practices on product management, such as having a robust acceptance criteria. We start talking about the same language between those two things.
Yeah, absolutely. Excellent. So we're, we're coming up with a couple of minutes left to go. So Kirk coming up, pass it back over to you here to kind of handle the Q and A section. So we've kind of finished our, our large points for the content. So back to you Kirk.
How to Apply Microservices to a Legacy System
(Mike Hahn and Sean Sullivan)
Sounds good. Excellent presentation guys. Appreciate the information. Uh, as we mentioned earlier, we are going to go into a Q. And. A. We've got a couple of good questions lined up. If you have a quick comment or question, please don't hesitate to ask it. Uh, Mike, I'll direct this to you and if anybody else wants to respond, that's great. Uh, how do you see microservices being applied in the transition of like legacy systems?
So a lot of that to me when I see it from, from my seat Kinda ties right back in with the business requirements and, uh, and 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 know, you've heard it a little, 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? So, Sean, I don't know if you've got anything additional to add on on that, but that's kind of the way I see it.
Yeah, absolutely. Ypu know with any transition, what you're going to find is you have, and you know some parts of your system are just, they're 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, s,ooner, 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 was speak to the stories behind the if statements and as any developer knows when you're fixing bugs, there's all kinds of just little nuances through that, through that, throughout that system that have been accounted for. And so to take all that and throw it out the window just because it's legacy, it's the wrong approach because there's so much of an inherent value in that that's been derived 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.
Should You Choose Microservices for a New Application?
(Mike Hahn and Sean Sullivan)
Okay. Appreciate that. Let's move on to the next question here. If you were developing a new reasonably complex application, would you utilize microservices from the start?
I'll take this again first. Probably nine times out of 10, I would probably say yes. Um, just because it's it, it's going to be much easier to design independent little pieces because you know, let's be honest in the evolution of like Sean was talking about evolutionary architecture, but not only that, the evolution of the market requirements and the business requirements are going to keep moving. So the more you can decouple those needs from the beginning, you know, so like for example, you might decide to, to third party OEM a payment processing system initially, but in the long run, that's a piece of technology that you want to own. So if you put, if you put it in a little microservices approach with that down the road, when you go write your own, you can just kind of replace the service for, for the simplistic way of looking at it. So again, Sean, I'll ask you just kind of see if you've got anything else beyond that. But that's, I would say more, more often than not. Yeah, you're gonna you're going to start this way.
Yeah. It's, it's really, uh, it's really a challenge because as I just mentioned, the challenge is drawing the boundaries, right? So microservices as it is, I think a service oriented approach to building a product is definitely the way I would go. What I, what you would probably find with what my recommendation would be, the services would end up being a little bit, uh, more encompassing than they would be in a place where you absolutely know what your business cases are. So in the case of 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 and understanding how all 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, you know, you have kind of your core systems around user identities and maybe some payment systems and maybe uh, you know, whatever the couple of features, a few features are your organizational will 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 they can start to um, you know, think of, think of like, uh, 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.
So you, to use Mike's example, so you do build a payment, the larger payment service, but then there are certain parts of it that are not scaling as well as others. Or you're seeing a little bit interesting patterns around volatility or faults happening there. You may decide to kind of split that piece off to be its own thing so that, that can absorb that in a different way. And it really all just comes down to is it's kind of letting the patterns emerge and reacting to them, but all the while creating a system such where you can do that with those defined contracts and protocols that really makes it easy to, to play in the system as a product developer.
Why Choose a Nearshore Partner?
Sean, I appreciate that. Um, while I have you, uh, let's, let's get one more question and I think we'll close it out. Um, but for those who didn't, um, get questions answered, we will address those separately following this call. But back to Sean, one of the questions coming up is, uh, you know, I think you've kind of covered your decision to scale your development team with an outsource partner, being Tiempo, but what was it that led you to choose a nearshore company over other, you know, potentially different geos like Asia or Eastern Europe?
Yeah, I mean to, to put it simply, I think one of the biggest things was, uh, was the proximity from a timezone standpoint. And I touched on that, you know, somebody on the other side of the world, the challenge can be that they're, they're awake when you're asleep and that sort of thing, vice versa. And you know, as we all know, working the systems together, communication, you know, that's the thing you have to nail on a development team is communication, everyone has to communicate effectively. And while that asynchronous communication can be effective, um, the ability to just pick up the phone or Skype or Google Hangout or whatever and just get that person face to face at that moment and have that conversation, it's so much more valuable. Um, you know, specifically for us. And once we started to engage the cultural, similarities were so evident to us that it seemed like a no brainer. So those are probably the two big things.