APIs, Microservices, and the Service Mesh

okay everybody can hear me cool hi my name is Gary Schutt I work for Apogee and I've been working for Apogee since 2014 I'm a tech strategist based here in Stockholm helping our customers with our API initiatives sometimes hands-on work actually building things and sometimes just more strategic with the business like what types of things to focus on how to be successful with your API programs and initiatives and kind of what things not to do and today I'm gonna be talking to you guys about micro services and service mesh and by the way I want to say I agree with Tom it's actually that a lot of times it does become a mess and I have a whole lot of opinions which I'm happy to to share with you that back at our booth on the do's and don'ts of kubernetes and kind of containerization in general okay I have a couple of goals I would this talk so I'm going to talk a little bit about service match the value of service mash kind of API management and where these kind of combine and meet each other and intersect and there's a continuum of worlds there that we're gonna try to address so when we talk about micro services oftentimes of late at least we're talking about kind of sharding up an existing model with into a bunch of smaller little pieces and that can take different forms so in this case as we're showing here we've got this big monolith we start to break it up in these micro services and then maybe over time we create some sort of container manager and put that put those micro services inside that service mash but as a point of reference I want just to point out that this is very common and in fact it's very often that we refer to micro services as if they're synonymous with containers running inside so sort of orchestrated container environment but that's not true if you want to go write your own small framework for running PHP based and lamp based micro services you can absolutely do that this is just one way to do it and it happens to be a way that speaks to the kind of Google at scale method of handling at the moment but there's another way to do this right so if you want to move towards micro services instead of breaking up this big monolith in a bunch of smaller pieces we might instead just wrap that monolith with an API so that we can lie to our consuming audience you know the real customers have already the eyes which are developers so that they think we're a modern company that has a bunch of microservices the lie underneath it and this is important because actually that might be an evolutionary way for you to make these steps right you start by wrapping this ugly monolith and you put the the makeup on a pig and what the customers of your api's don't know is that actually underneath the surface you're doing all this extra work to kind of make that happen I'm in the the what drives all this is together are these api's so I've got consuming audiences that are communicating with these api's and those api's should in my humble opinion form a sort of contract so as I said the real customers of your api's are the developers and those developers are going to agree to a contract that you as the producer of these api's are providing and everybody needs the honor of this contract it doesn't work but these contracts can grow and grow and they can have multiple versions and I can be confusing and so we kind of might need some way to keep track of that and that's where service mesh might come into the picture if you're running type that type of mesh with a micro service architecture that's probably based on something like containerization strictly speaking mesh doesn't have to be containerized but that's usually how it's done and in that case we're looking to connect and kind of control that flow of traffic we want to secure it so that we've got a one pane of glass or a single pane of glass looking at how all these services are are secured control so that we can apply different policies in a uniform way and in a very specific kind of way and then finally observe right so we want to pull traffic out of this mesh of services so that we can make some kind of determination of what it might mean for posterity so let's talk a bit about management for shared API so in this picture here I've got a bunch of clients here on the Left that are consuming these api's in my case since I work for averaging and the Apogee API platform is sitting in them in the middle and then a couple of applications there on the far right so a legacy application and some sort of model of application once using so of the ones using rest so this is a kind of a common common way to think of the world and why do we care about API management in this case well because we want to be able to discover these services so I got soap and I got rest and that's not uniform from my developer audience and again your developers are your customers and so I want my customers to have a good experience so I don't want them to have to use soap for this service and rest for this service and some funky custom XML thanks for this other service rather I want to make the kind of modern and easy to use an approach for them and then I want to get reporting information on it and theoretically if I really succeed succeed with this the holy grail is to monetize it so I can make some real money off fruit okay so this grows right so I still got these clients here on the left and I just got the I got my services there on the right but now I've got clients that are internal as well so I've got an internal application that likewise is consuming these applications and the drawing here they're connecting directly but we can imagine they might be going through Apogee as well kind of is a logical connector there so likewise that internal app is also a developer or developed by developer who is a customer of these API and has some opinions about how they should work and this grows and that internal app starts calling other services or those services like wires are going that external application and this explodes into you know just massive amounts of growth in these and these and this really is a mess you know and so now not only do I have a gateway here that's trying to facilitate all these different pieces in a way that it really can't handle because they're deployed independently but I've just got a mess of dependencies in a way that's kind of hard to keep track of and it's to address this this mess of a service mesh that we have that we really want to move towards something like kubernetes right so what we want to do is containerize these services inside of kubernetes add something like SEO to that and of course working for google that's what I'm pitching and then what we have the ability to do here with apogee is add an adapter in there that gets in the middle of it so this same control plane that I'm using to manage and make that consuming audience tractable that's coming in from the outside at the edge I can use that same control plane to keep track of the same internal audiences that are consuming between each other inside the mesh and even that internal app likewise inside the internal parts of the corporate network okay so when we think about the mesh it's kind of grows from simple concepts well I've got services that want to communicate with each other in this case HTTP G RPC maybe even actual tcp between them and then at some point I think you know I'm really worried about the security of this if I were doing it's a virtual machines or on bare metal I'd probably make sure I was setting out proper security rotation schemes for the keys that I'm using but in this case I can defer automatically to something like the mesh control plan for me in that case this do so SEO can make sure that I've got bi-directional MPLS deploy there I also want to kind of distribute logs and takes any any traffic that runs through any piece of this man I want to offload that somewhere for further processing I want to be able to distribute policies between them make sure I can report them have control over the routing and maybe even local authentication and authorization on these services independently of one another right but maybe centrally controlled so all these types of things I can control and I mean I use a mesh and I can mesh enforcement piece to make that work but rather than putting that that the code inside my own applications I might use something like a proxy and in this case it's a sidecar all that sidecar means is I deploy the service I care about as from a DevOps perspective I write the code I care about and I have a process to deploy it and then automatically the sidecar peers next to it and it's connected to the rest of my mesh to kind of control how I'm mediating that traffic so now I've got a sidecar proxy process that's going to do the retries and the connection timeouts and the blocking and the throttling if I need to as well as collecting the logs for the successes and the failures and offloading that to another system over time my with with this I might realize that I've got this powerful control plan this is underneath it so these proxies themselves don't need to have that logic for that configuration stored natively rather they can defer to a collection of pieces that lie here at the bottom so SDO is a mess DCO comes with a whole bunch of extra pieces but they're powerful pieces so I've got a service like pilot that's gonna allow me to do secure naming so every service that I deploy automatically registers itself with pilot so that I can find them and it takes over the kind of that DNS lookup piece if I don't want to use DNS and I want to use a more classic look up a service by its name and version and have it run it for me I can defer that the pilot it'll do that if I don't want to worry about the EM TLS certificates that I want them to roll it's the Citadel process that takes care of that for me and for Apogee perspective if I want something that's gonna allow me to add extra functionality at the sidecar piece and in our case to handle kind of ingress gateway pieces and ultimately egress gateway pieces I can use the mixer to add that kind of logic there and we embed ourselves as Apogee directly into that mixer so that we can get that control playing back again so everything's controlled from a central point but I have a way in a tractable way for posterity to control is growing suite of services that I deploy in that mesh and also to kind of keep track of them over time okay so service is an API it's both need API management and so basically you're gonna have some kind of containerization system probably the lives underneath it an orchestration framework upon that you're gonna have some kind of services management thousands of services as it says here I mean your your size and your mileage may vary in terms of how successful or unsuccessful you may be I kind of think having thousands of certain anima services running an environment might be a recipe for disaster but you need some way to orchestrate those and on top of that you want an API management platform that forms the basis for you to productize these services so that the consumers the customers of your ApS could find them no matter where they are so that if they're inside the mesh they can find them and use them so if they're outside of the external world they can subscribe to them and if you want to so that you could charge the money and makes money off of that and that's it how did i do on time okay you did great thank you thank you [Applause]

Channel: Nordic APIs

Views: 1,691

Keywords: APIs, Microservices, Service Mesh, Apigee, Geir Sjurseth, Nordic APIs, 2019 Platform Summit

Id: IKbNG_VHHHE

Length: 10min 5sec (605 seconds)

Published: Fri Dec 06 2019