Friday, June 25, 2021
Applications in a microservices architecture can communicate with each other in different ways. Adopting an event-driven paradigm based on asynchronous messaging provides services a way of communicating while reducing runtime coupling. Functions are a natural way of implementing event-driven business logic in terms of suppliers, processors, and consumers. Furthermore, when going serverless, we aim at executables with instant startup and efficiency. Enter Spring.
Spring Cloud Function favors using the functional programming paradigm to implement your business logic and provides useful features to build data pipelines, including type conversion and function composition. Functions can be exposed through different options (like web endpoints or message channels), and adapters are available to run them on platforms like Knative, AWS Lambda, Azure Functions, and GCP Functions. Spring Cloud Stream integrates your functions with messaging systems like RabbitMQ and Kafka without requiring any change to your code. Finally, Spring Native lets you compile your applications as native executable using GraalVM and providing instant startup, instant peak performance, and reduced memory consumption.
Ever wondered what is a Cloud-Native Application? Is it a microservice or a monolith? oh, it must be made for Cloud? Ever wondered how to develop a Cloud-Native Application? Come to this session to find out about what makes an application Cloud-Native and then learn how to build a Cloud-Native Application using the latest MicroProfile technologies (MicroProfile 4.0) such as Config, Fault Tolerance, Rest Client, JWT, Metrics, etc. This session finishes with a live demo on developing Cloud-Native applications using MicroProfile 4.0 running on Open Liberty and deploying them on k8s.
Despite the "micro" in the name, real world microservices tend to use a lot of technologies like data persistence, log facades, IoC which aren't always included in the chassis. Hence, Java architects tend to repeat themselves assembling projects with microservices chassis+libraries trying struggling to find the balance between "usefully bloated" and "heavily bloated".
In this presentation I present our(my company's) experience while curating a set of libraries that complement MicroProfile chassis to manage microservices, data migrations and data persistence like:
* Eclipse JKube
Explaining why these libraries are useful and play well in the context of MicroProfile/Jakarta EE and Microservices patterns like those in microservices.io
Later I describe how everyone could curate their libraries and create their archetypes, and how we did it obtaining as product Kukulkan EE:
Saturday, June 26, 2021
Kubernetes enables possibilities to develop cloud-native microservices or decompose traditional applications making them more technologically advanced with the help of containers. Currently, most of the Kubernetes solutions are offered on top of VMs and there is room for further improvements. Implementing nested architecture of application containers running inside system containers opens additional flexibility of resource allocation and management, accelerates provisioning of the clusters and pods, as well as cuts the overall costs. During this session, we’ll review the possibilities of running a Java-based application inside the Kubernetes cluster with nested container architecture, what configurations should be taken into account, and how to overcome the barriers on the way to more efficient Kubernetes hosting.
How does one choose to architect a system that has a Microservice / REST API endpoints? There are many solutions out there. Some are better than others. Should state be held in a server side component, or externally? Generally, we are told this is not a good practice for a Cloud-Native system, when the 12-factor guidelines seem to be all about stateless containers, but is it? It’s unclear and this confusion may lead to poor technology stack choices that are impossible or extremely hard to change later on as your system evolves in terms of demand and performance.
While stateless systems are easier to work with, the reality is that we live in a stateful world, so we have to handle the state of data accordingly to ensure data integrity beyond securing it.
We will examine and demonstrate the fundamentals of a Cloud Native system with Stateful Microservices that’s built with Open Liberty in Kubernetes:
- Microservices/REST API – Options to use when running your apps in the JVM
- Concurrency – how to take advantage of multi-core CPUs and clustered distributed systems
- Stateful vs Stateless - while stateless apps are easier to implement, the bulk of the apps in production are stateful which involve a higher level of complexity and risk, especially when data would need to travel across multiple machines and network boundaries
- Deployment – how about containerization and orchestration using Kubernetes?