How can we effectively develop for the cloud, when we as developers are coding back down on earth? This is where effective cloud-native developer tools can enable us to either be transported into the cloud or alternatively, to bring the cloud back down to earth. But what tools should we be using for this? In this session, we’ll explore some of the useful OSS tools and technologies that can used by developers to effectively develop, design and test cloud-native Java applications.
18. 18
Starters
Give me a starter project or
template for my MicroProfile
application
• start.microprofile.io
• VS Code extension
• IntelliJ plugin
Create
19. 19
Starters
Give me a starter project or
template for my Jakarta EE
application
• start.jakarta.ee
• Runtime-specific
starters/generators/templates
• Open Liberty Starter
• start.openliberty.io
Create
21. 21
Dev Mode
What if I don’t have to build,
package, deploy and start my
application manually during
development?
• Liberty Maven/Gradle Plugin
• Dev mode for hot deploy
• Continuous/hot testing
• Container support
• Debugging
mvn liberty:dev
mvn liberty:devc
Build
24. 24
IDE or Editor Integration
Working with MicroProfile API and
runtimes inside my favorite editor
or IDE
• Eclipse
• IntelliJ
• VS Code
• NetBeans …
• IDE integration for runtime
lifecycle management
• Custom runtime plugins or
extensions
Edit
25. 25
Coding Assistance in Editor/IDE
Can I get help with working with
MicroProfile APIs inside my favorite
editor or IDE?
• Language Server for Eclipse
MicroProfile incubator project at
Eclipse Foundation
• LSP4MP-based VS Code
extension, Tools for
MicroProfile from Red Hat
Contribute at
https://github.com/eclipse/lsp4mp/
Edit
26. 26
Coding Assistance in Editor/IDE
Can I get help with working with
Jakarta EE APIs inside my favorite
editor or IDE?
• Language Server for Jakarta EE
(LSP4Jakarta) incubator project
under the Eclipse Foundation
Contribute at
https://github.com/eclipse/lsp4jakarta
Edit
27. 27
Code Generators
Any additional help with generating
(boilerplate) code?
• MicroProfile Rest Client from
OpenAPI docs
• CLI via OpenAPI Tools
• VS Code extension
• JAX-RS stubs generation in
OpenAPI Tools
Edit
30. 30
my-
app:latest
(app
container)
mongo:4.0
(DB container)
Dev/Test env
Production env
integratio
n tests
end users
my-
app:latest
(app
container)
mongo:4.0
(DB container)
Testcontainers
Integration tests that are easy to
setup, write, and run
Test your apps the same way
they run in production
Tests are portable to any
compatible implementation:
o Liberty
o Wildfly
o Payara
o TomEE
o etc…
32. 32
Buildpacks.io
Provide framework and runtime support for applications
Transforms your application source code into container
images that can run on any cloud
Avoid the need to manage Dockerfiles
</>
Source Code Buildpack
Specification
pack CLI
OCI Image
37. 37
What is Telepresence?
• Fast, local development for Kubernetes and
OpenShift Microservices
• Benefits:
• Accelerate Inner Dev Loop
• Shift Testing Left
• Use Your Existing Workflow
https://github.com/sdaschner/liberty-dev-experience https://heidloff.net/article/debugging-microservices-Kubernetes/
38. 38
How does it work?
‘telepresence connect’
`telepresence intercept
service-name’
42. 42
Developer Tools MicroProfile - Common Tools Jakarta EE - Common Tools Runtime Tooling (Open Liberty)
Starters
start.microprofile.io
MP Starter IDE Plugins
start.jakarta.ee Open Liberty Starter
Build & Run N/A N/A
Liberty Maven & Gradle Build
Plugins
Dev mode
IDE/Editor Integration
Eclipse LSP4MP
LSP4MP IDE Plugin(s)
MP Extension Pack for VS Code
Code
Eclipse LSP4Jakarta
Liberty Tools for Eclipse, IntelliJ
IntelliJ and VS Code (tech
previews)
Dev mode for any editor
Code Generators
OpenAPI Tools
MP Rest Client Generator
N/A N/A
Automated Testing
JUnit, Arquillian
Testcontainers, MicroShed
Testing
JUnit, Arquillian, Testcontainers,
Hot testing
Deployment N/A N/A
Paketo Buildpacks,
Dev Mode
Telepresence
43. 43
Resource Links
• Liberty Tools for Eclipse: https://github.com/OpenLiberty/liberty-tools-eclipse
• Open Liberty Starter: https://start.openliberty.io/
• Liberty Tools for VS Code:
https://marketplace.visualstudio.com/items?itemName=Open-Liberty.liberty-dev-
vscode-ext
• Liberty Tools for IntelliJ: https://plugins.jetbrains.com/plugin/14856-liberty-tools
• VS Code Extension Pack for MicroProfile:
https://marketplace.visualstudio.com/items?itemName=MicroProfile-
Community.vscode-microprofile-pack
44. 44
Resource Links
• TestContainers: https://www.testcontainers.org/
• Paketo Buildpack for Liberty: gcr.io/paketo-buildpacks/liberty
• Telepresence Examples:
• https://github.com/sdaschner/liberty-dev-experience
• https://heidloff.net/article/debugging-microservices-Kubernetes/
• Open Liberty Guides:
• Jakarta EE: https://openliberty.io/guides/?search=jakarta%20ee&key=tag
• MicroProfile: https://openliberty.io/guides/?search=microprofile&key=tag
• Open Liberty Deep Dive: https://openliberty.io/guides/liberty-deep-dive.html
How can we effectively develop for the cloud, when we as developers are coding back down on earth? This is where effective cloud-native developer tools can enable us to either be transported into the cloud or alternatively, to bring the cloud back down to earth. But what tools should we be using for this? In this session, we’ll explore some of the useful OSS tools and technologies that can used by developers to effectively develop, design and test cloud-native Java applications.
What do developers care about?
What do developers do? (when creating cloud-native apps)
Move to OSS technologies cloud-native, agility, portability, no vendor-lock in, community driven, etc
How do we best work with these technologies locally to effectively build cloud-native applications?
We’ll focus on a few Java specific OSS technologies for the examples given and demos shown
Eclipse MicroProfile is a set of cloud native capabilities, implemented by our Java runtimes, that provide standard applications annotations implementations for applications to use in containers – building on a core of familiar Java EE technologies. LRA is one of the newest MicroProfile specificactions, derived from WS-BA, to provide a simple compensating transaction for Java microservices.
The blue specs are part of the MicroProfile 3.3 release. ReactiveMessaging and LRA are standalone specs.
The LRA model provides a good balance between a loosely coupled transaction model that preserves independence of application lifecycle of each microservce and application simplicity over maintaining data consistency in the presence of failure. Simple Java annotations are used to register completion and compensation tasks while the platfrom takes care of ensuring these get invoked appropriately, across any form of system failure.
* use a more visible list, not so OL focused
Apply OSS tools to what developers actually need – what they do
Can be tedious to have to re-build, re-package, re-deploy applications every time you want to see a code change
What tools are there available for us to make this easier?
Dev Mode – hot deploy tool, abilities to start server, watch app for changes, re-build and re-package when needed and re-deploy
Takes onous off developers
Can see changes immediately – live test changes
Offered as a maven or gradle plugin from Liberty
Snippet shows plug needed (example is the maven plugin)
Just need to run command shown
Also container integration, just need to run the c goal to be able to test in a local container environment
Also offers debugging, so dev mode makes a debug port available and allows you to connect to an IDE through this port to debug at any time
The WAD tool watches for any changes that we make in the project and re-deploys our applications.
Without fast deployments and short feedback-cycles about a new feature, you lose a lot of time just “idling”. As a Java/Jakarta EE developer, you will most likely have a local installation for the target application server and deploy the application several times a day during development. In the past, I've used Eclipse/IntelliJ/Netbeans with various vendor plugins to start the application server and deploy on every new code change. This was always quite a fiddling task, as I sometimes got issues with the plugins, had to wait for a new release or it wasn't as fast as I expected until I could see my changes. Luckily Adam Bien (@AdamBien) solved this with a small Java project called WAD (Watch and Deploy) which deploys thin .war ‘s on every change to any server and improves your productivity.
Next is the edit stage
As you’re editing typically we use IDEs or Editors
What tools or plugins do we have when using favourite OSS specs or runtimes in fav IDEs?
Many out there – screenshot shows just some from VS Code marketplace (search on MP)
Many MP-specific Plugins and runtime-specific plugins (e.g. Quarkus, Open Liberty)
Integrate straight into your IDE
Really convenient
Offered for a wide range of IDEs
Example shown for Open Liberty here is Liberty tools
Open Liberty Tools are lightweight tools for developing, assembling, and deploying apps to Open Liberty.
It supports editing Liberty server.xml configuration (Liberty Config Language Server), developing MicroProfile applications, a Liberty Dashboard for organizing your projects (With a few clicks, you can start and stop your app, run tests, and view test reports.), and Liberty dev mode functions, all from within your IDE.
What other coding assistance could I get in an editor or IDE?
We are probably aware of the coding assistance editors can give us for working with Java projects, but what about specifically working with OSS Java specs like MicroProfile or Jakarta EE?
This is where language server projects come in.
One project is Eclipse LSP4MP – language server for Eclipse MicroProfile (all OSS, lives under eclipse foundation)
Provides in-editor language features for MP APIs (e.g. code completion or snippets for popular APIs, or diagnostics or quick fixes when you use an API incorrectly), feedback to fix or enhance code before you run your app
To use, just install plugins/extensions into your IDE of choice
E.g. there is a VS Code extension from Red Hat (Tools for MP) that consumes this language server project
What about working with Jakarta EE APIs?
Similar project also under Eclipse foundation
Language features support also offered for Jakarta EE APIs (e.g. code completion or snippets for popular APIs, or diagnostics or quick fixes when you use an API incorrectly), feedback to fix or enhance code before you run your app
Should mention that both of these projects are considered incubator projects, so always looking for feedback from the community or to get more of the community involved (let us know if there is a feature you’d like to see that isn’t already there)
Ok, what about if we want to generate snippets of code or generating boilerplate code? Are there tools to help?
Yes! Code generator tools like OpenAPI tools -> for example you could generate a MicroProfile Rest Client from OpenAPI documentation
This is available as a command line interface if you were to use the OpenAPI Tools or as an IDE extension (e.g. VS Code) – example given on the right and in next slide for this
Enables you to generate a MP Rest Client directly into your project
You can also generate JAX-RS stubs with OpenAPI Tools too
Elias giving talk on this next in Room A4 (13:00-13:50)
Like all good developers….
What tools do we have out there for automated testing?
Usual suspects are obviously available (Junit, Arquillian)
But… if we want to leverage containers…. Can use technologies like TestConatiners or MicroShed testing (implementation of Test Containers)
Mimic prod-like container environment – more confidence that code works as expected
Helps with 12 factor app methodology (Dev-prod parity)
Stops the saying “well it works on my machine”
Oleg giving talk on this tomorrow in RoomA2 (13:00-13:50)
Testcontainers make a variety of different testing easier such as:
Data access layer integration tests
Application integration tests
UI/Acceptance tests
Much more via contributed modules
Supports JUnit 4/5 and Spok
Testcontainers give you the ability to do UI/Acceptance testing in a container. This has great benefits such as:
- Fresh instance of a browser
- No browser state, plugin variations or browser upgrades
- Video recoding of test session or just failed test sessions
What about deployment
Moving towards more devops style teams
Need to consider this…
The Cloud Native Buildpacks project was initiated by Pivotal and Heroku (creators of the 12 factor app methodology) in January 2018 and joined the Cloud Native Computing Foundation in October 2018. The project aims to unify the buildpack ecosystems with a platform-to-buildpack contract that is well-defined and that incorporates learnings from maintaining production-grade buildpacks for years at both Pivotal and Heroku.
Cloud Native Buildpacks embrace modern container standards, such as the OCI image format. They take advantage of the latest capabilities of these standards, such as cross-repository blob mounting and image layer "rebasing" on Docker API v2 registries
Advantages:
You can build your application without creating a Dockerfile!
Advanced Caching: Paketo buildpacks use built-in caching to improve performance so you can quickly rebuild your application by updating only the layers that have changed.
Bill-of-Materials: a built-in software bill of materials (SBOM) support provides insights into the contents of the application image.
Minimal Application Image: images contain only what is necessary.
Reproducibility: reproduce the same application image digest by re-running the build.
Auto-detection: images are built directly from application source.
Rebasing: instantly update base images without rebuilding your source code by patching the OS layer of your image
Using the knowledge of the many years of experience with buildpacks, the CloudFoundry buildpack engineering team created the Paketo.io project which is based on former CloudFoundry Buildpacks .
Paketo is an implementation of the Cloud Native Buildpack interface specification for a wide variety of languages (e.g. .Net, Go, Node.js, Java, Ruby or PHP).
The Paketo Liberty buildpack provides the Open Liberty runtime to a workflow that produces an Open Container Initiative (OCI) image that can run just about anywhere.
Advantages:
You can build your application without creating a Dockerfile!
Advanced Caching: Paketo buildpacks use built-in caching to improve performance so you can quickly rebuild your application by updating only the layers that have changed.
Bill-of-Materials: a built-in software bill of materials (SBOM) support provides insights into the contents of the application image.
Minimal Application Image: images contain only what is necessary.
Reproducibility: reproduce the same application image digest by re-running the build.
Auto-detection: images are built directly from application source.
Rebasing: instantly update base images without rebuilding your source code by patching the OS layer of your image
A builder is an image that contains all the components necessary to execute a build.
A builder is an image that contains three components:
a set of buildpacks, which provide your app’s dependencies
a stack, which provides the OS layer for your app image
the CNB lifecycle(opens in a new tab), which puts everything together to produce your final app image
We’re using the base builder in this case
Now what?
With your OCI image, you can run your application locally with the docker run command.
Now run your application:
docker run --rm -p 9080:9080 myapp
or deploy your application to any Kubernetes-based platform, such as Red Hat OpenShift, by using an Open Liberty operator
Telepresence allows you to swap a pod running in Kubernetes with a service running locally. All requests to the pod in Kubernetes are redirected to the local URL and port.
Cloud Native Computing Foundation Sandbox project
https://heidloff.net/article/debugging-microservices-kubernetes/
Can help with debugging
Telepresence consists of two core architecture components: the client-side (CLI) telepresence binary and (Kubernetes) cluster-side traffic-manager and traffic-agent.
1
The `telepresence connect` command utilizes the traffic-manager to establish a two-way (proxied) tunnel between your local development machine and the cluster. Now you can access remote K8s Service as if they were running locally.
2
Running `telepresence intercept service-name` triggers the traffic-manager to install a traffic-agent proxy container that runs within the Pods associated with the target Services. This can route remote traffic to your local dev machine for dev and test.
Daniel Bryant Devoxx UK 2022 video on YouTube
