Warm-up chat: Sami Pippuri, Whim - Part 1

Lauri (00:04): Welcome to DevOps Sauna. My name is Lauri, and I am the chief marketing officer of Eficode. Once in a while, we come across services that shake the fundamentals of what we believe in. A service called Whim is definitely one of them. As they say themselves, Whim wants to offer a digital alternative to owning a car. To achieve this in no way little feat, they had to make a number of technological and cultural choices. We had a unique opportunity to get to talk to Sami Pippuri, one of the very first employees and then CTO of MaaS Global, the company behind Whim. Sami had an enjoyable talk with Marko Klemetti, the CTO of Eficode.

Lauri (00:49): As with every major project, there's more to talk than fits the episode, therefore, we split this chat into two episodes. The first one you're listening to now focuses on the technology choices, user experience and DevOps as a culture. The second episode focuses on aspects such as organizing and scaling up the teams and building the commercial model for the services. Let's get going.

Marko (01:17): Awesome. Hello, Sami. I'm very delighted to hear you're here. A small introduction from myself, I'm Marko, the CTO of EfiCode. We have not met, but of course I know who you are. Trying to keep today in a very lightweight discussion type of sense, so that it's more of a friendly talk than an interview. Could you, with just a few words, introduce yourself?

Sami (01:46): All right. I'm happy to be here. Yeah, I'm Sami Pippuri. I'm a software engineer by profession or training, and have a bit of a history in the telecom sector, as is usual in Finland, so I worked at Nokia, Microsoft, but then lately a few startups. I've been building products for consumers, scaling teams up, and sometimes even down. But my latest stint has been at MaaS Global, where I joined as the first employee after the two founders and built basically the product, the technical operation and scaled the team from that zero or one person to 80 people, there abouts, across several countries.

Sami (02:33): Now I'm slightly moving to a different kind of a role in a consultancy point of view. I'm still helping the MaaS team closely but also other companies who may want to scale their operations in a similar fashion to what I did at MaaS, so becoming more of an independent consultant going forward.

Marko (03:01): Awesome. I actually have very similar memories myself starting at Eficode, already 14 years ago, and scaling up our DevOps unit as it currently is in Finland, similar size. I already know how you probably feel. Can I ask you, what's your first memory of DevOps? Or when did you first bump into DevOps?

Sami (03:24): That was probably in the Nokia era when I was working with a team in Bristol. Nokia had bought a company from there, which was a startup with very humble beginnings, around 50 people or so. I think it could have been a little bit less than that. I actually moved to UK to work with the team for a couple of years and was there to ramp up, what was called back then, business analysis, even though it basically morphed into a Product Owner/Scrum Master team. I had worked with mobile software before, and cloud services were just up and coming with Amazon just having barely launched S3 and so forth, but these guys had ... Obviously, things were private data center oriented, but there was a process of deployment of VMs, essentially building up VMs. It was rather new for me, so it was a good learning experience, and that's ...

Sami (04:37): It wasn't really called DevOps back then. I think there were Ops and there were deployments and so forth, but the term DevOps didn't really come up back then, but that's basically what was involved when making builds and making deployments continuously. That was a very nice experience for a mobile engineer back in the days.

Marko (04:59): Yeah, I can imagine. Must have been the same era when I started. I've collaborated in CruiseControl and then later in Hudson, which are the first CI or Continuous Integration Tools, myself. Do you have a recollection of how ... Did you already have memories of Agile or had you already been working in Agile mode before that, somewhere?

Sami (05:23): Yeah, that was around 2007, actually. I forgot to mention that one. That was just a point where ... I can't recall whether I had learned about that job before that stint, but certainly during it, I did some research and studies as well. No, actually, I had taken some Agile courses just before going there. I was curious on trying it out. And actually, a funny story about it was that when we went in, we were pushing a very rigid process to get the team deliver what has been agreed, and so forth, but very quickly I realized that that's not going to work with this team. Definitely, it doesn't work that well in general.

