"It’s not only Lambda! Economics behind Serverless" at JAX Conference in Mai 2019 by Christian Bannes and Vadym Kazulkin (both ip.labs GmbH)

A presentation I gave at ESPC 2018 (the European SharePoint, Office 365 and Azure Conference) about use of Azure Functions to extend Office 365 solutions. Covers Azure Functions fundamentals, adding code to PowerApps/Flow, Site Designs and Site Scripts (and PnP site templating), SPFx and Durable Functions. Also has tips on v1/v2, performance, pricing and how to avoid cold starts.

Discussion of Azure web apps, App Insights, "Azure Functions in the real world", ARM templates, queues, BLOB storage and more. Includes a video demo of AAD-secured Azure Function called from a SharePoint Framework (SPFx) web part with SPO cookie auth.

aka "Wisdom from the Masters, learned the Hard Way" Disclaimer: not an AWS talk. All views expressed are my own only.

This document provides an overview of deploying Joomla at scale on Amazon Web Services (AWS). It discusses infrastructure as code using AWS services like CloudFormation, configuration management with tools like Chef, monitoring performance with CloudWatch, governance and compliance with services like CloudTrail, and optimizing resources. The presentation emphasizes automating everything, designing for failure, and implementing a defense in depth security strategy across availability zones and regions.

I presented this at JavaOne 2011 on October 6th. It discusses some of the problems related to environment provisioning that enterprise Java developers face and how the new Platform-as-a-Service (PaaS) product from Amazon Web Services called Elastic Beanstalk can solve some of those problems.

This document discusses scaling digital asset management systems to handle large repositories. It begins by describing challenges that can arise from trying to scale a DAM system without optimization. It then provides recommendations for optimizing asset processing workflows and configurations. Finally, it outlines several architectural approaches for scaling a DAM system, such as using separate instances for ingestion/processing and executing intensive tasks. The goal is to first optimize and then scale the system in a way that matches asset usage and adds necessary resources.

Scalable applications are by nature resource intensive, expensive to build and difficult to manage. What if we can change this perception and help developers design full-stack applications that are low cost and low maintenance? This session describes the underlying architecture behind www.deep.mg, the microservices marketplace built by Mitoc Group using AngularJS, NodeJS and powered by abstracted services like AWS Lambda, Amazon CloudFront, Amazon DynamoDB, and so on. Eugene Istrati, Technology Partner at Mitoc Group, will dive deep into their approach to microservices architecture using serverless platform from AWS and demonstrate how anyone can use serverless computing to achieve high scalability, high availability, and high performance without huge efforts or expensive resources allocation.

Content Management Systems are by nature resource intensive, expensive to customize, and difficult to manage at scale. What if we can change this perception and help PHP / Drupal developers architect a content platform that is high performance and low cost, high security and low maintenance? This talk will focus on 3 key topics: 1) serverless environment, 2) microservices architecture and 3) hands-on demos. We will describe a serverless solution and propose a scalable architecture that will help Drupal community to adopt cloud-native approach without huge efforts or expensive resources allocation.

Most large-scale web companies have evolved their system architecture from a monolithic application and monolithic database to a set of loosely coupled micro-services. Using examples from Google, eBay, and KIXEYE, this talk outlines the pros and cons of these different stages of evolution, and makes practical suggestions about when and how other organizations should consider migrating to micro-services. It concludes with some more advanced implications of a micro-services architecture, including SLAs, cost-allocation, and vendor-customer relationships within the organization.

A presentation I gave at ESPC 2020 (the European SharePoint, Microsoft 365 and Azure Conference) covering simple options for adding AI to Power Apps and Power Automate solutions. Topics covered include AI costs and different implementation approaches - including Power Apps AI Builder, use of Azure Cognitive Services from code, and use of Azure Cognitive Services in a Flow (Power Automate).

The document discusses 3 key ways that developing software for the cloud differs from traditional approaches: 1. Incremental delivery, with frequent small releases of new features rather than large periodic releases. 2. Increased automation, including automated testing and continuous integration/deployment pipelines to support more agile development and deployment. 3. Analytics of usage data to inform product decisions and ensure features are valuable to users. Developing with the cloud in mind requires rethinking processes to focus on agility, automation and data-driven insights.

The document discusses challenges in distributed systems including: 1) Avoiding database transactions by using logical transactions and handling replication conflicts. 2) Handling database schema changes by adding fields lazily with feature toggles and migrating data in the background. 3) Ensuring consistent reads across replicas by having a separate API and handling cross-datacenter replication lag. 4) Dealing with multiple datacenters by pinning APIs, separating read/write services, using a SQL proxy, or client routing.

This document provides an introduction to web components and discusses their benefits. It explains that web components bring a native component model to HTML, allowing for reusable UI functionality both within and across applications. The document demonstrates several types of web components, including custom elements, HTML templates, HTML imports, and shadow DOM. It also discusses browser support for web components and strategies for improving support, such as using polyfills.

The document provides an overview of the SharePoint Framework (SPFx) from the perspective of an ISV. It begins by focusing on key aspects of SPFx like publishing versions, pushing updates through a CDN, using shared code and external libraries, and using custom PropertyPane properties. It then provides a history of SharePoint development models and extensibility opportunities. The document explains what SPFx is, its advantages and disadvantages, and choices for the UI framework. It discusses building a solution, publishing, dependencies, consuming data, the advanced PropertyPane, updating SPFx, and provides some helpful tips.

This document discusses modernizing classic SharePoint sites. It provides an overview of the capabilities of modern sites and features that can apply to most classic sites. It demonstrates tools for understanding, remediating, and modernizing classic sites, including a modernization scanner, techniques for transforming different classic page types like wiki and publishing pages, and options for in-place or cross-site modernization. The document encourages starting the modernization journey to reduce growing modernization debt.

A presentation I gave at SharePoint Evolutions 2015. Here, I compare SharePoint apps (now renamed "SharePoint Add-Ins" as of April 2015!) and the newer flavour of app development, Office 365 apps. It focuses primarily on the perspective of a development team implementing the app - and factors to consider when deciding between the two approaches. However, to do this we must consider end-user and administration aspects, as well as code/development. Key agenda points: - Changes in SharePoint development - Apps, 2 years on.. - SharePoint Add-Ins – a recap - Office 365 apps - Why did Microsoft introduce these? What do they promise? - Comparing SharePoint Add-Ins with Office 365 apps - For the end-user, administrator and developer - Summary

Scalable Web Architecture: LAMP, AWS, S3, CloudFront, EC2, caching strategy, scaling database, hight availibility, fault tolerant, horizontal scalability

When we talk about prices, we often only talk about Lambda costs. In our applications, however, we rarely use only Lambda. Usually we have other building blocks like API Gateway, data sources like SNS, SQS or Kinesis. We also store our data either in S3 or in serverless databases like DynamoDB or recently in Aurora Serverless. All of these AWS services have their own pricing models to look out for. In this talk, we will draw a complete picture of the total cost of ownership in serverless applications and present a decision-making list for determining if and whether to rely on serverless paradigm in your project. In doing so, we look at the cost aspects as well as other aspects such as understanding application lifecycle, software architecture, platform limitations, organizational knowledge and plattform and tooling maturity. We will also discuss current challenges adopting serverless such as lack of high latency ephemeral storage, unsufficient network performance and missing security features.

When we talk about prices, we often only talk about Lambda costs. In our applications, however, we rarely use only Lambda. Usually we have other building blocks like API Gateway, data sources like SNS, SQS or Kinesis. We also store our data either in S3 or in serverless databases like DynamoDB or recently in Aurora Serverless. All of these AWS services have their own pricing models to look out for. In this talk, we will draw a complete picture of the total cost of ownership in serverless applications and present a decision-making list for determining if and whether to rely on serverless paradigm in your project. In doing so, we look at the cost aspects as well as other aspects such as understanding application lifecycle, software architecture, platform limitations, organizational knowledge and plattform and tooling maturity. We will also discuss current challenges adopting serverless such as lack of high latency ephemeral storage, unsufficient network performance and missing security features.

When we talk about prices, we often only talk about Lambda costs. In our applications, however, we rarely use only Lambda. Usually we have other building blocks like API Gateway, data sources like SNS, SQS or Kinesis. We also store our data either in S3 or in serverless databases like DynamoDB or recently in Aurora Serverless. All of these AWS services have their own pricing models to look out for. In this talk, we will draw a complete picture of the total cost of ownership in serverless applications and present a decision-making list for determining if and whether to rely on serverless paradigm in your project. In doing so, we look at the cost aspects as well as other aspects such as understanding application lifecycle, software architecture, platform limitations, organizational knowledge and plattform and tooling maturity. We will also discuss current challenges adopting serverless such as lack of high latency ephemeral storage, unsufficient network performance and missing security features.

When we talk about prices, we often only talk about Lambda costs. In our applications, however, we rarely use only Lambda. Usually we have other building blocks like API Gateway, data sources like SNS, SQS or Kinesis. We also store our data either in S3 or in serverless databases like DynamoDB or recently in Aurora Serverless. All of these AWS services have their own pricing models to look out for. In this talk, we will draw a complete picture of the total cost of ownership in serverless applications and present a decision-making list for determining if and whether to rely on serverless paradigm in your project. In doing so, we look at the cost aspects as well as other aspects such as understanding application lifecycle, software architecture, platform limitations, organizational knowledge and plattform and tooling maturity. We will also discuss current challenges adopting serverless such as lack of high latency ephemeral storage, unsufficient network performance and missing security features.

hen we talk about prices, we often only talk about Lambda costs. In our applications, however, we rarely use only Lambda. Usually we have other building blocks like API Gateway, data sources like SNS, SQS or Kinesis. We also store our data either in S3 or in serverless databases like DynamoDB or recently in Aurora Serverless. All of these AWS services have their own pricing models to look out for. In this talk, we will draw a complete picture of the total cost of ownership in serverless applications and present a decision-making list for determining if and whether to rely on serverless paradigm in your project. In doing so, we look at the cost aspects as well as other aspects such as understanding application lifecycle, software architecture, platform limitations, organizational knowledge and plattform and tooling maturity. We will also discuss current challenges adopting serverless such as lack of high latency ephemeral storage, unsufficient network performance and missing security features.

This document discusses factors to consider when deciding whether to use serverless (FaaS) architectures. It outlines 6 key areas of consideration: 1) application lifecycle, 2) workloads, 3) platform limitations, 4) cost at scale, 5) operational constraints, and 6) organizational knowledge. For each area, it provides examples of relevant questions and considerations. It also discusses predictions for the future of serverless computing, including support for more runtimes, weakened limitations, and new use cases like big data and machine learning.

This document provides an agenda and summaries of key points from a presentation on integrating systems using Apache Camel. The presentation discusses how Apache Camel is an open-source integration library that uses enterprise integration patterns to connect disparate systems. It highlights features of Camel including components, data formats, and testing frameworks. Customer examples are presented that demonstrate large returns on investment and cost savings from using Camel for integration projects. The presenters argue that Camel provides flexibility, reusability and rapid development of integrations.

This document provides a summary of a presentation on virtualizing tier one applications. The presentation covered the top 10 myths about virtualizing business critical applications and provided best practices for virtualizing mission critical applications. It also discussed real world tools for monitoring virtualized environments like Confio IgniteVM and vCenter Operations. The presentation aimed to show that virtualizing tier one applications is possible and discussed strategies for virtualizing SQL Server and Microsoft Exchange environments.

TCO of Serverless application. How Serverless helps us to be productive, write less code and implement evolutionary architectures. How to measure productivity to see you're on track with Serverless

The goal of Serverless is to focus on writing the code that delivers business value and offload everything else to your trusted partners (like Cloud providers or SaaS vendors). You want to iterate quickly and today’s code quickly becomes tomorrow’s technical debt. In this talk we will show why Serverless adoption increases the developer productivity and how to measure it. We will also go through AWS Serverless architectures where you only glue together different Serverless managed services relying solely on configuration, minimizing the amount of the code written.

Cloud native orchestrators like AWS Step Functions and Amazon SageMaker Pipelines can be used to construct scalable end-to-end deep learning pipelines in the cloud. These orchestrators provide centralized monitoring, logging, and scaling capabilities. AWS Step Functions is useful for integrating pipelines with production infrastructure, while SageMaker Pipelines is good for research workflows that require validation. Serverless architectures using services like AWS Lambda, Batch, and Fargate can build scalable and flexible pipelines at a low cost.

This document summarizes serverless design patterns and tools. It begins with a brief history of cloud computing and an introduction to serverless computing. Common serverless use cases like event-driven applications and stream processing are described. Several serverless patterns are then outlined, such as hosting a static website or REST API using AWS Lambda and API Gateway. Finally, the document demonstrates a serverless application and discusses future directions for serverless technologies.

Ben Sherman is a software engineer and founder of Plator Solutions, an AWS consulting firm. He has a computer engineering degree and previously worked at Amazon. The document defines serverless architecture as cloud-hosted backend services and event-triggered functions that are fully managed, allowing developers to focus on business logic without managing infrastructure. Key benefits of serverless include cost savings due to paying only for resources used, seamless scalability without capacity planning, and faster development without backend provisioning and management.

When we talk about prices, we often only talk about Lambda costs. In our applications, however, we rarely use only Lambda. Usually we have other building blocks like API Gateway, data sources like SNS, SQS or Kinesis. We also store our data either in S3 or in serverless databases like DynamoDB or recently in Aurora Serverless. All of these AWS services have their own pricing models to look out for. In this talk, we will draw a complete picture of the total cost of ownership in serverless applications and present a decision-making list for determining if and whether to rely on serverless paradigm in your project. In doing so, we look at the cost aspects as well as other aspects such as understanding application lifecycle, software architecture, platform limitations, organizational knowledge and plattform and tooling maturity. We will also discuss current challenges adopting serverless such as lack of high latency ephemeral storage, unsufficient network performance and missing security features.

TCO of Serverless application. How Serverless helps us to be productive, write less code and implement evolutionary architectures. How to measure productivity to see you're on track with Serverless

Serverless computing allows you to build and run applications without the need for provisioning or managing servers. With serverless computing, you can build web, mobile, and IoT backends; run stream processing or big data workloads; run chatbots, and more.

The goal of Serverless is to focus on writing the code that delivers business value and offload everything else to your trusted partners (like Cloud providers or SaaS vendors). You want to iterate quickly and today’s code quickly becomes tomorrow’s technical debt. In this talk we will show why Serverless adoption increases the developer productivity and how to measure it. We will also go through AWS Serverless architectures where you only glue together different Serverless managed services relying solely on configuration, minimizing the amount of the code written.

- PyWren-IBM is a Python framework that allows users to easily scale Python code across serverless platforms like IBM Cloud Functions without having to learn the underlying storage or function as a service APIs. - It addresses challenges like how to integrate existing applications and workflows with serverless computing, how to process large datasets without becoming a storage expert, and how to scale code without major disruptions. - The document discusses use cases for PyWren-IBM like Monte Carlo simulations, protein folding, and stock price prediction that demonstrate how it can be used for high performance computing workloads.

Slides on how to build your WordPress site so that it performs like an enterprise application. Associated video: http://wordpress.tv/2014/06/25/john-giaconia-enterprise-wordpress-performance-scalability-and-redundancy/

With the increased use of cloud services, organizations are faced with finding the most efficient way to use existing IT infrastructure alongside cloud-based compute, storage and networking resources. This has resulted in the rise of hybrid IT whereby companies leverage both on-premises and cloud resources to drive increased agility, stability and accessibility.

ip.labs is the world's leading white label e-commerce software imaging company and processes millions of images every day. The workflows of our users consist of designing, saving, loading, ordering and delivering to the printing facilities the photo products like prints, photobooks, calendars, gift products among others. In this talk we'll explore the challenges of our previous solution based on ALB, EC2, EBS and EFS, our motivation and architecture behind the reimplementation of our image storage solution based on AWS Serverless services like API Gateway, Lambda, DynamoDB, SQS, SNS, EventBridge and others, benefits that we've got with this new solution but also challenges we needed to overcome and trade-offs we had to make.

Java is for many years one of the most popular programming languages, but it used to have hard times in the Serverless community. Java is known for its high cold start times and high memory footprint, comparing to other programming languages like Node.js and Python. In this talk I'll look at the general best practices and techniques we can use to decrease memory consumption, cold start times for Java Serverless development on AWS including GraalVM (Native Image) and AWS own offering SnapStart based on Firecracker microVM snapshot and restore and CRaC (Coordinated Restore at Checkpoint) runtime hooks. I'll also provide a lot of benchmarking on Lambda functions trying out various deployment package sizes, Lambda memory settings, Java compilation options and HTTP (a)synchronous clients and measure their impact on cold and warm start times.

Java is for many years one of the most popular programming languages, but it used to have hard times in the Serverless community. Java is known for its high cold start times and high memory footprint, comparing to other programming languages like Node.js and Python. In this talk I'll look at the general best practices and techniques we can use to decrease memory consumption, cold start times for Java Serverless development on AWS including GraalVM (Native Image) and AWS own offering SnapStart based on Firecracker microVM snapshot and restore and CRaC (Coordinated Restore at Checkpoint) runtime hooks. I'll also provide a lot of benchmarking on Lambda functions trying out various deployment package sizes, Lambda memory settings, Java compilation options and HTTP (a)synchronous clients and measure their impact on cold and warm start times.

Java is for many years one of the most popular programming languages, but it used to have hard times in the Serverless community. Java is known for its high cold start times and high memory footprint, comparing to other programming languages like Node.js and Python. In this talk I'll look at the general best practices and techniques we can use to decrease memory consumption, cold start times for Java Serverless development on AWS including GraalVM (Native Image) and AWS own offering SnapStart based on Firecracker microVM snapshot and restore and CRaC (Coordinated Restore at Checkpoint) runtime hooks. I'll also provide a lot of benchmarking on Lambda functions trying out various deployment package sizes, Lambda memory settings, Java compilation options and HTTP (a)synchronous clients and measure their impact on cold and warm start times.

In this talk, we’ll use a standard serverless application that uses API Gateway, Lambda, DynamoDB, SQS, Step Functions (and other AWS-managed services). We'll explore how Amazon DevOps Guru recognizes operational issues and anomalies like increased latency and error rates (timeouts, throttling, and resource limits) and integrate DevOps Guru with PagerDuty to provide even better incident management. Amazon DevOps Guru analyzes data like application metrics, logs, events, and traces to establish baseline operational behavior and then uses ML to detect anomalies. The service uses pre-trained ML models that are able to identify spikes in application requests, so it knows when to alert and when not to.

There is a misunderstanding that everything is possible with the Serverless Services in AWS. For example, the misunderstanding that your Lambda function may scale without limitations. But each AWS service (not only Serverless) has a big list of quotas that everybody needs to be aware of, understand, and take into account during the development. In this talk, I'll explain the most important quotas (in terms of scaling, but not only that) of Serverless services like API Gateway, Lambda, DynamoDB, SQS, and Aurora Serverless and how to architect your solution with these quotas in mind.

Java is for many years one of the most popular programming languages, but it used to have hard times in the Serverless Community. Java is known for its high cold start times which may heavily impact the latencies of your application. But the times change: Community and AWS as a cloud providers improve things steadily for Java developers. In this talk we look at the best practices, features and possibilities AWS offers for the Java developers to reduce the cold start times like GraalVM Native Image and AWS Lambda SnapStart based on CRaC (Coordinated Restore at Checkpoint) project.

Java is for many years one of the most popular programming languages, but it used to have hard times in the Serverless Community. Java is known for its high cold start times which may heavily impact the latencies of your application. But the times change: Community and AWS as a cloud providers improve things steadily for Java developers. In this talk we look at the best practices, features and possibilities AWS offers for the Java developers to reduce the cold start times like GraalVM Native Image and AWS Lambda SnapStart based on on FirecrackerVM snapshot and CRaC (Coordinated Restore at Checkpoint) project.

This document summarizes Amazon CodeCatalyst and DevOps Guru, which help revolutionize the DevOps lifecycle. Amazon CodeCatalyst allows developers to create serverless projects that include code, development environments, CI/CD pipelines, and issue/report tracking. DevOps Guru uses machine learning to detect operational issues in services like DynamoDB, API Gateway, and Lambda by analyzing metrics to find anomalies and reduce human intervention. It provides both reactive insights for existing issues and proactive insights to predict future problems.

In this talk we’ll use a standard Serverless application which uses of API Gateway, Lambda, DynamoDB, SQS, Step Functions (and other AWS managed services) and explore how Amazon DevOps Guru recognizes operational issues like increased latency and error rates (timeouts, throttling and resource limits) and integrate DevOps Guru with PagerDuty for providing even better incident management. Amazon DevOps Guru analyzes data like application metrics, logs, events, and traces to establish baseline operational behavior and then uses ML to detect anomalies. The service uses pre-trained ML models that are able to identify spikes in application requests, so it knows when to alert and when not to.

There is a misunderstanding, that everything is possible with the Serverless Services in AWS, for example that your Lambda function may scale without limitations . But each AWS service (not only Serverless) has a big list of quotas that everybody needs to be aware of, understand and take into account during the development. In this talk I'll explain the most important quotas of the Serverless Services like API Gateway, Lambda, DynamoDB, SQS and Aurora Serverless and how to architect your solution with these quotas in mind.

Java is for many years one of the most popular programming languages, but it used to have hard times in the Serverless Community. Java is known for its high cold start times which may heavily impact the latencies of your application. But the times change: Community and AWS as a cloud providers improve things steadily for Java developers. In this talk we look at the best practices, features and possibilities AWS offers for the Java developers to reduce the cold start times like GraalVM Native Image and AWS Lambda SnapStart based on CRaC (Coordinated Restore at Checkpoint) project.

Java is for many years one of the most popular programming languages, but it used to have hard times in the Serverless Community. Java is known for its high cold start times and high memory footprint. For both you have to pay to the cloud providers of your choice. That's why  most developers tried to avoid using Java for such use cases. But the times change: Community and cloud providers improve things steadily for Java developers. In this talk we look at the features and possibilities AWS cloud provider offers for the Java developers and look the most popular Java frameworks, like Micronaut, Quarkus and Spring (Boot) and look how (AOT compiler and GraalVM Native Image play a huge role) they address Serverless challenges and enable Java for broad usage in the Serverless world. We'll also look into AWS Lambda SnapStart feature based on CRaC (Coordinated Restore at Checkpoint) project which also reduces the cold start time of Java Serverless application on AWS. We also look into the tools which help us figure out the optimal balance between Lambda memory footprint, invocation time and execution cost.

The document compares GitHub Copilot, Amazon CodeWhisperer, and ChatGPT for Java developers. It provides an overview of each tool, compares their programming language support, IDE support, and pricing. It demonstrates their abilities for general tasks, simple functions, more complex algorithms, JUnit testing, and Spring Boot web development. It concludes that while the tools provide helpful suggestions, developers are still needed to ensure correctness and efficiency. GitHub Copilot and ChatGPT benefit from OpenAI, while Amazon CodeWhisperer needs quality improvements for Java but may leverage AWS services.

Vadym Kazulkin presented on AWS Lambda SnapStart, which aims to reduce cold start times for Java functions on AWS Lambda. SnapStart works by saving snapshots of the JVM state during a "priming" invocation and restoring it on subsequent cold starts. This can reduce cold start times from seconds to milliseconds. However, SnapStart currently only supports Java 11/17 runtimes and some limitations remain around deployment time and full cold start measurement. Priming the application before taking snapshots can further reduce cold starts but with tradeoffs around additional Lambda costs and optimization time.

I will introduce two AWS services: CodeGuru and DevOps Guru. CodeGuru Reviewer uses ML and automated reasoning to automatically identify critical issues, security vulnerabilities, and hard-to-find bugs during application development. DevOps Guru analyzes data like application metrics, logs, events, and traces to establish baseline operational behavior and then uses ML to detect anomalies. It does this by having the ability to correlate and group metrics together to understand the relationships between those metrics, so it knows when to alert.

In this talk we’ll build a standard Serverless application which uses of API Gateway, Lambda and DynamoDB and explore how Amazon DevOps Guru recognizes operational issues like increased latency and error rates (timeouts and throttles) and integrate DevOps Guru with PagerDuty for providing even better incident management Amazon DevOps Guru analyzes data like application metrics, logs, events, and traces to establish baseline operational behavior and then uses ML to detect anomalies. The service uses pre-trained ML models that are able to identify spikes in application requests, so it knows when to alert and when not to.

In this talk I will compare 2 services which aim at automatically identifing critical issues, security vulnerabilities, and hard-to-find bugs during application development: Amazon CodeGuru and SonarQube from the perspective of the Java developer on AWS. Amazon CodeGuru Reviewer uses ML and automated reasoning to provide recommendations to developers on how to fix issues to improve code quality and dramatically reduce the time it takes to fix bugs before they reach customer-facing applications and result in a bad experience. SonarQube is an open-source platform for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities on 20+ programming languages. SonarQube offers reports on duplicated code, coding standards, unit tests, code coverage, code complexity, comments, bugs, and security vulnerabilities

Java is for many years one of the most popular programming languages, but it used to have hard times in the Serverless Community. Java is known for its high cold start times and high memory footprint. For both you have to pay to the cloud providers of your choice. That's why most developers tried to avoid using Java for such use cases. But the times change: Community and cloud providers improve things steadily for Java developers. In this talk we look at the features and possibilities AWS cloud provider offers for the Java developers and look the most popular Java frameworks, like Micronaut, Quarkus and Spring (Boot) and look how (AOT compiler and GraalVM native images play a huge role) they address Serverless challenges and enable Java for broad usage in the Serverless world.

This document discusses Projects Valhalla and Loom in Java. Project Valhalla aims to introduce value types to improve memory usage and performance. It plans to unify the Java type system by introducing value classes, primitive classes, and reference projections. Project Loom introduces virtual threads and continuations to enable simple and scalable concurrent programming using structured concurrency. Both projects are currently in preview stages in JDK 19.