 Having a fireside chat instead of like a regular presentation, but we're recording this so I'll go ahead and like do this like a presentation My name is Eric Chabelle. I work for Red Hat for more than 10 years now Kind of an interesting title I have there's a second person on this Presentation that I put up there. It's a very good friend of mine that I've worked with in the Netherlands. It's where I'm from He spends a lot of time as a solutions architect talking to customers about all kinds of interesting stuff and About two years ago. We came up with this pitfalls kind of theme talking about What customers what partners what people are running into in various aspects of? product development software development Digital transformation all this kind of stuff right a lot of buzzwords involved We did a talk a couple of years ago at Red Hat Summit about three pitfalls of hybrid multicloud And people got so excited about that it was voted like top 10% or something in that conference It was kind of shocking to us because it all started with a phone call between him and me Where he's complaining about how customers keep making the same mistakes all the time You know, I just ran into another one is doing this again And this three pitfalls happened the same way a year ago we started talking about it and We took this Too far away by hand So we did this at Red Hat Summit in Boston this year and what we did if you look really closely It's kind of hard to see but at the top there we put a whiteboard in front of the door So when you came in and we divided we had two arrows We said if you're doing microservices sit on this side and if you're thinking about it Or just interested in it or just here because you don't know what's going on sit over here And this is right at the beginning, but you notice really quickly. It's about 50 50 isn't it? And it was completely full and it was 50 50 and the way they're positioned in the room We got sort of like this thing that one's talking to the other and we did this a little bit as a discussion And we did way more than just three We put up these opinions and and my controversial statements are things that people think Have to do with these microservices and we would let them talk about it And it was really kind of funny. He was at one side of the room and I at the other and you'd see The conversation being taken away from us and they started arguing about stuff back and forth across this So what I did is we took notes during this talk and I picked out three for this presentation and this is the first one How many people in here are developers that everybody looks like it Who here's an architect who here is doing microservices right now for who here has never touched them No idea what I'm talking about Okay How many people here have done services web services rest services whatever services you have a concept of what a service is right? How many people have an actual job And I'm just saying that in a funny way who here's a student So we got one student. Okay. That was that was a little bit of my concern about how many students were going to show up to this because one of the things About working in an organization, you realize that the complexities versus what you program in the university are vastly different. I Remember my very first job they came in here write this web service. That's no problem But writing a web service on your laptop versus writing a web service in an organization is a whole different ball of wax How many people here work in an organization and we use kind of a buzzwordy kind of thing here saying Traditionally siloed organization. So here who here works on applications or Multiple applications in the sense of there's a deployment cycle. It takes two three four six six months to deploy something all the way to production Maintenance maintenance cycles a couple times a year maybe once a year Who here works on the services that are in some kind of service layer? So everybody's just working on web apps web front ends Okay Traditional siloed stuff has to do with the development team and maybe you've seen this before where you have requirements and you have architects that bring stuff You have business users that might be voicing some opinions And you're all sitting around and you're planning out your your development cycle and you're doing your work And you're releasing these various things you're checking off boxes. Hopefully like a g-ray issues or Whatever it is that you're working towards a release cycle Then you make the step towards microservices and for the guys here or the gals here that have done microservices services Does this sound anything like what happened when you guys jumped into microservices and thought wow, this is really great We're gonna make a bunch of microservices and off we go Did your organization change? Anybody have anything that they could share with that So you don't get asleep in this talk today Anybody wants to say anything but What we find and what we see a lot of is people say okay, we're gonna do microservices We're gonna chop this stuff up take a big old monolith. We're gonna break it up into pieces at least some of it and what they're not realizing it and not understanding is that there's a completely different methodology involved with working with this stuff so Instead of being a development team that owns everything Or at least most of it so maybe have a front-end team and maybe have a back-end team or services team But they own all of it now you're splitting it up and you're giving each one of these pieces to individual teams that own that piece So imagine owning that one service, and I don't mean just owning that service like develop it push it into a pipeline, and I'm done You own everything going forward you own the release cycles you own the CVE Security patches you get to decide when where and how you release this and how often So instead of doing your development cycle on your app Pushing this stuff out once every three four six months if you're really good at it. I worked in a bank So it took us Almost eight months just to do one release Now you're talking about all the individual pieces of your application can be released hourly Every half hour if you want to every time you push a fix if you want to Think also about that development team has to own the testing of their individual service They have to own the API front-end of it You have to Document that properly so people understand that your API isn't changing drastically between this version that version of breaking Everybody's use of it Things that people do not think about they're just not ready for that stuff and this makes it super hard So a lot of people are getting into it in the first case start breaking stuff up and then realize wait a minute That's a now start treating each one of these individual services in a team as a business-to-business connection So it's just as if you've now created a little team outside your company And you have to interact with them so does anybody using any kind of piece of software ever from an external party such as Salesforce Some of the Google services, whatever they are they have an API. They have a development team that does stuff completely out of your purview All right, you have to deal with that You don't get a choice. You don't own the API. You don't own the release cycle. You don't own any of that That's something that people are absolutely not prepared for The second one Sounds kind of simple and obvious Maybe you think there's how many people think that just a small service is a microservice you shouldn't The thing behind this is it's got to do with the hints I was saying about having a team and having to treat it as if it's an external party Where this development team owns everything has the interface back and forth like that One of the questions that comes up really quickly after they discover so so imagine the company starts doing this Making this transition bumps into oh we have to have a little bit of an organizational change because you have to give the freedom away to These individual teams to do what they're going to do And play nice and set up the infrastructure to do all that Then you come back around and you start thinking about oh Wait a minute. I have this big monolith. I know performance. I know API calls. I know service calls Are all inside this monolith so I know how this works how this interacts. I know the performance of this I can test this I can put metrics out about this Anybody here attend Christina Lynn's talk yesterday about a reference architecture for microservices She had some really cool drawings up there if you remember now if you look at these two sets of seats Imagine each one of these seats are an individual microservice in your organization And all these are deployed in some data center over here in the world And all these are deployed somewhere else in the world And I'm the application up front here, and I'm using you you and him over there You don't talk directly with each other ever Right. He has an interface. You have an interface and you have an interface. I talked to you I do that through entering this data center at the front end and going all the way to the back to whoever it is and talked I Don't know exactly what the performance in the network is going to be each time I make that call I don't know that If he wants to make a call over and use some service over here He has to come all the way out here all the way in here into that data center, right? So what you're giving up is the freedom of knowing what your Networking calls and speed and the performance is going to be for the flexibility to deploy all these things at any time you want To be able to fix security bugs like that To be able to react to what your customer wants to do I can change my business application up front here to their needs Any time I want because I'm not dependent on all these different services being updated to it's not a monolith anymore So I've taken the monolith broken it up into these pieces and you can now Have a trade-off you have to do deal with how far do I want to go or do I not want to go or can I live with The performance issues that I don't exactly know Anybody go through that when they were doing microservices anybody split up a monolith before Don't promise them anything when you do that So To find that happiness has an awful lot to do with understanding how you're approaching this and what you're trying to achieve and being able to communicate that correctly to your CIOs or to your Lead architects or to whoever is sponsoring this kind of stuff To become that modern cloud native high-performance Quickly agile company being able to react to everything and anything that's happening around you You can't be deploying a monolith Over eight months Trust me. Everybody else is gonna be way faster than you. They're gonna eat your lunch, right? That's how that works Any questions so far anything I said sound like something out in left field We just said monoliths are not something you want to be deploying every eight months What if your monoliths is that fast? right So microservices are not always Better than than monoliths What do you think of that? So this is kind of contradicting everything I just said right There's nothing wrong with looking at a monolith and deciding large portions of it are not worth turning into microservices are tearing apart What if I take those three services out of my monolith that I just talked about put them in those data centers and Now I can release my monolith every two months instead of every eight That might be enough business justification to stop right there and don't spend any more money on that project Because I guarantee you no matter what you're doing and how cool you think technology is The business is the one that owns it the business is the one with the money They're gonna look at you and say why are we even touching this shit? I don't want to spend my money on this Great example the bank where I used to work still has in the corner a machine running From when I worked there almost 15 years ago Running the same version of one of our open-source projects and the business unit still says no I don't want to upgrade it's not broken. Don't fix it It's an option So that's what we mean by having like an agile monolith. It's not so much that you're changing everything, but you're making That slight sliding shift over into some microservices. It's a way to start without having huge impact on your organization It's something to think about it So We've looked at the three different pitfalls The organization might not be ready for this stuff Just saying I'm gonna do microservices is not doing microservices and you are gonna run into a wall if you think that's how it works If you try to design your design teams and your development teams the same way as you did for normal monolithic development or Service development up to now. It is a completely different story Your definition of a microservice and understanding what I described with two data centers and how that works and sacrificing The the known factors of how your your your networking is working in your your timing and metrics on your service calls Versus the agility to be able to react to your business and changes Every hour if you so wish without impacting the actual application It's a huge change Then microservices being not always the answer beyond all monoliths There's nothing wrong with identifying that a monolith Can be slightly carved out and left alone and is agile enough and you sped up the development cycle So we're no longer waiting eight months or more. It's now only two So that's three we could stop here, but it wouldn't really be that fun What if we didn't have like a bonus one? So Who here has been attending all these data talks that they've been having here who's a big data fan? Or a data engineer, what are they what are they calling him now data scientist your data scientist? There you go So one of the things that comes up and it didn't make the top three for me, but it's probably a really close for State Applications have state. What about state? So if I'm Putting all these services out there and they're in little containers and you know, you're over there You're here. You're here. What about the state of my application? How am I managing that? What are we doing with that these distributed data stores? How are you dealing with all that stuff? Most of what we're pushing for when I talk to people about this is there's We use open source technology from Red Hat so that there's quite a few things going on out there in the cloud native world Where they put a layer? Across the stuff that monitors change in your data sources And this is this is the path I would suggest is instead of tearing it all up and trying to store data Locally by each one of these things and completely radically changing an architecture that's already in place you have to realize most organizations have a whole lot of Yeah, technical debt is the word you always hear but it has to do with they've made decisions in the past and you're stuck with So this database is not going anywhere because it comes from Oracle and the CEO made a big commitment to Oracle And that's what's going to be here for the next 10 years. That's just the way it is But to be able to have the state information you want and to monitor that correctly to plug into that correctly There are layers of software that will now monitor those changes and allow you to publish those changes directly to individual microservices and things like that When you look at these slides and I forgot to mention They're already online about 10 minutes before this talk started they published to Chevelle.org my last name is my website That's where you'll find them In the notes of the the talk you'll find links to the very software element you can look at that do that stuff The other option is you know people try to and that's what you mostly see happening It's like a gut reaction from anybody that's done services. It's a tightly coupled the data for each one of these services to the individual Individual services, which means you now have containers out there with stores being coupled tightly to the service in the container Which is not exactly the flexibility you're looking for I got a few references of stuff you can read and look at This stuff is not easy Don't care who you are or what they tell you it's not easy, but Just like anything we do and we're so ready university research it a little bit Look for some of these best practices look for some of these these tips and tricks and stuff And make make decisions that work well for your organization I still I mean one of the most simple things as an architect when you look at an organization or look at stuff That you're trying to do is keep it simple, you know that kiss principle that works all the time that has the longest living Well-functioning execution of a solution is if you keep it simple so if you can take a hint out of this stuff that would probably be the best Anybody have any questions it sound like hocus pocus or can you use some of this down front? You can just talk and I'll repeat it Make some really great points about With the microservice, how do you determine? When to use a microservice and then after that how would you sell it? Okay, so First thing you said it made some good points about microservices. Second thing you said was That's correct me if I say this wrong. How? How do I decide when to make something in microservice and then how do I sell it? Which I don't understand. Oh, well, so let's say you've decided we need to use microservices to solve this problem You Okay, so that he's saying I for some reason in my organization have decided that we're going to do microservices and how do I communicate that to my team? So it has an awful lot to do with the number two pitfall that we talked about You're looking for agility versus It sounds really bad right agility versus stability I Don't mean stability of your application. I mean stability of a known Almost waterfall kind of process of how you're developing stuff from front to back do a release and I go back around I do front to back do another release that stuff takes a long time. It's all tightly coupled We're going for the agility of being able to Expand your organization's Reaction to your domain to your market to your customers a Very good trigger could be that you want to use some service that is already a third party So if you've been interacting with any kind of a sass application or sass service from Sales force is always an easy one to use. Let's say you're doing that or you have some third-party vendor that you're plugging into that process you just replicate for services across your organization and Usually it gets triggered a decision like this is because you're starting to think about doing this modern way of being agile and getting a little bit more quick to respond based on an upgrade or an update to An existing monolithic something where you could carve off a few things and that's what I would always push for and what I always Prefer versus just like a brand new greenfield. Let's do microservices for this project If you do if you see people doing that, that's where all these come from Right because they stumble over all of them You just you're not sure you don't know exactly what you're doing and you it's just logical And you're gonna bump into this stuff Taking things in smaller jumps smaller pieces and smaller bites But you make mistakes without killing yourself or ruining a project or ruining your name or Running budgets up through the roof because you forgot about a bunch of aspects And I spent some time in Holland at one of our The biggest Railway maintenance Organization we have and they're still going through saying this is like a government organization. They're not agile It's not a quick change. Nothing is quick It's filled and staffed by IT people that are really happy with what they're doing for years and years and years and don't want to change Their way of working so you're being brought in to talk about this stuff because a younger somebody is now put in charge to make change and The best way to approach is to ease them into it, right? I Truly believe that Does that answer your question in a long roundabout way? Yeah, there's no single right answer never and never yeah, there's no single right answer absolutely not Like like the third one says there are things that don't need to be a microservice Could because of cost could because of you know the known fact it could because of a customer that doesn't want to pay for it that kind of thing Anybody else Yes, sir So I Okay, I'm gonna try to repeat that for you guys I'm gonna paraphrase a little bit so Say say if I'm wrong How do you ensure that all these individual micro services that are doing data transactions and stuff? Equal the sum of what used to be one great big transaction from your monolithic application close enough Okay, that's that's exactly what I talked about in the bonus one The bonus pitfall There are Various options to ensure that there's a layer between your micro service Architecture and services that are dealing with the state with the database or whatever your storage is whether it could be data lake It could be anything right Data warehousing whatever it happens to be Keeps the consistency and guarantees the the transactions as you're saying and you use that layer to ensure and to Configure for each individual search what they need to know so read write whatever it is whatever data they need to have that's how you how you manage that and That is used also to map the answers back to whatever the application needs to know So it sounds sounds a little bit like you're isolating everything out into individual services and that it's a mess, but It's a bit of magic going on in that That that layer you're putting across it One of the tools is called. I don't even know if I'm saying it right because we say it differently in Holland But debesium if you've heard of that There's links in the in the presentation for that and that specific slide about what these components are take a look at it It's it's about you know putting a layer across to monitor changes and report those back to where you tell it to report it back to So if I'm a microservice that needs to know about an update to a customer ID or something like that or an age because it's a birthday It will push that back you can subscribe to that information. I Didn't say the complexities will go down It's not you know nothing is a magic pill. It's it's it's a trade-off. It's a trade-off between known ways of working versus having much more flexibility and quicker releases I Could even imagine in in in ten years ago pushing a button on my code to commit it to a repository and that triggers all kinds of pipelines That basically can push it all the way to production Without an ops guy touching it Anybody doing that now that's the dream isn't it? So imagine if you have a microservice, it's only about this big right? I mean you didn't change anything you just put a CVE change in it to stop some kind of security thing About I don't know half hour. It's in production I bet most ops guys are scared shitless when they hear stuff like that But if all the automated pipelines are in place of all the testings in place, there's nothing wrong with that. Is there? That's the dream Anything else? Well, thanks Got very crowded