Allen Helton, Tyler Technologies

All right, another episode of Breaking Changes. I’m pretty excited. I’ve got my friend Allen Helton today from Tyler Technologies. He is someone who’s continually caught my attention in the space, because when you’re really busy doing things in your work, or events, or other things going on, it’s hard to keep up with what’s going on. So when people are building interesting things that float up on my radar regularly, I start to take notice, and Allen is one of those people who is just continually building really cool tools that kind of blow my mind as far as what’s possible when it comes to APIs as well as Postman. So thanks for being with me today, Allen.

Absolutely, happy to be here, Kin. Good to see you.

Yeah, thank you so much. So you work with Tyler Technologies. Tell us a little bit about what Tyler Technologies does and what you do there.

Absolutely. So Tyler Technologies is a company that focuses on empowering people in the public sector. We build software for everything from schools, appraisal and tax, government. We deal with local, state, and federal government. Anything that you can imagine that you have done in or around government, Tyler makes software for you. Ever gotten a ticket? If a cop’s ever pulled you over and written a ticket, it’s probably from Tyler software. We are one of the biggest, we are the biggest public sector software company in the world, and we only focus on the public and empowering the government.

Yeah, I first came across what you all are doing as part of my work in government. So I do work occasionally with state and county and municipal governments, but I also work a lot in DC, and your fingerprints are all over everything. No matter what agency, pretty much every state that I’ve touched, there’s some fingerprints from Tyler Tech on what’s going on, CSV downloads, anything that I’ve played with. So how long has Tyler Tech been doing this?

So Tyler’s been in the space for a very long time. We’ve been more than 50 years. I probably should have done my homework and told you exactly what year it was, but it’s been a very long time. We started as a company called Software Group and started building and acquiring the company, building the company, acquiring other companies, and growing more and more over the years. So we’ve been around for a very, very long time.

So are you guys just building technology platforms, or do you offer services and other things that go along with that?

Well, it really depends on what you mean, because we do offer platforms, we offer software, we offer SaaS offerings on our software. So we do host our software for clients if they want us to take that on. Primarily I personally deal with the courts and justice division, and that’s really a lot of where my domain is. We do both on-prem and SaaS and hosted installs. We offer services like professional services to get you up and running, started, and we offer client success, so after you’re live, let’s keep you successful in the long run.

Yeah, I think that’s kind of where I was getting at. So do they know what APIs are generally when you talk to these customers?

It definitely depends on the group. Yes and no. I’ve dealt with everybody on the client side, ranging from end users to the administrators to the IT staff, and of course depending on the group of people you’re talking with, APIs do or don’t make sense. IT staff pretty much always knows what an API is. I don’t know the exact saying, but they say the government lags behind a few years in tech just in general, and not really wrong. We’ve actually been seeing quite a bit of acceleration toward things like the cloud and modern web practices in the past couple of years, and Tyler being really a forerunner in pushing that and driving that and providing easy accessibility into modern cloud-based software. So we’ve actually been taking the opportunity as we build the software to educate our customers as well. Here’s what a REST API is, here’s a JSON payload as opposed to an XML standardized request response. So to answer your question, yes, they do know what APIs are to a degree, and we’re taking the opportunity to say, okay, well, here’s all the very cool things that you can do, and here’s how we can connect you with these other systems and how you can connect with ours if you want to extend the functionality that we do with something custom.

Yeah, and my experience in working in government is they’re usually about 10 or 15 years behind, but I would say in the last five to eight years I would say that gap is closing.

I think it would be, I would put it at five to ten depending on the agency that I’m talking to, state, federal level. And I think it’s probably due to those types of services that you offer, as people are just getting more aware and understanding what’s going on. Before we dive into what you deliver and what you do, how long have you personally been working at Tyler Tech?

I started at Tyler my last month of college, back in 2012, and I’ll tell you what, that was the hardest month of college for me ever, because I already had the job prior to the degree, so it was very hard to have that motivation through the finish line. So nine years, I’ve been with the company for nine years, been in the tech sector for that amount of time.

Wow, nice. So what’s your degree, and are you classically trained in programming?

I am. I have a software engineering degree from the University of Texas at Dallas.

So how has your view changed being a programmer since you left the university and actually got your hands on things? I mean, do you feel different as a programmer? How are things shifted for you?

