Enterprise Java in the Age of Microservices, Containers and Cloud-Native

Is your Java application ready for the real world? Join Markus Eisele and Natale Vinto, authors of the book “Modernizing Enterprise Java,” and Ana-Maria Mihalceanu, developer advocate at Red Hat, to uncover key ways to modernize your Java application.

 

Intro

Ana-Maria Mihalceanu: Hello, everybody. Welcome to GOTO Book Club. Today, I will be the host, talking to my colleagues, Markus and Natale, who are awesome. I would let them introduce themselves to you. So, let's just take it alphabetically. Markus, go first.

Markus Eisele: Thanks, Ana, for having us. I'm Markus Eisele, obviously based in Germany, living in the wonderful landside of Munich in the northeast. I've been working for Red Hat for two years and this is my second stint. My official title is actually business development manager, but I like to think of myself as a developer strategist. I guess that's all for now. We'll uncover more later. Natale, over to you.

Natale Vinto: Hey, everyone. This is Natale from Italy. I'm a developer advocate here at Red Hat for OpenShift, which is the enterprise Kubernetes from Red Hat. I've been a software engineer, solution architect, working in EMEA for OpenShift. Today, I cover the developer advocacy for OpenShift, so all cloud-native and Kubernetes who are our customer, our community. So, thank you for having me today.

 

​​Steps to migrating your monolithic app to a cloud native model

Ana-Maria Mihalceanu: So great to hear from you. I was so excited to host you today that I almost forgot what's going to be the subject of our conversation today. Natale and Markus are the co-authors of "Modernizing Enterprise Java," which is a concise cloud-native guide for developers. It's a recently released book to help us in modernizing Java applications. We've been hearing a lot about microservices in, I think, the past 10 years. But let me get straight to the point, and even get to the point where we're talking about the painful stuff. In your opinion, what are the key points that we, as developers, should follow when we want to migrate from, let's say, a legacy monolithic application to one that is following the cloud-native model? And any of you can start on this one.

Markus Eisele: Let me start because that's also the chapter order that we wrote the book in. I'm responsible for all the great words and strategy and thinking, and Natale is actually doing the implementation. As in real life, I'm the architect behind this, and Natale is actually putting life and breath into all of this. I think it's not even the right question to ask, right? So, the first question that should be answered, and that might actually not be a question for a developer, it might actually be a question for the business team behind what we're trying to create. We need to understand what the real requirements of an application are.

We've been implementing monolithic applications, host systems even, for the longest time ever and we've been pretty successful. I built some of the largest enterprise Java-based systems in Germany and to my knowledge, they never failed. So the specifications, ultimately, were the right ones. With our time changing significantly, our behaviors changing, our literal toys changing, smart devices, there's a significant shift in what the requirements from a business perspective actually are.

One of my favorite examples is online banking. Every Monday morning, first of the month, half of the population is checking their online accounts. That is pushing a significant load on an application that has not been there before because everybody was literally going to the bank or checking their postbox for everything. So if the requirements, the business personnel, the business teams have ultimately suited to justify something like a distributed application, in the broadest sense, then we can start talking about how to implement these kinds of applications. To me, personally, everything starts at the non-functional requirements, like how do we need to scale? How do we ultimately react to failure? I'm on team business requirements.

Ana-Maria Mihalceanu: Okay, team implementation, what do you have to say, Natale.

Natale Vinto: From an implementation perspective, we have instruments. After the model, we have the theory, and then we have the instrument to start modernizing the application. So, we have basically three approaches that we outline, and we do this also in the book. For modernizing, let's say, monolith and monolithic apps, you can do the rehosting, you can do the replatforming, and then you can do the refactoring. In the implementation part of our book, we went into refactoring. We split the monolith into several microservices, because this is the optimal choice, but it's not always the right choice.

Maybe you just want to modernize some part of it. Maybe you just want to move the monolith into a container or Kubernetes. In the book, we took the approach of starting splitting the monolith into microservice. And from an implementation perspective, we adopted modern Java frameworks such as Quarkus. It's a modern Java framework to develop applications in modern use cases, which is an edge computing or serverless application.

But we also use other frameworks that are popular in the Java ecosystem, like Spring Boot or Reactive Java with Vert.x. So we had an overview of what the Java developer today had to adapt to the modern context of cloud-native, heterogeneous. An app today needs to be really portable across multiple clouds if you want to scale and serve your customers in multiple environments. 

 

