 Hello, everyone. Welcome. I'm going to be talking about a really nice big meaty topic, which you could actually spend an entire two-day conference like this unpacking. So I started pulling this together thinking, like, oh, yeah, I can totally do like a 30-minute talk about data-driven IoT apps on Cloud Foundry totes, which is Californian for totally. And as I started pulling together, I rapidly arrived at like 50 slides for 30 minutes. So we cut some down. By the way, my name is Dormaine Dreowitz. I work at Pivotal. You can find me on the Twitter's. My handle was there. But now it's gone. So the agenda of what we're going to walk through, talk a little bit about event-driven architectures, because I think that that's kind of relevant for IoT things. But there's a good compare and contrast I think that needs to happen, because it's not that request response architectures aren't still useful. We'll talk a little bit about streaming data integration, specifically highlighting a microservices approach. So I'm sure a lot of folks here, I'm not going to upset anyone's shoulder injuries and ask the question. I'm going to sort of assume everyone here is kind of into the concepts of microservices and why they're a good idea and useful. Of course, that there are challenges and trade-offs and work that go into them. I'm not going to rehash all that. There's lots of great talks here that go into that in better detail. Then where's the cash? It's a little bit of a play on words. Like where's the catch? Talk a little bit about more integration, because there's like other types of integration that are super relevant here. And then I've got a few resources. Some things that are not in scope for this talk, because I couldn't sprawl infinitely. Things like security, monitoring. For example, there's actually, I was just learning recently, GE apparently is using the UAA capability in Cloud Foundry for their device authentication. Super interesting. Couldn't fit it into this one, so I have to sort of just point you to finding that particular resource. And there's other obviously important security topics. Monitoring, also always important. Again, I'm not really going to go there. So just to kind of get started. So the backdrop of this is really like, I think Cloud Foundry is a really useful platform for building IoT apps. There's also this sort of emergence of the notion of an IoT platform and a lot of IoT solutions. So I came across this projection forecast. I'm not sure exactly what the word Gartner uses. But they sort of said, okay, within five years, 70% of the software capabilities required for an IoT solution are going to be just part of standard cloud stacks. And that's up from less than 20% today. So basically in the next five years, we're going to see this huge shift where a lot of IoT capabilities are just going to get baked into more horizontal, general purpose cloud platforms. I think Cloud Foundry stands to benefit from some of that. And already support some of these things today. So I guess what we're maybe talking about is that that less than 20% slice. There's also a corresponding prediction, which is about pure play IoT solutions, certain percentage of those going away within the same five-year period. So let's talk a little bit about event-driven architectures. This is something that I've been kind of trying to wrap my own head around as opposed to request response architectures. Definitely important for IoT. And the way that I kind of rationalized this to myself was to think about it in terms of, you know, connected devices are really like reality TV celebrities. They're like popping up like crazy. And so, you know, I don't think Gartner does predictions on or IDC or Forrester, not to like play favorites with anyone. Predictions on, you know, what, how many reality TV celebs are going to exist in five years? They'd like to do that with the number of connected devices. But it's essentially like the same thing. And they're very, there's all these events that are like happening to them, right? So Macy, the teen mom, I don't know, does anyone here watch teen moms? Oh, let's see those shoulder injuries. They're kicking in. So she's back with Ryan. Oh my gosh, that just happened to her. Apparently I care. I don't know. But nonetheless, there's all these events that are happening out there to these things, just like all these reality TV people. And we sort of find out about them. I think it's kind of interesting that there's a lot of different cadences in which we sort of find out and that like different levels of detail. So, you know, I might see something come across Twitter. You know, like daily, it's like, oh, come on, really, it's like hourly. But but there's a really tiny snippet. So I might just get the headline of like, you know, Macy's back with Ryan. I don't know who these people are. And then on a weekly basis, you know, we might be going through the shopping cart line. And at least in the US, there's all the sort of celebrity magazines are right there on the checkout counter. And, you know, you have a little bit more time to read the headline and then maybe like the little blur below it, absorb a little bit more information about what's happening. And then there's maybe annually, when I'm sitting at the doctor's office or the dentist office, which I go to the dentist twice a year. Thank you very much. You know, then I'm actually maybe sitting there waiting and I might flip through and read actual paragraphs in, you know, in the US, we have People Magazine. I was like, I've got to tailor this for like a European audience. But it's really hard to do research on foreign language magazines and reality TV stars. So I ended up just defaulting to the UK because I speak English. So okay, magazine is apparently like the equivalent of People Magazine in the UK. So another way I think of thinking about this is, okay, maybe this is a better, more accessible example is your like a soccer team, right? When they play a game, that's just happening, right? And we tune into it when it's happening. But then there's like, Oh, maybe I want to choose something. And it's really about me and what I want to watch. And that's a little bit more of the experience where, okay, you're on, say, Netflix, and you're picking what you're going to watch that day. So I think this is interesting, because I think actually both of these scenarios are important and relevant when dealing with connected devices. The devices are out there and events are happening. And there's going to be just, you know, a stream where you can just tune in at any point of what's happening to these devices. And that's useful for certain things. But there's also going to be a mode where it's like, now I care about it. Now I want to find out what's going on. Or I want to, you know, interact with this device. And that's where a request response model is going to be really important. So anyways, one of them, one situation is about them. And one situation is kind of about you is another way to think about it. We don't have to go too far with this analogy, because it will start to break down. All good analogies break down at some point. It's just a fact of life. So instead, I've decided to take my like lightweight super high level architecture as the Internet of Macy in honor of the fact that, you know, stuff is just happening to Macy, maybe without her control either. I don't know. It's tough to be a teen these days. And so this is sort of the backdrop of our event driven architecture, which is then feeding into applications. So let's kind of think through and walk through some elements of the Internet of Macy. And we'll start with this kind of big chunk in the middle. And because this is where a lot of the data integration happens. Now I'll pause to you. And I was just having a conversation with my colleague Duncan about this. And what so I felt like I really should acknowledge a lot of a bit like processing of data is actually moving further and further towards the edge. And so back here, we have those IoT gateways and edge platforms. And so to some degree, there's a whole interesting thread to pull on around how you're doing the processing and some of that data integration closer to the devices closer to Macy, really, we're going to be talking about once it kind of hits a more central cloud platform. So there's taking a microservices approach to a streaming data integration pipeline. This is really part of just a broader picture that's coming together for a lot of organizations around just digital business. And so that's the umbrella. This is not unique to IoT is my point here. But the benefits that you can extract from this with continuous data integration and event driven processing, you know, they do apply to IoT, they also apply to some other things. That's kind of the main point of this slide. But you've got that lower latency decision making. You want to be able to incorporate multiple data sources. So not just what's happening to Macy, but you might want to, you know, get weather data, because that might be affecting what Macy is wearing that day, because that's going to end up on Twitter. And then you also need to continuously train those models. So that's something to factor in, where it's like, maybe that's not actually happening on a streaming cadence. That's happening on a batch cadence, right? Sort of like the depth of information you might want to be getting at a different time that might have implications. So and then there's another interesting idea where really being able to do this well is sort of a prerequisite for serverless and function as a service, regardless of the use case, whether it's the Internet of Macy or not. Just being able to have a grasp of, you know, building an efficient event driven architecture and how a moving towards a microservice model for that is going to really set you up to then start to take advantage of serverless and function as a service. So one of the tools I wanted to introduce for folks, if they haven't heard about it, for this, and which runs on cloud boundary, is Spring Cloud Dataflow. So this is a microservices based data pipeline tool. You can orchestrate both streaming and batch cadences of data processing. And it being part of the sort of spring family, it actually makes use of each of these stages as spring boot applications, right? So each one of those steps in the process, you know, I'm going to ingest data from here. I'm going to ingest data from all these different sources because it's not just about Macy. It's about, you know, all these other things that might be relevant to understanding what's going on with Macy's world. But then I'm going to have to parse and filter and enrich that data. Each one of those processing steps, again, an individual service, perhaps a spring boot service if you're using Spring Cloud Dataflow. And you get a number of developer benefits from this. When you start to lay that pipeline of spring boot apps on top of Cloud Foundry. So you're now getting that unified model for handling both my streaming and my batch processing that I have to do, as well as, you know, all the benefits of being able to continuously integrate, continuously deploy those individual application, right? So you're decoupling that entire pipeline. So, and then some operator benefits that you're, if you're familiar with Cloud Foundry, this is just like any other application running on Cloud Foundry that you now get the benefit of. But you're actually supporting this data pipeline. And it's a messaging driven pipeline. You can actually bind these different services using a number of different messaging based services or vent log services. So whether it's Kafka or RabbitMQ or Solis or some other messaging architecture, because that's going to be really important as you need to support this as an event stream as opposed to a request response mode. So an example, this was a customer who presented a little while ago, CoreLogic in the U.S., they are a major player in the mortgage industry, but kind of a lot behind the scenes. So they were processing a lot of data and they started using Spring Cloud Dataflow. And what they described it as is building this on-demand data manufacturing. In this case, it wasn't for a connected device. But the model, the architecture is totally applicable to a stream of events coming in from, you know, the Macy's of the world, connected devices, as opposed to just people applying for mortgages or something, and those kinds of events off of a web-based application. Now, of course, the difference is, you know, there's going to be that edge tier gateways and edge platforms between those connected devices, the Macy's, and the pipeline that you see here. Now, the other thing I wanted to highlight is that that place where, you know, we're going to actually send some of this data down. You can tap these different streams at different points. Maybe after you've enriched that data, that becomes a good point to store it, persist it into a data warehouse so that you can then run those deeper, long, you know, timeline analytics against it. As you train those models, having a way to push that output, whatever the freshest model is, back in front of the pipeline of data, so you're constantly scoring against an updated model. That's really useful in terms of the need to continuously train models for doing whatever, if it's predictive maintenance for a connected device. You want to have the freshest models. One other thing to point out here is that variety of data sources, things like data coming in from a, you know, a support tool, right? And that might even be like a hosted support tool, SaaS based. And that's where all of your data from customers reporting incidents is coming in. You want to be able to marry that somewhere, do analytics, so that you can understand perhaps where you can start to predict where support incidents are coming from. So that's an important step that's in many ways happening as like an offline process to the rest of the stream. And so having a way to integrate the two I think is really useful. Now I promised a little bit of kind of hinting at where this then takes you for functions as a service and serverless. And this is the diagram from a recent post by Kenny Bustani, as one of our spring developer advocates. And here he sort of, he lays out this concept of the service core, where you have a long running service and here in this case it's a spring boot app. And then there are short running processes that in this case he's using Amazon's Lambda service to then fire off those different processes. In this case, one of them is a state machine function, another one is a, I can't remember the name of the other one, but there's a metrics function. And so you can imagine laying that on top of one of these stream, a spring cloud data flow processes. I think that that could start to get really interesting. The other thing is, oh, I'm going to blank on it. Oh, he's promised at the end of this, by the way, the blog post has some great pointers to sample code and sample demo app that you can play around with. He's hinted at the next stage of this is actually going to be running all this on Cloud Foundry. So that's one reason why I bring it up here to this audience is I really think this is a watch this space kind of place that is very relevant to building these IoT apps. I think it's a little early. There's not a ton there, but if you're super interested in this, I would watch this space. So now let's dive a little bit into kind of where we've sort of done that stream processing, some amount of batch processing to train those models, but now it's going to surface up in an app because at the end of the day there's often a user on the other side of this connected device and they're using an app. Increasingly it's some kind of mobile app or even for technicians in the field for in an industrial IoT situation, they're working off of a tablet device and what have you. So there's going to be an app at the other side of it. That app, again to kind of come back to, we're all on the same page here for microservices, I'm not going to rehash all that. Let's assume that we are building that application in a microservices architecture as well. What's the what's the role of a cache in supporting that? So this is, I'm going to basically give you an abridged version of the top Cornelia Davis and I did at the Cloud Foundry Summit in June, so that's all recorded. I've got the link as one of the resources, but when you think from the, you're coming in now from the app perspective, having a bunch of microservices talking to the same database, especially if that database is also supposed to be supporting a legacy monolith is definitely an anti-pattern. You're not getting a lot of the benefits of microservices that you would hope for when you're essentially still tied at the database level. So your ability to iterate is constricted, that's no longer something you can do independently. Your tech stack is sort of pre-decided for you because you've got the same shared database and of course you're going to have some performance and scaling challenges if you want to continue to grow that new service that's supporting whatever other end of that IoT user. So this is where Cornelia's introduced this, at least from my perspective, she's introduced it, the data API and so this kind of being this isolation layer between perhaps a legacy database, some kind of shared database that exists that you have useful information you're trying to get from and your emerging microservices architecture and this providing this, as she describes it, a surface area to implement that access control, perform a lot of different functions in order to be able to support those microservices better. Now, okay, how does this data API layer help resolve those performance challenges, resilience challenges, the ability to choose your own stack and even some other changes that come up a lot when you're trying to iterate independently, like your schema versioning. This is where a cache associated with that data API becomes interesting. So this notion of every microservice needs a cache, right, that's kind of a bold statement, right, whenever you put every in front of something, things get serious. So if you look at some of the architectures proposed and introduced and sort of exposed by Netflix, again, the URL there is from a talk from Scott Mansfield where he articulates the cache as this hidden microservice that's really supporting this massive, highly resilient microservices application, right, the architecture that they have at Netflix. And this slide screenshot is from Adrian Cockroft during his time at Battery Ventures. And if you look into it, you see how every piece has this cache to support each service. So again, this is the abridged version, but essentially we've addressed performance, you can with this caching layer associated with the data API address performance issues by using an in-memory technology at that point, especially if you can have a horizontally scalable, clustered in-memory technology so that performance isn't just hindered to obviously a single node. Resilience, it's providing this bulkhead for the rest of the application. You can start to use a different, as you kind of now writing data through to a different database, you can select an appropriate database for that workload. So if it's a NoSQL database versus that the legacy one, which is kind of, oops, it's on this side, kind of looming as like the Death Star that's kind of fading in the corner here, which is most likely a relational database, great for a lot of use cases, not always for everything. And that's also another post by Kenny Bistani talking about the strangler pattern, which I highly recommend for making those kinds of transitions. And then of course schema versioning is another really interesting thing you can do here, where two versions of that data API you can now start to make those changes in a more graceful way without having to disrupt all the applications that might be using it. Okay, so the last area I want to touch on is that, okay, we've talked about some of the, at least the cloud based components of this data pipeline and doing that in a way that's, you know, making use of a microservices architecture, getting all those benefits, the data caching layer. But if you zoom out, there's also all these other applications in the mix that we have to think about integration with. And I kind of alluded to this when I was going through the spring cloud data flow section where, you know, you might be wanting to pull in from some kind of your support desk tool. So if we zoom out, we do have the things, right, and we have the IOT apps, right, which was this is the new stuff that has to get built to support, you know, that technician in the field that's now equipped to do more predictive maintenance as opposed to just preventative maintenance. And, but you also have business systems on both sides of that, that are going to need to integrate with a lot of the data pipelining work that you've done in the middle. So how do you do that? So one thing to consider here is that you have different types of integration that you're going to be supporting. And so, you know, not just these connected device data streams, you've got app to app integration, you've got different cloud services, right? So when you don't you don't control all of the apps. So it's really nice to sometimes think that well, I can build a spring integration app for that and build everything I want there. But you know, maybe there needs to be something deployed in that SAS vendor. How can you do that? And then of course you've got mobile app integration on the sort of IoT app facing side, which has some unique requirements in terms of certainly the network latency and a lot of those functions in terms of the limited bandwidth and the limited, you know, number of calls that you want to be having that mobile app client make to the back end service. And then you also have different types of developers. So again, it's nice to sort of maybe think like, OK, our Java developers, they can they can build all of this. But as this starts to grow and touch more parts of the organization, there are teams of integration specialists who are basically sitting in control of the integrations with some of those business systems. And so you want to be able to engage with them too and show them that they're supported on this journey, if you will. And so you have some different users to think about and you have some different application integration types. OK, so let's bring it all together. We're coming into the home stretch here. And now I've kind of cleaned up my still very high level diagram and, you know, the the ability to bring in data from your other sources, including some of those kind of standard cloud services, I think that's where the iPads integration piece becomes really useful. Your standard data ingest, which is definitely part of the Spring Cloud Dataflow piece of the solution. And then again, being able to have your API gateway to sort of mask a lot of this complexity for all the other apps that maybe wanting to build that's making use of whatever's going on with Macy, because I mean, let's face it, everyone wants to know what's happening about Macy at this point. And again, you might still have another like side of the iPads equation to go back out to some of these externally run services. And OK, ignore the little gear wheel. I totally forgot to delete that. I was I can't remember where I was going to put that, but just ignore it. So the blue box sort of is the rough lines around a lot of the stuff in this blue box can run on Cloud Foundry, right? And by the way, we've definitely dropped the Edge Gateway platform from this side. But that's a big area in that blue box that you can build on Cloud Foundry that brings a lot of utility and value. And by the way, a ton of those pieces are making use of microservices architecture, helping bring those benefits. Other ones might be kind of coming in more with a service broker or mostly a service broker to to sort of add some of these other pieces of functionality. Now, it doesn't mean that the pieces below the blue box can't run on it or don't in certain scenarios today. So when I start to overlay some of the available pieces on this, then you again, I kind of decided to blur the lines because there are some pieces below the previous blue box line that are relevant here. But certainly, again, I work at Pivotal. I work with our ISV partners and our internal developers who build services for Pivotal Cloud Foundry. So a lot of these are also relevant to just general Cloud Foundry. I'm just bringing in personal experience from the Pivotal side here. iPads vendors like MuleSoft and Dell Boomi are available to solve that piece, highlighting Spring Cloud Dataflow and Spring Boot for those data pipelines, both streaming and batch. A range of caching solutions, I always give a special shout out to Pivotal Cloud Cache, which is based on the Apache Geode in-memory data grid technology, which is particularly powerful from a horizontal scaling perspective. And then again, MuleSoft but also Apigee from that API gateway layer, there's a number of integrations that those vendors have built with Pivotal Cloud Foundry to be able to support that piece. Then I call out Kafka for the event log piece because I think that there's a lot of utility in the event log in this scenario where you're trying to you have potentially lots of different subscribers to this data. You can, as I mentioned, use RabbitMQ in Solus for the messaging infrastructure that supports Spring Cloud Dataflow. And I do think that they might be particularly relevant, particularly when you start to reaching out more to those edge pieces because of some of the protocol requirements there. And so message brokers have a piece in there. So that's why I've kind of illustrated with this like slash mark because you can kind of use it over here. But I really think there's actually a role for both of these. They're slightly different. And then for data warehousing, of course, we have Pivotal Green Plum, which is based on open source Green Plum database. You can also use Cassandra for some of these types of things. Green Plum is SQL based, so there's a lot of SQL based machine learning that you can run in parallel on Green Plum, which is great for churning out models for more predictive whatever with your Macy's. And then to kind of pull it back and bring in another sort of example from a customer. This one was from Cardinal Health. So they actually presented about a year ago at the US based Cloud Foundry Summit. And so here they were building sort of a personal health care IoT solution. And so again, you can see how there's a number of these components have fit into their architecture. There's some additional pieces. They have the drawing kind of oriented a slightly different way than me. But that's like, that's what happens. You get 10 people to draw an architecture. You're going to get 20 different versions. So anyways, just to sort of illustrate that there are folks that are kind of building along these lines. I promised a bunch of resources. So there's the two posts from Kenny Bistani, both of which point to sample code and demo that you can play around with yourself, one around the strangler pattern and one around the services core for how to then integrate functions as a service using Amazon Lambda. A whole book that Cornelia is writing on cloud native patterns. And so the first several chapters are available today. If you find her here at the conference, you might be able to get a discount code on the whole book. That talk by Scott Mansfield on Netflix and the caching service, the hidden service, which I realized like hidden service makes way more sense than secret service, because that's something else. And then Jim Schengler from Cardinal Health, his talk, I've got links to the slides there. Then a couple other ones, a webinar we did a little while ago on the continuous data integration and the talk that we did. Cornelia and I did at the last summit. So I'll post these. But there's just one more thing I want to give you guys. And that's the discount code to Spring One Platform. If you want to come all the way to San Francisco in December, I'll be there. I look forward to meeting and talking with you. So with that, I know I kind of just went a minute over, but I think we just did 34 slides in 30 minutes. So give yourself a round of applause. So enjoy the beer o'clock or the Kina beer for fear experience upstairs. I'll be here for a little bit to answer any questions. Thank you.