Screaming in the Cloud - Azul and the Current State of the Java Ecosystem with Scott Sellers

Episode Date: September 20, 2022

About ScottWith more than 28 years of successful leadership in building high technology companies and delivering advanced products to market, Scott provides the overall strategic leadership and visionary direction for Azul Systems.Scott has a consistent proven track record of vision, leadership, and success in enterprise, consumer and scientific markets. Prior to co-founding Azul Systems, Scott founded 3dfx Interactive, a graphics processor company that pioneered the 3D graphics market for personal computers and game consoles. Scott served at 3dfx as Vice President of Engineering, CTO and as a member of the board of directors and delivered 7 award-winning products and developed 14 different graphics processors. After a successful initial public offering, 3dfx was later acquired by NVIDIA Corporation.Prior to 3dfx, Scott was a CPU systems architect at Pellucid, later acquired by MediaVision. Before Pellucid, Scott was a member of the technical staff at Silicon Graphics where he designed high-performance workstations.Scott graduated from Princeton University with a bachelor of science, earning magna cum laude and Phi Beta Kappa honors. Scott has been granted 8 patents in high performance graphics and computing and is a regularly invited keynote speaker at industry conferences.Links Referenced:Azul: https://www.azul.com/

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. I come bearing ill tidings. Developers are responsible for more than ever these days.

Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDEs, repos, and pipelines. Snyk integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, and more, as well as things you're likely to actually be using. Deploy on AWS, secure with Snyk, learn more at snyk.co.screen.

That's s-n-y-k dot c-o slash screen. This episode is sponsored in part by our friends at aws app config engineers love to solve and occasionally create problems but not when it's an on-call fire drill at four in the morning software problems should drive innovation and collaboration not stress and sleeplessness and threats of violence. That's why so many developers are realizing the value of AWS AppConfig feature flags. Feature flags let developers push code to production, but hide that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development.

You can seamlessly incorporate AppConfig feature flags into your AWS or cloud environment and ship your features with excitement, not trepidation and fear. To get started, go to snark.cloud slash appconfig. That's snark.cloud slash app config. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest on this promoted episode today is Scott Sellers, CEO and co-founder of Azul. Scott, thank you for joining me. Thank you, Corey. I appreciate the opportunity and talking to you today. So let's start with what you're doing these days. What is Azul? What do you folks do over there? Azul is an enterprise software and SaaS company that is focused on delivering more efficient Java solutions for our customers around

the globe. We've been around for 20 plus years and as an entrepreneur we've really gone through various stages of different growth and different dynamics in the market. But at the end of the day, Azul is all about adding value for Java-based enterprises, Java-based applications, and really endearing ourselves to the Java community. This feels like the sort of space where there are an awful lot of great business cases to explore. When you look at what's needed in that market, there are a lot of things that pop up. The surprising part to me is that this is the direction that you personally went in. You started your career as a CPU architect, to my understanding. You were then one

of the co-founders of 3DFX before it got acquired by NVIDIA. You feel like you've spent your career more as a hardware guy than working on the SaaS side of the world. Is that a misunderstanding of your path, or have things changed, or is this just a new direction? Help me understand how you got here from where you were. I'm not exactly sure what the math would say, because I continue to can't figure out a way to stop time. But you are correct that my academic background, I was an electrical engineer at Princeton and started my career at Silicon Graphics. And that was when I did a lot of fantastic and fascinating work building workstations and high-end graphics systems,

you know, back in the day when Silicon Graphics really was the who's who here in Silicon Valley. And so a lot of my career began in the context of hardware. As you mentioned, I was one of the founders of a graphics company called 3DFX that was one of, I think, arguably the pioneer in terms of bringing 3D graphics to the masses, if you will. And we had a great run on that. That was a really fun business to be a part of just because of what was going on in the 3D world. And we took that public and eventually sold that to NVIDIA. And at that point, my itch, if you will, was really learning more about the enterprise segment.

I'd been involved with professional graphics with SGI. I'd been involved with professional graphics with SGI, had been involved with consumer graphics with 3DFX. And I was fascinated just to learn about the enterprise segment. And I met a couple of people through a mutual friend around the 2001 timeframe. And they started talking about this thing called Java. And, you know, I, of course, heard about Java. But as a consumer graphics guy, didn't have a lot of knowledge about it or experience with it. And the more I learned about it, recognized that

