 Okay, it might as well get started. Can everybody hear me okay? That sounds pretty loud from here, so I bet it's loud over there too. Well, thank you all for sticking it out on this Wednesday afternoon. I know it's been a long, long week. Pretty exciting stuff all around. I'd like to kind of try to take a different perspective than probably what we've seen a lot of from this week. What it's like to actually be an ISV in this ecosystem, this very platform-centric ecosystem. We are a member company, but I still feel like we're a bit of an outsider kind of coming in. So I wanted to share some of our experiences, some of our thoughts about how this ecosystem is forming, and various ways that we can all kind of collaborate. So to get a quick pulse on the room, raise your hand if you're from a member company already. Anybody? Okay, and out of those who has a distribution provider. Okay, excellent. And then any fellow ISVs in the room? Okay, and then anybody here, not a member company, but who wants to become a member? Ooh, okay. Well, we'll have to do some convincing then. So my name is Ivan Dwyer. I'm from a company called Iron IO, and we joined, we built our own development platform for kind of building these highly scalable, event-driven, now called serverless applications, and we built that independently. But we've had strong links to the entire Cloud Foundry ecosystem for a long time through a variety of partnerships. So we actually formally joined the foundation back in October of last year, just in time for the Berlin Summit. And I've really continued to kind of participate and work with the various members of this ecosystem. So that's really what I wanted to focus on today. And ecosystem is such an important topic around any open source community, sometimes even more so than the actual technology itself. And I really believe that what Cloud Foundry is doing in this regard is very unique, but also very, very impressive. Now I think we can all kind of grasp very easily what a single open source ecosystem is like and how the various players interact from the vendors to the end users and everybody in between. The successful ones kind of move forward and continue to grow through this continuous feedback loop. And that's how it really kind of stays progressing is everybody's kind of in line, there's good governance, everybody kind of collaborates and works in a mutually beneficial productive way. But this is really, really hard to do on its own. And I'm sure if any of us have been in this IT ecosystem long enough, we've been in the wrong end of an open source ecosystem before. If you wanna hear my story, ask me about the Limo Foundation. I'll tell you all about it someday. So what is the ecosystem of ecosystems? And that's kind of the way that Cloud Foundry has kind of positioned itself. So what it really comes down to is is that each of the distribution providers who are building their own platforms are forming their own ecosystems. They have their own end users, their own partners, their own contributors. And they do that in an independent way. But what Cloud Foundry does is it puts the structured governance around each one of those independent ecosystems and allows them to do that kind of independent path, but do it in a way that's beneficial to everybody else in the community. And that's really a pretty unique concept. But one thing about Cloud Foundry and in this ecosystem of ecosystems, it's not a multiverse. These aren't isolated, independent ecosystems. We're all kind of communicating and we're all working together. And that's what really makes it an ecosystem of ecosystems and what the foundation has done. This is pretty impressive and they've really laid the groundwork to establish this kind of mutual path direction while allowing everybody to go about their business as we all have to do. And I made this slide before seeing any of the keynotes. So I'm very happy that I think my perspective lines up with how the foundation sees itself and it really starts with this interoperable technology platform. The ability to allow our end users to pick up and move applications and services across environments is pretty important. And then that core technology platform under the hood allows those providers building the distributions to do it in a very focused way. I mean, we see a lot of vertically specific Cloud Foundries, as GE predicts and then we see some geographically focused Cloud Foundries, like SUSCOM application cloud. And having the core foundation unified and consistent allows those companies to build their own path and their own ecosystems, but do it in a way that benefits everybody else in the entire ecosystem. And so when companies like us want to get involved we can because of this kind of extendable service broker kind of interface, which I'll get to in a bit. And of course the shared developer community. This is the one part that I probably don't have the best insight into because I'm not a contributor yet. But from what I've seen so far with Cloud Foundry is a group of highly motivated individuals alongside a group of highly motivated organizations all working towards a common goal. And that common goal and the shared interest that we all have is really to lead this digital transformation era within the modern enterprise. As vendors we do that through our solutions. But as end users we do that within our own organizations. I mean if you're an end user and you are here at this conference it's because you want to be here. You want to be part of that digital transformation process and you probably had a lot to do with it within your own organization. And why that matters? That matters because in today's incredibly fast paced highly competitive world the businesses are on the hook to deliver continuous innovation to their customers. And because every business is becoming a software company in some fashion the developers then are on the hook to deliver that continuous innovation to the business. And we need this kind of platform centric way to enable those capabilities. Because we've seen already some shake ups in some industries because this can be a vicious cycle if you don't track it properly and if you don't kind of have your finger on the pulse. I mean every one of the end users that's been on stage here recognize this in time to start this transformation process. And so that's what's leading a lot of these organizations to adopting Cloud Foundry is the entry point. And it's that entry point that forms the ecosystem and it's that entry point that builds the stack and gives companies like us a reason to be a part of it. And it starts with the distributions. And that's the first decision you'd make as an organization picking the distribution. It's based on the characteristics, the independent ecosystem and of course the company behind it. And now we want these distributions and these platforms to be capable of distributing work, distributing components across a wide range of clouds, public and private. And to have that kind of consistent platform layer that we can kind of guarantee that these workloads can be interoperable is pretty important in what's really sets Cloud Foundry apart. But then once we start, we get the foundation light, it's time to start actually building the applications and building the workloads. And this is really where I see the extendability of Cloud Foundry beginning and where companies like us kind of come into play. And the way I say it is, no two enterprise applications are alike and not all workloads are equal nor should they be treated equal. Very enterprise applications are comprised of a wide range of workloads that all have different characteristics and different behaviors and they should be ran through a lifecycle that is very specific to that workload. So we could either tell all of our customers we must build 12 factor apps only or we could start to extend the capabilities of Cloud Foundry to support other types of workloads. What's important is that all those workloads fall into the same umbrella of the core Cloud Foundry environment. And that's where companies like us start to get involved and try to give an answer to these serverless workloads. It's a very different type of workload than a 12 factor application. There are servers, I assume everybody knows that. But that's not enough. Of course as developers we wanna add to our toolkit and we wanna feed our applications with data. So we need to add services and then we need to hook up to databases. And Cloud Foundry does a really good job of enabling those capabilities and basically giving the developers an end-to-end kind of environment for running their applications. As luck would have it, there just so happens to be a best in breed provider for every one of those boxes in that reference architecture. And that's just my reference architecture. Everyone has a different view of what that looks like but this is kind of what I've come up with and landed on. And as you can see, we found a place for ourselves in this stack up there in the top right of the Cloud Native workloads. And it's because of that box in the stack and us being able to put our logo right there is really why we joined the foundation and why we're involved in this community. And we're working together with all of these companies to make sure that what we're delivering is this kind of end-to-end enterprise-grade system. But of course, there will be overlap between all of those companies in the technology, the features that we're delivering to our customers. We might run into each other into some of our sales efforts. The business models might line up. Some of us might be charging subscriptions based on the application number and then we might be monitoring that application. So that's another subscription and there's security and another subscription. There's overlap. But I think that's okay. What it really comes down to is that we're all better off as an ecosystem and the end users are better off when we kind of put all of our heads together and we find where our best fit is and who's best in breed and who can deliver what the best and deliver that as a single kind of entity. And I've always called that the Voltron stack and I'm really hoping that catches on. So if anybody's on Twitter right now and wants to do that, that would be awesome. Because we've all encountered that RFP with that line item that made us scratch our heads. Sometimes it's a full page. Sometimes it's a full section. Sometimes it's just one feature where we know we can't do it. And we could either lie and say no problem and go back to our engineering team and say we can do this, right? And then just watch them stare us down. Or we could say, all right, I'm part of this ecosystem. I know everybody, I know what they do. We're all friends, we all drink together. Why don't I call somebody up and see, hey, can you help us out with this? Can we put our heads together and figure out if we can have a shared joint solution? And we found that works obviously a lot better. And actually in the Cloud Foundry community, that's been really successful for us as a growing business. We have partners who know what we do. They have my phone number, they have my email address. They say, hey, we've got a customer, really wants to do this long running, batch job asynchronously. Would really rather have you guys do that. Can we work together and figure that out? And it works. And that's really a key driver for our involvement and what we try to bring to the table. So I hope that sets the stage. I just want to talk a little bit about what it's like being us in this world. We are a small company in context of Cloud Foundry, about 50 people in San Francisco and across the world. We have our own aspirations, our own enterprise growth. And that's a key driver for us participating in communities like this. So to get specific why we actually join Cloud Foundry Foundation is being on this growth path, we want to be aligned with leading industry movements such as Cloud Foundry. And in that process, we've been able to find customers through our participation and through our partners. And it's really enabled our growth. And it's been great and a great reason for us to be here. Of course, the technology has to line up. So the fact that we found a place on the stack for us was very important for us participating here. If there was not a place for us, it would be not worth our effort to be here. But we found that. And then we also, we have our own multi-Cloud aspirations. So being able to work alongside other interoperable platforms, other clouds is really important for our own efforts. And having Cloud Foundry as a marquee platform that we can support is really important from a technology perspective and a business perspective. And again, it comes down to this shared vision. And it's really around developer empowerment and operational abstraction. And that's how we position ourselves. And it's very much in line with how Cloud Foundry positions itself. And we believe that in combination independently or together, we do provide a value add to that digital transformation process. And so far, so good. I've been in partnerships in some form or fashion throughout the entirety of my career for across a wide range of industries. And the one thing that's always remained consistent and it sounds super obvious, but you have to have something to bring to the table if you wanna get welcomed in. If you don't have something to bring to the table in a community like this that's so established and has so many big players, you're not gonna get welcomed in. So to make it as crystal clear and obvious, I'll be very direct. And the way I usually break this down is in terms of a value add is, what do we bring? Why you should care depends on who you are, but generally speaking, why you should care. And then how we can make it actually happen. And again, I'll go back to the application workloads. We bring a new type of workload to Cloud Foundry, which is important for any enterprise deployment. When you get into production-grade applications, being able to support workloads is incredibly important. And we do that by partnering with members of this community to enable our services to the developers. Having a very clear checkbox next to some specific RFI RFP line items, might be a job scheduling API might come up. We offer that and you can check that off of that RFI. And we do that through our service broker extensions that we offer to distribution providers. And it just so happens that our services line up very nicely next to a couple of AWS services, specifically SQS and Lambda. And we found that there are a lot of enterprise organizations that want those capabilities, but they want it in another Cloud environment. And so that's essentially what we bring. We bring the capabilities of that. I mean, we've been doing it since 2011. So Lambda's been around for a year. But of course, they're AWS, so they do what they do very well. But we do it outside of AWS and we do it in a nice containerized way. So that matters to a lot of people. And that's what we're working on right now in collaboration with a lot of the partners in this ecosystem. And of course, marketing drives a lot of what we all do. So to have trends like just Docker in the serverless computing movement, to be able to have an answer to that is important because a lot of developers want to stay up to date, might ask some questions. And if someone says, what's your serverless story? You can say, well, we have a partner. They do a great job of it. And then we can work on some marketing and sales initiative. And that works very well. So without that full kind of spectrum, it's not really worth us being involved and it's not worth anyone being involved with us. But what we actually bring does matter, I think, to this ecosystem. And so far, we've found that that's been receptive. But of course, Cloud Foundry is an incredibly opinionated platform. I don't say that in a bad way. It's just something for companies like us to consider when we're breaking in from scratch because we built our platform our way. And we've been doing it for five years and we're pretty good at that. But in this world, it's not enough to bring some of the table. You have to bring something to the table in the Cloud Foundry way. And I don't mean that from that, pair programming dojo perspective. I mean that from the actual platform itself at the technical level. So in our experiences so far, we've had to interface with a number of components of the Cloud Foundry platform, starting at the service broker. That was the easy part. We've been on Pivotal Web Services Marketplace for a couple of years now and that was really easy. You can provision an account with us. You can start using our API on your PWS applications. Check, that's easy. At service broker, we've then moved out and made independent and we have customers using that service broker with their Cloud Foundry deployments to provision accounts for us. But we operate services that need to be deployed via Bosch if they're gonna be in the actual Cloud Foundry deployment. So we have to figure out how do we do that? How do we package this together as something that can be deployed via Bosch configured and scaled and customized? And so that's where I hope to see some of the same standardization that we saw with the service broker API around some of the packaging and I've talked to a few folks here who share that desire where we can actually take that package and make that a Cloud Foundry package that can be picked up and moved so that the services are also interoperable as the applications are. Because we deal with workloads, we deal with the end-to-end lifecycle. So there's actually some core internals that we have to interface with. So we found that there are times that we need to actually connect to the Cloud Controller API, things like logging and monitoring. That means we have to develop that. We have to build that into what we do. But there's a reason for doing that. Now the really cool one, and this is what we've been working on for a while, is an actual native runtime integration. So we're a job processing platform based on Docker containers. Our notion of a task is a Docker container. Diego's notion of a task is a Diego task. Is there a benefit for us to incorporate our service, our API, all the things that we do around lifecycle management, but do it in a way that interfaces with a runtime? So instead of us spinning up a Docker container, we spin up a Diego task. And the answer is, yes, there's a reason to do that and we're working very, very hard to figure out the best way to do that. And in that process, we've uncovered some gaps. And we've uncovered gaps on both ends, from our end and from the Cloud Foundry end. And really the goal of the past few months has been to try to narrow that gap to the point where we've got a package integration. There were some things that we built our platform around Docker and maybe we were a little too tightly coupled to the Docker API. So in this process, we uncovered that. And we did a little bit of re-architecture and we made ourselves a little more container agnostic. And that was beneficial for us just across the board. Now on the Cloud Foundry end, the Diego Runtime Task API was still early when we started working with it. So what we did was we started playing around, took some notes and then provided feedback back to the team and then I feel like we actually influenced the roadmap. And that is pretty cool for a company like us kind of coming into this very established community with very strict rules around contributions and just being an ISV to try this stuff out in the way that we did, I feel like we had an influence on that. But one thing I know I need to learn more is about the actual governance around contributions and what that looks like. Because then I feel like we can really influence. But that worked well for us. I hope it worked well for the task team. We'll see if Guido agrees. So that's a lot of work for us to do. We're a growing company but still small. So we have to make decisions. When to commit to and invest in a technology partnership. Actually it's more of an initiative than it is a partnership. It's an initiative for us to take on Cloud Foundry. So when do we do that? Forgive my amateur diagram design skills but this is the best I could come up with. You have kind of the strategic interest moving in one direction and then customer demand moving in another direction. At some point there's an intersection there. And usually it's when cocktails with partners intersects with an RFI. Hopefully not at the same time but some kind of intersection between those two things. But that's not enough. Because it's gotta be a product fit. It's not a product fit, we're just spinning our wheels here. Partnerships for the sake of partnerships just doesn't make sense. So we found that we put iron IO up next to Cloud Foundry and we really looked at it closely and we said, there's a fit here. These things, they line up, there's some overlap, there's some things missing, that's fine. But if we really look at it from this perspective, this is the right fit for us. And because we've got this interest that we're moving in this direction from a strategic perspective and because we have customers in this Cloud Foundry ecosystem coming our way and it's this nice perfectly timed fit, we made the decision to commit to and invest in Cloud Foundry. And of course that means that we're now working with partners and customers together in these joint initiatives. And it kind of goes without saying but I'll just bring it up anyway, that any one of these initiatives has to be a win, win, win, not just a win, win. The partners have to win and the end user has to win. So there's a couple things that we've encountered that could come up. I mean, we obviously, we have our own business model, we have our own licensing model. So how do we line that up with our partner's licensing model so that we're not double charging our customers? So things like that, we have to take into account as we kind of build our business in the Cloud Foundry community. But so far, it's really just a matter of kind of putting our heads together with our partners and everyone's been receptive and we've kind of found nice ways to kind of coexist and put forth a mutually beneficial solution. One point I did want to make here is, even though we are committed to and invested in the Cloud Foundry ecosystem, we are an ISV, we do have to remain neutral and kind of focus our value add across the entire IT ecosystem. We have our own interoperability aspirations. So we work with all the platforms and all the container orchestration services. So that's part of the when do we commit to and when do we invest comes down to back to the previous diagram is one of all these things line up. I mean, we can be influenced on strategic interest and customer demand but it's in our best interest to kind of remain neutral. So sometimes I kind of gotta zip up the mouth a little bit when things start getting a little too opinionated but really it's been okay for us to kind of coexist and just as Cloud Foundry wants to be interoperable with different Cloud providers then we want to be interoperable with different platform providers. Everybody wins at the end of the day there. So it was this time, no it wasn't this time last year, it was in Berlin at the Cloud Foundry Summit. So I was at the pivotal party and I think it was Josh McKenzie came running up to me and said, hey, from your perspective, do you care how opinionated the platform should be? And I thought about it for a second. I had like two drinks so I was still okay. And I came up with this, I said I am unopinionated about how opinionated the platform should be. Meaning I get both angles. I understand the benefits of a very prescriptive platform like Cloud Foundry and I also think things like Kubernetes and Mesosphere are super cool. It's all about choice at the end of the day and we tend to kind of, we'll just go where the wins take us where our customers are driving us towards and try to play nicely. But with that being said, and I can confidently say this while still remaining neutral, in this digital transformation era that we're in right now, I strongly believe, and we have the same perspective, that Cloud Foundry provides the right abstraction layer. By abstracting away all the complexities of the underlying operations and exposing an incredibly easy to use interface for application development, those developers and those businesses who are on the hook to deliver continuous innovation can. And that's really where I see Cloud Foundry's strengths. It's our own strengths. And together we kind of try to make sure that all those things line up and that does that story comes together at the end of the day. So I will close by saying just on a personal note, this Cloud Foundry community has been incredibly welcoming. Being a small ISV, I still have to elbow my way into some of the conversations, but I generally feel like people are interested in what we have to say because I do feel like that shared mutual interest is understood across everybody that participates in this ecosystem. It's good thing that everybody drinks enough so I can just kind of pop in with a little glass of wine and say, hey, what are you guys talking about? Usually works. I didn't get thrown out of any circles at the reception last night, so I'm happy. But we're still kind of outsiders. We're not contributors. No one's gone through the Dojo program. This is a few people I've kind of put aside and said, help me work on this a little bit. But I'm hoping that our continued investment and our continued participation will uncover some things that we can actually contribute back and that can be contributed back in a beneficial way so that the entire ecosystem benefits from what we've done and what we've worked on. So I hope that this time next year or the next summit or whenever that is, that me or somebody else from my team is up here presenting something that we've contributed back to the community. Until then, we've got a lot of work to do, but I think we're getting supported by our partners which has been incredibly helpful. So I think with that, I will open it up for questions. If you wanna get in touch with me, you can find me on email or find me on Twitter. They're sparingly. Well, yeah, thank you. Any questions? Come on. In not spinning up a container, but spinning up a task instead, a difference? That's a good question. We haven't benchmarked that yet because I think we're still working with the task API itself to make sure that we can do those types of things, but I think that would be actually pretty interesting side-by-side comparison. And one thing I talked to some of the Cloud Foundry folks, what would be interesting is if we could put forth a benchmark around kind of concurrent processing within the Cloud Foundry in Diego runtime, that would be a useful benchmark across the entire ecosystem. So that's probably something we'll wanna do and make that comparison with how we spin up Docker containers, so yeah. Good question. Let me follow that up. Anybody else? Are we doing on time? Huh, perfect. It's 201. Okay. Well, thank you so much. I appreciate it. My name's Ivan. Cheers. Okay.