Microservices: Patterns and Practices Panel

Transcript

So, welcome back to the microservices patterns and practices track. So we have all of the speakers, save one, but that's cool; to talk about -- yeah. C'mon up. We have all the speakers, this is great. Awesome, all five of us. So very informal, I didn't correctly -- you know, this is what you want to hear from us. So I think we will try to figure out how to center -- have a mic for you and us. Awesome, we have two, I can be the runner around of things and maybe I will ask for a volunteer to help me with that. I will keep this one. Cool, fire away.

How do you manage your data when you are doing green deployment? So, for instance, you might have a version that writes new records in, that the old version doesn't understand, and how does the old version know it is not an error and that it is actually real data?

Randy Shoup: I have an answer for that, but why don't you take a stab at it first.

Roopa Tangirala: So when you have changes at Netflix, you can do it, it is stateless, it is not a problem. But when you have changes for Cassandra, it is schemaless. So when you are adding a new column, or changing schema, you don't necessarily need to do a DDL to change the schema. You can directly keep inserting into the new data set, or the new column family, the new column. That is one way.

And the other way, if they help to do migration from one column family to another, we help them build tools, we own the client libraries, so we can help them write to the old and to the new, and we have tools like fork lifter, which helps lift from the source to the destination, but not all deployments need changes where we are moving data around, at least that is what Netflix has.

Chris Richardson: I would add, so to zero down time deployments, constrain the kinds of changes you can make at the database level. So you can add a column, for instance, but you cannot just drop a column. So it is sort of careful make changes, and decouple database schema changes from, like, your zero down time deployment.

Randy Shoup: Yeah, don't do what you just said. Not even kidding. So what you did is you broke the interface. You made a non-backward compatible data change and you exposed it to other people, and you did it in a way, like, in between a minor release. So if people are familiar with semantic versioning, what you just described was a non-backward compatible major version change. Does it make sense what I'm saying? We used to produce data in this form, and now we produce it in this non-backward compatible other form.

And so, don't do that. What you can do is what Chris said, which is -- and we can talk in detail about the change you wanted to make. There are lots of ways to make backward compatible changes. You can add an optional field-we need to talk about it in a little more detail, sadly. But yeah, the idea is that, you know, as a service owner, your primary job is never to break the people that use your service. o you are never allowed to break clients, which are consumers of your events. Conceptually, does that make sense?

Yeah. Okay, cool. Way in the back. Actually, I will go here first, and then I will get to here next.

So, one of the things that we have found is deciding boundary contexts for microservices. It could be as easy as, like, okay, we are having orders, and then there could be five types of orders, and now we know microservices is a monolith after a while. How do you decide boundary context so it is good enough after a couple layers?

Louis Ryan: I mean, mostly it is probably going to be informed by your development practice in your development decisions, rather than any strict semantic thing you would try to guess from the get-go. I mean, I tend to think of microservices as emergent patterns that come out of the need for decoupling. I don't have the microservice caliber on me. It is -- so it is, you know, it takes effort. But usually, you know, the decoupling works at development team boundaries pretty well, or at functional responsibilities within development teams. That's where I would start.

Chris Richardson: Yeah, I would sort of say this is one of the hardest problems, and it is really not specific to microservices. You know, this is basically another way of re-phrasing it is, like, what are the boundaries of my module, right? And I think, picking module boundaries is difficult. And, unfortunately, there is no, sort of, kind of mechanical process that, if you apply it, you will come up with a perfect kind of set of module, some module boundaries. So, in the case of services, it is like, yeah, most of them are organized around particular business objects, like order management and customer management and so on. But that is your first guess, and you go with that, and if later on you find out that some services got too big, then hopefully at that point there is a clear enough boundary between the two internal parts of that module so you can split it in a meaningful way.

And then, just to sort of echo what Louis said, the point of service is to enable a small team of developers to deliver rapidly and safely. And, so, it is like -- if a module, you know, if a service gets too big, that really means the team that is developing it has got too big, and they are weighed down by communication overhead. And so you kind of want to split the team, and you want to split the code, so they can go back to being a small, nimble team again.

