 So before I get started, I have to do a Josh Long trick. He made me commit to doing this. I'm going to get a quick selfie of all of us. I suck at selfies, so I'm going to try to get my top of my head and everybody else in there. Let me just one more to make sure. OK, cool. I'll tweet it later. So for those who don't know me, and you shouldn't probably know me, I'm not really that well known in the industry. But I was with SpringSource for quite a while. I joined SpringSource in 2008 because I sold my company Covalent to them. We brought Tomcat and the Apache web server to SpringSource. And of course, then SpringSource ended up at VMware. And I stayed with VMware for a couple of years afterwards. And you'll hear the history of the company in just a minute. LightBend previously Typesafe. Maybe you probably know us as Typesafe. But I went from VMware to Typesafe in 2012. So I thought, Michael suggested this last night, that I would give you kind of a quick overview of the history of the company. Because I think it's not just relevant for what we're about. But more importantly, kind of what we're seeing, what's the evolution of technologies around the JVM. And certainly, Spring and the Spring technologies have changed a lot in the last four years. And of course, we, Typesafe, LightBend, have brought a lot of new technologies to the JVM as well. And I think our history kind of helps explain that. This will probably take me, depending on how fast I talk, 15 minutes or so. And then what I really wanted to share tonight is we just published today. Actually, it's probably not even out yet in Singapore. But it's coming out in the US today. A survey, results of the survey we did, that was 2100 developers and architects around technologies that they're using and planning to use going forward. So things like containers, docker, and of course, excuse me, using technologies like ours to build microservices, technologies like Spring. So it's a deck. I haven't even used it before, so it'll be the first time. But it's the results of that survey. So I thought it'd be interesting. Company was formed in 2011 by Jonas Bonair and Martin Odersky. And Martin is the founder of Scala. He also happens to be a full-time professor at the EPFL University in Lausanne, Switzerland. He still works for the company, and he still is a professor. So he's got two full-time jobs. And then Jonas Bonair is the founder of ACA. I'm sorry. I should have said Martin founded Scala, of course, and we'll get to the history of Scala in a minute. And Jonas founded the ACA project. And the two of these gentlemen came together in 2011 to form what was type safe at the time. And as you'll see in just a second, they formed the company after the technologies had been already in the market, already adopted, in fact. Scala goes all the way back to 2001. First release 1.0 came out in 2003. Anybody here use first release of Scala? You probably didn't want to. Or even 2.0 probably didn't want to. It was probably 2009 or 2008 maybe before they got to a point where you could really utilize it. But this is an interesting kind of graphic because it shows that this is not a new technology, this language. It's been around for quite a while. Martin started this project at the EPFL. Initially, it's a research project to prove that you could take functional programming and object-oriented programming, put them together in a single language on the JVM, and give developers the choice to use whichever they want. He also wanted to make sure that it was an advanced language at the time where it utilized all of the resources available, hardware that had multi-cores. I mean, CPUs had multi-cores. That was hard to do in the Java world back then. The rest of these are also the languages. And some of these have done really well. Some haven't. Kotlin's picking up speed. Clojure's kind of stalled a bit. But they're still out there. Groovy, of course. That was a spring-source technology. We acquired that at spring. It's now a separate project again. As of this latest survey that's done by Redmonk, Scala is the number two language on the JVM. Still pales in comparison to Java, though. We're not quite 10%, probably between 8% and 10%. So it's still very small compared to Java. But it is the number two language on the JVM. The first real commercial use of Scala happened in 2009. And this was, for those of us who watched the World Cup in 2008, remember that Twitter, if you used Twitter back then, you saw a lot of fail whales, right? That thing just crashed all the time because people were trying to tweet about the games and couldn't, because literally the system couldn't stay up. So Twitter made the decision to re-architect the services that they built all in Scala on the JVM. And so that started, I think it started early 2008, made it public in 2009. And that was really the first time you started to see people using Scala as a language on the JVM in kind of commercial use, if you will, as opposed to just research. Up until then, you'd find Scala in universities. Stanford's been using it for years on their, just lost the name of it, but anyways, they're a high parallel computing platform for testing hardware. They use Scala as a language to prove it can perform really well. And other universities, same thing, have been using it for years, but not commercial customers, not companies, building applications. And the result was not just that the site didn't go down or the service didn't go down, but they actually saw a huge improvement in performance. And that was one of the objectives as well. This still predates TypeSafe. TypeSafe doesn't exist yet in 2009. 2010, you started to see a whole lot of other companies picking up the technology or picking up Scala. A lot of big web 2.0 web companies, whether it's LinkedIn, Box, Tumblr, Meetup, these companies started adopting it. Then you saw some commercial, typical financial industry companies like US, UBS, sorry, HSBC, Morgan Stanley, JP Morgan. Many of these companies pick up languages early in their life. Most of them chose to use Scala because they had some performance requirements and they wanted to get much more performance than they were getting out of just Java on the JVM. Again, this still predates the company. We don't exist yet. ACA similarly started before TypeSafe. ACA was born in 2009. Jonas was trying to create, trying to solve two problems. He wanted to solve the biggest problem of which was high concurrency on a web-based application. How do you build a system that can handle massive amounts of concurrent users and scale both horizontally and vertically? And he also was trying to solve a problem for just native cloud-based run times, if you wanna call it a run time. And I come from Spring, as I said, and I also came from Covalent, which is the company behind Tomcat. Tomcat's still the largest container, if you wanna call it that, in the Java market. It doesn't do real well in a cloud-based environment. Sure, you can run it on Cloud Foundry. There's lots of ways you can try to make it scale, but it is not natively built for that kind of use case where you're gonna run it across a cluster in the cloud. ACA was designed with that in mind from the get-go. And then, a big moment in history for the company, I joined. So, it's, the company was around for more than a year before I got there. I knew about it within two weeks of when it was founded. It was founded in February of 2011, and the reason I knew about it, because at VMware, one of my jobs was to look at other technologies that we were seeing in the market and potentially acquire them. We did five acquisitions while I was there. We looked at 37 companies in the two and a half years I was there. This was one. I tried to buy the company. It didn't happen. Thankfully, it didn't happen. They said no, but that's how I knew about them. And then a year later, they passed forward, they were looking for a CEO. Obviously, Martin couldn't be the full-time CEO as a professor, and the VCs were looking for somebody who had some experience in open source and building businesses around open source, and they found me. So, it was perfect, at least in my eyes, it was perfect match. The first thing I did, there's actually a slight reversal here. I'll come to it in just a moment. But the first big thing we did publicly was we embraced Java. ACA works with Java. There's a Java API. And we'll talk about play in a minute. Play works with Java as well. The company, at that point, and still even a couple of years after, was known as the Scala Company. TypeSafe and the name TypeSafe has a lot of meaning to Scala and programmers in Scala. We are very invested in Scala. Everything we build is built in Scala. But we, if you look at our customers and our technology stack, it serves the Java market. In fact, our customer base is more Java than it is Scala. So it was important for us to make that shift. And it's not just a shift in message, it's a cultural shift. You can imagine anybody who's been using Scala and is a fan of Scala, once you've decided to go that way, it's hard to go back. It's hard to say, okay, Java's okay, or I'm gonna use Java. So we went through an internal kind of turmoil if you wanna call it that, of just accepting that Java was good enough. And actually, great. Now that you have Java 8, much better. Play framework. This actually happened before I joined. I was still helping the company, or I was helping the company before I actually made it here full-time. And we did this acquisition. So Play came out of a small company in Paris called Zanexity, they changed their name since then. And they designed the Play framework. We acquired the IP, paid them to build Play 2.0, which had more Scala support, and of course just is the version of Play that's available today. So that gave us a web framework. So prior to that, we had the Aucca framework and tool set, and then of course we had Scala the language. This gave us much more of a platform. The next big challenge for the company is to try to define what's the market? What's the category we're going after? And we could just say we were the next spring source, or we're a better spring source. We're not, and we weren't. We were trying to solve a different set of problems, and today I think both of us are converging. But at the time, the challenge was how do you describe it? And most of you probably heard of this thing called the Reactive Manifesto. We published it now three years ago, July 2013. It was written by Jonas Bruner. The initial version was written by Jonas Bruner. And when we published it, this was our objective, was to define what does it mean to be reactive? How do you define this next generation of applications in a consistent way, or nomenclature that you can all agree is the right way to describe it? And these four key tenets kind of make up what Reactive is all about. It's message driven, it's elastic and resilient, and of course it's responsive. And responsive could be an end user application with a web page or a phone app, or it could be responding to just services on the back end, not necessarily having a UI. But these are the four tenets. And if you haven't read the manifesto, actually there's no slide here. If you haven't read the manifesto, it's about two and a half pages or something like that, maybe three pages, it's reactivemanifesto.org. I encourage you to read it. When we published it, or when Jonas published it, it didn't say type safe or light bend or anything on it. You didn't know it was us, that was intentional. We were trying to see if we could get other vendors to say yes, this is the right way to describe these kind of new applications and the way they should be designed. And we succeeded, you can see that here. So Pivotal, which hadn't been, actually it was Pivotal by then, I'm sorry, in 2013. IBM, Red Hat, VMware, Microsoft, and all these companies said yes, this is the right way. Three months after we had published the first version of 2.0 came out. And in 2.0 there was tons of contributions from these vendors as well as other individuals in the industry that said, yeah, you're not quite right. There's a few ways you could describe message driven versus event driven in a little bit better way. But the good news is this 2.0 came out with a lot more support. It's an open source project itself. You can see it on GitHub, you can contribute to it. There's lots of comments on it. And I'll stop talking about it, but that's the manifesto. Next big news was 2014, we adopted Spark as part of our offering. And Spark, for those of you who don't know, I'm sure how many people here have used Spark or have some experience with it? Like half, that's great. Spark is written in Scala. And there's a whole bunch of other technologies that is in this new reactive fast data world that also are written in Scala. Kafka, written in Scala, parts of SAMHSA, Beam, and a whole bunch of other technologies. Miso, or Marathon on Miso's. Scala happens to be the language of choice for a lot of infrastructure projects, things that get used in this new world. Well, we adopted Spark as part of our offering because developers were using it in their applications, not just the data scientists who are running Spark jobs. We're not serving that use case. We can't, we're not Cloudera, we're not Hortonworks, we're not one of those companies. But we can help people who are building applications like an ad serving app or something like that where Spark is part of it. And that's exactly what we offer support for. The next big news, 2016, we changed the company name. I alluded to this a minute ago as to why we changed it. There really were two reasons, and by the way, I wrote some blog posts if you're really bored some night and you want to read them. May of 2015 was the first one, and then there was two or three others after that, about why we were changing the company name and the process. We were very open about it, we talked about it publicly, which was both good for us to kind of get feedback, but it also allowed people to kind of come to terms with it, right? If you're scholar developers, you probably love Typesafe, right? Am I right? Any other scholar developers here? I don't know a single scholar developer who did not like the name or love the name Typesafe. They all loved it, right? But it was a funny joke to call the company Typesafe and invent actors. Point made. So actors, that's not the reason we changed it, but it's a contributing factor. Yes, so, but Typesafe, most people thought of Scala when they heard Typesafe. It was kind of natural, right? Typesafety and Scala. And we are more than Scala. We serve Java, and we are intending to try to serve the Java market. And it was really hard to get that message across with a name that really spoke to Scala. And the second reason that drove me crazy is people misspelled it. We were Typesface all the time. There's an article, they fixed it, but there was an article that came out, they interviewed me in 2013, and they put in big bold letters right across the top. Typesface, Java, the JVM gets Typesface. First off, that doesn't even make sense, but secondly, we're not Typesafe, I mean Typesafe. So that kind of stuff just drove us crazy. So we changed the name. And Lightben doesn't speak to Scala, doesn't speak to Acca, doesn't speak to any technology. It's not supposed to. It's supposed to be a name that's memorable, but it's supposed to be thought-provoking, but not tied to the technology, right? So that was big news. And at the same time, we changed the company name. This was February this year. We launched a new product, a microservices framework for Java. Today it's Java only. It does not support Scala, it will. It does not support Scala yet. Lagom, and anybody know what Lagom means? Lagom is a Swedish word, which means just right. Perfect size, not small, not large, not medium, but perfect, just the right amount. So the name change and the launching of Lagom were intentionally done at the same time, because we wanted the Java world to recognize this company, but also see that we had a product, a software project that was available for Java developers, and so that's what Lagom's all about. Okay, I'm gonna flip through this next couple of slides fairly quickly, but we talk about reactive. This is not a sales pitch, but this is a, it's an impressive slide, right? These are all companies who use our technology in production today, and every one of them is a customer, meaning they have bought our offering, our subscription. In the open source world, we all know this in spring, of course, you're probably all consumers of spring technologies. There's literally tens of thousands, if not hundreds of thousands of companies who use your software, not all of them by your product, your subscription offering. Every one of the ones on here has bought our subscription, and we've grouped them by kind of business case, what was driving them to move to a reactive way of building applications, and these, I would say these three here in the middle was where we lived for the first three, two and a half years of my being at the company. New projects, Greenfield projects, an IOT based system like the precision agriculture system at John Deere, completely built from the ground up. Or down here, Verizon, this is the new Go90. Anybody use Go90, the platform where you can watch streaming video on your phone with Verizon? So it's a service they built. It's a video streaming service that wasn't even in existence more than 18 months ago. And then new market expansions. This is usually taking some platform and making it available to a new audience, like Direct TV. This is when they launched their service for iPhone and iPads that previously was only available on the set top box. Obviously that's an American company, so you probably don't know much about it here, but. Or Major League Baseball, this is an interesting one. What do you think of when you hear Major League Baseball? They probably have content for people playing baseball, right? Well, they built this amazing video streaming platform that now they've licensed to HBO. HBO is, if you watch Game of Thrones online, that's being run on Major League Baseball's streaming video platform. So they've actually spun out a company from Major League Baseball that does nothing but serve content for video. So excuse me, that's where we lived, those three groups there. The other two, especially the one on the far right, is kind of where we're seeing more adoption today. And it's simply put where companies are taking their existing applications and either adding some new services in a microservice way, adding some new functionality, or they're breaking it down, breaking that big monolithic application into smaller microservices-based. And so you can see some of the companies there, but there's quite a few that have embarked on that. All right. Do you have a great Java versus college? You know, I could rattle them all off. I think initially it's about 60% are Java. What happens though over time, as you would expect, is people start to play around with Scala. So there's a couple companies I'll mention real quick. UBS was all Java initially, and then they shifted, so they have a little bit of Scala now. Fidelity was all Java with Aaka and Play, and then they picked up some Scala sets. So just over time, they see some opportunities or they just want to learn a new language. It might be because they saw Samplap or they picked up a library that there's recommended or highlighted in Play, and they start using Scala because of that. Yeah, I'm sorry. Interrupt me if you have any questions. Okay, so what is our platform? Well, it's an open source based platform. I've talked about a couple of technologies. In fact, here, just to show you, this is the open source technologies that we provide. Obviously, we're not the authors behind, sorry, I keep walking over here. We're not the authors behind Java, we support Java. The rest of this is part of our platform. Spark, of course, we can't own it. That's an Apache project, but the rest of these are all completely driven by LightBend and the community around our LightBend technologies. What we sell is a whole platform that gives you not just that technology, but we license it to you under commercial terms. We give you support. We give you some tools or functionality for production that are not available in the open source. Things like orchestration, monitoring, and that's part of the product that you buy under our subscription. All right, so that's it for the sales pitch. Questions? All right, that's the history of the company. I'm going to jump to the survey results while I'm doing that. Anybody have any good jokes to tell? Sure. What do you guys have to say? So, if I'm the spinner of the development team and you've been trying to converge on the right architecture for use case, can you guys help me or is it just a license or anything? Yeah, so we provide a product that is under a subscription and we provide training and consulting as well. Our subscription includes classic support, but we pride ourselves on the fact that we go much further than the normal break fix when something's broken. Anybody here have a subscription from LightBend? That's what we need to fix. But the experience that you should expect is that we're going to help you be successful with your development project if you're in development, obviously. It's, and you know, I can speak to SpringSource because I brought it to SpringSource. For the last 17 years of my career, I've been in open source. And the one thing I know is if you don't deliver great value around the technology, and I'm not just talking about software, but great experience, they're gonna stop paying you, right? The customers are gonna say, I got support for the first couple of months. It worked, I'm done. I don't need your help anymore. So we pride ourselves on the fact that we will continue to move with the support that you need, right? So at the start, it might be architectural help. It might be just like the question, I need somebody to come in and help me design my system. But then when you get into development, we're gonna help you with development and knowledge transfer. When you get into just building the application and you have questions on what's the best way to do it, we're gonna give you advice on that. And finally, when you go into production, we're gonna help solve problems when they go into production. So that's the support side of it. And then as I said earlier, there is also training and consulting. If you want some help for building an application or you wanna bring somebody in from Lightben, we'll do that. We have a lot of partners, and Zeneca is here. I don't know where Michael went. Oh, it was right here. So Zeneca is a partner. They do training for us. They do consulting around these technologies as well. Okay. So I mentioned this report. It literally came out or comes out today. It's available off our website. So if you go to the website and look for it. We've done, this is the fourth one. We've done the last two years. We've done surveys on just what technology you're using on the JVM, very generic ones. We've done ones on what are you using for data? Data manipulation or using Spark or are you using things like Flink or Hadoop and other technology? So we do these about every six months. This one was targeted at developers. We got a decent amount. You'll see a decent amount of input from architects and management, not just developers. Developers know us, right? And they're the ones that we're mostly engaging. But starting to see more and more architects and management folks at companies looking at these technologies. Our objective with this one was really to understand what's happening with cloud or people actually deploying real production applications in the cloud. Are they using containers yet? If they are, what are they doing with them? Is microservices real? Is it something people are really implementing or building today? And then what kind of tools around microservices are they using? And finally, what about data in motion? Streaming instead of data at rest that's written at disk. Seeing data that's actually being dealt with while it's in flight. Excuse me. The audience, well, this gives you a pretty good estimate. Half, 52%, we're small startups. Kind of typical of what you'd expect. That's the people that know us, love us. But 28% up to 5,000 people and 20% with 5,000 or more people. And here's the breakdown of people. 50% developers, 27% architects. 16% management and 7% other. The interesting thing is in the large companies, 5,000 plus, 59% of them were architects. So that's a smaller group, of course, but there are more architects there than there were developers. Here's the key findings. And we'll come back to these. I'm just going to talk through each of these with the data. But number one, microservices and FASTAID are absolutely driving modernization efforts. Whether it's taking an existing application and changing it to be a streaming-based app or a microservice app or building something new, something brand new. Containers, when I say containers, generally speaking, we're talking about Docker, but Linux kernel containers are challenging or changing the way people think about deploying their applications. It's no longer the app server, right? So I mentioned Tomcat, I'm very familiar with it. Could be JBoss, could be WebSphere, could be WebLogic. Any of those containers are being replaced with things like Docker and enabling people to do more microservices, but also just enabling a more portable piece of software that I can move things from cloud or on-prem to different infrastructure with a lot more ease. And then finally, the benefits of cloud, a flexibility of driving applications to the cloud really are forcing people to rethink the way they build their system. So if you're going to start with a cloud as a way of deploying it, it's pretty easy. But if you don't know if you're going to go to the cloud, you might architect it in a way such that it'll be much easier to move it to Amazon or Azure or somewhere else in the future. All right, so the first one we'll talk about is microservice and data streaming or fast data. I don't have to repeat this, but these, actually I will, because reactive is an umbrella kind of construct where microservices, fast data, all these kind of use cases or technology movements fit. They fit under the reactive umbrella. They meet these requirements, right? So we're not talking about something distinct from reactive. Reactive just as an umbrella over all of them. So one of the questions that was asked was, what's the main reason why your organization is embracing microservices? And interestingly enough, or maybe not so interesting, is that the top two were all about kind of productivity. So faster, safer deployments for ops and then developer velocity of getting software out. Whether it's new releases or maintenance to existing applications or services. And then you started to see things like elasticity, driving it, just more resilient, more fault tolerant, right? And then lastly is the, I'm planning to deploy this in a cloud and so microservices makes that a lot more tenable or easier. Again, stop me if you have questions. I probably don't know the answer, but I will at least try to come up with something. So what describes your adoption of microservices? There were lots of other answers here. I don't think they're listed, but there's a little white slot at the top. But are you building things or in production already? If you look at the service oriented architecture, the precursor to microservices, how many real production systems were ever built successfully? I don't know the number. I'm just curious if anybody has a guess. It's a small percentage of what was talked about, right? Not a lot of people actually made it and got an SOA based system out and running in production. An awful lot of money was spent, an awful lot of energy was spent, but not a lot of success. In literally just a couple of years, already 30% of the people who responded to our survey are running microservices in production today. They're already there. And then there's 20 more percent, so half total are seriously piloting, building something, planning to deploy something into production. And then the other rest. So sandboxing as well as sort of interested or not interested at all. But clearly this is a big, big real movement. It's not just something people are talking about. They're actually doing it. Just a question. So very often when we talk about microservices, we see examples such as Twitter, Facebook, like these big product campaigns. I work for a bank. Do you think I should use microservices? I just have a simple app. It's not so. I mean, there is always way to use microservices. I mean, for example, cash. It's a good example of microservices. If you hide something like IRASpy or cost base over your service, it allows you to provide some very light civilizations and rules. It is a microservice. For banks, for example, I work for bank. We had jail microservices, jail occasions. It's your ATMs. You don't need to put it in your monolith application. I mean, and everyone desires to have it as a separate thing and so on and so forth. Yeah. I'm sorry. So yeah, I would just reiterate what you mean to say. There are use cases where it doesn't make sense, right? Where just flat out isn't the right way to build your application. Or it works today and there's no need to break it down into microservices. Maybe if you started from scratch today, you would have done so. But not every monolith needs to be broken down into microservices. In banking, we see an awful lot of it, but it's partially because they do a lot of iteration of new systems, whether it's a replacement of the old or it's just something new, right? Some new trading platform or some new risk management tool or risk assessment tool. So we're seeing an awful lot of microservices work in the financial, you saw some customer names, but in the financial industry, there's an awful lot of it. Could I add one more? Sure. Frankly, it is a really tricky thing because when we started to use microservices in bank, we were a little bit confused when we tried to build, for example, customer microservices. But all of you activities are about customers and you don't know how to segregate it, how to build, lose the couple to the system if all the payments are about your customers, internet bank, the customers and so on and so forth. But if you try to look at your system with a different angle, not with the angle of customers, but with the angle of functionality, you will see that payments is one part, deposits is another part, something like promo, different advertisement is quite a separate thing that could be separated. So it's just the way how do you see on your system? How do you look at your system? Thank you. Okay, another question that was asked was what's the overall data processing systems or practices you have today? And so this was really kind of a binary question, is it batch or is it real time data streaming? And so you can see that at the far right, there's mostly real time, 35%, that's pretty impressive. You have to take into consideration the people that answered these surveys, right? These are people that know, at least have heard of us probably. But that was still a much bigger number than we thought. This is people who are already building systems that are dealing with data in flight, data as it moves, right? Not data just being queried from a database. And then the second one, mostly batch, a little bit of real time, so similar numbers. And then split with the 21% between the two and then finally, it's very small, right? Only 13% between all batch and all, oh that's real time, sorry, only 8% is all batch, right? So very small that said we don't do anything except data that's at rest and we do batch processing against it, so. So that was a surprise for us. And then the second part of that question is, oh actually this is combining the two, sorry. This is asking the question about are you already using microservice in production and are you using data processing in batch, I'm sorry, in streaming mode in production already? So similar, and you'll see if you read the report, there's a lot of context here, but most of the people who answered yes to this one, the first one, also happened to answer yes to that one. So the correlation is very tight between the two. Again, probably that's not too surprising. This was a complicated one, not just to put the slide together, but a complicated one to kind of dig down into, but what's your experience with different data streaming technologies? And I'm not gonna give you a primer on the different ones. There's a great small little booklet that Dean Wampler, Dean Wampler's one of our CTOs at the company, he's well known in the data industry, he's worked with Spark and Hadoop technologies in Kafka for quite a while. He wrote a great little book that's free, I encourage you to download it, it's O'Reilly published it, you can get a link from our website that goes through all the different streaming technologies, everything from Spark streaming, to Storm, Flink, Soms, and of course, Aka Streams in Kafka as well. But I'll give you one point here, that Kafka is generally used for data that's coming in from some source, right, and via topics. And Aka and Spark Streaming are generally dealing with streams of data that's being processed, right? So in the app itself, between the services or in a service. And then Storm's similar, and then anybody heard of Flink, or using Flink? Excuse me. So Flink is fairly new, it's Apache project, happens to all be built in Skala and Aka, so it uses Aka, and Soms is written in Skala as well. And there's one more that's not here, it's Gear Pump, anybody heard of Gear Pump? It's Intel started it or built it, it's based on Aka, it's distributed Aka essentially, so doing Aka across the cluster. But this, so I won't try to go through all the data here, this tells us that Kafka's got a lot of use, right? So Kafka using a production already, 18%, 28% evaluating where Aka Streams, nobody else is even close there when it comes to production. And then evaluating you see similar numbers. Most people just haven't heard of Soms or Flink yet, the people at least we surveyed. So let's talk about containers. Really changing the way people think about deploying their applications. Who's using Docker already? About half again. In production or starting, anybody in production with Docker? Cool, that's great. So yeah, it's supported by these numbers. This is probably not a surprise that most of the users of Docker are new applications. Kind of fits with what I said earlier, it's Greenfield, it's new, they're using all new technologies. But this is pretty impressive, 41% of existing applications, people are looking at a way to either make a more portable or break them into microservices and deploy them on Docker or both. But 41%, that was an impressive number. Again, we didn't expect that one at this early stage. Why are you looking at containers? I don't think this is a big surprise, but, or not, I'm sorry, not why yet, we'll get to that. What's the interest is it? Are you playing around? Are you actually in production? We already saw those numbers. Are you not interested at all? So clearly, from here up, that represents 70%, 74% of the people that answered the survey. So it's real, it's not just people guessing or pretending to play with it, they're actually gonna do something real if they haven't already. Then the orchestration side of things, which orchestration tools are you depending on today? This is actually as of now. No, I'm sorry, it's not. As of now, question, I don't have a slide on. So as of now, MISOS is 22%, then it's Docker Swarm at 28%, and then it's Kubernetes at 19. So that's people who've actually deployed something already. I don't have a slide, but if you do look at the report, you'll see that data. This is where you're going. And I thought this was interesting. Docker, of course, is making Swarm really tied to Docker. And so therefore, if you're gonna be using Docker, it's gonna be easier probably to adopt Docker Swarm than others. Marathon, MISOS, we certainly see a lot of that, especially in the fast data world where you're doing data streaming. I mentioned that Verizon app and the Major League Baseball app, both of those are running on MISOS as the container resource management layer. Nomad, I have yet to see Nomad, but it's clearly some people are using it. Anybody using anything else that's not listed up here to manage your containers? Anybody using Kubernetes yet? No? Okay. We're starting to see Kubernetes show up a lot more. Sorry, two questions or two people? What development needs? For development. You're using Kubernetes? Okay. But are you planning to use it in production? No, just for development. Okay. Would you use something else in production? Would you deploy it on Swarm or on MISOS or something else? So, we're acting as an application. So, those are fixed standards. Only for development wants to be used for when there's Docker on Kubernetes. Okay. So, when you're done with the app, it doesn't need to run on the workstation. We are not there yet to actually use the Docker in MISOS production. Yes, the viewing application is not the answer to the question. Got it. Okay. Somebody else was... Yeah, I think the statistics is a bit skewed. So, if you ask general Docker user base, you would see more Kubernetes than anything else, I think so. What do you think, excuse it, but we'd be interested because, you know, our audience is... Developers? Yeah. Okay. Versus DevOps and just people in general, especially not JVM languages, and so on. So, that data is probably in this survey we should look at it and see if the architects or the management folks give a different answer than the developers. Maybe Doke actually did the similar survey. Yeah. Yeah, I've seen Docker surveys. There's interesting ones there. I mean, they show swarm being, like, pretty much everything that people are using. And, you know, it's just like if you were to ask all of our people to use Aaka, what frameworks, or if they're using Play, what other frameworks are they gonna use? They're probably gonna use Aaka, or they might use, you know, it's things that are related to us, right? Okay. So, let's talk about the benefits of moving to the cloud and why people are doing this. So, the first question we asked is, you know, where are you? And this data actually is really interesting when you look at the size of company. So, when you looked at those 5,000-plus employee companies, most of them are over here, either here or here. In fact, they're planning to go here, but they're on-prem primarily. They're not in the public cloud, right? Not a lot of banks are in the public cloud yet with much of their application workload. They might have a private cloud, right? They might have set up a cloud foundry or something internally. The public cloud, you see that, obviously, in lots of startups, you know, PayPal, public cloud, right? I'm sure there's many other companies here that are using a public cloud. So, these numbers were not that surprising. The answer to this question was interesting. To see 40% didn't know what a hybrid cloud was, right? Didn't expect that, but when you look at the developers and a lot of them are in startups, they don't think about Amazon or I think about maybe Azure or Google, but they don't even think about the concept of building something that's gonna run in production on physical infrastructure that they host. They're putting it up on a public cloud. And then you can see these yourself, but some in production and hybrid, this is where the data really got interesting. This is where enterprises are, the banks. They're actually moving to a cloud-based and I can tell you that even financial services companies are looking to start moving some of their services or applications to public cloud. Of course, they're gonna make sure they're secure and accessed only by the people that are supposed to have access, but they're planning to run them there because they wanna stop having to manage all that infrastructure, deal with the operation side of things. And then similarly, this group, so these two are kind of the same, but you saw a lot of people either already using hybrid cloud or planning to out of these big corporations, the larger ones. Startups were generally all cloud only. I mean, you yourself came from an EMM. What do you think hybrid cloud will be like? Because you can see both the sectors. Yeah, different than what we thought of EMM or at least while I was there. And what we thought was gonna happen was people would build, they would take something like Cloud Foundry and build a private cloud first, deploy all their applications on that, manage it that way. And then as services became or needed to become public, they would move into a cloud foundry-based public hosted service. Remember, we had cloudfoundry.com, it was free and it was a way for you to run your applications. That was the concept. We thought people would start private and then just move some of it to public hosting. What's happening, this data doesn't necessarily show it until you get down to the details, but what we see more is people are taking application services and building them from the ground up to be public cloud, something that's running there. And it might be dependent on or work with something that's running inside the firewall as well, but they're separate services. And so they're not taking it first from on-prem and then slowly migrating it. They're actually building distinct services that are okay to run in a public cloud on top of existing private stuff, stuff that's behind the firewall. So I think a hybrid cloud to me, it's still gonna look like you're running, you may not be Cloud Foundry, but you're gonna be running some sort of internal private cloud for all your stuff that's cloud-based. And then the services that need to be public or you can run publicly, you're gonna have them there instead. And the key to hybrid is that it means it's not, they work together. It's not, this app runs here and this app runs here. It's one app that actually runs in two different places. Or parts of it. What's opening with OpenStack? Well, clearly OpenStack has done very well. I can't give you much of a current opinion on it, but two, three years ago, we thought OpenStack was gonna die. Just thought Red Hat has invested a lot of money in it and didn't think it was gonna make it. To us, we're agnostic about it. We don't really pay attention and we honestly don't ask the question, what kind of private cloud software are you using? Are you using Cloud Foundry or using OpenStack? We don't ask those questions. We probably should, but we don't. Are you using OpenStack? I know. Okay. Anybody here using OpenStack? I was the developer of OpenStack and a computer computing team. Oh, okay. I'm a market full of kind of users. Cool. So the experience that I'm having, actually I'm speaking to multiple CEOs in the banks, is mostly they are interested in, not on the IS layer, but on the pass layer. They're not even thinking about this containerization. So they say that we have these developers. They know how to write good code. Now, give me a platform that will leverage, improve the time to market, basically. Improve the time to market. You don't want to deal with any of this containerization. You deal with it. So either PCF or OpenShift or BlueMix, put it over there, get the bundles, put it over there. Maybe OpenStack will be used by these platforms. Exactly. As an underlying open, so as underlying IS layer, but not on the, not developers or DevOps doesn't want to deal with this. Because the APAs are, you know, they are not at the level of the resources in OpenMix yet. There's a lot of infrastructure to do with things that are quite cool and safe. Thank you. Okay, I think I have just a couple more. Is there another question? Nope, all right. So cloud strategy, it's kind of a follow on question to the prior one. So on-prem have no plans to move to cloud 31%. And most of this was, you know, large infrastructure companies, big enterprises. I think the percentage that, in that 31%, the percentage that came from the 5,000 plus was 60%. So mostly large companies. Second, similar number, or same number, but, you know, running your applications in the cloud. A lot of startups here, a lot of small companies, right? But that's just where they started. They didn't even bother starting on-prem. And then you're seeing some movement towards cloud native strategy. It's similar to what I shared earlier. And then finally, the last one is just kind of, we're not there yet, but we're looking at it a year out. Or a year plus out. And how many here are running applications already in a public cloud right now? How many are doing it all on-prem? No public cloud at all. So a couple, all right. Yeah, so I think this is similar to what we're seeing in the data. Why? Why are you keeping it on-prem? It's a good question to ask. Not a surprise as to the reason security. Biggest concern, compliance. Of course, if you're in some industry where you can't make things publicly available, you just don't have a choice. You know, and actually the third one's a valid one. Some don't need it. I mean, in the future, don't need it versus you want to continue to invest in all that operational infrastructure and operational people. Seems kind of foolish, right? If you can run it in a much more efficient way in a cloud, and it doesn't have one of those first two concerns, you know, security or compliance, why keep it on-prem? And then of course, people just reluctant. Okay. This was an interesting question. How much influence do your teams have on your company's architecture and technology choice? So this wasn't just cloud. This was all of the questions we've asked so far. Who has the influence on the decisions of what gets used, right? And the question is targeted at developers. So 40% a lot. You would think so in smaller companies. Developers have a lot of say. They should. Developers, if you ever read the book King Makers or the New King Makers by Stephen O'Grady, developers get to decide what gets used. That's absolutely happening. Some still this, these two, 100% in the big enterprises. So that wasn't a surprise. But it started to change. But literally the ones that said zero, they all came out of the large corporations. Do you know the breakdown of this result that called the do their roles? This was just asking the people who surveyed about developers, right? So if you're an architect, the question was posed to you, do your developers have a say? Or if you're a manager, do your developers have a say? It'd be interesting to just take the developers and see if they think they have a say and then take the data is there. We probably just need to slice it. But this is everybody. So yeah, thank you for clarifying that. Okay, last summarized. Takeaways, agility is not just about the developer agility. It's also about how you operate. So in a reactive based system, I was telling somebody this the other day, that reactive isn't just about the constructs of how you build an application, how you think about its architecture and how you develop it. It's also how you deploy it and how you maintain it. How you're able to iterate in an agile way. And that means operations or DevOps operates in a much more agile way than what historically they would have done. One way to get there is through microservices. It certainly helps. It's not the only way, but it certainly contributes significantly towards it. Think of what you need to do to move off of those big monolithic app servers, right? And I'm not just here to tell you to stop paying Oracle or IBM or one of those guys. But for these agile microservices based apps, putting them on top of a big heavy container just doesn't make sense. It's certainly not Legault, right? It's not the right size. Think about data. So many of the new applications, data is at the center of it and data that is literally in motion. Data that's live. It's not just querying an old relational database. It's actually data streams coming from IoT devices. You might have an IoT based platform or maybe IoT is just part of it. Either way, that data, you can make use of it in real time. Whether it's anomaly detection or it's decision support or it's literally the application itself maintains those devices and it's dealing with the data that comes from those devices in real time. And then finally, think about data as being fast. Not just mini batch. Spark is great. Spark is mini batch. It's way better than MapReduce on Hadoop, right? But sometimes you want it even faster. You want lower latency. You want literally very, very fast processing of the data. So if you can do it in a way that doesn't require any latency or delays, then do so. That's it. This is available on our website right now. I just checked before I came in here. So if you go to the website, just do a search for the report. I don't think it's on the homepage right now, but you'll find it. Thank you. So before I wrap up, any other questions? I think we have time for Q and A. Sure. Yeah, one question. Is there a problem in the other side? It's not the answer, you know. So the activist, the body, and the looking is a string kind of thing. So that's an understanding. Yeah. So is that true? Is that a kind of particular use case for the active program, you know? Is there other problem in the looking? Problem is there's an advantage in that. Yeah, I think the question you're asking, I want to make sure I get it right. Is non-blocking a requirement for reactive? Yeah. Okay. It's broken. One more, one more. One more, again, the non-section. Yes. The non-section isn't protected. Yeah. So I'm going to give you my answer. I'm not Jonas Boner or Victor Klang or one of the guys that, you know, wrote ACA and wrote the manifesto. The reality is you can get very reactive and still have some things that are blocking. You can still have, in fact, it's really hard to have a complete system top to bottom that is 100% non-blocking, right? You're probably still querying some database that's synchronous and blocking and you're just, you're stuck with it, right? So if you want to have a reactive based system, there are times when you just flat out can't, even if you try to rewrite things, it's not possible. But even still there are some functionality, some parts of applications that work fine in a blocking way. There's no reason to rewrite them or re-architect them. Struggle through trying to build an asynchronous way. We've done it, right? And we've literally faced both customers as well as our own technology challenges where some things just flat out and have to be blocking. But to be truly reactive, 100% top to bottom, it's got to be asynchronous and it's got to be non-blocking. So I guess I give you both answers, but the reality is it's not practical. In every case it's not practical. Sure. I have a question about Lightben's future and strategy. You recently closed a series C funding of $20 million. So I guess my question is it gonna impact your strategies? How are you gonna work on new products like Lagom and provide new services, things like that? Yeah, so it was our, there's a series C funding round. It's kind of a typical series C for a startup. This is my ninth startup, so I've got a little bit of experience. When I say typical, it's at the point where you've proven the technology. You've got customers who are using it and proving that it has real value. Now your job is to scale. To scale both the growth of the technology's adoption, so the open source project work that we have to do and community work, but also the business. You have to scale the business. So the money we took was to help us on both those fronts. Prior to that, if you look at our makeup at the company, we're 105 people right now. We've doubled in size in 12 months. We were 50 people 12 months ago, and we were 59 people in January. So we've added 40, whatever that is, 46 people since January. The company is still 50% engineering. Actually slightly more engineering. There's a lot of software that comes out of LightBend. And we're not the only ones who build it. There's a lot of community members, I'm sure some of you are contributors, but we still have to have a very heavy engineering team. And especially if we wanna build new technologies that add to the platform. So Legom is new and there's a new team. It's James Roper runs it. He was the play lead. Now he's the Legom lead, but he's brought in new engineers. We'll do the same thing. I can't share too much because a lot of it's kind of early stage, but you will see some other technology that's net new from LightBend. And primarily to further the ease of adoption, the ease of kind of getting this stuff, not just using it, but getting it into production, building applications that actually meet your business needs. So a lot of investment on engineering. In fact, that 20 million, we're not gonna spend it all, fortunately, we'll be at cash flow positive before it's gone. And that was the other goal. They don't wanna have to go out for funding again. And it's always something that can come up, but the plan is not to have to do another funding round. That we are at a point where we're growing fast enough on the business side that we can make heavy investments, but still get to cash flow positive before we need more cash. But yes, we'll put quite a bit of that towards engineering and we'll grow on the classic, go to market side, right? Sales and marketing. Sorry, in terms of consulting, so I guess one of your added value is that your expertise in Scala. So when you support big Java shops, are you really just doing that? Or are you also trying to convince them that it's choosing Scala and more lightweight technologies? The reality is we never try to convince somebody to use Scala. But if the question comes up, this piece of functionality, can I do it in a more effective or efficient way with Scala than Java? We're gonna give an answer that's honest, right? But if you look at most of our customers, the people that are engaging the company, they're at Java. They wanna build it in Java. They've got Java developers. They don't wanna have to spend the time to learn Scala and we help them with that. So if you bring us in for training or you bring us in for consulting, you're gonna get it in Java if that's what you want and we won't pitch Scala to you. But if there is interest that you wanna learn, maybe learn a new language or you wanna build some of this in Scala in a functional way, it will help you. Yeah, you have to experience it though. I mean, if you asked the company three years ago, I might have said that, but in practice we were all Scala, right? We actually have Java engineers now. We have Java consultants. We didn't three years ago. Sure. Who's gonna set the direction for Scala? It's a great question. How many people have heard of Scala Center? I know you're not all Scala developers, so Scala Center was announced or launched just about four months ago, shortly after we changed the company name. And Scala Center is the beginnings of a foundation around Scala. Scala is completely owned by EPFL and LightBend. We jointly own 100% of it. We control it if you wanna call it that, but it's a community-based project. The compiler team and the current, whatever the current distribution is, comes out of LightBend. Contributions come from other people, and they get to submit them as a pull request or just as ideas, but the distribution, Scala 212RC1, that just came out the other day, that was 100% delivered by the LightBend team, Adrian Moore's team. So now to get to your question. Who's gonna direct Scala? It's still Martin Odersky. It's still Martin, and now Scala Center is a way for people to get involved. So the Scala Center, the concept behind it was that we were gonna officially announce a organization, a non-profit organization, whereby individuals can come to contribute code, or people can contribute money, and right now there's 11, I think it's 11 Scala Center sponsors, we're one of, of course, where you give money and you get to give a priority list of things you wanna see, things you wanna see in the future. There's no guarantee that it'll make it in there, but it's the beginnings of kind of a community-based, not a meritocracy like Apache, but a community-based effort to allow others to contribute and make their set directions. But ultimately, it's still Martin. It's Martin plus the team that's at LightBend, the rest of the team. So in your opinion then, how do you see the type level and the contributions? So the good news is, type level has not only made great contributions in Scala 2.11, there's some features that went in, and now Scala 2.12, there's quite a bit that came from them. They have historically done it via just pull requests that go to Adrian and his team. With Scala Center, they can get involved with a piece of functionality, whether it was the shapeless library or something like that, they wanna invest in, and then that can either, if it's gonna go into the core, they have to submit it as a, I just lost the name. The letter, sip process, thank you, couldn't remember what it's called. You submit it into the sip process, and that's been restarted since the Scala Center. It kind of died for a while, but it's been picked up again just in the last four months. Type level also just recently committed that they're gonna use the current distribution, the light-band distribution, and maintain compatibility with it, so you won't have a fork anymore. So things that they build would be additive to Scala, but it'd be based on the current Scala 2.11, I don't know what the last release is, or 2.12 when it comes out. Can you give us some previous stuff in cool coming in the language itself? It seems that all these packaging, modernizing stuff is, any community coming anytime soon, or something like that? First off, I'm not qualified to really tell you what's coming next. I could tell you what's in 2.12. 2.12 was all about making it completely compatible with Java 8 and making it work better in the Java environment. We did a lot of translation work before in Scala to make it work on the JVM. Now that Java and the JVM support some of the things that have been in Scala for a long time, we don't have to do that anymore. So there was a lot of work in 2.12 to just clean up the library, clean up the compiler, to not do all these machinations that used to have to be done. 2.13 will have a lot of new stuff in it. And there is a, I don't know if it's just a blog post or if it's in the SIP stuff, but there is a blog post that Adrienne wrote to kind of outline some of the things coming in 2.13. I encourage you to read that. I can't even rattle off any of them, sorry. There's some interesting things. And some of which come from the guys at type level. You know, they've done a good job of contributing code, but also giving us ideas. Demetri. My question is about Apache Spark. I know that IBM made some kind of huge investment into this technology. And could you please describe the relationships between LightBand and Berkeley and Databricks and IBM as well as in Newster? Well, Spark obviously has really exploded on the market. You know, it's really only a three-year-old project. And now people don't even talk about doing things when that produce for new projects, right? And Spark is bigger than just one piece of software. We've been involved from before it was even a project, before it was something you could find. It was the Amplav guys were working with LightBand because it's written in Scala. And there were things in Scala that they needed us to do. So Scala 2.11 actually had some functionality that was specifically for Spark. In the REPL, there was a bunch of stuff we did in the REPL for the guys at Databricks. So once they announced the project and the company was launched, our involvement was still there, but they had a company now and they had funding and they could do a lot of work. They came back to us with only requests around Scala. That continues today. But Spark is much bigger than Databricks. Spark is, as you said, IBM, Portland Works, Cloudera. Last night, I looked, there were 12 different vendors or companies who contributed to Spark. So not just Databricks. Databricks still happens to have most of the engineers, but Databricks is building data scientists tools and not focused on just the core of Spark as much as they are that. Our relationship is to make sure that Scala really works well with that. And the Scala API is fully supported. So you can use Java with Spark, right? You don't have to use Scala. We make sure that the Scala interface always works. And then whenever there's a problem in Scala that is represented or shows up in Spark, we have to fix it. We have to deal with that. IBM happens to be very heavily invested in it. They're building all their analytics stuff on top of Spark. And they happen to be using the entire LightBend platform to do things. Excuse me. What's your take on managing open source projects? So for example, you mentioned that Playaka owned by LightBend and for example, Spark is Apache project. So between these two. Yeah, so I have a lot of history with Apache. I got involved with Apache in 2000. So Apache started in 1996 essentially, but 98 when I really became known. Apache is a great place to not only get lots of community involvement, but to see projects grow into other projects. So sort of see the project that ends up becoming more than that. The downside to it is, is that it's really hard to keep a individual team focused on a goal on getting something delivered. So if you think about Spark, they didn't go to Apache until Spark 1.0 was done. So it was completely built inside of AMP Labs. Thank you. And then brought to Apache. And I spent time with Matei and the team over there before they made that decision just to understand the consequences of it, right? I think it was the right thing to do. They had to, because all the Hadoop stuff was already in Apache. And that's the second part of the question you have to answer is, what's your technology's ecosystem like? Where does it live? And what other technology is gonna be used around it? If you looked at Aaka or Playaka in particular three years ago, there was not a lot of other open source projects that depended on it. Now there are plenty. I mentioned Flink, even Spark has a little bit of Aaka in it. So it's changed in kind of its ecosystem around it. But when I got to the company, it was a standalone project and it made sense for us to keep it that way. And we had some goals for it that I and Jonas and others were nervous that Apache wouldn't really allow us to do. Because you lose control when you put it into Apache. There's a ton of benefit, but you lose control, right? You now have a community that gets to be involved in it. So my opinion is you have to know where's your technology gonna live? What's it gonna be used with? Do you have the wherewithal and the investment to actually move your project from inception or idea all the way to something real on your own? If not, then Apache is a great place to take it or Eclipse or Linux Foundation or one of the other ones. But if you do have the ability, then there's not any hindrance to doing it yourself as long as you allow communities to get involved. And if you look at our projects, today play has the most external contributions. Probably 60% of the code comes from somebody outside of the company. Then next is Scala. Scala happens to be, well, EPFL, if you take them out of the equation, it's still probably 30% of it is coming from outside. ACA has the least, but we're changing that. I don't know if you've seen the Alpaca project, which is a new announced community effort. Probably 10, 12% of ACA comes from the outside. Maybe a little bit more, but not much. And it's both a combination of the way the team works, but also just the fact that there aren't that many people interested in contributing to ACA. Lagom, which is new for us, today only has about 10%, but we expect it to be like play, where it's gonna be more than half comes from community members, individuals. We certainly welcome people to contribute. All things from LightBent are under the Apache license. So you're never gonna have a GPL or other bullshit licenses that make it so it's impossible for you to do whatever you want with the code. So you all. So what's the plan for ACA? You consider it done that you just don't want to develop it anymore? No, lots of development around ACA. Around streaming obviously was a big investment for ACA streams, clustering prior to that. And there will be other things that you'll see come from us. What I meant is that when we started it, we didn't think we could get very far if we'd have put it into Apache. Could we now? Sure, do we need to? I don't feel like we need to, but there might be a time in the future where it makes sense. Good question. It's not an easy answer. I mean, literally ask ourselves that all the time about the projects. Does it make sense to keep this to ourselves or take it to Apache? Anybody here who uses Spring, right? Spring's not an Apache, it's Apache license, but it's all controlled by the pivotal guys, always has been. As a library developer for Scala, so when I develop the library, I have to target the versions of the Scala, like I have to produce the artifacts for these versions, my two versions. So we're talking as a vision to simplify the life of it in a library developer. Yeah, you heard of Tasty? Is it Tasty? I always get the name wrong. I think it's Tasty. Anyway, it's an abstraction layer between Dottie and the core compiler. That is one of the objectives of Dottie. I don't think it's not explicit in that we will always allow for you to build the one and then it'll be able to be run or compiled two different versions of Scala. It's a great question for Martin or for Adrian or somebody. I'm happy to ask it for you if you want, but I don't know the answer, except to say that there is a stated goal to make it easier to have. Speaking of the facts, the libraries keep changing. The value proposition of the white ones are now needed is lost because they change this. They cannot change whether they can change too easily. Yeah, so I can give you the answer Adrian would give you and that is that we've, for the last three years, been investing to try to rationalize the library to something that's gonna be consistent going forward. So put things in modules, put things outside the core so that they can be added as needed and leave the core alone. Get it to where it can be maintained going forward and can be something that you can depend on. So it's been a heavy investment from LightBend and from the community, but LightBend really spent a ton of energy in the last three years on just that. And Dottie introduces another complexity as well as possibility for addressing that. Because we have seen this complexity in Scala base, so how do we increase the complexity? The goal is the opposite, to not increase it at all. I say it increases it only because it's also not gonna be binary compatible with Scala 2.x, right? So that's the complexity side of it. But it should be easier going forward from that point. The second point is about data structures and optimization. Keep computing that the developer tech is being keyed because it's so slow. And even the R10 data structures are like, we need data types at the wrong time, so is there any optimization that you would need to that? Yes, does it address your specific needs? I don't know. But yes, lots of optimizations in the compiler and dealing with everything from data types to anything else that we can find. So there's the incremental compiler probably has the most improvement. If you haven't played with that, it's gained a lot of performance improvements, but also just not as many bugs, not as many issues that you used to run into. I'm happy to take your questions and send them directly to the right person. I don't wanna try to give you answers, but if Adrian or one of the guys on his team could give you a better answer, I'm sure they would. And the nice joke is that Scala compiler minus Bitcoin under the hood. That's your monetizing strategy. Okay, any other questions? Well, thank you. Oh, sure, sorry. I'm sure there is one more. I need just one last question. So we can wrap up. Okay, actually I have a question. Sure. And... Okay, thank you for... How do you guys hire our engineers? Like, let's say I'm Scala contributor, are you going to hire me because I need contributions? How do you do it? Yeah, I mean, certainly historically, when we wanted to add to the teams, the individual teams, we looked at who had made contributions. Who seemed interested in contributions are just code contributions. You answered questions on Stack Overflow or on the forums. If you look at the engineers that we've hired in Play and Acca, they've been individuals that were known in the community. They either were involved through code or through responses or speak at conferences or all the above, right? But we've also shifted in our thinking that I mentioned earlier, we need Java. We need people with Java experience and not Scala that can actually answer not only questions to our customers around Java, but actually make sure that we support Java, right? That Acca does a great job of providing an API for Java and Play and Lagoam and all the other technologies. So, we've hired a number of engineers. Try to think of a number. I think we're about seven this year so far, engineers. And four of them are not Scala developers at all. Now, they're learning Scala because we write things in Scala, but they come with a Java background. We're, I think I mentioned earlier, we're in 18 countries. We hire people where they're at. We literally look for the talent that can help us with the need that we have. And the teams, there's no single team all in one location. The Acca team used to be, but they're very distributed now. The Play team used to be all in Australia and now it's Australia, New Zealand and California. So, we're very distributed. 105 people in 18 countries, not something I brag about, but because obviously it's operationally tough, but it shows what we mean when we say we hire where they're at. We don't force you to come move to San Francisco. Now, if you wanna move, happy to have you in San Francisco too, but it's not a requirement. And we have job openings, lots of them. So, I think I saw nine postings for engineers on our site just the other day. So, we're looking for technical leads, looking for Java developers, fast data developers, lots of people. And then our customers, one of the things we're very proud of is we promote our customers' job positions. So, you can see, I don't know if PayPal has any more up there, but they used to have some job site, or job postings on our site. Lots of companies hiring, right? Asking for people that have skills using our technology. Sir, just one thing. And with the community as well, I just wanted to take a note as well. Bay Web has also open sourced Scala. I mean, on top of Scala, we have made a framework called Scopes. That's right. Yeah, we've heard about that. So, it's basically, it's built on top of a cup, but with some customizations, which PayPal says could be good standards, right? So, we have open sourced it. Maybe you guys can try it out for building large-scale web applications. So, you just wanted to let you know as well. Sir, you're such a funny guy. Why they use the Spray instead of using I can answer this question. Because the first versions of Scopes were before HTTP was introduced. Oh, okay, fine. And from the next version of Scopes, there will be no compatibility with Spray. I mean, we are more, we are emigrating. I have just stuck it, but they just wanted to let the community and maybe... Yeah, no. Thank you. Yeah, I think last time we counted, which is now about nine months ago, there was about 120 projects, open-source projects built around the Scala ecosystem, around Aka, around Play, around Scala, that are available. They're open-source. Of course, a lot of them come from Twitter and LinkedIn and Morgan Stanley's open-source one. Goldman Sachs has a couple. But always looking for more contributions from the community. We need to do a better job as a company of promoting those, you know, that these are out there. All right, thank you very much.