Oh yeah, oh, night and day different. I always make a joke that when I started at Tyler I couldn’t have felt less prepared for a professional programming job. I knew all the theory, but when they asked me to implement it, I was freezing up. I was terrified to make my first commit. I’ll tell you what, I didn’t know how the delivery mechanism was, so I thought as soon as I committed a change it was going to affect all of our customers without going through a pull request or anything. I was horrified. And back then I was really focused on doing the task in front of me, really just solving that problem, not necessarily in the fastest way, not necessarily in the correct way, because I didn’t really understand what that meant. And I just kind of grew over the past few years, or over the beginning of my career, to understand a little bit more about what programming was about. Okay, this is what performance is. Okay, this is what it means to do it the right way. This is why we do things the way we do. I learned what maintaining code was once I started having to do it, and paying the price for defects that I introduced. Okay, I guess that makes sense, I need to think about the big picture instead of my tighten error focus. And a couple of years ago, in 2019, I was given an opportunity to become a manager of cloud native teams at Tyler, and that kind of shifted everything for me. The paradigm that I knew it in software was out the window. Went from monolithic annual deployment kind of thing to CI/CD, microservices, REST-based APIs, totally different tech stack. We use serverless a lot, a very different mindset when it comes to that. And then even down to the programming languages throughout, we had been programming in C#, switched over to JavaScript. I don’t think I’m ever going to go back, I love typeless coding. And I would say the past two years I have grown infinitely more than the first seven of my career, and that’s because I’ve had the exposure to things like Postman, exposure to the active AWS community, exposure to open source. It just kind of opened my eyes. It’s been there the whole time, but I kind of took a step back, looked around, what are other people doing, what can I do to help Tyler become a real player, how do we become a front runner in moving into the cloud, building legitimate software that’s modern, that feels good, that’s fast, scales, it’s highly reliable, things like that. Quite a journey.

Do you feel like that’s like API enablement right there? I mean, do you feel like it’s not just the technology of APIs that is enabling Tyler Tech and then your government customers to evolve, but it feels like your focus, your career, and your ability to engage with the community and learn and grow is also accelerated because of APIs?

Absolutely, they’re for everything, everything. And even within this past couple of years in this pivotal part of my career, I at the beginning got all protective and felt really strongly about the tech stack that you used to build APIs. It’s my way, it’s my way or the highway. And I’ve come to realize it really doesn’t matter. If I’m providing consistent APIs with good documentation that perform consistently, that scale well, that people can understand and they’re intuitive, then why do I care what it’s written in? I don’t. You use what’s best for you, that you can write the highest quality code and reliable code, as long as you’re providing me something that’s consistent in providing a wholesome unified experience.

Interesting. So it feels like you embracing the interface and API way of doing things has kind of freed you from that dogma of the programming languages, the infrastructure, that I don’t think we always realize holds us back as much as it does when we’re latched on to a certain way of doing things, a certain language. And often many of us are back-end coder programmers, and it kind of keeps us isolated. So it feels like going API and then focusing on the interface, and specifically external and partner APIs, or at least being part of a cloud community, you’re able to evolve faster and change and think differently.

Absolutely, absolutely. Yeah, this is a really big, Tyler’s really big, we have a bunch of different branches, and we offer things that all play with each other, they interact with each other. And by creating APIs that are consistent across all the branches, we can actually provide that feeling of, yeah, this is one company, it’s not just this is this branch or this is that branch. It might be written in entirely different tech stacks, but if we’ve provided a way to make the APIs look, feel, and act the same, then we can provide a better user experience for all of our customers.

So let’s talk about how do you do that? How do you get teams in alignment when it comes to the design of the API so they look and feel the same no matter where they’re being built? That’s hard.

