1
00:00:07,820 --> 00:00:10,332
Welcome back to Adventures in DevOps.

2
00:00:10,332 --> 00:00:13,365
For this episode, we're going to do a deep dive with serverless.

3
00:00:13,365 --> 00:00:17,838
So we've invited founder and long time cloud solutions architect, Lena Furman.

4
00:00:17,838 --> 00:00:19,290
uh Welcome to the show.

5
00:00:19,290 --> 00:00:24,634
You've done it all, UX designer, web designer, full stack, cloud engineer, and now cloud
architect.

6
00:00:24,634 --> 00:00:30,209
But as founder, that probably also means customer meetings, user research, and I'm sure
training.

7
00:00:30,209 --> 00:00:31,880
You can't get away from that, huh?

8
00:00:32,312 --> 00:00:32,832
Thanks, Florian.

9
00:00:32,832 --> 00:00:33,723
Thanks for having me.

10
00:00:33,723 --> 00:00:36,493
Yeah, it's kind of I've done all of the above.

11
00:00:36,493 --> 00:00:41,626
I love some of them, some not so much, but they're all part of my daily life.

12
00:00:41,626 --> 00:00:45,557
And I think in general, see myself as a generalist.

13
00:00:45,557 --> 00:00:50,810
I can do many things well, but none of them really great.

14
00:00:50,810 --> 00:00:54,541
So yeah, that's really where I find my strength.

15
00:00:54,541 --> 00:01:01,254
think I would also get bored otherwise if I would just really only dive into one topic and
then.

16
00:01:01,570 --> 00:01:04,459
become the best expert in the world in that topic.

17
00:01:04,698 --> 00:01:11,543
I mean, it really is so many things, but I feel like you are the founder at Baspinian,
which is a cloud consultancy, is that right?

18
00:01:11,964 --> 00:01:19,839
And I assume that your customers have so many different requirements or challenges that
you need to sort of work your way through.

19
00:01:19,839 --> 00:01:24,102
And I like the perspective that you've done all these things, but you don't like all of
them.

20
00:01:24,102 --> 00:01:26,242
So which ones do you not like?

21
00:01:26,242 --> 00:01:31,145
So the technical topics are usually the one that we are very passionate about that we jump
onto.

22
00:01:31,145 --> 00:01:37,308
But usually, you know, it starts way before that with the human challenges, with the human
problems.

23
00:01:37,388 --> 00:01:42,731
And I like that you used the word challenges because that's right, usually makes sense to
start.

24
00:01:42,731 --> 00:01:50,355
It doesn't make sense to already think about the technical solution to the problem that we
have had in our mind from the very beginning.

25
00:01:50,355 --> 00:01:55,670
And I hope I have to hold myself back sometimes to not just do that from the get go.

26
00:01:55,670 --> 00:02:06,088
like to just get into the project and already have in the back of my mind that serverless
is going to be the solution for this company, for this team, for this project, for this

27
00:02:06,088 --> 00:02:07,098
problem.

28
00:02:07,119 --> 00:02:17,526
So yeah, I think that's what I hate the most, that I have to hold myself back and not jump
into the technical problems or technical topics from the very beginning.

29
00:02:17,816 --> 00:02:19,609
So you really focus in the serverless domain.

30
00:02:19,609 --> 00:02:22,915
think anyone who knows you knows you're all about the serverless.

31
00:02:22,915 --> 00:02:31,389
And I think before we get into sort of the customer conversations, the question I think I
need to ask you most is, in the age of AI, is serverless over?

32
00:02:32,579 --> 00:02:35,040
I kind of expected a question like this.

33
00:02:35,420 --> 00:02:39,342
And obviously the answer is it depends because I'm a consultant.

34
00:02:40,963 --> 00:02:47,266
No, think obviously serverless has a lot of uh potential also for AI.

35
00:02:47,367 --> 00:02:55,111
I think there is a big confusion that people, when they hear the word serverless, they
directly think about function as a service.

36
00:02:55,111 --> 00:03:01,114
They think about AWS Lambda, Google Cloud Functions, Azure Functions and so on.

37
00:03:01,198 --> 00:03:14,022
m And I think serverless covers a lot more topics and a lot more services that are offered
by modern day infrastructure providers, cloud providers, whatever you want to call them.

38
00:03:14,022 --> 00:03:27,345
And there are serverless services that cover the AI area where you can have basically
serverless inference or serverless training, or even consume the AI itself just through an

39
00:03:27,345 --> 00:03:30,860
API, which is also kind of serverless, right?

40
00:03:30,860 --> 00:03:37,576
Serverless basically just means that there are no servers involved for you as the
consumer.

41
00:03:37,577 --> 00:03:40,840
Obviously, there are still servers in the back end.

42
00:03:40,840 --> 00:03:42,841
There will always be servers.

43
00:03:43,022 --> 00:03:48,026
But you as the user, as the consumer, you don't have to concern yourself with those
servers.

44
00:03:48,147 --> 00:03:51,290
And for me, that's the definition of serverless.

45
00:03:51,290 --> 00:03:55,612
It's not to jump directly to function as a service.

46
00:03:55,612 --> 00:03:56,733
no, I absolutely agree.

47
00:03:56,733 --> 00:04:05,117
I think it's one of those areas where there's a lot of people that stand up on principle
and believe that serverless has to be a particular thing.

48
00:04:05,117 --> 00:04:11,425
based off of that, they either decide it's the best thing ever or it's literally the worst
and they won't go anywhere near it.

49
00:04:11,616 --> 00:04:12,427
Exactly.

50
00:04:12,427 --> 00:04:16,929
it's also like everything in IT, it's not a silver bullet.

51
00:04:16,929 --> 00:04:19,926
are, you know, upsides and downsides to it.

52
00:04:19,926 --> 00:04:27,786
I quite like this image of, you know, the abstraction ladder where if you climb up the
abstraction ladder, then you have to do fewer things.

53
00:04:27,786 --> 00:04:33,459
There is less that you have to think about and concern yourself with, but there is also
less that you can do.

54
00:04:33,459 --> 00:04:35,660
So you have fewer possibilities.

55
00:04:35,800 --> 00:04:38,582
You have less flexibility and

56
00:04:38,872 --> 00:04:47,507
This can be applied to AI and to other topics, to compute or databases, file storage, blob
storage, whatever.

57
00:04:47,748 --> 00:04:57,934
But um usually you have to place yourself somewhere on this abstraction ladder and it's
how much control can you and are you willing to give away?

58
00:04:58,156 --> 00:05:06,615
Yeah, mean, you're arguably constraining yourself with lack of fine-grained configuration,
whereas the most configuration you would have is if you were on barren metal.

59
00:05:06,615 --> 00:05:15,134
I think maybe the question is, especially because you're in the consulting space, how do
you decide that serverless is right for all of your customers when, I mean, we know it's

60
00:05:15,134 --> 00:05:21,050
the right answer, but how long does it take to convince them that that's actually what
they wanted all along?

61
00:05:23,159 --> 00:05:24,700
It really depends on the people.

62
00:05:24,700 --> 00:05:29,202
That's what I mentioned at the beginning that usually you cannot start with the
technology.

63
00:05:29,202 --> 00:05:30,803
You have to start with the people.

64
00:05:30,803 --> 00:05:32,544
You have to understand their problems.

65
00:05:32,544 --> 00:05:36,546
You have to understand where they come from, what their background is.

66
00:05:36,546 --> 00:05:40,308
And as I said, it's also not always the right solution.

67
00:05:40,308 --> 00:05:45,401
Usually companies don't have a full on serverless strategy or not.

68
00:05:45,401 --> 00:05:47,702
It's not a binary choice usually.

69
00:05:47,702 --> 00:05:51,018
They have cases where maybe there are

70
00:05:51,018 --> 00:06:02,064
able from a compliance point of view, from a technical point of view, to give away the
control, to give some control to the platform provider or the serverless provider.

71
00:06:02,345 --> 00:06:11,550
But there are cases where they might not be able to do that because the data is just so
sensitive, because it's important for them to have the sovereignty not to do it.

72
00:06:11,870 --> 00:06:16,893
It also always comes with a higher lock-in if you climb up the abstraction ladder.

73
00:06:16,893 --> 00:06:18,674
So usually it's more of...

74
00:06:18,678 --> 00:06:26,841
Is this use case suitable for serverless and not is this company or is this team suitable
um for serverless?

75
00:06:26,841 --> 00:06:32,724
For me, this also goes a bit into this discussion of microservices or not.

76
00:06:32,724 --> 00:06:34,845
It's also not a binary choice there.

77
00:06:34,845 --> 00:06:45,629
Usually, uh it can make sense to start out with a big monolith and then break out little
parts that make sense, that do have the requirements to be broken out, that have maybe

78
00:06:45,629 --> 00:06:47,830
their own lifecycle or stuff like that.

79
00:06:47,970 --> 00:06:53,132
These are all, I think, very similar discussions that you need to have with customers.

80
00:06:53,390 --> 00:07:03,330
I totally agree and you know it's interesting you brought up the I think it's on our
secret bingo card here microservices versus model it that I think we want guests to sort

81
00:07:03,330 --> 00:07:14,090
of talk about I'm still planning this episode where we where we have a heated debate over
one architecture I hate to even call them paradigm versus another one I'm it's sort of

82
00:07:14,090 --> 00:07:18,284
hard to separate it with serverless because there is this aspect of

83
00:07:18,284 --> 00:07:27,417
with serverless that if you don't control the servers and you limit the configuration that
likely you may also want to limit the scope of each individual function in a way.

84
00:07:27,417 --> 00:07:38,500
think one of the heated debates even bring it closer to home in the serverless realm is do
you try to still shove every all the business logic for a particular service into a single

85
00:07:38,500 --> 00:07:46,492
function or unit container or do you segregated across some sort of business lines or
functionality?

86
00:07:46,492 --> 00:07:47,738
Is there a limit?

87
00:07:47,738 --> 00:07:56,516
I don't know if there's one overarching sort of strategy that claims it to be the best
practice, but I've seen a lot of people on both sides of the debate.

88
00:07:56,516 --> 00:07:57,928
Where do you land on that?

89
00:07:58,146 --> 00:08:03,228
So when I started out doing serverless, that was even before I founded Best Binion.

90
00:08:03,509 --> 00:08:09,752
And it was at a startup that started completely from scratch with their infrastructure.

91
00:08:09,752 --> 00:08:12,033
And we wanted to do everything serverless.

92
00:08:12,033 --> 00:08:14,035
were a very small team.

93
00:08:14,035 --> 00:08:21,558
We didn't have the capacity to take care of servers and neither did we have the financial
means to do so.

94
00:08:21,779 --> 00:08:24,150
And we fell into this trap.

95
00:08:24,150 --> 00:08:28,122
So we started building this huge landscape of like 60 different

96
00:08:28,326 --> 00:08:32,867
functions that were all kind of their own little nano service, I call them.

97
00:08:32,867 --> 00:08:35,468
uh And it was crazy.

98
00:08:35,468 --> 00:08:45,731
We couldn't really manage them well after time because luckily they were all written in
Go, so they were all kind of similar, but uh they all had their own life cycle.

99
00:08:45,731 --> 00:08:50,092
They all had their own dependencies that could come up with CVEs and stuff like that.

100
00:08:50,092 --> 00:08:53,283
When we upgraded the Go version, was a huge endeavor.

101
00:08:53,283 --> 00:08:54,613
It was a huge task.

102
00:08:54,613 --> 00:08:57,216
So right off the bat, I completely started into

103
00:08:57,216 --> 00:08:59,747
one extreme of this debate.

104
00:08:59,747 --> 00:09:03,669
And I think that's almost never good, it's almost never the right answer.

105
00:09:03,669 --> 00:09:05,549
And we had to learn it the hard way.

106
00:09:05,549 --> 00:09:12,422
We then tried to, after a while, consolidate different functions from nanoservices into
microservices.

107
00:09:12,422 --> 00:09:19,515
You know, we did all of the domain-driven design workshops, event storming, all the good
stuff.

108
00:09:20,235 --> 00:09:26,870
And in the end, we ended up with, I think it was around six microservices that were all
each their own function.

109
00:09:26,870 --> 00:09:30,653
And I think that was a much more sane place to be in the end.

110
00:09:30,653 --> 00:09:42,021
And I like to follow this approach that I mentioned before, that you start with one big
thing and then when there are different requirements for parts of it, then you start

111
00:09:42,021 --> 00:09:44,903
breaking them out one after the other.

112
00:09:44,903 --> 00:09:49,706
And when I say requirements, this can be, you it's a different team maintaining this part.

113
00:09:49,706 --> 00:09:55,430
Does this part have different requirements towards resources, you know, compute?

114
00:09:55,534 --> 00:09:59,057
uh storage memory, stuff like that.

115
00:09:59,138 --> 00:10:01,120
Does it have its own life cycle?

116
00:10:01,120 --> 00:10:05,504
Stuff like that can then make sense for parts to be broken out.

117
00:10:05,504 --> 00:10:15,086
But to do it just from the get-go, think it's most of the time is really an overkill and
it will lead to much more complexity than you would have initially had.

118
00:10:15,086 --> 00:10:18,566
I think this cannot be overstated and you called it out.

119
00:10:18,566 --> 00:10:24,746
Like look at the interface for the control plane, for the configuration management of your
individual server lists.

120
00:10:24,746 --> 00:10:39,246
if we're talking about like cloud functions and GCP or Lambda and AWS, you've got things
like memory and timeout for the most part, maybe runtime and architecture like AMD or ARM,

121
00:10:39,246 --> 00:10:43,566
you know, x86, 64 as the options.

122
00:10:43,566 --> 00:10:44,106
And that's it.

123
00:10:44,106 --> 00:10:45,240
There's not a lot else.

124
00:10:45,240 --> 00:10:50,042
Maybe it's the total amount of hard drive space or temporary storage space.

125
00:10:50,042 --> 00:11:01,145
If there's a difference between that, then you sort of have to have a distinction in what
you're deploying because you can't have both two different values there for the same

126
00:11:01,145 --> 00:11:01,646
thing.

127
00:11:01,646 --> 00:11:03,987
You have to deploy separate pieces there.

128
00:11:03,987 --> 00:11:09,088
You know, trying not to get into the, you know, whether or not microservices is
appropriate or not.

129
00:11:09,309 --> 00:11:13,006
I think the one thing I do like about what you said here is that

130
00:11:13,006 --> 00:11:19,500
And maybe the question in the back of my mind is when you are using a serverless
technology, there's two things that come up.

131
00:11:19,500 --> 00:11:28,666
Number one, I feel like the cloud providers really try to push a lot into segregation,
into building, I even hesitate to call them nano services.

132
00:11:28,666 --> 00:11:30,898
What's smaller than a nano?

133
00:11:30,898 --> 00:11:33,220
Like an Angstrom, Angstrom services.

134
00:11:33,220 --> 00:11:43,116
All the documentation, lots of the articles out there on the internet always suggest like,
yeah, just throw another uh function as a service.

135
00:11:43,370 --> 00:11:48,894
instance at that technology and so they lend themselves to going in this direction.

136
00:11:48,894 --> 00:11:57,879
But I think my experience mirrors your own, which is, well, have the right level of
separation, whatever that is.

137
00:11:57,960 --> 00:12:03,984
It's like, I don't know how many it is, but it's three things or four things or whatever a
thing is in this context.

138
00:12:03,984 --> 00:12:07,987
But the cloud providers don't come up with that argument to start.

139
00:12:07,987 --> 00:12:13,228
And then there's a lot of debate within the industry of how to approach these things and
you end up with people on both sides.

140
00:12:13,228 --> 00:12:15,080
I like the way you've broken it down though.

141
00:12:15,080 --> 00:12:24,692
The one retort I think I have is, and it's the same thing that Sam Newman brings up in
building microservices, is that you start with the monolith and then say, break it apart.

142
00:12:24,692 --> 00:12:31,019
However, in practice, most large organizations I see who have monoliths cannot break it
apart.

143
00:12:31,019 --> 00:12:33,842
They have tried many times and failed.

144
00:12:33,954 --> 00:12:35,265
Yes, I fully agree.

145
00:12:35,265 --> 00:12:36,714
I've seen that before.

146
00:12:36,714 --> 00:12:39,357
And I think this comes down to that.

147
00:12:39,357 --> 00:12:44,480
Even if you start out with a monolith, then you still have to do your architecture right.

148
00:12:44,480 --> 00:12:48,462
You still have to create an architecture that allows you to break out those parts.

149
00:12:48,462 --> 00:12:57,877
And usually what works quite well is, you know, this clean architecture, hexagonal
architecture, where you have a clear separation between the core, the business logic of

150
00:12:57,877 --> 00:12:58,427
what you do.

151
00:12:58,427 --> 00:13:02,029
em And you have clearly defined interfaces.

152
00:13:02,029 --> 00:13:03,608
And I think that's something that

153
00:13:03,608 --> 00:13:08,740
For example, language like Go really facilitates and helps you to go in this direction.

154
00:13:08,740 --> 00:13:13,182
But this doesn't even have to do much with serverless, in my opinion.

155
00:13:13,182 --> 00:13:24,367
But if you don't do this, your due diligence, when it comes to architecture and prepare
your monolith for stuff being broken out, then obviously you're going to run into problems

156
00:13:24,367 --> 00:13:32,130
and you're going to hesitate in breaking those things out because it's just so much work
or because your engineers are afraid of...

157
00:13:32,130 --> 00:13:36,944
breaking things that they don't have anything to do with, rightfully so in the most cases.

158
00:13:36,944 --> 00:13:46,822
yeah, just having microservices or nano services, uh angstrom services, it doesn't prevent
you from having to do your architectures right.

159
00:13:46,822 --> 00:13:50,284
It actually makes it much more important that you do so.

160
00:13:50,405 --> 00:13:59,172
And that is something that I think when it comes to these requirements, I also work a lot
with containers, with Kubernetes and these kinds of things.

161
00:13:59,172 --> 00:14:01,642
And to me, when I look at serverless,

162
00:14:01,642 --> 00:14:12,985
Usually the requirements that serverless applications have towards architecture are
basically the same as the traditional cloud native service, but it's much more important

163
00:14:12,985 --> 00:14:14,446
that you actually follow them.

164
00:14:14,446 --> 00:14:23,288
When you run your application on Kubernetes, maybe you can be forgiven if you store
something on the file system or something like that because your application will not

165
00:14:23,288 --> 00:14:25,439
restart for months and months.

166
00:14:25,439 --> 00:14:29,250
But when you're running something on a function as a service platform,

167
00:14:29,250 --> 00:14:33,100
then it's going to restart every couple of minutes or hours.

168
00:14:33,100 --> 00:14:39,404
So you're going to run into the problems much more quickly and it's going to be much more
severe if you make those mistakes.

169
00:14:39,554 --> 00:14:40,299
See?

170
00:14:40,358 --> 00:14:45,180
I have, like, I think the exact same scenario and I look at it from the opposite
perspective.

171
00:14:45,180 --> 00:14:57,666
You are saved from the grievous mistake you've made if you pick a pure serverless solution
because it reminds you immediately how dumb of the thing you did in trying to use the

172
00:14:57,666 --> 00:15:00,047
hardware directly in a way that wasn't prepared.

173
00:15:00,047 --> 00:15:01,148
Like it's ephemeral.

174
00:15:01,148 --> 00:15:09,792
Whereas if you try to build a whole queue system that's dependent on a database that's
ephemeral and you're running in Kubernetes, you're much more likely to get six months out

175
00:15:09,792 --> 00:15:10,492
the door.

176
00:15:10,492 --> 00:15:15,034
and then find out that you've caused a huge production incident of which there's no
recovery.

177
00:15:15,034 --> 00:15:16,745
Well, no, technical recovery.

178
00:15:16,745 --> 00:15:21,217
Of course, there's still a business recovery, which is usually an email saying, oops, we
messed up.

179
00:15:21,217 --> 00:15:25,459
We promise to take a serious look at our architecture and do better in the future.

180
00:15:25,519 --> 00:15:29,421
Whether or not that's coupled with actually doing those things is a separate question.

181
00:15:29,421 --> 00:15:31,352
But I think this is sort of weird.

182
00:15:31,352 --> 00:15:39,886
There's a weird crux for me where if you use serverless in the way that it's described, it
forces you to think about those things.

183
00:15:40,352 --> 00:15:43,803
It's not forcing you to think about things that you wouldn't have had to think about.

184
00:15:43,803 --> 00:15:51,515
It's forcing you to think about things that you would have had to think about but decided
not to because you didn't know or you thought you knew better and going down that

185
00:15:51,515 --> 00:15:51,905
approach.

186
00:15:51,905 --> 00:16:03,439
So from my standpoint, I see it as a safety mechanism rather than or uh rather than a pit
of failure where you're forced to spend time and resources and effort learning about

187
00:16:03,439 --> 00:16:06,310
something that you may not have wanted to otherwise.

188
00:16:06,926 --> 00:16:07,906
Absolutely.

189
00:16:07,906 --> 00:16:18,431
Yeah, that's, I also always recommend people to run at least two replicas of their service
on Kubernetes, not just because it's going to be more stable for them and more production

190
00:16:18,431 --> 00:16:28,276
ready, but again, exactly because of the reason you just stated, it forces them to not
have shared, to not store stuff in memory that would have need to be shared between those

191
00:16:28,276 --> 00:16:30,597
services and all these kinds of things.

192
00:16:30,597 --> 00:16:34,188
just lets you run into those traps much earlier on.

193
00:16:34,982 --> 00:16:43,186
So for these customers that haven't fully come to terms yet that they're going to be
migrating to serverless because they haven't even thought they haven't thought of it or

194
00:16:43,186 --> 00:16:45,867
they did think of it and they just hadn't met the spinny in yet.

195
00:16:45,867 --> 00:16:49,819
ah What is your what is your best argument for the migration?

196
00:16:49,819 --> 00:16:58,803
Is there one that you end up going to more frequently than others that you're just like
here it is and then bam they migrate over or do you feel like it's a it's a challenge

197
00:16:58,803 --> 00:17:01,844
every time or is there something else going on?

198
00:17:01,998 --> 00:17:03,579
So all of the above.

199
00:17:03,959 --> 00:17:10,553
It's uh usually a challenge because there are completely new paradigms for people that
they need to learn.

200
00:17:10,553 --> 00:17:14,845
It's completely new ways of how they deploy and write their applications.

201
00:17:14,845 --> 00:17:20,448
m I think the one argument that mostly convinces people is cost.

202
00:17:21,308 --> 00:17:25,971
That's probably true for many different areas in IT and in business in general.

203
00:17:25,971 --> 00:17:29,993
um But I don't mean cost directly.

204
00:17:29,993 --> 00:17:31,714
So let me explain.

205
00:17:31,896 --> 00:17:41,773
think about cost, what you think about initially is, you know, what is on your AWS bill or
what is on your Google Cloud bill or what is in your Azure bill.

206
00:17:41,773 --> 00:17:51,901
And because that is the most tangible cost that is, you know, you have one bill, it has
one number down to the cent, you know, exactly where your costs come from and so on.

207
00:17:51,901 --> 00:17:57,625
So that makes these costs very tangible, but usually those are the least of your costs.

208
00:17:57,625 --> 00:17:59,576
Usually your most

209
00:17:59,576 --> 00:18:02,928
the most of where your costs come from are your engineers.

210
00:18:03,289 --> 00:18:10,693
They're usually much more expensive than your cloud provider bill or even the physical
hardware that you might have.

211
00:18:10,726 --> 00:18:17,078
I have this talk that I've held where I ask, is serverless a blatant cost trap?

212
00:18:17,078 --> 00:18:28,726
And obviously at first in this talk, also I focus on the cost of the infrastructure uh and
of the platform that you use and that you can save a couple of dollars there if you do it

213
00:18:28,726 --> 00:18:29,454
right.

214
00:18:29,454 --> 00:18:35,354
Like running a server constantly may cost you, I don't know, a hundred bucks a month or
something like that.

215
00:18:35,354 --> 00:18:39,774
And with serverless, you might get that down to five or zero bucks.

216
00:18:39,774 --> 00:18:51,274
But usually the real money that you save is when you make your engineers more productive
and when you have them spend their time on things that actually matter to their customers.

217
00:18:51,274 --> 00:18:57,974
Because when, like with my engineers, when they patch my operating system of the, or the
operating system of

218
00:18:57,974 --> 00:19:03,296
my server where my application runs, my customer isn't really going to directly notice
that.

219
00:19:03,296 --> 00:19:06,376
They're not going to directly care about that.

220
00:19:06,717 --> 00:19:16,869
Whereas if I have my application, the engineers or developers bust out new features or fix
bugs, that's what is going to generate real business value.

221
00:19:16,869 --> 00:19:19,600
That's what my customers are going to care about.

222
00:19:19,600 --> 00:19:26,472
So the more I can shift the focus of my engineers from doing infrastructure work that

223
00:19:26,666 --> 00:19:37,139
I could otherwise delegate to an infrastructure provider and get them to really do feature
development and stuff that is a bit more higher level that my customers care about, the

224
00:19:37,139 --> 00:19:46,326
more money I can save there because then I can use my engineers, my most expensive
resource, much, much more efficiently.

225
00:19:46,326 --> 00:19:55,858
What do you think when uh when you get customers on board and you're trying to sell them
on, you know what you can offer them is like cost the number one thing or are they coming

226
00:19:55,858 --> 00:20:01,353
to you with like performance concerns or with like unmanageability of what they currently
have?

227
00:20:01,353 --> 00:20:03,073
Where is like the biggest focus?

228
00:20:03,786 --> 00:20:06,749
It really depends on whom you talk to.

229
00:20:06,749 --> 00:20:10,352
So we usually have two ways of approaching our customers.

230
00:20:10,352 --> 00:20:19,239
It's either um we go through the technical folk that we meet at meetups, conferences, uh
stuff like that.

231
00:20:19,239 --> 00:20:26,045
And they're usually quite passionate about the technology, about optimizing performance
and all these things.

232
00:20:26,045 --> 00:20:32,152
uh And the other approach is obviously through the business side, through the decision
makers.

233
00:20:32,152 --> 00:20:40,524
that are not so easily found at a cloud native meetup or a Kubernetes conference or
something like that.

234
00:20:40,624 --> 00:20:46,676
And there, think for those people, the concerns are usually the ones that I mentioned
before.

235
00:20:46,676 --> 00:20:47,956
They are talking about cost.

236
00:20:47,956 --> 00:20:51,267
They are talking about how can we serve our customers more?

