Interview Intro

Richard Rodger: Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.

In this episode we talk to Asim Aslam, who is my favorite kind of CEO, a CEO who codes. In fact, you would be hard-pressed to keep up with his GitHub, which is a sea of green and quite wonderful. Asim is the CEO of M3O.com, which is a startup offering a universal suite of microservices. It offers a full business logic layer for building applications. I am rather fond of this idea, because to my mind, this is the purpose of microservices really, to provide reasonable business logic and make it easy to plug together.

Asim's startup is built on the basis of open-source project, which contains over 100 microservices and which he has maintained over the last couple of years. You can find it at Github.com/micro/services. So jealous - what a wonderful project name to have. Using open source in this way has accelerated the creation of his business.

We also talk about how being a maintainer for an open-source project is a lot like commercial developer relations. You have the same sort of forces and you have to do the same sort of things – it's just that nobody pays you. Without further ado, let's get started and hear from Asim himself.

Main Interview

Asim Aslam

Richard Rodger: Asim, it is lovely to have you here today on the Voxgig podcast. Welcome.

Asim Aslam: Thanks for having me, Richard. I really appreciate it.

Richard Rodger: My first question is going to go straight into what you are doing. You're one of those people who has founded an open-source project and then turned it into a startup. Take us through that story; how did that happen?

Asim Aslam: Back in 2015 I was working at this ride-hailing company in London called Hailo; Hailo was a taxi app competing against Uber. And I had joined them to help them replatform and they were effectively migrating to a Go-based microservices stack. And after a couple of years doing that, I realized the power of that technology and architectural pattern.

And I realized that there wasn't any sort of open-source tooling around that. Netflix had been blogging about it. They had something in Java that they were talking about, but there wasn't anything in Go. And my feeling was, if there's Rails for Ruby and there's Spring for Java, then there has to be something for Go. So, I decided to write something, open source it, and then quit my job and focus on it full time. And that's where it started. And I was-

Richard Rodger: I know you did at the start. Was that just, I'm going to do open source, or did you have an idea that it was going to become a company?

Asim Aslam: Well, I – to be honest, I thought it could be a product of a company. I saw what Pivotal had done with Spring and Spring Cloud, which is based on Netflix. Netflix's cloud architecture. And I just thought wow, I could do this in Go for the cloud. And so, my first instinct was; let me try to build something. Let me try to raise some funding.

I knew a few people; I knew some people back then like Alexis Richardson, who was doing Weaveworks, and he was kind enough to make some introductions for me. But ultimately, nothing formulated on the funding side back then, but that was the goal, the ambition. I did feel like this platform and architecture could be a product in a company.

Richard Rodger: And looking at the open source, there's a mountain of work there. The project itself – so, just so we get this right. What's the exact GitHub URL for your project?

Asim Aslam: Well, I would say the – times have changed and things have moved on. But the GitHub URL – the GitHub org is micro, M-I-C-R-O.

Richard Rodger: You've got the – that's a lovely one to get; well done.

Asim Aslam: Exactly. So, this – but the initial project I actually started with was a project called Go Micro, so it's just Go hyphen prefix to that. And the starting point was, "What's the smallest thing that I could put into the hands of the developer that they could use?" And it was this idea of a framework. But the overarching product, company, everything like that, was micro. And the idea of a platform more so than a framework was what I thought about.

The - this is seven years ago, so you start with one thing and then you evolve it. And then over time, you realize that the usage patterns that you had thought existed actually diverge from your own use case to whatever the audience is doing. And so, this is how I ended up with separate projects, effectively.

Richard Rodger: What I like about what you've done is, you've taken it to the next level, which is – a lot of the microservices frameworks, in whatever language, tend to focus on things like the networking and service discovery and circuit breakers and all this stuff. Which is important, but what you've done takes it to the next level, because you're also solving business logic problems, which a lot of frameworks I find just leave to the developer.

Whereas you mentioned Ruby on Rails. If you look at Ruby on Rails, one of its values is that it also solves the business logic problems. Because there is an ecosystem of things that do user management and ecommerce and stuff like that. Was that deliberate, or did it just evolve that way?

Asim Aslam: No, this was always the goal. The whole value of the thing that I saw at Hailo was that we had 100 microservices running on this platform. The framework and the platform itself enabled the development model, but it was the value that was in the services and what you could do those. Because those were powering mobile apps, web apps. Every new service could leverage 100 other services that were already on the platform to perform interesting new features.

