This article is more than 1 year old

IBM Java CTO: Devs shouldn't have to learn Docker, K8s, 30 other things to deploy an app

Big Blue's Duimovich chats cloud and more to El Reg

Index At IBM's Index developer conference in San Francisco, on Tuesday, The Register sat down with Big Blue's Java CTO John Duimovich to talk about the Java programming language, IBM, the cloud and other developer-oriented concerns.

Duimovich made the case for IBM as a cloud platform partner, based on the company's Java expertise. He also argued for Java – 22 years old – as a vital, evolving language.

Oracle, Java's meddling uncle, last year said it would hand over governance of Java EE to the Eclipse Foundation.

For enterprise Java, that means a chance to accelerate the development and deployment of new features and to become more responsive to the needs of corporate developers.

"What they did is they gave control of the evolution of enterprise Java to a foundation," Duimovich explained. "They moved the code itself and the governance. And I think that was in part that acknowledgement of some of the momentum that MicroProfile has had."

MicroProfile is an initiative to make Java EE – or Jakarta EE, assuming the name change vote goes as expected – more suitable for the development of lightweight, composable microservices, as opposed to large monolithic applications.

"This is where the compatible future of cloud Java is being defined," he said. "You're going to see EE evolve to adopt many of these new technologies."

Image from IBM's Index conference

We sent a vulture to IBM's new developer conference to find an answer to the burning question: Why Big Blue?

READ MORE

IBM, said Duimovich, is interested providing support for any language that enough developers want. He said the company sees quite a bit of interest in Node.js, particularly for front-end applications, and more modest interest in Swift now that its ecosystem has become more mature.

"If you have any serious performance needs, Java's your story," he said. "If you want to integrate with all the systems you're going to have to integrate with terms of an enterprise, no question."

Duimovich contends enterprise Java is "actually a pretty interesting space" these days, pointing to developments like reactive programming, where you're dealing with asynchronous code and high event rates for IoT applications.

"Enterprise Java at the Eclipse Foundation is going to drive new features more quickly," he said. "And I think it will also be a more inclusive community that's easier to join."

For IBM, that's an opportunity to build relationships with the open source development community. "Now that IBM is open source, we have a much greater chance to actually engage with developers," he said.

Where once IBM kept its cards close to its vest, now as developer of open source technology, there's far more contact with the development community, which has the potential to translate into new customers.

"This excites me because I've much better contact points, a broader set of developers," he said. "People who may not be IBM customers still are able to interact with us and work with us and then, and hopefully from our perspective, turn into IBM customers because they can buy support and other things."

Embracing open source means opportunities for technical interaction between IBM personnel and outside developers. Duimovich recounts how IBM gave a university course in how to use the OMR technology to build a virtual machine called Base9.

"We got six people instantly who want to work with us because they knew we were doing this," he said, adding that being involved in open source means a better reception from developers.

Obscure bug reports

Open sourcing its JVM hasn't translated into a significant increase in community code contributions yet, but Duimovich voiced appreciation for the obscure bug reports where someone will fix some edge case with a line or two of code.

Seeing Java EE develop at a more rapid pace has pluses and minuses, Duimovich said.

"Developers who are waiting for language features and other stuff won't have to wait three years," he explained, pointing to aspects of Kotlin, Scala, or other languages that may be incorporated into Java EE sooner rather than later.

"Java this year got a shell, a read-eval-print loop (REPL)," he said. "Every other scripting language had that. Java is finally there."

The downside, he said, is that everyone has to move faster just to keep up.

"It's a great time to be a Java developer," he said, "and a VM developer," adding that competition between virtual machines benefits everyone.

Duimovich sees IBM playing a starring role in the cloud optimization of Java. As an example he pointed to VM startup time. A 40-second startup time didn't matter as much when app servers stayed up for months, but you can't have that for containers.

"So we've made both our startup time and ramp up time over 2x better than existing JVMs and we're continuing to focus on that," he said.

IBM's Java VM has also been optimized to return memory when it's not being used. "Our VMs will automatically give the system back memory when we go idle," explained Duimovich.

Reducing a system's memory footprint in the cloud translates to reducing the system's cost. That's not so much of an issue with JVMs that are maxed out all the time.

"But I can tell you from our mainframes and from our deployments, we've seen there's a lot of idle VMs that wake up once in a while," he said.

The most pressing technical issue for Java and containers, said Duimovich, is having Java memory adapt to container sizes, because if you exceed that, it kills the container.

Low level

"You want them to dance as one, so to speak," he explained. "If you reduce the memory in the container, you reduce the memory in Java. Those are the kinds of things we're working on at the low level."

In its effort to reduce the footprint of Java, IBM is also working on moving its JIT compiler outside of the address space and have it as a service.

"That opens up a huge bunch of opportunities for us," said Duimovich, noting that each instance saves 200 to 400 MB of footprint, which is what you want for microservices and moves Java closer to the memory requirements of other languages.

And as a service, he said, it has more visibility across instances, which provides the opportunity to compare performance data in A/B testing.

"The easy way to think about it is if I'm bringing up 100 or 1000 microservices, did every one of them need to compile Object?" he said. "Clearly not. And you can get that with AOT – ahead-of-time compilation static – but then you've giving up some of the things Java can do like dynamic bytecode modification."

Beyond Java, Duimovich expressed interest in making development easier overall by making it more dev and less ops. "The notion that as a developer you'll have to learn Docker, Kubernetes, and 30 other things before you can even deploy an app is something I'd like to get rid of," he said.

Maybe there's a cloud for that. ®

More about

TIP US OFF

Send us news


Other stories you might like