Randy Shoup: I have one more thought, and then I will go back to the guy with the earlier question. So one of the things that I assert because I believe it is probably, if you are, you know, the five-person start-up, you might not want to start with microservices. Part of the why is that it is still a little bit complicated, maybe a lot complicated to build a distributed system, and everyone's questions are around things that are complicated. When you are small you want to start of doing something different. And another part of it is you want to understand your domain and decompose it in a reasonable way before you do microservices. Does that make sense? Microservices are just a physical manifestation of a decomposition of your domain. So I have found, because I have tried and failed to do it many times, my first cut at a new problem and figuring out what the decomposition of the domain is- I mess it up all the time. And I have gray hair/no hair, I have been doing this for a while. So there are two rare exceptions to the rule of maybe don't start with microservices when you are tiny.

The first is, if your MVP, if your minimum valuable product requires scale. So if you are building the Heroku competitor, for example, you are building internet infrastructure, you better scale from the beginning. That's a requirement. And the second is, if you know your domain super well. So the examples there, and I can think of, one great example is people building new banks, right? So Nubank from Brazil who gave the first talk yesterday, in the Architectures You Always Wondered About track, they started with microservices. Why? Because the composition of the bank you have known for the last 50 years, because the components of the bank are really well-understood. But for the rest of us, we don't know the domain well enough, and that is why this is such an important problem.

We know that we're a monolithic application, and we know that we want to get to business context-type services. But where does that line draw- is it a product level, an API level, a microservice level? Where is that line? Is it just what feels right?

Rafael Schloming: Sure. So, yeah. That's a -- that is a hard question, but I think one of the ways to, sort of, help think about it is actually something Randy said earlier, which is don't think about the size of a microservice in terms of its, the lines of code, think about the scope, and how do you define scope? Well, you need to understand what it is you are trying to achieve at a high level, one or two sentences. So I always like to think about, you know, and this actually goes to the question before around how do you know if an API is done.

It is really a negotiation between the user of a service and the team that delivers that service. You need to track the usage, if your users are happy, then you're done. And, well, yeah, assuming you don't have to change it every five minutes. And so, yeah. And so it -- it really helps to think in terms of that framing, understanding who the user of the service is, and going from there. And, from that perspective, you can just try a lot of different kinds of APIs that will sort of serve the same mission and figure out what you need. And, again, you can track how successful you're making your users in order to measure your progress as you, sort of, iterate through the difficult design space. So that's what I would say.

Randy Shoup: So this is a little bit of a flip response, but I don't mean it in any aggressive way. Do you guys know, do you build one class, like, one language class in Java or whatever? No. How do you build, how do you know what the scope of the classes are? That's a design thing, the class is a single responsibility; we try to make the interface minimal and try not to be chatty. The reason we ask it that way is not to put you on the spot, and the people that are working for me are laughing right now: this is a thing that I have done many times with my team where, this is a legit thing to say. Man, microservices, we have never built services before. Have you built classes, have you built, like, interfaces like within the particular, you know, language environment that you are? Oh, yeah, we have totally done that. How do you figure out what goes in and out? That is simple, and we refine it over time.

That's the answer; you know more than you think about how to design services. If you know how to design classes, for the most part, you know how to design services. The only part is recognizing that you cannot be as chatty with services as you can be with something that is in process in your, well, in your process. Does that make sense? But, other than that, you already know. If you know how to build applications, which you totally do, by who is on your badge, you already know more than you think you do about building services.

Chris Richardson: Yeah, and the decomposition applies at many levels. In a sense, you decompose methods and classes and packages, modules, and so the microservices is just yet another level in that kind of hierarchy. One comment I would add is that I think microservices kind of have this important relationship with team structure as well. Like, for me, I think there are two models for microservices. There is this super fine-grain model, which is one service per developer, which seems to be happening at some companies. Right? Or, when you have, like, thousands of services, I mean, that sort of that order of magnitude. Another way of thinking about services is that a small enough, quote, “application” that a team can remain nimble and agile.