And I felt like, how do you put this into the open source? You can't start with all of that; it's very hard to drive adoption through that. So, you have to start with a framework. Then you move on to a platform; then you move on to services. And it was, I think, around about the time that the project had maybe 5,000 stars, that I was able to raise funding to build a hosted – a cloud hosted offering. And part of the iteration through that was, we started to write these services. And it was only recently, like maybe a few weeks ago, where I actually blogged about it and said, "Here's 70+ services that you can leverage."

Richard Rodger: Let's get a tiny bit technical for a minute. So, in your framework, how do the services communicate?

Asim Aslam: They're doing it via RPC, via GRPC.

Richard Rodger: And let's say that you have a business logic service that handles user management, that type of stuff. How do I go about customizing that? Every implementation, every app that you build, has its own weird needs, requirements, that sort of thing. Your user management service, let's say, has the basics. How do you customize it?

Asim Aslam: Yes, this is the interesting thing. It changes based on what people's requirements are and where they're running it. So, from our standpoint, we built the thing that interops with all the other services that we built and what we needed. And then we're offering on this as an API to end users who can use that as well. And it's their choice how they augment that.

But from my perspective, let's say you're picking up and running this open-source software. You can – because it's open source you can fork it; you can change the code and then run your own copy of the same thing. Now the interesting thing here is that all that logic is hidden within the service, so the end points can stay the same. And to any other service, to any other user, it's still just an authentication service, a user service by the same name. But you can customize it.

Richard Rodger: (Inaudible, 00.09.44) contract, so…

Asim Aslam: Yeah, exactly. I think one of the simplest examples for people here is that there are multiple third-party user authentication management providers. So, you might say, "I have this user service that has a contract, and anyone who offers a user service has to honor that contract. So, whether it's alt.zero, whether it's Google, whether it's Twilio or someone else, you can write a copy of that service that does it. Now whether or not you run all of the same – all of them at the same time, or whether you just switch them out, it doesn't really matter to the end user, right?

Richard Rodger: Yeah, exactly. And talk to me about the experience of being an open-source maintainer. I am one myself; I maintained a microservices platform focused on Node.js for over 10 years, which is – and it's evolved in that time. But I've gone through all those experiences with contributors who are really helpful; people who write documentation, contributors that are – have outlandish expectations; people who are rude. All sorts of crazy stuff. What's – tell me about your experiences?

Asim Aslam: I think mine – it might be similar to yours. It's quite tough, because I was a solo maintainer for a really long time, for maybe four and a half, five years. And people come and go during that time. People come in who get really excited about the project, have a lot of ideas they want to contribute, but don't always have an understanding of the overall scope of the project. So, it can be hard to bring those people in without sometimes dampening their expectations. But people still-

Richard Rodger: (Inaudible, 00.11.50)-

Asim Aslam: Yeah, it can be tough, because you can have this idea about what you want to build, and people want to come in and help. And you are looking for the help, but sometimes the alignment might not be there. But over the time a lot of valuable contributions have made; people have come and gone. But still, you end up being the solo maintainer, and that's quite a burden, quite a task. So, for me, initially, it's very exciting and exhilarating to have your project adopted. It's really exciting to see getting thousands of GitHub stars and stuff like that. But it can be quite tough.

Richard Rodger: Yeah, it's – the thing that I found difficult is that is the – with the – it's – the people who are enthusiastic are in some ways trickier. Because I've a very strong belief in backwards compatibility and making sure that we don't mess around with people who have chosen to adopt us previously. When you have new blood, they want to change everything. They see all the mistakes. And I will go, "Yes, I know it's a mistake, but we're stuck with it."

Asim Aslam: It's true. And that one's quite hard, because you're fighting change and they want to create change. And often velocity of development comes through that change. And I don't know; some things I think – I guess the way I think about system design is about building upon APIs and abstractions. And so, the idea is, you can write this core piece of software, and then rather than building into it, you build on it. So, if you need new features and things like that you extend it.

It's – there's a lot – if you look at some of the biggest used pieces of software in the world like Linux and Windows and (Cobranettis, 00.13.49) and whatever else, they're modular, extensible, but then they also provide a platform to run things. And so, the idea's like, you don't have to build into this thing; you can build on it. You can find ways around it. I think people don't hopefully see that unless they have decade-plus experience.

Richard Rodger: Yeah, you need a certain level of cynicism, I think, to run an open-source project that has a reasonably large user base.

Asim Aslam: I think either you get really lucky in the first couple years; things go well. And you have a lot of help; you have a lot of contributors, a lot of maintainers who are there with you. Or you're stuck for a long time, running it on your own, and that in itself can be tough.

Richard Rodger: In terms of the evolution of your framework, you ended up – it was inspired by your previous work experiences. It ended up being used by people. I found that feedback cycle to be very helpful, because no matter how much industry experience you have you always end up with tunnel vision based on your path dependence, how you ended up doing what you're doing and how you know what you know. And other people's usages are often surprising, but you have to be open to them, I think, don't you?

Asim Aslam: Absolutely right. I think for me, I went into this building a piece of software for myself and people who had similar experience. And what I found was that the people who adopted it were the complete opposite. They were people who had – so the framework was for microservices development, and it required a certain level of distributed systems knowledge.

And the people who came had – they had no distributed systems knowledge and no microservices knowledge. And they were the ones who wanted to use the software, because they thought that it could help them. And so, all of a sudden, you have to open up your mind to, how do I enable this new kind of user who needs help with this, as opposed to the user I was going after?

Richard Rodger: Yeah, and I actually feel those users are more important in a way. One of the things that I feel the microservices community – whatever platform or language – should do better at is less internal discussion about networking and the mechanics of service discovery and what protocols are the right ones. All of that stuff is implementation details. Because we're here to get stuff done, (Break in audio, 00.16.46) with large teams of software developers. It really doesn't matter at the end of the day.

Asim Aslam: It's true.

Richard Rodger: Those (00.16.52).

Asim Aslam: It really doesn't matter. And I think when you're working on the – when your job is mostly to implement those details, then you can get lost in it. But actually, the end user is trying to solve a problem, so you have to try to see if through their eyes, where it's like, look, I'm trying to build something for a business case. I need help. I just need to get past these kind of issues that I can go back to doing what I was doing. It can be hard.

So, I think the thing that we did in the past year of building these building logic services, offering them as APIs and now open sourcing them to everyone else, is to showcase – look, the entire software world needs to move up to stack. We need to stop talking about, networking and all this kind of stuff. It's time to mov eon.

Richard Rodger: Completely. Especially when you have clients who want to get stuff done. How have you found the experience of moving from open-source maintenance and looking after that community to then, I guess, leveraging that to do a start-up and raise money and all that sort of stuff.

Asim Aslam: I think-

Richard Rodger: Talk us through that history and how that happened. It's fairly inspirational.

Asim Aslam: I think – so as I mentioned, when I started out, I looked at Pivotal and Spring, and even the company before it, Springsource, as inspiration. And the goal was always to raise money to build a team, to build a product and a company. And so, I had a pitch stack very early on; kept iterating on that, kept talking to investors.

And it's a different skillset to switch from – one half of the day, all you're doing is sitting in front of a laptop, coding, to the other part is sitting in a meeting with someone who has no engineering experience and trying to tell them why this is valuable. It took a while; it took maybe four years before I could convince anyone to fund it.

And so, in 2019, I was able to raise a little bit of money and say, "People are continually trying to build and solve these platform problems. We should offer one as a service; here's a popular open-source project that I built, that I think could be that service. And then here's all the things that we could do after we do that." Rather than everyone building all of these bespoke platforms and services, we could all build them in one place and reuse that, and think about the compounding value and velocity of our development then.

And so, I got that done, and then all of a sudden, your gears switch again, so you're not going back to coding; you're going to hiring. You're trying to find people who want to work with you to build this product; you're trying to align them on doing that. You're thinking about product roadmap and payroll and everything else that comes with it.

Richard Rodger: Which is – you're either going, "Can I please just go code?"

Asim Aslam: Yeah, it's interesting, because you want to go back to the thing that you find familiar, that you feel that you're really good at. But actually, your job is to evolve and figure out the things that the company needs next. And a lot of that means feeling inadequate and not great at the next thing and the next thing, because you've never done it before. It's tough. If you're up for the challenge, then it can be interesting. And I – it's what I really wanted. I really wanted to build this product; start this company, work with people again. Because I spent so many years working on my own just as a solo developer in open source. But yeah, it comes with a lot of challenges.

Richard Rodger: Yeah, it's not to be underestimated, but you do learn an awful lot. You are selling to developers; that's your market.

Asim Aslam: Yeah, that's right.

Richard Rodger: So, you're part of that chain of evolution. And if we look backwards, you're looking at things like Heroku. And forwards, are we looking at no code? Is that the place you end up, or – how do you position yourself in, I guess, the future of programming?