what was going on in the Java world and credit to Sun for really creating, obviously, not only language, but building a community around Java and recognize that new evolutions of developer paradigms really only come around once a decade, if not then, and was convinced and really got excited about the opportunity to ride the wave of Java and build a company around that. One of the blind spots that I have throughout the entire world of technology, and to be fair, I have many of them. But the one most relevant to this conversation, I suppose, is the Java ecosystem as a whole. I come from the background of being a grumpy Unix sysadmin

because I've never met a happy one of those in my entire career. And as a result, scripting languages is where everything that I worked with started off. And on the rare occasions I worked in Java shops, it was great. Here, we're going to go, here's a war file. Go ahead and deploy this with Tomcat

or whatever else people are going to use. But basically, don't worry your pretty little head about that. At most, I have to worry about how to configure a heap or whatnot. But it's from the outside looking in, not having to deal with that entire ecosystem as a whole. And what I've seen from that particular perspective is that every time I start as a technologist or even as a consumer trying to install some random

software package from the depths of the internet, and I have to start thinking about Java, it always feels like I'm about to wind up in a confusing world. There are a number of software packages that I installed back in, I want to say, the early 2010s or whatnot. Oh, you need to have a Java runtime installed on your Mac, for example. And, okay, going through Oracle's site, do I need the JRE? Do I need the JDK? Oh, there's OpenJDK, which kind of works, kind of doesn't. Amazon got into the space with Coreto, which, because that sounds nothing whatsoever like Java,

but strange names coming from Amazon is basically par for the course for those folks. What is the current state of the Java ecosystem for those of us who have basically the closest we've ever gotten is JavaScript, which is nothing alike except for the name? And, you know, frankly, given the protection around the name Java, and, you know, that is a trademark that's owned by Oracle, it's amazing to me that JavaScript has been allowed to continue to be called JavaScript because as you point out, JavaScript has nothing to do with Java per se. Well, one thing they do have in common,

I found out somewhat recently, is that Oracle also owns the trademark for JavaScript. Ah, there you go. Maybe that's why it continues. They are basically three law firms in a trench coat masquerading as a tech company some days. Right. But anyway, it is a confusing thing because I think arguably JavaScript, by the numbers, probably has more programmers than any other language in the world, just given its popularity

as a web language. But to your question about Java specifically, it's had an evolving life. And I think the state where it is today, I think it's in the most exciting place it's ever been. And I'll walk you through, you know, kind of why I believe that to be the case. But Java has evolved over time from its inception back in the days when it was called, I think it was Oak, when it was originally conceived at Sun and eventually branded as Java. And at the time, it truly was owned by Sun, meaning it was proprietary code. It had to be licensed. And even though Sun gave it away in most cases, it still, at the end of the day, was a commercially licensed product, if you will, and platform. And if you think about today's world, it would not be conceivable to create something that became so popular with programmers

that was a commercially licensed product today. It almost would be mandated that it would be open source to be able to really gain the type of traction that Java has gained. And so, even though Java was really garnering interest, you know, not only within the developer community, but also amongst commercial entities, right? Everyone in the era now I'm talking about is around the 2000 era, all of the major software vendors, whether it was obviously Sun, but then you had Oracle, you had IBM, companies like BEA were really starting to blossom at that point. It was a, you know, you could almost not find a commercial software entity that was not backing Java, but it was still all controlled by Sun. And all that success ultimately led to a strong outcry from the community saying,

this has to be open sourced. It's too important to be beholden to a single vendor. And that decision was made by Sun prior to the Oracle acquisition. They actually open sourced the Java runtime code, and they created an open source project called OpenJDK. And to Oracle's credit, when they bought Sun, which I think at the time, when you really look back, Oracle really did not have a lot of track record, if you will, of being involved with an open source community. And I think when Oracle acquired Sun, there was a lot of skepticism as to what's going to happen to Java. Is Oracle going to make this thing, you know, back to the old days, proprietary Oracle, et cetera. And really...

What it used to do is being heartbroken over Solaris at that point to pay too much attention to the Java stuff. But it felt like it was sort of the same pattern repeated across multiple ecosystems. Absolutely. And even though Sun had also open-sourced Solaris with the OpenSolaris project, that was one of the kinds of things that it was still developed very much in a closed environment. And then they would kind of throw some code out into the open world and no one really ran OpenSolaris because it wasn't fully compatible with Solaris. And so that was a faint attempt, if you will. But Java was quite different. It was truly all open sourced. And the big difference that, and again, I give Oracle a lot of credit for this because this was a very important time in the evolution of Java that Oracle maintained Sun's commitment to not only continue to open source Java, but most importantly, develop it in the open community. And so, you know, again, back in this is the 2008, 9, 10 timeframe,

