Why Quarkus?

One size rarely fits all. I've written about this a number of times, for instance on the topic of extended transactions. In the world of building architecture that rule applies too or we'd all be living in caves! The Red Hat/JBoss middleware developer strategy for many years has recognised this fact and we support the frameworks and associated stacks for a wide variety of developers to use when building the next generation of microservice-based applications. Because polyglot is the normal situation today it does not just focus on Java, hence why Node.js is in there. Furthermore, not all new applications will be build from scratch; there has to be a way for existing applications to evolve and similarly for existing developers to evolve their skills rather than having to start from scratch.

As anyone who has been in this industry long enough knows, existing investments remain with us for years (decades in many cases). We can’t just throw them out the window when something new comes along. Neither can we throw the people out the window! Therefore, appealing to so-called brownfield developers is critical because it allows them to leverage their existing skills and key knowledge which likely has built up over many years. Brownfield can include:

• building new services and applications which require/leverage/integrate with existing systems but where the new components are developed in some new framework or approach;
• evolving existing systems, components and services built with mature (I hate "legacy") frameworks and stacks towards newer styles. One example of this would be the evolution of CORBA to J2EE.

So whilst it might look like adding Quarkus to the mix confuses things, it really doesn’t, or at least it shouldn’t and here’s why: there’s a spectrum of developers and applications and our approach attempts to cover the important areas of that spectrum. Specifically there's no one tool or framework right for the entire application or developer and you’ll need some or all of Quarkus (remember, it combines [will combine] serverless with Camel-K/Fuse, our core services on Kubernetes, such as [xPaaS] SSO, transactions, messaging, and uses Eclipse Vert.x for reactive and Eclipse MicroProfile/SmallRye), with EAP/WildFly if you need Java EE/Jakarta EE. And crucially, wherever your app is developed or deployed, they will be able to communicate and interact seamlessly as if developed with the same technology stack.

We’ll be talking more about how this all comes together in the coming weeks and months but another important point to remember is that we’re driving this upstream first, as we always do within JBoss/Red Hat. In fact Ken Finnigan's recent blog about the future of Thorntail is one of those important next steps. So if you want to get involved and help influence the technical direction please do! There are multiple entry points, i.e., you don’t need to start with Quarkus if you are more interested in Keycloak, or WildFly or Narayana (yeah!)

Containerless Microservices?

A few weeks ago I wrote about containerless development within Java. I said at the time that I don't really believe there's ever the absence of a container in one form or another, e.g., your operating system is a container. Then I wrote about containers and microservices. Different containers from those we're used to in the Java world, but definitely something more and more Java developers are becoming interested in. However, what I wanted to make clear here is that in no way are microservices (aka SOA) tied to (Linux) containers, whether Docker-based or some other variant.

Yes, those containers can make your life easier, particularly if you're in that DevOps mode and working in the Cloud. But just as not all software needs to run in the Cloud, neither do all services (whether micro or macro) need to be deployed into a (Linux) container. What I'm going to say will be in terms of Java, but it's really language agnostic: if you're looking to develop a service within Java then you already have great tools and 3rd party components to help you get there. The JVM is a wonderful container for all of your services that has had many years of skilled development within it to help make it reliable and perform. It also runs on a pretty much every operating system you can mention today and hardware ranging from constrained devices such as the Raspberry Pi, up to and including mainframes.

In the Java world we have a rich heritage of integration tools, such as Apache Camel and HornetQ. The community has built some of the best SOA tools and frameworks anywhere, so of course Java should be one of the top languages in which to develop microservices. If you're thinking about developing microservices in Java then you don't have to worry about using Linux containers: your unit of failure is the JVM. Start there and built upward. Don't throw in things (software components) that aren't strictly necessary. Remember what Einstein said: "Everything should be made as simple as possible, but not simpler."

However, as I said earlier, the Linux container can help you once you've got your microservice(s) up and running. Developing locally on your laptop, say, is unlikely to be the place where you want to start with something like Docker, especially if you're just learning how to create microservices in the first place. (Keep the number of variables to a minimum). But once you've got the service tested and working, Docker and its like represent a great way of packaging them up and deploying them elsewhere.