 I'm Mark Little, and I heard cats. The cats that I heard are the Jboss Fuse, Feed Henry and some aspects of the developer programme that we have within Red Hat, and it's good cat herding. The micro profile is a collaborative effort by ourselves, IBM, Hiara, Tommy Tribe and the London Java community, and the idea is that we want to work entirely in the open. We have a website, microprofile.io, to define a profile for developing microservices based applications with Java EE, and then eventually to extend beyond where Java EE is today. Microservices have kind of exploded onto the scene in the last couple of years as a way of improving business agility. The typical way that we have as an industry been developing software for years is waterfall. But when you're putting out a new version of product 12 or 18 months cycle, nowadays it puts you at a competitive disadvantage. So microservices is meant to give you much better agility by decomposing your application into a set of services that are independently versioned, independently deployed and obviously independently developed. Microservices have, as I said earlier, been around essentially for like two years. Really their history goes back a little bit further to service-oriented architecture. We've seen some negative backlash on SOA for better or for worse, and there are a number of vendors when they're pushing microservices these days are essentially saying that if you want to get the benefits of them, you have to start from scratch. You really need greenfield deployments. Now, while that may make sense for some microservices, and we do have options from a Red Hat perspective in that area, we have seen an awful lot of things that are being done. We've seen a lot of interest from our customers and communities about how they can use the knowledge that they've built up over the years around Java and Java E and move slowly and pragmatically towards microservices. And Wildfly Swarm is a project that we started about 18 months ago to do precisely that. The aim is to take a Java E compliant application server and associated applications within it and allow you as a developer to pair it back into only those bits that get deployed into a service that you need for the business logic within that service. And Wildfly Swarm generates fatjars that are also immutable, which fits into the new approach of immutable architectures as well. Micro-profile is starting off as being focused on Java EE because that's a well-known standard with a well-known and well-defined set of component standards, or JSRs. But Java EE was never developed and defined with microservices in mind because it's been going for the best part of 15 years. So we do envisage that, although we're going to start off with micro-profile being very, very Java EE specific, we rapidly are going to start adding in things like Netflix, OSS and other things to go in other areas, such as reactive event-driven microservices, which isn't something you find in Java EE today. I think it's more of an evolution in the same way that Java EE was an evolution, everything that had come before it, Cobra, DC, et cetera. And we've been evolving Java EE. A few years ago it was J2E. We didn't change the name to Java EE from J2E just because it felt like a good thing to do. Everything is evolving, and microservices profile is a natural evolution of that. And in a few years' time, I don't think we'll talk about Java EE, we'll talk about Enterprise Java, but you'll be able to recognise a lot of the same components. We're doing this outside of the JCP at the moment because I think, in my personal opinion, I think it's shared by a lot of others, is standardising something too early gives you standards that are completely irrelevant. Not fit for purpose. And despite the fact that microservices has been around for a couple of years, it's still very, very young in that space. And even much more immature in terms of how you take a Java EE application server and move it towards microservices. So we want to do this collaboratively in proper open source fashion upstream first, get some experience, and then once we think we've got a baseline trying to standardise that. We announced the micro profile at Dev Nation with IBM, Pyara, Tommy Tribe in London Java community. Simply because those were obviously the major Java EE vendors that are around, at least some of them, and a Java community user group of 4,000 members, which is significant. We want to do more. We absolutely do want to do more. In fact, we were talking to others who were interested in this up to the announcement time, but they just couldn't get through the legal loopholes on their side. And since then, we announced the micro profile.io website that's associated Google group where people can get involved and that has seen a huge number of people join since we announced at Dev Nation. And that's the right way of doing it. And I'm hoping that we will get more and more supporters, community, individuals and other vendors in the next few weeks or months. Well, currently you can obviously get involved in Wildfly Swarm and Wildfly Swarm will track whatever we do in the micro profile. In fact, it's being used as one of the main driving forces for the micro profile. At the moment, because we do not have an agreed baseline for what the micro profile will look like in terms of JSRs, what we're currently thinking about is putting quick starts up there. So show how you can do a JAXRS and CDI and maybe JPA micro service with a Java EE style with Wildfly Swarm, with IBM's Liberty profile and with the PyR and Tommy Tribe equivalents. So people can get access to stuff now and start playing around with it. And I think that's the right thing to do because we really are at a point where we want input from people. We want them to tell us what works and what doesn't work. In terms of governance of the whole micro profile effort, we're still discussing that and we'll have that again in a very open way. It's not like it's going to happen behind closed doors. Whether it goes through to an established foundation such as Eclipse or Apache, again, we will discuss that in a very open way. I think it's really, really important that we don't do something that ends up looking like it's a Red Hat only or an IBM only effort. So having it move to some kind of foundation or adopt the same approaches as an existing foundation is definitely my preference. Of the two, I go with something that already exists because setting up foundations and managing them is something that we shouldn't do. The micro profile effort at the moment is probably going to be focusing on just one or two areas in what we might consider a full blown micro profile stack. There are so many things going on in other areas, whether it's Netflix OSS, whether it's Docker containers, whether it's things like CloudForms and CI CD. All of those really do come together when you're doing micro services because you don't typically deploy just one micro service. You'll be deploying tens or hundreds maybe eventually. So you need all these things to make that work well together. I do not think that will be the remit of the micro profile.io effort. It'll be to define a bit of that that then fits into things that are going on elsewhere.