the evolution of Java, the decisions, the standards, you know, what goes in the platform, what doesn't, decisions about updates and those types of things, that truly became a community-led world and all done in the open source. And credit to Oracle for continuing to do that. And that really began the transition away from proprietary implementations of Java to one that, very similar to Linux, has really thrived because of the true open source nature of what Java is today.

And that's enabled more and more companies to get involved with the evolution of Java. If you go to the OpenJDK page, you'll see all of the not only incredibly talented individuals that are involved with the evolution of Java, but again, a who's who and pretty much every major commercial entity in the enterprise software world is also somehow involved in the OpenJDK community. And so it really is a very vibrant, evolving standard. And some of the tactical things that have happened along the way in terms of changing how versions of Java have released still also very much in the context of maintaining compatibility and finding that careful balance of evolving the platform, but at the same

time recognizing that there is a lot of Java applications out there, so you can't just take a right-hand turn and forget about the compatibility side of things. But we as a community overall, I think, have addressed that very effectively, and the result has been now I think Java is more popular than ever and continues to, we liken it kind of to the mortar and the brick walls of the enterprise. It's a given that it's going to be used certainly by most of the enterprises worldwide today. There's a certain subset of folk who are convinced that Java, oh, it's this legacy programming language and nothing modern or forward-looking is going to be built in it.

Yeah, those people generally don't know what the internal language stack looks like at places like, oh, I don't know, AWS, Google, and a few others. It is very much everywhere, but it also feels on some level like it's a bit below the surface level of awareness for the modern full-stack developer in some respects, right up until suddenly it's very much not. How is Java evolving in a cloud these days? Well, what we see happening, you know, this is true for, you know, I'm a techie, so I can talk about other techies. I mean, as techies, we all like the new thing, right? I mean, it's not that exciting to, you know, talk about a language that's been around for 20 plus years. But that doesn't take away from the fact that we still all use keyboards. I mean, no one really talks about what keyboard they use anymore, unless you're really into keyboards.

But at the end of the day, it's still a fundamental tool they use every single day. And Java is kind of in the same situation. The reason that Java continues to be so fundamental is that it really comes back to kind of reinventing the wheel problem. Are there other languages that are more efficient to code in? Absolutely. Are there other languages that have some capabilities that Java doesn't have? Absolutely. But if you have the ability to reinvent everything from scratch, sure, go for it. And you also don't have to worry about, well, can I find enough programmers in this new hot language? Okay, good luck with that. You might be able to find dozens, but when you

need to really scale a company into thousands or tens of thousands of developers, good luck finding everyone that knows whatever your favorite hot language of the day is. Required. Six years experience in a four-year-old language. It's hard to find that sometimes. Right. And the reality is that really no application ever is developed from scratch. Even when an application is, quote, new, immediately what you're using is frameworks and other things that have been written long ago and proven to be very successful. And disturbing amounts of code copying and pasting

from Stack Overflow, but that's one of those impolite things we don't say out loud very often. That's exactly right. So nothing really is created from scratch anymore. And so it's all about building blocks. And this is really where the snowball of Java is difficult to stop because there is so much third-party code out there. And by that, I mean, you know, open source, commercial code, et cetera, that is just so leveraged and so useful to very quickly be able to take advantage of and get, you know, allow developers to focus on truly new things, not reinventing the wheel for the hundredth time. And that's what's kind of hard about all these other languages is catching up to Java with all of the things that are immediately available for

developers to use freely, right? Because most of it's open source. That's a pretty fundamental catch-22 about when you start talking about the evolution of new languages. I'm with you so far. The counterpoint, though, is that so much of what we're talking about in the world of Java is open source. It is freely available. The OpenJDK, for example, says that right on the tin.

You have built a company and you've been in business for 20 years. I have to imagine that this is not one of those stories where, oh, all the things we do, we give away for free, but that's okay. We make it up in volume. Even the venture capitalist mindset tends to run out of patience on those kinds of timescales. What is it you actually do as a business that clearly obviously delivers value for customers, but also results in being able to meet payroll every week? Right, absolutely. And I think what time has shown is that with one very notable exception, a very successful