I’ll be honest with you, that is very hard. I started with a self-reflection. We had just gotten into microservices, just on my team. It started with my team, we just started with microservices, I think we had about eight at the time. And I was building some test suites in Postman, and I was typing out the URLs and they were all inconsistent. The request bodies were different, the expected responses were different. We were consistent with the status codes that were being returned at the very least, but I started looking at it and I was like, this is really disconnected and disjointed, and it didn’t feel like it was from the same application at all. We have a bunch of different microservices that compose up a single application, and it just didn’t feel right. So what I did was I created essentially a governance collection in Postman. I watched your webinar on API governance, and it really sparked an idea in my mind that you can reflect back from Postman and look at the stuff that you have in Postman using the API. And I thought, well, if I can do that, I can write some JavaScript that goes through and analyzes the endpoints, the request bodies, the response bodies. I can start putting governance around it, again mostly stolen from you, the idea. And so I took that and I ran with it a little bit. I took your collection that you had created as a basis and created something and put it in our CI/CD pipeline, where it just started putting in these requirements, these governance things that say every property defined in an OpenAPI spec has to have a description and an example, and the description can’t be shorter than this or longer than this, and the example has to be meaningful. And you have your standards around what paths are like, the how-to-build-a-path standards, around response codes and the normalizing of the types of responses that you can provide. And just made the build start failing if the APIs didn’t adhere to that. And that’s the part that was really hard, because we have this really high velocity on the team turning stuff out, and work goes really quickly when you work in serverless. And it just came to a grinding halt for like a week, because the build failed on everything, and we were trying to scramble and figure out, what do we do, how do we do this? So we started paying specific attention and looking at the OpenAPI specs and just had to adjust. We had to make an adjustment to say this is the way that it needs to be, because once we get to a place where the builds work again, everything’s going to be consistent. We had to go and update the code, we had to update our Postman test suites, because routes changed and the shape of the data that we were passing in changed. Luckily we weren’t in production, so it’s okay to make those breaking changes.

You get bonus points for mentioning breaking changes on the show. You just won the jackpot there.

Yes, okay, good, I’m glad you caught it. I don’t really recommend that way at this point, because that was a lot. Luckily we weren’t in production. If you are in production, definitely don’t do that. But the key phrase is just start and start small. We started with my team, and now I’m on the integration governance board of Tyler, I’m bringing what we did up to there, and we say how do we mature as a company to get to this point, because we went extreme. We went from nothing to fail builds if it’s not that way.

Yeah, I probably should finish that series, because that governance one, I had a whole next part about how you run those manually first, you don’t put them into the pipelines. There’s an education process, and then I got derailed because of Postman Galaxy, so I didn’t actually do the second part, I apologize.

Ah, it hurts to hear that, I lived in fear.

Yeah, no, I mean, that’s powerful. So I’m impressed that your team rolled up their sleeves and did that with you. Were they just pretty gung-ho to try to raise the bar and raise the quality of your code and your design patterns within that time frame to get there?

Yeah, I have a really good team, I have a really strong team, and one of the things I like most about everybody on my team is that they really have a strong desire to learn, and they’re always in a learning mode and take every opportunity, every detriment, every situation where the build breaks to learn and improve. And doing it this way, the team loved it. They obviously don’t like the rework and say, well, it worked before, now it doesn’t work, but they took the opportunity to make themselves better and feel like we as a team have built best practices, we’ve set standards, we’ve paved the way for other teams to follow suit for us.

Yeah, well, that’s powerful. I would love to keep working with you and getting feedback on this approach, because the ability to use a collection in that way in the pipeline, because you can manually run it, and because it has documentation in there, there’s a modularity to it. So I would love to learn how you guys kept applying and changing the rules, because it was purposeful in that I wanted to teach people to fish when I built this. It’s not like, oh, I’m going to create this governance solution and it’s just going to fix all your problems. I want to teach you this approach, and you ran with it in such an amazing way. That’s one of the reasons you caught my attention, what you’re building with it went beyond what I imagined. So I would love to keep trying to learn more from that. But I want to go a little bit into the serverless part, because I know a lot of companies are considering serverless and wanting to understand how it can impact their business and make changes, and then I’ve seen companies like you that have just gone all in and just radical transformations because of it. So can you speak to a little bit about what serverless enabled when it comes to your API development?

A lot. And really what it actually enables, if I had to boil it down to one thing, it enables us to only focus on solving the business problem. Which, any seasoned software engineer will hear that and be like, that doesn’t, no, you have to worry about servers, manually updating the machines, and what happens when things get out of whack. Nope, the cloud provider takes care of that, which is awesome. We write the most performant code that we can. That’s one of the changes in developer mindset when you switch to serverless, is it’s pay for what you use, so you better make it as fast as possible, because if it’s slow for no reason or just because something isn’t written well, then you’re paying more, you’re paying a premium for that. It really helps you focus as a developer on what is the best way to write code, you solve a business problem and you solve it better, and then you continue to solve it better and refine, and not have to worry about things like scaling. We use AWS, and with Lambda functions, they scale automatically, they have I think it’s five nines of availability. It’s never down, and we don’t have to worry about that, and if it does go down, then AWS is dealing with it, and that’s not something that I have to get a phone call at three in the morning when the site’s down, because it just doesn’t do that. I don’t have to deal with ongoing maintenance of servers, I don’t have to deal with networking, it all just kind of plugs in place all together, and really we get to focus on what is the best way to do something for the customer.