Asim Aslam: I guess the way I think about it is, I look at the evolution of technology and the fact that we've gone from – I guess thinking about the consumption of infrastructure and software services is, you go buy some hardware. You rack it in a co-lo somewhere, to – Rackspace will give it to you over an SSH connection; to then just being able to one click deploy something; to consumption of APIs. And I think in the current field that we're at is another decade or two of trying to standardize consumption of APIs, and literally all software services becoming programmable in that way.

And the thing is, currently, the idea of API consumption is, you make a HTTP call to something. Maybe you get a set of client libraries and specific languages. But I think more predominantly, as time evolves, it's either going – it's going to be something else programmatic. It's going to be some no-code thing; it's going to be something text based, something UI based. Maybe even voice based, I don't know.

But I think we're going in that direction. And it's one thing to have exciting ideas of what the future is, and it's another to know that sometimes you can be too early to market. So, for us, we're in this space where we're saying, "We're offering these services as APIs. You can consume them in any language." But predominantly, the people who are going to use them are app developers, people building front-end applications, mobile applications, that kind of stuff. And we do see some people in the no-code space adopting them as well, and that might be the next step, but it's still early.

Richard Rodger: And just going back to this idea of developers as customers, how have you found that? What are developers like as customers?

Asim Aslam: It's tough. We're developers ourselves and the – you think that you understand the market and sometimes you don't. But the idea is, more so – the thing is that the developer now has the ability to purchase within companies, wherever they are. The developers are usually the ones even starting companies; therefore, they're buying all the software tools. So, I don't think that's a barrier to entry anymore. It used to be like, the developer couldn't get the credit card to purchase anything. You had to go through this long-drawn process. I don't think that's the problem.

I think the bigger problem, for people moving from an open-source to a SaaS service space or whatever else offering product, is your initial user base is not your customer. You're going to struggle very much to sell to that existing user, because they're already getting value out of your open-source software.

So, the buyer for whatever product you offer as a hosted offering is going to be someone new, someone different. Maybe they had the same problems, but effectively, the starting point is now, as opposed to this other user who's already up and running on their own infrastructure. So, I think that's what it's like at the moment.

Richard Rodger: Yeah, there's a certain irony there, isn't there, because the early adopters of your framework, they're using it because it's open source. But they came in eyes open, knowing that they'd have to sort out infrastructure themselves. So, that user base is not quite ready to migrate over to a fully hosted offering.

Asim Aslam: No. It depends. It actually depends quite a lot on the type of user. A lot of senior back-end developers will want to actually manage their own infrastructure, so those people are hard to sell to. In fact, you have to avoid them as much as possible, because it can be a distraction. Front-end developers are very much used to consuming services.

Richard Rodger: Like Firebase, that type of thing.

Asim Aslam: Exactly. If you can get stuff into their hands, then they're more likely to adopt it. They're not sensitive to that kind of thing. They middle ground is really hard. I think – if we're talking about microservices architectures, it's like a – it's actually a very – it's like an untapped market in a sense.

Because we all – those of us who have done it understand the value of that form of development. But we don't see the platforms that enable that kind of development without a lot of work that you have to do yourself. And we don't see a lot of offerings that focus on that or provide reuse of software in that way. And I think it's not clear to me; it wasn't clear to me in the beginning why. Maybe it's the complexities of the architecture; maybe it's the fact that people do need to own it because of that.

But I think now, seeing that, if you set the consumption model as an API, that there is the potential to create that situation where it is two-sided. If you look at the makeup of a company doing microservices, there's a back-end developer writing services, and there's a front-end or mobile developer consuming those services via an API. So, if you just think about it, two – the two sides of a market, the platform should enable developers to build microservices and the platform should enable a different set of developers to consume them. And that's what we ended up doing with our product.

Richard Rodger: Yeah, of course. And it's a natural divide, of course.

Asim Aslam: Yeah. I mean, it's a very clear divide, divided by the API gateway. And we initially – we started off with a Platform as a Service with our framework and said, "Anyone looking to build microservices, here's the platform to do it." And again, it was a set of developers like us that were very senior, that had back-end experience. And they just wanted to run their own infrastructure.

So, we had to say, "Well, we're not going to capture this side of the market yet. Let's focus on the other side. Let's focus on the end user, who is not sensitive to this infrastructure, who wants to consume something through an API, likely the Firebase user. And we'll be the ones who'll develop all those services first. And once there's enough value here and there's flywheels spinning, then we'll open the platform back up for other people to develop on it." And that's how I would think about it.

Richard Rodger: Yeah. And that's a typical startup story, where you do end up – as you get out in the market, you do end up evolving based on how people react. Do you see – it strikes me that you're – are you familiar with Retool.com?

Asim Aslam: Yeah.

