Choreography vs Orchestration in Serverless Microservices
We went from a single monolith to a set of microservices that are small, lightweight, and easy to implement. Microservices enable reusability, make it easier to change and scale apps on demand but they also introduce new problems. How do microservices interact with each other toward a common goal? How do you figure out what went wrong when a business process composed of several microservices fails? Should there be a central orchestrator controlling all interactions between services or should each service work independently, in a loosely coupled way, and only interact through shared events? In this talk, we’ll explore the Choreography vs Orchestration question and see demos of some of the tools that can help.
Chopping the Monolith
There are reasons for microservices: independent deployment of business capabilities. However, the unspoken assumption is that you need to deploy all capabilities all the time. My experience has shown me that it’s plain wrong. Some capabilities need frequent deployment, while some are much more stable. In “the past”, we used Rule Engines to allow updating business rules without deployment. While it solved the problem, this approach had issues. Between introducing a Rule Engine and migrating your complete system to microservices, Nicolas believes that there’s a middle path, and that this path is Function-as-a-Service.
In this talk, Nicolas will detail every point he has made above, and show how one can use Serverless to pragmatically design a system that allows deploying as often as you need.
Network Service Mesh
A Runtime Domain, fundamentally a compute domain, is the environment where your workloads run. Normally, each Runtime Domain has only one Connectivity Domain. In practice, this means workload shave only one connectivity option and only workloads in that Runtime Domain can be part of that Connectivity Domain. There’s a strong coupling between Runtime Domains and Connectivity Domains.
DevOps and Microservices Better Together
You want to do DevOps and move fast using continuous delivery but your architecture is holding you back. In this talk, we will look at how a microservices architecture is essential to make DevOps and CI/CD successful.
AI-Enabled Log Analytics for Proactive Troubleshooting
In this talk, we will focus on AI-empowered analytics of log lines to detect suitable starting points for debugging and troubleshooting, as these methods are highly relevant in practical applications and help to bridge the gap between devs and ops. Also, this talk will present the basic idea, business reasoning, and potential behind AI-empowered log analytics and introduce a typical structure of the corresponding platforms.
Ways to Deploy Azure Resources in an Automated Manner: Arm vs Terraform vs Bicep
When it comes to infrastructure-as-code in Azure, there are now multiple ways and languages that you can choose from – the most used being ARM, Terraform and bicep.
But how to decide when to choose which? Join this session in which we will discuss the pros and cons of each, while we demonstrate them via DevOps by realizing automated deployment of an infrastructure environment.
This talk will examine a traditional application with its dependencies between methods, classes, packages, and modules. We’ll talk about how those impact applications’ ability to grow and be decomposed into independently deployable units. Then we’ll see how and where to apply location transparency. Finally, we’ll rise above the code to explore how Domain-Driven Design, CQRS, and Event Sourcing architectural concepts tackle complexity and why location transparency is key while doing so.
Beyond the Black Box
In this talk, Oren Eini, founder of RavenDB, will discuss how you can take a non-trivial distributed system and ensure that you have visibility into what is going on there.
No one reads the log, and by the time you get to it, this is too late. We’ll look into metrics and telemetry, self-reflection, and ongoing self-check / anti-entropy processes.
The Future Is Above Clouds
Now that most of us moved at least part of the workload to the cloud, the logical question is, “what’s next?” We are almost certainly adopting the multi-cloud strategy to leverage innovation from multiple sources, reduce the dependency on a single provider, and, overall, pick the right service for the job. However, that opens a whole new set of issues. How do we manage infrastructure, services, and applications in such a heterogeneous setup? How do we make it easy and transparent at the same time? How do we deal with many different APIs and control planes enforced by all the cloud vendors we use? How do we rise above the clouds?