And that is sort of -- that is a much coarser grain model of microservices. And so that impacts decomposition.

Louis Ryan: So, yeah, I mean, I think it is probably a common problem for a lot of people in the room, that they have a monolith yak that they want to shave, that is totally fine. Start shaving where you think shaving adds value, and stop shaving where you are not getting any more value. It is okay to have a monolith if it is doing what it is supposed to do. I know that might be heresy here, but if it is doing what it is supposed to do. If it is not, shave it, and iterate.

Randy Shoup: Sorry, this was an excellent question at the break. I will shut up after this. The excellent question was more or less, hey, are microservices worth it? And the answer, for most of us, maybe not, right? It is -- again, as I tried to say in my talk, it is the .1 percent, .01 percent that get to really large, where you absolutely -- there is no way Google, Amazon, Netflix, StitchFix, work without microservices. But microservices, if you don't have a huge load, it is fine to stick with a monolith. Like the point, when should we stick to microservices? Well, when should you, when are you unable to scale things independently, when does it slow down, when do things evolve at different rates? That's the wall that you have to scale. But if you're happy, I'm happy- we will say it that way.

Chris Richardson: And I want to add to that, like, you know, if your development velocity is not where it needs to be, I would actually start to review your development practices before switching to microservices. So, for instance, if you are not doing automated testing thoroughly, and I think probably 70-plus percent of organizations, according to a source lab report, are not -- have not, like, completely embraced automated testing. So if you are one of those, work on that first. And then, you know, once you have the hang of that and you really are able to automate as much as possible, then think about the microservice architecture. It is kind of like, try running or walking before you run.

Rafael Schloming : Yeah, that's a great point. Excuse me, that's a great point, and a great thing to do is just, it doesn't need to be super heavy weight, is to track where you spend your time. If you are doing lots of manual testing and that is slowing you down, you don't necessarily think about that on a day-to-day basis. And, you know, if you are spending a lot of time wrestling with particular areas of your monolith, maybe that's the time you should start shaving your particular patch of yak.

Louis Ryan: So I think Randy gave a couple examples of why you might want to do that, scale being the more obvious ones that is quoted in the industry. I think there are other reasons; security is a big reason why you might wanted to shave your monolith, because you have two things that should not be stuck together in the same trust domain, that's a big reason. he development experience is clearly one, release velocity is a big deal. So there's a variety of reasons out there, you know your domain, you know what is going on in your domain, you should be able to reason about those reasons to make those types of decisions.

Chris Richardson: Yeah, it is interesting, from my perspective. I think that microservices are primarily a way to tackle complexity rather than scale. Scaling, I mean, obviously, it is a way to scale, but complexity is first.

Yeah, I had a question along the -- can you guys maybe comment on what the patterns are that teams are using to get to microservices? Do they start in the middle where it really matters and it is an important object, or do I do it on the side where it doesn't make a big difference, and can I just slap a rest API on an existing app and call it a microservice?

Chris Richardson Well, you know, if you are -- if your yearly bonus depends on having a microservice… But, I was just going to make a joke. But, no, I mean, microservices -- this term microservice really does get heavily abused, right? Like this motion, can I -- can we use a microservice for that is sort of just kind of the wrong notion, I mean, from my perspective. Microservice is a short hand from the microservice architecture, which is an architecture style for the application; it is all about having a system.

And one thing to think about, and so if you have this massive monolith, and if there is one part of it that is under very, very active development, and another part that you never touch, then if you want to extract them out, you know, if you want to build a microservice, or a service, then extract out the parts of your application that are frequently changing. Because that will give you the, sort of, biggest bang for the buck.

You know, if you think about your monolith, that is on the slow track of development and everything that you extracted out of the microservice is on the fast track, the rapid deploy and all of that. So you want to invest the effort in those areas that really, really make a difference.