When is the monolithic application better?

Ana-Maria Mihalceanu: Thank you, Natale. That was a great answer and it reminded me why microservices are loved by so many teams. When working with the monolith, it's very difficult to introduce change or to produce change and deploy those changes very quickly. And in our modern day, as Markus has mentioned earlier, we need some agility in terms of how we're doing things. We require more flexibility with the applications that we're working with. However, my personal opinion as implementor, I still believe that monolithic applications have their places in the world. And as Markus said everything starts with requirements and especially when you take a look at the non-functional requirements. But in your opinion, are there cases in which the approach of monolithic application is better? And if you have some examples, it would help us greatly.

Markus Eisele: I'm taking this one. There's a rule of thumb. You mentioned that distributed applications have advantages when it comes to developing with different teams, having agile approaches, zero coupling between the services, so it gives you a lot more freedom to ultimately develop. You can have the same kind of freedom in a monolithic application if it's well designed and well crafted. And usually, if we're thinking about monolith, we think about these insanely large applications that need, like, 15 minutes to start, the famous application server days, right. I think if we're not talking about these kinds of monoliths but we're still talking about well architected ones, there's a bunch of nonfunctional requirements that ultimately would point towards a well architected monolith.

One example is the traditional departmental application that does mostly CRUD operations for example. You could basically just use what Enterprise Java gives you, ideally generate your complete persistence, have it rolled out on a famous little desktop PC under somebody's desk and 20 people keep using it and being super productive with it. If you wanna run a worldwide global online shopping site, it's probably not the right choice. It all comes down to what I have to invest ultimately and which architecture to choose. And that's my rule of thumb.

The easier your requirements are in terms of scalability, performance, users, simultaneous users, the more I personally tend to monolithic architecture because it's still easier to develop. In particular if you stick to Enterprise Java. And the more you're breaking out of these smaller functional requirements and non-functional requirements, the more you need to go fully distributed ultimately.

Ana-Maria Mihalceanu: That's a very good point. And speaking about popular applications, all of us are using and loving our browsers, our modular monoliths, because we're having a core in which we're adding extensions and plugins. When we're looking at our IDs, some of them have this type of architecture where they're actually monoliths. They're not necessarily microservices and they still work awesome for all of us and do their job.

Natale, any thoughts about implementing monoliths in real life still? What would be your options in this case? Or would you always go to the distributed part, the least resistance part?

Natale Vinto: We have also seen in open-source projects that microservices are not the right choice all the time. It depends on the context or their functional requirements, as Markus said. I can quote an example. Istio, a popular open-source project for implementing service mesh in Kubernetes, started its control plane as microservice but then they reverted back and they went into a monolith. It was too complicated managing that complexity with microservices that they went back into a monolith. There are use cases where it's still valid but in general, if your application needs to be scaleup and distributed, the microservices approach is still valid even if it's a stateful application. Today there are solutions that help your stateful app to coexist in a more heterogeneous, more distributed work. And that's why we basically cover the whole book into a Kubernetes experience because we thought that the ease and the ecosystem brought historically by application containers like JBoss or GlassFish or WildFly can be also served by Kubernetes.

In the book we outline which of those functional requirements can be covered by Kubernetes and Kubernetes also helps in stateless and also stateful application deployment. And that's why Java developers, Java Enterprise developers today can take benefit from frameworks like MicroProfile, like Quarkus and also the ecosystem from Kubernetes to get the same experience, the same ease of developing applications in business context.

Markus Eisele: What we're seeing across the board and I personally believe this is going to be even more so in the coming years is the stateful application itself on Kubernetes comes with a lot of challenges. In particular, if you put something stateful on something stateless in general. But yes, there's a mix and match. It might actually be a fact that your application doesn't have the same requirements all over. Maybe there's just a certain part that needs scaling. For example, the online account access for the online banking example I made earlier.

Kubernetes is a pretty, pretty great operational platform where you can put all these different workloads on top. The magic is to understand how all these bits and pieces wire together. In particular, while we as seasoned developers also have a high interest in regaining and keeping our existing knowledge. So, and this is totally selfish, I've spent endless hours implementing Enterprise Java APIs and now somebody's coming around the corner telling me to do everything else in Rust or other languages and I'm like, "No. I know my APIs and I know that they've been suiting me pretty well." If you get an opportunity as a developer to reuse your existing skills, for example, on the basis of MicroProfile, like, a subset plus extensions of a full-blown Jakarta EE, that is definitely giving you an advantage in the field. So yes, I think the message here is go for Kubernetes. But think about how to implement something on top of it. And Natale's example was spot on.