And it’s very modular. I mean, you get to do one thing and focus on just that atomic business unit, right?

Yes, and one of the things that I really like about that, I’m a big fan of the single responsibility principle anyway. Your code shouldn’t be spaghetti code where you change something over here and all the way over there something flips a switch. But what I really like about it the most is because we have single responsibility principle, we also get a really tight lock on security, because we deal with government data and there’s zero slip room on that. We cannot let anything out on accident. So what serverless provides us is the ability to say, okay, this one function, this one API endpoint only has the ability to load a single item from this one table at a time, can’t delete it, can’t update it, can’t query it, can do just this one thing. It can’t talk to any other services, so there’s no injection attempts, and it really helps us keep everything locked down, which as a government shop, that’s a big deal.

Yeah, and I’m guessing that really helps with legacy, like whatever’s on the back end. You can create this new kind of atomic, policy-based, do-one-thing-and-do-it-well API that allows you to evolve legacy code forward a lot faster.

Absolutely. And what’s also cool about it is you can use whatever language you want for whatever endpoints you want. Now I’ve already said I use JavaScript a lot, that’s what we use 99% of the time, but I was building an endpoint to interface with a government agency the other day, and pretty much, for reasons I’m not going to say, I had to use C#, and that was okay. I built one Lambda function in C#, was able to communicate and put it in the same API that it was running 10 other JavaScript endpoints, it didn’t have a hiccup, everything worked fine. It was okay, I didn’t have to build another repository or another web service, just said okay, this is the route to this one, please work.

Nice. Yeah, I mean, I agree with you. Node.js is my preference, but doing work in scientific circles and others, I have to dive into Python quite a bit, and it’s a pretty easy switch to do that in a serverless and AWS Lambda environment. So moving forward now on the front of that, I’m assuming you’re using AWS Gateway as a front end for your Lambdas?

Yep, yep.

Nice, we use, and then what, oh, go ahead.

We use pretty much every flavor of API Gateway. We use the REST API Gateway, we use the newer HTTP, and then as of recently we also use the WebSocket API as well. That’s been a fun one, I think we were talking about that on Twitter the other day.

Yes, tracking on you closely with our roadmap. It was like, oh, looks like Allen’s gonna need some sockets, we better get that into the platform. So yeah, you’re driving the roadmap, sir.

Yes, that was actually really cool for me to see our first WebSocket work, and also test the new feature to Postman at the same time, because I really try to use like every feature that you guys push out, and as far as Postman goes it all just works, which is super nice.

So what’s the reason behind WebSockets? What’s driven that? Where do you make the decision between a REST HTTP or WebSockets?

That’s a good question. I’m very much of the mentality that software should be iterated on, and I kind of go on a three-phase model: do it, do it right, and do it better. Do it down and dirty, prototype, let’s prove it, proof of concept, maybe a little bit nicer, because you shouldn’t use proof of concepts in production, but just make it work. And do it right is okay, let’s do it the way we should have done it, now that we understand that it works. Let’s do it to best practices, the standards. And do it better is polish. Let’s make it faster, let’s make it work better. And part of that, for me, my point of view is in the user interface when you have an async operation. It’s a really bad experience to hit a refresh button over and over if it’s done, and the do-it or do-it-right phase has the refresh button. Do it better is let’s refresh it automatically when it’s done, let’s put a little badge up in your notifications bar that says you have a notification or something’s done, let’s refresh a section of the screen automatically. And that’s what WebSockets do for you. It’s pushing from the server down to the client. So what we’re doing is we’re just trying to enhance the user experience a little bit better to say this async op’s done, and you can continue on with your day. Hopefully you weren’t waiting for me, but if you were, go ahead.