Randy Shoup: So, as always, I have thoughts. So here are my thoughts. The steps, so I'm going to make some architectural change from the monolith to the microservices. So I want to prove that this fancy millennial way of doing a microservice is actually a thing, and will work in our environment. So the step zero is to do a pilot. And so the way I would like to think about that- let's take a vertical, end-to-end actual experience that matters to our business, like, I don't know what your business is. Let's imagine that you have something that actually matters to users and build that in a new way. So it could legitimately be a new thing you will build a new way, or re-build an old thing that exists in a new way. Either way, take a vertical end to end thing and build it in a now way. Why?

We are building a pilot, we want to de-risk it and we want to learn all the things we don't know about the microservice thing. We are doing it as a pilot rather than building the entire infrastructure. We do a vertical end-to-end user experience because we want to be able to be focused on some particular thing and that tells us what we need to do and don't need to do. If we choose something that doesn't matter, we don't know what is in or out. If we choose something that is actually useful, then that will help us to focus on the minimal thing we need to do to get our job done. And the other reason we choose something useful is if that doesn't work, at the worst, we have provided some value to our customers.

Does that make sense? So that's the step zero, that pilot. And now that that pilot is successful, and we have learned all of these things about how to do things in a new way, we will call it microservices, now the steps 1-N are take the things that have the highest return on investment, not the easiest things, not necessarily the hardest things, but the things that have the highest return on investment and we convert those to the new way first.

So this is a bit, I'm intending to, like, over, you know, the consumer, I want to over arch all of the comments that people are making. So think about the areas that are really fast-changing, maybe that has the highest ROI, or the part of the site with the highest revenue, that would be a place where it would be valuable to move faster to make more revenue. So does that make sense? You did the pilot, you de-risked it, and then you do the highest ROI, and then the second and third highest, and you keep going until you run out of patient or resources. And if you run out before you are done, that is cool, because the monolith that still exists is not something that you care about. There wasn't the ROI, it didn't go above the bar of what it would take for us to, you know, get motivated to convert it to microservices.

That is exactly what Ebay did. So when Ebay- people who were here have heard me talk before about Ebay had this monster C++ monolith and they broke it into many applications written in Java. So it wasn't microservices, but the principle is the same. Once they did the pilot and they convinced themselves that Java can work in the Ebay infrastructure with the skill set and people and all that kind of stuff, then they basically reverse-sorted the site by, like, which -- they took the pages on the site and reverse ordered them by revenue contribution. So the top revenue page they converted first, not because they desperately wanted to have the greatest risk but, if and when they ran out of patience, money, or resources, they did the most valuable thing first. And even by the time I left there in 2011, they had started the re-architecture in 2000 or 2002, or something like that, and they had mostly finished by, I want to say 2007, or 2006. It took a while, and even after I left in 2011, there were still things that were on that V2, like, C++ monolith architecture, but they were things that nobody used; they were simple, they didn't change. So there was no ROI to convert it to the new way. There you go.

My question is about the communication between microservices. So we talk about having events, so service A talks to service B- I'm here by the way. So what if, for a business-critical service, like credit card processing, and say we see lot of patterns by Kafka or other brokers, once I received the -- once the message is in the broker, then there are ways to recover, or re-try. But what's the recommendation to ensure that, hey, the credit processing service does issue the event? I see, for example, Kafka now has Kafka connect, and with every DB commit, or every DB transaction, it could publish straight to Kafka. What if the business object is not the same as what you have in the DB? So I wanted to get your ideas here.

Roopa Tangirala: So in terms of services, owning the source of truth, so each application service is the source of truth for the data it is serving. So for payments processing, in Netflix's case, they don't use Kafka, they have different payments tools. They are using transactional data tools for that payment processing. But basically the idea is that each service is owning the piece of data it is responsible for, and it is the source of truth for that. Right?

So, and that is how the interactions happen, like, other services will ask the service instead of directly either copying the dataset or having multiple copies in their back-end.

