The Seven (More) Deadly Sins of Microservices • Daniel Bryant • GOTO 2017

[Music] thanks everyone totally conscious that following Brian Cantrell is a hard act yeah that talk with awesome the one good thing is they don't have to apologize for talking too fast which I usually do so Brian's kind of set me up there which is great the next 15 minutes we're going to look at the seven more deadly sins of micro-services the kind of anti patterns effectively that I see and have seen over the past three or so years as a consultant working in the UK and in Germany and a little bit in the US as well it started a few years ago I did an initial seven deadly sins and I think it was devoxx UK and took on New York and these were kind of the deadly sins related to anti patterns of microservices got some traction doesn't great feedback I learned a bunch from presenting one of the reasons I like to present is to get feedback from yourself so please you know great the app right by the app obviously but come and chat me ask this as well this talk is now online you go on to info q and Ashley the talk I'm doing now is on info to you as well a slightly older version every time it changes but these are the new deadly sins yeah but there's definitely a bit of crossover from the original deadly sins the original anti-patterns but we'll go through today and have a look I'm not going to say these are more advanced they're just a bit different I noticed as microservices sort of moved into the mainstream I was working with different companies sort of moved from the innovators to the early majority if you're familiar with diffusion of innovation and different problems came up those companies have different skill sets different goals different values and all these kind of things so I've tried to reflect that in the latest version of the talk so this is me loving of over Twitter's at Daniel Bryant UK the UK at the end is important I think the other guy like we have the UK is a wrestler or something so don't tweet at them tweet at me as I mentioned software elihpa and Ben Java developer for a long time go JavaScript as well big fan of continuous delivery so I've got a book at a mini book axon O'Reilly you can grab a free copy thanks to nginx by that link there and might have a couple of hard copies actually to give away at the end as well and but I'm a big fan of continuous delivery and technology and definitely the symbiosis of the two things is super super important and micro services I think bring this to the forefront Brian to the hinted at that in terms of micro services being quite tricky from an organizational side let's dive straight in yeah the first anti-pattern and it's lust and it's using the latest and greatest technologies we're all guilty of that yeah the reason you're at a conference is probably to learn about the latest and greatest tech the challenge is new technology is great until it isn't yeah you know I'm a developer this has been me many times yeah you know go docker cubanelle sees all these good things and it's very easy to trip ourselves up yeah evaluation is a critical skill seems obvious but I've come to realize in my career that's kind of obvious things in common sense is anything but common good to be reminded of these things my mentors remind me constantly about the need to evaluate as I've moved sort of promote dev to an architect to a CTO evaluation changes how you do it what your goals are but evaluation is super super critical yeah thinking about our micro services even a good fit and I like to look at a lot of things from the perspective of business organizational staffs from architecture and operational side as well DevOps see stuff I like I'm seeing a bit of this you've got and I talked about mode to sort of the forward facing apps they should be now agile and nimble which is great they should be micro services the challenges is I'm seeing sort of middle management latching onto a buzz word and saying they're doing micro services even when they're not yeah and this have issues with evolution being limited by the existing system they redo some of their middleware as micro services all these kind of things the problem with both of these kind of things is it's effectively lipstick on the pig yeah looks good at first glance go a little deeper not so great yeah from an architectural point of view I think it's really critical to build around business functionality Everhard wolf talks a lot about and Stephane till cove as well about self-contained systems and I like a lot of the self-contained systems like microservices plus plus I'm not saying one's better than the other where they're a bit more restrictive in their design principles so I really like this notion both from micro-services and self-contained systems of building around business functionality this is where I and my team and the people companies I've worked with had the most success we're not simply reinventing middle where we're building business slices of business functionality you've got to be aware of things like cloud native as well I kind of hate the word cloud native but like DevOps and like a bunch of other things you know it's quite an open term but there is some value in it here being cloud native thinks about how the underlying infrastructure has changed over the years and therefore now we need to think about things like architecting for 12 factors or 15 factors is another another great book on I Riley about 15 factors we really need to understand the architectural principles behind micro-services ya know microservices emerge from the likes of Netflix Amazon gilt and they emerged a lot of times out of the organizational structure now many of us are kind of copying it the other way ranked so we really need to think about architectural principles finally DevOps DevOps as you know Brian hat and a bunch of great talks I've seen yesterday DevOps is many things to many people for me it's kind of end-to-end responsibility of delivery and continuing support but in my journey I've seen DevOps be everything from sort of on a spectrum if you like from developer with root access to production seen out on a few times yes right the way through to massive change control it's probably a happy medium there somewhere yeah so we need to think about these things always a company and we as an organization are we as a team good from the business point of view are we distantly so architectural point of view and do we get the ops side as well these are critical things to think about if you're moving to micro-services serverless nano services take a pic these are things I think we need to think about once you've decided to move to an architectural style that's pretty much what micro services are you need to think about technology that comes along with it more often than not you don't even need to change your technology its content thing and I'll talk about that in a second but I've seen many great systems you know on PHP built on Python bill and Java and they've literally used the same kind of stack just to build smaller well-defined services and that has worked really well I've seen many other organizations and of course this is all anecdotal based on my experience massive survivor bias and all this kind of thing but I've seen many other organizations where they say be a PHP shop and they're trying to build Java micro services or they're a Java shop and they try to build go based micro services sometimes as valid but sometimes it's not we need to think when we're going to bring in new text to the stack we need those effective conversations about why we're bringing these things in and this is all my favorite models it's not mine I've got it from a conference a couple years ago agile conference I think over in in the US actually and it talked about the spying model though we as humans are really good at using tools yeah it's what separates us from kind of our nearest evolutionary competitors but a sort of tooling has got more specific in our world I'm talking about you know Java go kubernetes ECS that kind of thing as students got more specific we often get stuck we're equally plausible options are available we don't know how to resolve any differences the classic I see for example is I like Java I like go and people just get stuck at the tool level at the bottom but I need to work up the spine and there's a whole wiki that explains how to do it to look at what are we really valuing yeah now as a team we might value a really strong strong tool chain and I think Java at the moment get stronger tool chain lingo personal opinion if we're developing for lightweight container based services and we're being charged for ram and memory no footprint then go is probably a better solution but we need to be having the right conversation at the right level of the spine and these things it just helps me as a developer when I'm getting really in the details it helps me have the conversations with my team lead with my CTO whatever make sure I'm having the right conversation at the right level I found this really beneficial definitely I look at the wiki little bit of an example yeah so to sort of bring some of these things home a classic with micro services I'm seeing it should we containerize or not yeah Dakka Dakka Dakka I think now I love docker use docker many times sometimes it's not appropriate though but this might kind of bring a few things home I think we missed a teaching point of view we're seeing this kind of thing and a hat tip to KC West here on this stuff is KC slide and so that we cram this monolith into a container and called it a micro service this is lipstick on the pic pretty much yet architecture op same kind I think you know expectations vs. reality containers just look amazing anyone who saw Andrew Andrew clay shapers thought yesterday talks about it it's great you know we just put our application in the container that's all good stuff yes but the reality is yeah this is containers but if your architecture or your operational practices are a bit of a tire fire all you end up with is tire fire in a container yeah and I'm sure if you can see the one with first responders here this is what we refer to as DevOps in our industry yet continually putting out fires up in there I'm sure you have as well in terms of the valuation be careful what you search for if you search for I should use docker in production you're going to find articles that say yes if you search for I should not use docker in production you'll get a thousand articles that say no so confirmation bias is really quite tricky the original Deadly Sins talk talks about how to overcome this a bit more but I just want to denote it's early morning I can't want to get people sort of engaged very small amount of audience participation it is super easy to be tricked in terms of bias so I'm going to ask you who things are top lines figure or the bottom lines bigger or they're both the same size so who thinks the top lines bigger there ask you cool who thinks the bottom line is bigger and who thinks they're both the same size the vast majority honest with the both the same size it's actually the top line that's bigger yes I've shifted so this votes for those don't notice a classic optical illusion and your brain pattern matched and when he's trying to be clever and then I was but in a subtly different way yes this happens all the time in tech you know even our own kind of sensibilities but definitely when vendors are involved it's easy to be tricked yes so just think now I don't say this lightly I read this book Thinking Fast and Slow by Daniel Kahneman I read it about five ten years ago now and it genuinely changed my life not my developed is my development life of my life in general it talks a lot about bias we have as humans like availability bias confirmation bias these kind of things and it talks about heuristics we use our brain is a complex um as a species we haven't figured out our brain yet you've got the kind of reptilian brain still there through evolutionary time you've got the neocortex which is a newer kind of bit of the brain and the book talks about system 1 and system 2 the reptile brain and sort of thinking brain it's a really good read it really helped me understand obviously it's not eliminates my bias because that would be impossible but it helped me understand some of the bias I bring to the table and from my team I've seen in the past when we're trying to evaluate should we move to micro services should we use docker those kind of things yeah so second sin gluttony and this is all about communication blocking so a lot of people in my experience are a bit shy of using RPC and if you're a Java developer remember I use RMI back in the day back into the 2000s and everyone's used RMI but it was kind of horrible so I think that's why many of us and there's many other languages have similar stories so that as many of us are a bit shy to use kind of RPC tooling we like rest and Jason and I do dry stress and Jason is really good really good to get started if you're looking at building loosely coupled services yeah but don't relax things like GRCC and Apache thrift and Avro there's proper interface definition languages where you specify a contract and then the information goes over the wire in binary format so it's super efficient because you're sending binary data over the wire and I like the contract sometimes the contract is really beneficial when you're trying to exchange data yeah some of the pushback I get you know the human readability of Jason but in reality when systems are in production you're not going to be reading the traffic going between services you should be logging correctly what you want to pick out you should be using correlation IDs and monitoring to understand traces you shouldn't be relying on the ability to crank open the the protocols kind of bit conflicting with what Brian said they're solely conscious of that so I think me and I agree on a whole bunch of stuff but maybe that one's a slightly different thing but I really like these kind of frameworks like they the grcc in particular I've used quite a bit there you can generate sort of clients subs and so forth in many different languages Java JavaScript Ruby is a bit wonky actual at the moment but a bunch of other things so you can do the whole polyglot thing if you want to and you can still use these kind of protocols for communicating between services I've got a bit of pushback for awhile about the kind of operability of those things and now what we're seeing is something called service meshes popping up so it can be quite tricky to do observability and so forth of and binary protocols it can be quite tricky it can be quite tricky to do fault-tolerance routing service discovery that kind of thing so things like link addy traffic and envoy have popped up now link addy at Scala JVM based on voice C++ and traffic is go so everyone's just gone of every community popped up with this service mesh idea and the idea being it runs as a sidecar to your main service main service here sidecar pattern has been around for years and basically your service communicates to the sidecar and it's been responsible for fault tolerance service discovery for routing a whole bunch of things yeah TLS termination that kind of stuff and I'm really liking this model I do genuinely think it's where micro service communication at least the RPC side of micro service communication will be going over the next few years for example envoy and with lyft and you know link D came out of buoyant they're solving really big real world problems and a bunch of other problems as well which many of us can relate to if we don't have massive systems and Christian foster from Red Hat there's fantastic article introducing the concepts behind service meshes so you're going to see that I think quite a bit of the next couple of years totally recommend checking it out mustn't say RPC not the devil in disguise sometimes events are better and basically events in messaging your trading availability for consistency now as a developer I think it's quite hard sometimes the kind of an acid world and the RPC world it's much easier to model in my head I've cut my teeth on relational databases or I was a my sequel DBA for a while and then I'm moving from acids to what they call base now in terms of eventual consistency it's quite a mind kind of twist but it's really beneficial so much time saying look at our view look at Jason our breasts and stuff look at our see look at events as well and Jonas Bonnie I think is a bit of ahead of the curve with this so a Jonas is the CTO at light bender who worked at same time safe and he is got some really interesting ideas so I've linked their presentation and I wrote up one of his and talks so it's all his work there but I wrote up a talk and info cue I just learned so much about when we should look at events versus RTC and kind of the reactive thing and Jonas has been really involved in this reactive is only getting hotter yeah if you look at a lot of the framework dotnet Java they're all embracing this reactive principle because I think micro service is up until this point have been very much about architecture the static view of the system behind the context etc I think the next evolution we're seeing it with a service is going to be around the data around the events and this is the dynamic view of the system yeah static and dynamic there's always the two and architects we like to focus on a static but the dynamic is super important and reactive kind of embraces that dynamic principle a lot more switching it up a little bit so as anyone working on enterprise service bus is here I'm conscious I'm a little bit old yeah me and Sam a few people are yeah yeah really engine for a while enterprise service bus is that the dream was that you could have this nice bus in the middle of all your services you know it basically abstracted away all the communication headaches yeah as an architect when I rolled into projects and I saw this kind of architecture diagram I was always like oh this is not good yeah oh yeah our architecture super simple a few services talking to each other I knew when I cranked open the ESB the communication would be a little bit like this yeah I knew there'd be some security and probably some governance going on in there as well yeah it's never as simple as it seems on the architecture diagram now the ESB is typically deployed behind the firewall it's the point as a back-end kind of communication bus and say we were to move the service boundary the ingress point down a little bit and change some of the service names so now we got our entry point down the blue line we've got like iOS app website etc etc talking to services below what I like to ask yourself for a second is that an ESB or is an API gateway yeah I don't think about that one now don't get me wrong I'm not bragging on API gateways they're an amazing tool centralizing a lot of cross-cutting concerns like rate limiting security you know it's nice to have a central point of ingress something like an engine X a Kong mule soft API gateway but it's all too easy to let business logic drift into this thing so what happened with the SBS they promise to make our lives simpler but we were just pushing the complexity somewhere else yes and you're going to hear me a couple times as much I genuinely do love and the Netflix tech stack I know many of the Netflix people with really cool people and what you hear talks about Netflix is a little bit behind where they actually are my experience so you kind of get the echos of where they've been and things like Netflix Zul is an amazing API gateway I'm sure a few of you might be playing around with it it's like an API gateway it's pluggable you can put in groovy scripts to dynamically change runtime behavior which from Netflix is point of view is fantastic they've built out all their backends and they drop the groovy script in to enable like a kind of like feature flag like Sam was talking about yesterday an able that path the snag is you know Netflix are very disciplined about what code they put in to this you know dynamic and code loading I've seen some companies basically put business logic into that as well so when you deploy something only are you deploying a service but you're deploying something into the gateway before you know it you've got you know interactions between other services multiple components for deploy API gateway is awesome that watch for loose coupling same with the SVG if these in principle I think were great but we highly coupled ourselves to implementations the vendors kind of and I'm my opinion of course the vendors got involved I think with ESB is too much they try to differentiate themselves and it became an arms race and you got locked in don't think people are doing that with API gateways I think we're doing ourselves to be honest so think about fundamental serve you know fundamental software architecture loose coupling high cohesion separation of concerns single responsibility these are all fundamental patterns that really help you in micro services moving on switching gears a little bit so we're going to look at the organizational side now and I like being agreed what's mine is mine when the organization and micro services bingo I'm not going to talk about too much Conway's law everyone loves a bit of Conway's law yeah and but it's true I've seen you know in this is Alex evidence but I've seen way too many systems to to not realize that micro services and software in general you know it's the back of people as much it is about the text yes maybe more particularly in a migration from A to B I don't care what MB are there things are going to change and change always brings loss yeah lot of habits loss of understanding lots of responsibility and as a shoot as humans we're massively lost a verse that comes from Daniel Kahneman's book but it is true I don't like losing things I get nervous when things change we all do yeah so we need to think about the organizational aspect of micro services and many companies I work with I think maybe ignore some this thing the class thing I was getting with Open credo when I was working there was we they rink that a company would bring us up and they say we're stuck with this technology stuck with micro services and we're like we're more than happy to help you no problems we like to know bit about your business and we'd like to know a bit about your organization you know we're not trying to upsell but we just we realize you know we need to look at the holistic kind of thing going on yet we infrequently towards like the last six months although we get a lot of pushback when we started talking about looking at the organization no no don't worry we've decided to reform our teams around squads chapters and guilds we've got you covered yeah and when you walk in their squads will be basically scrum teams rebranded chapters will be tech leads and a guild is you know we run a conference kind of once a month something yeah beware of cargo coding I've heard it took that already a repeat three times we are not Spotify yeah and Spotify aren't amazing like the people that's amazing but they've kind of come to this culture and we're just trying to copy what we see yeah you need to think about things like lis practices the principles and the values that's a wise what if I got to where they did now Spotify I know again lucky enough with this info queue connections I get to chat these amazing people which I'm very lucky I was chatting some Spotify people and they said to me we optimized for autonomy and innovation we as extremely music companies we can outperform or innovate our competitors we make more money yeah so the reason they came to this like design of organization was they're optimizing for autonomy and for innovation now it's kind of nicely with Brian's talk this morning if I'm building software for a nuclear reactor the last two words I want to hear in terms of values are autonomy and innovation yes makes sense when you see it that like bluntly it makes it makes really good sense but I've seen it kind of finds you I'm sure I've even done a bit of this myself much as I'm talking to Antep and I've done them a few times as well but think about these things we need to understand when you're copying tech when you're copying organizational structure whatever when you're copying anything think you're looking at the top of the iceberg whole bunch of stuff below the sea yeah need to look at the crap practices principles and values and that's much better way to understand how you should form your organization how you should build your software so sloth is the next sim switching up this is getting lazy why well we call them non-functional requirements but I think they're I like the term cross functional requirements because I've seen many systems that were not functional due to non functional requirements yeah these kind of things so I like this quote a lot and it comes with Aiden Casey on its blog great blog post and he says the driving and technical requirements for a system should be identified early to ensure they are properly handled in the subsequent design the driving technical requirements now how often do you know if your client will come yeah boss to lower your customer says to you if you build this feel this or this it's all functional stuff yeah and then you say um how fast should it be gay a fad should it be secure yeah and you're like what what does that mean that matter I think we've interesting totally guilty as charged yeah we're a bit and we don't push back enough yeah we build systems from this functional point of view we don't look at the non-functional and as things are scaling more this is becoming more and more of a problem I I think as well so I've often seen projects and again I've been on a few of them where the illah tees are an afterthought the kind of availability scalability all this kind of good thing and and the pushback I kind of get with this is that we're a agile and with agile famous sort of Mary Poppins yet kind of quote we're agile we delay decisions through the last responsible moment I personally love the idea of the last responsible moment it's the kind of moment where if you don't make a decision it's going to be irresponsible don't things are going to go wrong you don't want to make a decision here you don't have all the data make it here when you've got the most data it's the last responsible moment to make the decision otherwise it's all going to fall apart but the kind of newsflash is sometimes with NF ours this is actually upfront the last responsible moment is upfront yeah how are we going to scale how we're gonna do security these things and it can be costly and I think prohibitive in some projects I've worked on to adapt late in the project and micro-services I don't think you know again anecdotally I don't think makes it any easier I what one project I worked on we had to try and retrofit security into micro services and no longer was it just retrofitting security into one thing because like 20 of the things now and they'd all been built subtly differently so you know be aware these things really really important hat tip to fam here follow Sam's work and lobster in an exam for a while now this thinking about security in particular I think it's going to catch up with us as an industry yeah regardless of micro service in particular micro services people are getting bit that's fast and loose with what they can do Sam's on a great talk of lost the last year also Aaron gratify Yuri talked a lot about container security and if you are working with containers I highly recommend checking out Aaron's work and even like a lot of container software like docker and so forth out of the box it kind of comes with some slightly funny config settings partly from historical reasons and it's backwards compatibility but I use in namespaces those kind of things so the combination have a look at Sam's deck have a look at Aaron stuff if you're using containers this will give you a great primer to think about the importance and how you might go about doing security within micro services yeah I think it's really really important lastly we're at the point now where we can definitely test these things in the build pipeline I mentioned I'm a huge advocate of continuous delivery I think is a single biggest thing I've done in many companies or my team uh she says you know what I've worked for people it really can be a game changer as many of other things you can do as well but once you've got this pipeline where you can put code in one end and it runs the gauntlet and gets tested and it pops out the other end you're either ready for production or in production it's just fantastic technical people and business people alike go crazy when they see this it's a really good feeling we should be codifying these NFR into the build pipeline I'm a big fan of Gatling for for testing at the moment Gatling is a scholar based tool you couldn't very easy DSL don't even know scarlet would write it the beauty is you can write things saying Gatling and then you can ship it off to flood die oh then a flood is a commercial service I've got no interest in it in terms of commercial interest and but it's an amazing service where you can run your Gatling scripts scaled up on Amazon so we can put something into staging we've been using it just to test locally but now we can replicate the number of users and Hammer our services the check they stand up these things are really valuable you should be able to use whatever you're using all the way through the pipeline ideally should have to do what you're doing locally and development and then scale it as it goes through the pipeline and Gatling and flood bio floods Auto is a great example of that security testing things leaves me a table stakes and like you're not if you haven't got this stuff go home when you're back go back to the office put it in straight away super valuable things like the OWASP dependency check totally check out the OWASP website i've learned a bunch of stuff about vulnerability smoosh but the OWASP dependency check is a language mutual and a way of checking for critical vulnerabilities in your code sorry in your dependencies I should say so in the Java world it uses a maven plugin and it looks for old versions that you're bringing into your codebase that contain critical vulnerabilities does the same with pip it does a bunch of stuff of ruby gems as well so it's a real nice way to make sure you're not bringing in dependencies to ask that have vulnerabilities yeah and BD security is a nice wrapper around the OWASP zap tool which is an automated penetration testing tool it doesn't replace penetration testers but it's a very nice way to get the kind of basics of security in the pipeline and the nasty docker bench and Claire are forth there static vulnerability analysis scanners for docket images so if you're bringing in say docker or rocket or any kind of container technology you typically run an OS within so you've got your artifact but now you're wrapping an OS around it so you want to use things like Claire which is open source to do vulnerability analysis on that you don't want to be running half putting your poodle for example in your container it's very easy to do that next is rapid slowing up when bad things happen previous talk I talked the heck of a lot about the technical side yeah release it fantastic book if you haven't read it it's you know it's pre cloud pre micro services Michael Michael Nygaard is one of those people that's often the head of the curve it's a fantastic book famously this is the book that Adrienne Cockroft gave to some people in Netflix and it's been Christensen and also Colton Andrus - the main engineers there he gave them this book and said we need to codify this stuff and ice back and out pops the simian army at pops chaos monkeys yeah so bulkheads retries timeouts all those kind of good stuff circuit breakers came from this book so technical side or when stuff goes wrong do read this stuff I'm changing my thinking around some of these things around putting more the fault tolerance into the platform into the service mesh for example but these are good primers but today I'm going to talk about more the people side of bat but when bad things happen and when bad things do happen people are always involved yeah I personally like to be this person yes kicking back with a beer caching the console and check yeah and though it's in all seriousness yeah you know you need to know what's going on and how does dev ops fit all into this you know again this is going to be a skirt around dev ops because delts is a huge topic and you did a great job on this stuff yesterday but some resources I found really useful to help me understand about developed and shared responsibility shared ownership end-to-end delivery these kind of things Matthew Skelton fellow Londoner awesome guy like give a big finger again it's got some work called DevOps topologies where he highlights in the red they're anti patterns of DevOps implementations they're kind of dev dev ops ops team for example it also highlights in the blue some good patterns around DevOps it's a really good resource of how to identify perhaps where you are the company as an organization the team and where you want to move to to get the best out of what he believes you know devil should be and I subscribe to a lot of Matt Matthews theories he's written some cool books and stuff as well I do love books so in the UK before I've changed jobs I used to have a long commute so I used to read a lot of books on the commute I travel quite a bit I guess as well but these for me helped me understand what DevOps is about I love the sre book it's already been talked about quite a bit of this conference Andrew talked about it yesterday it's Google's way of doing DevOps and again don't cargo cults don't blindly copy what you see there because I've seen that a few companies as well but the first three chapters of that book are amazing about just watching the evolution of how Google do DevOps yeah they sold things in a very interesting way and I've learned a bunch in that book which I've sort of distilled them and taken away keeps looking fantastic no Keith's quite well and always enjoyed chatting to him his head's occurred when it comes to infrastructure the thought worker and that book won't make you an expert say in terraform or ansible but it will give you the primer to understand how infrastructure as code fits into the big picture and that's really important I think with micro services unless you're putting onto a platform you need to think about the platform things that effective devops cover so Jennifer and Katherine's amazing work from Etsy Catherine is beer ops on Twitter she's really good person to follow they talk more about the people side the cultural side the hiring side of DevOps really helped me to think about this kind of shared ownership thing and lastly DevOps handbook is a fantastic book you're in the enterprise and looking to understand how to move to this new modality of working that we're calling DevOps now so there is a danger I think with the DevOps thing one of things I see when things going wrong is there's this notion of hero or heroine Connor and culture the hero pops up I'm a false patch DevOps engineer and you see there's quite a bit in London quite would get quite a bit actually of this one person offering they can solve all of your developed problems and I was chatting to charity majors at conference last year and charity runs honeycomb honeycomb do I oh very distinct sort of career and she was trying I think we trying to hire honeycomb and people saying to her yeah I'm a false back there Vox engineer and she just got completely sick you know this when she interviewed them they were not full stat they knew a couple of things and she did this great quote at the talk at craft conf last year and she said I'm sorry but if you're not designing the computer chips and writing the website but I don't want to hear from you as a full stack developer yeah you know Kevin Henley often talks back there so people say their souls back you often ask them how's your device driver writing code and everyone's like wired and right device drivers you're not full stack it kind of been listened but we can only do so much as an individual back when I start my career full stack meant I knew JavaScript at the front end and Java at the back end it Dennis expanded to knowing databases and that's got kind of crazy I like to be a generalist but I totally appreciate the need for specialists I've worked with some amazing people in my career at Open credo and many other companies as well well I may be sort of looking at the overall thing but cannot do the work without people being specialized specialized in certain things yeah Brian hinted early this morning dev dev ops I love the idea develop unda mentally it is developed together there's different skill sets set from these comes down to defining responsibilities such as the kind of anti pattern I've seen people building entire micro service platforms Colin works at pivotal very calling the very opinionated person I saw this tweet a few years ago it's always bugging chat enter Colin and he was seeing a lot of people building their own thing a few years ago and guilty as charged I had to go at those in a couple of projects as well do we really want to build an entire micro service platform or should we as developers be focusing on the stuff that matters yeah on the core stuff and for me this comes down to continuous integration continuous delivery mechanical sympathy is understanding the fabric or the platform you're deploying on to in enough detail so mechanical sympathy comes a lot from our Formula one motor racing and so Jackie Stewart very good driver he understood how an engine worked he couldn't build an engine as it he was driver really good driver but he understood about torque ratio power bands all this kind of stuff that made him a really good driver he understood the one level data but also one level deeper the engineers were what they're the genius is doing all the work on the engine but he understood he had sympathy with the mechanics yeah I think we need to get sympathy as developers as architects with clouds with containers because they do alter the way you deploy and run services I've got a bunch of other talks you can look online wave talks more about that kind of thing logging and monitoring hopefully table stakes these days super important but do look at open source pass fast be but you know DB as a service I should say I am seeing a lot more value in these things you know a lot of people want to run their own stuff but I think the arguments were running a pipe private cloud is pretty thin unless you are a Google or some other company or you have very strict regulatory requirements I think you know most people are getting into public cloud and the next evolution of this in my mind is going to be the embrace of pass yeah we've been flirting with it for a few years and things like open share stea sky foundry and all the kind of service type stuff and database-as-a-service there you know it changes the way you work but there's a lot of benefit to the developer for cussing out some of the operational overhead I Amazon take care of that I let Microsoft Azure take care of that basically I think so what the answer pans I see is people shooing this going I'm gonna build my own platform you always need a platform what if you're developing micro services you always need a platform service discovery scheduling fault tolerance you end up building itself and again guilty as charged on that when I did it a few years ago we've accidentally kind of built app switching up so yes now as I've seen the data models because like we talked a lot about RPC and all these other things but architecture and data models is the fundamental stuff of what we do as a softer developers yeah and a couple of our bands I've seen one is the shared single domain pattern which I come from Tara Cabot Robbo see a CEO of open credo now so work with Jarek a lot needs deep think on this stuff so I'll talk about that and also the connection with data stores as well so previously we had one model to rule them all that was that was good path you know good best practice should we say I remember if you find buildings in spending months building what we called the canonical domain model yeah getting the perfect representation of things in your business but it's it month it took you know long time because it's really hard to do when you got a big enterprise you can all agree on what certain things look like I think is another reason why micro services have become popular because you can model your domain depending on your interests yeah so the manger in design I won't talk too much about it but it's well worth looking into and the books are quite a deep read to give us but there is a shorter book now as a green book coming out which summarizes a lot of these things so a lot of the clients I work with I say you get sort of a primer understand some of the key concepts behind the main driven design and the green book is a fantastic reference because a lot of these things you know it was written before micro services I will say that so as all the concepts don't gel perfectly with micro services but they really helped me as an architect of the developer understand about modeling because all software is modeling some aspect of the real world yeah you're coding you're modeling the business you're modeling something and improving my modeling skills really helped me build software to realize but definitely micro services because we have different you know different models in different services I found this really beneficial again watch me no does break encapsulation it does introduce coupling famous thing I did a few years ago which I shared and asked facts with all my domain entities thinking I was really clever and I shared it with each service the problem was it was a start-up and the domain was constantly changing so every time the domain changed I had to redeploy all the services which was like you know clearly - my point of view so I've been there I've done that don't don't do that it really sorry and think about you know when you're in Alice analyzing your system you're thinking about building micro services or you're doing a migration you need to understand where you where you are situational awareness but also where you're getting to as well and two techniques I found really beneficial are context mapping and all such classic domain driven design stuff and events storming and again only just getting into event storming but they model the static and the dimittam and the dynamic systems but sorry offsets are again they model the static and the dynamic properties of the system you're designing it's really important to look at both aspects yes static in terms of bounded context use a service or a count service check out service these kind of things but also how does the data how does the business logic flow around kind of see the system these are two things I found really helpful my journey with micro services the beauty of bringing out these kind of individual models and individual services we can choose appropriate data store technology now this is awesome but a word of caution you know choose the right tool for the job relational databases are awesome I use them like my sequel I'd Postgres a lot I use like the cloud versions of them typically they're really valuable for structured data no need to throw them out no need to throw out the banner the baby with the bathwater as they say Cassandra is awesome but I think many people misunderstood the stories coming from Netflix they thought it was a faster and more scalable version of a relational database it's not yeah and I was seeing many problems my team missing many problems in credo where people were having problems scaling Cassandra thinking it was a technical issue it was actually a data modelling issue they've modeled the data it like it was a relational database and Cassandra doesn't scale like that so they were doing queries would freeze the whole cluster for example so often technical and data modeling go hand in don't build grass databases relational databases I thought that once a month my bad and again I'll just reiterate be aware that asked if you were developer if you identify as a developer it's very easy to spin up a docker container with Cassandra with Redis pick your pick and for there is operational overhead for running that in production it sounds really obvious but seriously many times in projects I work on there's some kind of docker container running in production that's got stuff in it you know super fragile Carl I Brian was saying it's like the tire file waiting to explode yes so think about the operational aspects as well and so final thing hopefully coming out quite nicely on time is pride and I think testing changes a lot and with micro services because you're no longer poking one thing in something dropping out you've got a distributed system yeah and QA often get sort of marginalized in my anecdotal experience people forget about the QA stuff until the end of the project and then Clint's micro-services it's all changed in the impact of massive previously I talked a lot about local verification and quoting Lisa Toby Clemson's awesome work from Salt Works again and so if you're just getting into micro services and testing Toby's is a kind of canonical reference Sam's books got a great primer on the overall thing Toby stuff is really good on the testing angle yeah so do check this out I'm going to go a bit them deeper this afternoon or something like that partners of my work expect oh so hands up this is all open source work I'm going to be talking about but it's partly with stuff I've done on my team I should say I've done inspect oh and but I really got into service virtualization at the last year and that's what we sort of used to call it work I think of the industry is changing a little bit to API simulation or service simulation where the idea being is sometimes quite tricky to develop against something that's either you know another team developing or isn't ready yet or it's a third party you know if you look on the diagram here and a spot on our on this side and you have that consumer the producer may be unavailable it may be expensive to run but you're building something that is coupled to it so you can actually put something in the middle like it's basically it is crudest form it just records requests and responses at an RPC level you can do messaging as well but won't cover that today this is really valuable I had a couple of projects so we worked where we needed to interact with this third-party system but we'd only use it once a month and we couldn't generate deterministic failures so we wanted to test our system with handle these failures we couldn't do it until we started using basically a proxy you put a proxy in the middle there you can see and it's kind of kind of useful when you scale it up yes oh so you got many in you know microservices many internal produces you've got some maybe a paypal or ebay third-party system at the outside your boundary this gets harder and harder I've written a school about locally testing micro services so if you search online locally testing micro versus I've shared my thoughts about that already but this is one way and a lot of thing is the de facto way but one way is to virtualize those services it is comes typically a bit later in the pipeline you might want to mock failure up front but virtualized later and then you can do kind of funky things with these virtualized services these API simulations if you will there's a bunch tools and classics and you might have these in your organization already there's new stuff like hover fly which I'm working on open-source whymark awesome guy Tom acre student in the UK works on a java sort of framework very similar as basic VCR Betamax mountebanks and thought works mirage is a python-based one so all the languages are covered whatever you're coding in I'm going to talk a little bit about hoverfly and this is open source it's go based super high-performance the reason we wrote it as we were struggling with some of the other tools that were not and they're written and jvm languages and bunch of other things they just weren't designed quite right so we couldn't scale them so now we've actually like the rewritten we've written this stuff and go super lightweight single binary and you can simulate many services from one binary mechanical kind of funky stuff in here and this is you know what are you using why mark cover fly or whatever you typically sort of really know you put your thing home fly in this case in the middle between your client and your external service and you record traffic so when you're in simulate mode you can get rid of the external service and you can just put a request in it matches and it responds back the cool thing is you can often with these things put middleware in the middle so you can do stuff like remove credit card details or social security numbers that kind of thing yeah and strip out data to record later it's quite useful and you can pipeline these things classic Linux stuff as well the really funky thing comes in simulate mode where you can kind of use it to do fault tolerance you recorded your requests and responses but now we can reach into the recording of those change the data add delays basically mess with the response and in a deterministic fashion you can codify how you want these services that these fake services to act and you can test that your system your service behaves appropriately so hopefully I've got some Java and j-unit support I'm Java developer kind of than most if I do you can spin up like rules like this and it's all like a nice BSL kind of thing why I'm not because identical in terms of style so I'm showing you all fly but it's kind of very similar many other things you actually put it straight into your testing there's like a dotnet version Python a bunch of other stuff as well and but you see the power you can basically codify in your test harness you can say fake these services fake these endpoints it's a very powerful paradigm when you suddenly realize you you can even spin up things that don't exist yet why a mocks got a great DSL for coding these things mirages kind of the same you can codify what you want to be there basically if you're being blocked by some dangling service you can get working by codifying these kind of rich mocks upfront you can do at fault tolerance stuff is always quite quite funky as well but yes let's wrap this up I think we are going pretty close to time so this is what I'm what I'm sort of seeing is the seven more deadly sins yeah and do you think you're going to go to micro services think is it the right choice for you it is the right choice for your team it is the right choice for your organization think about technology docker go java there's always a cost for bringing in new stuff yeah think about communication same kind of thing I like service meshes really liking reactive and events as well but figure out what's right for you yeah you know what your skillset of your team is these kind of things think about the organizational aspects it cannot be under emphasized my my experience and also think about things like getting lazy with NF ours from the peanut people and technical perspective as well with Raph exactly that think about when things blow up think about DevOps I think you know some notion of whatever you identifies DevOps has to be in place in your team to use micro services you have to have end of end to end responsibility you have to have shared ownership otherwise micro-services get out of hand very quickly my experience and envy so yeah think about the single domain model think about how you're backing those models with the data stores and stuff but don't get me wrong many of the things have been kind of around the edges the fundamental stuff we're talking about with micro services is architecture and it's the main modeling yeah and as static and it's dynamic so think about those things and you won't go far wrong I think we often get distracted with other things but that's your fundamental stuff to think about and testing does alter one thing I found useful is these kind of notion of virtualizing services and again love to your feedback on that kind of stuff as well some books I always got at Sam's book I've been introduced of my genuine microservices there's a couple other O'Reilly books in the same space total shout out to Susan Fowler that has an awesome book production-ready micro services you haven't read it please do it's a really nice kind of primer for running services and Susan used to work at uber Steve you may have heard the story but now she's working a stripe and she's got some amazing thinking around this stuff a bunch of other ones thinking about AP is continuously all this kind of stuff the slides will go online I think some of them already are online at that point I shall stage don't forget to rate the talk really appreciate your feedback both on the app and also in person or Twitter or something but thank you very much for your time you

Channel: GOTO Conferences

Views: 35,761

Rating: 4.8861208 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Daniel Bryant, SpectoLabs, Microservices, GOTOchgo, GOTO Chicago

Id: NP189MPfR7Q

Length: 48min 5sec (2885 seconds)

Published: Tue Jul 04 2017