Talking about Micronaut with Graeme Rocher
We at CROZ are huge fans of Spring and are using it since its beginnings in 2003. Although it seemed like a perfect swiss-army knife, we always felt that some things could be easier, especially in web department. Our feelings proved right in 2006 with the advent of Grails – super-simple web framework built on “convention over configuration” principle and Groovy programming language. Grails was all that we were missing in traditional Spring MVC stack and we loved it so much that we have contributed a couple of plugins to Grails community.
Imagine then my luck meeting Graeme Rocher on GOTO Amsterdam 2019!
Graeme is currently working at Object Computing Inc as Project Lead of Grails and most recently as Project Lead of Micronaut framework. Knowing what a revolution Grails was back in the days, I have no doubt that Micronaut will follow Grails path. Once again OCI team recognized shortcomings of the current Spring Boot stack stemming from the nature of cloud environment and provided fantastic alternative. We talked with Graeme about Micronaut features, how it fits into JVM ecosystem and what we can expect from Micronaut in the future.
Graeme, thank you for this chat!
Ivan: Comparing with similar frameworks like Quarkus and Helidon, it seems that you were again the first one to get started in this direction. Just like Grails introduced revolutionary ideas that were later on followed by Spring Boot. Tell us how you continue to be an innovation leader? How did you come up with the idea to develop Micronaut?
Graeme: When you work on a framework like Grails for over 10 years you benefit from obtaining a deep understanding of how modern framework internals work and the various downsides and compromises that need to be made using the technology you have available to you. Frameworks like Spring and Grails are built using reflection and annotation processing done at runtime. Reflection doesn’t come without downsides in terms of memory consumption and runtime processing. Groovy, for example, is a dynamic language built completely on reflection and has higher memory consumption than Java due to this because fundamentally using reflection consumes more memory than not using it. Android tools and frameworks tend to completely avoid reflection for the same reason. So the idea for Micronaut was a natural evolution in terms of trying to understand how we can build a modern framework that has all the features of Spring and Micronaut but without the performance and memory compromises.
Ivan: What do you see as the main comparative advantages of using Micronaut?
Graeme: Micronaut is a great choice if you are after the productivity benefits of frameworks like Spring and Grails, but prefer a leaner and more memory efficient environment. Micronaut also exposes a great API for integrating with compilers in a language neutral way. An example of that is Micronaut’s support for OpenAPI (Swagger) which is processed at compilation time (outputting the appropriate Swagger YAML) instead of at runtime resulting in saving memory as runtime analysis is not necessary.
Ivan: What do you see as the best use cases for Micronaut? What would be main criteria for choosing Micronaut?
Graeme: Microservices, Serverless functions, CLI applications, Message-Driven Microservices are all great fits for Micronaut.
Ivan: How steep (or flat) is Micronaut’s learning curve for somebody experienced in Spring Boot?
Graeme: A design goal of Micronaut was to make the learning curve as flat as possible for Spring and Grails users, so users of those frameworks should have little trouble.
Ivan: Is it possible to use Spring modules in the Micronaut application?
Graeme: The answer is: it depends. Most of Spring can be consumed as a library just like any Java library and of course, you can easily use components like RestTemplate and JdcbTemplate in Micronaut if you choose.
Ivan: What can we expect from Micronaut in the near future?
Graeme: We are wrapping up support for Data access applications with Micronaut Data 1.0 this year and then will be focusing on Micronaut 2.0 which will support HTTP/2, JMS and more.
Ivan: How can people contribute to the Micronaut ecosystem?
Graeme: A good place to start is to look at the issues tagged as “help wanted”.
Ivan: How do you feel about GraalVM? It looks promising but is it production ready?
Graeme: Firstly, GraalVM is a collection of different technologies that include the Truffle language framework, the JIT, Substrate and so on. As of this writing the current version is 19.2.0 which is regarded as production ready by Oracle. One component of GraalVM that is particularly interesting for its applicability in Serverless and Microservices applications is the Substrate Native Image Tool, which is currently an experimental component of GraalVM.
Substrate allows you to compute a Java application into a native machine image using Ahead of Time compilation and closed world analysis resulting in dramatic reductions in startup time and memory consumption. This works nicely with Micronaut since it is easier (but not impossible) to perform closed world analysis in applications that don’t use reflection. This component of GraalVM definitely has huge potential and is exciting technology that has come a long way over the last year or so.
Ivan: Can you tell us who is the real Graeme: Groovy-guy or Java-guy? 🙂
Graeme: Neither I think. I am a JVM-guy and am excited about everything that goes on in the JVM world. 🙂
Ivan: Congratulations on recently being awarded Oracle’s 2018 Groundbreaker Award! Considering your innovation track record so far, are you already preparing something new and revolutionary up your sleeve that we should know about? 🙂
Graeme: We are always trying to innovate and push boundaries on the Micronaut team at Object Computing and I am happy to be one of the people who is in a fortunate enough to be able to work on innovative new technologies like Micronaut and Micronaut Data.
Get in touch
Want to hear more about our services and projects? Feel free to contact us.Contact us