Chris Richardson: There are several parts to it. One is atomically publishing a message when the data changes. So conceptually, there's a transaction involved in updating the database and publishing a message. And so, one of the things that I'm going to cover in my talk, which is next- apparently the track host is not going to be, there, because he is going to be giving a different talk. So anyway, there's a whole thing around transactional messaging, which is a way to, which is kind of a super interesting topic. And then, so it ends up reliably being published to the message broker.

So that's, you know, step one. And then step two, your message broker has to be reliable. So that's what Randy was talking about with at least once delivery. And then the consumer-end, you need idempotent event or message handling to ensure the correct semantics, and that includes keeping track of all of the message IDs you have seen. So it is a whole complex topic that I will talk about later this afternoon, and some I cover in my book, Microservice Patterns, shameless plug.

Rafael Schloming: I just wanted to reference back to the, you know, it is like designing classes, this area of ownership is -- ownership and the whole area of communication, and this whole event thing. That is where you are transferring responsibility for ownership of some data. And that is where microservices get the most different from designing classes, or one of the areas they get the most different from designing traditional class APIs, because you don't have to worry about, you don't have this same, sort of, locality of data in the context of a, you know, a class hierarchy. So it is just something to keep an eye out for.

Just a follow-up question, I guess, a bit of a dovetail on the last one. Related to the event-driven architecture, can you share your thoughts from the panel on the use of either pass by value, pass by reference on those messages, and how the consumers work with that message and maybe your thoughts on how to handle ordering of those?

Louis Ryan: I can give my opinion, which might also be slightly heretical here, but this is influenced by Google scale. We mostly don't do it. Most service to service communication is not reconciled through a broker. We use things like retries and network level things to get scale by not hitting storage. You know, and so again, it is one of the scale questions. If persistent queues in storage gives you reliability that you need at your application level at scale, then you should use it. And I think, at certain scales, some of the patterns might become a little bit more limiting, particularly depending on the amount of work waiting for that. Right? So it is not that we're anti that pattern, per se, we do use that pattern, and we use that pattern encapsulated behind an API with a clear segmentation of responsibility. But, for the most part, we don't do it. We don't do rendezvous or that type of thing.

Chris Richardson: I can't believe you don't use Kafka.

Louis Ryan: We have things that look like it.

Chris Richardson: No, that was a joke. But Kafka seems fashionable.

Louis Ryan: So I hear.

Chris Richardson: Rightly or wrongly. So, for me, so when you -- so when we have been talking about event, in my brain, what I have translated that into is domain events, which are a concept from domain-driven design. So if you go read one of the DDD books, you know, they have, like, Implementing DDD by Vaughn Veron or Vernon Vaughn, it has a chapter on domain events, and including what you should have in an event, you have a choice. If an order is created, you can publish the order ID, but that is of no use to the consumer because they have to get the order. So there's the concept of event enrichment, which says put useful data that is useful to the consumer in the event. And when you publish an order-created event, stuff the order details in there. And when you are using event sourcing, where your events are your storage mechanism for your domain objects, you have no choice except to put the necessary data in there.

And then your other point was ordering, yes. I think ordered, at least once, delivery of domain events is really, really important, because if they arrive out of order, then you are going to have pretty weird behavior. And I mean, there might be other situations where you don't care about delivery and you can just pub/sub an event, but ordering is usually quite important.

Randy Shoup: You asked THE question, which is how I deal with event delivery when I get the thing multiple times, and how do I deal with event ordering? So both of those things you don't have in event process or in messaging across a distributed system or those problems. And yeah, I think we have given parts of the answer, and I guess I would say, I mean, I keep threatening to do this event Master Class, it can be -- every time I give a talk about this stuff. There you go, well-played. And so, yeah. Let's see.