Yeah, I would say that level of polish, it’s a better user experience, but it’s interesting that that experience is driving your back-end architectural decisions, and I think it’s a sign of maturity I see in a lot of operations. You start with REST simple, let’s get our resources, let’s get these used, let’s accomplish this business objective, and as that matures and evolves and the experience evolves around that, then you’re looking at event-driven and asynchronous connections and other things like that. So that makes a lot of sense. A lot of folks are just trying to figure out how to navigate between those, and it feels like, for me, it’s a natural maturity, and you guys are just kind of on that journey, making it good and better as you progress.

So as far as quality is concerned, it sounds like you’re testing every individual API and you rolled in governance as part of that. Talk to me a little bit about how you test each API.

Yeah, so I’m really excited to talk about this. The governance thing that I told you we shoved into the build, that I built primarily off of your collection from a webinar that you did like a year ago, I enhanced it a little bit, I didn’t leave it at governance. What I did was I had it automatically generate test requests and really do exhaustive fuzzy tests on every endpoint. Because one of the governance rules that we had was every request that’s a post or whatever has to have every parameter, every field in the body defined and with an example. I was able to write some JavaScript in Postman to say, okay, if these are the examples, let me just take those, generate request bodies from there based on every endpoint that I see in the spec, fuzzy test, what happens if I don’t include this required field, what if I pass it in blank, what if I don’t pass these in. If you have a one-of in there, let me pass every iteration of that, and Postman does it all automatically. So we have a standard API that has maybe 20 endpoints in it, and maybe the request bodies have a few mutations each, the automation that we have around there will run a thousand tests against it. It’ll go and actually hit the implementation of our API on the builds with all of these mutations of these requests, and if it doesn’t do what it was supposed to do it’ll fail. So an example of how it knows what it’s supposed to do, like if we don’t pass in a required field, we reasonably expect we should get a 400. That’s shame on you, client side, that’s a client-side error. And if we don’t get a 400 back, well, that’s a fail, because we didn’t pass in a required parameter. If we ever get back a 500, can’t do that, we should never be returning 500s, there’s a defect in the code somewhere. And then we also, one of the coolest things that this does is it actually uses AJV to validate the response bodies. So if I do a post, I can then subsequently in the automated test do a get on that object that I just created, and if the data isn’t in the same shape or comes back with a different data type, AJV will catch it and say, no, you said it wasn’t going to be that way, but it is, and it’ll fail. It just does these exhaustive tests every time automatically in the build, which has provided unbelievable value.

Yeah, I mean, you’ve merged kind of what usually are fairly separate things: contract tests, security testing, governance. I think people who aren’t this far along in their API journey see those as very separate things, and oftentimes governance isn’t even on the radar, security is kind of an after-the-fact, but you’ve kind of baked all this in. And then I would say, taking it to another level, I’m really impressed with you being able to watch that webinar and understanding the generation of collections, because that dynamic creation of collections, there’s quite a few folks who didn’t watch those webinars and didn’t see that potential, but then you just really latched on to it. So you’re pulling a collection that defines your API and generates, you have a collection that pulls that collection and generates from that, or are you using an OpenAPI as part of that?

It’s just the OpenAPI spec. It’s a collection in Postman that uses the Postman API to load an OpenAPI spec, and then generate all these tests just from the spec, and your examples are in the OpenAPI.

So you have a contract, to elevate this back up to the business level, you have an OpenAPI contract for each of your APIs that describes the entire surface area and has examples, and then you’re pulling that using a collection from the Postman API. This is the inception part that I think some people stumble on. And then you’re dynamically generating your tests from that description.

Yes. And honestly, I did this for selfish reasons at the beginning. I mentioned earlier I’m a manager, so my job day to day is making sure that my team gets their work done, and one of the things that I was noticing day after day in our stand-ups was, the code’s done, I’m just working on the Postman test, and working on the contract tests and the security tests. And it got to a point where we were being really thorough, at least we thought we were, and it was taking longer to write those than it was to actually write the code. And after I saw your webinar, I was like, okay, I think I could actually automate this, I think I could get us back a lot of time. And I tried it out, and I got us back days a week across the team if you sum it all up, it’s significant.

Yeah, I think that really touches on the business focus of this show, I would say, is bubbling things up to like, why do APIs matter at the business level, and that really focuses on the productivity, but also quality and governance all kind of fit into the same packages. You’re able to make your teams more optimized.