237
00:20:51,267 --> 00:20:57,649
How can we be more flexible in the market and turn out features more quickly and stuff
like that?

238
00:20:57,649 --> 00:21:01,600
But when you talk to the technical people, which I could also

239
00:21:01,600 --> 00:21:04,332
identify and relate a bit more to usually.

240
00:21:04,470 --> 00:21:06,975
So then I think it's a lot about passion also.

241
00:21:06,975 --> 00:21:15,161
These people are very passionate about what they built and they're very passionate about
this optimizing performance, these topics.

242
00:21:15,202 --> 00:21:26,161
They're passionate about the technologies that they use and you have to play your cards
really well if you want to convince them that new technologies, other technologies might

243
00:21:26,161 --> 00:21:29,600
be more efficient and might benefit them.

244
00:21:29,600 --> 00:21:33,912
not just their company, also them as people in the long term.

245
00:21:33,992 --> 00:21:45,537
And that's something I think that we usually forget that we're still talking to people who
have their own pride, they have their own passion, and they have their own fears also.

246
00:21:45,617 --> 00:21:51,620
They might even be afraid of new technologies because it might make them obsolete, or at
least they might be afraid of that.

247
00:21:51,620 --> 00:21:57,742
So I think, yeah, when we talk to the technical people, these are all things that we need
to take into account.

248
00:21:57,912 --> 00:21:59,783
think I'm going to misquote the year here.

249
00:21:59,783 --> 00:22:09,375
think AWS came out with like Lambda in 2014 or something, or at least that was the moment
when my team decided that it was the opportunity to actually investigate and there was no

250
00:22:09,375 --> 00:22:18,007
shortage of conversations, philosophical mostly, about how to actually utilize this
technology to use one Lambda per endpoint.

251
00:22:18,668 --> 00:22:19,928
How does the cost work?

252
00:22:19,928 --> 00:22:21,489
Is it actually viable for us?

253
00:22:21,489 --> 00:22:26,570
I think literally every conversation, what language do we use because we weren't running?

254
00:22:26,634 --> 00:22:32,917
in JavaScript at the time or Python, we were using C sharp and I don't think there was a
runtime for that.

255
00:22:32,917 --> 00:22:40,621
But when it did come out, it was like, it's the slowest next to Java, which was always,
it's like, well, it's not the slowest.

256
00:22:40,621 --> 00:22:42,242
So we could be doing worse.

257
00:22:42,242 --> 00:22:45,274
And I think there is a huge argument behind that.

258
00:22:45,274 --> 00:22:49,878
Like why not to use a particular technology because it doesn't match up well with.

259
00:22:49,878 --> 00:22:58,552
what you have going on as an organization and doesn't necessarily drive the conversation
to change what technology you're beholden to.

260
00:22:58,552 --> 00:23:02,464
So really, rather the question is can we use serverless?

261
00:23:02,464 --> 00:23:03,564
That's not the right question.

262
00:23:03,564 --> 00:23:08,606
The question is, what do we have to do in order to start using serverless?

263
00:23:08,606 --> 00:23:12,328
And then you're really asking the question, who do you want to be as a software engineer?

264
00:23:12,328 --> 00:23:17,526
And then people attach their identity to like, I'm going to...

265
00:23:17,526 --> 00:23:22,388
maybe make a little bit of a jest towards our last week's guest, who's a Haskell-er.

266
00:23:22,388 --> 00:23:24,129
I feel bad.

267
00:23:24,129 --> 00:23:26,280
Try to make Haskell run on Lambda.

268
00:23:26,280 --> 00:23:28,671
You're not in for a good time right now.

269
00:23:28,671 --> 00:23:31,792
Maybe in a couple years from now, you'll be in for a good time.

270
00:23:31,792 --> 00:23:33,893
But right now, it's a struggle.

271
00:23:33,893 --> 00:23:37,514
You try to use Java on Lambda up until a couple years ago.

272
00:23:37,514 --> 00:23:39,275
There was no snapshotting.

273
00:23:39,315 --> 00:23:40,996
Incredibly expensive to run.

274
00:23:40,996 --> 00:23:44,337
And maybe that's something we can get into a little bit.

275
00:23:44,337 --> 00:23:47,374
But I think there really is an aspect here where

276
00:23:47,374 --> 00:23:49,634
You have to convince the engineers.

277
00:23:50,054 --> 00:23:54,394
I guess, you know, my, my trauma is showing from, from, my past.

278
00:23:54,714 --> 00:23:56,634
Uh, and so maybe I want to ask you about this.

279
00:23:56,634 --> 00:24:02,234
When you, when you get in the weeds, are there any interesting stories that just like
immediately come into your mind?

280
00:24:02,234 --> 00:24:04,874
I know you keep bringing up the cost and the level of abstraction.

281
00:24:04,874 --> 00:24:13,894
Do you, were there like stories of training or stories of, I mean, you sort of looked in
the distance, so maybe there is something that particularly came to mind.

282
00:24:14,246 --> 00:24:15,287
Got me.

283
00:24:15,327 --> 00:24:25,236
Yeah, there is a so there is one back when when we were still um talking about the
transition from, you traditional VMs to servers.

284
00:24:25,236 --> 00:24:33,842
There was one when we when we talked to a customer and tried to pitch this idea of using
Kubernetes and containers to them.

285
00:24:33,983 --> 00:24:38,847
And we tried to explain to them what are the benefits of having these immutable images.

286
00:24:38,847 --> 00:24:41,519
And the person was really not happy about hearing all of this.

287
00:24:41,519 --> 00:24:42,668
And they were like,

288
00:24:42,668 --> 00:24:47,111
You know, I just want a container that I can SSH into and install my stuff.

289
00:24:47,111 --> 00:24:48,782
So how could I get this?

290
00:24:48,922 --> 00:24:56,367
And we were like, okay, we have to take a step back and start a bit earlier and explain
that to them again.

291
00:24:56,367 --> 00:25:09,336
uh And that then led to a very interesting conversation because a lot of the learnings um
that we apply in the container world or even the serverless world, uh like this immutable

292
00:25:09,336 --> 00:25:11,968
images and immutable infrastructure thought.

293
00:25:12,002 --> 00:25:14,964
we can actually also apply to VMs.

294
00:25:14,964 --> 00:25:19,586
So that's sometimes how you can get people on board and how we did it back then.

295
00:25:19,586 --> 00:25:31,473
So we used, back then I think it was Packer and Ansible to create an immutable
infrastructure, sorry, an immutable image that we could then use on VMs.

296
00:25:31,473 --> 00:25:39,928
And we could sort of, that would help the transition with this person because they could
still use their beloved VMs, but they would see what benefits um

297
00:25:39,928 --> 00:25:48,092
this immutable image would bring to them and it would introduce to them very slowly this
new way of deploying and this new way of working.

298
00:25:48,233 --> 00:25:53,390
And then to take the step from there to containers was a much smaller one.

299
00:25:53,390 --> 00:25:58,650
and you have to show them the pain of their current setup and then they'll easily
transition.

300
00:25:58,790 --> 00:26:02,590
I feel like it's the, well, you don't have to manage infrastructure.

301
00:26:02,590 --> 00:26:04,710
You don't have to configure these things.

302
00:26:04,710 --> 00:26:06,310
You don't have to worry about it.

303
00:26:06,310 --> 00:26:12,510
Logs, they just show up automatically in a third party service or interface that you can
just go to and they're all right there.

304
00:26:12,510 --> 00:26:17,510
You don't need to configure any sort of interaction layer, any sort of logging driver,
anything like that.

305
00:26:17,510 --> 00:26:18,910
And I'm like, oh, but I want that.

306
00:26:18,910 --> 00:26:23,354
And then you go and ask them, okay, I need you to list out to me all the pains that you're
having.

307
00:26:23,354 --> 00:26:26,035
Well, getting logging working is a real challenge.

308
00:26:26,035 --> 00:26:32,986
Sometimes the container crashes and I don't, the VM crashes, I don't know what's going on
or a times out or the CPU usage is too high.

309
00:26:33,036 --> 00:26:42,628
we have to deploy these side cars to, know, or agents onto the machine that keep track of
all of the metrics and then understanding like what to alert on and if the alerts are good

310
00:26:42,628 --> 00:26:44,798
and then, and then patching it is terrible.

311
00:26:44,798 --> 00:26:50,770
And I'm like, how can you say no to serverless and then say at the same time, you hate all
these other things?

312
00:26:50,770 --> 00:26:52,640
Like it does not compute.

313
00:26:53,791 --> 00:26:57,835
Yes, it's all about the why in the end.

314
00:26:57,835 --> 00:27:07,503
You need to convince people of why they're doing this switch and not just how they will do
it or what the switch will consist of and what are the different steps to get there.

315
00:27:07,503 --> 00:27:09,885
It's like, why do we do this switch?

316
00:27:09,885 --> 00:27:15,660
What are the benefits that your company but also you as a person will get from this?

317
00:27:15,862 --> 00:27:25,085
I remember, uh this was a long time ago actually, I was working at a company on a team
that, it was called Integration, but now I'm sure it would be called Platform Engineering

318
00:27:25,085 --> 00:27:26,385
or some other mistake name.

319
00:27:26,385 --> 00:27:34,447
ah And we were sort of in charge of the infrastructure for all the environments, including
production.

320
00:27:34,447 --> 00:27:43,362
Interesting story though, in production we weren't allowed to actually SSH in, although of
course since we were using Microsoft, at the time it wasn't SSH, was some...

321
00:27:43,362 --> 00:27:46,264
PowerShell derivative to actually get onto the machines.

322
00:27:46,264 --> 00:27:54,608
And we needed to get access to deploy a piece of architecture that would allow automatic
deployments in the future with the new technology we're rolling out.

323
00:27:54,608 --> 00:27:56,889
And there were like hundreds of machines.

324
00:27:57,230 --> 00:28:05,094
And it was a very simple thing we needed to do, basically install, like run this one
script for each of these places that the script has been really well tested.

325
00:28:05,275 --> 00:28:11,542
Of course, there are machines that are not exactly configured the same, even though
they're supposed to be exactly.

326
00:28:11,542 --> 00:28:14,824
It's like the almost exactly is the real struggle there.

327
00:28:14,824 --> 00:28:22,240
Especially on Windows machines where there's like some C++ redistributable or the .NET
installed version.

328
00:28:22,240 --> 00:28:28,314
Like it's supposed to be four, four five or whatever, but for whatever reason, it doesn't
have an old version of something on it.

329
00:28:28,314 --> 00:28:31,857
And one of the engineers on our team said, I'll take that activity.

330
00:28:31,857 --> 00:28:34,538
Now this was before LLMs.

331
00:28:34,538 --> 00:28:36,130
we didn't, I don't know how that would have helped.

332
00:28:36,130 --> 00:28:39,542
Maybe someone can jump up and down and say, they could figure it out.

333
00:28:40,000 --> 00:28:48,133
Literally went in and connected manually to each of the hundreds of machines there were
and ran the script one by one for each of them and that's what he did the whole day and I

334
00:28:48,133 --> 00:28:58,708
didn't find out to the end of the day that this was done and I'm just like Mind blown like
at what point did it feel like this was the right thing to do ever like if there was five

335
00:28:58,708 --> 00:29:08,662
Maybe I'd get it but like literally sent the whole day I'm like this could have been like
a for loop that that's it like nothing more complicated than that to run it

336
00:29:08,662 --> 00:29:10,405
He enjoyed it, thought it was the right thing.

337
00:29:10,405 --> 00:29:20,842
So I think it really says that there is this aspect of mindset that really goes into the
type of engine that expects that there's a certain flow that still works.

338
00:29:21,080 --> 00:29:31,334
Yeah, I love that you said he enjoyed it because I think that again comes back to this
that you also need to take the human into the equation, right?

339
00:29:31,334 --> 00:29:35,696
I think that's also a big uh topic when it comes to LLMs these days.

340
00:29:35,696 --> 00:29:43,479
Because these LLMs can make us so much more efficient when we're doing engineering, we can
turn out much more code very quickly.

341
00:29:43,599 --> 00:29:50,382
But I think LLMs can also take the joy and a bit of the relaxation that we get sometimes
out of writing code.

342
00:29:50,414 --> 00:30:00,699
ah Like, at least for me, doing the conceptual work, doing the meetings to get to the
architecture and so on, this is very interesting, but it's also quite challenging.

343
00:30:00,699 --> 00:30:11,544
And to me, like 10 years ago, there was a very good balance between this and then the
actual writing code, which controversial opinion can actually be quite dumb, quite a dumb

344
00:30:11,544 --> 00:30:12,784
job to do.

345
00:30:12,884 --> 00:30:17,006
Because if you have very clearly specified requirements.

346
00:30:17,006 --> 00:30:20,528
then writing those down into code is pretty straightforward.

347
00:30:20,528 --> 00:30:23,070
That's why LLMs are quite good at this, right?

348
00:30:23,070 --> 00:30:35,727
And if LLMs now take away this part of the work that we used to use m for more relaxing,
for more dumb work where we can turn our heads off, where we can get into the zone and get

349
00:30:35,727 --> 00:30:43,414
tunnel vision and just implement the feature, I think this can be quite challenging for
people, including me, um that you now...

350
00:30:43,414 --> 00:30:55,351
Your work nowadays consists of much more of the conceptual work and of the work where you
really have to actively turn your brain on and you don't get so much of this more

351
00:30:55,351 --> 00:30:56,802
rewarding work.

352
00:30:57,322 --> 00:31:04,547
And I guess this person who ran the script hundreds of times, they had the same feeling
with every VM or every machine they did.

353
00:31:04,547 --> 00:31:10,810
They got another uh reward in their brain and they had another success for themselves.

354
00:31:10,944 --> 00:31:14,222
Yeah, I think this shouldn't be underestimated sometimes.

355
00:31:14,222 --> 00:31:28,302
So it's an interesting perspective that the meaningless, I don't want to say that, menial
tasks of software development are actually required for stimulating us or giving us the

356
00:31:28,302 --> 00:31:32,802
freedom to continue to think about the challenging architecture or conceptual ones.

357
00:31:33,110 --> 00:31:35,494
Even for our mental sanity, I would say.

358
00:31:37,551 --> 00:31:48,432
So one of the points of mental sanity that I think you probably secretly hoped I wouldn't
ask about but can't be left out of the episode is all of the challenges for why serverless

359
00:31:48,432 --> 00:31:53,827
can't be used and that falls into the dreaded category of performance also known as cold
starts.

360
00:31:53,827 --> 00:31:57,290
So what are your perspectives there?

361
00:31:57,390 --> 00:32:04,990
So if cold starts are a problem for your application, then function as a service is
obviously not the solution for you.

362
00:32:04,990 --> 00:32:07,690
The solution can still be serverless.

363
00:32:08,450 --> 00:32:20,290
So that comes back down to this, what I mentioned initially that, and during our
conversation, even us, fell into this trap of we talked about serverless, or sorry, we

364
00:32:20,290 --> 00:32:25,210
talked about function as a service, but we always just used the word serverless.

365
00:32:25,794 --> 00:32:30,527
I think even if you have a problem with Cold Start, serverless can still be a good
solution.

366
00:32:30,527 --> 00:32:34,959
You can still use a serverless container platform or stuff like that.

367
00:32:34,959 --> 00:32:39,682
But obviously Cold Starts are very real and they're a very important thing to consider.

368
00:32:39,682 --> 00:32:48,556
There are ways of optimizing them depending on the CPU architecture that you use,
depending on the programming language, the framework that you use, depending on how you

369
00:32:48,556 --> 00:32:50,227
set up your application.

370
00:32:50,227 --> 00:32:55,650
And usually if you want to use function as a service, it's good if you take a stack

371
00:32:55,650 --> 00:33:06,755
back and think about how you can make your architecture more um event-based, maybe even
more asynchronous, so that the cold starts aren't that much of a problem for you anymore.

372
00:33:06,755 --> 00:33:13,818
And if that's something that you are not willing to do or that is not efficient for you to
do, then choose something else, by all means.

373
00:33:14,094 --> 00:33:21,434
I think that the challenge there is people coming on board saying, oh, I have to
completely rethink how we design technology.

374
00:33:21,434 --> 00:33:32,294
And I want to be in the space where I'm fully in control of these levers that I have been
in control of the whole time, where now I have to actually take into account this critical

375
00:33:32,294 --> 00:33:33,274
potential problem.

376
00:33:33,274 --> 00:33:39,314
But on the flip side, I really like the perspective because I think honestly, most of the
time it is totally the truth.

377
00:33:39,314 --> 00:33:40,972
Whereas it

378
00:33:40,972 --> 00:33:47,886
likely has a meaningless impact on the whole architecture if redesigned with that
constraint in mind.

379
00:33:47,886 --> 00:33:59,373
There are ways, as you put it, if I just think about AWS, there's both provision and uh
manage capacity options, uh pre-purchase, et cetera, as well as ways of maintaining warm

380
00:33:59,373 --> 00:34:00,294
containers.

381
00:34:00,294 --> 00:34:07,822
And so even in performance critical applications, there's ways of getting around that,
even without doing anything extra.

382
00:34:07,822 --> 00:34:14,502
And then on top of that, can of course reduce that by doing little unnecessary or complex
tricks.

383
00:34:14,502 --> 00:34:24,282
I've seen some out there like Lambda automatic warmers that come in and call your API
unnecessarily to make sure that you don't have any containers down and they do it every 15

384
00:34:24,282 --> 00:34:29,342
minutes or so, so that the container will always be warm, but not cost you as much.

385
00:34:29,402 --> 00:34:32,822
you know, honestly, and it still comes out to be cheaper than the alternative.

386
00:34:32,822 --> 00:34:34,722
I don't know if it's a good idea because

387
00:34:34,722 --> 00:34:43,828
You're increasing the complexity, is something that you sort of promised to eliminate and
you brought up cost, the total cost of ownership that is, uh with managing a solution.