So, again, on delivery, you can have at most once, or at least once. If you care about your event, you want at least once. So that is on failure; I deliver it two times, three times, N times. At most once is basically for logging data, things that on failure you want to drop it. Domain events do not fall into that category, but logging things are. That's the first thing, and then you have this multiple times, and then you have to be idempotent, the client has to cross reference that multiple times. CRDTs is something you should look into if you are kept up at night by these problems, conflict-free replicated data types.

And then in terms of event ordering, A, one of several ways to deal with it. You can deal with ordering in the bus, blech, that is not so great. And the other way to deal with it is to have events be the notification of a thing happening and then you go and read back to the service that produced the event for the current state of things. These are all legit ways of handling a problem, and think about these answers -- there's Randy's way to do it versus Chris's way to do it versus Louis's. Think about that there's a space of solutions to this problem, and don't takeaway from it solving by reasoning with first principles. I tried to tackle it by saying, this is easy- no, it is not. A lot of people have done a lot of thinking about this for decades.

And Martin Fowler of Refactoring Fame gave a wonderful keynote, it is pretty short, 18 minutes, at GoTo Chicago this year on event-driven architecture. And he does, in his wonderful way, very clearly, he goes through the pros and cons of events as notification, and events that carry the data with it, event sourcing, etc. That's well worth your 18 minutes to check out.

Louis Ryan: I want to throw in a cautionary tale, or not necessarily a parable, but I gave a talk earlier on super powers, beware of super powers. Event brokers are super powers. Be careful when you put things into queues where you don't know where or how they are going to come out, or who they will come out to. If you don't know the answers to those questions, you shouldn't put those things into a queue until you can answer the questions. If you have data that you care about or your users care about, you need to reason about those things to some degree. And event brokers have been pitched as a way to give operators control so they can answer those questions, validate that. Okay?

Question from here, again. So let's look at some evolution. So initially when the web started, everyone was writing interesting apps, and then came Rails and MVC and Rust and then people started writing that, and then we had monolithic scales slowing us down. Now microservices is the buzzword. You cannot walk into a company and not hear the word microservices. So if you just step back and say, what are some things that you foresee will happen after the microservice trend saturates? What is next? Microfunctions?

Louis Ryan: Didn't that already happen?

So I wanted to step back and see, from a different zoom-out lens, what is next, what do you know -- do you think will happen?

Randy Shoup: The meta answer is look at what Google, Amazon, and Netflix is doing now. Meaning no shame if you are asking that question, I will be flip, if you are asking that questions, you are years behind these people, and that's a good thing. You don't have to reason, you can look at what these larger architectures are sharing.

Chris Richardson: Yes, that's an interesting one. At some level, there's a limit beyond which it doesn't meaningfully make sense to decompose a module, right? And so, like, if you go back to some of the classic work in object-oriented design, the common closure principle, the things that change for the same reason should be packaged together. And that means, if you decompose a package into two packages, and really, you have split this business concept across those two packages, then whenever that business concept changes, you are changing both of those packages. So you are going to see this lock step.

So certainly, to me, there's a pattern in an anti-pattern in the microservice architecture, the distributed monolith, where you are really releasing multiple services simultaneously because of that. So that's one part which is sort of, from a logical perspective.

And then, you know, from just sort of nuts and bolts technical thing, you can certainly say that, when it comes to deployment, our unit of deployment has been getting, it is increasingly lighter weight and more ephemeral. So, 10 years ago, if you wanted to deploy something, you had to get a physical machine, or 15 years ago. And now you just deploy a lambda on AWS, and that is like -- and in such a short amount of time, that's a radical transformation in how we deploy things. And so that, to me, is one kind of huge trend. And even from a design point of view, there's this common closure principle that you have to keep in mind.

Rafael Schloming: There's a way I like to think about this question that is very complimentary with this, but from a different perspective, and that is thinking about the trends in terms of how many people you need to accomplish something. If you look at the transition from monolith to microservices, through the organizational lens, it is like a shift in the division of labor, right? You are taking the output of, you know, a team, an engineering team of thousands of people, and you are fundamentally assembling the output of that work in a different way into a single, coherent hole. And the trend has been, if you look at, you know, what, 10 years ago, the size of a team it took to deliver a given service. I mean, today, a teenager could do the same thing out of his parent's basement in a weekend. And so, at least close to that.

