Eric Newcomer - Making Cloud Integration Easy, & The History of the Cloud

(Joel Beasley at 00:00:00) Hello, my friends. Today we're talking to Eric, the CTO at WSO2, and we discuss how to get comfortable being uncomfortable, how WSO2's Choreo platform makes cloud integration easy, and the history of the cloud from invention to today. All of this right here, right now on the Modern CTO podcast. Here we go.

(Joel Beasley at 00:00:26) This is the Modern CTO podcast.

(Eric at 00:00:37) Tell you a little story about how I got into computers and IT. When I went to college, they had a science credit. I was actually an American studies major, which is history and literature combined, but we had to take science credits. And our first class was an introduction to science and technology: a lot of film strips and shows and presentations. And one of them said that basically computers were taking over the world.

(Eric at 00:01:01) So I thought, heck, if that's the case, I better learn something about them. So I took a Fortran programming class and I got through that. And then I took COBOL, COBOL 2, computer architecture, every class they had. And because my school was a co-op school, I had an internship as a programmer. Then when I got out of college, they offered me a job back, and that's kind of how I got into it.

(Eric at 00:01:24) And I thought at that time, okay, you know, I'll just do this for a little while till I find something in a writing career that I can move to, like journalism or something. But, you know, I guess it's just as well that that never happened. But I did end up writing a few books, so I guess I can claim to have achieved somewhat of that goal. And yeah.

(Joel Beasley at 00:01:43) There you go.

(Eric at 00:01:44) Yep. Even though they're technical books, you know, it was still something. And yeah, so that was my first job, actually, was kind of also interesting. I was working for a criminal justice information systems out in Chicago, and you notice I said Chicago—I said that right, I hope, with Chicago accent. Anyway, one of the prisons we went to was the prison where Joliet Jake in the Blues Brothers was incarcerated in Joliet. So we did the prison system for that. I went out there, interviewed the guards because they were our users. And I can tell you that's not the door—in the movie, that's not the door that they used to let prisoners out. That was the trauma entry. But it was kind of interesting. We were at that time modernizing these old systems in the prisons, and they were losing prisoners because they didn't have an up-to-date track of where everybody was. They had a batch system they'd run every night, and they'd get these little index cards. Somebody would come to the front desk and look for somebody.

(Joel Beasley at 00:02:46) Wait, so I just want to be clear: prisoners were escaping because their IT systems weren't up to date?

(Eric at 00:02:52) No, they weren't escaping, but they didn't know where they were because—

(Joel Beasley at 00:02:57) Got it, got it.

(Eric at 00:02:58) —they might have been in the lunchroom or they're in the infirmary if they were sick, or the library. They might have a lawyer come to see them. They might be on a work release program, and they wouldn't know. Or one of the worst things would happen: sometimes the guards would change—guards would change roommates. Like if they wanted to see a fight or, you know, maybe somebody wanted to be somebody's boyfriend or something, and they would mix it up and you couldn't find them. So we were having to put in the system where the guards were all accountable for all the changes that they would make, and you had an online system you could query to find out where they were any moment of the day. I know it sounds like a kind of funny thing, but it was an administrative challenge that we were able to overcome by modernizing their system.

(Eric at 00:03:36) So that's kind of a theme—been a theme for me in my career, just helping to modernize things in different areas that I worked in. I went from there to a company called Digital Equipment, which at the time was number two computer company in the industry, just behind IBM, inventors of the minicomputer, basically, at the time. And I ended up in the transaction processing group there. First I was in the database group, and then in transaction processing. And the architecture of their TP monitor product was very much similar to what I worked on in Chicago. We had a front end and a back end, so it's a two-tier system. And we dedicated all the client traffic on the front end for performance and put servers on the back end. And so we were kind of modernizing—transaction processing was dominated by IBM, and we had a better solution. And so eventually ended up getting into an architecture role there, designing the future system. Everything that we had was based on a proprietary operating system, proprietary hardware back in those days. And then we were modernizing it to put it on Windows and UNIX, and so I was now doing that. But then Compaq acquired the company. And for a while we were working on this project together with Microsoft to bring our transaction processing database technology over to Windows NT, because Compaq thought that would be the next big wave with adoption of enterprise NT. And after they acquired Digital, they had like 45% of the NT market. But Microsoft pulled the plug on it in the end because Intel wasn't ready with their 64-bit chip, even though my company was.

