API Environmentalism with Alexander Karan of Climate Clever

[00:00:00] Mike: Hello friends, we're here for another episode of API. So you won't hate, my name is Mike, your cohost. I'm here with the ghost of Phil who was supposed to join me for this call. But he is in the middle of the woods somewhere using an Atari for a modem. And we were unable to get a good enough connection to actually be able to chat.

So you'll have to accept my word that he's still alive and kicking and doing well and . Planting things all around the UK there and it seems to be in good Nick. And in the meantime, we will have a chat with my new friend Alex, Karen from climate clever. Alex is working on a product that is super near and dear to my heart and certainly our hearts and kind of the mission with APIs.

We won't hate here. It is a online platform for carbon neutrality. It's an API first platform that has quite an interesting story in that. For being built. And as many of the folks who listen to the podcast are probably familiar with carbon neutrality and climate aware projects is something that we really love talking about here.

So I'm really keen to hear from and learn about climate clever from Alex,

[00:01:00] [00:02:00]

[00:02:27] Mike: alex, how are you doing?

[00:02:28] alexander_karan: I'm good. I'm good. Thank you for having me, Mike.

[00:02:31] Mike: Of course. Yeah. You're very welcome. So why don't you tell me a little bit about yourself kind of before climate clever the story of, of leading up to how you got there. And then, then maybe we can talk a little bit about climate clever itself.

[00:02:43] alexander_karan: Okay. Cool. So yeah my name's Alexander I've been a software engineer for a very long time. Now time has lost all meaning. I'm mostly a JavaScript engineer, so I pretty much play with JavaScript all the time. I love it and hate it. It's a love, hate relationship. Yeah, full climate.

Clever. I [00:03:00] worked for a dev agency for quite a few years, heading up the development and design teams there. Which was actually how I met the founder of climate clever because we built. first iteration of the product at the dev agency I worked for. Yeah. And then I guess before then, you know, a few years of freelancing doing no development and iOS development, actually, I used to do that.

Don't really touch iOS anymore. Got quite frustrated. Yeah, And then rewind even further. I guess I used to do development inside a few like big old school companies back home in the UK, which is where I'm originally from. And then pre that I wanted the musician, you know, so. That's like sort of the brief condensed history.

So, you know, accidentally fell into programming slowly took over my life. You know, and then here I am as a co-founder of a startup.

[00:03:51] Mike: Yeah, I think that's probably a familiar story for many of us. Funny enough, you, you obviously, the listeners can't see this at all. You can't see it because of the angle of my [00:04:00] camera here, but if I. Toss my door aside. I'm I may a reformed musician, a and M current programmer myself. And I've spent a lot of time in the JavaScript ecosystem, building things and products and companies and doing consulting and all that.

So it sounds familiar. It's one of those things where I feel like you stick your head up and you say, "oh yeah, I know JavaScript," and then suddenly you fast-forwarded 10 - 15 years. And you've been doing it for a living and solving other people's problems for quite a long time. Very cool that you were able to get new position to actually work on something that is meaningful to you.

And, and in particular, probably coming from more of a consultative sort of studio role. It's really nice to be able to own the thing you're working on and have some you know, personal value tied up in the thing that you're building too. So, yeah, that's really cool.

[00:04:44] alexander_karan: 100.

[00:04:44] Mike: So what, what yeah, so tell me about climate clever itself.

What's what's the elevator pitch.

[00:04:51] alexander_karan: Ooh, the elevator pitch. I'm the wrong person to do the elevator page. I guess

[00:04:54] Mike: elevator pitch.

[00:04:56] alexander_karan: they weren't allowed to speak to the edge of D is [00:05:00] the elevator pitch.

Okay. So we are a API first platform, but we have a pretty cool. Front end. We help businesses in particular measure and report on their comp and remissions and take action to reduce their footprint.

We also do help schools and homes because that's where we originally started. But our main focus is sort of SMEs and the business sector.

[00:05:23] Mike: Yeah. And so how has that taken shape over time? What was your initial sort of first version of climate? Clever? What did.

[00:05:31] alexander_karan: Okay. So

rewind to 2012 where I did even know about climate clever and didn't really care about climate change all that much. So the founder of climate clever and also my partner Vanessa Allan's helps certify the first carbon neutral school in Australia. She came in with a group of other people as well.

