 All right, we'll go ahead and get started. Thanks everyone for joining us today. My name is Dormaine Drewitz. This is Camille Davis. So today we're gonna be talking about why and how. Oh yeah, the ambient noise. No, but it really, it kind of adds to the ambiance as if we're in like a marketplace. Yeah, I specifically requested like the Roman Forum background noise. There's an app and it just instantly creates that sort of vibe. So yeah, anyways, with that, we'll get into it. So this is the agenda slide. In other words, how this is gonna go down. And so first we'll start with why, like why are we even doing this? And this is the untold true-ish story of one developer in her quest for building a complete microservice architecture. Then we're gonna talk about the big ball of mud in the room. We'll get into data and Cornelia's gonna take you through a lot of the considerations there. Then we'll talk a little bit about some other interfaces and how that kind of has to be taken into consideration. And finally, we'll find sweet, sweet harmony and cloud foundry, spoiler alert has a place to play in that. So let's meet Jamie, she's our developer and she's gonna save her company millions of dollars by building an application. It's a vacation request app. There's a lot of people in her company and they're billed by the hour and what they found is that people do their request approvals over email. Those don't actually get logged in their really clunky HR system until many months later. Well, all of that accrued vacation time is sitting on the balance sheet in the meantime. So there is actual dollars at daycare. Some of her goals as she is taking on this project is that she wants to be able to iterate quickly. She wants to be able to build the first version of the product, a minimum viable product if you will and then iterate as she gets feedback from users. Fortunately, a lot of her users are internal so she has access to them but she really wants to be able to take advantage of that and not just use it as a project once and be done with it. She wants to be able to use the tech stack of her choice. She's been learning about a lot of great technology options out there, has ideas about how they might be able to fit in and wants to be able to make use of them if they're appropriate. She wants to be able to support a mobile front end. She knows that all of the millennials in her company all wanna be able to do their vacation requests via an app and she wants to be able to scale it for the long weekends and what I mean by that is not just that it scales and she doesn't get called in over a long weekend but that right before a long weekend and people start requesting that extra day off is when she expects there's gonna be some surges in use of the application. When you think about all those goals, you step back and you squint and you ask yourself, I've smelled the smell before. It smells a lot like microservices and there's some very reasonable reasons why someone would want to take a microservices approach if they're trying to meet all those goals by having a small team that's organized around that specific business capability. In this case, it's the vacation requester app independently deployable with its own tech components allowing teams to produce and consume APIs also particularly useful for now starting to support multiple front ends and then people being able to choose the best tools for the job going back to the choice of stack but there's always a but, there are trade-offs. When it comes to microservices architecture, it's not a free lunch as some people like to say and if you have really good eyesight you can get that URL and go read the entire article but nonetheless some of those trade-offs include well, you're going to take what would be a relatively simple architecture in the monolith and you're just going to start to have a bunch of distributed components that need to talk to each other. If something is failing, how is that going to be handled? How are you going to be able to identify where there are problems in this distributed architecture, et cetera? And so there's a lot of great solutions out there in particular, the ones that she is gravitating towards are the Spring Cloud services stack which are developed based on the technology open source by Netflix, if you haven't heard about this already, everyone here heard of the Spring Cloud services pretty much everyone, good. I only see a couple of people who may or may not have rotator cuff injuries which is preventing them from raising their arms. I know that there's always a rash of rotator cuff injuries right before conferences so I'm completely familiar and I feel your pain. So those are some of the considerations she's already sort of thought about but then there's this other big ball of mud in the room which is that she is gonna have to integrate somehow with that legacy monolithic application that's out there and we'll get into why in a minute but let's just take a moment to appreciate why she wouldn't want to build this new vacation requester app as just a new feature in that legacy big ball of mud. For one thing, it's got few tightly coordinated Big Bang releases so this is really gonna get in the way of her being able to iterate quickly and figure out if she's building the right functionality for the users that she wants to really get this to be an addictive app amongst the population in her company. It's got an existing tech stack. That's, she's basically the cards have already been dealt as it were. It's also got a singular unit of scale and so in terms of what she expects to be her own, it tends to have scaling around benefits enrollment time once a year but there's lots of long weekends and holiday times when people, she expects there to be little mini surges and so that's a consideration she's concerned about and it's got pretty mobile unfriendly APIs so right now it's just a kind of clunky interface that no one really likes to log into and does as few times a year as possible. And there's no real way to reasonably support a mobile front end for the little slice of functionality she wants to offer. So if we take a look at her MVP requirements and this is where we start to get into why she is definitely gonna have to integrate with that monolith for better or for worse. She wants to be able to allow people to look up the number of vacation days they have available. That's usually something that people often want to know anyways and it's certainly useful for them to know before they go through and start saying and I need four more days off. Well, you only have three days left. So they need to be able to select the days they want off maybe from a little calendar interface and then to be able to show the pending and confirmed vacation days that they've already consumed somehow which is not including in scope in this first version but maybe later is the actual workflow of approvals for managers. So unfortunately all the managers are stuck with logging in to the clunky interface but she's gonna get to them later. Now, just in order to do this basic MVP see the number of days you have off select and then be able to see if they've gotten approved that's already touching domain data that's sitting in the relational database that supports that monolith. So that's where I'm gonna hand it over to Cornelia to now take us through some of the challenges with the data side of building this microservice. Awesome, thank you, Dormaine. So exactly as Dormaine said here, we've got this, she's, Jamie's building this brand new microservice-based architecture at the front end. So she seemingly isn't tied to any legacy but immediately there we can see that she is in fact tied to legacy. And to kind of summarize where we were at before was yes we've moved from this monolithic layered architecture and so Jamie's not building this on the left-hand side. She's building that on the right-hand side. So that's brilliant, right? So she, if you look at her architecture she doesn't have tight coupling anywhere, right? Would you agree? Except for that picture that we just saw a moment ago. So if you only look at the left-hand side of the picture, every one of those microservices is loosely coupled and each one, each team that's working on a microservice is independent of the other but that's only if you look at the left-hand side. As soon as you look at the picture in complete you see that they are in fact not loosely coupled at all. If one of the microservices on the left-hand side that's tying to that centralized database needs to make a change to that database then all bets are off. Now we're back into that cycle of hey, we've got to coordinate with a bunch of teams. We've got to change the schema in lockstep and so on. So that's the issue and by way of introduction, again my name is Cornelia Davis. I've been working on Cloud Foundry for about five years and Cloud, in Cloud Foundry has been part of this industry shift where we've really figured out how to do things on the left-hand side of the screen but by and large we have been focusing on the cloud native app and what we wanna talk about now is what does it mean to have cloud native data and so that's exactly what we're gonna go on. Now I'm just gonna scratch the surface here today and I'm gonna start with this picture and say this is Jamie's world. So Jamie's building the brand new stuff on the left-hand side but she has to tie to the ball of mud on the right-hand side. So we're gonna start to back up from that and see what are some of the techniques that she can use to try to keep her team more loosely coupled than it would be if we just had this picture here. So that right there, that picture that I showed you on the previous screen and in fact this picture that we're showing here is the anti-pattern. We don't wanna take a bunch of microservices that are all tied to the same shared monolithic database. This picture is kind of an extension of the previous slide in that it also points out that it's not just all the microservices that are tying to that shared database it's the monolith is tying to that shared database as well. So there's a tremendous amount of coupling going in there. And so when we see this picture we lose a lot of those characteristics that we've been claiming we get with microservices architectures. We actually lose them as soon as we start to look back at the data tier. So we lose the autonomy to iterate. I already mentioned that when one microservice when a microservice needs something different from the database they have to coordinate with the other microservices as well as the the slow moving legacy application team. They do releases every nine months. So am I gonna, is my microservice gonna have to wait nine months before I can make that next release? So autonomy to iterate is going away. The autonomy of the tech stack is now in question as well. Are the drivers for this common database available? Or what if I have a graph oriented problem but I'm tied to this relational database? So autonomy of the tech stack goes away. Performance might be a problem. So I might have some very slow moving back end systems that I'm connecting to and scaling can be a problem as well. If I were to scale instances of my microservice can my back end database that used to deal with maybe a dozen or a couple of dozen connections now deal with maybe thousands of concurrent connections and still perform? Not sure. So these things that we all need and want from microservices architecture we're not sure we can have. So our aim now for the next several slides is try to look at and figure out patterns that are gonna give us these attributes back again. So the first thing that I wanna point out is that there's a category of microservices that you should start thinking about. And I call them for lack of a better term, the data APIs. So these are microservices but they really have data concerns. So they're not just calculating something or they're maybe not just just combining a couple of pieces of information or formatting something or transforming something or transcoding something. But they actually represent a set of data. And so when you start doing those and we don't have time to get into all of the details but in data microservice one of the things you need to make sure is that part of your contract is the data format itself. So you can't just have a blob and say well I'm returning JSON and you go ahead and you change the JSON and well my API didn't change because I'm still just returning JSON. The actual schema in your JSON matters. So there are some concerns around data microservices that maybe you don't have if you have a less data centric microservice. Now so those are some of the things that you need to worry about. But if you then if you're looking at the right hand side here on this picture the before picture was that I had maybe dozens of microservices that were all tied to the single database. Now what we're doing is we are saying actually those dozens of microservices we're gonna give them an API endpoint instead. Yes I totally agree that this database is still a shared database. And you might be thinking that I'm just kicking the can a little further down the road. And to some extent I am because these two are perhaps gonna be coupled but we'll talk about that more in just a moment. But I have more loosely coupled those microservices at the top there. Having those data microservices also gives me a surface area where I can start to implement things like throttling API gateway types of things. So throttling other policy enforcement access control policy applying and so on. So specifically thinking about those types of microservices is the first pattern that I want you to think about. Now how does that do here? If I start adding kind of that data API service layer if we look back at the four criteria that we had kind of actually we're slightly modifying them let's take a look at how these things with that as a ground that is the groundwork how do we do against these different attributes performance resilience, polyglot persistence and schema versioning. So let me point out for a moment that there's just a little bit of a data flavor to these things. These things are all very familiar, right? There are things that we talk about with microservices. We talk about performance microservices give us scale out that's very much related to performance. Resilience microservices if you put them together the right way and that's a big if if you put them together the right way with the right bulkheads and the right air gaps in place then you achieve some resilience. Polyglot microservices we talked about that in terms of the programming languages that you can program in. Well now we're talking about polyglot persistence. Versioning versioning of microservices is something that we have been talking about for several years but now we're talking about schema versioning. So you see that there are things like performance resilience, polyglot and versioning are concepts we're familiar with on the microservices side. Now we're just gonna start applying those to data. All right, so let's talk first about performance and resilience. Now remember what I said when we add these data APIs here aren't we just kicking the can further down the road? And yes to some extent you are. But think about this now. These data APIs are responsible for data. They have state. Now mind you I am not suggesting that that state is living inside of the memory of that microservice or on the disk that's tied to that microservice. The cache itself is an external service that you're binding to. So the application, the microservice is still stateless but it's bound to a stateful cache. Now what does that cache give me? Well it certainly helps with performance because in the past without the cache every request that's coming in here I have to go back to the backend database. So it definitely helps me from a performance perspective in that I'm not going to spinning disk to get the answer. I'm actually just going straight in memory and retrieving that information. So I get immediate benefits from a performance perspective. I also get a certain level of resilience. If I consider that cache a part of my bulkhead to the back end, I now when the back end experiences problems you can design applications. There's many, many use cases where it's better to get back an answer on data that is potentially stale. There's a lot of very slow moving data out there. Potentially stale. Rather than not getting an answer at all. So the cache acts as a bit of a bulkhead. So that's great. We can take this data API, apply caching to it as an additional pattern and achieve some of those things. Now let me talk a little bit more about caching. So I am making the assertion here that caching is an important part of your microservices architecture. Now this slide here, it's a battery venture slide. You can see them on the right hand side there, not my slide, it's from battery ventures. So if it's from battery ventures, who's the individual who this slide is for? Who's slide is this? Adrian Cockroft, exactly. So Adrian Cockroft was a battery ventures. He's now at Amazon. But if you don't know him, you should. But he was the chief architect for the whole transition that Netflix had from their old monolithic architecture, the picture we're seeing on the left hand side, to the microservices architecture. If you look at this slide, which by the way is a sequence diagram in a spreadsheet, which is really weird, but it's there, is that you'll notice that cache is all over this. They've got caching on the client side, they've got caching on the server side, they've got cache services in the middle. And I did put it on here and we will post these slides, of course. There is a fantastic talk that I encourage you to take a look at by a gentleman named Scott Mansfield. He is part of the team that provides caching as a service to the Netflix community, the Netflix developer community. And they call it the hidden microservice. So caching is an absolutely essential pattern for your microservices architecture that starts to bridge the gap over to cloud native data. All right. So then the next thing is, when I have these, if I start to pull out these data APIs, remember I said that they're now surface areas where I can apply policies, throttling and so on. And they're now the interface for the dozens of microservices that are up here. It allows me at this point now to say, okay, are you all familiar with the concept of strangling them on a list? That's where you're starting to take that monolithic application and you're starting to pull parts of it out and externalize them. And there's some very well-known patterns on how to do that. You leave proxies in place in the monolith and then those proxies actually just make calls out to the new microservice that you've externalized. You have to deal with different failure modes and so on, but there's really some known practices around strangling the monolith. Well, if I've already put this data API in place that I can start to strangle the data monolith, I can start to extract data from that and make it its own database on the side there. So that now gives me the ability to have apply the right data technology to the problem that I have at hand. Graph-oriented workload, make it a graph database. A very schema-less type of a data, make it an object store or make it just a key value store. So it allows you to make choices on that and the polyglot persistence is really key. All right, now, remember we talked about versioning. So here we have a picture where we had version one of the API and now we're gonna create version two of the API. So I have consumers here. I have a bunch of consumers. And let's say I had a database schema, that super simple example contrived but easy for us to understand. For some reason, version one had a name field, a single name field, not first name, last name, but a single name field. And now there's microservices up here that they're like, you know what? I really need to break out first name and last name. So what we do is we don't make all of those consumers move in lockstep. We create a second version of this API and remember part of the contract isn't just the API contract, it's the schema contract as well. And we say the schema changed. So I'm not backwards compatible, I have version two of my schema. And of course I have caches in both places. Now, does that mean that I have to change the database when I come out with version two? No, imagine that version two could now say, as a stop gap until I version my database schema, I'm gonna go ahead and parse that. I'm gonna do the first name, last name parsing. And to make sure that I maintain my performance, I'm still gonna involve the cache. So these are the types of patterns that I want you to think about. Now, the reason that we're doing that is because we still want some autonomy and I'm gonna go, I'm almost wrapping up here on the data patterns. So we've got version one has the blue schema, version two has the yellow diamond schema and right now the database has the orange triangle schema. Notice that I am not, even in version one, I'm not necessarily projecting exactly the schema that's down in here. And that's one of the things that the data API gives you is the ability to disconnect your actual implementation the bits on the disk from the way that you're using that. And that's a really important pattern. Now, I can do a number of things. I can evolve this a number of different ways. So I, and notice there that at some point I'm probably gonna involve the database schema. So let's look at what we used to do. What we used to do was we didn't even have this layer at all. We made all of the folks up here move from the orange triangle, which was here, to the purple plus. And we made them all move at the same time. And that was complete lack of autonomy. Now we've got a bunch of other options. One option is the one that I just talked about, which is to say, hey, I'm gonna leave this one talking to the orange triangle. I'm gonna take the new schema and it's still gonna talk to the orange triangle but I have these things versioned side by side. Because it's not backward compatible I have version 1.0, we're using semantic versioning here. 1.0 on the left, 2.0 on the right. Eventually, I can migrate my schema over to on the database and now I'm versioning 1.1 and 2.1. So that doesn't mean at the same time that I need to version, that I need to move all of my microservices that are consuming the data APIs. Another option and I won't go through it in detail is you could say, well, I'm gonna go ahead and do the database at the same time. And the one that I do wanna leave you with is there's this interesting one that says, well, wow, can I actually have version 1 tied to one database and version 2 tied to another instance of that database? Is that complete crazy talk? And I'm gonna suggest to you that in the cloud native data world not entirely, and this isn't to talk on this, but here's the tagline, think unified log. Think about these databases really just being materialized views of a system of record that is the unified log. So that's a whole nother talk, we'll do that some other time. So those are the patterns that I want you to think about and I'm gonna hand it back over to Darmaine and she's gonna help pull all this back together. Thank you, Cornelia. And I wanna make sure everyone got the bit about every microservice needs a cache. So now take a moment, reach under your chair and find your very own cache because you get a cache and you get a cache. Sorry, I just had to have an Oprah moment. Okay, so we're gonna, I know there's tears coming down from his face. All right, so we're gonna shift gears. The data part is arguably the most difficult part of Jamie's task to kind of wrangle with the monolithic database that is tied up in the big ball of mud. But now we're gonna shift gears and kind of think about the front end of her experience and where there's some other elements for her to consider. So on the front end, she's now thinking about supporting a couple of different front ends including a mobile front end. And that introduces a number of challenges that arguably are challenges anyways, but they become really amplified in the mobile world. And so things like bandwidth management, you know, all those users who are consuming over a wireless network or a cellular network, there, you wanna be really careful about the data that's getting sent over that network. You wanna be really careful about the number of calls that have to go back and forth over that network. And so that alone becomes something to manage. There's some other kind of challenges to think about which is just around security and authentication between the different microservices and then traffic management. Always wanna be considerate for the potential for huge influxes of traffic, whether they're for a long weekend or perhaps something more nefarious. So this is where something like an API gateway kind of sitting in that layer between those front ends and then the rest of her microservice architecture becomes really useful because it provides this point of control in front of those front ends where you can do the transformations of the calls so that now when a mobile application is gonna be requesting data, it's doing so, it can do so with fewer calls and send back just the right amount of data that needs to be sent. And that's gonna really help with that bandwidth management. Also, thinking about, now the API gateway doesn't have to just sit kind of in front. It's something that can actually also be embedded in the container where those different microservices are running. And that provides another interesting point of control for things like OAuth authentication. And so those are both useful things and you can also do traffic management at either a kind of macro API gateway layer or that micro gateway that's sitting in with the container of the actual microservice. So I wanna be conscientious of time but nonetheless, these are some interesting points of control that she wants to bake into her architecture. So the stack is starting to take shape. And I know I've left off like a couple of things. There's obviously a lot of things to consider with spinning up a new app like this but in the interest of time, we just focused on these points. But her architecture and her stack is starting to take shape and you can start to see that there is still kind of the front end and kind of the middle and then some of the back ends but there's now different services with different discrete tasks that she's able to break apart. And when you kind of take a quick snapshot of what some of the data requirements are, as you can see, there's cash for all the different microservices but there's, and those are often very read heavy. The user database is something that is gonna need to map to the SQL database because that's important. And then you might have another part that's a very right heavy. So all of this is kind of pointing to some challenges around, okay, well how am I optimizing for read heavy workloads and write heavy workloads and just some of the different requirements that come up. And this is really one of those points where when you add that plus API gateways and now there's all these different components that she really wants to bring her own tech stack to the table. And when she's figured it all out and she goes back to her ops team, her just basic ask is please don't tell me this is gonna take three months and then you're not even gonna support it in production. This is a question I'm sure we've all asked other people or ourselves in the mirror with a stiff drink in our hands. It's just, I don't know how your Tuesdays go but nonetheless, fortunately, her company has adopted Cloud Foundry and so they have a whole menu of options available to her to quickly pull us together. This is just a small snapshot of some of the different services available in here. Since I work on Pivotal Cloud Foundry and I focus on the ecosystem around the Cloud Foundry platform at Pivotal, I'm sharing with you some of the options that are available on the Pivotal network. But when it comes to relational databases, tons of options from MySQL and Postgres, some of these are available as on-demand databases that will be provisioned as Jamie needs them. Other ones are available where they can be, just a table can be set aside for her in an existing database. From a caching perspective, as you probably noticed this icon here in Cornelia's slides, and this is Pivotal Cloud Cache. There's also various Redis flavors which can be used for some caching, but Pivotal Cloud Cache has a lot of interesting advantages particularly around its ability to scale. And then if she wants to use, say, a document database, there's a couple of Mongo options. And then when you add in the Spring Cloud services, which the Netflix OSS technology for configuration management, service discovery and Circuit Breaker, those are all available as the Spring Cloud services. And even a notification service, like push notifications so that when one of her users finds out, oh, your vacation has been approved, that's also available as just its own microservice out of the box, complete with its own stack. And then for API gateways, Apigee and MuleSoft are both options. So with that all in place, in four weeks, she's able to get her minimum viable product and start getting it out and testing with a small group of vacation-hungry users so that she can now start to iterate and refine this and be well on her way to saving her company millions of dollars for their accrued vacation. So there were a number of different resources referenced either explicitly or implicitly in the presentation. So I want to share with you just a couple of those. Great article from Kenny Bistani on strangling the monolith. And so if you want to dig in more onto the strangler pattern as it pertains to sort of taking the domain data off of a monolithic database and start to strangle that off for a microservice, that's a great read. Cornelia is coming out with a book and I'll let her share some exciting news on that in just a moment. There's also the video that she mentioned with Scott Mansfield and also kind of a fun short video with a couple of folks over at ThoughtWorks, Cassandra Shum and Rachel Leighcock on the pros and cons of microservices. So with that, some exciting news from Cornelia. Yes, indeed. So I am writing a book. It is, I'm writing it for Manning and we are in early access, so it has been released. The first, I think three or four chapters are out there already. And we were yesterday, deal of the day. So Manning does deals of the day. And I told them, well, I'm at a conference this week and they said, oh sure, we, for your conference attendees, we can extend deal of the day through the end of the week. So through Saturday, you can use this conference code here to get 50% off. And that would be either ebook or print book. That's totally up to you which one you choose. And if you have not been part of the Manning Early Access program, we basically, about every month or so, will continue to release a chapter. And I would be so, so grateful for any feedback that you might offer on that. So I think I'll let you close it up there. We'll leave that up for just a few more seconds so that you can take your photos of that special discount code. But wait, there's more. It's not a slap chop. We are having spring one platform at the end of the year. And the early bird pricing goes through, I believe, June 24. So in addition to that early bird pricing, there is a special code up here to get $100 off your registration. So did you guys know that this was going to be like a coupon prize at the end of the talk? Yeah, probably, yeah. You guys are, tell your friends it's fine. If they're here, you can tell them. But yeah, go ahead and snap a picture of that discount code as well. We hope to see you in San Francisco in December. Thank you.