 All right. Thank you all for coming here this afternoon. My name is Richard. I work at Pivotal. I'm Arthur. I'm work for Microsoft. Today, we are going to talk about serverless even now. Yeah. We're going to have some fun mostly demo. We're going to show you a lot of code that may or may not work. So it's going to be really exciting. Then we are going to show kind of a venture of an architecture. We're going to take a look at a lot of different Azure functions, give you a sense of how things work together. And the point of this is also to show you how Java works well on Azure as well as Cloud Foundry. Give you a sense how this works. This is going to be so hot you're going to need to know the fire exit, apparently, in all of these presentations. So buckle up. So event-driven architecture. I know we talk about this stuff, but we probably see this in a lot of different places. Arthur, do you drink coffee? Oh, yeah. Every day. Nice. So that's pretty much asynchronous, right? I mean, you don't stand there and wait for the barista to give you the coffee. Typically, you move away, and then they say your name probably incorrectly, and then they'll hand you the coffee later. So it's kind of event-driven based on them calling your name. Processing alone, you know, I think we own houses in the Seattle area, and you've got to go through the loan process. And that's step-by-step, right? It's a series of events. It's not one synchronous process through. We see that all the time. Customer complaints, you call up and yell at somebody, maybe Microsoft, about a weird support issue. Weird support issue. It triggers something, right? They're not constantly polling their customers, although I think they do, kind of how are things going. It's event-driven. It's based on getting some feedback. And then finally, hey, all of you, of course not now, because this is an awesome presentation, but you often check email. And that's often event-driven, right? You respond to the event. You do something with it. So we're surrounded by events in an architecture, but building a modern one usually takes a different kind of approach. So we've actually built an architecture for you. We're going to build some of this together. And it kind of uses this fictitious example of a store of coffee variety, as we're both from Seattle, that wants to do more event-driven ordering from different branch locations. We're going to be generating low, generating inventory. We're processing that database. I want us to talk about some of the technology here. And then using Pivotal Cloud Foundry in the Boston location, using Azure App Service in additional regions, because we're actually going to, in this session, add Singapore to the mix. And this is real life. We're actually adding this in these real locations, right? Yes. Nothing up your sleeves. You're wearing short sleeves. So nothing up your sleeves. This will be legit. And we're going to kind of see how you scale an event-driven architecture out in Azure. But did you want to explain some of the key tech in here, like Azure Functions and Cosmos? Sure, yeah. So when we talk about event-driven here, we are talking about serverless. So serverless, a piece of code that's triggered by any events, right? So whether it's a coffee store, or a loan processing, or customer complaints, there are plenty of events in the world, right? So the serverless, then it turns into event-driven Java. Now, imagine, imagine there is a real-time inventory hub, right? So serverless and event-driven. In this case, very often, the retailers tell us, right? They want to provision a store or provision a region where they have lots and lots of terminals, whether it's a warehouse terminal or a store terminal. They want to provision in less than five minutes or less than 10 minutes, right? How fast that they want to expand, right? So what you're looking at here is a mix of things. So let's take a focus on what's happening in Boston. The same thing is being scaled to London. And today, what we'll show you is what's happening in Boston and London. And then we're going to start deploying into Singapore and you'll see how responsive and how event-driven it is, right? So let's look at the Boston, right? So there are four key things here when you look at this picture. The first one is the data ingestion, right? It's using an event hub. It's a fully managed cloud-scale ingestion of data that's coming in. The ingestion is all about whether all the transactions are pumped in, all the notifications are pumped in right there. The second piece you see is the serverless to process real-time data. It processes the data. It stores them and also notifies, right? You can see the picture with a small strike on it, right? That's the functions, the serverless sitting there. And then the third piece is the data store, right? So the inventory data as well as the transactions, they're all stored in fully managed, no SQL, Azure, Cosmos, DB, data store. Now you can place these very close to your users, right? Particularly for all the read operations, it can be served right from the local region, that's what you see. And then you see the dashboard. Dashboard is nothing but a springboard app that talks to a Cosmos DB and listens to events that are coming in. Now as Richard said, in one region, we deploy to Pivotal Cloud Foundry. In other regions, we are deploying to Azure App Service, right? So just before this meeting, like a session about five minutes, 10 minutes ago, we provisioned some of the resources, which took us about, for Singapore, which took us about less than eight or nine minutes about, it took to provision. So now what we're gonna do here is we're gonna live, start deploying some of these terminals, like shop to store terminals into Singapore. Now before we, maybe we should show the existing, existing events how they're coming in, right? Yeah, you can call. So we can show what's existing and then once we finish the demo, kind of wrap with some of the key architectural principles of EDA, event-driven architecture, what spring does, what Azure does, and also kind of undersold Cosmos, which does some pretty remarkable stuff. We showed replication there, but being able to say, here's a master and let's go ahead and copy different nodes to other regions is literally an API caller checking something on the map. And you get multi-readmasters, you get read replicas. It's really neat tech for actually global replication. Sure. So you can see the dashboard where you can see the Boston stores. You can see the inventory of products and how many are there and the events are coming in. We built two pages just to show one is actually, the one on the left-hand side is WebSocket push and one on the right-hand side is HTML page refresh that's pulling in data, right? So here you can see how Boston and London are happening. Now before we deploy, let's start the deployment and then I'll show the code, right? So because deployment takes a couple of minutes as well. Let's do it. So let's start with Singapore. So here we are, so where am I? I'm right here, so let me go here. And what are you deploying to Singapore here? Yeah, I'm going to deploy the point of inventory first. So functions. Functions, yeah. Deploying functions, using Java code? Using Java code, right? This is a Java track I'm just trying to make and have you back there. Yeah, there you go. With that stuff, you go next door. This is Java's house. All right, we have a bunch of environment variables that we need to set, so setting that. Great, now as your function behaves just like what you would expect from a function platform, right? This is triggered based on data changes, storage changes, HTTP calls, actually comes with the HTTP part built in so you don't have to add a gateway or anything to that. These are functions that spin up on demand when you're not using them. You don't get charged anything. They don't do anything. It scales back down to zero. So pretty nice platform multi-language, including Java, which is pretty unique. Right, so I'm going to start a deployment. I'm going to use a Maven plugin to package and then start deploying to Singapore, right? It's all the way to Singapore, right? So we're going to start here. It'll start while it starts and starts deploying here. Let's start looking at the code as well, right? So here is, so here are the functions. Zoom in one level. One more level? We can do that. Visual Studio Code. Yeah, it's Visual Studio Code. You know, developers tell us that they love this idea editor as well because it's super fast and it's lightweight and it's very responsive as well. A multi-platform. Multi-platform as well, yeah. So we have a bunch of functions. You saw all of these in the diagram. So here is the update inventory, right? Where it receives a trigger from Event Hub and also receives a documented Cosmos DB input and then it processes and then puts it back into the output here. So there's a bunch of code here that satisfies this contract described right here, right? So we can also take a look at the point of transaction. So the point of transaction code is also a time trigger that pumps in code into the Cosmos DB Event Hub in this case, okay? So let's take a look at the, it's deploying. It's very close to deploying at this point. All right, and these functions are simulating usage, right? The timing triggers. Yeah, these time triggers are simulating your point of sale or your point of intake in a warehouse. So when a customer is actually screening, scanning, when a salesman is scanning all the purchases, those are the things that are happening here. Which is gonna be helpful when you're trying to simulate your own sort of load testing or testing from different locations, deploy functions in whatever your 50 regions around the world, you could actually do that as well. All right, so the first deployment happened. This is the intake. The next one we're gonna deploy a sales terminal, right? So let me go here. Let me set up some more. You're replicating the functions of course in each region, right? Each one kind of stamps out the same architecture over and over again, which is nice for scaling an adventure of an architecture. Each environment's not a snowflake. Let me just check. I deploy POS or PR. Show of hands of who's doing serverless stuff now. Some functions, yeah, the few, the brave, okay. One more time, all right? There we go. We start the deployment one more time. Nice, this is point of sale. This is the point of sale. So it'll start pumping in events as soon as that arrives. So we already deployed the point of inventory, right? So let's take a look at if there are changes in the dashboard at this point. We're waiting. Nice, we expect to see a new column show up here. Yes. You can see the Boston and London events coming in. So we're waiting for Singapore to kick in. And we're waiting to see that that we wanna show the Azure portal as well, the magic you're creating. Sure, yeah. So let's go. So here's the pivotal where we have deployed the dashboard. Let me also go into the portal here. Portal Azure. You're doing plenty of it programmatically, but obviously people like me who like to click buttons can come to the portal. And so we could see your event hub here. We could see Cosmos. We could see functions. Manage it all here as well, right? I mean, deployment you're doing from the command line, but all the management scaling is gonna happen from here, read replicas. You must have a big Azure bill every month. Yeah, all of these are here. So let's take a look at what's happening in the Boston area, right? So here's the Boston area. If I were to just get the functions alone. And you're not creating a new Cosmos, you're just using the replica. Yes, it's only the replica at this point. So these are the logic for the inventory processing as well as some of the point of sale and for the inventory devices running right here in Boston. Now, as Richard said, Cosmos DB, there's one instance that's available globally. You can take it anywhere you wanna go. Today, Azure supports it in 50 regions and the number of regions are growing as we speak, yeah. So, oh, I see the Singapore events are coming in, right there, Singapore is clear, right here. There you go, it started, Singapore started. Singapore is live, all right. Singapore is live now. You can see Singapore, it's arriving, yeah. So you saw a third column show up. It's responding to all the events that are now arriving directly from Singapore. So you can keep on adding regions like this. You can start provisioning more stores, you can expand to more regions. It's just limitless at that point. Good, so we go talk about the venture of an architecture of it? Sure, yeah. So what you saw there was hopefully life changing, something that you're all gonna go back and tell your families about, but what were some of those key components that we saw in an venture of an architecture? First, I think we saw decoupling, right? You could deploy these things as monoliths in each kind of piece that talks to the database. It wouldn't have to be four different functions, but in this case, we could scale those functions independently. We could do all sorts of interesting things when you have single purpose components. Is there things you see from that? I mean, that's kind of those key criteria. Anything special there you'd want to point out besides the decoupling? It's the single purpose, like each of those function focuses on one thing and you can scale it, right? It has its own life cycle. It has its own contact. As long as you satisfy that contact, you can keep on scaling up, scaling down depending on your needs, yeah. Right. You know, the other thing we saw is trigger-friendly systems. It's hard to do an venture of an architecture if things don't emit events. Maybe that seems blindingly obvious, but sometimes it's tricky with legacy systems. You either have to figure out how do you maybe simulate that with polling, things like that, but it's helpful when something like Azure Functions actually has built-in triggers for things like storage, data services, HTTP messaging, event hubs. It's nice. I mean, any system you want to turn into event-driven, how are you helping it emit events in some case? Sure, yeah, even customers always, developers always ask us about what about user-generated events, right? So you can always generate and start pumping into an event hub. At that point, it's scalable. Then the serverless can start responding to those events that are being ingested into it. Right. You know, next up to that scalable infrastructure, the whole point is if I'm trying to do event-driven architectures, in many cases, it's unpredictable usage. So do I have something that if it takes an hour to scale it, it's kind of difficult to be super event-driven. So how am I thinking about infrastructure that scales both in and out fairly quickly there? At the same time, making sure that you have some of the stateless and streaming event handlers. How am I processing event streams? That's what's exciting in the Azure Event Hubs or Kafka or these other tools. How am I taking data, processing it in real time, not waiting for analytics later, right? We're not going to the store at the end of every day looking at sales. We're looking at sales real time. We're processing event streams and making decisions and stocking inventory, not after a crisis happened. We actually know in real time. So finding a platform that gives you some sort of streaming support is going to be important. Yeah, an inflexible storage. Not all of this belongs in the relational database. I mean, Cosmos is, I guess we don't say no SQL anymore, right? It's a schema-less. It's schema-less, yeah. It's fine. So the idea that I do have a flexible event structure that I can stick in there, if we change the event structure, if Singapore stores different data, theoretically, than US, you could tolerate that, right? That the database doesn't break. But some people also do event sourcing with relational databases. So there's a mix. You want blob storage, potentially for logs and like. You want some sort of repository for storing raw events in many cases, and then further analytics. So looking for storage options is going to be important. And then some sort of extensibility, because we're showing something here where we're adding a lot of components. How easy is it to extend these architectures? An event-driven architecture that's rigid kind of defeats the purpose there. So tell me a little bit, after you talk about observability, we'll talk about Azure. But the hardest part with some of these architectures is can you retrace what just happened? As I have a series of triggers, of functions, I have a series of events and streaming processors, if someone said what happened yesterday, how are you piecing together a bunch of functions that lived for two seconds, a bunch of things that scaled in and out, and an event stream? That is not trivial. That's not a super solved problem at the moment. So how are you gonna actually do traceability to survive an audit, or to do some of these other things? That is important. So what's Azure do for me? So Azure, so you saw the event stream, you saw the storage, and you saw the serverless. What Azure offers here is a fully managed, a fully managed event hub, where you can start streaming data. That's number one. And it's also a fully managed Cosmos DB. You do not have to worry about replication. You do not have to worry about any management, anything there, everything is taken care of for you for the Cosmos DB. And the third one you saw there is the functions, right? So Azure offers a fully managed serverless computer on time. You deploy it, it'll be triggered, and it can be done concurrently, and it can scale to meet the needs of how we are triggering it, right? Now, in addition to being all these managed, right, you saw that complex contract that we had for the update inventory. How do you test that, right? So in addition to offering a fully managed serverless compute runtime, we ship the same runtime as a DevTool for you. So you can locally set it up, you can locally run it, you can attach your debugger, whether it's IntelliJ Eclipse or VS Code, tooling of choice, and then you can start stepping through the code, right? So you know that it works before you actually deploy it to Azure. I think Cosmos has a local clone as well, doesn't it, for a local Dev environment? It has an emulator that you can use that as well, right? Just tough with cloud development, sometimes your local Dev experience feels weird, it's hard to replicate what's in the cloud. So it's nice the function runtime that you can run locally, that's pretty good. You can completely run locally, the same contract that you saw, that contract can be registered locally so the events will start pumping into your Devbox, and then you can step through your code to see exactly what is happening. So it's no, you don't have to wait until you deploy on Azure, and then see what's happening there. You can see it on your machine, it runs, and then you can go to the cloud. The global instance scale, so Azure offers global and instance scale. Today Azure is supported in 50 regions, and the regions are growing. We just deployed to Singapore, if you were to go to, let's say another country, pick Australia, right? It's just a matter of time, right? 15 minutes you'll be up, right? Or you take Hong Kong, you want to open stores in Hong Kong. 15 minutes, it's all provision, everything is up and running from the cloud point of view. You still have to set up a store in Hong Kong, but that'll take longer than the cloud provisioning here. And Microsoft did just add availability zones last week, I think it's generally available, so there's multiple physical facilities in a region. Yes. It's robust, right? Robust functions. So you saw how we deployed, right? So we can keep on deploying. When contract changes, of course the things will also change, and it's robust enough to handle things like that. The high throughput and the reliable here. So you saw Cosmos DB, right? Cosmos DB, it supports elastically scalable throughput. You just have to say what is your ceiling limit that you want. So it starts scaling up to that point. Now, you also saw the event hub. Events hubs are suitable for hyperscale ingestion of data. So whether it's telemetry, whether it's transaction, or events that are happening around the world, all of those can be pumped into event hubs. So the limitless data storage, right? So Cosmos DB, it supports elastically scalable storage. It's up to you how much you want. You can keep on increasing. Sky's the limit there. Practically, I would say it's limitless. First is relational database. I think Azure SQL caps out. What, it's a few gigs still out there. Maybe it's a couple terabytes at the most. It is. They've increased. I don't know the current number, but certainly it's different from Cosmos. Cosmos is huge. It's up to you. You limit your costs, right? And you don't charge me as it gets bigger. Yes. No, of course you do. Not giving away storage. That's crazy. So security is across the board, right? Specifically for Cosmos DB, all the data is encrypted at rest also in motion, right? So it's completely all of them. And some of the developers ask us that they want everything inside a virtual network that's not accessible from the internet. So that is also supported for all the data options now, virtual network, so that it's even more secure than exposing it to the internet here. Good. So some of the ways Cloud Foundry kind of supports this sort of architecture together is all the Spring libraries. We showed a little bit of Spring here and some of the boot apps, but Spring Reactive now, Spring Cloud Stream. We're gonna have some cool things along the way for Spring Cloud Stream and Event Hubs on the way. So if you're building these sort of event-driven apps, you're also looking for the libraries and frameworks to make it a little simpler. So Spring and Cloud Foundry and Java make this a bit simpler. At the same time, of course, if you're running Cloud Foundry on Azure and we won Microsoft's Consumption Partner of the Year last year, so we know that a lot of Cloud Foundry runs on Azure. That means that's great, right? That you want a platform on top sometimes of platforms to help with your dev life cycle, owning infrastructure, and the like. So if I wanna deploy Cloud Foundry, a lot of good scale, which is what I demand from an event-driven architecture. I have to scale in and out. The key also is the different types of apps. In an event-driven architecture, you're gonna do some batch processing. You might do a nightly sync between all the events that came in. Maybe they got stored and you're actually gonna make sure you didn't lose everything so you synchronize nightly via batch. You're also gonna do streaming apps, web apps, function apps coming up shortly with Spring Cloud Function and Pivotal Function Service. So a lot of good things coming in the container space and in the Cloud Foundry space for events. And then finally, putting this anywhere, right? Azure's great stuff in 50 locations. I think there's many, many more as you have your on-premises locations as well. So as I think about trying to run an event-driven architecture the same anywhere, I'm probably doing a mix of things on-prem, off-prem, different providers, co-location, whatever that makes sense. It's nice if you can stamp out the same event-driven architecture, regardless of your infrastructure pool, as much as Azure's a great place to run. So I'll do a quick plug. You'll see us hopefully on stage next at Spring One in Washington, DC, as we continue to talk about Spring. But what else can we, questions we can answer about the venture of an architecture in Azure? How can we, are there tools that you've looked at or you're interested in or wanna see how these work together? If this is a, we're gonna take this buddy comedy on the road, what do you wanna know about? Yeah, so question is how do you guarantee the order of events in the venture of an architecture? Sometimes you don't. And it depends on if you have the mysterious only once delivery, which is somewhat mythical, this idea of can you really guarantee things? Don't get backed up and read deliverance. Is your whole architecture actually participate in that sort of flow and transaction? So sometimes you go for item potent systems where I can technically do things out of order and I don't have a negative side effect on the systems. You know, when you do do a right ahead, you know, a right log, like event hubs, like Kafka, things like that, you are guaranteed that if they get written in a certain order, they will get read in a certain order. You're not dealing with message cues and things where you can technically lose it. But it still seems like the semantics are perfect for guaranteeing order, but the right log sort of model versus a message broker seems like you get higher guarantees. I don't know your thoughts. I think you covered most of it, yeah. I think so, yeah. All right, good, other questions? Good, well, if not, we'll be here for the shy people if you have other questions, we'll stay up here. Azure is good stuff for venture of an architecture. Cloud Foundry helps you a ton with the venture of an architecture. Well, I'm really excited what Spring does with reactive and streaming that actually makes these apps easier because this is a tricky architecture. I mean, as much as we really like building this and frankly, Oster did all the work, so I use we generously, is this is gonna be a complicated architecture. If you look at it, it's just easier to build one app that does intake processing and one data store and that's kind of it. That's not awful, but as I try to scale, as I try to scale individual components, as I wanna update these things in pieces, you do wanna decompose this into a set of services. So the complexity sometimes is higher, but the payoff is greater. And those are real trade-offs. Sometimes this is overkill, sometimes this is what you need. I'm glad the frameworks and tools make this easier, but please don't over-engineer if you can help it. Thank you for the talk. Thank you. Thank you everybody. Thank you.