So even the core functionality around application building on top of Kubernetes makes these choices day by day. There is not just the one single answer.

 

A concise cloud native guide

Ana-Maria Mihalceanu: True. Speaking about options and trying things, one important thing I loved about your book, I read it and I actually used the examples from it, is that it has chapters with theory explained correlated to the examples and you can find the examples on GitHub. And you can reuse those examples for your own trials and see if they can help you and inspire you into creating your own microservices. I really loved that the examples come together and they do make an app. Probably a lot of the readers want to get more into this approach but don't have a larger scale example. So, kudos to that and for the examples shared there. I think it's good to correlate theory and how it should be to the real life.

Any other goals that you see achieved in the book to becoming more cloud native you'd like to mention?

Natale Vinto: The subtitle is "Concise Cloud Native Guide." It's a starting point to your cloud native journey. This is what we would like to give to our readers that can have a theoretical overview, as you say, Ana, and then also practice. They can be hands-on on Kubernetes locally. The examples are on Minikube which is a local Kubernetes environment for desktop and also, on cloud. We also have an environment called Developer Sandbox for OpenShift which is free to use where you can run all the exercises on this cloud Kubernetes environment.

Markus, correct me if I'm wrong. We wanted to do the alley-oop for all the Java developers to score in this Kubernetes work.

Markus Eisele: Absolutely correct. What was super important to me is to glue all the theories out there. There are amazing books like Sam Newman, Chris Richardson. You can learn everything about how to build a decent microservice application out there. What I was missing mostly is trying to tie these things together, with existing Java specifications with practical examples that ideally were something that hundreds of people have already been trained on and enrich all of this with a little bit of guidance around it. So, I think we spent a significant amount of characters in this book on explaining the migration path forward. The assumption basically is that you have some kind of Java setting you want to conserve, treat as legacy and change it into heritage, take it forward. So, find the right way of building the future for this project.

Making the decisions around migration or rehosting or re-platforming or a complete rewrite ultimately. We are guiding people through all of this but we are also ending in technical examples. I think it's about time to at least say a little kudos to Alex and Madu, two very valued coworkers who built this initial core of the example and they've trained hundreds of Red Hat customers with this example over the last couple of years. It's not super artificial. It actually is a valued resource that we use with customers on a day-to-day basis. Natale put the cream on top and made it look good and glittery ultimately. At the core, this is something very practical. You'll get the full download in a very concise way and you don't have to read millions of pages with all the theory. So, it's kind of iterating.

I want to believe that we did this because of COVID, because all our attention spans ultimately dropped to almost zero. You can even decide how you wanna read this book. Do you wanna read one, three and five from the chapter perspective so you'll get all the theory and all the architecture thoughts around it or do you want to start with Natale's hands-on examples? Then you go to chapters two, four, six and seven. Ultimately, your choice. I have to admit it wasn't a deliberate choice. I think it's something that played out over time. It's amazing to write books with Natale. Somebody who's never written a book might not even remotely feel the pain but there's a famous quote out there. Writing a book is as close as a male can get to having a baby, like giving birth. It is insanely painful to design a cohesive thought structure, and come up with chapters. Natale and I naturally created this separation between the chapters.

I have to admit that I'm comparably proud of this approach. I get my business development people to read my chapters and it helps them. And on the other hand, we can still hand it out to solid rock proven SAs in the field and they also learn a bit. I think that's what I love the most about the book.

Ana-Maria Mihalceanu: Yes, as a reader of technical books, I enjoy reading books that have concise chapters and examples like recipes in them. So, like, correlating theory, not having too much written in the narrative unless the concepts are really tough or new and then have examples correlating with that. And that, at least for myself, has not been something COVID related. It has been something for many years because we're all the time in the hurry to easily learn anything. There's no developer in this world that doesn't want to learn something fast and have a fast learning curve when approaching a new way of development, a new practice. So having a book structured like this is speeding up the learning curve. At least that's my perspective. I also have experience with other technology recipe books that I read the same way and I could get a grasp of the technology only for the areas where I was needing it.