Well, and because of the contract, I use this phrase a lot, I quote Donald Rumsfeld’s known knowns, known unknowns, and the unknown unknowns. And when you’re working every day, I know a lot about API design, but it’s not always right there, and I don’t remember to implement this header or this little detail when I’m writing tests. You don’t always think about every possible scenario, your head’s just not there, maybe you’re thinking about going to lunch, you got soccer practice later with your kids, there’s something. And having this OpenAPI contract gives you this kind of known known, and then because of the automation you did, it kind of starts allowing you to probe and understand the known unknowns and even some of the unknown unknowns, as far as taking a parameter and seeing if you remove it, things that you probably wouldn’t think about. And so that for me is taking security to the next level, because I try to articulate how OpenAPI helps with security in this way, and people are like, well, we fuzz and we scan with it, but it’s really that probing of the surface area and understanding what’s there and narrowing it down back to that, it should do one thing and it should do it well, and it shouldn’t do any of these other unknown unknowns or known unknowns. And it really kind of takes things to another level. So you went, that dynamic test collection generation, you went above and beyond what I did, because I was definitely just trying to show, hey, layering governance as part of your existing test, because my webinar was like, oh, here’s how you do contract testing, here’s how you do performance testing, and oh, by the way, you can use the same infrastructure to do governance testing, but I wasn’t dynamically generating anything. So kudos on that, I’m impressed.

Yeah, if you start from the governance point, then you can assume there’s going to be a lot of things there that you can use to key off this generation stuff. If the governance is already in place, you can assume there’s going to be an example everywhere, you can assume that things are actually required that should be required. I’m putting in the required fields that should be required, instead of making everything optional. So it sets you up really nice if you start first with governance. Even as hard as that sounds, you enable yourself a lot down the road.

And so you’re baking this into the pipeline, so this becomes a part of everything that goes out the door, and then you mentioned you’re now part of a company-wide group trying to bring it up to the same level.

Yep, yep. So it started small, prove that it worked, and then joined a board at the company level, at corporate, that says how do we make consistent APIs across the company to make it feel like everything is coming from one company instead of a bunch of different teams. And so I showed them what I’m doing, how we do things, other people showed how they do things, I can get ideas, I got a lot of ideas actually on how to modify what I’m doing. And we’re just taking that in stride, we combined a bunch of different ideas from a bunch of different people on the board and say that is what we want everyone to get to. How do we get there? We start building a maturity model to say step by step, this is how you get from where you are today to where we want you to be in two years, three years.

Yeah, no, that’s powerful, because again, you took the learn-to-fish aspect of this to another level, where you guys learned how to do it and learned how to use it, and then now you’re elevating to the organizational level, showing others how to use it, they’re bringing what they learn and what they know and their practices, and then you’re standardizing that across the company and then codifying it into the pipeline, so that everything goes out the door meets this consistent bar that’s set by everybody. Because it’s not just, oh, the top-level organization that you’re part of is mandating that everyone should do this, it’s a collaborative evolutionary thing.

Exactly, exactly.

Nirvana, if we’re talking about it from an API point of view. But you acknowledge this is going to take years to get there. I mean, even with the fast iteration, it takes time, right?

Absolutely. And there’s a lot of stuff that we spoke about in the board meetings that I haven’t done yet just on my team. There’s a lot of things to do, a lot of progress to make, it’s not easy. I did the extreme case at the beginning, but even if you take it slow, it’s still not easy. Getting buy-off from the bottom up on a top-down governance decision, it’s hard. And what I always say is, just start. You don’t have to do the whole thing right now, just take a step. The Great Wall of China was built one brick at a time, and that’s kind of how you get there with governance like this, just do a little bit.

So how many are you maintaining new versus legacy APIs as part of your team’s work?

I get the luxury of doing greenfield development, so all new, all new. I run two teams, two cloud native teams at Tyler, and they’re both new builds, and we don’t have to maintain any of the legacy stuff. We do integrate with legacy APIs a bit, and we’ve come up with some, I love, creative is the right word, but forward-thinking modern approaches to integrate with the legacy APIs. Because what I don’t want to do is build some code hard into the app that integrates with old stuff that holds us back from bleeding edge. So we do things like webhooks to be able to integrate with legacy.

Right, so you put in a middle tier between the new stuff and the old stuff that knows how to listen and translate to the legacy apps.

Yeah, it’s fun. It’s a different adventure every day with all the different types of APIs that we get to use day in and day out.

