You have probably heard of the cloud-native approach such as cloud-native platform, architecture, and application since the Cloud Native Computing Foundation (CNCF) defined the term back in 2015. Or even three years earlier than the CNCF definition. I mean the term cloud-native was first used by Bill Wilder’s book, Cloud Architecture Patterns, which is almost 10 years ago.
What I want to say here is that the cloud-native approach has a long history. And in that history, the commonality of the definition of the cloud-native is the patterns of organizations, architectures, and technologies that consistently, reliably and at scale fully take advantage of the possibilities of the cloud to support cloud-oriented business models.
Cloud-Native can also be described as a combination of best practices that include, but are not limited to, continuous deployment, Linux container packaging mechanism, and microservices to help achieve the elastic scaling capabilities, speed of introducing new functionality, and increased automation needed to cater to an unpredictable competitive landscape. So, the ultimate goal is to be able to adapt the cloud-native technologies quickly and cost-efficiently.
Otherwise, Kubernetes-native is a specialization of cloud-native, and not divorced from what cloud-native defines. For example, a cloud-native application is intended for the cloud, a Kubernetes-native application is specifically designed to run on Kubernetes platforms, generating software designed to maximize the functionalities of Kubernetes API and components and facilitate infrastructure management. Also, all applications must be packaged for Linux container images such as Docker and OCI format then run them on Kubernetes, allowing enterprises to manage the business applications on multi- and hybrid clouds on Kubernetes.
More importantly, both cloud-native and Kubernetes-native technologies deliver the added benefits of self-service access, automated infrastructure scaling, and dynamic resource pools, which most clearly distinguish them from traditional applications running on virtual machines.
New challenges and limitations into Kubernetes-Native with Java
Java was designed to maximize network throughput for the most demanding enterprise applications while ignoring its size in computing resources such as memory, CPU, disk storage, etc. As long as the business applications were stable, no one cared that you were required to pay a million dollars for only 2 GHz processors and 10 GBs memory to run business applications on 3~4 Java servers back then.
Java was also to be designed to be long-running applications, maintaining critical customer data, and user experience for months or years at a time. In those circumstances, business application restarts should be avoided at all costs. 10 minute boot times were acceptable, at least to operations teams.
More importantly, Java frameworks had rich dynamic behaviors built for mutable systems which means developers built an intermediate code, aka bytecode then deploy it to any app servers on Java virtual machines. These Java frameworks did a lot of acrobatics to keep the apps flying in the air, and even allowed developers to modify the app as it flew.
However, with the rise of Kubernetes-Native infrastructure and containers, these dynamic behaviors and associated heavy footprint of Java apps no longer match how developers and operations teams want to build and deploy applications today. For example, if one of your microservices needs to be deployed more than 100 or even more than 1000 pods to handle scalability and reliability issues in Kubernetes, the dynamic behavior of Java frameworks would compile & build the same microservice as the same as the number of deployments. This is the challenge to use Java for Kubernetes-Native infrastructure, especially at scale.
3 things Kubernetes native Java framework must have
Easy to Kubernetes integration – While implementing business features on Kubernetes, developers want to refer Kubernetes APIs as many as they can. For example, sensitive information such as database username and password can be stored in Configmap or Secret rather than the application itself. This development model would be more efficient for scaling applications as well as more reliable systems.
Developer Joy – To accelerate the development loop from local to Kubernetes, the remote development capability should be also considered in Kubernetes native application framework. Let’s say that you already have a business application deployed to the remote Kubernetes. And now, when you have to change code for new business features, bugfix, or even performance improvements, how would you do that? Generally speaking, you could change the code locally first then rebuild, retest, redeploy the changed code to the Kubernetes along with the development loop. What if you could make the changes to the remote Kubernetes from your local Java editor tool directly right after changing the code without any rebuilding, repackaging, and redeploying it? This feature will increase developer productivity as well as optimizing development time for the Kubernetes-native application development.
Container first design – A new Kubernetes-Native Java framework should make it efficient for containers with low memory consumption and a fast first response time for Kubernetes-Native use cases such as high data volume transactions, rapid scalability, serverless functions with event-driven executions. For example, native compilation for Java applications allows developers and operators to extremely optimize the Kubernetes native applications with super-fast startup time like milliseconds and tiny memory footprint like 25~30 times lesser than the memory footprint of the same microservices on Kubernetes. So higher density on the same Kubernetes allows enterprises to reduce infrastructure cost after all.
Conclusion
You might want to go to the CNCF landscape to find out a new Kubernetes native Java framework for your business. They, you will see more than 950 projects, tools, frameworks, and platforms that enable you to solve these challenges for not only Java developers but also system admins using Kubernetes ecosystems. But, it’s too many choices for a decision-maker such as a developer team lead or your C-level person.
A better solution for Java developers is to let them solve the issues using the pure Java framework rather than trying to integrate or adopt inexperienced new tools or projects. Quarkus is a brand new Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best-of-breed Java libraries and standards.
Quarkus aims to write cloud-native microservices and designing serverless applications deployed to cloud infrastructures (e.g., Kubernetes and OpenShift) and taking advantage of the underlying platform to do amazing things such as live coding, unified imperative & reactive programming, and expanding capabilities like distributed caching, high volume messaging processing, security with single sign-on, cloud deployment, making portable serverless functions and more. Many enterprises have already adopted Quarkus for app migration and modernization on Kubernetes as well as digital transformation due to cost-saving, developer productivity. Try it out for yourself here!