And, you know, they help to measure the emissions of the schools. They helped reduce their footprint, so saved them save them some money as well. And then also offset [00:06:00] what was left for. And that got certified as the very first carbon neutral school in Australia. And my partner and the CEO is a, an amazing academic.

So obviously that's where it all came from. And then she spent the next few years teaching and lecturing and researching doing all those things that I don't quite understand the academic Stu. And eventually she decided. Bone a pilot where she had like a bunch of schools. I think it was like 10 schools in total.

And they ran through the same program. If it was this around 2016, 2017, and you know, all on Excel sheets and Google docs. Right? Like it was so, you know, which I just think you can't knock Excel sheets. They're bloody fantastic. You can build full fledged apps in there. That's great. So, and they sort of took all these schools on the reduction program. And then she got some grad money together and that's when she approached the devil and see, I worked at, and so we built the first iteration of the climate clever platform, which was just targeted at the schools and [00:07:00] we would help them measure their electricity, gas, water in LPG. And. Usage and then we'd help them audit their buildings.

Like there's some really good stories from that period. Like I think there was this, one of the schools was like, you know, why is our gas bill so much higher than all the other schools when they were comparing themselves? And it turned out because they had seven gas leaks, you know? So like they just didn't know.

So it wasn't until he could see all the data and they could compare. And that's sort of what led rise to this little mantra that we have inside the company, which is you can't manage what you don't measure. So yeah, so we sort of, you know, so we grew you know, the platform to more schools. And then I think after about a year I left the dive agency and I had this nice, cushy, easy job lined up.

And somehow Vanessa convinced me to come work for And then obviously fast forward to now we're in a relationship, we've run the company together. We have a baby together, so it's turned out pretty, pretty fun. And yeah, so, I mean, obviously COVID came out of nowhere in 2020, so that sort of put a little, you know, hold all plans because all the [00:08:00] schools started shutting down.

So we pivoted into homes to help homes cause we could do the same. And yeah, and so we've managed to save a lot of emissions and money for homes and schools across Australia, which has been amazing. But as we sort of came through COVID we realized, you know, being a startup need that more sustainable business model and schools and homes aren't necessarily the best way to do.

So we sort of moved more into the business sector because as you know, laws change, especially around the EU and their laws that they're looking at that does affect supply chains globally. We've started looking at businesses and helping businesses, not just measure and reduce, but actually report in a really transparent way.

And so that's really, what's important because we want to help people. But we called the emissions accurately and also be able to report them in a really transparent way. So there's none of this greenwashing nonsense and they can say, Hey, look, this is my footprint. This is what we're doing. And this is how it was calculated.

And so all of that. Is, although it's like [00:09:00] this wonderful kind of pretty UI that's, to be honest, I don't build most of that anymore. There's other engineers in my team that are far better at front end development than I am. But it's all built on an API, so it's an API first platform and there's quite a lot of reasons for that.

But yeah, so that's kind of a little bit of the journey, what we do and stuff.

[00:09:17] Mike: Yeah, I can imagine all of the listeners of the podcast peeking up like Prairie dogs. Once you start mentioning API is towards the end there. I'm, I'm a bit interested in the product side of this too. It sounds. The value of something like this, it speaks for itself. What I'm kind of interested in is where the actual connection between the technology and measuring happens, like, are you using off the shelf hardware to measure emissions?

Is it something where you have nice access to energy and, and gas intake for individual buildings through services in Australia? Or are you doing custom installations on, on buildings? How does.

[00:09:55] alexander_karan: Sorry, I just got out the left. Would you like easy access to bills that would make [00:10:00] my life a dream? That's that's not how utility companies play bowl in Australia. I don't know about the rest of the world, but they're like, no, It's our

data.

[00:10:09] Mike: Yeah.

[00:10:11] alexander_karan: So there's, there's quite a few different ways that we approach this because as we move into. There's more than just simple emission streams, like electricity, gas, and water. You've got like, you know, for software companies, server usage, you've got equipment, you've got liters of diesel. You know, all this stuff has to be recorded. So always, always the first method of data entry is manually. And we create really easy to use endpoints and UI forms to achieve this.

So that is always the first thing, no matter what emission we're talking about, we always create a manual entry to deal with it. And the reason we do that is because, you know, some people don't have access to digital. Recordings. They just track things. There's so many different things, especially when you're [00:11:00] dealing with a country like Australia as well, where internet isn't always the best, you know, regional Australia is very different to Metro Australia.

