 So the next session we have in this track is my gym materials speaking about 10 design tips for micro services developers. What do you, Jim? There we go. I assume you can hear me? Yes, we can. And then I'll share my window. I assume you can see my screen, and I can see that I'm sharing my screen. So I think we're good to go. All right. Hey, good morning. All right. Let's get this thing going, and we'll do our best to keep this thing on track for those watching at home. Hey, so good morning, good afternoon, good evening. My name is Jim Tyrell. I'm a senior principal solutions architect here at Red Hat. I've been here almost 15 years. Been in our public sector sales practice that entire time. I'm also 25 years a Java coder. And this talk is 10 design tips for micro services developers. This isn't going to speak on any particular technology per se, but it's going to give you some high level things to think about as you're creating micro services. And actually, as you watch this talk, you probably will see that these things apply to other software development you are doing. At the end of this, I will invite you to a workshop I'm doing at the end of the month, which would be kind of a follow-on to this thing where I actually will get into some code, some thinking around how to do domain driven development in the context of micro services, a little bit of emphasis on Quarkus and Java. So just something outside of this presentation. Stream, if you will, that'll be an invite at the end of this. So development and design, I believe, sits at the intersection of science, art, methods, and patterns. I am the founder of Design for Developers, just a website. If you want to go check it out. It's where some of my writings are for this. On social media, I'm known as the design at tick. If you didn't know it, here at Red Hat, we published a library we call Open Practice Library. This brings together a lot of design thinking tools. These are really great ideation tools with my master's degree at the Institute of Design in Chicago. I learned about many of these, practiced with a lot of them. But the end of the day, as a software developer, a lot of them just don't exactly speak to me when I'm writing code, when I'm trying to deliver systems. And because of that design thinking that I have, let me put this out there in the ecosystem. And one of the things that I absolutely love about software development is the fact that it brings together science, art, patterns, and methods. Every day, I'm excited to get up to Sling Code because of that intersection. And with my master's degree, I noticed that, especially the design program that I went to in Chicago, that design is about art, but it's also most certainly about patterns, methods, and science, right? And if you didn't realize that design is a science, it most certainly is. That is some of what I talked to at my website, designfordevelopers.io. Since I'm the son of a math teacher, you can't have an equation like that without the transit of property. And that means that design is development, and development is design. These two things are inescapably intertwined almost like gravity. You as a software developer are making design decisions every day, yet sadly, you probably don't have a lot of design training in your background. And that's what this session is a little bit about. That's a little bit about what the Open Practice Library is certainly about, and then of course, the designfordevelopers.io website. And this is a quote, something that I've put out there for a long time, right? Unless you are impossibly lucky, and sometimes I say unlucky, all software at some point will be consumed by humans for sure during its development, but also for the years after it was delivered as will be maintained, it may continue to be used by humans. In other words, if you're familiar with the Mythical Man Month, all the cost of software is in its maintenance. If you're Britain software for any length of time, you as a developer, if you come back to something a year from now, I've seen jokes on Facebook and other memes that who wrote this thing and when you figure out it was you, it's a challenging endeavor. Certainly it's one of the more complicated things we will do as humans. One of the things that I've spoken about and think about is the user interface notion of software, right? And I think there's at least three, and let's talk in prior, people have talked about test cases, documentation, but I think for us as software writers, we're responsible for any one of these three user interfaces, right? And obviously it's a GUI graphical user interface. That is most certainly gonna be there. Your API is code, right? The methods, functions, variables, et cetera, that you deliver are most certainly gonna impact the user interface for those end users. And then where this talk kind of gets into and thinking about a little bit is the API is a service as a user interface, right? And it was we're throwing around JSON objects at URLs. Most certainly those are user interfaces to someone at some point. Even if the machines go off and do that, have you lifting for a long time? More than likely us as humans are going to have to deal with that writing interaction with that at some point and thinking about the human along the way will pay huge dividends. One of the things that I brought up in this talk is the five E's. This comes from a Dublin talk, a great firm out of the Chicago area in my design community with my master's program. It came about what predated TED talks in 1997. I'm assuming you've probably never heard of this. You'll notice I crossed out the word great. I crossed out the word curated in this. Organically every experience you have, no matter what it is, including this talk will organically actually have a state of enter, engaging and exiting. In other words, you will most certainly enter the experience you will work within it and then you will leave it. And I would argue that that's just an experience. So that's just organic and you're not managing the emotions or any state of that user along the way. The five E's though adds one thing at the beginning and one thing at the end that I think we as software developers don't do a great job of. So the first one in this, and I would argue that every great curated experience has these five steps and you are consciously thinking about them as you're creating your microservices. You wanna think about how you're gonna bring in people into your universe or that's a read me on a GitHub page advertising because you're looking to sell these services out in the wild, maybe webinars or lunch and learns internally, but somehow you need to make people aware of what it is that you're delivering and give them confidence that you can help solve the problems that your solution will provide for them. You also need to think a little bit about how they're going to enter this experience. What is that demarcation or what is that start line if you will for when they get into that experience? You need to think about, as I talked about the engagement, right? What are they doing in there? What are you doing to remove friction, toil and invisible work, which is a term I like to put out there a lot around design of the context of software. Of course, those users are going to exit it. And most importantly, and probably the most important thing to think about to really create a great experience is how do you extend that experience for that end user? We're gonna go through a few things to think about as we work our way through this talk. If you'll notice at the bottom middle of this page, there's entice is in there. So we are still at the enticement step of this talk. I'm still trying to bring you into this narrative, if you will. And we're looking to bring you along on this journey, right? And the other thing to think about is that all journeys should have consistency. So certainly at the macro sense, you wanna think about these five steps, but you probably also wanna think a little bit about these at the micro sense, right? So at the macro sense, let's say you wanna send emails to the world, right? You're gonna be like Twillow or any number of other services that are out there in that space that do that. But along the way, when people are looking to deal with an API, what are you doing to bring them into a specific use case within that? So that's what I'm speaking to when I ask you to think about all experiences having consistency. You know, like all good designers, all good software people, right? We should Google around and find what other things exist in the past around this. Again, another thing from 1997 from Nelson Norman Group. These are just luminaries in the design field. Don Norman is very famous, couple books that are off on my bookshelf here to the left. But this is a great list, but it really spoke to lowercase D designers of colors, fonts, layouts and things like that. I mean, it definitely speaks a little bit to a software developer, but it just didn't quite resonate with me. So, you know, like everything when there isn't a good standard in software, you know what we should do is go create another standard just to proliferate those across the ecosystem. So I came up with this list. It started with just a few S's and I just decided to do the whole thing and asked we're gonna drill into each of these here in a second. And I hope and think that you will have a good list of things to check off as you're thinking about your software. So with that, let's cross that start line. Let's enter this talk. So let's get into 10 design tips from microservices developers. So the first one is avoiding Dr. Bre, right? And as you're bringing people into your experience, you really wanna think about what you're gonna do to help them with getting rid of or creating anti-quick starts, right? That's what's out in the world. The wall of intertwined texts, the challenge of missing steps. And then the last one I call back and forth, right? So anti-quick starts. I'm amazed that today in 2021, in August, I still get to quick start pages that literally have hundreds of steps for me to do. Tens of pages to navigate. And I have no idea how I could possibly do all those things perfectly and accurately along the way to get started with something. You know, I think that just speaks for itself. The wall of intertwined text, intertwined text is probably one of my biggest pet peeves in this documentation game, right? We have Windows, Linux, and Mac OSs are the tools of choice of people that write software. And heavily our instructions might start out great with telling us what to do exactly for these three operating systems. When you get to step two, they might just document the Linux and Windows instructions and hope you'll figure out what you should do for your Mac. And then you get to your third step and you're left wondering, well, what do I do on Windows or Linux? And the worst thing about these steps is that these things are never labeled step one, two, and three. There's usually just a huge long checklist of things to do. The different OSs are interchanged with each of these instructions and more than likely you're gonna fail because you're gonna miss the fact that you needed to do this one nuance thing along the way. Another one, right? The internet meme of question marks and profit in step four, right? Missing steps along the way. Please don't leave your users with question marks about what gaps they need to fill in to run your project or your service, right? You should be able to give people the ability to just quickly get started with your service. And we'll get to those with the nine items of the assessment here in just a little bit. And this is the one where probably you live in day in and day out as you're running the most certainly deploying software, right? And this is what I've called the back and forth. This idea that you're gonna have certain pages of documentation that you're gonna have open. You're gonna go track down another guide from somewhere else. You're gonna open up a stack overflow page. And then you probably have some notes written down from the last time you did this. You're gonna bring all four of these open on your monitor or across your desktop. Try to put those all together to deliver an experience for yourself to get something installed. My friendly ask is that for these four things to just think about your end users and think about your future self as you have to come back to this maybe in a year to figure out what it takes to deliver the software. So let's get to those nine purpose defining statements or what I call the assessment at this point. So security over slowness, right? And notice if this is kind of enticing your users and as you're bringing people into your experience you really wanna think about what you're doing around security, right? Are you using TLS, HTTPS? Are and what are the rules around password management? What are you doing around tokens and keys and how they should be stored or not stored? Do they, are they one time use and then they're hidden from use for you forever or can I go recover them? Do they time out if I don't use them for 30 days or five hours and are they gone forever if I don't ever use them? Do they time out if I don't use them for a couple of weeks or a couple of months, right? What are the rules around data at rest and or in flight? You know, in the government space that I hang out in we talk about FIPS encryption 140-2 soon to be 140-3. And these are just some of the things you should think about in the context of security over slowness and you don't wanna have security by obscurity. One of the things that I had that happened to me just a few months ago that I was playing with the service, downloaded a software key, tried to use it a month or two later, didn't get any success with that key. It was kind of like, hey, what's going on here? Thought to myself, well, let's go get a new one, got a new software key, went and used it and the code worked without any changes other than that software key. It would have been great if the documentation when I downloaded that key, it told me, hey, dummy, that thing's gonna expire in just a few hours or a few days. Whatever the rule is. I actually have no idea what the rule is. I just was caught up in it and that creates some friction for me as an end user. Scaling over shattering, right? We're living in this web-enabled world with mobile devices where it's not unheard of to have hundreds of thousands of users hit your app if something happens that brings a lot of people to you. At the same time, you also wanna think about disaster recovery and high availability, right? What are you thinking about your services to keep them up and running under the face of increasing pressure? What are you doing around things like K-native, serverless functions as a service, OpenShift, Kubernetes, containers, and other building blocks to give you easy ability to scale up and scale out horizontally the software that you're running in your organization. What are you doing around the saga pattern and idempotency so that services can just keep being invoked and tell something happens, letting your user be able to just keep on firing request at your services. And most importantly, what are you doing to bend but not break, right? It's one thing to have a slow experience. It's a whole nother experience to get the white screen of death which is always a bad thing for your end users. We'll talk about that here in just a few seconds. Support over stumbling, right? Going back to that Dr. Breed question of earlier, what are you doing to provide your users a getting started experience? How can they self-start with that experience? How can they get started or do you require them to give you a credit card or way more than a password or way more than an email address and a password, right? What can give them to be successful as quickly as possible? I'll talk a little bit about documentation getting started experiences here in a bit but what are you doing to get them to be successful as quickly as possible? What are you doing to make them superheros as fast as possible? And what can you do to facilitate that for them and your end users? So here's an example, right? I'll pick on the guys at Twillow since I gave them a little bit of a shout out earlier sort of. So I wanted to send as part of a proof of concepts a few months ago, a text message, right? And a text message on your phone, pretty simple, right? Your phone has your phone number on it, you then pick your friend that you're sending your text message to and then you send them the text message, right? Download this code from their getting started examples, went in there, signed up for a phone number, gave him my phone number, activated my phone number as a message receiver of text messages from this account, ran that code and once you know it, that my phone number was not valid in the context of this example. And you would think, at least I would think that matching the real world going to that Nelson Norman list of earlier would be an important thing, right? And just thinking about how I use my phone, right? A phone has the phone number it is and the message and the two phone number are together. But you go look at the docs for this and it's actually not that case, right? The actual, the two phone numbers first, the farming phone numbers in the middle, the string is there at the end. These are the kind of things that drive users crazy, a little bit of that friction, toil and invisible work. Sanitization over string, right? I think, well, this is an example out of the Swagger ducks in the spring pet store. I'm not exactly convinced that the update in existing pet semantics on the left-hand side match the semantics on the right-hand side. I would actually argue that that put example of updating a pet should probably have the pet ID on the URL. The other semantics as well as other ones in there are updating a pet or deleting a pet. And I just think that having that URL have that pet ID in there makes me feel a lot better about the way this looks and feels from an end user perspective. I also think it gets you thinking at least a little bit about the difference of creating a pet on the left-hand side and updating a pet in the right and changing the nomenclature of what it is that you're passing around and not making any mistakes you as an end user human. Of course, this gets to my next big headache and this is what is ID in this example, right? Is it a capital IND, a capital I, a lowercase D? If you look at the documentation here, right? The curly brackets have an uppercase I, a lowercase D and then the words they find pet by ID all capsed there in the blue get. And of course, as you go on, you know, there's an XML bark up around this that's going on with this and an example of ID. So which ID should it be, right? Should it be lowercase, should it be uppercase? I would also say these three IDs here should probably be fully qualified. How many times have I spent some time debugging something just because you crossed up the same word in the same way across different classes or whatnot? I would argue that this should be pet ID, category ID and tag ID, keeping the world a little bit easier for your future self when you're trying to debug or just figure out what's going on as you're decoding these things. I would also argue and add that I think ID should always be capital I, capital D, full stop. That's it, done, end of story. If you disagree, put that in the chat and feel free to argue with me when this talk is over. So since over some and right, this is this idea that as users engage with your software that they have the time and the prompts to do what our next best steps are and they're not requiring them to have huge amounts of training or knowledge. And one of the questions or examples I always put out there are your end users, airplane pilots or nuclear power plant operators or are they the trainers of those who is actually you as a software developer, you actually could train the pilots or the nuclear power plant operators of your offering if that is indeed what you were shipping. At the end of the day, I think most of us are just Homer Simpson, right? We are trying to deliver software or use the software once a quarter, once every six months, maybe once a year. There are very few things that we will do that require the type of training that a nuclear power plant operator or airplane pilot undergo for an event that probably will never happen to them. And of course that begets a question, what happens when a nuclear power plant operator is Homer Simpson and thankfully that's a question for another day. So we'll leave that one alone. Safety over setback, right? As your users are engaging with this, what are you doing to allow them to undo things? What are you doing around eventual consistency, idempotency again, thread safety? What are you doing to allow them to be safe in the use of your offering? You give them a sandbox, do you allow them to play? Do you allow them with immutable architecture or infrastructure to just throw away everything that they did with a database instead of touching anything? What kind of rules do you have around how people touch development systems versus production systems and how do you keep all that safe? What are you doing around test cases around all those things? All right, just some of the things that you need to think about in the context of this. And my big ass is error messages. Think about the fact that your end users do not have the terminal access that you had while you were developing that microservice. What are you giving them when they interact with your microservice in a browser or a postman or some other tool to let them know that something did not go correctly? What are you doing to validate that input? What are you doing to let them know that something did validate or words are crossed up? And the last point here is a white screen of death is never okay. You should never not return at least something to the end user to at least let them know that something is up and running and available at that endpoint. Stewardship over suffering for that long-term user, somebody who has invested some time to play with you. What are you doing to make them great at what they do? What are you doing to document the middle, the thick middle use case of the bell curve of what they're trying to do? Like a lot of examples, a lot of projects out there have some hello world simple getting started examples. They might also have every command line switch documented but where those two kind of meet in the middle is not really documented, might not really be tested all that much and it just drives end users nuts and crazy. My friendly ask would be what are you doing around observing your users and removing friction toilet visible work for them? I challenge you, I implore you, go out, watch your users use your brand new software, people that have never touched it in the past, be quiet, listen to what they're telling you about what's going on and just see what they can tell you about what they are struggling with. Status over surmising, right? At the end, you wanna make sure that as you're exiting the user that they have a clear ending. You're letting them know that something has occurred that they have finished up. You might give them some stats about what it is that they accomplished. You definitely wanna do some metrics gathering. You definitely wanna grab some logging. You definitely wanna gather information for the next step which is statistics and study over speculation, right? As your end user is finishing up this, what can you email them to let them know about what it is they accomplished? How are they comparing to others in your use cases and your user bodies? What are you doing to follow up with them about what it is that they accomplished? What can you do to make their experience easier and lighter weight? And the last thing I'll talk about there is user interviews and surveys. And this is a vendor, a nameless vendor from a friend of mine a few months ago and I was snowboarding with them and they were using a new cloud service in the NoSQL database space. And they were in a beta program and the tooling told the product manager that, hey, this person was having some problems. He got an email from them and didn't even realize that this could should happen. The guy asked, hey, can we speak to you about your challenges or our efforts? And he said, sure. They came together, had a meeting. The product manager brought the program manager and a developer. They met on a Tuesday. My friend showed them and screen sharing some of the headaches and problems he was having along the way. Later on that week, that vendor had fixed those problems. When was the last time you were able to both watch and talk to a user of your software and be able to fix that bug challenge or friction point in near real time? Very, very powerful. So let's just, in conclusion, let's just kind of wrap through this, right? You wanna avoid doc debris. You wanna make sure that you have security over obscurity. It's security over slowness. You wanna make sure that you can stand up to web scale type of traffic and workloads. You wanna make sure that your net new user doesn't have to stumble all over the place. They can figure out what's going on organically or very simply. You definitely wanna think about how you're gonna standardize over these things, right? You wanna standardize on ID and words and nouns and all the words that go around your system. So there's some consistency across the entire ecosystem of your services. For your long-term users, you definitely want to give them the idea that they can sense the next best action. They don't need to summon from the depths of knowledge. What is they're doing or trying to deal with? Safety over setback. You really wanna think about how your end users can use your product safely and not get themselves into any trouble. What are you gonna do for your long-term users to let them know and discover what it is they could do and give them some deeper examples and documentation or use cases or test cases they can peruse to learn more about. Over time, you definitely wanna gather what information is available for your users. You don't wanna just guess and assume that people are doing things a certain way. You wanna actually see it with your own eyes. And as time goes on, you definitely wanna gather real-world feedback from your end users and see what's going on there. So at the end, these 10 design tips for microservices developers give you a framework to help you remove friction toil and invisible work. You will make your users smarter when you take away their friction toil invisible work. That's definitely a talk for another time. And please come meet me out at designfordevelopers.io. And I'll have a workshop that I'm gonna call 10 more design tips for microservices developers with some Java and Quarkus thrown in. That's at the end of the month. You can register that at a link I'll put in the chat here in a second. And please feel free to reach out to me and all those fun little links up there. Facebook, Twitter, LinkedIn, Instagram. Feel free to set up a meeting to meet with me if you'd like and or see this workshop in a month. And I will put a link to these slides in the chat also. And with that, we're almost sort of back on time. I gave you guys back a minute or two. And if you all have any questions, feel free to put that in the chat or the Q&A. Thank you very much.