Sami (06:16): After a couple of misses of saying, "Okay, this is the roadmap," and then things get locked and then fail to deliver, I just kept the surface that I still present roadmaps to the management, et cetera. But underneath, we actually started running an Agile process, and what do you know, the next delivery was on time and folks were amazed, "Hey, what happened?" And like, "Yeah, there's this thing that I never told you about, that we are actually running an Agile operation."

Marko (06:53): Sounds really awesome. I feel that also the people who have started doing Agile and DevOps, in a way, hand in hand because they, of course, in my opinion, support each other a lot, even while Agile is already established itself when DevOps as a term was conveyed somewhere in 2011. But still today, I feel the same applies. So then some organizations need the piloting under the hood, in a way. Could you give a short breakdown of the technology choices you've done in Whim?

Sami (07:33): Sure. And this was actually pretty ... Well, I don't know if the word spot on is correct, but I've been using my job interview slides as a reference in many public talks and I've shown that, okay, this is the kind of slide that I showed to sample for the CEO when interviewing for the job. He basically gave me a challenge, said, "Okay, we need to build this kind of a thing that integrates lots of these different services, and we want to focus our efforts in serving the end user rather than, say, tinkering on the perfect routing algorithm for all of our money's worth, how would you do it?" And then I had used serverless on a few hobby projects before.

Sami (08:30): It was still quite rough around the edges, so it was a bit risky, but I knew that this feels like something that I want to try in this project, because we had funding for basically creating an MVP and no visibility beyond that. So I thought that, "Okay, what could possibly go wrong?" Pick up a bit of a rough technology, but the worst case would be that we ran out of money, and at least we have learned something because I believed back then that innovation is moving up in the stack. This will be a logical step how the stack will evolve. People will want to have more and more of managed services, so I thought, "Okay, this is going to be, anyway, a good learning."

Sami (09:22): In the good scenario that it's a good success and we start scaling it, then at least we have already built a solid foundation and we know a bit about running a serverless stack and building it. And we can start scaling it with perhaps less of a rewrite because there's ... All the foundation doesn't need to change. You don't need to swap out Amazon. This was the logic back then, so like I said, we were all in with Amazon, pretty much on the compute-

Marko (10:01): If I may ask, is it Lambda you started with?

Sami (10:05): Yes. It started with a pure Lambda implementation.

Marko (10:12): Wow.

Sami (10:13): Severless in our world means Lambda. And it has, a little bit, morphed into more broad views of AWS services. There are some cube clusters and so forth for longer running services, data operations, et cetera, but I think the core is still very much how it was designed back then. We started out with a very puristic micro servings approach, but then we took a step back into more, say, for example, making deployments as sort of a monolith, because things were changing all the time and there was a risk that systems get out of sync and services don't talk to each other. So we rolled back a little bit and went to a monolithic deployment, even though the actual services were still split into ... I think we've been around a hundred plus Lambda for the core service, and now I think it's around maybe 160 Lambdas. And then, of course, in the integration side, there's even more than that.

Sami (11:35): But the puristic microservice architecture in Lambda was a bit tricky to get performance in this kind of a scenario where you have maybe not so much traffic. And then most of the services were interactive with the end user, so you can't afford to have long pauses for a cold start, et cetera. Amazon has, of course, done a lot of excellent work on optimizing the cold starts, so it's not really a problem anymore. But in stages where we had things like VPC bound Lambdas, et cetera, and cold starts to be five to 10 seconds, that's too long for the end user to wait. So you have to work around those kind of things.

Marko (12:26): Yes. It's obviously just, well, a price to pay for the bravery. But on the other hand, now that we look at the world is going, as you said, already managed services and definitely serverless and everything. If you look at how the version control in serverless technologies have evolved, and also many of the organizations are moving into, well, not only microservices but serverless technologies, and having the versioning done in such a way that you can actually deploy some parts independently. It's something that you've enabled from the core, and then just decided to take the step back into monolithic deployment, which is completely not wrong because, of course, it might work better in some cases, as yours for example. It's really, really interesting.