And that was about 10 years ago. Learning fast is something that we want as developers and that's where the book is helping us and has helped me learn all the concepts, acquire the concepts, see the practice and put it to work fast.

 

Tackling the transition from a traditional app to a cloud native app

Ana-Maria Mihalceanu: Speaking about migrations, can you talk to me about the challenges that you've seen when migrating or that transition from the traditional application or vintage application, as I like to call it to the modernized one with generally not so comfortable things to change?

Markus Eisele: Maybe I go first. We have a couple of anonymized customer cases. What we see frequently across the board is applications that are not well architected. Technically speaking, traditional Enterprise Java has the three-layer approach and is more or less artificially constructed out of modules. It's not by design thought of as a domain model underneath. It's mostly very entity driven and from a modularity perspective, comparably technical. Translating this kind of technical monolith into something that is more domain driven is quite a challenge to the point that customers might decide to rewrite things from scratch which could be another challenge. In particular if you look at existing real grown applications, meaning something that has been in service for more than 5 to 10 years, you will absolutely run into situations where you won't find the necessary specification anymore or people left to ultimately implement an application. And it makes it impossible to even refactor something because you don't really know what you're gonna break. There’s usually only very rudimentary test coverage on all of these applications. It's, like, challenges from one to the other but it all starts with what we typically refer to as the spaghetti kind of monolithic application.

On the other hand, I've also seen very well architected and modularized applications. Maybe even on the top of OSGI as a framework. And for these applications, it's really hard to justify the move to something that is stateless because they already scale comparably well and they still would need a complete technical overhaul underneath to rip out these modularity frameworks. Challenges from a technical perspective are mostly due to design or older Java versions even. Basically, preventing you from doing anything modular because you are tied to something that is really specific, proprietary. Natale, anything else comes to mind?

Natale Vinto: I think you outlined many valid use cases for that. And the challenges are also the ones we mention in the book. We have to decide if we want to start modernizing just some piece of the application. If we go into refactoring, we need to estimate the effort for refactoring the whole application or the component. So, I think the analysis phase requires some time and it's the crucial one. It's the step where you decide the approach. In the book we mention the three approaches and if you go into refactoring, as we did, you have the help of frameworks but this means also you need to rewrite the app. There are use cases where this is very valid and there are use cases where it's not valid. Maybe you want just to leave one part of the monolith up and running and you would just lift and shift in a container and you start modernizing the other part that you know is easier to do. This is another approach. We can call it maybe hybrid. You split the complexity and, in your initial analysis you estimate effort for this migration.

I think this initial step is very important, where you do an analysis of what to migrate and what to do and you have all the instruments as we go into the book to start adopting the right approach for you.

Ana-Maria Mihalceanu: That was great. When Markus was mentioning the part with the legacy, with the apps and the architecture, I remembered that when it comes to modular monoliths, some people are having circular dependency between the modules. That shouldn't be happening. That should be independent. But I've seen that back in the day. However, OSGI is a great framework to build modular monoliths but you can still achieve a nice way to have things loosely coupled which I believe is a great point.

So that's one way to look at things. And another way to look at things is dependencies that you have in your app. Natale, you've seen this as well many times, have a lot of interdependencies and dependencies to some libraries that kind of force you to stick with one framework or one version of a framework or platform because of those dependencies. Probably some of them are not always maintained. That's an advantage to open source from my point of view. Always sticking to open sources that are maintained by strong communities is a great advantage.

 

How containers affect the speed of app development & deployment

Ana-Maria Mihalceanu: And speaking about open source and frameworks, what do you think container technology is bringing in terms of affecting speed of development for application development and deployment? How does containerization help you speeding up things for developing an app or in deploying it?

Natale Vinto: Containers are becoming a standard for deploying applications. Today any new application is most of the time a container. Because it's an open standard, it's very important that this is open because any vendor can take the standard and do a hopefully open-source implementation like we do in Red Hat. So, the container is an open standard or an open API which is the open container initiative. You can take this standard and implement it and you have your Docker image, your container image. So, the format is really important. If you think about it, in the past, it was hard to move an application from one site to another site. There was a ZIP file or another Tarball or even an executable. The fat JAR was not there, we had a WAR file, the EAR file. So enterprise archive or web archive.