Richard Rodger: They offer – they're part of the no-code space, but it's a bit more serious than things like Bubble.io for example. It's back-end enterprise applications, but it's – they're traditional proto-apps, but there's a whole bunch of extra services. But the development model is definitely, you go to a website and you're dragging and dropping things, and you have to – you're coding by configuration and doing snippets of code and text areas and that sort of stuff. Which is just too awkward really once you reach a certain level of complexity. And it strikes me that you're one level deeper, I think, in that --

Asim Aslam: Yes.

Richard Rodger: -- you offer the same types of functionality but it's still proper coding. So, you still have a get out of jail in the sense that I can open my BIM or my Visual Studio or my Emax and whatever, and get work done.

Asim Aslam: Yes. I think the – what we understand quite well as developers is composition of software and functionality. We just – it's all we do, day in, day out. So, we understand how that works and we spent multiple decades doing it. And so, we understand how it all fits together and so we know how to create things that can be reused. So, giving developers a set of libraries that they can programmatically then build on top of is the key.

And I think the thing about UI and no code is, they don't have that yet. Every company ends up building some custom UI software to drag around these components and widgets and whatever else they are. But what they would benefit is from what we benefit from, which is programmability and being able to reuse stuff.

So, if composition of this kind of no-code stuff let you escape hatch to the code – it could be pure JavaScript or whatever that generates the widget, and then you could somehow chain all those things together and reuse them, that would be super interesting, but I just don't think it exists.

Richard Rodger: Asim, I would be very interested. And it's harder than it looks as well, and there's quite a bit of computer science in solving that problem. Let's wrap up with a final question, which is; what is on the cards for you in 2023?

Asim Aslam: I think for me, I hit this point in the product where I looked at the – I looked at it and I said, "Wow, this is super valuable. It works really well." But I think the adoption curve is not moving fast enough and it means that I do have to go up the stack. I have to find – the way I look at it is, I have to find a simpler and easier way for anyone to consume APIs. Just as we're talking about this no-code stuff, what is the simplest way to consume an API? It's through no code; it's where the person doesn't have to write any code at all.

But I think we haven't yet understood the best ways to do that for APIs dynamically. I find that there's a couple ways that seem to work well. One is being able to dynamically generate forms for any API so that you can just use them. The other is to use some sort of command line model, but on the web; that's another way. But for me, the goal is, how do I simplify the access and use and consumption of these services; that's what it looks like.

Richard Rodger: Yeah, because when you – as a working developer, when you have to use an API service, be it Twilio or whatever, it's a lot of work. You got to read the docs and you got to muck about with curl, and then maybe there's an SDK, but now there's another API that you got to learn on top of the rest API. And maybe they have Swagger; maybe it's GraphQL. IT's not plug and play, right? It's --

Asim Aslam: No.

Richard Rodger: -- something to leverage, and it's different for everybody.

Asim Aslam: Yeah. It's-

Richard Rodger: The purpose is a different – different level of documentation, different models. It's very tedious.

Asim Aslam: Yes, so we just had – I think – there's a university in Massachusetts that had a predictive analytics course, and they had used our product for part of that course, to receive – to pull out some of the dataset for weather and some other stuff. And I emailed – I didn't know that this was happening, but I saw the usage flux and then I saw the people who'd signed up.

So, I emailed them all to ask, and all of them said, "It was in the course and it was just really easy to use. The documentation was really straightforward. And there's this great selection of APIs that I can access through one API token." And that's it for me. The selling point is that – I don't think all of the APIs in the world or all of the data or all the services in the world are really easily programmatically accessible. The browser gives you one way to access any website, any resource. Why can I not programmatically do that for all of these things? Where is the one easy resource to do that? It doesn't exist.

Richard Rodger: I just want one API key, right?

Asim Aslam: Exactly. I want one API key; I want one end point to call. I want one way to access data and services. It doesn't exist and I think that's what's – I think that's what continues to drive me, that it's super frustrating that it doesn't exist, that it's blatantly obvious that it should exist. And I just haven't got the consumption model right yet, so I think when I nail it, you'll see that it works really well.

Richard Rodger: That's it. I'll be – sign me up. I'll be – it would make my life quite a bit easier. Thank you so much. That was super interesting.

Asim Aslam: Yes, no worries. Thanks for having me.

Richard Rodger: Absolutely. We'll keep an eye on M3O as well. And hope to talk to you again sometime in 2023; we'll see how things went. Cool, thank you so much.

Asim Aslam: You too. Thanks very much.

Endnote

Richard Rodger: You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at Voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time.