388
00:34:43,828 --> 00:34:52,237
By throwing these complex things in, you're sort of defeating the whole value that was
offered there in the original hypothesis of switching.

389
00:34:52,237 --> 00:34:54,937
Yeah, summarized it so well.

390
00:34:54,937 --> 00:35:04,417
think usually these workarounds, they come down to ego or to passion, which sometimes go
along.

391
00:35:04,617 --> 00:35:15,537
But yeah, I think they come from this passion that we have to really optimize for
performance and for costs and really bring down the cloud provider bill that I will see at

392
00:35:15,537 --> 00:35:16,797
the end of the month.

393
00:35:17,117 --> 00:35:21,548
But the actual costs that I have to spend

394
00:35:21,548 --> 00:35:28,950
more time of my engineers or that my users will have a worse experience, they're usually
not worth these workarounds.

395
00:35:29,972 --> 00:35:38,880
I think I'm going to short circuit what you say and totally take it out of context and
interpret it as passion is the root cause of all incorrect architecture decisions.

396
00:35:41,716 --> 00:35:44,217
I think it actually is in many cases.

397
00:35:44,721 --> 00:35:45,583
No.

398
00:35:47,479 --> 00:35:50,080
I mean, there is something to be said there.

399
00:35:50,080 --> 00:35:55,924
I think, you know, once you start the ball going down one path, it's hard to really look
anywhere else.

400
00:35:55,924 --> 00:36:04,389
It's sort of this tunnel vision in one perspective, and then you attach an emotional
aspect to it as well that you want to keep that decision.

401
00:36:04,389 --> 00:36:12,110
And then maybe coupled with another aspect of aligning your self-identity with whatever
that is, like if you're a...

402
00:36:12,110 --> 00:36:21,770
Microsoft MVP or AWS hero and now you're looking at this at particular angle and you're
like, well, I don't want to switch clouds or I want to use the technology that's

403
00:36:21,770 --> 00:36:22,130
available.

404
00:36:22,130 --> 00:36:23,790
I don't want to switch this other thing.

405
00:36:23,790 --> 00:36:27,790
Or if you're some expert in some, I'll say legacy technology.

406
00:36:28,250 --> 00:36:36,850
The goal, the idea of switching away from that to something that may be better suited is
sort of an attack on how you envision yourself.

407
00:36:36,910 --> 00:36:39,890
I do see a lot of engineers.

408
00:36:40,226 --> 00:36:46,168
have this challenge, feel like, when I talk to them about serverless, they feel like, no,
it could never work.

409
00:36:46,208 --> 00:36:48,158
And part of it, I think, is their own definition of it.

410
00:36:48,158 --> 00:36:50,239
And so I like how you broadened it in this conversation.

411
00:36:50,239 --> 00:37:00,732
Like, I wouldn't normally have looped, say, containers, like direct containers, things
that match the OCI protocol or Kubernetes pods into serverless initially.

412
00:37:00,732 --> 00:37:02,313
I wouldn't have normally included them there.

413
00:37:02,313 --> 00:37:06,796
But if you throw that into the definition and you separate it from functions as a service,

414
00:37:06,796 --> 00:37:17,463
I feel like in a way you are tricking people into believing that they've been on
serverless all along and now switching from one platform to another platform is an easier

415
00:37:17,463 --> 00:37:18,585
said activity.

416
00:37:18,585 --> 00:37:19,288
um

417
00:37:19,288 --> 00:37:28,335
Yeah, then they don't need to rethink what they have been doing for years and, as you
said, re-identify their identity.

418
00:37:28,335 --> 00:37:32,566
oh

419
00:37:32,566 --> 00:37:37,790
Yeah, it does seem like the biggest concern is from a fundamental lack of understanding.

420
00:37:37,790 --> 00:37:46,666
One of the areas that I think has still a huge opportunity for improvement over time and
maybe you have a perspective on this is historically, I used to say that there are certain

421
00:37:46,666 --> 00:37:50,539
technologies that are way better for using to do certain things.

422
00:37:50,559 --> 00:37:59,986
And the arguments that I had say even against Kubernetes early on compared to functions as
a service or some other extreme aspects of serverless was

423
00:38:00,108 --> 00:38:06,942
whether or not you needed access to GPU, better control over the uh infrastructure that
you're actually getting under the hood.

424
00:38:06,942 --> 00:38:13,516
Like if you're deploying on virtual machines proper or even bare metal, you had additional
capabilities.

425
00:38:13,516 --> 00:38:26,173
But I think that over time, we are actually seeing a migration in the hyperscalers and
other cloud providers offering the same configuration and same complexity to functions as

426
00:38:26,173 --> 00:38:28,598
a service, to all aspects of serverless.

427
00:38:28,598 --> 00:38:30,930
that sort of defeat any sort of justification.

428
00:38:30,930 --> 00:38:38,887
And so when I look at posts from on the internet, we moved back to bare metal and
everything is cheaper because we can manage it so much better.

429
00:38:38,887 --> 00:38:50,296
I think to myself, they moved away from serverless today based off of what serverless
offered, but they didn't account for the fact that serverless is a migrating concept and

430
00:38:50,296 --> 00:38:56,561
that it will grow in understanding and complexity to match the interface that is best
optimal for the consumers.

431
00:38:56,561 --> 00:38:57,398
uh

432
00:38:57,398 --> 00:38:59,700
software developer experience, if you will.

433
00:38:59,780 --> 00:39:08,919
And as that changes, you may get more and more access to exactly the interface that is
optimal without having to worry about all the complexities that come with why you migrated

434
00:39:08,919 --> 00:39:11,851
off of bare metal or virtual machines in the first place.

435
00:39:11,851 --> 00:39:12,372
I don't know.

436
00:39:12,372 --> 00:39:19,678
Maybe this is just my own just rant in the area, very short-sighted that I just can't get
out of my head though.

437
00:39:20,870 --> 00:39:26,642
Yeah, but I think there's something that we see quite a lot these days that people go
back.

438
00:39:26,642 --> 00:39:33,814
We see all these blog posts of people going back to the good old days and when they used
to just have that one server.

439
00:39:33,814 --> 00:39:45,477
And I think there was recently a post on Hacker News where somebody hosted multiple of
their startups on just one server each with a SQLite database and uh probably one

440
00:39:45,477 --> 00:39:48,288
container or even just a systemd service.

441
00:39:49,024 --> 00:40:03,518
And, and yeah, I think it also again comes back to us being human and that it's, it can be
something that is also much more fun to play with because you have more control and then

442
00:40:03,518 --> 00:40:13,961
it allows you to, to then, you know, delve into topics like even Linux and how you set up
a proper firewall on Linux and stuff like that, which actually I also miss doing

443
00:40:13,961 --> 00:40:19,054
sometimes, like I'm running Linux on my own laptop because that's where I actually get to.

444
00:40:19,054 --> 00:40:22,598
play around with it and use it and dive deep into it.

445
00:40:22,598 --> 00:40:32,229
Whereas if I'm just setting up um Linux on a container or even using function as a
service, then it's all abstracted away from me.

446
00:40:33,031 --> 00:40:39,798
I also do like this idea of going back to the roots and actually learning again about
those topics.

447
00:40:40,044 --> 00:40:48,160
You know, there are some aspects that I really want to agree with and then there are other
ones where it's just like Linux is the worst operating system except for all the other

448
00:40:48,160 --> 00:40:48,480
ones.

449
00:40:48,480 --> 00:40:54,204
ah I get so scared.

450
00:40:54,204 --> 00:41:02,890
So I don't like do a super lot of software development on my machine, but it's like for
the podcast, I released the website and the episodes.

451
00:41:02,962 --> 00:41:09,444
and there's some automation involved and I'm installing some packages and every day I'm
just like, I got to run some package manager.

452
00:41:09,444 --> 00:41:13,065
There's going to be some vulnerability like that's in there.

453
00:41:13,065 --> 00:41:23,348
Like it's just a number of days until I have some malware on my machine and I'm trying
really hard not to, but I am just scared that that is just an inevitability in so many

454
00:41:23,348 --> 00:41:24,128
ways.

455
00:41:24,128 --> 00:41:26,468
And I, when I can, I'm just like, you know what?

456
00:41:26,468 --> 00:41:32,838
I prefer just to push this directly to production, not think about it, not install
anything and it will just work.

457
00:41:32,838 --> 00:41:34,569
And if it doesn't, the build will fail.

458
00:41:34,569 --> 00:41:35,739
It will tell me about it.

459
00:41:35,739 --> 00:41:36,389
Stuff will run.

460
00:41:36,389 --> 00:41:37,379
There's no patches.

461
00:41:37,379 --> 00:41:39,100
There's no weird stuff.

462
00:41:39,280 --> 00:41:42,721
And I don't have to be scared of my operating system.

463
00:41:42,721 --> 00:41:44,332
And then the here's like, no, I love this.

464
00:41:44,332 --> 00:41:45,492
This is my favorite part.