Java brought some help in universality and portability but that was not enough because of dependencies, as you say. So, the application containers like Tomcat or WildFly were bringing those dependencies but they were also the dependency of the operating system. Today with containers you basically have an operating system that brings you your dependencies and then you have your runtime dependencies, your framework dependencies. It's a very valid approach to start using containers for developing new applications, even porting old applications because you can take advantage of this portability. Your app runs in any cloud, public cloud, private cloud, your workstation or any other place that has a container running.

And I think this is a very, very valid approach and in the book we also cover the container creation of applications from a Java perspective with frameworks like Jib or JKube. You can create a container from Java. You don't need any kind of Docker engine, Docker OS. But we cover the container engine. We mentioned Docker, we mentioned Podman. As a Java developer, you have the power to create this format which is an open format and distribute your application to any cloud.

Markus Eisele: Adding to this, I think the challenge itself is developer velocity. So, if we all agree on containers being the ideal way of moving application bits and pieces across various execution environments, on premises, cloud, whatever you want to, it's still comparably challenging to have a distributed system consisting of various containers even locally, like, emulated or tested or whatever. So, there's good approaches. Test containers is one of them.

There are also challenges. Imagine running Kafka locally on your machine. So Quarkus addresses these to a certain extent thinking Redpanda. There are a lot of developer productivity features hidden in various frameworks and platforms to be honest. If I think about something super specific that we're unfortunately not talking about in the book because we wanted it to be general purpose obviously, but then I think about the OpenShift developer UI. There's a lot of stuff in this UI that makes life for developers easy. Think about the service binding operator that you could use to just wire your application bits and pieces to Kafka queues and topics for example.

I think as a general challenge in this field going forward, Kubernetes and containers, we will have to invest a lot more into developer productivity. From a gut feeling, from an old guy like me, I think we went down from 60%, 80% of coding in day to day to about 40% at max because all the rest is going down the drain. Configuring YAMLs and mingling around with kubectl commands.

So, in general, yes, I agree. It's a great packaging format. It has tons of advantages whenever we think about putting it into production but there's also challenges that you need to overcome as a development team to make this part of your new approach and the DevSecOps or whatever it's called these days is obviously also not the full answer to it even if process is a part of it.

Enough rambling. Yes, I love it but it takes a lot more and I think we tried to help developers and architects navigate these various bits and pieces, more implicitly by using them and describing them and giving people hints into the direction. But I think what we also said pretty clearly is we're taking an opinionated approach. So, we're looking at the world in an ideal way, this is the Natale and Markus recommendation. If you wanna be successful, go this way. 

Ana-Maria Mihalceanu: It's good to have a blueprint of success and I think we've been looking to blueprints and patterns for a long time as developers. However, looking at how the world is right now, I think the first challenge is how to build them when you have a legacy app and then how to orchestrate them. Because making many apps and putting them in a container is easy, putting all the parts together and correlating them correctly and having them produce the expected outcome is one of the difficulties or some of the difficulties that probably many developers and DevOps face nowadays.

 

Java improvements that help with developer productivity

Ana-Maria Mihalceanu: Speaking about the fact that the book tries to be agnostic as much as possible and keep it to open source which I like. What do you see that could be done in regards to working with Java to improve the productivity of developers? I guess this is a book for Java developers.

Markus Eisele: Fair question. And actually, a good one. I have to admit it's hard to answer. I think what we've seen in the last couple of releases has been pretty solid in terms of container support, container detection, resource limitations. And we're actively not touching on that topic at all in the book because I assume that people are going at least with Java 11 these days. What I do think is that it also develops pretty quickly. Just a couple of weeks ago for example, there's been a new open-source project created called Cryostat that basically launches like a sidecar container on Kubernetes, allowing you to collect all your Java flight recorder recordings from the various JVMs running in your application. We're still literally paving the path forward. Java, my personal perception right now as a language, is focusing a lot on improving use cases, APIs and making sure people get the latest and greatest to implement whatever business functionality is needed.

The runtime ecosystem meaning the JDK or the general purpose VM looking at GraalVM for example is kind of a similar development along the lines. So GraalVM obviously has insane advantages when it comes to running serverless workloads, instantly launching little functions, a small footprint, high packaging density on these Kubernetes hosts. I don't really know what I would want from Java at this point because I think it's already pretty solid, well equipped to handle all kinds of container use cases. I think my direction would be more in the runtime area. Looking at how to connect the actual VMs, not naming a specific one in this case and making sure they can be easily used as input for auto scaling even beyond the information we have as of today which is basically memory consumption and CPU cycles.