So you've got to always have these simple methods of doing things. The second way we do is CSV uploads. And that's because of. Tons of businesses, you know, just record stuff and CSV, you know, in Excel sheets. So we have some CSV mapping that we do inside the API end points. So we have API end points that take CSVs and they do that.

W our next options, we have quite a few options. Our next option is for utility companies that have easy to use websites, we've built scraping services that go in log in on your behalf and grab all your data. They are incredibly fun to maintain because like every week there's like another bug like, oh, they've slightly changed.

The only reassuring thing is noticing when utility company websites go down more than your own product, that is quite oh, that's just the utility companies just down again. That's all it is second time this week. [00:12:00] So that's quite interesting. And then the final method, that's still in development at the moment that we've been working on for a while with the help of Microsoft, actually, Microsoft has been really helpful here. in Perth.

Well, ahead of off. We've been working on a PDF data extraction. So we've got a few different methods, one we'll log into your utility company and grapple the PDFs. A two, we'll give you a special email where you can drop the PDFs into the email or three. You can just upload it. And we abstract the data out of there.

So Microsoft got this wonderful. Sort of PDF form recognized station AI that really just, you know, is the icing on the cake. Yeah. So those are kind of the different methods we use for collecting data. Now we can use life meters, like people like, oh Yeah.

live meters. They're really good, but, well, that's only a few utilities, but also like we don't need to know your usage on an hourly basis to work out your footprint.

So it's, you know, why collect all that data is, [00:13:00] is sometimes the answer to that.

[00:13:03] Mike: Sure. Yeah. It's funny as you're describing this, the thing I, I I've had a couple of thoughts, but one thing that I'm thinking is that forcing manual entry for people on some level is also a really nice way to get people, to recognize that they're using something that by, by forcing you to sit and write down something, you're enforcing a good habit that, Hey, I've actually burned a liter of diesel fuel, or what I've done here is I've turned on the air conditioning for 12 hours and I'm writing that down every day.

It makes it. A lot more internalized at that point. I'm sure that's creating some good behaviors.

[00:13:30] alexander_karan: Yes, it does. I mean, like I have to be honest, like when I first joined climate clever full time, I was blown away by how complex Bill's work, because I'd never even looked at my own bills. And it's amazing how many people have never looked at their own bills as well. And when they actually start looking at them, like, especially when we're working in schools, the amount of schools that just paid them and ever even looked.

You know, it was quite alarming. Cause then that's when you find these inconsistencies, then when you find things that are wrong is by actually looking at them. So Yeah.

[00:14:00] it does, it doesn't force good habits. I mean, it's the same thing with the actions that we suggest to people. I think like 60% of the things that we suggested.

Right. So they're not actually, they're just behavioral change. And I always used to think to myself, I was like, there's no way, but just that, that people don't know about this stuff, you know, like it's no way that they're not turning off the lights, you know, like this is crazy, but the thing is, they're not, you know, like schools in Australia, you know, they, they have a six week. Over summer, which is like the end of December and the whole of January for us. And like schools just don't switch everything off, you know? And so we started developing these switch off campaigns where the schools would go and switch everything off. Like all the students were going involve and they'd save like five grand over that six week break, you know?

And it's just like, And it's so crazy how like, just behavior change is just enough to get you going, you know, like, not even like, oh, switch to renewable energy [00:15:00] solar. So, Oh, get solar panels, like just, just simple stuff that people, and I always thought that people must know about this and they don't, you know, they just don't even think about it.

[00:15:11] Mike: Sure. Yeah. It's not like you're going into office buildings and convincing everyone to become vegan. One by one, you can get a lot done by using a little bit less water and fuel and electricity here and there. The other thing that came to mind for me too, is something in my current job. I talked to a lot of founders of startup.

And it's really interesting to hear commonalities between the success stories of growing startups and how they got to where they are. And one thing that seems to be pretty common with a lot of startups that are successful is that they've done a lot of the work manually for a very long time before they started automating it.

Because that lets you get familiar with the pain that you're trying to solve. And so as you mentioned before, having this whole thing within Excel spreadsheets for a long time, probably. Your self and Vanessa are really good perspective on what the actual thing is that needs to be automated here, where you look for easy optimizations and things like that, and good ways to make recommendations.

And it's, it's been my experience, at least from talking to [00:16:00] folks that that tends to be something that helps people design a product. That's actually solving a real problem as opposed to a perceived problem.

[00:16:08] alexander_karan: Yeah.

100%. I'm always like, give me the low code. Look, it pains me to say, cause I'm a developer, right. And I don't want people to come from. But I'm like, you know, always go for the load code option, never built something straight away, you know, it's, it's, it's always like, you know, Excel sheets. You can do a lot with Excel sheets and Google docs.

You can do a lot just whacking up a static website with a survey and it, you know, it's always good to get people using stuff about building a whole heap of stuff first, because you do discover pain points. You know, that there's, there's totally and also you see if it's worthwhile. And then when you hit the limits of the Excel sheets, then you can start converting it.

But, but even then I think. It's always keep it simple. You know, I think I've, there's so many times where I think, you know, that sort of program or part of my brain has gone, oh, let's be clever and do this and we can add this. [00:17:00] And I'm just like, and then I get the inspire and I'm like, man, we just keep it.

Every, every iteration should be simple, just a slightly simpler, you know, small improvements rather than like big, crazy things, you know?

[00:17:14] Mike: Yeah yourself and your team in the future. We'll both be happy with you if you've done it that way, too.

[00:17:21] alexander_karan: 100%. I always, I always notice, like when you're coding on something, you know, you past self has done a really good job. Like, you know, past Alex, he did a great job today or like other days you're like, seriously, what was passed out. Cause they gain. If I ever get ahold of him, you know, like.

[00:17:39] Mike: Yeah, there are days where I wish I could buy my past self a beer. There are also days where I wish I could knock my past self over the head and write a little more documentation, something like that. I've I've been in the middle

of resurrecting, a very old project that's years and years old. And I'm amazed by that dichotomy.

Like some of the things that I did are so clever and well-documented and thoughtful and helpful for me now. And some of the things are just like [00:18:00] assumptions, assertions, whatever you wanna call. I just assumed I would remember this little trick forever or the way that things were set up and interconnected forever.

And let me tell you from eight years since I definitely don't remember how things worked way back when the, the, the simple path would have been helpful in a lot of those cases, too. So can you tell me about climate clever now and maybe what's next? What are, what what's happening in your world now and what are kind of the goals that you might have going through?

[00:18:24] alexander_karan: Okay. So, well, obviously our biggest focus is becoming businesses. So sort of our focus for the next year or two is to one grow the emission streams that we measure. So every time we measured just in case I haven't explained it already, an emission stream is like electricity or gas or diesel, or, you know, taxi rides to the airport, anything that produces emissions.

So sort of, sort of, you know, goals add more ambitions. Make reporting easier. So like one of the cool things that we do is we generate these really cool, like, you know, custom reports that reflect all your data in a really [00:19:00] easy to read and consumable way to expand those reports and just get more businesses on the platform and also, you know, help look at supply chain emissions, I think more than anything else.

So not just like, Hey, I'm at business. Here's my emissions, but Hey, I'm a business inhale all the scope, three emissions of, you know, like all my suppliers and how they affect me as a business. And what action were taken on those, because now obviously I'm not a carbon scientist, so never quote me 100% accurately.

On all the definitions, but like most people care about scope, one scope, two missions and scope three, not so much, but scope three is really starting to become a big focus. So yeah, we really want to help tackle that issue as well through?

supply chains.

[00:19:47] Mike: Yeah. So for the uninitiated give me the non climate scientists definition of what scope one, two, and three are roughly. You don't have to be exactly correct.

[00:19:58] alexander_karan: Oh my God. Okay. I [00:20:00] really suck at this.

[00:20:02] Mike: I do too, which is why I put it on you.

[00:20:08] alexander_karan: Oh, man. I really do Scott. Okay, so scope one and two are sort of like emissions that, you know, you use directly you know, from burning, right? So like they're direct emissions. So scope one is 100% direct. So that would be like, you know, company vehicles company facilities, things that you are 100% responsible for.

But Bernie scope to kind of like indirect emissions. So like, like, like a really good example would be like electricity, the transport emissions of getting it to you. That would be. Scope to right. Cause it's, it's in direct emissions from you using something and then scope three, a like completely indirect emissions.

So like, you.

know

You know, if, if you're a business measuring your emissions and you're counting your staff's commute to work, right. [00:21:00] Because that's not a company. It's not a scope, one emission, it's a scope three emissions, right? So it's, it's another form of indirect emissions, but it's like once that you're less responsible for, and then this is where all the weird carbon accounting stuff comes in and like what emissions fall under what scope and who's responsible for them and all this other stuff.

And that's where it becomes really, really complicated. And that's why we have an API

[00:21:24] Mike: Yeah, that's, that's really cool. That's one of those things where I don't think we were having discussions about this, you know, 10 years ago this kind of thoughtfulness and sort of introspection about where emissions are coming from. And, and the fact that these terms, you know, scope one, two, and three are becoming.

Normal in the, in the vernacular around the world is, is a good sign in itself. Even if it's not something we've completely conquered yet. So let's talk a little bit about the API side of what you've built in climate clever. Obviously don't divulge any trade secrets, anything like that, but I'd love to hear a little bit about how you've built climate clever, some of the tools you used, some of the API building strategies that your team uses, that sort of a thing.

[00:21:59] alexander_karan: [00:22:00] Okay. Cool. Alright, cool. So we have, it's a node API because of course I love Java script. And it's, it's ho it's currently hosted on AWS, but it is currently being moved to Azure. So there's an interesting story bound behind that as well. So we use ECS on AWS, which is like serverless containers.

So we've got like five microservices all running in Docker containers. You know, simple node API and each, and that just all sits behind API gateway and load balancer, nothing crazy fancy, you know, it's not like, well, you know, we're not a huge, massive company. That's got requests coming in from all over the world, so we don't need any of that crazy stuff.

But we take a very sort of design driven approach to API development. Become more and more and more important as we've moved on. So the reason there's an API is because when we started the platform, when we started building the very first iteration, we were like, well, this is all great, having this nice UI for. Things like smaller business, smaller schools, but as we get bigger, you know, bigger [00:23:00] companies, they're not going to be like great another app to use. They're going to be like, give me the API so we can just integrate it into our systems. And as we work with supply chains, they're going to say the same thing.

So we decided to build it on an API. Level. And this means that I could work really closely with the carbon specialists and sort of, you know, bash back and forth API documentation on how this thing was going to work and all the terminology that went into it. And also with, you know, the other developers and designers in the team, Hey, look, we're thinking about doing it like this.

This is all the information is going to include. We actually use a tool, which I believe Phil, you still work for, which is. So we design, you know, we, you know, we designed a mock all our API end points in there first, before we even touch any code. And we sort of, you know, circle that around the team.

And it's also a really transparent way of staying open with our customers because we have documentation in there about where all our carbon cows come from and how they. [00:24:00] Because we're all about trying to be transparent. Like it's, it's complicated and you might not understand all of it, but we want to try and be as transparent as possible.

And then there's kind of two sides to the API. So there's the external side, which our app uses and which other customers use. So we D we do have an integration into a few other platforms which is pretty cool. But, yeah.

so that's the external side and then there's the internal side. Because one of the most complicated things.

About carbon factors or carbon, you know, calculations and methodologies is that there's all these different factors that you use. So what's a factor. A factor is kind of like a number that you times your consumption or usage of something by to work out the carbon footprint. And there's all these different like rules and.

If and else and switch things, statements that decide what factor gets used. So what we ended up building was actually, we built a system that allowed the, you know, [00:25:00] carbon specialists to enter the factors and then I not have to write much code. And then it sort of used logic to help assign that to people's emissions data.

And that's what we spend a lot of time building over the last. Is a system that does that and it, and it's a really transparent system as well. So like when anybody enters an emission, it tells you who entered it and then it can't be deleted once it's entered, it can only ever been updated. And it's, so it's, it's kind of like, you know, full transparency, but without blockchain, because we can be transparent without it, you know?

So,

So

[00:25:33] Mike: like you've, you've come up with a fairly elegant approach to an accountability system that that will scale also. It's a really delicate point and something that I feel like is almost even understated that you decided that the API was going to be important from early on.

I can imagine a world where you happened on that realization. Maybe a little later in the process or perhaps too late in the process where you'd have to go and re-engineer. Probably much easier to have done that, to begin with and also to start it with a [00:26:00] design first API implementation to.