465
00:41:45,492 --> 00:41:51,361
love, I love being afraid of like what malicious services are running on my machine and
connecting to the internet.

466
00:41:51,361 --> 00:41:58,586
And you have like a wire guard up or like a peer guardian or something that's like
monitoring every single IPv4 and IPv6.

467
00:41:58,700 --> 00:42:00,663
you know, connection that's being created.

468
00:42:00,663 --> 00:42:02,175
Be like, I know what that is.

469
00:42:02,175 --> 00:42:02,696
That's fine.

470
00:42:02,696 --> 00:42:03,948
That one, that's not okay.

471
00:42:03,948 --> 00:42:06,361
And I just can't imagine managing that.

472
00:42:07,971 --> 00:42:09,281
Yeah, I get that totally.

473
00:42:09,281 --> 00:42:15,155
And I think it's also, you know, a bit of a world of unicorns and rainbows sometimes.

474
00:42:15,155 --> 00:42:26,291
Because, you know, when I talk about my personal laptop, for example, or my home lab that
I have running at home on my Raspberry Pi, if stuff goes bad there, sometimes, you know,

475
00:42:26,291 --> 00:42:29,222
it's just my spouse who's angry about it.

476
00:42:29,222 --> 00:42:35,646
But if stuff goes bad at my company in production, then I need to actually get up at 2am
and fix that stuff.

477
00:42:35,646 --> 00:42:36,674
And I think

478
00:42:36,674 --> 00:42:44,034
There, very quickly, will start to then not have so much fun anymore with playing with all
these little things.

479
00:42:44,034 --> 00:42:52,534
So there are also different use cases and different worlds where one can be fun and the
other one not so much.

480
00:42:53,062 --> 00:43:03,948
There's definitely the Daniel Pink drive where he talks about motivation 3.0 of if you pay
someone to do an activity, it has an opportunity to steal the enjoyment you get away from

481
00:43:03,948 --> 00:43:04,208
that.

482
00:43:04,208 --> 00:43:13,523
But there is definitely the, if there's stress associated with the thing that you're
doing, then that also has the opportunity to steal your enjoyment and motivation away from

483
00:43:13,523 --> 00:43:14,033
it.

484
00:43:14,033 --> 00:43:15,173
So I have to ask.

485
00:43:15,173 --> 00:43:16,774
uh

486
00:43:16,832 --> 00:43:25,566
As a consultant, you get to have unique opinions uh on cloud providers, given you work
with different customers, and you have seen some complex setups that probably go quite

487
00:43:25,566 --> 00:43:26,187
wrong with them.

488
00:43:26,187 --> 00:43:37,912
Do you have anything that particularly comes to mind when, if you get a preference of
where to build, do you like cloud functions, Lambda, Kubernetes in AWS, Cloudflare

489
00:43:37,912 --> 00:43:38,403
workers?

490
00:43:38,403 --> 00:43:41,844
Do you have like, you know, this is the thing that you like the most?

491
00:43:42,008 --> 00:43:45,860
So one of my favorite setups is actually based on Lambda.

492
00:43:45,861 --> 00:43:58,309
And I really like, I think for almost every programming language that is supported by AWS
Lambda is there is a uh kind of a shim or framework that allows you to just build a

493
00:43:58,309 --> 00:44:08,507
regular web app, like be that an express app when you're using uh TypeScript or just a
regular Go HTTP server or whatever.

494
00:44:08,507 --> 00:44:10,828
And it just allows you to add

495
00:44:10,840 --> 00:44:22,718
couple of lines of code to then wrap this initial web server that you have created and run
this web server exactly as is in AWS Lambda, or I think it also exists for other function

496
00:44:22,718 --> 00:44:24,180
as a service platforms.

497
00:44:24,180 --> 00:44:33,646
And I really love this setup because you get all of the advantages of being able to
develop it locally on your computer with the tools that you use and love.

498
00:44:33,646 --> 00:44:39,438
You can start your server with one command and you don't need anything, you know, like
local stack or something like that.

499
00:44:39,438 --> 00:44:41,578
to run your application.

500
00:44:41,698 --> 00:44:44,978
But then you can, with one command, deploy it to the cloud.

501
00:44:44,978 --> 00:44:52,598
You have all of the benefits of Function as a Service, like integrated tracing and
integrated tooling and all these things.

502
00:44:52,598 --> 00:44:57,778
You have the cost benefits that you see on your cloud bill at the end of the month.

503
00:44:57,958 --> 00:45:02,398
You have the almost infinite scale and all of these good things.

504
00:45:02,398 --> 00:45:07,218
So for me, this is sort of the best of both worlds that I have seen.

505
00:45:07,218 --> 00:45:08,738
And I love the setup.

506
00:45:08,770 --> 00:45:20,298
And it also really easily allows you to do what we discussed earlier, that you build this
initial monolith of a web application initially, and then you break out parts of it uh

507
00:45:20,298 --> 00:45:21,398
later on.

508
00:45:21,542 --> 00:45:24,794
She's really the official spokesperson for serverless.

509
00:45:24,794 --> 00:45:31,748
You nailed down all of the benefits and eliminated all of the negative possible concerns
there.

510
00:45:31,748 --> 00:45:35,511
I think one thing we didn't really talk about was the improved developer experience.

511
00:45:35,511 --> 00:45:41,074
I mean, I know there's the whole management cost, the total cost of ownership I think we
did get into.

512
00:45:41,074 --> 00:45:47,438
But I think there is a really interesting thing here where one of the huge pushbacks that
I have seen in the serverless space

513
00:45:47,438 --> 00:45:51,398
is people saying, oh, it's too difficult to spin up a service.

514
00:45:51,398 --> 00:45:54,498
I need to use some bloated extra technology to run.

515
00:45:54,498 --> 00:46:05,298
And I always am super confused there because all you need to do is literally start this
application as you would any other process on your machine, as if you hit like F5 or seven

516
00:46:05,298 --> 00:46:08,158
or whatever your keyboard shortcut is to run.

517
00:46:08,158 --> 00:46:16,440
And I don't know if it's a disconnect that I'm not seeing or whether or not it's just like
not putting the pieces together that it's really just so easy.

518
00:46:16,440 --> 00:46:19,155
to run serverless technologies locally.

519
00:46:19,372 --> 00:46:27,378
Yeah, I think it's also a bit connected to usually when you change something in your
application, then you don't just do serverless, right?

520
00:46:27,378 --> 00:46:37,777
When you're changing things, then you're changing probably more things than just um
putting, taking your application as is and putting it into, onto a serverless platform.

521
00:46:37,837 --> 00:46:48,165
And I think it's usually this complexity that comes with all of the things that you're
trying to optimize and to change in one step um that can then be quite overwhelming.

522
00:46:48,760 --> 00:46:58,628
Because then at the same time, maybe you're also uh trying to uh use uh infrastructure as
code or a serverless framework to deploy your stuff.

523
00:46:58,628 --> 00:47:01,861
And then you're also trying to use a serverless database at the same time.

524
00:47:01,861 --> 00:47:03,543
And then how do you use that locally?

525
00:47:03,543 --> 00:47:15,913
And I think it's usually the complexity of trying to overdo with the optimizations and
trying to do many things at once uh that creates this illusion.

526
00:47:15,913 --> 00:47:17,206
uh

527
00:47:17,206 --> 00:47:26,213
Did you ever run into this yourself with uh trying to do some development with a third
party repository or another service that had a ridiculous setup like that?

528
00:47:26,514 --> 00:47:28,696
yeah, even my own stuff.

529
00:47:28,696 --> 00:47:31,759
Like I've definitely fallen into that trap.

530
00:47:31,759 --> 00:47:43,089
uh Yeah, it again probably comes down to passion because then we get passionate about it.

531
00:47:43,089 --> 00:47:44,501
We want to optimize many things.

532
00:47:44,501 --> 00:47:52,317
We want to do the best thing that we can and we could sometimes fall into that trap and
I've fallen into it many times.

533
00:47:53,420 --> 00:47:55,049
How did you pull yourself out?

534
00:47:55,054 --> 00:47:56,795
ah Sometimes I didn't.

535
00:47:56,795 --> 00:48:02,259
uh I worked with what I had because it was already too late.

536
00:48:02,259 --> 00:48:10,666
uh And sometimes it makes sense to take this step back and just start, like we said
before, start with the why.

537
00:48:10,666 --> 00:48:11,997
What am I trying to achieve?

538
00:48:11,997 --> 00:48:14,068
What problems am I trying to solve?

539
00:48:14,068 --> 00:48:22,122
And are actually some of the things that I'm now trying to add or change not contributing
to this initial goal that I've set myself.

540
00:48:22,122 --> 00:48:24,636
So with that, let's switch over to PIX.

541
00:48:24,636 --> 00:48:26,985
So, Laino, what did you bring for us today?

542
00:48:27,576 --> 00:48:31,099
So I already told you that I have two picks and I would decide on the spot.

543
00:48:31,099 --> 00:48:34,851
So I'm going to do that and I'm going to decide for Home Assistant.