succession example being Red Hat, there are very, very few pure open source companies whose business is only selling support services for free software. Most successful businesses that are based on open source are in one way, shape, or form adding value-added elements. And that's our strategy as well. The heart of everything we do is based on free code from OpenJDK. And we have a tremendous amount of business that we are following the Red Hat business model where we are selling support and long-term access and a huge variety of different operating system configurations, older Java versions, still all free software though, right? But we're selling support services for that. And that is, in essence, the classic Red Hat business model. And that business

for us is incredibly high growth, very fast moving. A lot of that business is because enterprises are tired of paying the very high price to Oracle for Java support, and they're looking for an open source alternative that is exactly the same thing, but comes in pure open source form and with a vendor that is as reputable as Oracle. So a lot of our business is based on that. However, on top of that, we also have value-added elements. And so our product that is called Azure Platform Prime

is rooted in OpenJDK. It is OpenJDK, but then we've added value-added elements to that. And what those value-added elements create is, in essence, a better Java platform. And better in this context means faster, quicker to warm up, elimination of some of the inconsistencies of the Java runtime in terms of this nasty problem called garbage collection, which causes applications to kind of bounce around in terms of performance limitations. And so creating a better Java is another way that we have monetized our company is value-added elements that are built on top of OpenJDK. And I'd say that part of the business

is very typical for the majority of enterprise software companies that are rooted in open source. They're typically adding value-added components on top of the open source technology. And that's our similar strategy as well. And then the third evolution for us, which again is very tried and true, is evolving the business also to add SaaS offerings. So today, the majority of our customers, even though they deploy in the cloud, they're still customer managed. And so they're responsible for where do I want to put my Java runtime? I'm building out my stack, et cetera, et cetera. And of course, that could be on-prem, but like I mentioned, the majority are in the cloud.

We're evolving our product offerings also to have truly SaaS-based solutions so that customers don't even need to manage those types of stacks on their own anymore. On some level, it feels like we're talking about two different things when we talk about cloud and when we talk about programming languages. But increasingly, I'm starting to see across almost the entire ecosystem that different languages and different cloud providers are in many ways converging. How do you see Java changing as cloud native becomes the default rather than the new thing? Great question. And I think the thing to recognize about really most popular programming languages today, I can think of very few exceptions. These languages were created, envisioned, implemented, if you will,

in a day when cloud was not top of mind. And in many cases, certainly in the case of Java, cloud didn't even exist when Java was originally conceived, nor was that the case when other languages such as Python or JavaScript or on and on. And so rethinking how these languages should evolve in the very much the context of a cloud native mentality is a really important initiative that we certainly are doing. And I think the Java community is doing overall and how you architect not only the application, but even the Java runtime itself can be fundamentally different if you know that the application is going to be deployed in the cloud. And I'll give you an example specifically in the world of any kind of runtime-based language. And JavaScript is an example of that.

Python is an example of that. Java is an example of that. Python's an example of that. Java is an example of that. And all of those runtime-based environments, what that basically means is that when the application is run, there's a piece of software that's called the runtime that actually is running that application code. And so you can think about it as a middleware piece of software that sits between the operating system and the application itself. And so that runtime layer is common across those languages and those platforms that I mentioned. That runtime layer is evolving, and it's evolving in a way that is becoming more and more cloud native in its thinking. The process itself of actually taking the application, compiling it

into whatever underlying architecture it may be running on. It could be an x86 instance running on Amazon. It could be, for example, an ARM64, which is Amazon has compute instance now that are based on an ARM64 process that they call Graviton, which is really also kind of altering the price performance

of the compute instances on AWS platform. That runtime layer magically takes an application that doesn't have to be aware of the underlying hardware and transforms that into a way that can be run. And that's a very expensive process. It's called just-in-time compiling. And that just-in-time compilation in today's world, which wasn't really based on cloud thinking, every instance, every compute instance that you deploy, that same JIT compilation process is happening over and over again. And even if you deploy 100 instances for scalability, every one of those 100 instances is doing that same work. And so it's very inefficient and very redundant.

Contrast that to a cloud-native thinking. That compilation process should be a service. That service should be done once the application, you know, one instance the application is actually run and the other 99 should just reuse that compilation process and that shared compiler service should be scalable and should be able to scale up when applications are launched and you need more compilation resources and then scaled right back down when you're through with the compilation process and the application is more

moving into the you know to the runtime phase of the application life cycle and so these types of things are areas that we and others are working on in terms of evolving the Java runtime specifically to be more cloud native. This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you want to learn more about how they view this, check out their blog. It's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit sysdig.com and tell them that I sent you.

