Microservices and Serverless - Sam Newman

thanks about all those who came along to my earlier the keynote earlier on I have made some improvements to my setup so hopefully now you're able to see my screen and my video I had to there's some things involving network cables I do not want to go into because the sysadmin in me wants to cry about the setup that is being jury-rigged here to make all of this work but hopefully I'm coming across very clear and that you're enjoying this probably self isolating at home oh we're now going talking a bit about our micro services and how they relate to the concept of service service is a big hype topic and I think rightly so actually and we're gonna be exploring a little bit about what services but talking about service and specifically function as a service in the context of micro service architectures as before we will be using slide o for questions so if you want to go and ask the questions during a talk Yunel - as slide though and use the hashtag k-y eight six zero that's why eight six zero and that will allow you to ask questions as we go do you want to go to that website now open up in a window so needed you can keep it open you can keep it refreshing and just ask questions as you as we go through the session and that will give you a lot of things to answer when we end I'm not going to talk about the work I do in the books I've really started that in the keynote but if you don't know more about you know decomposing - - micro services and all that sort of stuff you can find information about all of that and my books and the services that I offer for my company over on my website though we're here to talk about service and micro services so we should talk a little bit about micro services as I always draw them these nice hexagonal architectures and kind of you know you micro services have become almost ubiquitous in terms of its that for many people it's unfortunately become the default way of building software but it's sort of its uppermost in our minds but I do think it's often important to just refresh that sort of the most important characteristics of micro service architectures and you know talk about these things as being independently deployable services that work together modeled around a business domain so you know we're taking business functionality we're packaging it up together and I'm exposing that business functionality over network interfaces so typically talking about one process talking to another process over some sort of network boundary although that kind of blurs a bit when we start moving into the world of functions but we use the business domain to define those service boundaries but the really important characteristic here is this idea of independent deployability and that's a really important facet so many of the things that we look to get from micro service architectures noticing completely the key benefit that we get with micro architecture is over other styles of modular architecture is this idea of independent employability so we can make a change to a service we can deploy that service into a production environment without necessarily having impact on the rest of the wider system this can make it easier for teams to work in isolation or more previa tana meet of teams so you know your team can work with your service by itself they can make decisions about when to deploy this also works really well when you're trying to you know get teams to own more of the end-to-end sort of operational responsibilities for your software hopefully it also means is that you can get you can have more developers working on a problem without getting in each other's ways so if you know if if you could sort of break apart the different parts of your overall product or the overall system give those two different teams to own and manage if their services are also created in a micro service style they can be changed and evolved independently from each other and that's a that's a really important idea and then this idea of autonomy of it sort of firm cut through a lot of what we were looking at for micro service architectures James Lewis who these early people looking into micro services he wrote the original article over at Larsson Fowler's website now he's saying that Michaelis says so that micro services are in architecture which optimized for autonomy and so by picking a micro service architecture we're sort of saying that autonomy is really important to us and so we're gonna pick micro services because hopefully it can allow us to go faster work more in parallel its interest and this idea of sort of empowering teams and allowing teams to own more responsibilities you know it cuts across a lot of the shifts we've seen in IT development over the last 20 years if you think about the public cloud for example I touched on this in my keynote a big part of the public cloud is about allowing direct self-service access so rather than having to raise a ticket to an Operations team and say please can I have a machine instead you could go to your own dashboard and click a button to get it or even better write some code or use some sort of automated scripts to spin up the machines that you want as in public clouds have been credibly useful in terms of further empowering teams and giving them more autonomy and to autonomy here largely through the ability to sell service other benefits as well that come with the public cloud as we touched on in the keynote and really when you get down to what the public cloud is it's a succession of higher or lower you know multiple abstractions over underlying physical infrastructure you know you think about the core sort of infrastructural building blocks of storage compute networking rather than actually dealing with the physical aspects of that we're working with abstractions that allow us to reverse abstractions and so we're dealing with these things at a slightly higher level I don't have to go and connect a network cable I could write a for loop to connect a 10 20 or a million virtual network connections and at the base level we first thought probably third cloud first came out well I said she's not true but what really caught the imagination of public cloud early on was really quite you know the grand scheme of things low level abstractions over these three you know these three primitives of storage compute and networking we used to talk about the cloud using these these three these four letters IaaS infrastructure as a service so that's what that was the term used to describe what AWS were offering taken as it was emit a bit of a misunderstanding but nonetheless it's a term that's still in some widespread use infrastructure-as-a-service is really talking about those cloud abstractions that sort of are quite close to the physical counterpart right we can imagine when I connect a an attached storage device that's like plugging a disk into a machine and when I open up a network connection between two machines is like liking a cable in potentially so the the analogies between those two things that are quite similar and of course you know we've gone from in this world when we talk about compute in the space of infrastructure-as-a-service what we're normally talking about I'm spinning up a machine what I'm actually doing is I'm spinning up a virtual machine sitting on top of physical infrastructure and to the cloud provider they call an API to say spit up an ec2 instance on AWS for example well the scenes what's actually happening is you know that API call is hitting a virtualization layer running on their physical infrastructure and it's spitting up a virtual machine for me it's handing the networking and then passing control over to me and you notability that from a from a functionality point of view is quite similar to what you experienced VMware albeit with a nicer control plane on top so that's sort of infrastructures service and so quite low level and then we started kicking a bit looking at other types of abstractions and containers have become a big hockey fan scape certainly for people building sort of systems on top and Linux basis operating systems containers have been around for many many years and Windows actually the story around containers and windows and Raman it's been getting a lot better you know since really 2000 and Windows 7 2016 containers have been supported much better within the windows ecosystem although there's still definitely work to be done in terms of the size of those containers because you know even with things like nano server and stuff you know we still looking at quite large containers in the windows ecosystem compared to analytics ecosystem but but the but you know where we are it's an improving game but now many people are thinking about the container as our unit of deployment which you know is a slightly higher level abstraction than on a virtual machine right we sort of we're dealing with something else now is sort of dealing with a package of of operating system and our application together and that's our now our unit of deployment whereas before I would bring up a virtual machine have to plow the configuration for that virtual machines operating system let I'd put my software on top then I could figure that and then it was deployed and now we've kind of got a single unit and and part of the container metaphor sort of you know more subsequently has become this idea that you know you can treat a container like a black box it has common and your common interface to work with that container but just like shipping containers you don't actually have to care too much about what's going on inside so you know I'm deploying containers but I don't really content care if one of them is implemented Java the others implemented Ruby implemented and of course I could be having you know different operating systems running side those containers as long as my container platform lets me run those types of containers on it I shouldn't actually care about what's happening inside that container so for the point of view of a deployment activity I'm sort of further abstracted from the detail I'm not having to get deep in and configure a virtual machine to run my software I'm just being given a container and I'm going splat there is a container I've dropped it on the system and this is quite useful you know with it with a shipping container all shipping containers as common standard shipping containers but had the same fixing points they have the same dimensions and what that means is you can have a common set of tools around and managing those containers you can have a common pallet all right like this it can take a contender's to built designed to take any container that container could contain grain it could contain a car against pain know a bunch of washing machines or maybe it's empty you can either get refrigerated containers that sit within the same space and so by having a common container format we also can have a common set of tools and this is really what docker did for us before docker we had containers in the Linux and UNIX operating systems but they didn't have that common packaging contract that's what docker gets in bed well this is how we could packages the image we have for a container and here's like a common set of tools we can use to manage its containers and although you know many people now run containers without you they sort of set the standard in terms of what that format should look like and how we should work with that so we've gone from say physical infrastructure to virtual infrastructure virtual infrastructure to infrastructure as a service having a nice API control plane we've then gone a bit above that and we're now thinking about Keynes as a way to build and manage and ship our productions but then when you start looking at the world of the cloud there are just so many offshoots in terms of how you might want to go about deploying and however you might want to go about managing things and it can become a bit overwhelming so I'm gonna take you through a few examples of how we think about deploying and managing it so if I was in the world of say just purely the docker and I wasn't worried about with kubernetes Easter I just went to containers maybe I would spin up a virtual machine maybe an ec2 instance and I run the docker engine and it's a docker engine is gonna manage the isolation between these actually makes provisioning these containers and managing isolation those contained and so I could spin up multiple instances of my service each instance of my service or different services could be running in different containers all running on that same in this case this could be a virtual machine so I could take a physical machine break it into virtual machines I could then take a virtual machine and break that up into lots of containers and those containers from a resource point of view are quite isolated so I can say ok this container has this much memory and especially CPU the isolation isn't as strong as a virtual machine isolation but it's still really quite good I also get this property of uniform deployment this is what docker gave us was a managing containers on a single machine but of course we want more than one machine we might need more than one machine to run a platform because we want to handle more scale or because we need to handle the failure if one of them our VMs dies or one of our physical machines dies we need to make sure we still got enough instances to serve the traffic from our customers and so there are lots of the solutions that came out in this space for managing contains across multiple machines but the one that has very much one of course has been kubernetes so kubernetes gives you a way of managing effective container-based applications across multiple machines and one of the things it does really nicely is this property is this thing of is this thing called desired state management so with desired state management you can say something like I've got a service I want to make sure there's at least five instances of this service running across all the machines I have and if one of those is dies kubernetes has been up nothing for you if one of the machines underneath that dies kubernetes will also rebalance where your services are running and that's a really really powerful idea and again so this is another higher more high level abstraction rather than having to worry about an individual container kubernetes is just saying well I'll deal with all the hassle of where they're gonna run for you you didn't have to worry about that you just tell me how many you want and how big they should be and I'll sort the rest for you and you see the sort of inexorable march this is this is the story of computing a Cheeto developers we're always looking for more powerful abstractions because as we create better abstractions we get to do more work right we get to do more things with our time it makes us more powerful because rather than having to do all the time with a low-level detail I can abstract away that detail instead work at a higher level and get more done you know we don't many of us I suspect most of us do not code in machine code anymore nor do we code at assembly code we use higher-order programming languages because that turns out to be much more effective for most software development sometimes cases where you do when I go quite low level but most of the time you're very happy working at the level of sort of sort of general-purpose programming languages and the same is true for how we think about working with our infrastructure and with our sort of cloud or Clara Bay in Sweden we might want to go quite low level but a lot of time we're happy being higher up and kubernetes gives us our more highly abstracted platform for working with containers but but when you look really containers you say well ok with virtual machines I take a physical machine I break it up into virtual machines and those virtual machines allow me to sort of have separate isolated execution units on the same physical machine well containers sort of do the same thing in a way and you could argue that containers are just a maybe a better better from a developer point of view form of virtualization we've basically found a way of breaking apart a set of resources into isolated sets of resources that can be pegged to certain processes so maybe you know if you look at it I mean although containers are often much better from us from a developer point of view they can be much more cost-effective because it's not as heavyweight as virtual machines they allow us to run those containers on laptops more easily than we might be able to do with say VMs and things like that they're arguably they are just a different type of virtualization from from that point of view but maybe more useful one so let's talk a bit about service and serve us a term service has actually been around for a lot longer than people think the originals of definition of service as far as I have been able to tell they've asked lots of other people about this and they'll come up the same answer actually comes from an article by Ken from and so Ken wrote the piece about the where he saw the future of software and applications going and he talked about it's being serviced they actually wrote this article back in 2012 which is sort of interesting so he said the phrase service doesn't mean that servers are no longer involved it simply means that developers no longer have to think that much about them and what he was reflecting on here was a whole host of services and products that sort of abstract away from developers the concept of the underlying infrastructure we don't have to work at a computer level anymore we're working at some a higher level of abstraction and so there is as you know so service is talking really about an observer right the observer the people who use service software they see it as having no servers effectively that's us as developers if you're running this on premise of course a service stack of some sort your developers in house might see it as service even though you as an Operations team might have to manage those computers now this was articles written about twelve but what seems to have happened is that people have reduced the concept of servers service - just meaning functions function as a service and they're saying well when people say service what they're actually talking about is function as a service that's I think it's unfortunate because I think that really misses the point of service service is not just about function as a service it's about much more than that so we've got yes function as a service which we're going to explore in a bit more detail in a moment but it also encompasses database as a service platforms think about something like cosmos DB or dynamo DB you're not worried about the Machine or how many machines you have you are basically sort of operating in a pay-as-you-go environment you are just creating tables and letting the platform underneath that work out all the details you're abstracted away from the underlying servers it also includes things like storage take a look at something like AWS s3 all you do with s3 is a blob store services throw data in you stick it in a bucket you have a hard maybe have some instructions that bucket if you don't have to worry about allocating disks you don't say I'll police add another one terabyte disk to that you just throw the data in and you're charged for what you use we also have messaging products the very first service launched by AWS was sqs in 2006 sqs is a service queue based messaging product you don't have to manage it you just put stuff in it comes out that's a service product offering their second ever products offering was AWS s3 also launched in 2006 that was also service so we'll though we came to see AWS as pushing infrastructure as a service the very first things they launched are very much things that fit the model of service so some was this idea that maybe the future arrived a bit earlier than we were ready for but there are many more things when you look at those cloud-based services and those cloud offerings there are lots of different things that fit that model if we look at specific AWS which I know a bit better than Azure you know dynamodb that's a back-end as a service Amazon s3 as blobstore service and of course for cloud functions we have AWS lambda so a dab if lambda so the first of what we think of now as the cloud function platforms that was launched that's launched in 2014 that was two years after ken came up with the term serving us so when we were talking about service there was no function as a service concept really in widespread use so this idea that now fast is what all services is sort of also doubly not true but we can think about this service product offerings like lambda like DynamoDB like cosmos DP like Azure cloud functions we can think about them as just another in the step of our another layer of abstractions in how we work with underlying physical resources so we can work if we want to with the underlying physical machines but then we started to virtualize that infrastructure so I a virtual izing the compute network and storage building blocks this is where you're using vmware or using the managed VMS maybe on your public cloud providers and then we built higher level abstractions on top of that we created sort of container orchestration as a service systems like kubernetes or maybe we're using managed relational database service it's like on them AWS for example I could spin up RDS which is a relational database service and although I'm sort of scaling it to an extent by a machine I say I want a machine this big it's actually handling a lot of the management of that machine for me so again it's a higher level abstraction over the management of that database and then on top of that we've now got even higher level extracted services we've got the function as a service platforms the back end as a service platforms those messaging products I talked to about I mean think about is your event hub right that is a service messaging product I've hidden even more of the detail away from me and I think it's arguably you know who evil we sort of also have platform-as-a-service stuff that sits on top of this you know things that give you even less control maybe but hide even more of the detail away from what you're able to do as we go up these layers of abstractions we reduce the amount of overhead that we have from a point of view of operational management but as we come down these layers you have a lot more low-level access and a lot greater control over how the system works so if I've got if I have direct access to the physical machine I have a huge amount of control over how things are done but I've got a lot more work and so whenever I work with teams on these sorts of things it's like we have to find a happy place ideally you want to give away as much as possible right and do as little work as you can but can you see to that control I think often people can give up more control than they realized and so I've been looking at all this picture I sort of came to realize that I sort of think of containers it's like a better virtualization but I feel that service and what service has done is really started I don't think we're we're entirely there yet but what we really have done is we've created better abstractions like better more developer-friendly abstractions so you know maybe we're containerization is a better form of virtualization I think the service products for a better for the fraction they kind of better developer friendly abstractions that hide away the operational work that's needed now you know I said very clearly that service isn't just fast but function as a service is one of the most interesting features of product sets under the service banner and I think it's good important to explore that and especially as what we're going to come to is looking at these function concepts in the context of micro services so the way sort of fast works is when they're quite straightforward right you've got a developer a developer create a function and so a function could be as simple as something's called raising voice it could be one method if you wanted to in practice it might be a bit more than that and you then deploy that onto a fast platform so this could be power functions this could be lamdaur whatever else what you then do is you can configure that function to run based on some event so generically talk about an event and an event could be a file being delivered in certain bucket it could be a page GTB request coming in over API gateway it could be a message being received it broker whatever so as these events come in the the fast platform will spin up dynamically spin up an instance of your function to serve that request and you're not having to configure the hosts he notes everything to say I want five machines that have got you know this much CPU that have this sign of IO profile actually all you can really do nearly configure with these things as you say my function when it runs needs this much memory and that's it and the fat form without you being involved says ah a request has come in about to launch a function here's a function to serve that request and that's done all without you having to be involved whatsoever you only pay for what's running so if you have say a virtual machine running 24/7 you've got to pay for 24/7 costs with a function you only pay if the function is invoked if it's not invoked you don't pay and so this can actually lead to making some significant cost savings I mean there's some variables around that but you know if you've got a system that maybe he's only used for two or three hours a day you could deploy it as a fast platform you don't have to worry about turning the Machine off and on again like a lot of people do so a lot of people if they say only gonna use a machine from nine till five they'll turn it off at 8:30 in the morning they'll turn that machine off at 5:30 in the evening then maybe they can automate that but it's a bit of housekeeping you've gotta do with a function and so platform you don't have to worry about that if no calls are made nothing gets launched if nothing gets launched you don't get charged that's really nice idea the other thing is it's gonna handle scale for you as well as gonna scale up and scale down as you get more requests coming in it will automatically spin up more instances and you can you can limit how many instances you allow because of course that kind of a cost implication but for me can I get a property right if an instance dies another request was launched a new instance anyway it was scale up as it needs to and kind of importantly as that traffic goes away it would shut those zones down for you and they'd not need it anymore FUNKER fast typically these functions are designed to be short-lived so originally you had quite short durations for these things I think I want to say we're lambda might have been like five seconds or thirty seconds or something like that you're now up to sort of you know on the different platforms vary but you know sort of 15 minutes can be for some of these but you look exactly our platform to know how long they run for but they are designed to be things that kind of react to something do the job and then shut down again so you're not looking for long lived processes so if you do need much longer lived processing function as a service probably isn't the right fit for you under the hood the way these are forms of working is with containers so when you a call comes in to launch your function but the fast platform is doing and spitting up a container instance running your function on here you don't have to deal with the container that's hidden away all you do is you give them their you give the fast platform your code and it deals with all that work for you and that's a really great thing again it's a more high-level abstraction the containers great but can we may take a queen could we design it in such a way that the developer doesn't need to worry about that container let's hide that detail from them that's exactly what fast does it allows a developer to just focus on code and the operational work is done by the platform itself now I have mentioned some of the constraints you typically have a restricted execution time you also do have somewhat limited runtime choices now this does vary that's with the execution time varies from platform to platform Google Cloud for example is really behind you know number of run time choices then you've got JavaScript and you've got go and I think there's I think Java might be in beta I'm not even sure the other two are not even sure if if the Python stuff is out of beta yet either as you actually got the broadest offering in terms of different runtimes theoretically you can run a Windows bat file as in a Windows batch file on as a function I mean you shouldn't but you can you could also run things like PowerShell scripts and functions - which can actually quite useful sort of maintenance administration tasks and I'd be sitting pretty well as well but I say as you has got the best its broadest set of runtime choices at the moment you also obviously have a lot less control like it's not just that you don't have you can't pick a programming language you you you you have to stick to programming languages that are supported but you may actually only have control over sir you might only have access to a certain number of versions of the runtime for example so if you've got a function that wants to run Java 5 you probably you know that's not going to work you're gonna have to be ready Java 6 or Java 8 or something like that so you also really have to rational point of view so from a sort of the only thing you really get to control is what code gets run how it gets you know what causes that code to get run and how much memory does my function have that's kind of it you can't do anything to configure the underlying operating system or anything else and also these functions are typically considered to be pretty much stateless so that means that an event happens I launch my function I do some work and that function vanishes again when another invocation comes in and that function gets launched again you can't share any state from the previous function invocation unless you've offloaded that state to something like a database so you can't be holding state in memory I and this also kind of means that so we treat these functions of being almost entirely stateless it's not totally true though because there are a couple of exceptions to this we'll come back to that a bit later on but in general you should think about functions as being entirely stateless which also by the way drastically simplifies your programming models it makes your life much happier if you can stick to a stateless model for trying anyway now coming back to micro services with minute talked a little bit about the concept of data ownership because this is gonna apply in terms of how we start thinking about function that now one of the things we want with functions is we want this with the services is this idea of independent deployability so we have this idea that a service owns its own data management and so if another service wants to get information if a service so the customer service e wants to get data from the invoicing service rather than you know reaching straight into its database instead you go and access that data via some sort of well-defined interface and the reason we want to do this is because we want to have very clear explicit service interfaces that we maintain compatibility ability of so that we can make changes to the invoice service safely so if I want to maybe make a change to invoicing on a deploy I want to know that that service interface is still compatibly my releases if I allow people to directly access my database and really access my data storage it then becomes a bit of a problem can I change how that data storage is done can I rename a column can I add a new constraint and the artists we should kind of not sure anymore because you might break that other consumer and so we talk about if it's eating viewing a micro so it's like a big black box right how the data it sort of manage is a hidden internal implementation concern so we don't want these sorts of that backdoor access and I want you to hold that thought on the back of your head and we start thinking about how we move into the world of functions so you know we tend to think of a micro service like as a collection of business functionality hosted on a network endpoint and you know often we package this up as a process we put that process into a container and we launch it so the first question is how do I map from a service to functions now actually in a lot of situations you can just map them one to one but it does depend on how big your services but some for services that might only do a small number of things mapping all of your function code that yours code into function a single function actually is very very good starting point and could work absolutely fine if you want to go finer grained than that and that's might be a common thing is you might start to see well actually I'm going to break all the things that my invoicing service does down into a series of functions well then the kind of question is well how do you find what what what things what mechanisms do you use to identify which functions you should create should I have a hundred function should I have a thousand functions do I take each method in my service and make each method a function in its own right and so you don't want to do that you don't want to have tens of thousands of these functions and it's you've got a real need if you do decide you want to go finer grains than one service or one function the piece of advice I'd give is to start looking for how you work and manage your sort of aggregate so your bits of data so this so that's an initial starting point would be to map the all the functionality about managing a single aggregate to being one function initially at least so inside by invoicing service we might work with and manage say an invoice aggregate and account aggregate and order aggregate so these sort of represent you know things with identity things with state and do you see also see consent have lifecycle associated with them and if you look at your service is pretty lots of things that are aggregates that you might manage within a service boundary and so if you know you're gonna start mapping these into functions a good place to start I say well actually we're gonna do is I'm gonna take all the code for managing an invoice and I'm going to create a function for managing that invoice aggregate and so any calls related to changing that invoice get handled by my function and this is where the word function kind of gets a bit amorphous because all really you've got with these things we talked about deploying a function what you're doing is really deploying a package of code and you have one of those functions which is your entry point for execution so when you're HTTP calc think it's called it's going to hit a function in the top of your function bundle that function could call other functions so there's no reason why you couldn't have one single entry point for all invoicing functionality for example and have an handle the whole life cycle around invoice single function boundary by keeping all of the code associated with managing a single aggregate in a single function it becomes much easier to make sure you're properly implementing the state machine around that aggregate and so if I have three aggregates here maybe if I go find a grain I may be looking initially at my invoicing service now actually testing of three separate functions now I saw now I'm getting into finer grained deployment so now I could update in Chow the other side of the invoicing is done and just deploy that function by itself which is you know kind of useful now if you're moving from say deploying your your service one big unit two now moving it towards lots of little functions you also have to give sort of jus thought to what's happening for people outside of your service boundary and my advice here would be that if you're deciding it's a big service down into smaller functions that you still try to hide that from the outside world so if the points of view of your consumers they think they're still talking to an invoicing service but behind the scenes what actually happens when these calls come in is they're just being dispatched these individual functions so from the outside world they think a single invoicing micro service exists from an internal implementation detail point of view though you're implementing that invoicing service in terms of lots of little functions and that's that sort of you want to hide that implementation detail because you might change your mind about how these functions deployed you might decide you know what I don't want to have twenty functions I'm gonna go back to one or I don't want to get rid of functions and go back in this is a container on kubernetes and if you've kept the external interface the same you can do that safely without impacting your kind of customers and yeah well not your customers your consumers which are nearly always going to be your own colleagues who are calling your service from something else that's good last about talk this talks about the outside world but what about you know about the database right so if I've broken my invoicing service down into say three functions from edging three different aggregates or I broken it down even further maybe I've broken down a state transition into a separate function which you which is what you can do if I take it to the extreme degree then well how does that work in terms of accessing my data at my database because we sort of said before that we don't want lots of things accessing the same database except courses coupling this is something we've got to consider because I mean once service because something was all in three five ten fifteen twenty functions and all of those functions are sort of all accessing the same database that starts to look a little bit like having lots of services talking to the same database he said we didn't want to do that because that creates coupling between the functions and the reality is if you're breaking functions down to be individual state transition on aggregate then those functions are inherently coupled anyway so what I tend to try and think about this as I say look these functions implement this service to these 5 10 15 20 functions they all would in the invoicing service the invoicing service manages a set of data and so as long as you kind of have that idea that logical association between the functions and the service then you can still have this working quite happily right so you can kind of think of now rather than one service owning the data now you've got a logical set of functions which implement the service which own the same data so my invoicing service which consists of lots of functions has I still can all access the same set of data because they all have seen conceptions the whole thing there were ok by the same team for example if you start seeing that different people are working on different functions a lot that might give you cause when I try to call those functions out of the invoicing service per se you might also want to pull that data out well now where these things get confusing in the world of service of course is that the data bases in in this world are a little bit different you know we think about a relational database we have typically with a relational database we have the idea of a schema so one relational database instance can support multiple different logically isolated database schemas so I can have you know my invoicing schema as all of my invoicing data is inside that invoicing schema and I can control who accesses that invoicing schema and that invoicing schema is owned by me the invoicing service and so that kind of idea of that of logically isolated data set is kind of really useful in the world of relational databases and other non relational databases to but when you start looking at the world service databases there those abstractions aren't necessarily there and there's just so many more options right so when I'm thinking about Azure I've got table storage I've got a cosmos DB on Google Cloud I've got a big table I got spanner I've got datastore on AWS it's simple D be dumpy I've got a drawer service and these are just a subset of the service datastore option database option right there right these are just the first you know eight I could find now in reality the list is a bit shorter than that because no one uses a table store which was simple DB anymore but you know it's there's still a lot of options out there so you're gonna have to pick if you want a service database that actually kind of having that nice property of not having to measure detail you know you you could have to work and assess these different options out there or or service is quite different DynamoDB or or service on database is much more akin to a relational database than dynamo DB is dynamo DB looks a lot more like a document database it's closer to a document database like I would say as its accomplished cosmos cosmos and dynamo DB a kind of a similar-looking databases and so that's that these databases have those from different characteristics so on dynamo DB do for example on cosmos DB I don't concept of a schema with a set of tables in it that can be locked down what I actually have is I have a table now these tables in dynamo DB and cosmos DB aren't like a table in a relational data store they're much more like a dough base you can imagine like a JSON document right right but can have multiple nested columns inside it and so often you don't need multiple tables store your data you might get away storing all of it in one table that has sort of bit more complexity around it so here's my invoicing functions using stuff from the invoicing table and I've call so got a customer table over here and my issue invoice function needs invoicing data and it needs customer data okay so I've got a customer table I've got an invoicing table that's fine okay but I've also got some stuff for managing customers and they need to talk to the customer table and it starts to look a bit like messy right it starts to look like we could be getting back in the world of everybody'll accessing anybody else's data because remember we still want this idea of so logically isolating our different service boundaries so here well I've got you say team a look exhaust fitting service and team B looks after the customer service and the customer service manages that customer data this issue tis a function shouldn't be directly accessing somebody else's data that's not what we want right because this is just as bad as one service reaching into another services database the key thing here is though that these different tables are I have you know others if you've created them both on the same account they're both available you can just go read them you can go view them if you want to what you actually have to do is sort of you have to yourself put in place that idea of the of the sort of schema type abstraction over the top of it because what we really want to do is say okay what I've got is my black box which is my invoicing functionality and on my black box which is my customer functionality and if I want to go between those black boxes rather than going through the direct access to somebody else's table I still should go to a function so I shouldn't if I need to customer data I might go and use the appropriate function to access that customer data now that the challenge is because we lack this logical abstraction of the schema with things like dynamodb and cosmos DB limiting access is something that you end up kind of doing either at the account level or using access roles so you could actually create an access role for the invoice service which can only see the invoicing table or an access role for the customer service that can only see the customers table so I've done this before by using effectively prefixes on table names and applying that as part of the identity access management rules so this role the invoicing role can see all dynamodb table is to start with the prefix invoice - and then that way you can kind of get some level of grouping that's a bit of work you have to do yourself to create those abstractions I did say earlier that these functions are typically stateless that's not there's sort of not quite true there's AWS everything called state front there step functions now step functions don't really let you have functions themselves which have state but it does allow you to pass state from one function to another if you look at step functions work you basically kind of create designs maybe the wrong word but a step functions gives you a way of sort of sequencing a whole bunch of lambda functions they get executed in a certain order when one function finishes it passed the state on to the next function it looks a lot like a workflow management tool or BPM I'm actually a bigger fan of Azure durable functions which i think is a much smarter developer friendly approach whereas step functions often as you end up wading through huge amounts of Jason to coordinate multiple functions working together with durable functions it basically hooks into reactive extensions so I can be I have a right piece of c-sharp code and I could say okay well I want to go and execute a function now so I can go and say here's I'm gonna do an async await on this other function invocation and what happens when that async away execute is that your function gets suspended it executes the other function once the other function is completed it comes back it starts your function up again and the results of that are passed back to you so it's sort of stateful but that the word state with all is sort of is it interesting it sort of has very specific meaning what's actually happening beneath the hood if you've ever looked at things like continuations and that's basically what the durable function stuff is working it's really really interesting now at the moment I think it's only officially supported for c-sharp on Azure but then Microsoft has said that they are going to roll out durable function support for all the languages they support so it there's a I think the Java doable function stuff is in beta at the moment so it's well worth looking at if you're looking to build more complex flows and I like the idea of keeping that stuff in code rather than sort of having to push it out to some sort of separate Jason type a structure because it becomes hard to see how things hang together whereas with durable functions you've actually got half a chance of like actually following the code flow and the flow between its functions within the scope of just by observing by sort of walking through your code I've mostly so far been talking about on-premise sort of thought as a public cloud based services and the reality is that the service offerings are significant public cloud and are very very very poor on private cloud part of that is because a bunch of the sort of the are the things that the service products do behind the scenes is just working with things that are difficult right like lots of file servers and all these sorts of things so we don't really have something as good as Amazon s3 that runs on premise because the initial outlays in costs are just enormous right you don't get to say I'm just gonna store a gigabyte in a blob store I only want to pay 10 cents an hour because step one in implementing an on premise blob store you know involves giving a seven finger chips and their app for a big filer or sand to sit somewhere in your data center so there's some challenges there but there's something like function as a service there are open source frameworks out there to give you fast light capabilities you can look at something like open fast for example which the framework that you run on top of kubernetes they can give you that sort of function invocation type experience it's not as fully featured as the fast platforms that exist for on a zero or on AWS but you know it's still a good approximation of that we've also seen Google are moving towards this thing called K native and so K native is going to embrace this idea of fast type implementations and other types of service products that you could run on top of any kubernetes platform the idea being you could go from kubernetes platform to kubernetes platform and have access to some common service type offerings the one caveat I would say about Kay native is that it's quite early on in its evolution Google have decided to take K native private inter it's evolution they're not developing that specification in the open like they did with kubernetes they're gonna own that then drive that themselves and Google's track record in in kind of getting technology to a point where it's stable enough for use as in you're not getting lots of churn and change hasn't been great it took a long time for kubernetes stabilized sto is still not stabilized and Kay native is being built on top of this do so maybe k native will be the future I don't really think it's going to be the present for many of us because even if maybe it works now they might quite completely redesign it in six months from now and yeah we'd have to expect that to happen now if you're interested in playing around with any of this stuff I think if you want to see this sort of really appreciate how powerful function as a service can be I think you spend half a day half a day playing around it pick a cloud platform of your choice and and start working with it now the out-of-the-box experience for setting up functions on these things is a lot worse than it should be and that's why I tend to point people towards a tool like the service framework so the service framework gives you a really nice command-line interface for packaging your software deploy it onto these cloud platforms executing them from your you know fax your terminal you can pull down the logs you can you can rollback versions and everything it's a really really nice tool chain for working with function as a service on you know sort of AWS cloud Google Cloud or Azure theoretically its platform agnostic right so the command line is kind of platform agnostic so you almost don't care from a command line point of view if you're talking to Amazon or Azure for your function but the reality is it's not as simple as saying I could just dynamically run those functions and either place more configuration than that but it is well worth a look and and and I think that the nice thing about the service framework is it's also it supports lots of different programming languages some of these sorts of service SDKs out there a specific to certain platforms like you get ones that are just for node functions you get ones that just Python functions you can go straight to the underlying cloud platform if you can go and use their consoles and stuff to do your stuff with a graphical user tools I would urge you to start with the service framework just initially because what you do is you can configure your function using a bit of code you can have it checked in you can fully automate your function creation deployment management and development life cycles from the beginning and that just that workflow is just so nice it's definitely worth taking a look at the service framework spend two hours at some point this week over the weekend you create a couple of functions play around with them and you'll just get start to get a sense of just how awesome they can be from a developer point of view so just to summarize you know we think about service we should put service in the context of this continuing drive towards having more and more powerful abstractions creating higher and higher order abstractions over underlying infrastructure that allows us as developers to get more stuff done I think the current crop of service offerings may not be the future I think there are better things to come I don't think they've really delivered on them full promises of this stuff yet but they are well worth exploring for many of the organizations I'm chatting to who are looking to move to the cloud I'm suggesting you know what maybe rather than trying to kubernetes fire your application maybe I should start looking to see if some this stuff could be functions instead use go straight to a native fast platform it can open up some you know significant benefits I mean above all all the server stuff is by abstracting away more and more detail from me it's empowering me more as a developer to get more things done myself which in turn is gonna help this drive towards independent deployability so in summary serverless think of service like more developer-friendly abstractions it's allowing us to do more to sort of own more responsibility without having to do more work it's making us more productive as a result functions can map really nicely to microservice boundaries you start thinking of your function you have a one-to-one mapping from a micro service to a single function we're going to break it down further you can go from the aggregate to function trigger even further again you can go from the state transitions of an aggregate down to a function as well but just if you're going to do all these if you're gonna start having lots of functions still have this overall arching idea of a collection of that worked closely together and keeping data ownership within that sort of logical service boundary I've got a bunch more stuff on service over my website I've got a video I did for Riley that you can watch as part of their online learning platform I've also got other talks on this stuff over on my website as well which I'm easy to find on the internet but thanks so much for listening along we have got some we've had been having questions open on slide oh so I'm just going to spin that up on my iPad it's trying to do face ID but I've got my headset on so it's getting confused so I should see if we've got any questions have come in on slide oh I'm just gonna open that up again and refresh that so while I'm opening up slide oh this is a chance for you to ask any questions so there's a little bit of a delay 8 6 0 okay let's take a quick look here we go this is a good question here from Eric some Eric says I didn't catch you say much about performance taking containers up and down sounds like a lot of overhead especially in cascades of east-west calls so what Merrick is talking about really here is what some people have described as the as a cold spin up so a request comes in and I have to launch a container to serve the request coming in now the time taken to cold start a container like that could be quite long it relatively speaking if you're working in a programming language like Java or or c-sharp the the nature of those runtimes mean that have a bit of a longer ramp up time if you're working with something like Python nodejs go they spin up much much faster so how quickly a cold spin up occurs is gonna vary from platter from run time to run time so if you have to have very very fast spin up time so that's something you might take to take into account the other thing is that the the underlying fast platforms are going through huge amounts of optimizations to keep that cold spin uptime as low as possible they're doing lots of things about sort of optimizing things at the JVM and the CLR to improve those spin up times you might look into things like the firecracker VMs and stuff like that the Amma's are doing to to make those things that contain it invocation even faster their third things going on here is it's very rare you actually get a cold spin up so what actually happens so certainly I know this happens on AWS I'm not I'm less sure about how it works on this year is Amazon actually keeps a sort of live copy of your container knocking it keeps it around so although it's not executing once the function stops executing it leaves that container where it is but it's in a dormant state and so in the end though that execution comes in they divert it to an already launched container instance I said it's like it shuts down again because of the point of view of the function the function does shutdown again it does vanish you know you don't have any state between those functions but actually they can to the runtime that held that function can be kept hold of by the underlying cloud platform and so that she that might and I might keep that around for hours and so you it's very rare that you'll see a full cult spin up time if you wanna see more just check so what you might want to do is to take a look I'm just taking a look yes oh really interesting posts out there I can certainly see let me just put a link on the cloud share though if the thing to search for is cold start up time or cold start time there is a just an article I read a while ago that might be a bit out of date this is they W a specific but it goes a little bit into some of the detail around these spin up times so so you might be interested in reading this article on how AWS does it this is actually somebody from the outside in trying to look at how how long those things are kept live for it also talks about the link between memory size and spin up that's the other thing you do live thing about aspect around performance is you can sometimes see a bit of variation in performance when you give a function a smaller amount of memory so like 128 256 Meg's what you will often see is Amazon will actually and Isis you may do it as I say as you it is the same so AWS said okay well I'm gonna give you at least 256 Meg and that's also a proxy for how much for CPU you get but if it's more spate that most performance available to you they'll let you use extra capacity so what you'll see is with the smaller function sizes you'll see a bit of variability in in how quickly those functions execute whereas actually if you want guaranteed far throughput you often better picking a larger memory size as well and that tends to relay to the underlying machine having been IO so there's so this is but the only level of control you have is that is that actual memory footprint the person to follow on this for AWS anyway is Yan Sui who's there so Yan's also the burning monk online this is actually one of his blog posts he's done so much work in this space for AWS I'm sure you'll find other in the Microsoft world I'm sure there are some great MVPs out there that can help share knowledge with you about how this works on Azure but I hope that makes sense and this is like I talked about in more detail on that I Reilly close okay now let's see have I still got my as slides up I can see any other questions [Music] so I think I've got all the questions done I appreciate that I hope the lines been good enough for you and you've been able to hear me if they've got any other questions for me best thing to do in the real conference well you could grab me in the corridor we can have a chat we can't do that here so I would say Jess just ping me on Twitter I'm just at Sam Newman on Twitter and as I said there's a whole load of information about all the kinds of the work I do and books and all sorts of other things over on my website so I hope you'll find something of interest to you and I hope you enjoy the rest of your day you

Channel: NDC Conferences

Views: 6,861

Rating: 4.8832116 out of 5

Keywords: Sam Newman, Microservices, Serverless, Serverless technology, Cloud Functions, Cloud, NDC, 2020, DevOps, Online, Conference

Id: CKLIL3Kbf60

Length: 60min 5sec (3605 seconds)

Published: Tue Mar 24 2020