Sami (13:18): I don't want to forget also the front end of things, obviously. Where we went maybe on the bleeding edge in the backend, we maybe went a little bit more conservative on the front end. Because after my experience with lots of client development tech, working with lots of different cross-platform frameworks, et cetera, I saw that getting a really optimized experience on the front end with cross-platform is quite tricky. We started out basically building native apps for iOS and Android, actually iOS first, so we had a working MVP by the time we hired our first Android developer. Android developer was excellent, but also having a clear goal I think helped the Android team very much where they could basically skip the learning process that the iOS developers had to go through with the changing designs and et cetera, which leads to maybe suboptimal architectures and some technical depth very quickly. So Android caught up to iOS and passed in areas very quickly. That was also fun to watch.

Marko (14:41): But it's also a way that many organizations have taken, especially because Kotlin and Swift have emerged and they're getting closer to each other by day. Of course, they still have their differences. And I said it's usually easier to implement the features into the secondary platform once you have done the learnings in another ... I actually made a fun pilot a year ago of what is the minimum number of lines of code that you can have to be able to release in both Google Play and App Store, and the answer was 10 lines of code of native. And of course in both cases, the application uses WebView, but it still passed also the App Store Review, which means that they still allow use of WebViews for certain areas, which is really interesting. Also, for the piloting phase, if you decide to go for a native application, this could be something that some organizations might want to try out.

Sami (15:45): Yeah. And I am a believer of the hybrid approach. There are lots of scenarios where having web content as part of your application just makes perfect sense, payment flows being one, for example. It's pretty impossible these days, with 3DS, to support all kinds of bank authentications natively in the application anyway. Something like React Native of course works for information heavy applications, and it's quick and relatively easy to get going, but then you start bumping into the maintainability issues over time, so that's why I've decided not to go with that early on. After Airbnb dumped it, I was vindicated on that one. But I think React Native still, of course, makes sense for a lot of companies, especially when you are on a budget and want to support both iOS and Android.

Marko (16:42): Yeah, exactly. But still I said, I don't think there is a way to beat that the native flow of the applications, even today. We've been years on the different cross-platform libraries, but still I think native is the winner in many, many cases. I would like to ask about the UX. As said, you are providing services, from your point of view, third party, and that must bring challenges also to the decisions in UX. How have you organized your UX design and development? And how has it worked for you?

Sami (17:20): Well, the design has been a little bit of a separate entity because of similar scalability things, probably. It started out as very design centric when we started building the MVPs. Lots of user research went into it, so the design itself was taken pretty far before any technical work was actually started, because this had started already before I joined. There was a solid baseline of user research and concept being done already, but we continued that, obviously, in sort of a parallel track from technical development. So the design team, which has won us a lot of these awards, constantly developed the thinking and create ideas and test them out with actual focus groups and end users. I'm really proud of the work that the design team has done and it keeps doing all the time, so constant user validation.

Sami (18:31): At its best, when we then said, "Okay, yes, this is the kind of concept or change that we believe in," putting that into a cross-functional team where you have a clear goal, perhaps a deadline, because there might be something that we have to address by a certain date, which of course you don't want maybe as a team, but then it does produce this, "Let's get this done," kind of a feeling when people get around a whiteboard and you have a designer and a developer to actually brainstorm, "Okay, now there's this thing. We absolutely have to get nailed. Here's the concept." And then start working it through and developers start to get engaged in that as well, that, "Hey, this kind of thing is actually quite difficult to do, but if we do it that way, would that make sense?"

Sami (19:30): And you have this cross pollination of ideas, and that's so energizing to see and experience when you're in this virtual cycle where people just keep on building on top of each other's ideas and make it a much more tangible thing and are able to then implement it. So that is also a reason why I believe in this two pizza independent teams, that you get those good benefits and you get that kind of a vibe into the actual work.

Marko (20:14): Yeah. And I can say from my experience that it's way easier said than done, because there's always the people inside the team and how well they collaborate. And if you can just spike it up, you can get really, really good results out of it. There are, of course, guides on the two pizza team, as you said, and ways to approach it, but then the last part always feels a bit like magic.

Sami (20:43): Yeah. It doesn't happen, of course, with just about any topic. Also, people have to believe in it and they need to have a sense of purpose that this is exactly the right thing to do, and they want to be a part of it. I can say that that doesn't happen with every feature, but at its best, that's how it is. And that also creates positive memories for people. A lot of people have been saying that that was really tough times, but so glad that we were able to do it. And then when you get awarded for it, as a design award or some other award, then even a year after, you will then fondly remember that time.

Marko (21:29): Do you have the designers now in-house and also the UX research part? Are you building it yourselves within the team? So is it an external, either from the teams external, or then of course an external company? Out of curiosity.

Sami (21:46): There's a core of the design in-house, and then there are, of course, contracting networks that can be tapped into if there is a particular topic, but ... Especially in a product like this, design is such a central thing that it cannot be really handled as a one-off project base. You can maybe spin out a project for investigating or researching a new area of product or a completely new product or a different take on it, but to have consistency over time, you need to understand also the vision behind what are we trying to do. So that's why I'm happy that it is in-house and there are excellent designers for those UX as well as visual design in-house. And luckily, the same people are also capable of validating their designs with end users. They might need a bit of help in terms of coordinating the participants and so forth, but the core of this activity is in-house.

Marko (23:08): Now, going back into the original question, how would you see DevOps as part of all of this? Of course, in the core of development as I've already heard, in the core of teams, in the core of the backend development, do you see DevOps being a part of everybody's culture or something separate?

Sami (23:29): Yeah, especially in the context of serverless. I've always internally wondered about, is what we are doing DevOps or is it not? I don't know. I have not really done the research on literature on how do you actually define what is DevOps. Because when using managed services like serverless and building on top of ready-made cloud services on Amazon, et cetera, what you are doing is kind of DevOpsy. You're managing your build pipeline. You're building on other people's work and optimizing things, maybe, but it's much less about the Ops side of things when you don't really have ... For example, we did not have any operations people until like three years into the company, so the developers are basically responsible of maintaining the infrastructure as well.

Sami (24:37): It's all infrastructure as code, so once you make the deployment, it either works on the first, second, or it doesn't. It doesn't just spontaneously break after going out for the weekend. With serverless, you don't have any security patches to apply, no servers to reboot. If something is failing after the fact of deployment, then it's probably, maybe you run out of some quota or your logging system runs out of disc space. That's basically the fault of not using a serverless, scalable thing. It changes the whole notion.

Marko (25:25): Yeah. And that's also why, in my opinion, it's also really hard to say what DevOps actually is, because ... Well, naturally for me, what you're explaining is the core of DevOps, being able to boost the productivity and boost the quality of the teams working and taking out the parts of the equation that are not supporting your core business. So maintaining services, for example, or servers even, would not be something that would be beneficial for your core business. So in the core of DevOps in that sense, definitely. At the same time, already as you explained, I feel that there is a new wave of DevOps coming from making sure that there is enough quotas, and you have some sort of security monitoring in place, and you have monitoring for probable misuse or some patterns that emerge from things that you didn't expect to actually happen. And the DevOps becomes more preventive than reactive than it has been, so along already.

Sami (26:33): I think that very well describes what we actually then ended up doing. So building things like monitoring is especially important in a stack like this. Again, when you don't see blinking lights and you don't see what the traffic is unless you actually visualize it, so I ended up building quite a lot of these different kinds of monitoring tools and alert systems and fraud detection tools and these kind of things. Very interesting attacks, for example, happen in a serverless environment where you don't necessarily notice that you're under attack. Only got a notification on my phone that really you just charged me again, because lots of SMS are being sent, and I was like, "Okay, what's going on here? Okay, there was a script key that found a way to send a lot of SMS messages." So yeah.

Marko (27:39): It's, as I said, the future. And also, I have to say that when organizations become like dots in a map, like Whim definitely has, and becoming noted services, it also increases the amount of misuse and frauds immediately. So that's also really important to have as part of the organizational culture and knowledge as well. It might happen so fast and surprisingly.

Lauri (28:09): That was thrilling, wasn't it? But it's not everything. Tune in to the second episode to hear Marko and Sami talk about organizing and scaling up the teams, building the commercial model, and also what's next for Whim.