That's S-Y-S-D-I-G. com. And my thanks to them for their continued support of this ridiculous nonsense. This feels like it gets even more critical when we're talking about things like serverless functions across basically all the cloud providers these days, where there's the whole setup, everything in the stack, get it

running, get it listening, ready to go. To receive a single request, then shut itself down. It feels like there are a lot of operational efficiencies possible once you start optimizing from a starting point of, yeah, this is what that environment looks like, rather than a big metal server sitting in a rack 15 years ago. Yeah, and I think the evolution of serverless appears to be headed more towards serverless containers as opposed to serverless functions. Serverless functions have a bunch of limitations in terms of when you think about it in the context of a complex microservices-based deployment framework, it's just not very efficient

to spin up and spin down instances of a function if that actually is any sort of performance or latency sensitive type of applications. If you're doing something very rarely, sure, it's fine. It's efficient, it's elegant, et cetera. But any sort of thing that has real girth to it, and girth probably means that's what's driving your application infrastructure costs. That's what's driving your Amazon bill every month. Those types of things typically are not going to be great for starting and stopping functional instances. And so serverless is evolving more towards thinking about the container itself, not having to worry about the underlying operating system or the instance on Amazon that it's running on. And that's where we see more and more

of the evolution of serverless is thinking about it at a container level as opposed to a functional level. And that appears to be a really healthy, steady state. So it gets the benefits of not having to worry about all the underlying stuff, but at the same time, it doesn't have the downside

of trying to start and stop functional instances at a given point in time. It seems to me that there are really two ways of thinking about cloud. The first is what I think a lot of companies do their first outing when they're going into something like AWS. Okay, we're going to get a bunch of virtual machines that they call instances in AWS. We're going to run things just like it's our data center, except now data transfer to the internet is terrifyingly expensive.

The more quote-unquote cloud-native way of thinking about this is what you're alluding to, where there's, here's some code that I wrote, I want to throw it to my cloud provider, and just don't tell me about any of the infrastructure parts. Execute this code when these conditions are met, and leave me alone. Containers these days seem to be one of our best ways of getting there with a minimum of fuss and friction. What are you seeing in the enterprise space as far as adoption of those patterns go? Or are we seeing cloud repatriation showing up as a real thing? And I'm just not in the right place to see it. Well, I think as the cloud journey evolves, there's no question that in fact, it's even silly to say that cloud is here to stay because I think that became a reality many, many years ago. So

really the question is, what are the challenges now with cloud deployments? Cloud is absolutely a given. And I think you stated earlier, it's rare that whether it's a new company or a new application, at least in most businesses that don't have specific regulatory requirements, that application is highly, highly likely to be envisioned to be initially and only deployed in the cloud. That's a great thing because you have so many advantages of not having to purchase infrastructure in advance, being able to tap into all of the various services that are available through the cloud providers. No one builds databases anymore.

You're just tapping into the service that's provided by Azure or AWS or what have you. And just that specific example is a huge amount of savings in terms of just overhead and license costs and those types of stuff. And there's countless examples of that. And so those services that are available in the cloud are unquestioned.

So there's countless advantages of why you want to be in the cloud. The downside, however, of the cloud is that at the end of the day, AWS, Microsoft with Azure, Google with GCP, they are making 30% margin on that cloud infrastructure. And in the days of hardware, when companies would actually buy their servers from Dell or HP, et cetera, those businesses are 5% margin. And so where is that 25% going? Well, the 25% is being paid for by the users of cloud. And as a result of that, when you look at it purely from an operational cost perspective, it is more expensive to run in the cloud than it is back in the legacy days, right? And that's not to say that the industry has made the wrong choice because there's so many advantages of being in cloud. There's no doubt about it. And there should be, you know, and the cloud providers deserve to take some amount of margin to provide the services that

they provide. There's no doubt about that. The question is, how do you do the best of all worlds? And there is a great blog by a couple of the partners in Andreessen Horowitz called this the Cloud Paradox. And the Cloud Paradox really talks about the challenges. It's really a catch-22. How do you get all the benefits of cloud, but do that in a way that is not overly taxing from a cost perspective? And a lot of it comes down to good practices and making sure that you have the right monitoring and culture within an enterprise to make sure that cloud cost is a primary thing that is discussed in metric. But then there's also technologies that can help so that you don't have to even think about