544
00:48:34,851 --> 00:48:39,835
ah don't know if you know it, it's a huge open source project.

545
00:48:39,835 --> 00:48:43,237
think one of the most active ones on GitHub.

546
00:48:43,398 --> 00:48:50,944
And it allows you to create home automations, but with everything being open source and
open standards.

547
00:48:50,944 --> 00:48:54,466
And it's one of the projects that I have been really, really passionate about.

548
00:48:54,964 --> 00:49:01,096
lately to work with and to set everything up in my Unicurrents and Rainbows world at home.

549
00:49:01,096 --> 00:49:11,123
I now I'm drawing the connection for something you said earlier about your spouse getting
annoyed when your home lab is having an incident when you couple them together with Home

550
00:49:11,123 --> 00:49:12,134
Assistant.

551
00:49:12,134 --> 00:49:15,986
Good catch.

552
00:49:15,986 --> 00:49:17,196
That's my fear too.

553
00:49:17,196 --> 00:49:24,502
When you have the robots in control, you need that manual override that's uh so many times
joked about in science fiction.

554
00:49:24,502 --> 00:49:32,418
popular culture about needing to open the door when your power or your server is offline
there.

555
00:49:32,418 --> 00:49:38,120
Yeah, there's even this term in the home automation community called the spouse approval
factor.

556
00:49:38,481 --> 00:49:47,745
It's quite an important part about any kind of automation that you do that you could do it
just for fun, but still it's going to affect everybody who lives with you.

557
00:49:47,745 --> 00:49:55,849
And uh they're going to still need to able to live in your home without big downsides of
your hobby.

558
00:49:57,708 --> 00:50:02,076
Are you limited in what you're allowed to sort of edit or have control over?

559
00:50:02,076 --> 00:50:08,608
you know, it's like first you do the prototype and then get sign off and, you know,
forgiveness later.

560
00:50:08,986 --> 00:50:16,479
No, my wife is luckily very um forgiving, but she expects me to fix stuff over time if I
fuck up.

561
00:50:18,814 --> 00:50:21,583
Do you have like internal SLAs?

562
00:50:21,686 --> 00:50:22,448
Yeah, exactly.

563
00:50:22,448 --> 00:50:25,638
oh

564
00:50:26,587 --> 00:50:28,768
I don't know if we should bring spouses into the episode.

565
00:50:28,768 --> 00:50:37,933
just you I already fear like if I was gonna do this like I would like there's how I feel
about our production services that we have that we already promised like ridiculous

566
00:50:37,933 --> 00:50:47,958
numbers of uh SLAs and uptime and I feel like I'd be stressing even more that like I come
back from vacation and something like the lights aren't gonna be working.

567
00:50:49,754 --> 00:50:51,631
yeah, that's a horror scenario.

568
00:50:52,990 --> 00:51:04,730
I don't know what would be worse, You know what, think I'm just, every time someone tries
to get me to go down the home lab route, I just carefully be like, you know what, I'm good

569
00:51:04,730 --> 00:51:06,982
with the amount of stress in my life.

570
00:51:08,715 --> 00:51:22,999
I think it's so I started out um not with the intention of optimizing my life or doing
anything good for us that will make living in our flat easier, but just to have fun.

571
00:51:22,999 --> 00:51:25,649
And I think that's the right approach.

572
00:51:25,649 --> 00:51:29,060
then over time, hopefully you will grow into creating useful stuff.

573
00:51:29,060 --> 00:51:34,879
But I think you shouldn't start out with that expectation towards yourself.

574
00:51:34,879 --> 00:51:39,206
Yeah, don't do it with the whole goal of to replicate something you saw on the internet.

575
00:51:39,206 --> 00:51:46,848
Is there one aspect of the Home Assistant that you feel like you can no longer live
without, like the most valuable thing that you've implemented?

576
00:51:47,354 --> 00:51:52,638
So we have a go to sleep routine, which I quite love.

577
00:51:52,819 --> 00:52:02,187
it's so in the evening when I put my phone onto the charging pad, then it monitors the
areas where we have our bathroom and bedroom.

578
00:52:02,307 --> 00:52:08,583
And um as soon as there is no more movement, then it really turns kind of turns off the
whole apartment.

579
00:52:08,583 --> 00:52:11,094
So it shuts down all the lights.

580
00:52:11,195 --> 00:52:14,838
It removes the power from our office area.

581
00:52:14,990 --> 00:52:21,657
It turns off the digital clock displays on the wall, turns off all the speakers and stuff.

582
00:52:21,657 --> 00:52:23,288
And that is just so convenient.

583
00:52:23,288 --> 00:52:30,565
And it also gives me this mental peace that it's not just me who sleeps now, it's my whole
apartment and my whole life, kind of.

584
00:52:32,088 --> 00:52:32,709
okay.

585
00:52:32,709 --> 00:52:37,061
it's also like environmental impact there, like reduction, energy usage.

586
00:52:37,082 --> 00:52:43,214
How do the digital clocks on the wall uh maintain their time for coming back after the
wake up?

587
00:52:43,214 --> 00:52:46,299
So the clocks don't turn off, it's just a display that...

588
00:52:46,299 --> 00:52:49,630
I say, you've got like special clocks done.

589
00:52:49,630 --> 00:52:56,416
Yeah, it's actually a very cool project called Autrix that you can find on GitHub, which
is also open source.

590
00:52:56,416 --> 00:53:05,742
And it's just an additional display that is made up of big pixels, so it looks quite nerdy
and you can basically display whatever you want.

591
00:53:05,743 --> 00:53:13,298
It also displays a welcome message whenever my wife or I come home, or it shows a message
when we need to walk the dog and stuff like that.

592
00:53:13,298 --> 00:53:16,070
So really cool project to look at.

593
00:53:16,711 --> 00:53:17,832
I like it.

594
00:53:17,993 --> 00:53:24,060
I still have this goal of like going on vacation and having all my plants water
themselves, but I haven't found the...

595
00:53:24,060 --> 00:53:30,086
It's too much stress or motivation to get to that point to actually build what I need to
make that actually happen.

596
00:53:30,318 --> 00:53:32,858
Yeah, the plans are quite a big endeavor.

597
00:53:32,858 --> 00:53:34,418
I haven't gone there yet.

598
00:53:35,038 --> 00:53:36,099
That's my number one.

599
00:53:36,099 --> 00:53:40,221
Okay, so my pick, I think I just was gonna be lame this week.

600
00:53:40,221 --> 00:53:42,382
uh I don't drink coffee at all.

601
00:53:42,382 --> 00:53:43,533
I don't know what it is.

602
00:53:43,533 --> 00:53:44,644
I just never love it.

603
00:53:44,644 --> 00:53:53,429
uh I have this open challenge for anyone who I'm in a room with to serve me or get me to
try the best coffee they think is in the entire world.

604
00:53:53,429 --> 00:53:57,771
And so I am now a coffee aficionado who hates coffee.

605
00:53:57,771 --> 00:54:00,733
And that's just to know about me.

606
00:54:00,733 --> 00:54:02,744
ah I hate it, just don't like it at all.

607
00:54:02,744 --> 00:54:03,934
but I do drink a lot of tea.

608
00:54:03,934 --> 00:54:06,775
So you have to wonder what I have in these mugs every time.

609
00:54:06,775 --> 00:54:15,098
And this one I particularly like, it's called ah Himmel's Tau, which is like uh sky dew ah
or heavens dew.

610
00:54:15,098 --> 00:54:18,594
I think it's a euphemism for something, but I think it's absolutely fantastic.

611
00:54:18,594 --> 00:54:19,939
I don't know what it is.

612
00:54:19,939 --> 00:54:28,328
There's just like so many flavors and there's just always seems like a great alternative
to like juices or coffee or having anything heavier at the end of the day.

613
00:54:28,328 --> 00:54:29,702
I absolutely love it.

614
00:54:29,702 --> 00:54:30,343
Nice.

615
00:54:30,343 --> 00:54:31,924
Yeah, I will have to try that.

616
00:54:31,924 --> 00:54:36,689
I'm usually quite basic and I just go for Christmas tea all around the year.

617
00:54:36,689 --> 00:54:38,720
So I'm happy to try something.

618
00:54:39,342 --> 00:54:40,965
What is Christmas tea?

619
00:54:41,231 --> 00:54:45,710
You know, with cinnamon and maybe orange flavored.

620
00:54:45,710 --> 00:54:46,547
uh

621
00:54:46,547 --> 00:54:51,829
It's like the glue vine without the wine part.

622
00:54:51,988 --> 00:54:53,061
Exactly.

623
00:54:55,286 --> 00:55:00,270
So thank you, Lena, for joining us on this episode of Adventures in DevOps.

624
00:55:00,270 --> 00:55:01,273
Thanks so much for having me.

625
00:55:01,273 --> 00:55:02,480
I had a lot of fun.

626
00:55:02,759 --> 00:55:11,558
So thank you so much for joining us on this episode and thanks to all the listeners for
tuning in for this week and hopefully everyone will be back again next.