![\"\"](\"https:\/\/i3.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/06\/large-Voxxed_Days_Microservices_date_2019-01-2-300x116.png\")
<\/p>\nKeynotes<\/h1>\n\n- \n
![\"Emmanuel]()
Emmanuel Bernard<\/p><\/div>\n
Cloud Native: why, oh why?\u00a0<\/strong>by Emmanuel Bernard (twitter<\/a>)
\n<\/span>People are going Cloud Native, are going for microservices. But why?
\n<\/em>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.<\/p>\n <\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text css=”.vc_custom_1564907247115{background-position: 0 0 !important;background-repeat: no-repeat !important;}”]\n
\n- Reacting to the future of application architecture <\/strong>by Grace Jansen (twitter<\/a>)<\/span><\/span><\/span><\/span><\/span><\/span>\n
![\"\"]()
Grace Jansen<\/p><\/div>\n
Ever wondered how honeybees have come to be some of the world’s most efficient architects?<\/em>
\nLearn 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.
\nI 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.
\n<\/span><\/span><\/span><\/span><\/p>\n <\/p>\n
<\/div>\n<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text css=”.vc_custom_1566231209478{background-position: 0 0 !important;background-repeat: no-repeat !important;}”]\n\n- \n
![\"\"]()
Ana-Maria Mihalceanu<\/p><\/div>\n
Containerization crossroads: Experiences-Experiments-Expectations <\/strong>by Ana-Maria Mihalceanu (twitter<\/a>)<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\nContainers 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.
\nHowever, expectations grow regardless if you just started your quest for flexible application development or juggling expertly with Microservices, Docker, Kubernetes.
\nLet’s debate lessons learned and experiment to meet expectations!<\/span><\/span><\/span><\/span><\/p>\n<\/div>\n<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n\n- \n
![\"\"]()
Sebastien Stormacq<\/p><\/div>\n
Past, Present and Future of Microservices\u00a0 <\/strong>by Sebastien Stormacq (twitter<\/a>)<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\nLet’s reflect on the Microservices architectural pattern, how the industry came there, what are today’s challenges and what can we expect in the future? Seb uses is 25+ year of experience in the industry and key position as observer of cloud infrastructure, talking with many customers in different industries and geographies to identify our industry’s trends<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n[\/vc_column_text][vc_column_text]\nConferences (45 min)<\/h1>\n[\/vc_column_text][vc_column_text]\n\n- \n
![\"Emmanuel]()
Emmanuel Bernard<\/p><\/div>\n
Quarkus why, how and what\u00a0<\/strong>by Emmanuel Bernard (twitter<\/a>)<\/span>Quarkus: Supersonic Subatomic Java. Understand why how and what Quarkus brings to Java app developers
\n<\/em>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.
\nEnter 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.<\/p>\nData 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.
\nSince Quarkus is better lived than talked, expect a heavy demo session.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n- Subatomic, Supersonic, Reactive\u00a0<\/strong>by\u00a0Clement Escoffier (twitter<\/a>)\n
![\"Clement]()
Clement Escoffier<\/p><\/div>\n
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.<\/em>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.
\nReactive 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.
\nFrom WebSockets to Kafka integration and reactive streams, this talk shows all you need to know to build a reactive system with Quarkus.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n
\n- Micro Frontend: the microservice puzzle extended to frontend<\/strong> by Audrey Neveu \u00a0(twitter<\/a>)\n
![\"Audrey]()
Audrey Neveu<\/p><\/div>\n
Feedback about passage of existing applications to AngularJS & Angular and new applications to react during their development in micro front end architecture.<\/em>
\nMicroservices are so hype right now that they had their very own Voxxed Days event, and perhaps you\u2019ve already fallen for them and are replacing your good old monolith for new shiny microservices on the back-end.<\/p>\nBut have you ever considered doing the same on the front-end? Even hype-r (or crazy-er, we\u2019ll let you judge), have you tried mixing different JavaScript frameworks (let\u2019s say AngularJS, Angular and React for example) in a Single Page Application?<\/p>\n
That\u2019s what Micro Frontend is and that\u2019s what we\u2019ve done at Saagie. In this talk I\u2019d like to give you feedback on the different architectures we\u2019ve tried, their pros and cons and help you find which one would be the best for you, just in case you\u2019d like to opt for the dark and crazy side of front-end.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- \n
![\"Alain]()
Alain Regnier<\/p><\/div>\n
All you need to know to get started with microservices on Kubernetes<\/strong> by Alain Regnier (twitter<\/a>)
\nGold introduction on leveraging kubernetes to build a microservices based application. Lot of tips ands experience feedback.<\/em>
\nThis presentation will explain how to build a microservices based application on kubernetes.
\nAfter 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…
\nThe presentation will include tips and feedback from real life examples.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n
\n- \n
![\"Rudy]()
Rudy De Busscher<\/p><\/div>\n
Transactions in your micro-services architecture<\/strong> by Rudy De Busscher (twitter<\/a>)
\nThis 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.
\n<\/em>How can you make different pieces of your unit of work consistent in the distributed setup of your micro-service application?
\nYou associate the term transaction probably with a database, but the data source can be anything including a database in the micro-service world.
\nThe 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.
\nThis 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.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n
\n- How I Learned to Stop Worrying and Love the\u00a0Monolithe<\/strong> by\u00a0Ania Wyrwinska\u00a0\u00a0(twitter<\/a>)\n
![\"\"]()
Ania Wyrwinska<\/p><\/div>\n
I intend to share my 2-years’ experience from OLX Group as a backend developer, building microservices and maintaing the monolith(s).
\n<\/em>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?
\nCome 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.
\nI will talk about different architectural strategies that we have tried and how did they work for us.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n
\n- Responsible Microservices<\/strong> by Nate Schutta @ntschutta (twitter<\/a>)\n
![\"\"]()
Nate Schutta<\/p><\/div>\n
\u201cYour [developers] were so preoccupied with whether they could, they didn’t stop to think if they should.\u201d \u2013Ian Malcolm
\n<\/em>(paraphrased).
\n<\/em>These days, you can\u2019t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan\u2019s 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\u2019ll also look at what we need to do to maintain a healthy micro(services)biome.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n
\n- Battle of the Circuit Breakers: Istio vs Hystrix\/Resilience4J<\/strong> by Nicolas Frankel \u00a0(twitter<\/a>)\n
![\"Nicolas]()
Nicolas Frankel<\/p><\/div>\n
There are two ways to implement the circuit breaker pattern: white-box \u00e0 la Hystrix\/Resilience4J or black-box \u00e0 la Istio. Both have pros and cons. Come to this talk to hear more about that!
\n<\/em>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.<\/p>\nAmong 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.<\/p>\n
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.<\/p>\n
After this talk, you\u2019ll be able to decide which one is the best fit in your context.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- Creating event-driven microservices: the why, how and what <\/strong>by Katherine Stanley \u00a0(twitter<\/a>)\n
![\"Katherine]()
Katherine Stanley<\/p><\/div>\n
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.<\/em><\/p>\nAny 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.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- Monitoring in the Microservices world – Kubernetes Vs. Serverless based applications <\/strong>by Erez Berkner \u00a0(twitter<\/a>)\n
![\"Erez]()
Erez Berkner<\/p><\/div>\n
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.
\n<\/em><\/p>\nThe 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.<\/p>\n
In this session, we will discuss:<\/p>\n
The differences between monitoring Kubernetes and serverless based applications
\nBest practices for serverless monitoring
\nMethods to efficiently troubleshoot serverless based applications<\/p>\n
Join our session and get insights into the monitoring of microservices applications.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- Event Sourcing – You are doing it wrong <\/strong>by David Schmitz \u00a0(twitter<\/a>)\n
![\"David]()
David Schmitz<\/p><\/div>\n
This talk is about staying sane when using eventsouring in your microservices.
\nThis 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.
\nThis talk fixes _everything_ wrong with that and is basically a silver bullet.<\/em><\/p>\n“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.<\/p>\n
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.<\/p>\n
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.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- Looking back on migrating 30 microservices to a monorepository <\/strong>by Darya Talanina \u00a0(twitter<\/a>)\n
![\"Darya]()
Darya Talanina<\/p><\/div>\n
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.<\/em><\/p>\nFive 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:<\/p>\n
– struggle to perform evolutions across several microservices (like updating dependencies versions)
\n– time-consuming pull requests in several repositories for a single feature
\n– difficulty to share best practices between teams
\n– bugs in production due to partially merged code<\/p>\n
To solve this issues, we decided to migrate all 30 microservices to a monorepo.<\/p>\n
Over the course of several weeks, we had a team dedicated to performing the migration. We migrated all the microservices while:<\/p>\n
– preserving git history of every single microservice
\n– keeping the Continuous Integration flow fast
\n– adding tools to further improve developer experience and productivity
\n– and introducing zero bugs in production!<\/p>\n
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.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- Complex event flows in distributed systems <\/strong>by Bernd R\u00fccker \u00a0(twitter<\/a>)\n
![\"\"]()
Bernd R\u00fccker<\/p><\/div>\n
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).<\/em><\/p>\nEvent-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.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- From Zero to Hero with Kafka Connect <\/strong>by Robin Moffatt \u00a0(twitter<\/a>)\n
![\"\"]()
Robin Moffatt<\/p><\/div>\n
Lots of people use Kafka. Lots of people get data from other systems into Kafka, and out of Kafka to other systems.
\n<\/em>Not enough people use “Kafka Connect”,\u00a0 <\/em>the integration API of Apache Kafka<\/span>. <\/em>
\nThis 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. <\/em><\/p>\nIntegrating 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.<\/p>\n
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.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- GraalVM and MicroProfile: A Polyglot Microservices Solution <\/strong>by Roberto Cortez \u00a0(twitter<\/a>)\n
![\"\"]()
Roberto Cortez<\/p><\/div>\n
Lots of people use Kafka. Lots of people get data from other systems into Kafka, and out of Kafka to other systems.
\n<\/em>Not enough people use “Kafka Connect”,\u00a0 <\/em>the integration API of Apache Kafka<\/span>. <\/em>
\nThis 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. <\/em><\/p>\nIntegrating 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.<\/p>\n
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.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- The Evolution From Monolith to Microservices to Serverless and Beyond <\/strong>by Hugh McKee (twitter<\/a>)\n
![\"\"]()
Hugh McKee<\/p><\/div>\n
Monoliths, microservices, serverless, and event meshes, things are changing and evolving so fast these days. In this talk, we will look at what is changing, and more importantly, what remains relatively constant. And just for fun, we will take a look at what the future may bring in the not too distant future.<\/p>\n
If you are a developer or an architect, the odds are that you grew up building systems that are now commonly known as monoliths. In the last few years, we’ve seen a significant evolutionary shift to systems composed of microservices. Today we are witnessing the birth of serverless. The rate of evolutionary change is accelerating. But what is changing and what remains the same? In this talk, we will look at the evolution from the monolith to serverless seeking to extract the variables and the constants. We will also look at the progression from serverless to an inevitable future of frictionless computing.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n- Micronaut Deep Dive by Graeme Rocher (twitter<\/a>)<\/strong>\n
![\"\"]()
Graeme Rocher<\/p><\/div>\n
Many developers are looking to understand more than the basics of Micronaut this talk will be unique for them and how build components on Micronaut from the creator of Micronaut<\/em><\/p>\nThis session is for developers looking to go beyond the basics with Micronaut, a new microservices and serverless framework for Java, Kotlin, and Groovy. Taking an extensive look at how advanced features such as dependency injection (DI), aspect-oriented programming (AOP), and ahead-of-time (AOT) compilation work, the creator of Micronaut, Graeme Rocher, will walk attendees through Micronaut\u2019s elegant programming model. Attendees will come away with a better understanding about the motivations behind Micronaut’s design.<\/p>\n
<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n- Event-Driven Microservices, the Sense, the Non-sense and a Way Forward <\/strong>by Allard Buijze (twitter<\/a>)\n
![\"\"]()
Allard Buijze<\/p><\/div>\n
Microservices are around for a reason. Events are a powerful concept when used properly. However, how much time are you spending on infrastructure related code, compared to actual business logic that provides value to your customer\/end user? This talk is for inspiration on how to focus on what’s important, without compromises. I’ve done this talk as a closing talk at Goto Amsterdam, where it was extremely well received. It was applauded for the combination of fun, inspiration and practical use.<\/em><\/p>\nMicroservices, and especially their Event-Driven variants, are at the very peak of the hype cycle and, according to some, on their way down. Meanwhile, a large number of success stories and failures have been shared about this architectural style. How do we ensure that we don’t throw away the baby with the bathwater and end up re-inventing the same concepts again a decade from now?<\/p>\n
In this talk, I want to zoom in on different aspects around microservices. What are the promises made and how did it deliver on those? How did technology surrounding microservices evolve and impact our decisions?<\/p>\n
Lastly, I will look forward. How can we be pragmatic about microservices, avoiding some of the common pitfalls and helping ensure ourselves that we get the promised benefits, but without the pain.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n- Transforming a monolith to an API platform <\/strong>by Philippe Anes (twitter<\/a>) and Abderrazak Bouadma\u00a0(twitter<\/a>)\n
![\"\"]()
Philippe Anes\u00a0 &\u00a0 \u00a0Abderrazak Bouadma<\/p><\/div>\n
APIs are everywhere; over the last few years, APIs have been increasingly considered as one of the most valuable strategies for modern business a.k.a the \u201cAPI Economy\u201d and organizations are very demanding. APIs are also the most common way for microservices to communicate between each other. But designing an API architecture is not that easy, especially when you are migrating a monolith to microservices, you are transitioning a SaaS infrastructure to the cloud and your business is growing very fast.<\/p>\n
During this talk, we will share our experience on how we are leveraging our services with APIs while we are modernizing our platform at Kyriba, a fintech founded 18 years ago and which became a global leader in cloud treasury solutions.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n- Deploying Spring Boot microservices on Azure <\/strong>by Julien Dubois\u00a0(twitter<\/a>)\n
![\"Julien]()
Julien Dubois<\/p><\/div>\n
Azure is the world’s #2 cloud, and Spring Boot is Java’s #1 framework, so using both together makes a lot of sense.<\/em>
\nPlease note I intend to talk about a few top-secret offers that we are preparing on Azure, so I can’t tell you right now, but we should have some really exciting and new content for the conference.<\/em><\/p>\nDid you know Microsoft has a whole engineering team dedicated to Spring Boot, and that for the last 3 years they have ensured that Spring Boot applications work great on Azure? We’ll see how Java’s #1 framework works on one of the world’s top cloud provider, including many tips and news on our latest releases.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n- Supercharge product development with cloud best practices <\/strong>by Sebastien Stormacq (twitter<\/a>)\n
![\"\"]()
Sebastien Stormacq<\/p><\/div>\n
Continuous Integration (CI) and Continuous Delivery (CD) help developers automate the software release process.
\nThe faster you can release new features and fix bugs, the quicker you can innovate and respond to customer needs. AWS provides developer tools that help you automate the end-to-end lifecycle of your serverless applications. In this session, we will discuss methods for automating the deployment of serverless or containerised applications, using services such as AWS CodePipeline and AWS CodeBuild, and techniques such as canary deployments and automatic rollbacks.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
<\/p>\n
\n[\/vc_column_text][vc_column_text]\nTools-in-action (25 min)<\/h1>\n[\/vc_column_text][vc_column_text]\n<\/h1>\n\n- \n
![\"Laura]()
Laura Kirby<\/p><\/div>\n
Building a Customer Facing Analytics Platform<\/strong> by\u00a0Laura Kirby (twitter<\/a>)
\nMy 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.
\n<\/em>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.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n<\/h1>\n\n- \n
![\"\"]()
Guillaume Laforge<\/p><\/div>\n
Cloud Run, serverless containers in action<\/strong> by Guillaume Laforge (twitter<\/a>)
\nIt’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.<\/em><\/p>\nThe \u201cserverless\u201d 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\u2019re letting developers push their apps as the unit of deployment.<\/p>\n
Similarly, a container is just another way to package your business logic. And that\u2019s 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.<\/p>\n
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\u2019s managed Kubernetes clusters (GKE) giving you more control on the machines running your workloads.<\/p>\n
Last but not least, you\u2019re 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.<\/p>\n
After an overview of Cloud Run, its developer experience, we\u2019ll go through various demos to watch your serverless containers in action!<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n- \n
![\"\"]()
Ana-Maria Mihalceanu<\/p><\/div>\n
Helm your way with Kubernetes<\/strong> by Ana-Maria Mihalceanu (twitter<\/a>)<\/p>\nChanges, even those that represent improvement, are always accompanied by obstacles and discomforts.
\nKubernetes 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.<\/p>\n
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.<\/li>\n<\/ul>\n
<\/p>\n[\/vc_column_text][vc_column_text]\n
\n- \u00a0Pact tests: how we split up the monolithic deploy <\/strong>by Phil Hardwick\u00a0 (from mettle \/ twitter<\/a>)Attendees will, by the end of the talk:<\/em>
\n– understand how to use contract testing as a tool to enable confident delivery<\/em><\/p>\n![\"\"]()
Phil Hardwick<\/p><\/div>\n
– how to set up contract testing<\/em>
\n– key pitfalls to avoid when using it in a microservices context<\/em>
\n– how to migrate from existing delivery to independent continuous delivery<\/em><\/p>\nThis 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.<\/em><\/p>\nAt 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.<\/p>\n
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.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n- Jakarta EE – Not just for Servers <\/strong>by Chris Bailey (twitter<\/a>)\n
![\"Emmanuel](\"https:\/\/i2.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2018\/07\/E-BERNARD-150x150.png\")
Emmanuel Bernard<\/p><\/div>\n
Cloud Native: why, oh why?\u00a0<\/strong>by Emmanuel Bernard (twitter<\/a>) <\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text css=”.vc_custom_1564907247115{background-position: 0 0 !important;background-repeat: no-repeat !important;}”]\n Grace Jansen<\/p><\/div>\n Ever wondered how honeybees have come to be some of the world’s most efficient architects?<\/em> <\/p>\n Ana-Maria Mihalceanu<\/p><\/div>\n Containerization crossroads: Experiences-Experiments-Expectations <\/strong>by Ana-Maria Mihalceanu (twitter<\/a>)<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n 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. Sebastien Stormacq<\/p><\/div>\n Past, Present and Future of Microservices\u00a0 <\/strong>by Sebastien Stormacq (twitter<\/a>)<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n Let’s reflect on the Microservices architectural pattern, how the industry came there, what are today’s challenges and what can we expect in the future? Seb uses is 25+ year of experience in the industry and key position as observer of cloud infrastructure, talking with many customers in different industries and geographies to identify our industry’s trends<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n Emmanuel Bernard<\/p><\/div>\n Quarkus why, how and what\u00a0<\/strong>by Emmanuel Bernard (twitter<\/a>)<\/span>Quarkus: Supersonic Subatomic Java. Understand why how and what Quarkus brings to Java app developers 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. Clement Escoffier<\/p><\/div>\n 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.<\/em>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. <\/p>\n[\/vc_column_text][vc_column_text]\n Audrey Neveu<\/p><\/div>\n Feedback about passage of existing applications to AngularJS & Angular and new applications to react during their development in micro front end architecture.<\/em> But have you ever considered doing the same on the front-end? Even hype-r (or crazy-er, we\u2019ll let you judge), have you tried mixing different JavaScript frameworks (let\u2019s say AngularJS, Angular and React for example) in a Single Page Application?<\/p>\n That\u2019s what Micro Frontend is and that\u2019s what we\u2019ve done at Saagie. In this talk I\u2019d like to give you feedback on the different architectures we\u2019ve tried, their pros and cons and help you find which one would be the best for you, just in case you\u2019d like to opt for the dark and crazy side of front-end.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Alain Regnier<\/p><\/div>\n All you need to know to get started with microservices on Kubernetes<\/strong> by Alain Regnier (twitter<\/a>) <\/p>\n[\/vc_column_text][vc_column_text]\n Rudy De Busscher<\/p><\/div>\n Transactions in your micro-services architecture<\/strong> by Rudy De Busscher (twitter<\/a>) <\/p>\n[\/vc_column_text][vc_column_text]\n Ania Wyrwinska<\/p><\/div>\n I intend to share my 2-years’ experience from OLX Group as a backend developer, building microservices and maintaing the monolith(s). <\/p>\n[\/vc_column_text][vc_column_text]\n Nate Schutta<\/p><\/div>\n \u201cYour [developers] were so preoccupied with whether they could, they didn’t stop to think if they should.\u201d \u2013Ian Malcolm <\/p>\n[\/vc_column_text][vc_column_text]\n Nicolas Frankel<\/p><\/div>\n There are two ways to implement the circuit breaker pattern: white-box \u00e0 la Hystrix\/Resilience4J or black-box \u00e0 la Istio. Both have pros and cons. Come to this talk to hear more about that! 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.<\/p>\n 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.<\/p>\n After this talk, you\u2019ll be able to decide which one is the best fit in your context.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Katherine Stanley<\/p><\/div>\n 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.<\/em><\/p>\n 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.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Erez Berkner<\/p><\/div>\n 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.<\/p>\n In this session, we will discuss:<\/p>\n The differences between monitoring Kubernetes and serverless based applications Join our session and get insights into the monitoring of microservices applications.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n David Schmitz<\/p><\/div>\n This talk is about staying sane when using eventsouring in your microservices. “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.<\/p>\n 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.<\/p>\n 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.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Darya Talanina<\/p><\/div>\n 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.<\/em><\/p>\n 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:<\/p>\n – struggle to perform evolutions across several microservices (like updating dependencies versions) To solve this issues, we decided to migrate all 30 microservices to a monorepo.<\/p>\n Over the course of several weeks, we had a team dedicated to performing the migration. We migrated all the microservices while:<\/p>\n – preserving git history of every single microservice 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.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Bernd R\u00fccker<\/p><\/div>\n 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).<\/em><\/p>\n 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.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Robin Moffatt<\/p><\/div>\n Lots of people use Kafka. Lots of people get data from other systems into Kafka, and out of Kafka to other systems. 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.<\/p>\n 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.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Roberto Cortez<\/p><\/div>\n Lots of people use Kafka. Lots of people get data from other systems into Kafka, and out of Kafka to other systems. 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.<\/p>\n 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.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Hugh McKee<\/p><\/div>\n Monoliths, microservices, serverless, and event meshes, things are changing and evolving so fast these days. In this talk, we will look at what is changing, and more importantly, what remains relatively constant. And just for fun, we will take a look at what the future may bring in the not too distant future.<\/p>\n If you are a developer or an architect, the odds are that you grew up building systems that are now commonly known as monoliths. In the last few years, we’ve seen a significant evolutionary shift to systems composed of microservices. Today we are witnessing the birth of serverless. The rate of evolutionary change is accelerating. But what is changing and what remains the same? In this talk, we will look at the evolution from the monolith to serverless seeking to extract the variables and the constants. We will also look at the progression from serverless to an inevitable future of frictionless computing.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n Graeme Rocher<\/p><\/div>\n Many developers are looking to understand more than the basics of Micronaut this talk will be unique for them and how build components on Micronaut from the creator of Micronaut<\/em><\/p>\n This session is for developers looking to go beyond the basics with Micronaut, a new microservices and serverless framework for Java, Kotlin, and Groovy. Taking an extensive look at how advanced features such as dependency injection (DI), aspect-oriented programming (AOP), and ahead-of-time (AOT) compilation work, the creator of Micronaut, Graeme Rocher, will walk attendees through Micronaut\u2019s elegant programming model. Attendees will come away with a better understanding about the motivations behind Micronaut’s design.<\/p>\n <\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n Allard Buijze<\/p><\/div>\n Microservices are around for a reason. Events are a powerful concept when used properly. However, how much time are you spending on infrastructure related code, compared to actual business logic that provides value to your customer\/end user? This talk is for inspiration on how to focus on what’s important, without compromises. I’ve done this talk as a closing talk at Goto Amsterdam, where it was extremely well received. It was applauded for the combination of fun, inspiration and practical use.<\/em><\/p>\n Microservices, and especially their Event-Driven variants, are at the very peak of the hype cycle and, according to some, on their way down. Meanwhile, a large number of success stories and failures have been shared about this architectural style. How do we ensure that we don’t throw away the baby with the bathwater and end up re-inventing the same concepts again a decade from now?<\/p>\n In this talk, I want to zoom in on different aspects around microservices. What are the promises made and how did it deliver on those? How did technology surrounding microservices evolve and impact our decisions?<\/p>\n Lastly, I will look forward. How can we be pragmatic about microservices, avoiding some of the common pitfalls and helping ensure ourselves that we get the promised benefits, but without the pain.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n Philippe Anes\u00a0 &\u00a0 \u00a0Abderrazak Bouadma<\/p><\/div>\n APIs are everywhere; over the last few years, APIs have been increasingly considered as one of the most valuable strategies for modern business a.k.a the \u201cAPI Economy\u201d and organizations are very demanding. APIs are also the most common way for microservices to communicate between each other. But designing an API architecture is not that easy, especially when you are migrating a monolith to microservices, you are transitioning a SaaS infrastructure to the cloud and your business is growing very fast.<\/p>\n During this talk, we will share our experience on how we are leveraging our services with APIs while we are modernizing our platform at Kyriba, a fintech founded 18 years ago and which became a global leader in cloud treasury solutions.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n Julien Dubois<\/p><\/div>\n Azure is the world’s #2 cloud, and Spring Boot is Java’s #1 framework, so using both together makes a lot of sense.<\/em> Did you know Microsoft has a whole engineering team dedicated to Spring Boot, and that for the last 3 years they have ensured that Spring Boot applications work great on Azure? We’ll see how Java’s #1 framework works on one of the world’s top cloud provider, including many tips and news on our latest releases.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n Sebastien Stormacq<\/p><\/div>\n Continuous Integration (CI) and Continuous Delivery (CD) help developers automate the software release process. <\/p>\n Laura Kirby<\/p><\/div>\n Building a Customer Facing Analytics Platform<\/strong> by\u00a0Laura Kirby (twitter<\/a>) Guillaume Laforge<\/p><\/div>\n Cloud Run, serverless containers in action<\/strong> by Guillaume Laforge (twitter<\/a>) The \u201cserverless\u201d 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\u2019re letting developers push their apps as the unit of deployment.<\/p>\n Similarly, a container is just another way to package your business logic. And that\u2019s 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.<\/p>\n 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\u2019s managed Kubernetes clusters (GKE) giving you more control on the machines running your workloads.<\/p>\n Last but not least, you\u2019re 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.<\/p>\n After an overview of Cloud Run, its developer experience, we\u2019ll go through various demos to watch your serverless containers in action!<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n Ana-Maria Mihalceanu<\/p><\/div>\n Helm your way with Kubernetes<\/strong> by Ana-Maria Mihalceanu (twitter<\/a>)<\/p>\n Changes, even those that represent improvement, are always accompanied by obstacles and discomforts. 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.<\/li>\n<\/ul>\n <\/p>\n[\/vc_column_text][vc_column_text]\n Phil Hardwick<\/p><\/div>\n – how to set up contract testing<\/em> 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.<\/em><\/p>\n 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.<\/p>\n 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.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n<\/span>People are going Cloud Native, are going for microservices. But why?
\n<\/em>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.<\/p>\n\n
![\"\"](\"https:\/\/i1.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Grace-Jansen_Plan-de-travail-1-300x300.png\")
\nLearn 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.
\nI 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.
\n<\/span><\/span><\/span><\/span><\/p>\n\n
![\"\"](\"https:\/\/i2.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Ana-Maria-Mihalceanu_Plan-de-travail-1-1.png\")
\nHowever, expectations grow regardless if you just started your quest for flexible application development or juggling expertly with Microservices, Docker, Kubernetes.
\nLet’s debate lessons learned and experiment to meet expectations!<\/span><\/span><\/span><\/span><\/p>\n\n
![\"\"](\"https:\/\/i3.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/08\/Sebastien-Stormacq_Plan-de-travail-1.png\")
\n[\/vc_column_text][vc_column_text]\nConferences (45 min)<\/h1>\n[\/vc_column_text][vc_column_text]\n
\n
\n<\/em>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.
\nEnter 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.<\/p>\n
\nSince Quarkus is better lived than talked, expect a heavy demo session.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n\n
![\"Clement](\"https:\/\/i1.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Clement-Escoffier_Plan-de-travail-1-1-300x300.png\")
\nReactive 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.
\nFrom WebSockets to Kafka integration and reactive streams, this talk shows all you need to know to build a reactive system with Quarkus.<\/li>\n<\/ul>\n\n
![\"Audrey](\"https:\/\/i2.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Audrey-Neveu_Plan-de-travail-1-300x300.png\")
\nMicroservices are so hype right now that they had their very own Voxxed Days event, and perhaps you\u2019ve already fallen for them and are replacing your good old monolith for new shiny microservices on the back-end.<\/p>\n\n
![\"Alain](\"https:\/\/i3.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/06\/ALAIN-R-300x298.png\")
\nGold introduction on leveraging kubernetes to build a microservices based application. Lot of tips ands experience feedback.<\/em>
\nThis presentation will explain how to build a microservices based application on kubernetes.
\nAfter 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…
\nThe presentation will include tips and feedback from real life examples.<\/li>\n<\/ul>\n\n
![\"Rudy](\"https:\/\/i3.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/06\/Rudy-De-Busscher_Plan-de-travail-1-300x300.png\")
\nThis 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.
\n<\/em>How can you make different pieces of your unit of work consistent in the distributed setup of your micro-service application?
\nYou associate the term transaction probably with a database, but the data source can be anything including a database in the micro-service world.
\nThe 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.
\nThis 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.<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/i3.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Ania-Wyrwinska_Plan-de-travail-1_Plan-de-travail-1.png\")
\n<\/em>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?
\nCome 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.
\nI will talk about different architectural strategies that we have tried and how did they work for us.<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/i0.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Nate-Schutta_Plan-de-travail-1-300x300.png\")
\n<\/em>(paraphrased).
\n<\/em>These days, you can\u2019t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan\u2019s 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\u2019ll also look at what we need to do to maintain a healthy micro(services)biome.<\/li>\n<\/ul>\n\n
![\"Nicolas](\"https:\/\/i0.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Nicolas-Frankel_Plan-de-travail-1-300x300.png\")
\n<\/em>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.<\/p>\n\n
![\"Katherine](\"https:\/\/i0.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2018\/07\/Katherine-Stanley-e1562962152897.png\")
\n
![\"Erez](\"https:\/\/i2.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Erez-Berkner_Plan-de-travail-1-300x300.png\")
\n<\/em><\/p>\n
\nBest practices for serverless monitoring
\nMethods to efficiently troubleshoot serverless based applications<\/p>\n\n
![\"David](\"https:\/\/i1.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/David-Schmitz_Plan-de-travail-1-300x300.png\")
\nThis 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.
\nThis talk fixes _everything_ wrong with that and is basically a silver bullet.<\/em><\/p>\n\n
![\"Darya](\"https:\/\/i2.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Darya-Talanina_Plan-de-travail-1-300x300.png\")
\n– time-consuming pull requests in several repositories for a single feature
\n– difficulty to share best practices between teams
\n– bugs in production due to partially merged code<\/p>\n
\n– keeping the Continuous Integration flow fast
\n– adding tools to further improve developer experience and productivity
\n– and introducing zero bugs in production!<\/p>\n\n
![\"\"](\"https:\/\/i2.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Bernd-Ru\u0308cker_Plan-de-travail-1.png\")
\n
![\"\"](\"https:\/\/i3.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Robin-Moffatt_Plan-de-travail-1.png\")
\n<\/em>Not enough people use “Kafka Connect”,\u00a0 <\/em>the integration API of Apache Kafka<\/span>. <\/em>
\nThis 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. <\/em><\/p>\n\n
![\"\"](\"https:\/\/i2.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Roberto-Cortez_Plan-de-travail-1.png\")
\n<\/em>Not enough people use “Kafka Connect”,\u00a0 <\/em>the integration API of Apache Kafka<\/span>. <\/em>
\nThis 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. <\/em><\/p>\n\n
![\"\"](\"https:\/\/i0.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Hugh-McKee_Plan-de-travail-1.png\")
\n
![\"\"](\"https:\/\/i1.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/08\/Graeme-Rocher_Plan-de-travail-1.png\")
\n
![\"\"](\"https:\/\/i3.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Allard-Buijze_Plan-de-travail-1.png\")
\n
![\"\"](\"https:\/\/i0.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/08\/Capture-d\u2019e\u0301cran-2019-08-05-a\u0300-23.24.52-300x150.png\")
\n
![\"Julien](\"https:\/\/i2.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2018\/07\/J-DUBOIS-150x150.png\")
\nPlease note I intend to talk about a few top-secret offers that we are preparing on Azure, so I can’t tell you right now, but we should have some really exciting and new content for the conference.<\/em><\/p>\n\n
\nThe faster you can release new features and fix bugs, the quicker you can innovate and respond to customer needs. AWS provides developer tools that help you automate the end-to-end lifecycle of your serverless applications. In this session, we will discuss methods for automating the deployment of serverless or containerised applications, using services such as AWS CodePipeline and AWS CodeBuild, and techniques such as canary deployments and automatic rollbacks.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n
\n[\/vc_column_text][vc_column_text]\nTools-in-action (25 min)<\/h1>\n[\/vc_column_text][vc_column_text]\n
<\/h1>\n
\n
![\"Laura](\"https:\/\/i0.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/06\/Laura-Kirby_Plan-de-travail-1-300x300.png\")
\nMy 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.
\n<\/em>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.<\/li>\n<\/ul>\n[\/vc_column_text][vc_column_text]\n<\/h1>\n
\n
![\"\"](\"https:\/\/i1.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Julien-Laforge_Plan-de-travail-1.png\")
\nIt’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.<\/em><\/p>\n\n
\nKubernetes 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.<\/p>\n\n
\n– understand how to use contract testing as a tool to enable confident delivery<\/em><\/p>\n![\"\"](\"https:\/\/i1.wp.com\/voxxeddays.com\/microservices\/wp-content\/uploads\/sites\/54\/2019\/07\/Phil-Hardwick_Plan-de-travail-1.png\")
\n– key pitfalls to avoid when using it in a microservices context<\/em>
\n– how to migrate from existing delivery to independent continuous delivery<\/em><\/p>\n\n