(Eric at 00:05:17) But Microsoft didn't want to go to market with just Digital's 64-bit chip because we were kind of a small player compared to Intel. And after that, I had to go on to my next job, which was at IONA Technologies, and I started out as the transactions architect there. But because I knew a bunch of people at Microsoft from having worked at Compaq, I was able to talk to Microsoft about SOAP and web services, which was just starting around that time. And we were able to become the first company outside of Microsoft to publicly support SOAP and WSDL and web services standards and help bring them into W3C and OASIS and so on. And that was where I met the founders of WSO2, Sanjiva and Paul. They were also working on web services in those days. And then after my company was acquired, one of our biggest customers, Credit Suisse, here in New York where I'm living now, offered me a job. So last 10 years or so I was working in financial services as chief architect for different divisions of banks and trying to modernize systems, introducing SOA, big data, microservices, cloud computing, that kind of thing. And then last summer, Sanjiva let me know that there was an opening for a CTO at WSO2. I thought, great. I love Sanjiva. I love WSO2, and they have great technology. And the opportunity was to come in and help with the next generation of products. We're working on going more toward the cloud. Traditionally, we've been an open source on-prem company. We've been very successful with that, but as the industry is changing toward the cloud, we need to change. And that's a big part of what I'm trying to do. Again, trying to help modernize what we're up to. And so far, it's been pretty cool.

(Eric at 00:07:01) And one of the other things I should mention about WSO2 that's really attractive to me is this language they have called Ballerina, which is—you know, when I was at Citi, I was part of the cloud migration team to help get things onto Amazon and Google and Azure, things like that. And it's such a struggle to go from existing systems that were coded for, in some cases, mainframes or for large UNIX systems in Java and move those over to the cloud, because now you've got to refactor everything into microservices, change the way everything communicates, how everything is designed and broken up. And if you had a programming language that would help you with this, I think it would be a big help, big improvement in the industry. So that's something else we're kind of working on there in the background.

(Joel Beasley at 00:07:48) That's really cool. So it sounds like your whole career was just like going from one company that's going through major change and then getting them up to speed with that change, then going to another company that's also going through a major change and continuing to just modernize and change companies with the times.

(Eric at 00:08:06) That's what I really like to do. I really like to get new things adopted. You know, I can see the potential of a technical solution for solving a particular problem. You know, back in my first job, the problem we were solving was online information about prisoners so you could find them, and you could do that with this new technology by modernizing the systems. And ever since then, I've kind of looked for how can I solve problems with new technology that haven't been solved before, or maybe solve them in a better way, and modernize things.

(Joel Beasley at 00:08:39) Absolutely.

(Eric at 00:08:40) That's really cool.

(Joel Beasley at 00:08:40) Yeah, I was—I forget who I was talking to on the podcast a little while ago, but they were talking about how when they're looking to hire engineers, they always look for people that—they prioritize critical thinking skills and willingness to learn way above any kind of expertise in a given tool or anything. And I think you're a prime example. Like, just that brief description of your career—you're like an expert in being nimble and learning. And I feel like that's a—

(Eric at 00:09:17) You've got to learn new things all the time. That's true.

(Joel Beasley at 00:09:20) Yeah. I mean, I'm sure throughout all those different applications of change, you had to be using different tools the whole time. And each time, each different tool requires learning a whole new set of skills around that. I guess I want to ask, how did you fine-tune that skill of learning quickly to use all of the right tools?

(Eric at 00:09:47) You know, it's funny. I belong to a New York CTO club here, and we had a speaker at our meeting last week who is—I can't think of her name. Oakley, I think. Barbara Oakley. And she's made a career out of writing books and doing courses on how to learn new things. She had to do that when she became a professor and changed careers. And she talks about the different parts of the brain, and I'm just getting familiar with her work. I just wanted to mention it because there's a whole field of study on this that I was unaware of. But for me, it kind of goes just back to when I first was learning about computers, you know. The first time I saw a programming language, I didn't know what was going on. You know, you can miss a period in a certain place and it gives you an error and you can't compile the program. And I'm like, if you know that's an error, why don't you just put the thing in there and fix it? Why are you making me put a dot there? You knew it was wrong and you could have fixed it. Then I later realized they just don't know anything. You have to tell them every last thing very carefully, very specifically, because it all gets compiled down into, you know, binary stuff that's executable.

(Eric at 00:10:58) And I just felt, after a while—it's just kind of an informal way of putting it—but just beating my head against the wall for so long, just with a goal in mind of getting this, you know, learning this and making it work. It's the kind of—you just have to put your head down and go through it and do it and take your lumps. And one of the things that stuck with me from Barbara's presentation was you have to feel comfortable being uncomfortable when you learn something new. And that's not always easy, especially if you get into a more senior role and people are looking to you for leadership or you're trying to create a strategy or a plan that you get others to follow. And then you show that you're having to learn something new and you look like maybe you don't know what you're doing. But you have to be able to do that.

(Joel Beasley at 00:11:47) Absolutely. Yeah, like the phrase "get comfortable being uncomfortable," I feel like it's tossed around so much, but it definitely can't be discounted. Like, we all have kind of a propensity to focus on the things we're good at and spend time on the things we're good at because that's easy and that's fun. But you really get a lot more value out of spending time on the things you're not good at and focusing on those.

(Eric at 00:12:15) Yeah. Even if it's not so much fun.

(Joel Beasley at 00:12:17) Yep.

(Eric at 00:12:19) Another thing you can—I try to do—is set aside time, you know, blocks of time to do learning new stuff. Because if you don't dedicate some time to it, like you said, you tend to gravitate to things that are more fun or more interesting. And learning something new requires discipline and requires going through some, you know, discomfort where you're making the adjustment. And I think it helps if you just set aside some time, because it takes a while to get up to speed on what you're doing and to learn something. It just takes time, and you've got to set some time aside.

(Joel Beasley at 00:12:56) Absolutely. What are you learning right now?

(Eric at 00:13:01) Okay. My big challenge right now is learning the Ballerina programming language, and that's what my company's been working on for the last five, six years. And, you know, I've got the theories and the concepts of it, and I can use our new product, Choreo, which is built on Ballerina. And we can talk more about that in a minute, but I need to get really into the bits and bytes of the language and just master it. And that's something I'm just finding a little bit uncomfortable, but I really just have to do it.

(Joel Beasley at 00:13:34) Yeah, absolutely. Can you tell me a little bit about Choreo? What is it?

(Eric at 00:13:38) Yeah. So Choreo is our new integration platform as a service product. So it runs in the cloud. So it's part of our move from open source to the cloud. You know, as the market's moving that direction, we've got to go as well. And it has a great foundation on the Ballerina programming language, and the programming language was designed originally for abstracting integration, because we're an integration company primarily, although we have, you know, identity access management product as well. But most of our focus is on integration, and the language is meant to be a type of syntax that makes it very easy to create integrations and abstract middleware and all those kind of tough complexities you get when you try to put different systems together. But it turns out when you're doing that, it also creates a language that makes it easy to do some other things. So for example, the language has primitives in it that create sequence diagrams. So the Choreo product has an editor where you can edit sequence diagrams, and it'll generate valid Ballerina code. So you have a side-by-side picture of your code and your diagram, and you change the diagram, it changes the code. Change the code, it changes the diagram.

(Joel Beasley at 00:14:40) Oh, cool.

(Eric at 00:14:41) This is like a really cool thing to help with any level of developer to be more productive, because you can really see the integrations and the flows that you're creating when you want to put a couple APIs together to solve a problem. You can see it, you know, right there, like you're trying to maybe trigger something on a GitHub issue to put it into Google Sheets. You could just see what it looks like in the diagram. You can see side by side what it looks like in the code. And if there's something that's still easier to change in the code, you can just do it there and it goes back to the diagram.

(Joel Beasley at 00:15:23) Nice. So the diagram is like kind of a drag-and-drop kind of interface?

(Eric at 00:15:28) Yeah, exactly.

(Joel Beasley at 00:15:30) That's awesome.

(Eric at 00:15:31) Yeah. And the other thing we're doing with it, again based on one of the things that's in Ballerina, is you can get out of Ballerina all the metadata and annotations that you need to generate Dockerfiles and Kubernetes configs. So we've got actually a push-button deployment. So after you create your integration or API or your microservice, you can just push a button in the IDE and it'll generate all the stuff you need to deploy out into Kubernetes. So it's kind of like, you know, you've got DevOps—you know, a lot of people struggle with DevOps and SRE setups for Kubernetes. If you're not a big shop or you don't have a lot of expertise in those areas, you can just get Choreo and push a button, and it'll do all that for you.

(Joel Beasley at 00:16:17) For those that don't know, can you give like a baseline understanding of what Kubernetes does and what it's used for?

(Eric at 00:16:24) Oh, sure. Yeah. So Kubernetes comes out of Google. Actually, Google kind of invented the cloud, just to put a short summary on it, cloud computing. And this part of cloud computing is how they set up the slots for containers.

(Eric at 00:16:44) So I mean, people talk about Kubernetes as like it's a new app server, but it's not really. It's kind of like a pegboard. You know, you got to put this thing on the wall. It's got a bunch of holes in it, and you put your pegs in it. And the pegs, in this case, are containers.

(Eric at 00:16:58) So Kubernetes is this system of clusters and pods that are deployed out on the cloud infrastructure. They're just waiting for the containers to be deployed into them. So the way it works in these big shops like Google and Uber and Airbnb and, I don't know, like Twilio or Spotify, you know, or Etsy. You know, somebody has a big cloud deployment. They have a team called the site reliability engineering team that sets up all the Kubernetes clusters, and the developers are responsible for creating the containers and the config file to hand off to the site reliability team that then takes the containers, the config, and deploys everything out onto Kubernetes to get it to actually run.

(Joel Beasley at 00:17:47) Okay.

(Eric at 00:17:48) Definitely the runtime, but it kind of is set up specifically for containers, and most of the time that's Docker. So you get something in a Docker file, give it to a site reliability engineering team, give them their config, how many copies of this container you want to run, you know, how reliable you want to be, how secure, that kind of stuff. And then it just gets deployed out. It's kind of like the deployment map for taking the container and throwing it out there into these data centers.

(Joel Beasley at 00:18:14) Cool. So Choreo helps integrate between the Ballerina language and lots of other things, and it also helps you with your Kubernetes deployment, making that easier.

(Eric at 00:18:24) Yeah. Yeah. Exactly.

(Joel Beasley at 00:18:26) Okay. Cool. Thanks for that overview there.

(Eric at 00:18:30) Oh, thanks for a good summary. That was really well done.

(Joel Beasley at 00:18:34) Thanks. Well, so you mentioned that Google invented the cloud. Tell me a little bit more about that and the history there.

(Eric at 00:18:42) It's one of my favorite topics, actually. So I go to a conference that was related to my transaction processing days called High Performance Transaction Systems. It's every two years in Asilomar, California. It's basically the guy named Jim Gray who was one of the inventors of a lot of transaction processing technology, started it as a way for people in the field to exchange notes on what they're working on. And one year in 2007, they actually invited a bunch of big web companies, including Google and PayPal and eBay and, I'm not sure Facebook was there, but they've come later.

(Eric at 00:19:22) There's just, you know, I guess Yahoo was there and LinkedIn. There's just a long list of web companies, and they were presenting about their infrastructure. And they were basically telling a room full of people who had invented databases, transaction processing monitors, app servers, all the middleware, all the system software that everybody's using to run their enterprise IT departments. These web companies were telling them, we can't use your stuff. It doesn't work for us.

(Eric at 00:19:49) And we're all going, what are you talking about? And so Google started the story, and they explained how when they were spun out of Stanford, they went and looked at all of the options for what kind of infrastructure to set up to run their search engine on. They looked at the biggest mainframe, the smallest computer. And after they've gone through and evaluated everything, because it's a new business, right, so they just had to figure out what they're going to do, they realized that no matter how much money they spent, the biggest, most reliable mainframe, there was still a chance that that mainframe was going to fail and that they would have to build some recovery systems around that failure to accommodate that failure, no matter how much money they spent.

(Eric at 00:20:31) So they thought, okay, if we're always going to have to deal with failure, why don't we spend the least amount of money possible on infrastructure? We'll just buy commodity disk, the three and a half inch disks, commodity CPUs, commodity network cards, all PC parts, create PC-based servers, and then we'll create a layer of software on top of that to handle failure. So we don't care if these components fail. The system will just keep going because we've engineered around that.

(Eric at 00:20:57) Now, none of the products that you people have been using up to that point in the enterprise work that way because we always assumed that—I remember at Even at Digital Equipment, we were assuming this—we could engineer failure out of computers eventually. We'd get closer and closer and closer, and then we thought someday we're going to be 100% reliable. But you know what? Now that I think about that, I think that's not likely at all because computers are—no, really, if you think about computers, what are they? They're very fragile electronic things that are programmed by people that, you know, put a lot of bugs in their software, not on purpose, but, you know, I mean, getting completely bug-free software is almost impossible. And if you think about that and, you know, the instability of electrical systems, and if you think about, you know, like, the fat-fingered operator problems, you know, people make mistakes with operations.

(Eric at 00:21:53) You're almost never—you can't assume this. So I think Google changed the whole assumption on its ear and said, but things are going to fail. Let's just plan around that. And one of the first things they did was they decided to create their own file system because they had to insulate for the failure of these PC components, which are consumer-grade components, right?

(Eric at 00:22:16) So now all of a sudden, we've got enterprise-level systems being run on consumer-grade hardware and software because they put in things like their file system. Their file system, to get around this failure problem, just to give you an example how they did it, they said, okay, every time we write something to disk, we're going to write four copies to four different machines. So if any machine fails, we still got three copies of the same thing. Oracle does not work this way. NonStop series does not work this way.

(Eric at 00:22:46) They write one copy to disk, and they make sure it's written safely, and that's that. They don't write four copies. They use—

(Joel Beasley at 00:22:53) That seems crazy now.

(Eric at 00:22:53) It's crazy, isn't it? And most of these companies use the operating system file system. Nobody would think of inventing a new file system because that's part of the operating system. Always, people use that. But they needed to create a system that would tolerate any failure of any component at any time and keep going.

(Eric at 00:23:13) And they did that by duplicating things out, and that has informed so many things, changed so many things, that now you have this whole class of cloud-native software, cloud-native products. You have a whole foundation on cloud-native computing. And it's all about this new model that Google started back in 2001 or '02, maybe 2005, twenty-some years ago. And it's just caught on. Everybody uses it, you know, once they saw. But the reason it caught on was because this actually allowed them to have the most cost-efficient IT infrastructure ever invented, so they could undercut all the competitors on the ad prices for their ads. Yahoo noticed this, and Yahoo is going, how the hell can Google charge like a tenth of what we charge for ads? How can they possibly do this? So eventually, word got out and everybody started adopting this. And Amazon recoded their—in those days, web companies often rewrote their software because it wasn't scalable enough—rewrote their applications.

(Eric at 00:24:19) And so Amazon in one of their rewrites went to this model, commodity server infrastructure, as it's called. And at some point, you know, they were doing Amazon Web Services, which were initially a way for people to get information off their website through APIs. And then they're like, what do we do next? And they said, oh, you know, we have all this kind of excess capacity in our commodity server infrastructure. Let's rent that out.

(Eric at 00:24:45) So they created EC2 in 2006 and S3 in 2006 as additional web services. That's why it's called the Amazon Web Services, because you can access compute in EC2 through the web API. You could access storage through the web API. And eventually, that just became the model everybody's following.

(Joel Beasley at 00:25:05) That actually reminds me of another podcast I was listening to recently called HPE Tech Talk. It's just like a tech podcast by Hewlett Packard.

(Eric at 00:25:13) Yeah.

(Joel Beasley at 00:25:14) And so recently, HP actually built a supercomputer that was sent up to the ISS to help run experiments on the International Space Station.

(Eric at 00:25:25) Oh, cool.

(Joel Beasley at 00:25:26) And that presented a really interesting problem because, as you were saying, like, failure's kind of inevitable in computers. And this is like a really advanced expensive machine that they're sending up. They can only send one of them. And so it's like kind of reconciling the common adage of, like, failure is inevitable in computing with the phrase failure is not an option from space.

(Eric at 00:25:55) Yeah. Exactly.

(Joel Beasley at 00:25:55) And so yeah, they were talking about just like all of the fail-safes that they had to build into that computer to try to make it as failure-proof as possible. And I don't know. That's just—it was really interesting. I'd recommend it if you're into podcasts.

(Eric at 00:26:11) Yeah. Yeah. Thanks. That does sound interesting. It's a classic problem.

(Eric at 00:26:15) It's been there forever. But, you know, this whole move toward cloud computing had been creating its own complexity. You know, Amazon got up to 175 services now from the original two.

(Joel Beasley at 00:26:27) Wow.

(Eric at 00:26:27) And yeah. And people are going to the cloud. Now I've got all this complexity, and Cloud Native Computing Foundation has hundreds of projects all built up, you know, over time on this shift toward commodity PC-level, consumer-grade hardware and software for running big enterprises. And you can get a lot of benefits out of this. You get the reliability benefit, agility benefit, scale, almost unlimited scale, because you can just keep replicating your programs.

(Eric at 00:26:58) But you have to engineer for it. You have to, you know, take your Java programs that you wrote one way for the app server and create microservices out of them and figure out a different way to deploy them and containerize them, put APIs around them, and figure out how to orchestrate them and deploy them and connect them all together and figure out how they're going to interact with data. And all of these things are different and complex. And that's why, you know, what we're doing is trying to abstract these problems for people a little better. You know, the cloud computing has gotten, for all its complexity, to a certain level of maturity.

(Eric at 00:27:32) You know, you have the microservice issue, and then you needed to have containers, and then you needed to have container orchestration. But now that you've got that, you can kind of say, okay, we've got the foundational elements of what is needed to get programs created the right way and deployed the right way to take advantage of all cloud-native infrastructure and get all the benefits of reliability and stability, scale, agility, but you still have to kind of recode for it. But now that we've got this certain level with Kubernetes, we can say, alright, we can abstract all this. We can do it with a click of a button.

(Eric at 00:28:07) We can create the containers, create the Kubernetes, and put it out there. And on the other side of it, what we're doing is abstracting the developer experience. So what we're trying to do to help people take advantage of the cloud and get to the cloud and get all those benefits is make it easier to create your programs with this graphical interface and the code without losing any of those capabilities of deployment that you have on a CI/CD pipeline, DevOps, and SRE, and all this kind of stuff. And we think that's really going to help people. Our customers we show it to think this is going to really help us be more productive.

(Eric at 00:28:42) We can get stuff done, you know, much more quickly than before. So that's where we're trying to hit. We might be a little late to the game, but I think we're coming into it at a point where we can take advantage of a lot of what's gone on before and build on it in a good way to help people, you know, get things done much more quickly and easily.

(Joel Beasley at 00:29:02) Absolutely. Yeah. I mean, it sounds like as a company, your core competencies are really lined up well to take advantage of, like, the current landscape.

(Eric at 00:29:12) Yeah. Well, yeah. We spent, um, we've been in business fifteen, sixteen years almost, and most of that time has been in integration, which is a kind of abstraction. I mean, you have to figure out how to put systems together. You have to figure out what's the common point and how they can connect.

(Eric at 00:29:27) And that's very similar to the kind of work you have to do to make things behave correctly in the cloud.

(Joel Beasley at 00:29:34) Yeah. So I've read that at WSO2, you have an opinionated view of the cloud.

(Eric at 00:29:40) That's it.

(Joel Beasley at 00:29:41) Can you tell me what that means and like what's the difference between opinionated or non-opinionated?

(Eric at 00:29:47) Opinionated pretty much just means we're going to chart the path for you. So there might be 175 services on Amazon and, I don't know, three, four hundred on Azure and a few hundred on Google, but you may not need all of those things to get certain jobs done. And the job that we're providing for you with API creation, API integration, microservice development. We think we know which services that you need, and we think we know which CI/CD pipeline you need and which Kubernetes deployment scheme you need. So I shouldn't say what you need, but the opinion is we take a view, our view, of how this works best and make it kind of like the default. So if you just want to cut through all the complexity and have a simple solution, that's the opinion.

(Eric at 00:30:32) That's based on the opinion. That's what that means. Our opinion is the best way to do it.

(Joel Beasley at 00:30:38) Got it. So you kind of take all of the information in of what the client is trying to do, and you're the expert on the best tools to use to get to that end goal.

(Eric at 00:30:49) Right. Exactly. That's gosh. That's another good summary.

(Joel Beasley at 00:30:54) That's my whole shtick.

(Eric at 00:30:56) Come work for us. Help us with the content.

(Joel Beasley at 00:31:01) Yeah. Sure, man. Can you also tell me a little bit about WSO2's identity server?

(Eric at 00:31:08) Oh, yeah. Sure. I'm glad you asked. I should never forget about this. I get carried away with the cool cloud stuff.

(Joel Beasley at 00:31:14) Hey, identity server stuff is cool too.

(Eric at 00:31:17) It is. It is. Actually, my, you know, my last job at Citi, I was chief security architect at Consumer Bank, and we did a lot with identity. So in this case, what we're talking about is customer identity access management or, to talk about one of our big customers, Hilton loyalty program. If you come into Hilton loyalty program, they'll ask you to put in a, you know, a username or an email and a password, create an account.

(Eric at 00:31:41) So that's what our software does is it manages the account for the username and password. And if you need like a step-up authentication, like a two-factor, like an SMS or a QR code, we can add that in. Or if you want to add log in with Google or log in with Facebook, you know, you see that on a lot of websites, or log in with GitHub. That's the kind of stuff we set up for you. So we have all the developer libraries that you need to enable all those capabilities for your applications and for your APIs. And for APIs in particular is a good connection point with Choreo, which is creating APIs. And when you create APIs and deploy them, especially when they're publicly facing the internet, those APIs need to have identities so that you can control the authentication, to make sure somebody has the right login credentials, the login keys when they come in, so that you, you know, can control who has access to your APIs. And then once they're in, their identity can be associated with some authorization.

(Eric at 00:32:44) And especially in the cloud, this is really important because you have all these shared services out there that you need to lock down. So many incidents of data leakage in the cloud come because of overprivileged account access to shared data. And, you know, somebody gets in, sometimes the blast radius, as they say, can be pretty big. Because in the cloud, everybody's sharing the same virtual data center. Basically, once you get in there and you have these overprivileged accounts, you can get data from all kinds of places.

(Eric at 00:33:13) This is kind of what happened with the Capital One breach a couple years ago. Somebody got in with an overprivileged account, figured out how to decrypt all the customer information from Capital One and siphoned it off. So you have to be, especially in the cloud, very careful about that. And this is what identity access management helps you with.

(Joel Beasley at 00:33:31) So is your identity server mainly, like, consumer facing, like, with customer identities? Or is it also, like, what's it called?

(Eric at 00:33:41) The employees part.

(Joel Beasley at 00:33:43) Yeah. For employees at companies as well.

(Eric at 00:33:45) You can use it for that, and some people do. But we try to focus on the customer side and make sure all of the capabilities are there for log in with Facebook, log in with Google, two factor authentication, federation of logins from different applications. So if you've got different systems like SaaS systems and your own application, you want to have single sign-on, we could set all that up. So we tend to focus on that. And one of the reasons is a lot of companies have those systems for employees already.

(Eric at 00:34:17) But when companies are publishing out new websites or new mobile apps, they tend to need some new capabilities for managing their customers and making it easy for customers to sign up. So we kind of focus on that. It's like Auth0 that Okta acquired. It's very similar capability that we have in our identity server product.

(Joel Beasley at 00:34:41) So I feel like from a consumer side on pretty much any competent website, the sign-in or sign-up experience is pretty ubiquitous, like pre-commoditized. So what's the unique part about your identity server? Is it — I'm sure it has to be more on the back end of the management and security. Right?

(Eric at 00:35:04) Well, we really focus on how easy it is for developers to put this, the login stuff, in place. So we have all prebuilt libraries, templates, wizards, GUIs. You know, we're working on a software as a service version of this as well that'll make it even easier. You can use it in the cloud, and it'll have even more prebuilt templates. So you can just drag and drop your authentication bits in as you need them.

(Eric at 00:35:31) So we try to make it that easy for developers and make it very quick and productive, kind of like what we're doing with Choreo. So that's where we try to differentiate ourselves of how easy it is to put all that in place.

(Joel Beasley at 00:35:44) That's cool. Yeah. We've had a lot of financial services companies on the podcast in the past, like WePay and Stripe and stuff. And that sounds like you're hitting a similar vein there because that's where a lot of them have found success is in making it easy for developers and being kind of the first to make it really easy for developers to implement so that they kind of dominate the market that way.

(Eric at 00:36:08) That's the goal. Exactly. Yeah. Yep. Got it.

(Joel Beasley at 00:36:13) So I know you said you're really into writing. Have you done any writing recently?

(Eric at 00:36:19) Oh, not too much. A few blog posts here and there, put bits and pieces on LinkedIn. I've got a few articles underway. I did a couple — did recently a blog post for the company website. For personal writing, I don't do too much at the moment.

(Eric at 00:36:39) Keep thinking I'll get back to that someday.

(Joel Beasley at 00:36:42) When you're trying to solve a hard technical problem or something, do you ever find that writing about it helps you think about it more and come to the solution?

(Eric at 00:36:54) Oh, yeah. Absolutely. I think it's like the old saying, if you're teaching something, that's when you have to really master the topic because you don't really know it well enough to teach it. It's pretty much the same thing with writing. If you can write it down and get it successfully on paper, that's a good way of learning and understanding the subject.

(Eric at 00:37:14) I know that the book — I worked on a book on transaction processing with Phil Bernstein, who's really well known in the field. He's at Microsoft Research now. And I just learned so much just putting everything down on paper about all the transaction processing concepts and the different products. So absolutely, I think writing about it can really help.

(Joel Beasley at 00:37:38) That's really cool. Yeah. That's something that I hear over and over again is, like, people just — journaling is so valuable and writing in general, either whether it's starting a blog that no one's gonna read, it's super valuable for you as a person.

(Eric at 00:37:51) Oh, yeah. It is. And it's about communication. Right? And sometimes in the industry, especially, people don't understand how communication works with people as well as they do with computers. So they'll be thinking, okay. I've written this code, and a computer understands it, and it does what I want it to do. It compiles it into a certain finite state that's reproducible. But with people, the communication happens in the other person's mind.

(Eric at 00:38:22) It's not how you say something, but how it is understood that matters. So being able to figure out how to express a thought in a way in which it's understood by somebody else is very important. If you're just speaking how you would say something and understand it yourself, you're not gonna communicate as effectively as if you could, you know, imagine what it's like for somebody else to hear what you're saying and parse it and understand it. It's not compiled into binary code. Right?

(Eric at 00:38:50) It's understood through whatever the other person's point of view might be or the other person, the way they're listening or how they hear. So you really have to take into account the audience when you're writing or speaking. And I think sometimes technical people get caught up in just solving the technical problem till the point where they understand it in their own mind, and then they don't take that extra step of, how can I express this to someone else in a way that helps them understand it the way I do?

(Joel Beasley at 00:39:20) Yeah. That makes sense. Do you spend a lot of time on leadership at your company and working one-on-one with your direct reports and communicating with them?

(Eric at 00:39:31) Yeah. We have — I meet with every one of them every other week one-on-one and try to spend some time just talking about problems and maybe how we can approach things a little differently. We have a couple of leadership teams on the senior management level, and I try to contribute there as well. I've done a lot of things over a lot of years. I've been around.

(Eric at 00:39:55) And so I try to contribute where I can just, you know, pick up a relevant topic and maybe contribute what I can whenever something comes up.

(Joel Beasley at 00:40:04) How would you describe your personal approach to leadership?

(Eric at 00:40:07) Well, it's two things. One is you gotta lead by example as much as possible. So don't expect somebody else to behave in a certain way or be punctual or disciplined if you're not willing to be punctual and disciplined yourself, because people take the cues for how they behave from how you behave. And the second is really just to try to figure out and help understand what everybody's strengths and weaknesses are that you're working with. And try to, you know, if they need a little help here and there, find a good way to make a suggestion in a positive way.

(Eric at 00:40:45) I really prefer to work as a team of collaborators. Whenever I look at my past work experience and the best experiences I've always had, I've been in a team of peers or equals and collaborators where everybody's figuring out how to do their part and helping everybody else out, getting everybody to succeed. You know, the power of a team like that is much greater than a bunch of individual contributors. You divide the work up, and they go off and work separately. So I try to encourage that as much as possible. And especially, you know, I have a CTO office with some pretty senior technologists that work for me. And I don't wanna feel like I have to tell them to do their jobs.

(Eric at 00:41:27) I think they can do their jobs. They wouldn't be senior people unless they knew how to do their jobs. And then I try to just be a facilitator and see if I can get the teamwork to be improved and see if I can help coach the guys a little bit wherever I can find something I think might be helpful. But I really prefer if I can get a team collaborative environment going on. The way sometimes the way you can get this to work, and I've seen it work like this before, and I try to do it myself, is to try to figure out a vision of where you wanna go or some goal that you might have that's a joint goal in common.

(Eric at 00:42:06) You know, here, we're talking about moving our products to the cloud and getting people to adopt them and use them in production. They're in beta now, so it's gonna take a little while. But we have this vision and the goal of getting these things adopted in the marketplace and being a successful follow-on to existing products. So we wanna kind of describe in some detail what that might look like, what's the target state, or what's the picture of the vision that looks like when you get there, and share that out, syndicate it out, get everybody kind of enrolled in it, and say, okay. We're all working toward the same goal, the same vision.

(Eric at 00:42:41) Let's figure out each of us how we can contribute to this and help make it happen. What's the part I can play? What's the part another guy can play? What is the part we can play together? And try to get things on that basis so everybody's moving toward the same goal at the same time for the same reasons as much as possible.

(Joel Beasley at 00:42:59) Last week, I was talking to a guy named Ryan Westwood. He's the founder and CEO of a company called Simplus. And they do — they're like a digital transformation partner focusing on Salesforce. But anyway, this guy was like a serial entrepreneur and, like, total leadership guru kind of guy. And he's also a venture capitalist.

(Joel Beasley at 00:43:21) Interesting guy. But he was telling me when he's looking at startups to invest in, the number one thing he looks for is vision of the founder. And there you are saying it again, like, how important it is to have everyone on the same page with the vision.

(Eric at 00:43:39) Well, this is one of the reasons why I wanted to join WSO2 because I have known Sanjiva, the founder, for a long time, and he is a real visionary. He's a top technologist. He has a great ability to provision. He created the Ballerina language, and I just, you know, I really admire the vision and the discipline he had to work on that and then get that to the point where it is. And, you know, I feel like I can come in and help and lend a hand and, you know, sign up to that vision myself and keep it going. So, yeah, when I was at Iona, we had kind of the opposite thing happen. We had a CEO, originally one of the founders, was a real visionary, helped create — we were at one time the market leader in CORBA, which of course is an older technology now, but he built the company up, in other words, from just a startup in Ireland to, you know, he beat all the big guys, IBM, HP, Sun. All the guys were competing in that market, and this little Irish startup outdid them all.

(Eric at 00:44:40) And he had, you know, great vision and great execution. Unfortunately, at one point, he had to step down and brought in another guy. And he was brought in by the board, I think, primarily to stabilize the company. The finances were a little out of control. And he did that for a year or two.

(Eric at 00:44:56) He got the operations under control, and the company was doing well and profitable. But then it was time for what's the next product, what's the next vision, and he didn't have that. And eventually, the company went out of business.

(Joel Beasley at 00:45:10) Yeah. That makes sense. That's something I've heard my company's founder, Joel, say over and over again is when he's looking for his personal investing, the number one thing he looks for is that the founder's still at the company for, like, when investing in public companies and stuff.

(Eric at 00:45:26) It's such a tricky thing to have a founder who can build up a company on kind of a personal vision and a personal approach. You know, I think companies are like people. The people that found them, they take a lot of personality characteristics from the founders of the companies, how they operate, what the culture is. And when they leave, it's a big challenge to make that transition.

(Joel Beasley at 00:45:51) I wanna ask you about when you're talking about how you really prefer working in a team environment where everyone's collaborating closely and not really being siloed off on their own, How do you encourage that kind of collaboration in a remote work setting? Because that seems like a really challenging.

(Eric at 00:46:11) Yeah. We talk about that a lot, and I've only been remote since I joined in November. I haven't been back to the office yet. And I think especially for some of the guys — our base is in Sri Lanka. A lot of the guys who are there would really like to go back in.

(Eric at 00:46:30) But in the meantime, we just try to make sure we stay in touch by Zoom as much as possible and chat and emails. I've worked in distributed organizations for a long time, and what I try to do is I try to remember that whenever you're having a hallway conversation or you run into somebody or you talk to somebody about something, you have to remember all the other people in the organization that need to hear the same thing and reach out and call or Zoom or email or something to make sure everybody hears it. But I think it's also important just to have everyone get together as a team once or twice a week and just talk about everything, talk things through. So those two things, you know, get together and then make sure all the communication happens to everybody, everything that's important.

(Joel Beasley at 00:47:14) That makes sense. Alright. So before we wrap up here, is there anything we didn't get out there that you wanna make sure we get out for WSO2?

(Eric at 00:47:24) Well, it's been very interesting making the transition here from financial services back into technology. It's a bit like Back to the Future. I think we have a huge, huge potential to create the next wave of growth here around the cloud products and the simplification, the abstraction of integrations and deployments and ID management. And for me, it's, you know, like, I started talking about stuff on the modernization journey, so we're gonna modernize this company now.

(Joel Beasley at 00:47:56) Absolutely.

(Eric at 00:47:57) I think it's well underway, and it's gonna be fun.

(Joel Beasley at 00:48:00) Very cool, man. And are you hiring, recruiting? Anyone else that wants to get —

(Eric at 00:48:05) We are. Yeah. We got a lot of open positions. We hired, I think, 150 people or so already this year, and we're still there. Yeah. Yep. We're up to about 800 people now. And especially, we've got a lot of focus on trying to build things up in the U.S. more than we are. We need more of a team here and trying to build up in Australia and Latin America as well.

(Joel Beasley at 00:48:35) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.