Yeah, but you have this toolbox of serverless, you have gateway, you have protocols, REST, WebSockets, you have API design on top of that, like consistent API design, you have ways of testing, securing, and applying that governance as part of it. So that’s a toolkit right there, and then your CI/CD, and those little tests can run in the CI/CD. So that toolkit right there really gives you a lot when it comes to building and iterating upon legacy systems as well as new systems, and just doing things in different ways, because it’s very modular and just allows you to set up these facades that can quickly evolve, even if, like you said, you have to build the webhook middle layer to deal with some of the legacy things.

Yep, absolutely. And one thing that I forgot to mention earlier, which is a really good point to mention, is that building out the OpenAPI specs with governance and enabling the dynamic test generation is awesome by itself, but another huge benefit doing it the way that we do it, we can just immediately turn that around and provide that as end user documentation. It’s fully documented API specs, there’s full descriptions, full summaries, full example requests and response bodies, what are all of the possible status codes that I can get from every endpoint. Postman generates really nice documentation straight from that as well, so I don’t have to do anything for that. The documentation that we’re using to drive the dynamic tests is also the end user documentation. It’s self-documenting code, really, at its best.

Yeah, that’s another thing your teams are not having to do, so it feeds into the productivity but the business value, because it explains what each unit of business value that you’ve defined with serverless, gateway endpoints, and these contract and security and governance tests, and your documentation is as consistent as possible because you’ve got that governance layer. That’s powerful, man, I’m impressed. But it’s not a destination, this is a continued journey, you just got a pretty powerful toolbox to be able to continue in your journey and keep figuring things out. So impressive.

So would this be possible without the cloud? Do you feel like, even with APIs, it feels like serverless is a big piece of this and your gateway approach is a big piece of this.

It is. It’s hard for me to answer, I’m a full cloud guy, so asking me if anything is possible without the cloud, my immediate answer is no, always use the cloud. But thinking about it pragmatically, I do actually think you could do a lot of the stuff that I’ve done in an on-prem or hosted solution, it’s just a little bit more loopholes that you have to jump through. With us being in the cloud, we don’t have to deal with firewall settings, reverse proxies to get back in, because the generated tests are actually hitting the deployed version of our APIs, that’s how we can validate that everything works the way it’s supposed to work. But if we were going back down to on-prem, we would either have to be running that from inside of a VPN, or reverse proxying down into the on-prem servers. Which is one of the things that I really like about serverless, is I don’t have to deal with networking, so don’t ask me networking questions, because I’m not in that game anymore.

Yeah, no, I mean, back to the productivity aspect, it really starts shaving off these things. I know we want to embrace a DevOps reality, and I’m a full stack developer, I can do the networking, but man, if I’m not doing it on a regular basis, it doesn’t stick, and I like doing one thing well, and it really helps me. I think the cloud has helped elevate what I’m capable of. So I agree, you could do it without it, but it really helps elevate you to new heights.

Absolutely.

So what’s the future hold? What’s interesting that you want to be working on, technology-wise or anything? What are you going to play with next?

This is the year of async for me, so I’m going heavy into event-driven architectures, started messing around with EventBridge in AWS, and quickly realized the potential something like that holds, makes everything easier. I think my team and the stuff that we work with is at the point now where we understand REST, we understand synchronous, we understand orchestrated workflows, and now it’s time to do it better and drive it off of events, make things faster, use the WebSockets to come back. This year I’m going to start learning a bit about how to document async APIs. I feel very confident in my ability to do OpenAPI specs, but I’m not at all that way with async APIs, and I know you guys are working with them quite a bit, so I can expect some things from you that would make it easier on me to learn and make things better that way. That’s the big thing. I want to drive the event-driven architecture, it’s going to help drive user experience really from all ends. I can tell something when it’s done, I can make things done faster, and I can fan out, scale higher.

Exciting. Yeah, well, we’re looking for feedback from you too, so this is a feedback loop for the roadmap as far as what’s needed, because the goal is to make the API design and building phase as seamless between OpenAPI and async as possible, so that you can design APIs and do everything that you’re doing with OpenAPI right now with AsyncAPI. And so we’d love your feedback on the testing, on the security, and the governance aspects of that, the collections, how do you store, how do you capture, because WebSockets is potentially going to have a lot more data when it comes to it. So what does a collection look like, what is the history, how does that work in the pipeline. I think there’s a lot of things that we can learn from you as far as how to catch up with the journey you’re on as far as designing and delivering, but also delivering high quality APIs. So it’s good to hear, because async, I feel like when I’m on the async train right now, it feels like for me 2012, ‘13 with Swagger, for OpenAPI formerly known as Swagger, it was a really exciting time when it came to APIs, and mostly for the things that you’re talking about. It was community learning, learning from other people, seeing what other people were building and doing. And so I’m really interested in that at an async level when it comes across the API lifecycle, and seeing what folks like you’re doing with testing and governance and so on.

