Go + Microservices = Go Kit [I] - Peter Bourgon, Go Kit

so its 13:55 and that means in-room ao4 thank you we're going to talk about go and this talk is called go plus micro-services equals go kit and there's a little gopher in a hex nut there that's logo I don't know why my name is Peter I it doesn't matter who I am you can decide for yourself if I'm trustworthy or not at the end of the talk but you can follow me I'm that's my Twitter okay this talk is about so cloud native con right what is the cloud native application it's like all these things that has all these properties and one of them importantly I guess is that it's kind of micro service oriented so this talk in this talk I want to convince you that go is a good language to write your micro services in and I think go kit will help and if you want to add use it at the end of the talk that's great I support that but ultimately I'm not really pushing go kit it's just a means to express a few ideas which I think are helpful so maybe it'll help maybe it won't if you don't end up using it that's no problem for me I'm really more motivated to get you all to consider go for your business logic I guess ok so on that note like what is go I'm curious have we all raise your hand if you'd like at least dabbled and go a little bit right ok how many of you have like done serious like production work and go ok yeah still quite a few people that's great so for the maybe very few of you who need a bit of an introduction to the language like what it is where it sits and like the language matrix I thought I'd take a few minutes to kind of contextualise everything for us go was created by three engineers who happen to be employed at Google the the Apocrypha is that it was designed to solve at a language level problems that the Google engineers were kind of encountering and this is as far as I'm aware the first recorded piece well recorded maybe I guess I could have faked it but I promise I didn't the first recorded piece of information detailing the first ideas behind go the language and it is an email sort of meeting minutes dated 23 September 2007 which is a really long time ago if you think about it in in this world from Robert Griesemer to Rob Pike and Ken Thompson and the subject is prog line discussion and I guess this is the first meeting when they decided to go over what would some points that would eventually become the go language so starting point seed fix from all these flaws remove crud add a few missing features and you can kind of find this on the internet a few places so you can kind of get a sense of where they were coming from they like see but they felt that maybe it was not up to the task of modern modern modern problems so some properties of go I mean there's many of them these are the ones that I find the most interesting it is a statically typed language it is a compiled language and one of the key things is that it is the compiler should be very very fast and a lot of decisions were baked into what the language is and what features it supports in order to support this very important property so the build test run cycles are very quick and go it produces native binaries for a huge number of platforms and you can cross compile them very easily it's just setting an environment variable so if you have go installed on your Mac you can produce PowerPC binaries you can produce amd64 Linux binaries no problem it is garbage collected language which was decided very early to be an important usability kind of handle this does mean that it's not totally suitable for a lot of the things that C is suitable for but on balance the go authors decide this is the right move for the current sort of epoch that were in it looks like see basically it's got a big standard library and sort of a Python F standard library for lots of things you need to do in this modern world and it has baked in concurrency which we'll explore a tiny bit in my opinion this is what sets go apart from the current crop of languages I think it's a breath of fresh air from what I would call like kitchen-sink languages which is like the languages that say oh there's a feature that sounds good there's another feature that sounds good and to me like the canonical example of this is Scala it is a language of every paradigm which I guess you it's nice to have that sometimes but for me I really struggle to get productive in it go has an in composed of simple sort of orthogonal features that when you stick them together they don't have surprising results and to me the ultimate like counter example to this would be sort of the node ecosystem where there's lots of features that are kind of thought and developed in isolation and when you sort of apply them together well we've all seen the Gary Brent what talk right when he's going through all the JavaScript concatenation things in blah blah goes efficient by default and this is a source of consternation for many especially new go programmers that there is typically one idiomatic way to accomplish a task and that way sort of exposes all of the CPU cycles that are going to occur when you go through that text so for example there is only one way to do four loops there's no map or filter and so when you write idiomatic go it tends to be pretty efficient like not quite see but pretty close and to me this stands in contrast to a lot of dynamic scripting languages like Python and Ruby where to eke out performance you have to do things non idiomatically very often go has predictable runtime behavior and this means that when you deploy a go application there's not a lot of knobs to turn that can change dramatically the way it performs to me this is standing in stark contrast to all the jvm languages which require in my experience like quite specialized knowledge to operate a skill and finally go has a familiar heritage syntax and sort of basically an imperative programming paradigm which is familiar to most of us I guess there are things you can do you can program it in a slightly functional way you can program it and I kind of object-oriented way but in general it's like pretty straight line code and that's a great draw it makes it easy to learn easy to spin up new developers on and in that way sort of stands in contrast to languages like Haskell and maybe elixir to some degree so when we talk about languages we often like to use words like oh it's simple right or it's non magical what do we mean by these things it turns out these things these words are kind of like weasel words right so when you say simple and this is a quote I found on the lobsters what ones that when you say simple what it actually means is totally dependent on your context and in go simple means and I'll try to read this here that operational interpretation of a program fragment is unique straightforward and never in question after you've read the code so this means when you read a piece of go code you know exactly what the CP is going to do to it some order of approximation from this no-nonsense point of view higher-order functions are already suspicious and fancy concepts like closures transducers and Haskell's lenses and traversals are complete abominations I wouldn't go quite that far but I think this gets it goes idea of simplicity similarly I found another what do you call this thing a post on hacker news about the idea of no magic or magic free language and the key quote here is that a bit of code is magical when it's not sufficient to examine the tokens that the code is composed of and go back to the static textual definitions of those tokens to understand what's going on so if you look at a piece of code and you read all the things that should be enough to figure out what that code is doing and if that's not true then your code is magical so in Python Desk pseudocode this stuff on the left is magic if this code runs if you can s dot where did this method come from then like how did that happen right and in Python you can do this right and in Ruby you can do this it's called like monkey patching not magic it all would be this way of kind of composing behaviors where class something is derived from superclass right and you can go to the definition superclass you can read through what it is so go is entirely non-magical by this definition and like I spend too much time on this because I think this is maybe more than anything the thing that sets go apart from other languages like when you see go code you know what it's doing and you don't have to like worry too much about things that other programmers might have done to subvert your understanding and at least for me I love this I love it I love it I love it ok another sort of design principle at of go was captured in this talk by Rob plank it is a language that was design in the service of software engineering and this also gets at dislike industrial bent right it was created at a company that was trying to make money and that way sets it apart from Scala from Haskell this sort of thing and also sets it sort of apart from the programming language community a programming language theory community so you do see lots of articles on the internet like this why go is not good or three months of go from a high schoolers perspective and they make very negative conclusions and I think that's understandable because in a large way goes saying all these programming language theory things that have been developed and and reified over the last 10 20 30 years that's fine we can take some lessons from them but we don't need to build on them so directly and so you get classic reactions like this in fact there's an entire git repo of articles that are critical of go and they've been like subdivided into the topics that the the author has really disliked and it's called a go is not good a curated list of articles complaining the go isn't good enough ironically if you go to this repo you see that the the thing that produces the list is itself a go program so one final note about mine share so I guess go is a young language it's like seven or eight years old you can these are just two sort of random articles I found you can find lots of articles saying go is gaining my chair there's lots of interest there's lots of new developers it's not at the Java level yet but if you are kind of staffing up a project and you are considering go I think we're at the stage where you're going to be able to reliably find go developers or at a minimum trained people people are going to have heard of it they're going to be interested potentially and learning it and that's very easy so I just have this slide here to say my chair is there or like growing and we already know that right because we're cloud native people we can look at our portfolio of projects and note that a little more than half of them are implemented in go G RPC has of course go bindings linker D is like finagle for containers so I guess it's like Scala but maybe it maybe somehow qualifies fluency is written in Ruby and see if I'm not mistaken maybe it should have been written and go I don't know okay so that's like that's the go side of things now let's turn our attention a little bit to micro services part of the cloud native computing breakfast i guess my story with micro-services begins at soundcloud i won't go into the details about all of the things we learned there really suffice to say we were one of the early adopters I guess we did micro services before they were so-called like SOA back then and then slowly in the first year of our transition they became micro services and us and I think Spotify and Netflix where some of the first people so we've learned lots of lessons there and the one lesson that I want to kind of distill everything down to is that micro services solve problems in your organization but they cause technical problems they solve some technical problems but they create far far more so choosing to opt into a micro service architecture is something you should do only when you know you need to solve problems that are latent in your organization and typically this means you're big enough that well I'll get into some of them now but this is like the key thing that we learned I think so let me enumerate some of the problems that are solved for example my team is too large to work effectively on a shared codebase and by this I mean literally the mechanics of pushing commits having merge conflicts being able to push code around without causing too many like frictional problems mic receivers have solved the problem of my team is blocked on another team to make progress towards some business goal so if you often find yourself saying well like am i part of the features done but that team isn't done and so like we have a standstill in terms of our business velocity micro services can sort of break this traction right and allow each team to kind of iterate independently as long as they maintain these like strict contracts with the rest of the organization that's cool micro services can help solve the problem of communication overhead becoming gigantic is kind of like a follow-on from the previous point where you can't do things until you can like fully understand what everyone else in the organization is doing the strict contracts sort of give you an escape hatch for that and this all boils down I think to the idea that product bilasa t gets stalled and we need some way to get that back up again in my opinion this is what they solve now what do they cause in order to have any of these lovely properties we need to have well-defined business domains and in the domain driven design terminology this is called the bounded context right so you need to have stable API is each microservice needs to have a stable ish API so you need to understand what your business does before you can do that if you're still in the experimentation phase like I'm not really sure where all my business domains are going to land then micro-services are going to present a whole lot of friction for you you don't get chair databases anymore right so like micro services encapsulate their data storage that's sort of one of their key properties which means that if you need to start doing distributed transactions you're you're in for a world of pain because those are really really hard like like PhD thesis heart and you don't want to do them actually you want to figure out another way to do it eventual consistency blah blah blah that's also hard testing becomes really hard too in fact I as far as I'm aware it is a design error it's like categorically incorrect to try to integration test your entire micro service fleet you can approach that asymptotically with really strong unit testing and like contract testing and you can make an attempt at some kind of like burn-in test but really what you want to do is optimize for MTTR mean time to recovery right you have really good monitoring you're really good rollback procedures and you just kind of test and prod right with Canaries or Bluegreen or whatever so this is hardened it's like a mind shift and this and many other things we sought required the sort of DevOps culture mind shift culture shift where devs need to deploy and operate their own work and that means they need to get paged when their stuff goes down which means they need to be on pedra duty or whatever and this is often problematic for organizations you have the problem of job scheduling which kubernetes helps with if you're able to use kubernetes that's great but if you aren't then you have to kind of like approach it and realize what parts you need what parts you don't that takes time that takes energy that takes automation then you have the problem of addressability that is service discovery how to service a figure out about service fee this is an infrastructural concern then you have monitoring an instrumentation they should really be much higher in the in the list actually because this is critical this is the first thing you should be worrying about old tools like tail f4 like Maggio's and new relative it's like completely insufficient for this new world you start realizing hey we need to have better insight into the things we're deploying maybe we need something like distributed tracing and you can go next door in there and all the ballot learn all about it but you'll find out quickly that that's really really really hard it's it requires like complete homogeneous implementation of a certain stack over your entire fleet and if you have sort of decoupled teams that are responsible for doing it it's hard to get them all aligned and the infrastructure concerns are big and bla bla bla lots of problems there get the word up build pipeline see ICD this becomes important security oh there's this thing called security oops yeah I need to wire all that in once I have my first zero day or whatever okay so anyway there's like all these concerns right so a lot of people come from this monolithic mode where they have their monolith right there big Java app or whatever and then all these things I talked about are kind of like little piecemeal solutions around it right when you go to the micro service model you end up drinking your your monolith right or chipping in away and you create more of them but all these like piecemeal concerns they're they're still they're still present it's just that they no longer interact with a single deployable artifacts they interact with like multiple deplorable artifacts so the touch points right there's many many more there's like exponentially more and so the the point I want to raise is that all these concerns because like they've become multiplicative and you have to have not only like answers to all these purple boxes you have to have structure a way of like solving these problems in a reliable automated structured coherent way across your entire fleet of business services so at Sound Cloud the chief architect I don't know he's kind of a floater is a guy named Shaun Treadway there and he gave a talk similar to this last year and he did a survey and he went through all of the services in the company and counted up the number of purple things that they would need to have answers for before they could be considered like production ready so how many like ancillary concerns does a single service need to have answers for before it can be deployed does anybody have a guess what that number is 125 okay it's somewhere between he counted 40 things and some of them are obvious like what programming languages are written in and what programming paradigms was utilized what transport protocols is a talk on some of them are kind of the things that I mentioned here like what how do you do secret management how do you do alerting how do you do logs that you do log rotation what's the CI pipeline for blah blah blah some of them are really subtle like how do you do how do you register it in service discovery registry and a humane registry so when it fails you know like which person to talk to a lot of things so this is the context that we're all in when we opt in to the cloud native stack right we're want to do micro services because we understand that they can help our businesses achieve much better velocity especially as those businesses grow but we need help to structure this stuff so that we can answer all these questions in a good way and so that's where gokit kind of ventures into the picture initially I wanted it to be a standard library for micro services something like finagle for gos anyone heard of finagle or like its kind of familiar with finagle it's like solving some of these problems in Scala the idea is to provide adapters bindings etc it's a common infrastructure component to solve many of these problems it's important that it played nice in your existing kind of heterogeneous environment that a don't that it doesn't have like strong opinions about you need to structure your apps structure your infrastructure and this way you need to use console you need to use kubernetes like you have your own like opinions about that in org you have your own history your own competencies I don't really want to have opinions about that I just want to make it possible to write go and have it slot in and work well so at the end it's like just some way of providing structure to tame this beast that we've described an incidental complexity that comes with micro services so those were the initial goals today it's mostly the same it turns out over time the project's about two and a half or three years old now we've become even less opinionated about infrastructure than we anticipated and even more opinionated about application architecture than we anticipated so that's really what I want to talk to talk about today is how to structure go applications go micro services to we'll be able to solve these problems in Upland like a coherent way and I'm going to use gokit to sort of demonstrate patterns but you can obviously use whatever you like important non goals of gokit messaging patterns of you and RPC there's a whole class of micro service stuff that's so called like streaming or event sourcing or event oriented those are cool and interesting but it's not sort of what I'm focused on at the moment like I said we don't require specific types of infrastructure to work properly you can use whatever you want and we'll try to provide adapters to as much as we possibly can we don't act as an all in service framework so I say toolkit very particularly like we're not something you have to write your you're not writing like a go kit application right you're using bits of the go kit to make your application easier to deploy and operate and run and blah blah and we don't intend to re-implement existing good solutions or libraries or anything when things are lacking will provide better solutions but otherwise we'll just plug and play if you are familiar with other toolkits so their framework here's where we kind of land in the landscape micro is probably the other big go micro service sort of framework it's in my opinion from where I stand it's very opinionated it's sort of all in you have to buy into the micro ideology and its framework ish for that reason and so I stand apart from that finagle was sort of the original inspiration but in the end it's much lower level than go kid it's more concerned with like the mechanics of pushing bytes over a wire and getting bites back and it's very concerned with retry strategies when things go down and that sort of thing we go kit has all that stuff but it's not focused on it's vaguely similar to spring boot except spring boot is very magical by our previous definitions and very it's it's like own world right you become a spring boot developer I hope no one ever says that they are a go kit developer I will have failed terrified it's also somehow similar to Tokyo which is like this new rust thing but Tokyo I think is meant to be almost as close as possible to a finagle for rust and so it's also quite low level and I really want to emphasize I don't care if you use go kit I do care if you use go I I'm really sold on the go philosophy as a way of like being a happy programmer and I want to well to be completely Frank I want to create more job opportunities for myself in the future and get as many comfort as possible to buy into this but no I'd like it truly makes me happy as a programmer and like I want to sort of share that joy that's really my motivation okay so I said many times ago is about application architecture what do I mean by that so let's build up a little dummy service and let's demonstrate some of the things that I'm talking about so let's say this is our service and if you know go you know the interface I've decided to model the service as an interface and what I'm saying here is add service is something some you know box in a diagram that can sum two integers and return an integer and it can concatenate two strings and return two strings so it's like the stupidest possible thing you could write because it's a service right now we want to be able to return errors things can fail okay so that's the that's what we're building right so that's the that's the interface definition or naive first draft we've started adder addr the uber for addition or something and we need to like write our add service and and get that hot hot VC cache so here's our basic service it's an implementation of the add in add service interface we have our sum method which is just adding the two numbers and we have our concat method and it's adding the two strings and you know not much to it okay so this is our legs as I like core business logic nice easy so here's here's our here's our Red Square right this is this is our thing but there's a lot of stuff that we have to now start sort of layering on top right and the first one is a transport this is useless it's just sitting in memory we need to be able to talk to it so how do we talk to it typically we're going to do like a JSON HTTP thing right so here's our basic service one way to do it is to attach a serve HTTP method onto the struct so it becomes an HTTP handler it can talk HTTP so we're going to switch on the path and let's say if it's the sum we're going to construct this request object we're going to try to deserialize from the body you could also do URL parameters like do notice right let's just say we're doing it this way you deserialize the JSON object on the body into that thing it can fail so maybe it'll fail you use it to invoke the some method on the type okay we're just calling into our business logic cool and then you're going to serialize JSON back to the client straightforward enough okay the concat thing it's going to be the same thing different sort of types but exactly the same code okay and this is pretty like isolated I guess we have the business logic are these methods and then the transport logic is this method and like okay they kind of don't interact too much that's pretty okay great so what's next we got to talk about logging right everything has to log okay so how do we do logging here well I guess one way is you take this decode block of code and we'd stick in some log statements and of course we're going to love the errors so whenever we encounter an error we log the air and then we log success maybe at the bottom there okay cool basic information right we do the same thing maybe at the actual application layer so that was like in the transport now if we go down to the to the business logically when I maybe log the results of our computation so we log are some we log reckon cat maybe no no some strawman okay like let's say that solves the logging problem okay but now we have to do metrics of course right we have to monitor our thing okay so how do we do metrics well let's say there are some metrics defined globally or somewhere and like in the error cases we want to increment the error counter in the success case we increment the success counter maybe in the business logic we need to put a histogram for how long it took okay we can drop that in okay we've solved metrics but now it's time to do tracing and then maybe now it's time to do safety mechanisms like circuit breaking and and and rate limiting and no no we need like audit logging because we're not just like doing debug printf statements we actually care about like transactional semantics that at a higher level and then there's like this concept of service discovery they need to talk to something else and what's our deploy strategy maybe it needs to go to communities and there's like all these things right suddenly there's all these things and we don't want to like just do like little edits in the raw code right for every single thing here because then we get the spiraling unco here enlike impossible to maintain monster of the service right and I think we've all written like I've written more of these when I care to admit right so what we want is some kind of structure to allow us to solve these problems without just like editing the code for every single thing just randomly right so goki promotes the so called onion model what is the onion model basically you take your core business logic is sort of the center of the onion and then for every other concern basically you wrap that with what I call middleware it's also known as a decorator pattern and in gokit we kind of chop it up into three distinct phases or layers of the onion the innermost layer is the service layer that's where all your business logic stuff lives and that's where you're going to spend most of your time the next layer up is what I call the endpoint layer we'll talk about that and then the final layer is the transport layer where is it I have to click apparently okay this is very similar to other architectures that you might read in literature there's this thing called the hexagonal architecture where it's broadly the same model they use different terms of art like in the core it's like the core domain and then there's like a domain and application layer and then they I think this is from like Java world so of course the Audemars layer is a framework layer and then it's like interaction points to all the other services that you talk to a database a sequel server a mail server blah blah blah it's also very similar to something I like a bit more which is the the clean architecture and it's the same basic idea it's a bit more a Martin Fowler II domain driven design II where at the core you have your entities this is like your core domain objects and then as you extend out of the circle you think you have start solving different concerns so around the core entities are your use cases and here you might write some unit tests or something and then you have controllers and gateways and presenters which in turn interface with the web with a UI layer with a database with some device right and in the clean architecture that the core rule is a dependency rule which states that source code dependencies can only point inwards which is key that means in your core business domain it's like pure logic right you have your integers that you're summing together your users that are like being manipulated only as you extend out of the onion do you start introducing concepts like HTTP or G RPC right and the core stuff has no idea about HTTP or G RPC all they care about is the the business domain and that's important that's key so let's take our dumb little service and let's model it sort of a little bit as in this onion way and see where we get so we're going to take our service interface and in go the way that we manage request scope life's life cycles the way we do RPC basically is to have every method take a context parameter as the first parameter and that's just the way it works I won't get into the details here but so what will update our service interface to have that then we'll take our basic service and we'll we'll extend it a bit we'll make it a bit more interesting we'll have the some method maybe fail in some cases the concatenated can also do the same okay so now we have our core basically the same core service let's talk about how we can fold in this fun stuff at the service layer at the innermost layer and I mentioned already the decorator of the middleware pattern let's talk about what a middleware would look like and go this is one way to express a middleware that is a function that takes a service does some extra stuff to it and returns exactly the same service or I should say an interface that you can use in the same way but that has additional behavior kind of wired into it so for example a logging middleware might amend a service with a logger and here's how you would construct it right and in the some method of that logging middleware it would eventually call the next layer down but in the meanwhile it would log the things that it sees right so this is like about as simple as it gets it's just doing one extra bit of work as the request traverses through the logging middleware down into the next layer down okay what about instrumenting right so we could have an instrumenting middleware that didn't contain just a logger but contained metrics like counters or histograms and you can construct it kind of in the same way and in your sum method as the request traverses through the instrumenting middle where you can increment your counters depending on what the parameters say and in this way we can sort of create these isolated bits of kit these isolated little objects they can do solve individual pieces of this whole puzzle without complexing our core business logic or like one mega function that just does everything so you can I've showed you like logging this trending but you can do pretty much anything with this model right anything that needs access to your core business domain nice the point here is that we're going to solve each of these problems independent of the others like I said but also that we're going to optimize the way we build a service for maintenance that is for adding new concerns it's very simple you just create a new decorator and you wire it in when you want to modify an existing one you don't have to care that you might mess up the code that's doing something else because it's very single purpose like microservices itself you can kind of keep all that code in your head hopefully it's a very short little file and of course this makes it very easy to remove concerns you just delete the middleware and then hopefully that's that's it so that was the service layer that's are all the business logical is I introduced this endpoint layer what is that well it turns out if we have an additional abstraction which abstract Sauveur RPC it turns out we can do a lot of fun easy stuff there that you don't have to write that maybe gokit can provide for you so here's our endpoint abstraction an endpoint or like concat add any function really is something that can be modeled as a function that takes a request and return the response right so in go we have to do it this way it sucks talk to me later I'll tell you all about it and then we have wire in our context right because that's how that works and of course this can sail so your wire and air and wire in an error in the return and so this is what it looks like request in response this is the actual definition in gokit with this we can write it so called endpoint constructor that takes the service and constructs individual endpoints for all the methods so here's one that creates a some endpoint you can imagine on another one that creates a concatenated response types it's all kind of boilerplate that can be generated what does this get us this gets us the ability to define an endpoint middleware what does that get us well this allows us to wire in behavior that doesn't care about what's actually going through what the actual like a and B values are but maybe just cares about stuff that is only to do with the request self for example if you wanted to prevent outgoing requests from doing a thundering heard on some service that happens to be down you could implement a circuit breaking middleware that detected errors and after a certain number of errors tripped the circuit and prevented more requests from flowing and this for this behavior you don't need to know what is actually in the request you just need to see that the request is gone and success or fail right so we can provide this an effective kit provides this with a number of different implementations similarly we can do like a throttling or like a rate limiting middleware and so there's a lot of value ID stuff that can exist at this level that you don't have to write that we can provide for you that's cool what else does this get us well because we now have a stable consistent foundation of the RPC idiom we have the foundation that can we can build a lot of different transports on and so here we get into what is the transport mean the transport is the way your service talks to the world and whether it's HTTP or JRPG or whatever it always works in the same way a request comes in you have to decode it you do some stuff and then you encode a response back to the client so gokit can provide using the endpoint as like the basic building block as the foundation we can provide adapters servers to all the different transports so we have an HTTP transport here's what it looks like you give it an endpoint you give it a way to decode or request a way to encode a response and these are just like things that operate on HTTP requests right and then some options if you want to do some fun stuff and here's what the serve HTTP method basically looks like I just copied this out of the code you're going to decode the request if there's an error okay you're going to invoke the endpoint and then you're going to encode the response and there's a few other things but that's basically it so that's cool that's how you can turn an endpoint into an HTTP so ever similarly GRP see we have a G RPC transport and it looks exactly the same I mean the type definitions are different decoding a G RPC request is different than decoding an HTTP request but fundamentally it does the same thing and here's what serve G RPC looks like there it's exactly the same workflow just you know different types so this is cool this is like maybe a model of a service that we've built we have our core service we've done logging and instrumenting middleware in the service domain we've split out our two endpoints or ten endpoints we've wrapped them with you know different endpoint middlewares and then at the end we've and then like expose them on HTTP individual like little HTTP servers and at the end we've wrapped all the HTTP servers in sort of a box and we can present that on port and that can be how you talk to our service right but observe what's cool about this like we've constructed the HTTP server around the endpoint but like we can also pass the exact same endpoint to a G RPC server and we can expose the exact same service exact same business logic exact same like safety checking all the middlewares all the decorators all the way down on to ports running two different protocols at the same time right and and this is like key for me because we want to play nice in your existing environment we want to go Kate wants to be very helpful for like so-called brownfield development right where you have this old architecture and you want to kind of go on the migration path to the cloud native future but you need to do stuff like this for awhile and this sort of extends this is an example of transport kind of like adaptation but we also have the same idiom in in the metrics package so if you're currently using stats T but you want to go to Prometheus you can use a metrics abstraction that you can plug in a Sat ste back-end into it today you use that abstraction all through the code and then later you can add in a Prometheus back-end it can go to both and then later when you shut down your staffs the infrastructure you just delete the stats to the implementation that's totally fine and that's how a lot of things in boquete work in general we embrace and extend gos philosophy to be sort of simple in non-magical by these by these definitions that we talked about before in service to software engineering at the large and put another way I want to optimize for maintainability above all else so the lifecycle of the service from birth to death and hopefully all services die at some point how much time do you spend writing v1 of the service right vs. operating it I think it's like about this long - about this long right or like how much time do you spend writing code in general versus reading it I'd like probably about this much this much right so yoga is very much keeping that in mind as does go I think optimizing for reading rather than writing and so it's a bit for both in some places but I think it pays out in the end so I have I think like three minutes left is that right something like that so I wanted to quickly go through and talk about how we integrate with the cloud native stack spoiler alert it's all basically decorators so first up I still have three minutes yes okay we're going to do it Prometheus is a metrics decorator it works exactly like this we use this metrics counter I've already explained it to you cool open tracing very hard to do if you're just getting started but return to this model what is a lifecycle lever request well it comes through it traverses all of these layers right it goes to your business logic it may need to like go out call some other service right that will come back and it'll traverse the business logic and then go back out to the original requester I literally have two minutes but on the schedule it said 235 oh that's too bad alright well too bad thank you very much [Applause]

Channel: CNCF [Cloud Native Computing Foundation]

Views: 79,700

Rating: 4.9159665 out of 5

Keywords: CloudNativeCon, CloudNativeCon 2017, KubeCon Europe, KubeCon 2017, CloudNativeCon + KubeCon 2017, KubeCon Europe 2017, CloudNativeCon Europe 2017, KubeCon, CloudNativeCon + KubeCon Europe, CloudNativeCon + KubeCon, CloudNativeCon + KubeCon Europe 2017, CloudNativeCon Europe

Id: NX0sHF8ZZgw

Length: 38min 49sec (2329 seconds)

Published: Mon Apr 10 2017