And so I think that the limit of this really comes down to, okay, right, what's the point where that team size, you know, you can effectively stop shrinking that? It is how much a single developer can absorb and accomplish, until you throw in something like AI, which I'm sure people are doing now?

Chris Richardson: Can I just respond? One thing that is interesting is I don't know whether the productivity of an individual developer writing code has improved. Right? Like, writing and creating brand-new code. So I look back and, some things have changed, right? Like machines have gotten faster and bigger, and if we are stuck, there is Google or Stack Overflow. And then there's all of this open source stuff, so we can quickly assemble a bunch of libraries together, and if we get stuck, we Google the answer. But, in terms of writing code from scratch, I feel like it is an individual developer muddling along somehow, scratching their head. And, if that hasn't changed, we have not had a Moore's law for software development in that regard.

Louis Ryan: So if we are in the realm of predictions, you know, I think some of the answers are sitting outside in the vendor booths. More and more of your code is running on the same network, and I'm not meaning yours, I'm meaning all of you at the same time. You are all putting your code into cloud vendors; it is much more local with everyone else in this room than it was before. So we have this interesting networking effect. Microservices are not just a way for you to build services. It is also a way for you to consume services that other people have built for you.

So I think, when I look out there and I see vendors selling certain types of services, the thing that strikes me is that they're smaller versions of things that bigger vendors used to sell. I look at the APM space when I see that. And you will see the trend continue when there are more microvendors; there will be more marketplaces that help you acquire interesting things. Like somebody asked about geo location. You can buy that as a service. It is a tiny little service; it does very little in terms of an API and a huge amount in terms of the back end. So that is one thing that we might expect to see going forward.

Rafael Schloming: I think that those two answers spark a thousand, sorry, that sparks a lot. I don't think a developer writes a thousand lines of code, but they are way more productive because they figure out how to assemble a lot of things, and the other things that you just mentioned, or what you just mentioned is an example of, sort of, that marketplace of other things to assemble.

So when I log into an application, like Netflix, it is a pretty frictionless user experience, you know, I log in one time, I don't get a sense that I'm logging into the microservice for my user profile, and then I don't log into or re-experience the -- my customer history, etc. So how, in microservices architecture, do you maintain this frictionless UI? Because most of us are writing applications that span multiple services but, from a user standpoint, it is really just one thing that they are, one application they are trying to go to. So how do I maintain the advantages of a share-nothing architecture where I can deploy independently, I don't create these dependencies between them, but at the same time, I'm maintaining a user experience that is frictionless, unified, and the same consistent look and feel? Thanks.

Roopa Tangirala: Sure. Hello. So, yeah. So the way to look at that is, like, there are different tiers in the microservice layer as well. So there is front-end, which is taking all the user traffic, and then we have middle tier and back-end tier, which is your membership and all the cool services that give that data set to you. And so, in terms of the UI integration, there is a lot of interaction between these services, but, at any given time, the source of truth is just one service, right?

So, in terms of interactions with the UI, all of our UI team, and I'm not -- I don't have a lot of insights into that UI layer. But they do a great job in making sure all the interactions between these microservices and the results that they are getting in the UI are seamless. There's a lot of work that goes on behind the scenes, but each microservice is not related to the other. So that way, you know which service to call. So though there's a lot of interaction, you have fallbacks as well. So from the UI point of view, you don't see that you are having a degraded experience. If you are not able to get your personalized list of movies to watch for, that service, if you cannot go to that service, then they may fall you back to a fallback page. So you might not experience degraded service; you are not thinking you are not seeing your active list of movies, but with the service, it is giving you the fallback experience.

Great. So we are out of time. That was an awesome set of questions, thank you so much.

Live captioning by Lindsay @stoker_lindsay at White Coat Captioning @whitecoatcapx.

See more presentations with transcripts