So maybe there is a way to even integrate profiling deeper in applications that could be relevant. And I think this is definitely something that comes into play more whenever we are thinking about really heavily distributed applications with many, many, teensy, little services going all the way to serverless. Somebody needs to have an overview about all of this. So, it's mostly application, profiling and monitoring for now. I think there's a lot of potential to follow through on that.

Another opportunity I see is obviously runtime size. So, thinking of the new hot topics. For example, Edge. So how can I deploy a piece of Java successfully in a containerized environment to the most distributed infrastructures you can even distantly think of? There's a lot of improvements. The language itself, the runtime itself, I don't even have a wish list. So maybe I'm just happy as a Java champion. I don't know.

Ana-Maria Mihalceanu: Speaking of wish lists, there are ways to make our wish lists available. Thanks to the Java community which is quite big and to have those wish lists taken into account. There are many more topics where Java is useful nowadays and is expanding. I'm really grateful that the language itself in the past releases has been looking over to what other JVM languages had and improved on that for us and for the developer experience.

 

How containers can help when working on different technologies

Ana-Maria Mihalceanu: But since we also touched again the containers area, do you think that there is an impact on how containers are working on different infrastructure technologies or programming languages? Because for example, this is a conversation I had some years ago with a colleague of mine that was very fond of Node.js, that was telling me like, "Yeah, but I would not necessarily embrace Java when building microservices because I believe that it doesn't give me the same agility as in terms of Node.js." Do you think that containers can help us in this case, speeding up Java when working with them on different infrastructure?

Natale Vinto: I don't think it's the format per se. I think it's the runtime Java virtual machine optimization and the framework. For instance, Quarkus has optimization to reduce the footprint of memory usage, speed up the boot time, and is using an application web server which is Undertow which is optimized for running the workload. I think it's a matter of optimization and also supporting some programming models. Probably your friend liked a more reactive way to express code or this function code. I think Java adapted itself in the years to many programming models. Historically, for object-oriented programming and models, it now also went into the reactive model and also the function model.

You have definitely the choice as a Java developer to pick the right programing approach and the frameworks also help you very much. The containers I think still help with universality. The Node.js developer, the Java developer, the Rust developer, everyone uses containers. There's no messing up with the operating system. We use the same format. It can be in a Docker file, it can be in a framework that created the content. Everyone used the container. Anyone is indirectly also using the 12-factor methodology we mentioned in the book but this is kind of a best approach on rules to write an application. When you use a container, you're also using this approach. You're making things generic, agnostic. You're using environment variable to inject the configuration from outside. Your application is not hardcoding anything. It's prepared for best practices and that's where the container helps any developer. It can be Java, Node.js. It's the format plus the implementation of such best practices when you start developing your application which is universal.

Markus Eisele: I couldn't agree more. Maybe one more thought. The ultimate advantage of Java is it has shown to scale. And not only as physical executing applications but also in terms of team sizes and supervising quality, for example. There's tons of plugins, PMD, whatever to make sure everybody's following the same rules. So, we can, as an industry, as Java developers, deliver insane quality at scale at large. And the knowledge inherited in all these people loving and using Java is basically something that needs to be conserved. This is why I personally love Quarkus so much because it basically takes this approach. It conserves all the existing knowledge around APIs and behavior. It's like JPA on steroids.

You can literally use your existing knowledge and implement high speed microservices. Is that because of containers? Probably a little because it was kind of the initial factor. We are thinking about Kubernetes native applications that we wanna deploy. But yes. The industry at large including the movement to containers forced us to become better and still work alongside existing APIs and conserve this knowledge. We can't just all start writing JavaScript for many reasons. It might not be containers but it might actually be started by them.

Ana-Maria Mihalceanu: True. Yes, Java's been there for tens of years and has proven to us it's a safe technology to be used. It is good for the future. And that's amazing. And yes, thanks to the fact that now it's keeping up with other programming models than object-oriented programming, the one that we started in school is obviously a huge advantage. I think that we're approaching the end of our conversation. 

 

Misconceptions about cloud native

Ana-Maria Mihalceanu: I would like to ask you a closing question. In your book, do you address any of the misconceptions around being cloud native because cloud native in the beginning, when I heard the concept, it made me have this fear of missing out something. Do you have anything in the book about cloud native and misconceptions or this fear of missing out the cloud native that might help us also spiritually next?

Markus Eisele: Absolutely. We're touching on what we think about cloud native in general. It's not a big secret. I mean, even if it's in the book's title. My preference would be to call it Kubernetes native because we're looking at a specific execution environment. The cloud could literally be a lot of things. And not necessarily be based on this famous orchestration layer. Ultimately, I think we're not going through the theoretical parts of a 12-factor app or whatever people think cloud native is. We're more practical to the point of defining what I think coworkers of us named the “Microservices'ilities”. I'm messing that word up every time I speak it. But basically, the bits and pieces around your application development for a Kubernetes environment. So, to be Kubernetes native, I think I'm not totally overpromising but we've been looking at pretty much everything that a Java developer needs today to be successful and find its path. Is that cloud native by the books meaning 12 factor app? I'm not completely sure. We're definitely missing out on the team and DevOps thoughts around all of this. We basically recognize that this is a big piece of the puzzle but we really wanted it to be technology and one layer above, not 20.

To me personally, that was one of the biggest challenges writing this book, finding the right flying height, if that translates. Because just recapping what I learned over the past 20 years in this industry, I had the pleasure to learn every single technology layer that came on top over the past 20 years bit by bit whenever it was released and ultimately created. If somebody drops out of university today and wants to become a programmer and wants to be productive from day one, this is gonna be a challenge because there's so much to know. Making the right decision about things to talk about was one of the challenges that we tried to tackle by really focusing on that concise part and making sure it is relevant even if it's a little bit of theory. I guess that was a long answer for no, we don't.

Ana-Maria Mihalceanu: I was gonna say that maybe that's a good starting point for another book.

Markus Eisele: Maybe.

Ana-Maria Mihalceanu: Or a set of articles. Just saying. I like the duo that you are. 

Markus and Natale have produced an amazing book and I expect a lot of other good content coming from them. Being a developer nowadays is indeed different from being a developer when I started, twelve years ago. Because what I felt at that time as a junior was that there's time for me to get acquainted with everything while today I feel that there are so many new technologies and frameworks and so on. Sometimes it's difficult as a developer to keep up and you can feel overwhelmed.

And by the way, productivity from day one for a junior, I don't think that exists but that's my personal opinion. Natale, anything that you would like to add to what Markus said? He put the conclusion over there but any of your personal thoughts? That would be awesome to hear.

Natale Vinto: I agree that as we wanted to make this book concise, we couldn't go into all what is cloud native but what we did has good pointers. Like, we mentioned lots of other frameworks we couldn't use like Micrometers, Micronaut for metrics in application, a very important topic. Or logging the application. In some parts, we rely on Kubernetes internals. In some other parts, we mention other frameworks that would be useful for achieving that. We mentioned Service Mesh for instance but we haven't implemented it in the book. We implemented serverless and we liked this approach because we thought it's a very valid approach coming in the future with adding more IoT use cases, more machine learning but we couldn't cover everything. To keep it concise, we just go straight to some points and for the others, we just have pointers or links or we just mention other technologies.

To recap, I think this book is a great starting point when you want to start modernizing your Java application but also when you want to have any Kubernetes native approach. You want to start understanding and start delivering your application with Kubernetes as Java developers. I think this book is a really great fit for it.

Markus Eisele: Yeah, and if you ask me, they should make it mandatory for every university student to actually read it and buy it.

Natale Vinto: We should go to the university and do the evangelism.

Markus Eisele: It's absolutely perfect for them.

Ana-Maria Mihalceanu: Thank you very much. That was amazing coming from the two of you. There are ways to find the book available online, the way that I have read it. And yes, I do agree that's a good starting point into this modern world and especially for Java developers. It was done for you folks, for Java developers that want to still give a boost to the enterprise apps sector. That's an area that we should look more into and be more empathetic with those kinds of apps. Kudos to both of you for writing an awesome book and thank you for joining me today at the GOTO Book Club. Hope everybody has enjoyed this. You can reach Markus and Natale on social media to ask more questions or read more details about what's written over on Red Hat.

So, thank you very much for joining me. Again, kudos to our two awesome coauthors and my awesome colleagues as well. And I hope you have a great day. Bye.

Natale Vinto: Thank you, everyone.

Markus Eisele: Thank you.

Natale Vinto: Bye, bye.