This page is currently being updated (as speaker confirm)
Cloud Native: why, oh why? by Emmanuel Bernard (twitter)
People are going Cloud Native, are going for microservices. But why?
In this session, we will discuss what made these new architecture style possible, why and with which objective should we embrace them. And last but not least, let’s explore some of the key problems you will encounter: are you resilient and responsive in a systemic manner, why not? Communication, how to handle the explosion? etc.After this session, you will be armed with a better understanding of your gaps and what are the next steps in your Cloud Native and microservices journey.
Reacting to the future of application architecture by Grace Jansen (twitter)
Ever wondered how honeybees have come to be some of the world’s most efficient architects?
Learn how we can all use mother nature’s expertise to better architect our software solutions to be more reactive, responsive and resilient through reactive architecture frameworks.
I will be explaining the principles of reactive systems (including the key points behind the reactive manifesto) and using bee hives and the social behavior of bees to help visualize and understand the benefits of these principles.
Containerization crossroads: Experiences-Experiments-Expectations by Ana-Maria Mihalceanu (twitter)
Containers seem like a technology that came out of nowhere to improve application development, yet the idea dates since the 1970s when the concept was first employed on Unix systems to better isolate application code. Containers evolved, bringing forth abstraction capabilities that are broadly applied within enterprise IT.
However, expectations grow regardless if you just started your quest for flexible application development or juggling expertly with Microservices, Docker, Kubernetes.
Let’s debate lessons learned and experiment to meet expectations!
Quarkus why, how and what by Emmanuel Bernard (twitter)Quarkus: Supersonic Subatomic Java. Understand why how and what Quarkus brings to Java app developers
Microservices, rapid scalability & high density deployment platforms like Kubernetes require apps with low memory usage and fast boot time. Java had been the outsider due to its focus on throughput at the expense of CPU & RAM.No more.
Enter Quarkus, a microservices Java stack bringing your favorite libs (Hibernate, vert.x, Camel, RESTEasy …) to GraalVM and HotSpot with low memory usage and fast boot time. Enough to swim in containers like fish in water.
Data is usually the hardest part, lets demonstrate Quarkus with persistence and Hibernate ORM. Come explore live reload, opinionated persistence with Hibernate Panache, testing, GraalVM native compilation and more.
Since Quarkus is better lived than talked, expect a heavy demo session.
Quarkus is not only for REST and CRUD applications. Its reactive nature paves the road to a new class of applications ranging from IOT gateway to data streaming use cases. This talk explains how this reactive flavor works and how you can build event-driven microservices with Quarkus. It covers Websockets, AMQP, Kafka… Last but not least, the resulting set of microservices is a reactive system. It handles request even when some microservices are failing, and scale up and down depending on the load.Quarkus provides a supersonic development experience and a subatomic execution environment thanks to its integration with GraalVM. But, that’s not all. Quarkus also unifies the imperative and reactive paradigm. Let’s dig into this. This talk is about the reactive side of Quarkus and how you can use it to implement reactive and event-driven microservices.
Reactive code may look convoluted, but in Quarkus, the proposed model has been tailored to be as close as possible from your imperative code. Just a set of annotations and types gives you the ability to interact with Apache Kafka, handle requests asynchronously, implement data streaming processing, and so on.
From WebSockets to Kafka integration and reactive streams, this talk shows all you need to know to build a reactive system with Quarkus.
Feedback about passage of existing applications to AngularJS & Angular and new applications to react during their development in micro front end architecture.
Microservices are so hype right now that they had their very own Voxxed Days event, and perhaps you’ve already fallen for them and are replacing your good old monolith for new shiny microservices on the back-end.
That’s what Micro Frontend is and that’s what we’ve done at Saagie. In this talk I’d like to give you feedback on the different architectures we’ve tried, their pros and cons and help you find which one would be the best for you, just in case you’d like to opt for the dark and crazy side of front-end.
All you need to know to get started with microservices on Kubernetes by Alain Regnier (twitter)
Gold introduction on leveraging kubernetes to build a microservices based application. Lot of tips ands experience feedback.
This presentation will explain how to build a microservices based application on kubernetes.
After covering the basic concepts and the various kubernetes resources required for our architecture, we will go through the creation and deployment of a concrete example. We will also look at common tasks such as component update and issues investigation. Finally we will discuss various features of the architecture such as service discovery, redundancy, scaling and autohealing…
The presentation will include tips and feedback from real life examples.
Transactions in your micro-services architecture by Rudy De Busscher (twitter)
This session shows how you can use MicroProfile Long Running Actions to achieve the eventual consistency state in an easy way when you are using JAX-RS resources. You only need to write your business logic and the changes when the overall transaction is closed successfully or cancelled. There is no need to write some infrastructure code to achieve this.
How can you make different pieces of your unit of work consistent in the distributed setup of your micro-service application?
You associate the term transaction probably with a database, but the data source can be anything including a database in the micro-service world.
The MicroProfile Long Running Actions specification is based on sagas and the OASIS LRA transaction model specification. It defines the framework to guarantee the eventual consistency requirement using compensating actions for example.
This session will explain you the challenges and concepts of the MP LRA framework. And of course, you can see it in action with various demos.
I intend to share my 2-years’ experience from OLX Group as a backend developer, building microservices and maintaing the monolith(s).
Nowadays most of the developers sooner or later would run into a fun but scary challenge: there is an ancient monolith that needs to be split into microservices, otherwise it would reach the critical mass and explode.It seems that everything was already said and done about it, so why we keep talking about it? The journey is long and the road is bumpy. Is there a light at the end of the tunnel for the ones that started losing hope?
Come to my talk if you want to learn how we approached this situation at OLX Group, one of the biggest online classifieds platforms in the world.
I will talk about different architectural strategies that we have tried and how did they work for us.
“Your [developers] were so preoccupied with whether they could, they didn’t stop to think if they should.” –Ian Malcolm
These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice. In this talk, I will show you a set of factors you can apply to help you decide if something deserves to be a microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome.
There are two ways to implement the circuit breaker pattern: white-box à la Hystrix/Resilience4J or black-box à la Istio. Both have pros and cons. Come to this talk to hear more about that!
Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints.
Among them are different libraries e.g. Hystrix and Resilience4J in the Java ecosystem. In particular, they both provide an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability.
In this talk, we will have a look at how Istio and one among Hystrix/Resilience4J implement the Circuit Breaker pattern, and what pros/cons each of them has. Bonus, you’ll be able to choose what library we will focus for the demo.
After this talk, you’ll be able to decide which one is the best fit in your context.
Many developers are being pushed to move to event driven architectures without really understanding what their options are or what new technology choices they need to make. This talk not only give some background so people understand why they are making these choices, but also explain the different ways they could approach the shift. We will also introduce Apache Kafka as this is such a popular technology choice for this architecture.
Any team that has made the jump from building monoliths to building microservices knows the complexities you must overcome to build a system that is functional and maintainable. Building a microservice architecture that is low latency and only communicates using REST APIs is even more tricky, with high latency for requests being a common concern. This talk will explain how you can use events as the backbone of your microservice architecture and build an efficient, event-driven system. It will cover how to get started with designing your microservice architecture and the key requirements any system needs to fulfil. It will also introduce the different patterns you will encounter in event-driven architectures and the advantages and disadvantages of these choices. Finally it will explain why Apache Kafka is a great choice for event-driven microservices.
Monitoring Kubernetes based application is a common practice nowadays. What is changed when moving to Serverless, a microservices environment on steroids. Comparing an established method to a new practice can assist developers in building the right journey to the serverless world.
The software we write does not always work as smoothly as we would like. To know if something went wrong, understand the root cause and fix the problem, we need to monitor our system and get alerts whenever issues pop up. There are many useful tools and practices for Kubernetes based applications. As we adopt serverless architecture can we continue to use the same practice? Unfortunately, the answer is no.
In this session, we will discuss:
The differences between monitoring Kubernetes and serverless based applications
Best practices for serverless monitoring
Methods to efficiently troubleshoot serverless based applications
Join our session and get insights into the monitoring of microservices applications.
This talk is about staying sane when using eventsouring in your microservices.
This combination of half-knowledge and technical confusion leads to many projects that either refactor back to a ‘non-eventsourced’ architecture or reduce eventsourcing to a message queue.
This talk fixes _everything_ wrong with that and is basically a silver bullet.
“Every microservice gets its own database and then use Kafka” is a typical and naive advise, when reading about eventsourcing. If you approach this architectural style this way, you will probably have a really awful time ahead.
Eventsourcing and CQRS are two very useful and popular patterns when dealing with data and microservices. We often find in our customer’s projects, that both have a severe impact on your future options and the maintainability of your architecture. Presentations and articles on both topics are often superficial and do not tackle real world problems like security and compliance requirements.
In this talk we will look at how we tackled eventsourcing at scale successfully and what we learned along the way, including often overlooked issues like security, GDPR, and maintainability. I will summarize our experience while applying eventsourcing and CQRS across multiple large financial and insurance companies over the last 5 years. We will cover the Good, the Not so Good, and the ‘oh my god…all abandon ships!’ when doing eventsourcing in the real world…and see how we solved these issues.
This year, I helped improve developer experience and productivity of my team by migrating 30 microservices to a monorepo. The migration was tricky to do, but we figured it out after a few hiccups. We would have loved to have guidelines to help us perform the migration and this is what I plan to give to the audience.
Five years ago, my company decided to switch to microservices. In five year, we grew our architecture to 30 microservices, organised in several repositories. The growing number of microservices (and, thus, repositories) had a negative impact on our developer experience and productivity, including:
– struggle to perform evolutions across several microservices (like updating dependencies versions)
– time-consuming pull requests in several repositories for a single feature
– difficulty to share best practices between teams
– bugs in production due to partially merged code
To solve this issues, we decided to migrate all 30 microservices to a monorepo.
Over the course of several weeks, we had a team dedicated to performing the migration. We migrated all the microservices while:
– preserving git history of every single microservice
– keeping the Continuous Integration flow fast
– adding tools to further improve developer experience and productivity
– and introducing zero bugs in production!
This talk will give you the plan to painlessly migrate your microservices to a monorepo as well as solutions to address the major pitfalls of such a migration.
Most people think that event-driven choreographies are a must to build proper de-coubled microservices. That leads to a lot of problems I saw in a lot of real-life projects by know. I want to share that by using an easy-to-understand real-life example and explain how to better balance orchestration and choreography. I am convinced this will help most microservice projects I know to survive in the long run – and I get a lot of great feedback around it that (e.g. QCon voted 96% green).
Event-driven architectures enable nicely decoupled microservices and are fundamental for decentral data management. However, using peer-to-peer event chains to implement complex end-to-end logic crossing service boundaries can accidentally increase coupling. Extracting such business logic into dedicated services reduces coupling and allows to keep sight of larger-scale flows – without violating bounded contexts, harming service autonomy or introducing god services. Service boundaries get clearer and service APIs get smarter by focusing on their potentially long running nature. I will demonstrate how the new generation of lightweight and highly-scalable state machines ease the implementation of long running services. Based on my real-life experiences, I will share how to handle complex logic and flows which require proper reactions on failures, timeouts and compensating actions and provide guidance backed by code examples to illustrate alternative approaches.
Lots of people use Kafka. Lots of people get data from other systems into Kafka, and out of Kafka to other systems.
Not enough people use “Kafka Connect”, the integration API of Apache Kafka.
This talk introduces what it is, and why people should use it instead of trying to write their own integration code. It walks through just enough of the framework’s architecture for people to understand how to use it, and it highlights common issues that people encounter when using it.
Integrating Apache Kafka with other systems in a reliable and scalable way is often a key part of a streaming platform. Fortunately, Apache Kafka includes the Connect API that enables streaming integration both in and out of Kafka. Like any technology, understanding its architecture and deployment patterns is key to successful use, as is knowing where to go looking when things aren’t working.
This talk will discuss the key design concepts within Kafka Connect and the pros and cons of standalone vs distributed deployment modes. We’ll do a live demo of building pipelines with Kafka Connect for streaming data in from databases, and out to targets including Elasticsearch. With some gremlins along the way, we’ll go hands-on in methodically diagnosing and resolving common issues encountered with Kafka Connect. The talk will finish off by discussing more advanced topics including Single Message Transforms, and deployment of Kafka Connect in containers.
Building a Customer Facing Analytics Platform by Laura Kirby (twitter)
My team created a real-time data analytics platform using Kafka, Spark, Cassandra and Ruby on Rails. Spark parses and writes the data to Cassandra and Kafka. Our Rails application handles GET requests and websockets. Our customers now have access to real-time & highly detailed data.
Within IBM, I work on a product called Aspera. Aspera is a high speed data transfer service used by companies like Netflix, Disney and Amazon. For every millisecond that a transfer is active, we record data about the status of a transfer.We first tried Redis; however, it could not keep up with the high volume of writes and complex queries. We decided to try out Cassandra, since its strength is writing quickly and growing efficiently. We implemented a Kafka service to receive data from our daemon. With the use of Kafka, we were able to stream data about active transfers in realtime. We modified the Ruby on Rails application to interface with Kafka and Cassandra. For realtime tables on the frontend, we create a websocket and pass streaming data in JSON format from Kafka. For historical data, we make Cassandra queries, and again send responses to the frontend in JSON format.
Cloud Run, serverless containers in action by Guillaume Laforge (twitter)
It’s gonna be a brand new talk, likely with a few intro slides, but will be mostly with various demos of containers with a serverless sauce.
The “serverless” buzzword was popularized thanks to FaaS platforms (Function-as-a-Service). However, serverless goes beyond just functions. Even traditional Platform-as-a-Service solutions also exhibit serverless characteristics (managed infrastructure, auto-scaling capabilities, pay for usage), when they’re letting developers push their apps as the unit of deployment.
Similarly, a container is just another way to package your business logic. And that’s what Google Cloud Run is all about: you package your code in a container. You decide to use any language, runtime or library, as long as it runs in a container that can receive incoming HTTP requests.
Cloud Run is a fully-managed product that scales your container images from 0 to n depending on traffic, and you pay proportionally to that usage. It can also run in Google’s managed Kubernetes clusters (GKE) giving you more control on the machines running your workloads.
Last but not least, you’re not tied to the Google Cloud Platform at all, as Cloud Run builds atop the Knative serverless building blocks for Kubernetes. You can also deploy and scale your containers on other cloud providers or on-premises, thanks to the openness and portability brought by Knative.
After an overview of Cloud Run, its developer experience, we’ll go through various demos to watch your serverless containers in action!
Helm your way with Kubernetes by Ana-Maria Mihalceanu (twitter)
Changes, even those that represent improvement, are always accompanied by obstacles and discomforts.
Kubernetes can become very complex with all the objects that need to be handled in addition to releases that you operate with. The goal of this session: address complexity with development passion.
In this session I will explain and demonstrate live how you can simplify Kubernetes complexity with Helm: templates, values, requirements and pod specifications made easier, maintainable and reusable.
Attendees will, by the end of the talk:
– understand how to use contract testing as a tool to enable confident delivery
– how to set up contract testing
– key pitfalls to avoid when using it in a microservices context
– how to migrate from existing delivery to independent continuous delivery
This talk will contain real world examples of what we did as a company and how it changed our approach to delivery. I believe the topic of breaking up monolithic CI is important since we can do a lot of good work around microservices but still deliver in a monolithic way, which hinders a lot of the benefits of the microservices approach. We need varied and new approaches to testing and a team-lead focus on quality which I will communicate through my talk.
At Mettle, we built our application as microservices from the start yet still fell into the trap of a monolithic deploy. We built the services independently but then deployed all the changes once a week. The key problem was: how do we know that when we deploy this one service it won’t break everything? To fix this, we used consumer driven contract testing (using Pact) to make our services independently deployable and move towards flexible continuous delivery. Now all changes are deployed straight to production with confidence.
I’m going to share our learnings so you can get the most out of Pact and avoid the pitfalls we found along the way. We will also spend time exploring the benefits of contract testing and how to implement it in your services and CI process. You should come away with a head start in understanding contracts and how it could give you confidence to deliver more frequently.
This talk covers the recent advances that make it possible to build a deploy serverless applications on a standard Kubernetes basis using Knative Serving. This in turn means that serverless is no-longer limited to using proprietary cloud functions frameworks such as Amazon Lamba, Azure Cloud Functions, Google Cloud Functions or OpenWhisk – you can easily use open source tools to develop and deploy functions that build not existing Java frameworks, and deploy as serverless workloads on Knative.
Function-as-a-service (FaaS) and serverless platforms increase productivity, enabling you to focus on application code, with the platform taking care of how to deploy, configure, run, and scale the code. They do however require you to adopt a new programming model, creating generic handlers or actions that lack the expressive APIs that you get from frameworks and standards such as Jakarta EE. In this session, you’ll learn how it’s now possible to create FaaS- and serverless-based applications using the same APIs you use today such as JAX-RS and you’ll see a live demo of an application being built and deployed as a cloud native application on Kubernetes using a combination of open source tools and Knative serving.
The containers technology revolutionized the way we architect, develop and ship our applications, and brought Java developers closed than ever to “Write once run anywhere”!
However, Containers added some new layers of abstraction: We have to write a Dockerfile, setup Docker daemon, wait for builds to complete, fix any errors and finally push the image to registry! Wasn’t building a (j|w|e)ar easier?!
This TIA, explores what Jib, an open source fast image builder Java library from Google, brought to the table, and how it speeds up development by finely separating the application across multiple layers and incrementally building the image, by inferring what it needs from Maven or Gradle project. We’ll also discuss the concept of “Distroless” container Images and how to benefit from it.
An introduction to Apache Kafka – this is Event Streaming, not just Messaging by Katherine Stanley (twitter)
Processing streams of data in real-time and being able to react to that data is a powerful tool for software developers. It allows them to build applications that can evolve quickly and understand the requirements of their users. Apache Kafka is an open-source event streaming platform that is being widely adopted as the core technology for these new event-based architectures. It brings with it a new set of terms, such as topics and consumer groups and a distinctive shift away from traditional message queues. Kafka can be used in a variety of ways and this session will give developers the opportunity to see how it can make their projects even better. As a developer on IBM Event Streams which is built on top of Apache Kafka, I have experience with building and deploying Kafka-based applications, both in Java and other languages.
The amount of data the world produces is growing exponentially every year and many companies are realising the potential of harnessing this data. A lot of this is generated in the form of a never ending stream of events, with publishers creating the events and subscribers consuming them in many different ways. This is where Apache Kafka comes in, Kafka isn’t just a messaging system – it’s an event streaming platform. This session will introduce Kafka and explain concepts such as topic partitioning, consumer groups and exactly-once semantics. Finally, learn about more advanced concepts such as stream processing using the Java Kafka Streams library, cross-datacenter replication and integration with other messaging systems.
Building Supersonic, Subatomic, Cloud Native Applications with Quarkus and GraalVM by Emmanuel Bernard (twitter), Clement Escoffier (twitter), Antonio Goncalves (twitter)
Wanna go beyond the hello-world with Quarkus, discovery the internals? Then, Attend this workshop!
Cloud native applications in Java are great, but… Despite a fantastic ecosystem around Java, it falls short in containers, in comparison to Go or Node.js. The initial memory consumption, the startup time, and the optimizations for long-running processes are killer criteria in the cloud. Quarkus is a Kubernetes native Java stack tailored for GraalVM and OpenJDK. With Quarkus you can compile your application into a native executable, reduce the startup time to a few milliseconds, reduce the memory consumption to a few MB, and make applications ideally suited to run in containers.This workshop explores why it matters and how you can leverage Quarkus and GraalVM to build supersonic, subatomic, cloud-native applications.In this workshop, you will learn how to:
* build Web applications with Quarkus
* use Hibernate and Hibernate with Panache
* build event-driven microservices with Apache Kafka
* monitor your applicationsAll the applications built in this workshop are run on top of the JVM but also compiled as native executables.
You plan to deploy your application on Kubernetes but don’t know where to start ?
Our workshop will help you to achieve that:
* Through hands-on exercises using the “Hipster Shop” app (here), we will recall the main concepts of Kubernetes.
* To improve resilience, monitoring and security, you will deploy and setup Istio to manage your application.
We’ll take some time to focus on one of the core components of Istio, the Envoy Proxy.
* You’ll deploy Kiali (here) over Istio to get a visual overview of your application health.