It sounds like you’re building a lot, you’re moving pretty fast with these APIs. I mean, other than the documentation, I wanted to get your take, because Postman has a visualizer tool in it, how do you visualize all the APIs that you’re building and see them, or do you? I’m not expecting that you do, but how would you like to be able to see your infrastructure across? Is there a way that you imagine visualizing how APIs work, or the scope of APIs?

That is a hard question to answer, Kin. I think you can actually come at it from a lot of different ways. One thing I really like, the way that Twilio and Stripe do their API documentation, and what I like about it is that it’s business process driven. Documenting an API in a microservice, not necessarily business process driven, these are the operations that you can do to this type of entity in this domain service. But you don’t really get value in that until you say, okay, well, if I use Stripe as an example, if I create a charge, I then can go over to the payment service and create a payment on it, or I can do a callback and do whatever there. So it’s starting to chain the different business processes together and represent those in collections and documentation. I think that they can tie it up, because there’s nothing more overwhelming than seeing everything that you can do but not knowing what you should do. So paring it down, even duplicating some stuff, but giving it contextual data around it, like this is what you should use this for, here are some use cases that we have that we use these for, and documenting that way.

Yeah, no, I like that. And it was kind of a loaded question, I knew I wanted to see where you would take it, because there’s different directions you can go when I ask folks that. Some people are like, actually there’s a friend of mine, Arnaud, in Paris, he’s done visualization tools like mapping from OpenAPI, it’ll generate like a graph view of your entire landscape. Some people would take it and just build on the documentation, meaning how do we make the documentation richer, more meaningful, have more details. But then you took it an important step in connecting that with business value and making it so that documentation reflects business value. And that’s important to me, because that means not just developers are looking at documentation. Down the road, maybe it’ll take time, I don’t expect everyone in business groups to read our docs, but if it’s getting easier to read and it’s more meaningful and more purposeful for business, that means you’re going to have more eyeballs on the API landscape, and that’s another way to visualize and see things. And then you touched on events as well, as part of async and documenting, and I think being able to see the meaningful events, not just the resources or, as you said, the microservices. So I would love to keep talking with you about how to see at those levels, I think it’s really important, the business value, the events that matter across Tyler Tech.

So I didn’t have a question there. One of the things I’m working on getting better at is asking specific questions. I’m actually going to read books on becoming an interviewer, so I’m going to have you back on the show at some point and I’m going to be a much better interviewer. But I also like wrapping it up with those long-winded, as we’re coming into the close of the hour here, I want to get out of the tech, I want to understand you a little bit more. What occupies your time when you’re not building these cool APIs and playing with async?

I have two girls, they’re three years old and an almost one-year-old, they take up a lot of fun time, but that’s not work, they get my after-work hours. Before work, I’m a big runner, I really enjoy running, I’ve had a long running career, that’s usually how I start my days. I usually run, work, play with the girls and wife. She’s obviously very important, make sure I say.

Good catch, good catch. You don’t want to leave that one out, that’s a very important one.

Well, it’s been great to catch up with you on this. I owe you some cycles looking at some of your collections and thinking through, because one, I gotta finish that webinar series and get you some of the other details for that organizational level governance that I’ve been working on. Two, I want to learn from your generation, the collection generation, test generation stuff you’re doing, because that definitely took it in a direction that I wasn’t fully prepared for. And then we’ll definitely be reaching out when it comes to some of these other things. But thank you so much for your time today, I really appreciate it, Allen.

Absolutely, it’s been great talking to you, Kin.

Okay, well, and I’m gonna try to get you back, maybe not for a full show, but we’re gonna be doing some other segments and diving into some specific areas, and you’ve covered probably four or five of those areas, so I’m probably going to hit you up for some smaller conversations. So thank you very much.

Yeah, it sounds great, looking forward to it. Thank you very much, appreciate the time.

All right, you too.