Confusion In The Land Of The Serverless

Sam Newman

Recorded at GOTO 2017

Confusion in the Land of the Serverless

Sam Newman

Recorded at GOTO 2018


Get notified about Sam Newman

Sign up to a email when Sam Newman publishes a new video

I always feel a bit concerned when
people applaud at the beginning before
they see me talk because I kind of feel
like the only way is down from then on
in so alright yeah as friend said I did
write a book about micro services which
doesn't contain any reference to
serverless which made me feel like I had
to do something to address this
particular challenge but this is what
we're here to learn about today well
that's what I've been trying to learn
about the last year or so is what on
earth is this thing called service
there's the book you can see no service
information in the book I used to work
for a bunch of other companies I now run
my own firm called Sam Neiman and
associates we do training consultancy
and advisory work I've also been doing
some workshops on micro services some of
you are now in the room when are the two
workshops we had earlier this week and
it's been a big year for me a very big
year for me because you know starting
starting my own firm was was that was a
big deal and you know it's been look I'm
not gonna lie to you the reason it's
been a big year suddenly realized that
I'm 40 and that's being like I people in
my class will tell you firsthand that I
was sitting down for half of yesterday
because my back is so bad I now make
sounds when I get up out of my seat I
make large louder sounds when I sit back
down in my seat getting our pad of a
chair is amongst the worst things that
can happen to me in any given day I'm
old enough to remember when the internet
came on a floppy disk this isn't
actually a floppy disk but it did used
to come on bigger floppy disks I
couldn't find a good AML picture of
those I was very excited when I my modem
went up to being a 14-point 4k modem we
still had to deal with the issue that
you're trying to use the internet and
somebody else wants to use the phone and
you know your dad picks a phone up and
it's screeching in their ear so yes this
is when I remember the Internet I
remember when Facebook used to be called
the Facebook which is that what I insist
on calling it I also insist on not using
it cuz I don't understand it but yes
that's why yes this is the past and now
of course we live in the future a future
snapchat either you know what I know is
that every now and then my my son will
this myself
be sitting on the sofa he'll make a
funny face miss Cameron go and take a
photograph I don't understand what it is
nor do I understand how it's a
multi-billion dollar company now I'm
this is the thing right now I'm not that
old I suppose in the computing terms the
fact that I've been doing this for you
know 20 years plus years now it does
make me a bit old but I still feel like
I am in touch with some things I do have
some of a basis in reality I was
fortunate enough to be to use Amazon Web
Services extremely early on I sort of
accidentally found myself delivering the
first public training courses for AWS
years and years ago they all colleague
Chris Reid and so I feel like on this
cloud stuff I've got a firm grasp but I
should be able to understand this world
we operate in I spend lots of my time
with cloud platforms that make it easier
for people to go faster
I love helping people go faster that's
kind of what I want to do those of you
should have been here to see Steve's
talk earlier all about that how do you
optimize your flow and that got me
really excited you know infrastructure
automation build automation test
microc services and that's my thing and
then everyone starts saying are you've
you're not serving us so are you you're
not serving us you've still got service
and I'm very concerned about that but I
got confused because what does it mean I
am somebody who is half a system
administrator and half a developer more
by accident than by design when you
turned out to be the only person on a
project that knows Unix you end up being
the build monkey and next thing you know
you're the system administrator I quite
enjoyed that though it's why I
understand there are definitely
computers here right but the term itself
of course is serving us now service is
coming up fast on the Gartner heiko
meter we can see the Gartner hype ometer
here here's my own particular topic of
micros notices I want to point out I am
winning on this anyway right there's my
little blip right up there this might be
a bit old now I always find it funny
that micro-services is way up here and
service oriented architecture is way
down there and they're the same things
so it is all just marketing and service
you see over there is still a technology
trigger
which will we'll see I suspect we're
getting I think the peak the peak for
microservices is going to be dwarfed by
the peak of interest into service
computing later on but I started waiting
my way through all this trying to work
out what the hell is it what are the
impact in a micro service environment
what does it mean and so you know of
course I had to deal with the initial
challenge which was well there are
definitely computers here right so what
what is this thing really really about
now it might surprise some of you but
the term service has actually been
around for quite a long time it's only
really been maybe in the common
consciousness of us for maybe the last
couple of years but the term actually
treats its wait comes all the way back
to this article in 2012 and
unfortunately seeing as my slides are
being sliced off this is a piece by
kenan from back in 2012 about service
computing this is the earliest reference
I could find I found this fire Mike
Roberts and the definition can use full
service computing this was his
observation of kind of the new
generation of cloud-based services and
he talked about what he saw as this new
type of service at these service types
of platforms and his definition for
service was this the phrase service
doesn't mean that so servers are no
longer involved it simply means that
developers no longer have to think that
much about them computing resources get
used as services without hammett having
to manage around physical capacities or
limits so this will serve us as a
definition is still a good definition I
think at some level 2012 predates it now
the interesting thing is I've been to a
number of talks this year about service
computing that start off by defining
services saying services just functions
as a service that's all of this is we
going to think about it which of course
is hogwash because lambda launched in
2014 a full two years after the term
service was coined that's not really it
either we do they have to deal with the
fact that all of this stuff is about
your viewpoint this is a developer
focused
wave of services which i think is really
important it's really valuable these
things are serving us from our point of
view from developers point of view right
the platform is amazing it makes us feel
great and empowered it makes us feel
like yes we can do whatever we want I
don't have to worry about pesky
computers or administration purposes or
whatever else it's just is pandal for me
and of course underneath all of it are
sitting our servers and maybe maybe as
well
poor operations people that have got no
idea what the hell's going on with all
developers running around saying why
can't it be service all the time
and it is all about this is all about
things being in the either beholder
but really not so much the reality is
that most of us are only experiencing
service platforms at the moment though
via cloud vendors from Amazon from
Microsoft whoever else that means this
underlying management stuff is being
hidden very much hidden from us we just
get recharged those costs I don't think
that's going to continue now I went
looking for a better definition of what
service architectures were and I came
back to this post by Mike Roberts so
Mike Roberts is an old colleague of mine
and his witness really lovely post
talking all about different types of
micro service architectures it's
available over at Martyn father's site I
thoroughly recommend giving a read but I
was chatting to Mike about this and said
look are there any more sort of defined
characteristics that you've got for what
serverless means is it just you don't
have to worry about service and Mike's
actually got a fairly specific set of
criteria that he uses to decide this
thing is service these are the defining
characteristics of what makes for a
service product a server a platform so
the first thing he talks about is that
there's no management of server hosts or
server processes that's very clear I'm
not worried about how many of these
things I've got or what it is I'm not
doing operating system upgrades that's
hidden from me and tiny secondly this
idea that the platform itself should
auto
scale or spin up new things and
therefore also could shut those down
based on my need without me having to be
involved thirdly you get charged based
on precise usage so your base you have
charged based on what you use it how you
use a service you're not charged if
you're not using it right fourth the
performance capabilities you don't
define those in terms of like hice host
size our host count again it's this kind
of implies that that auto scale and auto
provisioning is is again it's very
abstracted you don't say when I hate
load add another machine you don't get
that level of control the thing to
understand with all of this stuff which
is services about higher order
abstractions higher order abstractions
can remove control from you you kind of
have to be okay with that
and finally there's this idea that
serverless gives you implicit high
availability in other words you don't
have to apply conscious thoughts you
just get high availability as a side
effect of using the service product
that's actually quite an attractive
option right now we'll come back to that
concept of high availability a bit later
on so if we use Mike's criteria there
are some obvious products out there to
fit that model really really well okay
we've got things like lambda and as you
allow functions so these things are
function as a service which for many
people are synonymous of service to the
extent where service means function as a
service but Mike definitions actually do
put in a whole lot of other products
that also fit the bill really well
Amazon dynamo or Google's BigTable
Amazon's s3 those are all service
platforms you're not worried about the
underlying computers you're not managing
in terms of hosts you're being charged
based on usage zero admin those also
absolutely fit the bill of service
architectures these these sorts of
things often called backend as a storage
typically the database types products in
a space now service being around
abstractions I started thinking about
what was my favorite develop orient
abstraction for quite a while and what I
still think
to a great degrees the gold standard for
developer focus platform as a service
and that's Heroku really interestingly
as awesome as Heroku is it doesn't fit
Mike's bill or Mike's definition of what
service is because you're still managing
in terms of things like host counts you
could also argue that you're spinning up
a machine as being you have a dynamo for
example dynamo is sitting there you're
still being charged through whether or
not is taking on a load so Heroku
doesn't fit the bill
there are some other odd things though
that do fit the bill which makes me
think this is always the challenge when
you have a very specific set of
selection criteria that you you
unwantedly pull some things in
Salesforce specifically the force.com
platform is a service platform might not
be one that you want to use necessarily
although I suspect every single one of
you is in a company that is using it
very heavily somewhere but yeah
Salesforce is force.com platform
absolutely would apply as a service
architecture in this world not scaling
terms of hosts you could argue about the
pricing model but it fits in some ways
better than Heroku does fastly a content
delivery network that's service you're
not managing that plane you can even use
Farsi to deploy applications if you've
got just a client only JavaScript
application you're being charged based
on usage you're not managing hosts that
fits and as I mentioned I think sort of
the this sort of predecessor for all of
these service type platforms arguably is
something like Amazon's s3 a really
simple easy to use highly available blob
store this is all about abstractions
services just all about abstractions and
we've been going through this journey
for a while now we started off with the
journey towards infrastructure as a
service the ability to cry a line of
code and have that automatically
provisioned some piece of infrastructure
arguably this is an abstraction which is
ops friendly more than developer
friendly but nonetheless it's there you
know we've got infrastructures of
service more recently we've been looking
at what some people have called
containers as a service really that
should be container orchestration as a
service platforms that are that abstract
out
detail of how you manage and scale
container based applications so think of
things like Amazon
ECS think of things like kubernetes the
various different offerings out there me
sauce and those things fit into that as
well a higher-order abstraction a
friendlier abstraction now ten years ago
if you'd asked me what direction this
whole thing was going in I would have
said that all of us by now would be
using a platform as a service when I
first saw Heroku is like eyes open it's
like obviously that's what we should all
be using or something very like it turns
out working out what a good developer
abstraction is at that level at the
level of a platform at the level of a
pure abstraction around an application
is really difficult this is always the
issue with abstractions the higher the
abstraction you create hopefully the
easier is to use but you often high
detail and hide information you
shouldn't hide you end up with leaky
abstractions or abstractions that high
too much information from you and that's
why it's taken so long I think for us to
start coming up with these higher-order
distractions it actually makes sense for
most of us for me platform as-a-service
is still the future it's still where we
going and serving us is really just a
better encapsulation of what that is but
nonetheless we're now drowning in
acronyms we've got Fast Pass pass Cass
ass service it's up this you know ku
Burnett has up there as well and it's
all getting a bit confusing and I don't
really know what's going on anymore and
you know parties talking about what you
do for a living and you end up feeling
like a bit of an ass it gets really look
this is all I came to think about it's
all about abstraction it's all about
hiding or a detail but isn't important
to you
I mean Kelsey gets it and if you don't
follow the awesome County Hightower you
should he's been one of the driving
forces behind making kubernetes like
such a big part of of many of our lives
nowadays you know this is his this is
his view on what coupon what services
you don't want to have to worry about
infrastructure you don't want to have to
worry about admin you want to write your
code and get on with your day job now I
don't think service computing can hide
all things from us but it can hide a lot
I still like coming back
original definition from 2012 from Ken
the phrase serverless
doesn't mean servers are no longer
involved they're still computers
underneath it all don't worry
servers are no longer involved it simply
means that developers no longer have to
think that much about them this is just
a continuation of the works been going
on for many years now by many different
people some of you may have heard this
term before undifferentiated heavy
lifting this is the term that was used
at Amazon to describe a lot of the busy
work that their teams were being asked
to do Amazon had this driver towards
autonomous teams so reducing the need
for coordination between teams allowing
those teams to operate and execute and
deliver quickly but they had to sort of
self-service as much stuff as possible
they wanted to be able to manage their
own infrastructure so they couldn't need
a centralized Operations team but they
found them spending they were spending
all of their time racking kit cabling
talking to vendors they said this is
undifferentiated heavy lifting what we
do doesn't differentiate ourselves from
anybody else we need something else to
handle this for us that's what drove the
creation of the product of the of the
infrastructures of service stuff that
they develop internally that eventually
became what we now use with a fire AWS
all that's happening is we're developing
a different idea of what
undifferentiated heavy lifting is for us
as application developers it's higher
order undifferentiated undifferentiated
heavy lifting it might not be computers
anymore that we're trying to abstract
over now it's functions now it's
databases in Mike's definition he talks
about this idea that serverless was
inherently highly available and I would
push on that point a little bit and talk
about that aspect of resiliency and and
some areas where I think service does
still have some questions that need to
be resolved now many many years ago I
played a very small part in the global
financial crisis if you want to know
more about the details of how I did this
you can watch the film the big short I'm
in reality what I was doing was pricing
helping price these things called
credit derivatives one type of this was
a collateralized debt obligation and the
collateralized debt obligation was very
simply put a type of financial product
where you took looks of bad loans and
you put them all together and then you
said and now it's all good and then
you'd ask the question well how does
that work and they say you put all the
bad loans together and then they're good
what part of this don't you understand
and then you just got on with the job so
do go read especially the book by Martin
Lewis at the film's based on is really
interesting now this system was really
in was we really fun to build but a lot
of the work that you know I plan into
microservices sins have was inspired on
this project we were actually delivering
our solution on this interesting thing
called a grid a computing grid this was
back in the days where you know we're
talking about grid computing not talking
about things like could doop and all
that sort of stuff that came later damn
hipsters instead we had a good
old-fashioned sort of grid computing
system we were using one called data
sign apps and the idea was that you
would run a whole lot of workers in this
grid and you could dispatch work to that
and you would use the grid to scale up
we were anyone iPhone our own kit at the
time it was pretty we one of the first
people in London to do this so it's
really exciting nowadays people go you
only had 25 machines Oh bless but
nonetheless here was all of our things
our pricing our trades but we needed
information from other sources so we
were pulling in information on different
risk profiles a lot of that was coming
from Bloomberg and things we're also
putting in general market data so
information about companies that might
look like they're going bust that sort
of stuff and they were storing the
information that we'd when we've done
these calculations were storing that
information out into a database and all
of those things were external services
that lived outside of this grid now the
reason we picked this grid by the way
this particular product is this product
had the ability to run Excel
spreadsheets in the server now you might
think why would you want to run Excel
spreadsheets on the server side well
that's when I tell you that for a long
time lots of the traders were actually
running these pricing algorithms in
Excel spreadsheets on them
machines and when they didn't like the
answers because for example the answers
might mean they didn't get a good bonus
they would just change the numbers until
it fitted what they wanted to do the
bank worked out that wasn't a great idea
and decided to centralize a lot of that
work so we had to be able to move
Ronny's Excel spreadsheets on a central
farm
another interesting capability of this
particular products was that you could
run the agents just as screen savers so
if in a normal desktop machine the
machine wasn't being used the screen
saver started up that machine would then
become available as part of the pricing
grid allowing you to read like scale up
the number of workers that you had and
so a colleague of ours told us about the
fact that we actually had a whole dr
center sort of north of north of london
the idea being that if the building had
to get evacuated that the traders could
move to the new location and carry on
doing their work these machines had to
be left on as part of the sort of
business continuity planning and so
these machines were always available and
so he told us this in hushed tones at
lunchtime I guess we could just we could
just install the screensaver they
wouldn't mind be fine so we did that
so we suddenly went from having a grid
that had like about 25 machines to
having a grid of about 300 machines and
it worked really well to begin with the
grid handled it beautifully and it was
just spun up all these end in extra
machines and we started chewing through
this work way way faster and then some
really interesting things started to
happen and is if from nowhere everything
stopped working we realized that what we
had done is overloaded every single
service that wasn't in the grid we were
generating too much load on the services
that were extracting information from
and we completely neut the database so
this was a cautionary tale we actually
had to back off the number of nodes we
increase the scale of the things around
our system we basically had a a mismatch
a mismatch capacity problem now we
actually deal with sort of mismatch
capacity problems and in our systems all
the time we actually build throttling
mechanisms into our systems all the time
sometimes we don't even know we're doing
it but it happens like one of the
traditional ways you might do this is
something like a database connection
pool when we have a connect
simple to handle connections down to a
database that limits how many calls will
go through to the underlying database
system itself so you can stop it being
overwhelmed you can actually shrink the
connection pool size of each service and
these work really nicely you have load
coming in if they need access to the
database if a request needs to get some
information from the database it goes
and gets a worker from the pool if the
one that if a worker is available that
request can then go on
in fact record if a worker isn't
available then the request has to block
and wait until one is and in this way
you're throttling the number of calls
that go through to a database protecting
the database and then allowing it to
continue to work so these connection
pools they help throttle the load it
also allows you if you can't get an out
of work out of the database perhaps
because there's so much load going on
you can actually shed load as well you
effectively can timeout on waiting for a
thread from the connection pool and
you've shed load which actually sheds
load of the whole system it reduces
resource contention and increases the
stability of your software whether we
realize it or not that's the role the
connection the database connection
pooling plays in our systems in our
applications the problem is connection
pools require continual state between
requests there is a pool that pool is
shared amongst lots of requests when we
start looking at some of the server
stuff though that those things don't
quite work do they because what we have
is we have something like a function as
a service offering like wium using
lambda or or or something else
when requests come in we launch a
function that allows us to carry out
some operation the more requests that
come in the more functions that get
executed to handle those requests so
more load more functions those functions
if they want to talk to our database
will increase the number of calls coming
in there is no place here for a
throttling mechanism at best you can
throttle right at the top ish in terms
of limiting the number of invocations
you've got but even then you don't have
much fidelity of control and so I
started wondering are we going to have
the same problem with function as a
service as we do with something like
well we had with that pricing system I
showed earlier in other words if you
get high load are you going to basically
end up nuking downstream databases just
like we did now of course the answer
here is well don't use a normal database
to back your functions as a service you
use a service database you use BigTable
or you use dynamo because those things
are server systems that will scale as
your function scale and that's sort of
okay to a point but then I have the
question well what about hybrid
applications IA I hate the idea of Big
Bang rewrites I think it's one of the
worst things we do in our industry as a
huge amount of problems associated with
Big Bang rewrites
so I always try and promote the idea of
incremental evolution of software so if
you want to move and adopt to serve some
servers products to make your life
easier you're going to need to bow to
migrate from the existing set up over to
a service architecture and so the idea
that you have to be all-in on servers to
solve these resiliency problems don't
doesn't sit well with me I also was
worried though that I could just just
could just be a theoretical problem
until I heard so a great presentation by
Steve from bustled
so bustled are a quite successful online
media company in the US I think it's you
start like 60 million uniques and
they're often held up as being the
poster pitch the poster children for
pure service the reality is bustled are
not pure service despite what some of
the case studies might lead you to
believe that's the vendor case that's
not necessary what bustled themselves
will tell you bustled run Redis on the
back end as a database now putting aside
whatever concerns you have about running
Redis as a database it works really well
for them but they were having all kinds
of interesting problems they were having
the same issue that we'd had they were
seeing their database their Redis
instances being completely overloaded by
these lambda functions that were being
spun up there are actually seeing some
really odd things there Redis instances
were topping out at 10,000 concurrent
connections and they were running on AWS
and at the time you were limited to a
thousand lambda function invocations at
a time so clearly the old functions were
lying around and those old connections
were lying around they ended up having
to do some really funky stuff down at
the actual
whereís knows to get rid of connections
that weren't active just to try and keep
those systems running this is actually a
real-world problem in terms of getting
your implicit high-availability this is
an implicit high availability to me it
feels like we've lost something by not
having that connection pooling idea
somewhere in the system there are other
kinds of resiliency protection
mechanisms that we use of course in
these situations circuit breakers being
a common one another kind of throttling
mechanism another kind of protection
resiliency in systems that use
synchronous point-to-point calls and
again you know it works in a similar way
load comes in if I my service or my
application needs to make a downstream
call to something and that downstream
service is misbehaving
maybe it's erroring maybe it's timing
out what we do is we open the circuit
breaker in order that in the order that
we start failing fast failing fast is
useful because it reduces resource
contention makes to our system stays
resilient that then allows us to get rid
of the load we go to faying fast circuit
breakers rely on state across requests
it's how many timeouts have I had in a
certain period of time how many errors
have I had in a certain period of time
before I consider that downstream
service is unhealthy circuit breakers
live in client code where do they live
in our functions so that's always been a
question to me it's like where is this
what I mean thinking about is actually
if we are going to continue using
functions as a service and we actually
going to end up with some kind of
throttling and load shedding middleware
that will sit between our functions
which are single request and ephemeral
and those parts are applications that
might need protection from them
increasingly I'm wondering if this is
potentially where service meshes will be
able to help the challenge of course is
that most service meshes are positioned
at different types of problems and I
don't necessarily know how easy it would
be to make that stuff work and assure
that you route via them but I don't tend
to find out of course I could be
worrying how many people here have
massively scalable systems you know how
many of us really have the kind of
problems that require a massive huge
scale that can dynamically prevail
staff maybe that's not the point if
you're running small loads then maybe
the stuff I'm talking about here isn't
going to be a problem to you but then
that is the promise of this stuff is
resiliency in these situations and and
clearly we can't do and I'm not entirely
sure there's the answers are out there
and I have been talking to people who
spend all of their time working in
service and saying so what about these
things and they go yep that's a problem
I'd say so what do you do about anything
go yeah that's the problem isn't it yep
so maybe next year we'll have a solution
to all of this I want to try and catch
up with a bustled team and find out what
they're doing but you know this may or
may not be an impact for you another
thing they has talked about a lot is
security and initially at least there
were a lot of concerns specifically
around function as a service and what
the security model is because very
quickly when lambda first got launched
people worked out our it's running
docker under the hood it's just a
container my function is really a
time and time again is that friends
don't let friends run on traffic code in
containers because there are although
contains are quite good isolation
mechanisms they're not necessarily a
very secure way in general to isolate
code from different people where those
people don't trust each other so this
has always been the mantra so you want
vm isolation or if you're lucky enough
to be a Microsoft you can use something
like these Fiat containers but
nonetheless normally we say we don't
want to cope we don't want a
multi-tenant code from different people
who don't know each other because your
trust models are kind of out of whack
the reality is of course what we're
worried about is a very very specific
targeted type of attack what we're
saying here is well somebody else's
function could do something to my
imagine how that's going to work though
I'm got you know when I launch a
function that's a contained that's gonna
spin up on some machine and I don't get
to decide what machine that function is
gonna launch on that function will only
run for as long as it's you know needed
that an attacker has to get their
function onto the same machine breach
the protections that are in that system
and then somehow find my function and
gain access to it so beyond the fact
this makes a targeted attack incredibly
difficult small
might be a mass-market attack if your
function isn't running it's not there
you know and you're running in a sandbox
anyway you're not running out full
containers when you deploy a function
that function is deployed into something
which itself is part of a container so
there are additional protections and
sandboxing around your function onto the
container itself I will say it's kind of
true this by the way just because your
function isn't running doesn't mean it
isn't there it's not quite true we know
that at least Amazon lambda for example
keeps around functions especially
certain like Java functions to decrease
the spin up time you know I told you
about bustle having those 10,000
connections coming into their various
instances but you can only have a
thousand functions running at a time
will that tell you it tells you there's
something running somewhere so we don't
exactly know all we know really is that
if your function isn't running we're not
getting charged which we'd normally ok
with so security wise I think we're in a
significantly better place in terms of
stateless functionality with a function
as a service platform the fact that your
code isn't running therefore can't be
attacked is a good thing I think also
because people are mostly writing small
functions as a small piece of code to to
look at and understand what's doing the
flipside of course is you are pushing a
lot of trust into the platform itself to
do the right things but that's happening
anyway if you're embracing a platform
talking of embracing platforms we should
talk about lock-in a lot of people are
very concerned about this to buy in to a
service platform you're buying into
often the products must certain vendor
this has always been a problem from time
immemorial when talking about cloud
computing because early on we were
promised it was all going to be utility
it's utility it's not utility is it
that's one of the dirtiest lies we were
ever sold
there is no utility when it comes to
computing right you'd say what utility
is when we talk about utility in the
context of of being able to shift
between vendors utility is what happens
in the UK we have a deregulated energy
sector and no matter what you think
about if that's a good idea or not
switching providers is trivially simple
you go to someone like you switch
electricity and then it gives you a list
of Cheaper providers you click a button
and in two days you're now with a new
provider no one has to come and reek
able your house no one has to go and
change your electric sockets just sort
of happens it's like magic it's like a
utility should be the reality is when
you're moving from cloud vendor to cloud
vendor these these things aren't the
same level of abstraction we don't have
the same level abstraction as 240 AC
electric supplies right the abstractions
are all different so moving from one
vendor to another is not a seamless
operation it's not utility in that sense
this thing gets people stocking what
about lock-in I would being locked in
locking thinking Zin is bad we don't
wanna be in a walled garden you know it
happens a wall Gardens I say what and
they go well you know and I really don't
but anyway I also get annoyed at this
because then what people start doing is
tying themselves in knots to create
their own abstractions over these cloud
providers in order to theoretically
allow them to maybe be portable later on
perhaps maybe if that happens maybe
on the lock-in front I don't like
talking about locking I instead like to
think about the migration cost instead
don't worry about being talked about
locking because that has always has
negative connotations instead try and
have a rational conversation about what
a potential migration might cost you in
terms of the different services you
might use because different services
from each vendor has a different level
of migration cost we think about
something like you know blob storage
like Amazon s3 the semantics of that
offering are quite similar to offering
from other providers
therefore migrating over to an
alternative blob storage provider the
biggest issue is actually going to be
shifting the data but the services are
quite similar and are very close compute
likely is a bit more work the api's you
need to spin up an instance are
different because there really isn't a
common standard around those things
that's widely used but once you're on
the machine you know a Windows machine
or a Linux machine run on on Amazon is
pretty much the same as when running on
Azure once you've got a spun up load
balancers the semantics are a bit
different but
migration wise even if I couldn't use
the cloud vendor I could jump in HJ
proxy that's some work it's not a lot
what the issue is more when you start
getting into things like fast function
as a service the platform's are quite
different that the capabilities of those
platforms are quite different
so migrating that stuff is difficult
because at the moment there aren't that
many solutions and certainly none that I
know of being used in production there
are portable functions or service
platforms backends as a service actually
can be even more problematic here the
semantics are very different there isn't
another database in the world that has
the semantics of DynamoDB for example so
if you need to move your application
into another platform you may well
actually have to rework code in order to
use a different type of database and
this is what you really need to be
thinking about when it comes down down
to is you've make an assessment about
migration cost and then you sort of say
to ourselves we'll look if we have to
move later on this actually could be an
awful lot of work so do we want to use
this service now and what we're trying
to do is have a trade-off between do I
pay now do I pay later do I pay the cost
now of not using this awesome cloud
service and using something else isn't
as good or pay the cost of creating an
abstraction over this awesome cloud
service that might reduce my costs later
on or do I say you know what we're going
to take the risk we're going to use it
and except there might be a cost later
on this is what it should be there's a
balancing force do not get mixed up on
trying to do things like you know cloud
arbitrage layers and stuff like that
because they're all rubbish because you
end up with a lowest common denominator
problem some people talk about mixing
vendors to hedge your bet now I think it
makes a lot of sense as an organization
to have a multi vendor cloud a mighty
cloud vendor strategy well my clients a
couple of weeks ago I was talking to
them and they said they as exactly what
they do across the organization they
have strategically decided that they
want to have investment in like I think
they're using Microsoft and using Google
and they're using AWS and they said
because as an organization we want to
have the skills in the organization to
take advantage of the best services as I
rolled out
potentially if there's a big cost
differential to look at migrating
services as appropriate but within any
given product area or solution they are
all in a one vendor because they say the
cost locally of try and support multiple
vendors is too high
beyond the just the fundamental
challenges around things like latency
and things like that
ultimately I come back to where I said
earlier you said the walled garden is
pejorative terms we use the thing is
when you're stuck in an ecosystem we
always assume it's a bad thing but you
know what being stuck in some places is
pretty good
right I quite like being in the Apple
walled garden the Apple wall god it's a
really nice place to be
it's a beautifully manicured lawn you've
got a lovely babbling brook people bring
you drinks and you're sipping martinis
it's nice you really enjoy it yes I've
been in walled gardens where there's
scorpions running around in the grass
there's a few snakes around I think that
the house might collapse on me at any
moment but I'm not there now just
because you're all in on a vendor don't
see that it's necessarily a problem and
in fact I think with all of these
service platforms you kind of have to be
you have to really embrace them I think
to get the full benefits of them now
this is starting to change people are
now starting to create serverless
products that don't aren't tied into
vendors widely thought I wonder I bet I
bet somebody by now has tried to come up
with a fast framework for running on
kubernetes and docker it took me two
minutes to find five that already exists
I know nothing about them but you can if
you want to go and use open fasts you
can fact use fast
Nettie's fishing we also have open wick
from a open whisk rather from apache and
of course open lambda who I would
imagine are going to get sued any moment
now with that name now the interesting
thing for me is against servlet is way
more than just that and if all you have
is function as a service you're missing
out on a lot of other things that you
need there are other problems in your
application stacks that need to be dealt
with beyond the problems I talked about
middleware types officer I think service
meshes will solve
what about backends
storage in a platform portable manner
David turns out that's a way harder
problem running containers in an
ephemeral style is really easy right so
therefore these fact these fast
platforms are quite easy to create where
is our equivalent of a dynamo DB or a
big table for running on our own
kubernetes instances that's a
significantly harder problem and I doubt
one we're going to see a good viable
production solution for anytime soon so
look I am as any good technologist is
still very much confused but I'm
starting to make a bit more sense of it
I've sort of been quite fortunate that
where we've gone through a few different
phases of buzzwords each which one of
which I wanted to take advantage of
accidentally by being near somebody who
knew something at the time you know
we've had agile we've got DevOps we've
got micro services and I've also
realized that some people have sort of
you've seen that the pace of change in
the world is increasing you know the
time it takes for a new thing to have
impact on our world is really shifted
see how long it took for us to all have
a pet you know a computer at home and
then see how long it took for us to all
to have affected the power of that
computer in our pocket in a smart phone
took a much less shorter time I think in
the same way we're seeing it with our
buzz words our buzz words are going from
being meaningful to meaningless in
faster time than ever before it took
agile like about 10 years
DevOps about five years microservices
about a year and I think while serving
us maybe six months if there's any
advice on they give you here firstly
don't feel bad if you're not using
service it's just a lifestyle choice
there's some useful stuff out there
there is an interesting question I've
got about this hybrid stuff we are
computers aren't going away but we are
adding computers faster than we're
that can use them therefore these
abstractions these higher-order
us to take advantage of those computers
to do things service is just another
evolution it's all about abstractions
and as we've seen we've got abstractions
all the way down
the last thought is with all of this is
that all of these abstractions use
service abstractions they start off
being tuned for the general case that
may or may not fit what you need and if
it doesn't fit what you need you often
have no choice but to use something else
but that's okay because underneath that
you've got things like you know
container orchestration as a service
you've got things like databases and RDS
that you can use directly we have a
wealth of tools available to us and I
just want you to think about the right
tool for the right job don't be scared
about embracing the platform and above
all by my book we have got time for
questions if you you can find out more
information
I do blogging and stuff over my website
and you can find me on Twitter that's at
[Applause]
Wesley ha Union one minute
sorry so I was hangouts tapes okay okay
let's start with this very serious
question I don't know
can we have abstraction as a service
it's actually a question from from the
app but okay so the land of service as
far as I understand is confusing will it
stay for longer or will it pass away I
mean I don't I think the having zero
admin abstractions that allow us to
build and deploy applications is
absolutely here to stay whether or not
the term servers survives I don't know I
don't think really matters that much so
I think we have got better at creating
abstractions that find that balance
between utility and ease of use and so I
think it's good banner term for those
products that fit that space so it's
that those products are here to stay I
think we all probably have higher order
abstractions to go I think the idea that
I should be able to throw an application
at this system and it will work
everything out for me so I think we'll
might have high order definitions of
what my application is that we might be
using that was the original premise of
things like Google App Engine way way
back in the day but what we found was
it's too hard to work out what to do
with your app because your app was
special to you so no I think if anything
will probably see high-order
abstractions being used more commonly
over time okay
similar question why do you think pass
is the future or maybe the same question
just because we should be we shouldn't
have to deal with the detail I mean this
is this is all about and actually you
know all computing you know since we
began has always been about creating
high-order abstractions to make us more
productive that's why we don't write an
assembly code anymore we came up with
other languages that don't handle that
stuff for us I think which is our
continuing desire to do more with the
time we've got available to us so what
do you think of AWS IOT MQTT price
because they do pricing by the number of
messages message size stuff like that is
that something I know nothing about the
information is that the information of
toasters that IOT stands for the
information of toasters yeah I don't
know about that specifically but one of
the challenges associated with any of
be charged based on precise usage so you
only get charged on what you use it can
make the world confusing but it's very
hard to know what you're going to use so
I can't speak directly to that product
but one thing you need to consider is
sometimes you might actually like to
just get a load of 82 instances to run
your stuff on because then at least you
have a known cost and for some
organizations having a known upfront
view of your cost rather than an unknown
and hard to gauge understanding of your
pricing might be a better choice for
your organization okay thank you very
much thank you thank you