[00:26:03] alexander_karan: Yeah, it definitely had its pros. I must admit, I think it's, it's not 100% of conscious decision by those definitely that okay. Your business is. Two it'll be easier. But it's also because I like building API is right. There's a little bit of that in there as well. I'd love to just be like, yes, I foresaw everything, but yeah, it's it really does help.

It does help cause the API documentation as well. It's like sort of Bible about how this whole thing works. Right? Cause carbon accounting is complicated. Like I thought development was complicated, but like carbon accounting is like, it's, it's just development on steroids. Like there's no format standard.

Everything can be different. There's this. Th there might be some fast and hard rules for a few types of emissions streams, but then once you move to another one, that completely goes out the window. It's different in every country as well. It's not the same. So there's like to try it. You have to [00:27:00] develop like a very simple generic system in the API that can handle these different factors.

So then when the other side of the API presents that the client or I, or our app, you know, it's easy to understand the consume, you know, Yeah.

It's it's, it's tricky. It's I it's, it's it's funny. Like, I always think what it does is actually quite simple, but it's been the hardest thing I've ever had to build.

You know, it just times is numbers together, but like architecture wise, it was so difficult.

[00:27:33] Mike: Yeah. Yeah. I suppose if it was an easy problem to solve, we'd have it nicked already, you know,

[00:27:38] alexander_karan: Yeah. And testing was definitely a big problem too, as well, but that was the.

[00:27:44] Mike: Sure. Yeah. Yeah, certainly. I wanted to ask you a couple of questions about an article you wrote recently for APS. You won't hate for people who are listening, you may recognize Alexandra Keller Karen's name because he wrote an article for us called modern API deployment options in the cloud where we talked a bit [00:28:00] about just what it's like to spin up an API in 2022, as a, as a sort of a Javascripty developer, like Alexandra and I happened to be.

I would love if, if you don't mind just talking a little bit about that too. It seems that we've come a very long way from setting up an FTP account on a server somewhere and, and setting up, you know, your $5 GoDaddy, VPN and setting things up that way. From a very, very basic standpoint, what do you see as the reasons to go with using some of these more modern deployment options now, as opposed to setting up and managing the server?

[00:28:31] alexander_karan: Well ease, right? Like I feel, you know, this, so there's something called the full stack fallacy. Isn't that an engineer can do everything. And well I think we can, if we use the tools, right. Like, but also I actually let me rewind a little bit, I think looking at front end development, right. Which is undoubtedly hard, has all these really amazing tools now where it's like, Don't worry about this.

You focus on solving the problem [00:29:00] that you're trying to solve and we'll deal with everything else, right? Like, you know, tools like Netlify and versatile. I'm going to be honest. I don't actually remember how to deploy a website or buy a bat without those tools. I know file share was involved in an AWS thing.

And I honestly, I honestly completely forgotten, you know, and that is fantastic, right. Because at the end of the day, as an engineer, I'm not in. To be super clever with my code or like, oh, I've used this tech stack over that tech stack, I'm there to solve business problems. Right? I mean, I mean, yes, I get to do some fancy stuff with code one and they're solving business problems, but that is my main point for existing.

And so that's why I, I wrote the blog about the new modern tools is like, we need this. Thinking it's like really great. And I'm taking off points because I can do all this stuff with the server?

I can manage all this stuff myself. You know, I don't want to have to do that. You know, at the [00:30:00] end of the day, I wanted to deliver value to the company I worked for and for its customers.

Right. That's the most important thing. And I can do that quicker if I don't have to manage everything about a server or manage everything about the database.

[00:30:14] Mike: Yeah, definitely. And you don't have to have all that expertise and I'm sure there's a plethora of fall on effect. Like you don't have to be a security expert for some vague Unix version that your server is. In some

FTP somewhere or manage those passwords, all that stuff for, for the uninitiated, the Netlify and versatile and I guess other other services like that, that use similar deploy options.

The big difference between the old FTP world and this world is. With those FTP servers and the file share stuff that you're talking about with AWS. Like it literally felt in a lot of cases, like you were just crafting some files on your local machine, maybe merging them in, into a get repost somewhere and then dumping all those files onto that machine almost manually.

In some cases, maybe add some nice automations. Can you talk a little bit about the deploy pipeline for [00:31:00] Netlify or sell what that works or what that feels like as a developer, as opposed to the FTP

[00:31:04] alexander_karan: Well, it's it's it's it feels great. So I guess so we, we, we used to use Netlify, we're actually on, for sale at the moment. But I can talk to you a little bit about how, like we use for Purcell for our front end, you know, like basically we do a PR into the main branch and all the tests get run, and then it deploys a previous. In the PR that you can go check out and mess around with, right. So that's not even the deployment, right. That's just, just a PR. So you can go and see the code just by clicking the link in the PR. So that's the first thing there's just gold and it's the best thing in the entire world. The second thing is you want to deploy a website, a web app on versatile. You create your account, you connect the get hub repository, you select the branch and then that's it. Every time you push changes to that branch it deploys. And then you can have deploys to other branches in your code. It's so fast and seamless. [00:32:00] It's fantastic. And, and because it integrates, since you get hub repository, you get feedback on, you know, every PR you do every get, you, push you to whatever millions of different settings, but it's just, it's fast.

It's. It's great. It's I don't even think about it. And I don't have to think about scaling. I don't have to think about delivery networks and all this other stuff. And I, I know my environmental variables are safe because I put them inside for cell, you know, don't need to store them anywhere else. It's just this so many upsides.

[00:32:32] Mike: Yeah, definitely. I think in a past life, if you found yourself working on a, something that became enterprise grade and you needed to have deployments in three times zones or in a bunch of different geographies, you would have suddenly needed to like have a relationship with a bunch of data centers and figure out where your literal physical computer is that you're deploying code to and, you know, devise some really clever way of activating one versus the other.

If, if the HTTP request was coming by via some IP route versus the other, and now you're. [00:33:00] Merging a pull request. You're even, you're not even emerging, you're opening a pull request and this thing is getting opened and distributed in ways that scales so far beyond just the team that you manage, just you writing code you are just, like you said before, taking advantage of all these things that are making your life easier as the person building the API or the front end too.

It's really, really cool to see. And so your, some of your product, at least the API layer is that built using serverless.

[00:33:28] alexander_karan: So obviously, like I said before, it's currently on ECS, which is serverless containers, but we are moving it to Azure which we're using serverless functions for. So, you know, we, we started the migration about two months ago. We'll be finished in a few more months. But yeah, we are moving it all to serverless functions for quite a few different reasons.

Actually. The first one is sustainable. Because although serverless containers are sorta serverless, they still do run a little bit all the time. So even though they're really, really tiny, they still have a footprint, right? So there are times, you know, cause our app, isn't [00:34:00] something that you log into every day, every hour.

So it does have quiet periods. So it, it makes sense to use serverless.

functions. And also, you know, the sustainability goals of Microsoft are. Very admirable and they align with our sort of company ethos. Right.

So that's another reason for the move. And then the final thing is there just as your functions are just really, really great.

They're fantastic. They got TypeScript support. They integrate into the S code so well, like when they came in and demo day for us and showed us how easy it was. I think we set up the four function app. Like 30 seconds integrated automatically into get hub for automated deploys and another 30 seconds without two button clicks.

And then like the local testing is just another click because it's plugged into BS code, you know, it was an extension. So it was really fantastic.

[00:34:51] Mike: Yeah, that's really impressive. That's very cool. That's something I need to spend some time playing with and I can think of one particular team mate of mine. Who's going to really want me to, [00:35:00] to give Atlas Azure serverless stuff ago. Okay. One more question for you. And before we'll kind of wrap things up here I've heard a lot of talk recently about serverless functions, but also the hype seems to be building up around edge functions.

I'm under the impression that edge functions are not always the right sledgehammer for problems that we're solving. What do you know about edge functions? Maybe? When are they the right choice for something? What's the difference between edge and serverless, especially from a a sustainability and sort of climate and energy use focus thing.

Does edge make more sense than serverless? Is there complications there that we might not be aware of?

[00:35:35] alexander_karan: So I think, I think edge does make more sense until you throw database into the mix. Right? Like, I, I th I think as I think as developers, we're always like, oh yeah, it's a new thing. It's hit, let's go for it. Right. Which I do feel guilty too sometimes, you know, but sometimes it's the right decision. Like, you know, spelt was like this really cool hip thing.

And then we tried it and it made so much sense and now we all love it. Right. But like, so. I [00:36:00] wouldn't necessarily build a full fledged API on serverless on sorry, on edge functions just yet. Because like, if my database is, you know, only in one location, you know, th the, the edge functions still need to make a big round trip cool to that database.

So it would make much more sense for me to just have an API on serverless from. Right in the same data center that my databases. But then the thing is if you will serving lots of static content or. Intercepting request to your API, then it might make more sense to use edge functions. And this is where like also complications come in, right.

Because the way I'm starting to see it is it's probably a good thing to have a mix of the two, right. Probably a good mix to have, you know, maybe this. Your main API on serverless functions in a data center next to your database. Although there are serverless and edge databases now as well that you can use and then like edge functions [00:37:00] for intercepts and stuff like that, you know, there's, you could protect images.

On your server or, you know, on a CDN making sure you're all, if you could intercept other requests and, you know, cash the response in a much harder way or chat, or like, I think a real good example is like intercepting a request, checking the location and returning a different response. You know, things like that, which can be done on the edge, which we much better suited than being done on your API.

So maybe a mix I think is the two. But I think that might change, you know, it, it would definitely be. More efficient to have stuff closer to your user. But then, but then this is the question, right? So this is always, this is always the million dollar question. I remember when I was talking about react and graph QL, right.

And people said like, we ask great for everybody because we all have similar front end issues to Facebook, but graph QL. Isn't great for everyone because not everyone is Facebook and not everyone has the same backend problems that face. And I think that kind of?

applies right. [00:38:00] Cause, okay. It's super cool.

Having your API and database on the edge network all over the place, but are your users all over the place? Are you global? Are you will wide? Is that kind of like a waste of time? I mean, I guess it doesn't run, you know, if, if it's not being used, but you've still got to deploy it and send it there. Right.

So, you know, th th there's always those questions. I think those things that we. W will you always forget about it back over like, oh yes, we need to prepare for infinite scale. And I'm like, yeah, but there's probably no more than 20 to 50 companies that need that crazy scale in the entire world. Right. So always would never scale up at the start, you know?

[00:38:42] Mike: Yeah, that's a brilliant answer that, that Is the sum of all of my fears. I think summarized pretty well. If I had to guess having seen some of the history of serverless stuff, my thought currently is that eventually we'll be able to deploy serverless slash edge functions without thinking [00:39:00] about whether it's a serverless or edge function and have the.

Hosting do some introspection and decide what's the most appropriate for the code that's being run, but you are right. Like my little blog that I post about designing things and philosophical earth things probably doesn't need to be deployed for instant use in Sri Lanka and Cleveland and Paris and Miami and New York.

Because if I'm being honest, most of my readership comes from the U S Canada, Australia and the UK. And you know, I would love it if everyone in the world. It's an access to the words that I have to write, but it's absolutely not the case. And there is a real cost to deploying, you know, my nonsense to a thousand servers around the world.

Every time I do a change to my site to

[00:39:38] alexander_karan: Yeah, 100%. I was just going to say like the, the also the more distributed things become, you know, like just, although microservices are a good thing, you know, for distribution makes testing harder, it makes explaining things harder. Like it makes all these things, other things that we don't think about harder that are also really important, you know?

And. Extra layer of distribution. I'm [00:40:00] sure it will create some interesting bugs. It works fine for me, but on that edge function over there, it's a little different, you know, so Yeah,

[00:40:08] Mike: Yeah, I'm just looking forward to the day where I create a software bug. That means I have to go to Fiji to test it out and see what's going wrong.

[00:40:18] alexander_karan: that's, that's a real reason. Edge functions exist, you know, like, oh, well I have to go to Hawaii to, to figure this out either.

[00:40:26] Mike: Yeah. They're all on the edge of an island somewhere that also happens to have drinks served with umbrellas. And, um, Alexander, what's the best way for people to find you and climate clever online? Where can they go?

[00:40:37] alexander_karan: Okay, so you can find me on Twitter. It's just Alexander cran under school at the end. They can find climate clever, which is just www climate clever.org. We officially only in Australia at the moment but always willing to hear from people around the world. Yeah. And that's why they can find.

[00:40:54] Mike: Fantastic. Well, thanks so much for chatting with me today. I really had a great time talking to you looking forward to [00:41:00] hearing more from you, hopefully in the future out Cron. Thanks for your time. Have a great.

[00:41:04] alexander_karan: Thank you so much for having me, Mike, it's great to be here.

[00:41:07] Mike: Right on.