what you really don't ever want to do, repatriating, which is about the concept of actually moving off the cloud back to the old way of doing things. So certainly I don't believe repatriation is a practical solution for ongoing and increasing cloud costs. I believe technology is a solution to that. And there are technologies such as our product, Azure Platform Prime, that in essence allows you to do

more with less, right? Get all the benefits of cloud, deploy in your Amazon environment, deploy in your Azure environment, et cetera. But imagine if instead of needing 100 instances to handle your given workload, you could do that with 50 or 60. Tomorrow, that means that you can start savings. And being able to do that simply by changing your JVM from a standard OpenJDK or Oracle JVM to something like Platform Prime, you can immediately start seeing the benefits from that.

And so a lot of our business now and our growth is coming from companies that are screaming under the ongoing cloud costs and trying to keep them in line and using technology like Azure Platform Prime to help mitigate those costs. I think that there is a somewhat foolish approach that I'm seeing taken by a lot of folks, where there are some companies that are existentially anti-cloud, if for no other reason than because if the cloud wins, then they don't really have a business anymore. The problem I see with that is that it seems that their solution across the board is to turn back the clock, where if I'm going to build a startup, it's time for me to go buy some servers in Iraq somewhere and start negotiating with bandwidth providers.

I don't see that that is necessarily viable for almost anyone. We aren't living in 1995 anymore, despite how much some people like to pretend we are. It seems like if there are workloads, for which I agree, cloud is not necessarily an economic fit. First, I feel like the market will fix that in the fullness of time. But secondly, on an individual workload belonging in a certain place is radically different than, oh, none of our stuff should live on cloud. Everything belongs in a data center. And I just think that companies lose all credibility when they start pretending that it's any other way. Well, I'd love to see the reaction of the venture capitalist face when a

entrepreneur walks in and talks about how their strategy for deploying their SaaS service is any other way. Well, I'd love to see the reaction of the venture capitalist face when an entrepreneur walks in and talks about how their strategy for deploying their SaaS service is going to be buying hardware and renting some space in the local data center. Well, there is a good cost control method if you think about it. I mean, very few engineers are going to accidentally spin up an $8 million cluster in a data center a second time just because there's no space left for it. And you're right. It does happen in the cloud as well. It's just, I agree with you completely that as part of the evolution of cloud in general is an ever-improving aspect of cost and awareness of cost and building and technologies that help mitigate that cost. So I think that will continue

to evolve. I think, you know, as you really think about the cloud journey, cost, I would say, is still in early phases of really technologies and practices and processes of allowing enterprises to really get their head around cost. I'd still say it's a fairly immature industry that is evolving quickly, just given the importance of it. And so I think in the coming years, you're going to see a radical improvement in terms of cost awareness and technologies to help with costs that, again, allows you to do the best of all worlds. Because if you go back to the dark ages and you start thinking about buying servers and infrastructure, then you are really getting back to a mentality of, I've got to deploy everything. I've got to buy software for my database. I've got to deploy it.

What am I going to do about my authentication service? So I got to buy this vendor's solution, et cetera. And so all that stuff just goes away in the world of cloud. So it's just not practical in this day and age, I think, to think about really building a business that's not cloud native from the beginning. I really want to thank you for spending so much time talking to me about how you view the industry, the evolution we've seen in the Java ecosystem and what you've been up to. If people want to learn more, where's the best place for them to find you? Well, there's a thing called a website that you may not have heard of. It's really cool. Can I build it in Java? W-W-W. Yeah. Azul website obviously has an awful lot of information about that. Azul is spelled A-Z-U-L. And we sometimes get the question, how in the world did you name a company? Why did you

name it Azul? And it's kind of a funny story because back in the days of Azul, when we thought about, hey, we want to be big and successful. And at the time, IBM was the gold standard in terms of success in the enterprise world. And they were big blue. So we said, hey, we're going to be a little blue. Let's be Azul. So that's where we began. So obviously, go check out our site. We're very present also in the Java community. We're at many developer conferences and talks. We sponsor and run many of what's called the Java user groups, which are very popular 10, 20 person meetups that happen around the globe on a regular basis. And so come check us out and appreciate everyone's time and listening to the podcast today. Noah, thank you very much for spending as much time with me as you have.

It's appreciated. Thanks, Corey. Scott Sellers, CEO and co-founder of Azul. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an entire copy of the terms and conditions from Oracle's version of the JDK. If your AWS bill

keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble