Shaping Tomorrow’s Technology: Navigating Cloud-Native, Serverless with Java Shaaf Syed Principal Architect, Red Hat ORGANIZERS: 

Shaping Tomorrow’s Technology: Navigation Cloud-Native, Serverless with Java fosstodon.org/@shaaf @syshaaf sshaaf https://www.linkedin.com/in/shaaf/ shaaf.dev Java developer, architect, advocate @RedHat, 🐧 ☕ , open source enthusiast, Technical editor at @InfoQ , 🏏 coach 🧢 🔭 I’m currently working @Red Hat ☕ Mostly backend Java development, and maybe some node sometimes.. 🌱 Java Technical editor @Infoq 🤝 I’m a cricket coach @ Glostrup Cricket 📝 I regularly write articles on https://shaaf.dev 💬 Ask me about Java, backends and architecture 

Too many tech words in the title talk cloud native Serverless Java 

Knative is more than Serverless 

Monolith Microservice Function f( ) Architecture Evolution ❖ Self-contained software ❖ Fewer cross-cutting concerns ❖ Lack of flexibility ❖ Difficult to Scale ❖ Difficult to maintain, update, and deploy ❖ Multiple, loosely coupled, independent services ❖ More scalable ❖ More flexible ❖ More Complex Development ❖ Easier to maintain, update, and deploy services individually ❖ Single purpose, event driven ❖ Easy development ❖ Highly scalable ❖ Highly flexible ❖ More Complex Deployment ❖ Cold start latency 

No content

Our Monolith’s Architecture & Challenges ➔ Scaling challenges e.g. individual components or app ➔ Lifecycle is prolonged due to dependencies ➔ Everything runs in the same process ➔ Technical debt, hard to innovate ➔ CI/CD 

Breaking down components into services ➔ Scaling is more independent to the component (hypothetically speaking..) ➔ Life cycles are shorter depending on the teams ➔ Everything is no longer in one big process ➔ Distributed, can introduce other challenges like latency, compatibility, single point of failures etc. ➔ Capacity, not all services are used all the time…. wait what??? 

Our evolved architecture- mix and match! ➔ Lets try this on one service ➔ Scale to Zero? ➔ Only use it when a component needs it.? ➔ Mix and match which ones? ➔ Cost, efficiency maybe more sustainable? ➔ Is it really beneficial in production? 

Demo time! 

Show me Event Driven Pattern- Eventing ➔ Operates on a Knative Service ➔ Publish an event without creating a consumer. ➔ Consume an event without creating a publisher. ➔ Push based approach ➔ Manages data delivery (Eventing) ➔ Knative Autoscaler - Demand-based autoscaling (HTTP) 

Show me the wild scaling! - Pattern 

Show me scaling of Events - with KEDA ➔ Automatically scale Kubernetes Deployments, Jobs & Custom Resources ➔ Provides 61+ built-in scalers, but users can build own external scalers ➔ Kafka, Prometheus, RabbitMQ, AWS services, Azure Services,... ➔ Scale resources based on events in the target scalers, eg. messages in Kafka topic ➔ KEDA does not manipulate the data, just scales the workload ➔ Installation through OLM Operator or Helm 

Show me the wild scaling! - Efficiency Over provisioning Time in capacity planning IT cost of idle resources Under provisioning Lost business revenue Poor quality of service More applications Direct line between IT costs & business revenue NOT Serverless with Serverless 

● KEDA - Kubernetes event driven autoscaling dead simple ● KEDA - pull model vs. Knative - push model ● KEDA - Standard Kubernetes resources vs. Knative Service ● KEDA can autoscale Knative Eventing Infrastructure ○ knative-sandbox/eventing-autoscaler-keda Takeaways - Leveraging architecture strength scale to zero scale on events 

Show me where to find the demo source https://github.com/sshaaf/coolstore-knative 

No content

Thank you for watching Remember to rate the presentation and leave your questions in the section below. www.yavaconf.com ORGANIZERS: