RICHARD SEROTER: All right.
Well, I'm Richard with Google.
I am here with Laurie today to talk
a little bit about cloud and development
and things like that.
Laurie, can you introduce yourself?
LAURIE BARTH: Yeah, absolutely.
I'm Laurie Barth.
I'm a senior software engineer at Netflix.
RICHARD SEROTER: Awesome.
I really appreciate you joining us here today.
I just wanted to kind of learn a bit from you
about how developers may be thinking about distributed
systems, things that may even start stretching
into other clouds, to kind of make
sure we're factoring in all the different perspectives.
So really first off, at what point
do you think in a developer's workflow do
they start to care where their software actually runs?
Do you care up front?
Do you care when you're about to deploy?
What point does a developer care?
LAURIE BARTH: Yeah, that's a really interesting question.
I think it sort of depends on what role
you're playing on a team, right?
So if you're the developer whose job it
is to architect the system, to think
about the different integration points,
then you really care up front.
You need to model that into your design.
To a certain extent, you can always adjust later.
But it's helpful to know those things if you have the answers
at the top of your project.
That being said, if you are a team member who's
focused on a specific part of the project, a specific smaller
subsystem, you don't necessarily have
to worry about it until a little bit later in the process.
That might be end-to-end testing.
You might not need to worry about it until you deploy.
You might not even need to worry about it until you're
asked to solve a real-life user issue where you need
to replicate their environment and figure
out what that actually looks like on their machine.
RICHARD SEROTER: Yeah, that's interesting.
So do you think that--
where do things like load balancing and security config
and which database you have available,
are there just some assumptions you can make up front?
And whether that's going in your data center,
it's going in a public cloud, you're
just going to use some certain abstractions
and work OK in there?
Or again, depends on the role?
If you're the architect versus the one coding business logic?
LAURIE BARTH: Yeah, it depends on
whether you're the architect.
It also depends on where in the stack you're working
and what scale you're working on.
There are systems that never deal with load balancers.
We don't talk about them very often,
because in these larger companies, that's not normally
the case, but they do exist.
And then especially if you're on the front-end side,
a lot of that's abstracted away from you
and you don't necessarily need to care
about it in the same way.
You just need to hit your API, and assume
that your load balancer and everything
else is dealing with parallelization
and distribution the way that you need it to.
So it really does depend what role you play on the team.
And that's not just architect or developer,
it's also where in the stack you're having an impact,
and whether or not your system is working at scale.
I mean, if you're building your own personal website,
I don't know that you ever really know.
RICHARD SEROTER: Yes.
So that's interesting.
So do you think if you look at the dev experience,
for the most part should that workflow
feel the same, whether I'm hitting AWS or Google Cloud
or whether I'm hitting a data center?
Is any part of the workflow for my local development testing
cycle, for the most part, can that stay pretty similar?
LAURIE BARTH: It can stay pretty similar
if you're using tools that give you a good local development
experience that mimics what you're going
to experience on the cloud.
Now granted, there are situations in which that's not
really possible, and you have to build and deploy
every time you want to test something,
and that's less than ideal.
So as long as you have those good local setup tools,
then yeah, you should be able to mimic
what you're dealing with in the cloud pretty seamlessly.
RICHARD SEROTER: What about from the security perspective?
So how do you think about the architecture dev experience
when it comes to platform security?
Again, if I'm going maybe to a more isolated environment,
I might have different security considerations.
Or again, is that not bleeding back into my application
development experience as much?
Do you see that as security architect overlay?
Or how does the security stuff come
into play, especially when I start thinking about where
this thing may end up?
LAURIE BARTH: Yeah.
I think a lot of that depends on how
robust the security of your organization is
and whether turnkey solutions already exist.
In places where they do, oftentimes you
are making an entire front door for your application
that all of your authentication proxies through that.
You don't need to worry about anything.
In cases where you need to roll your own, yeah,
that's definitely consideration ahead of time.
And I think everyone will say that once you
get to the point of dealing with permissions and roles, that's
where you start questioning every assumption
you've made about what you're going to build.
So yeah, you definitely have to worry about considerations.
But at the same time, the things you're running locally,
you're probably running--
let's say an Elasticsearch instance locally,
and you're hitting that, and it's not
until you're actually working in the prod stack
and deploying things that you have
to worry about the security groups
to consider who can actually hit that cluster.
RICHARD SEROTER: Yeah, that's pretty interesting.
I think I have noticed, maybe you see it too sometimes,
in the public cloud space, there can be this mentality of I
have to know everything about this environment
as I get started, and I have to know all these details.
And I'm not sure that's true.
Do you feel like, even if you're all
in on a public cloud, how much of that
bleeds back into the process?
LAURIE BARTH: Yeah, I think a lot
of that depends on whether you're
working on new or existing software,
or even a new or existing feature.
If you're developing something for the first time,
there's a lot of sort of mocking and dummying up
of things that you can do to get through the development
process, and then you work towards the integration
and deployment layers.
If you're working on something that exists,
then you have to be a little bit more finicky about exactly
what you're mocking and how much it matches what's actually
in production at the moment.
RICHARD SEROTER: Yeah, that's a great call.
That's a good differentiator.
So you wrote a good post earlier this year
on even just setting up your local machine.
What do you do when you boot up or when you just bootstrap
your local dev environment?
So you're working with developers, architects, others,
yourself, and you think about what does a developer need
on a local machine when they are building
something that goes to cloud?
What is that table stakes thing, that if a developer is
listening to this going, hey, I'm
starting to do more cloud stuff, what's
kind of must-have on that machine?
LAURIE BARTH: Docker.
You've really got to have Docker if you're
going to try and create some semblance
of an environment that isn't your local dev machine, right?
That's the best way to do it.
If you're dealing with customers who might be on Windows
and you're working on a Mac machine,
something like VMware or similar is
very helpful to get something up and running
that you can actually look at and interact with.
And we've mentioned before, that depending
on the maturity of your organization
you might have some security stuff.
Whatever packages and tools you need
to do to proxy your local dev experience
for whatever that tool is, is pretty important.
So whether that's your Google Authenticator,
or something else like that you have some larger
ecosystem around security that you
need to be mocking and pretending
to be an authenticated user, or whatever
user you're debugging for.
RICHARD SEROTER: How do you think about sandboxes?
Do you like everything just locally simulated and say, hey,
this is just going to feel like this?
Do you think each developer has their own sandbox carved out
in some production-like environment?
How do you like the mock production?
Do you want local simulations, or do you
want to actually put this into the real environment,
even for the dev cycle?
LAURIE BARTH: I like local simulations
because I think the feedback loop can be a lot faster,
depending on how many different local simulations you have
to be running at once.
I like the idea of a sandbox where you're really
trying to dive into a real-life scenario and say, OK,
can I duplicate the scenario that
was happening for this user?
For debugging, I think that's super helpful.
But for feature development, I'd rather
work on my local environment than in a sandbox,
but that's not always possible.
So my personal preference isn't as
important as what is theoretically actually going
to work.
RICHARD SEROTER: So when I look at the multicloud argument,
in some cases the argument put forth is, hey,
it's best of breed.
Like, all these clouds aren't the same.
There's awesome things in each public cloud.
There's things I don't even think of in other clouds I
don't use all the time.
So do you buy that best of breed argument for that?
Or do developers bring their software with them?
Like, hey, we love Vault, we're going
to use that as our secret store on every cloud.
Or hey, the database is offered by my primary cloud,
they're fine.
Yeah, this one maybe is a little better,
but I'm not going to switch all clouds for this.
So do you think best of breed is a real argument?
And if it is, are there certain types
of services where maybe that matters?
LAURIE BARTH: It's a real argument in one of two cases.
So it's a real argument if you are picking
a cloud for the first time and you don't
have a bunch of expected tools.
And in that case, then yes, go with the thing that
works best with the cloud you're working on.
The other scenario in which it makes a difference
is if you're working with a situation
where it truly is incompatible, and you have to make a change,
and therefore you go with the thing that's
sort of best in breed.
Beyond that, I think a lot of people bring their tools.
And it's not just that they're bringing the tools
that they like, they're bringing the tools that are already
implemented and they don't want to go back and redo them.
RICHARD SEROTER: Right.
So to you, is lock-in a bad word?
And if not or if so, I mean, when is it fine?
LAURIE BARTH: Lock-in is a complicated word.
I think it gets a little bit overused.
So lock-in applies for every project you'll ever
work on in some capacity.
You are locked into some piece of the technology
that you have chosen.
Otherwise, you're going to do a fundamental rewrite.
If you write something in React, it's
going to be a fundamental rewrite to write it in View.
If you write something in Java, it's
going to be a fundamental rewrite
to write it in Note, right?
So you're always locked in to a certain extent.
And I think we tend to think of sort of third-party providers
as the thing we don't want to be locked into.
But you're locked into your libraries and your dependencies
to a certain extent.
You're always going to have to rewrite some things.
So I think that there's a little bit
of a plug-and-play assumption with cloud
that isn't necessarily fair, given all of the software
interfaces that a lot of these clouds are providing for you,
whether that's for security or load balancers or databases.
For goodness sakes, if you want a plug-and-play database stored
in the cloud, you're going to have to rewrite
half your system anyway.
You might have to only do it at the database and persistence
layer, but you're going to have to rewrite something.
You're going to have to rework your tables if it's
in a different querying language, whatever it is.
So I don't think lock-in is a bad thing.
I think you have to recognize that you
are going to be locked in to a certain extent,
depending on what your project is.
And if you're OK with the idea that you're
going to have to rewrite things if you
need to migrate to another cloud, then lock-in's fine.
It's the scenario in which you expect
to be able to pick up and spin up somewhere else in a week,
that it's a bad thing.
But in that case, you're going to have
to put in a lot of thought to how you architect
your system, because you'll be locked in pretty much
regardless of what you do.
RICHARD SEROTER: Do you think there's layers there?
Where some people say, hey, maybe
I don't want to be locked in with [? IaS ?] at this point,
because that's lower-level infrastructure, a storage
provider, versus hey, I might be locked into my AI tools, that's
super novel stuff.
Or is it all the same sort of argument that you're making?
You're really just making some choices
of where portability is something you would actually
engineer for, versus just accept the fact that there's a cost?
LAURIE BARTH: It's all relative.
So you are always going to be locked in to a certain extent,
but there are certain types of tools where that lock-in comes
with a lot more friction to get out of than other tools.
So you're deeply integrated, for example,
with your frontend framework, but you're maybe
less deeply integrated with your PDF image bucket,
for example, that's just sort of a storage place.
That, you could probably change out a little bit.
You're changing a URL and making your security group setup,
it should be good to go.
But it's relativity.
It's always going to require some change.
It's very rare that you can just pick up something and drop it
into something else without any considerations.
At the very least, you have to reconfigure everything, right?
So that's work.
RICHARD SEROTER: This was terrific.
Laurie, I appreciate you sharing some wisdom with the team,
and I appreciate you taking the time.
LAURIE BARTH: Absolutely.
Thanks for having me.
[MUSIC PLAYING]