The emergence of serverless computing was initiated by functions-as-a-service (FaaS) offerings, which allow code execution in response to specific events such as an API request or uploading a file to a storage service. By utilizing FaaS offerings, developers can easily build and deploy code without worrying about the underlying infrastructure.

Serverless computing has blended with container-based technologies like Kubernetes, which enables containerized applications' deployment and management in the cloud. Consequently, hybrid serverless architectures emerged, combining the advantages of both serverless and container-based technologies. I'll also dive into how serverless computing has expanded beyond FaaS to include database-as-a-service (DBaaS).

Although the excitement about serverless computing may have dwindled in recent years, the use of serverless technologies is still on the rise, with over 50% of cloud customers leveraging serverless technologies. As the technology develops further, it is likely that serverless computing will continue to be a crucial aspect of cloud computing.

The world is not ideal - any large system consists of many separate subsystems.
We cannot control all of them during development and expluatation at once.
And according to Murphy's law, if anything can go wrong, it WILL go wrong.
When applied to the creation of distributed systems, this means that absolutely everything may and will break someday.

And in such conditions, we need to develop software that does not require constant attention from its creator.

We'll speak about the practices and our experience of creating software with self-healing based on the principles of closed loop automation
(at last, let's talk about the reasons for the stability of kubernetes),
compare it with the event-based approach that is common in the industry,
and honestly admit that the employer will have increased resources overhead and spent money at the expense of our good night’s sleep.

Enhancing server performance typically entails achieving one or more of the following objectives: reduce latency, increase number of requests per second (RPS), and minimize CPU and memory usage. These goals can be pursued through architectural modifications, such as eliminating some network hops, distributing data across multiple servers, upgrading to more powerful hardware, and so forth. This talk is not about that.

I categorize the primary sources of code performance degradation into three groups:

[*] Thread contention. For instance, too hot mutexes, overly strict order in lock-free operations, and false sharing.
[*] Heap utilization. Loss is often caused by frequent allocation and deallocation of large objects, and by the absence of intrusive containers at hand.
[*] Network IO. Socket reads and writes are expensive due to being system calls. Also they can block the thread for a long time, resulting in hacks like adding tens or hundreds more threads. Such measures intensify contention, as well as CPU and memory usage, while neglecting the underlying issue.

I present a series of concise and straightforward low-level recipes on how to gain performance via code optimizations. While often requiring just a handful of changes, the proposals might amplify the performance N-fold.

The suggestions target the mentioned bottlenecks caused by certain typical mistakes. Proposed optimizations might render architectural changes not necessary, or even allow to simplify the setup if existing servers start coping with the load effortlessly. As a side effect, the changes can make the code cleaner and reveal more bottlenecks to investigate.

The transition from custom authentication to a ready-made solution has significantly improved the security and simplified the management of authentication in our service. In this presentation, we will discuss the reasons why we decided to switch to Keycloak and share our experience and the results of this transition.

Our previous authentication methods, developed in-house, faced several challenges such as security vulnerabilities, scalability complexity, and user management difficulties. After exploring various solutions on the market, we chose Keycloak, an open and flexible solution for identity and access management. Throughout the transition, we encountered technical and organizational challenges that we successfully overcame, and now we can share our best practices and recommendations for a successful integration of Keycloak into existing infrastructure.

Our presentation will be beneficial for developers and architects considering the implementation of ready-made authentication and authorization solutions in their projects. We hope that our experience and results will enable other companies to reduce the costs of developing custom solutions and make the authentication process more secure, efficient, and user-friendly.

Practical software architecture: what do we all know about it but are too laisy to use
Software architecture is a tough subject: we all know we need it, we all put so much energy to get it right and we all are mostly unsatisfied with the result.

All our efforts on the architectural direction are based - ок at least expected to be based - on the two fundamental studies programmers universe provided us: “Clean Architecture” by Robert Martin and "Domain-Driven Design: Tackling Complexity in the Heart of Software" from Eric Evans.

But - no, it is very rare in our society to use the ideas from any of these books in the day-to-day job. Looks like these books are too good for us!

Seriously, they are just like the design for а shining castle on a high hill. And we need something much much simpler like a barnyard to grow and feed our projects. This is what I heard from my dear colleagues so many times!

And finally, I’ve decided to create a speech about practical architecture:
1. Yes, we need a barnyard and yes even a barnyard needs good architecture.
2. Good architecture is not about beauty but about very practical things: testability,
extendability and debugability.
3. Good architecture is easy, because
3.1. All our projects are almost the same
3.2. Singe slightly variated pattern will lead us to the good architecture for any of
the projects we are growing in our barnyard
3.3. Practical architectural requirements are really easy to follow. Actually, it is
much harder to not follow them as soon as you finally look at them from this
perspective.
3.4. Practical architecture is a self-supporting thing: as soon as you start it right in
one part of the project it will magically organize the environment in the proper
way.
4. The books mentioned above are not about shiny castles but - shocking - about
barnyards!

In general, CDN is very simple thing. You just need a bunch of servers, several fat links to the best ISP and the nginx. Is it enough?

And how to choose the best option for your project from several candidates?

Abstract
* what issues you can fix with CDN;
* questions you have to ask before onboarding;
* black magic of routing: what is the real nearest node;
* how to rule the world with BGP and DNS.

Netflix is a media streaming company and a movie studio with data at exabyte scale. Most of the data generated, transferred and stored at Netflix is very media specific, for example, raw camera footage, or data generated as a result of encoding and rendering for different screen types.

In this session, I will throw light on how we design a media aware and optimized transfer, storage and presentation layer for data.

By leveraging this architecture at Netflix scale, we provide a scalable, reliable, and optimized backend layer for media data.

Major takeaways from this session
- Learn about the challenges of designing a scalable object storage layer for data while adhering to the file system POSIX semantics of media applications
- Learn about the optimizations applied to reduce cloud storage footprint, such as chunking, deduplication
- Learn about how different applications expect data to be presented at different locations and in different formats.

Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs. Non-functional requirements are just as critical as functional Epics, Capabilities, Features, and Stories. They ensure the usability and effectiveness of the entire system. Failing to meet any one of them can result in systems that fail to satisfy internal business, user, or market needs, or that do not fulfill mandatory requirements imposed by regulatory or standards agencies. This session is about modelling and sizing critical NFRs for large distributed systems on cloud.

Foldable phones have created a new revolution in the smartphone industry with their unique form factors, bringing a new set of challenges and opportunities for developers. The challenge for developers is to make their applications adapt to different screen sizes and aspect ratios, while also taking advantage of the foldable form factor. This talk will explore the possibilities and challenges of developing for foldable phones, with a focus on building user-friendly and engaging applications that make the most of the new form factor.

Topic Disclosure:

1. **What risks do we get when choosing opensource solution? Top rules to consider when deciding to use opensource:**

1. Few words first about pros of OS (free, community etc.)

2. Risks: Bugs can take a long time to resolve (may not be fixed at all) + examples. You might need to write Workaround’s or solve it yourself. Software can become depricated and lose any support (examples of response from support for such cases)

3. Top Rules:

1. Be careful which OS you choose. Keep in mind that if you make a fork of the repository (a certain tag or version), support comes to you. You can get away with it, but no one is save here

2. If the solution you choose has many dependencies, each of which evolves independently, do not be lazy to study the history of versioning and compatibility. It is quite possible that one of the elements of the system may dramatically change the way it works and bring you a lot of pain (As an example at some point one of your opensource dependencies can suddenly go from binary-extension to database extension, consisting lots of migrations. And so, rollback for such a case might become tricky). Besides, solutions are often offered for single-node clusters and multi-node (high-available) clusters (different configurations). In such cases the support and development are often not parallel either

3. Study experience of other companies. It is quite possible that the chosen solution may not be able to handle your needs.

4. Try the solution on sandboxes/playgrounds, often provided by the vendors themselves

2. **How and what we might encounter when using opensource when it has become depricated?**

1. Consider challenges and problems we can fase using opensource (ex. - Solution for your architecture & tech stack does not work correctly)

3. **Saving the drowning. How to survive? Our story**

1. In common, the right solution is to switch to another software that has support. Or apply the vendor's recommendations. However, the customer may not be ready to spend time and money on the migration and want everything to work here and now (at least for some time). In this case we need to fix what we have.

2. On our example I will tell what we faced, where we had problems, how we fixed it during migration from deprecated soft to non-deprecated

In brief: Opensource solution, that we were using became deprecated. From that time support of the system fell on our shoulders. While migrating to another solutions, we still needed to fix bugs and issues ourselves and keep system running. Main thesises:

1. Do not draw conclusions about the correct work of the system at once and not chase deadlines. It is better to observe time and load, than to shoot from your hip and fix the consequences.

2. Do not be afraid to dive into the source code and even rebuild your custom images (show our example)

3. Be sure to monitor the key critical metrics. Define them for yourself (also tell on our example)

3. Our story about moving from deprecated solution to supported one (TimescaleDB → Victoria Metrics). Main problems and thesises:

1. There is usually no ready-made solution (data-migrator), or it may not work well. You will probably have to write it yourself. What do you need to consider first for such a migration:

1. Define how your data is stored (which tables, whether key-value only, perhaps there are series and labels lists). How can you retrieve and migrate them as quickly as possible? Show it on our case

2. Understand how to bring data to the new system. How to parallelize and fasten the process (example: upload/download to each datanode (shard) separately)

2. As a conclusion tell how total time was spent on the migration process and how much control was needed.

4. **Costs and expenses. Price for moving from depricated opensource to a supported solution**

1. How much time does it take to implement whole migration process? From analysis to process start

2. What competencies are needed, specialists of which roles might be necessary to add to the whole process?

The talk will cover following topics:

Memory architecture - CPU/Memory gap, memory hierarchy, multiprocessor cache, cache line contentions and its effects on scaling

Multiprocessor RW Lock - Fast reader/writer lock that scales linearly for read

0-bit spin lock - Lock that effectively uses no memory, allowing for cheap fine grained locking.

I will show how to use 12 factor app methodology in prantice.

Factor 1: share libs but not code. How to share own code between services? Local package server like nuget
Factor 2. Self-contain build for .NET on Java allows to avoid additional dependences
Factor 6 about stateless services. Is is posible to use in-memory cache when we need single instance of some service. But in-memory cache should be hidden using some generic interface. When we need to scale the service then we replace in-memory cache by Redis cache using configuration without changes in application code.
Factor 6: it is also possible to use file system for example for CSV export. But file should be removed when it closed. And requests should not search for files created by other requests.
Factor 9: graceful shutdown. IHostApplicationLifetime interface allows to react on application shutdown. Also I will show how to configure Quartz to finish background tasks such way that the can be resumed or restarted bu other instanses of the same service.
Factor 11: logging to stdout. If service writes logs to some service like Elsatic or Datadog then it is possible to lose some log records on service crash. So it is needed to use sidecar pattern, addtional service to read logs from console and upload to logs storage.
Factor 12: admin tasks as a process. I will talk about SQL migration tools like EF Core bundle and EF Core extension which allows to add any SQL script to the migration (https://github.com/CUSTIS-public/CUSTIS.NetCore.EF.MigrationGenerationExtensions). And I will show how to implement a tool to fix schema of NoSql data storages.

We will discuss concrete examples from Yandex 360

* In Yandex Telemost, when we do broadcasts, or manage incoming calls from meeting rooms, we need to allocate heavy VMs as resources. They require warmup, authorization and healthchecks, because at scale any one of these VMs can break or go rogue at any time. And only one of these instances can serve a stream at any given moment.

We need to maintain up to 99.99% availability of these services. We have specific rules how it is calculated, and we can formally minimize downtime from planned updates with the help of a wisely chosen strategy. We have historical data at our disposal to test theories. And we have been using it.

* Sometimes these services are so imbalanced in CPU/RAM ratio, that we need to host multiple user sessions within one container. Otherwise RAM consumption and overhead on PaaS would be enormous. In this case we need to orchestrate a 2-layered service with all of the requirements from above.

* Yandex Telemost is based on Jitsi. It holds multi-user sessions across several distinct components in memory. And registers in several discovery systems to organize the calls. Special care should be taken to prevent unintentional random split of conferences into several independent rooms. Or to prevent a rogue POD from intercepting one of the traffic channels thus making it impossible for users to join a particular conference at all

based on these examples, we are going to discuss
* problem of stateless single-pod services. And our approach to their managent and maintenance
* how we can calculate and minimize donwtime of these stateful in-memory components and enable more frequent releases
* why there should be only one service discovery
* how split brain-like situations emerge from scaling a component that provides multi-user sessions. When the component is not built for scaling world-wide. And we did to address the issue.

This provides guide-rails for modernizing legacy applications & systems with modern technologies like Open Source and Java EE on cloud. The talk serves as reference for the technology options and decision considerations when you’re weighing these choices for architecting application and systems.

In this talk, we will cover two different approaches to orchestrating Kubernetes clusters: OpenStack Magnum and Cluster API.

The story will start with: You and your team are now responsible for the Managed Kubernetes as a Service based on the OpenStack Magnum. Great news! And what is OpenStack Magnum?
We will talk a little about how Magnum works, what are its pros and cons, what’s wrong with Heat, and what is Heat.

It will continue to the: Houston we have a problem; I’m pretty sure we have to rewrite the whole service from scratch.
We will talk about how to find the right words for your Product Manager to make him agree that sometimes revolution is much better than evolution, and why you should get rid of legacy ASAP.

And in the end, you will know how easy it is to swap service core technology on the go.
We will talk about pets vs. cattle, about immutable vs. mutable, and how you can do big things with a small team if you automate everything. In other words, in this part, we will learn what perfection is.

Need to continuously ingest data from numerous disparate and non-overlapping data sources and then merge them together into one huge knowledge graph to deliver insights to your end users?

Pretty cool, huh? And what about multi-tenancy, mirroring access policies and data provenance? Perhaps, incremental loading of data? Or monitoring the current state of ingestion in a highly-decoupled distributed microservices-based environment?

In my talk I will tell you our story: all started with a simple idea of building connectors, we ended up building fully configurable and massively scalable data ingestion pipelines which deliver disparate data pieces to a single data lake for their later decomposition and digestion in a multi-tenant environment. All while allowing customers and business analysts to create and configure their own ingestion pipelines in a friendly way with a bespoke pipeline designer with each pipeline building block being a separate decoupled microservice (think Airflow, AWS Step Functions, Azure Data Factory and Azure Logic Apps). Furthermore, we'll touch such aspects as choreography vs orchestration, incremental loading strategies, ingestion of access control policies (ABAC, RBAC, ACLs), parallel data processing, how frameworks can help in the implementation of cross-cutting concerns, and even briefly talk about the benefits of knowledge graphs.

During the session, I will:

- Describe the benefits of using OpenTelemetry to collect logs, metrics, and traces on decoupled projects with a separate frontend, backend, and several microservices, to have them available in a single combined interface.

- Compare OpenTelemetry combined collector, based on opensource Grafana Stack, with separate solutions like Jaeger, Zipkin, Promtail Prometheus.

- Show a demo of a simple decoupled app on React at the frontend (JS), Drupal Framework (PHP) at the backend, microservices on Python, and a third-party API, and the Grafana UI interface with collected logs, metrics and traces.

1. Few words about ClickHouse and Prometheus
2. LTS problems in Prometheus
3. Clickhouse as a backend
4. Integration/Configuration:
5. **Why Not?** (VM/Thanos/Mimir)**…**
6. **Why Not ClickHouse?**
7. **Сonclusions**

A WebAssembly runtime is an embeddable virtual machine. This allows platforms to dynamically load and execute third-party bytecode without rebuilding their OS and Arch-specific binary. While WebAssembly is a W3C standard, there are a lot of mechanics required to do this, and many critical aspects are out-of-scope, so left to the implementation.

Most presentations discuss WebAssembly at a high level, focusing on how end users write a program that compiles to Wasm, with a high-level discussion of how a virtual machine enables this technology. This presentation goes the other way around. This talk overviews a function call beginning with bytecode, its translation to machine code, and finally how it is invoked from host code.

The implementation used for discussion is the wazero runtime, so this will include some anecdotes that affect these stages, as well as some design aspects for user functions that allow them to behave more efficiently. However, we will also indulge in a high-level comparison with other runtimes and similar technologies that in the past tried to solve the same problem.

When you leave, you'll know how one WebAssembly runtime implements function calls from a technical point of view.

How can one create a Market Risk System capable of providing real-time calculations for an entire portfolio, conducting strategy backtesting, performing hypothetical scenario analyses, and effectively analyzing and manipulating data.

Whether it's for an investment bank, a hedge fund, or any other business, the necessity for such a solution becomes apparent at a certain stage.

Drawing upon my experience in developing such systems from the ground up at several prominent investment banks, I'll endeavor to present common ideas on an architecture.

this presentation will be about good patterns of terraform code and pitfalls of bad IaaC architecture - especially in Agile environment.
I will focus on guiderails for platform teams, usage patterns from development teams, easy auditability of TF Code and deployment patterns

In this session we will review what a Digital Twin is, how they work, what it takes to create one and how to Architect a solution that scales to meet your needs. These virtual models can be used for a wide range of applications, including predictive maintenance, optimization, and simulation. Key to that is using the right Architecture and cloud platform for providing a comprehensive set of tools and services for creating, deploying, and managing digital twin solutions.

Attendees will also learn how to create a digital twin solution on cloud platforms(AWS, Azure, etc), including data ingestion, processing, and visualization. We will also get into the practical needs for specifying a Digital Twin deliverable and what kind of platforms can support their operation. So don’t get left out on the evolution of Digital Twins Design, check out this talk!

Learning objectives:

Learn what a Digital Twin is and how they correspond to the built environment

Understand what kind of tools are available for creating a Digital Twin platform

Learn how to Architect data from IoT devices into a data stream for a visualization platform for large scale operations

Become able to develop a Digital Twin design in your next project with sample guidelines

Monitoring is the key to the successful operation of any software service, but commercial solutions are complex, expensive, and slow. Why not do it yourself with open source? We’ll show you how to build simple, cost-effective, fast monitoring for practically any system using ClickHouse and Grafana. First, we introduce key elements of your monitoring solution: ingest, query, and visualization. We then dig into an example system showing how to store data efficiently, build queries, and create operational dashboards. Any developer can do it–join us to find out how!

This talk explores the current state and future developments of AI in SQL and data analytics. It highlights how AI techniques enhance SQL-based data analytics, enabling faster and more accurate insights. Challenges of data quality, interpretability, and privacy are discussed along with ongoing research efforts in explainable AI and privacy-preserving techniques. Future developments include automated query optimization, intelligent data visualization, and integration with emerging database architectures. Attendees gain insights to leverage AI for enhanced data analysis and decision-making.

Sick of sluggish databases? VeloxDB is a fast, open-source, in-memory database that merges traditional database and ORM. Achieving 2.5 million ACID transactions per second, it’s perfect for high-performance apps. Learn how we did it in our talk - applicable to high-performance devs in any domain.

Developers often encounter significant challenges when working with traditional databases, especially when they’re dealing with high load. NoSQL databases can offer faster performance, but often at the expense of consistency and correctness.

Meanwhile, Object-Relational Mapping (ORM) solutions are a popular choice for simple database access, but current implementations suffer from considerable overhead. However, what if we could eliminate the relational layer between the application and the database? By doing so, we could exploit the ORM interface to its fullest potential and eliminate the N+1 problem that plagues all ORM systems.

We developed VeloxDB, an open-source, ACID-compliant, in-memory database that merges the best features of traditional databases and ORM into a single, optimized solution. With VeloxDB, we achieved 2.5 million ACID transactions per second, a significant improvement over PostgreSQL’s 50k TPS in the same benchmark.

In this talk I will go into secrets and techniques we used to achieve this performance. This knowledge can be applied not only to databases and C#, but can be very useful when building high performance or data intensive applications across many domains and languages.

The following topics are on the agenda:

Custom Locks - VeloxDB utilizes custom locks, as .NET locks simply don’t suffice. Our locks are optimized for excellent multi-core performance and minimal garbage collector stress.

Lightweight Object Orientation - Our streamlined ORM layer significantly reduces the overhead typically associated with traditional ORMs.

Ultra-Fast Conflict Detection - We employ a highly efficient method for detecting conflicts between transactions.

Custom Memory Manager - The data managed by the database is handled by a custom memory manager specifically designed for database use cases. This manager is faster and more lightweight than .NET’s garbage collector.

Modern distributed databases scale horizontally with great efficiency, making them almost limitless in capacity. This implies that benchmarks should be able to run on multiple machines and be very efficient to minimize the number of machines required. This talk will focus on benchmarking high-performance databases, with a particular emphasis on YDB and our implementation of the TPC-C benchmark—the de-facto gold standard in the database field.

Firstly, we will speak about benchmarking strategies from a user's perspective. We will dive into key details related to benchmark implementations, which could be useful, when you create a custom benchmark to mirror your production scenarios.

Secondly, we’ll briefly discuss the popular key-value benchmark YCSB, which we believe is a prerequisite for robust performance in distributed transactions. Following this, we'll explore the TPC-C benchmark in greater detail, sharing valuable insights derived from our own implementation.

We'll conclude our talk by presenting performance results from YCSB and TPC-C benchmarks, comparing YDB's performance with that of CockroachDB and YugabyteDB — other trusted and well-known distributed SQL databases.

Topic Disclosure:

1. **What is TimescaleDB, and how to cook it? What kind of tasks would it be good for?**
1. TimescaleDB core concepts. How does it work as an postgresql - extension, which benefits does it give (ex. makes it possible to manage data/metrics with the usual SQL-queries). Which mechanisms does it have (space/time partitioning, chunks, hypertables data compression and retention, etc.). Configuration differences (singlenode/multinode setup)
2. More specific about singlenode/multinode setups. What is promscale and how does it work in pair with TimescaleDB?
3. What cases are most suitable for specific TimescaleDB setup?
2. **Choosing configuration and infrastructure for TimescaleDB**
1. Best Practices for System Deployment
2. High - available setup: Patroni + AccessNode + Datanodes + Kubernetes
3. Recommended parameters for VM’s and Databases. Postgres/patroni configuration (shared memory/wal params etc.). CPU/RAM/Disks etc.
3. **What to monitor?**
1. Key metrics to pay attention to (basics and specific for tsdb)
2. Which exporters and dashboards do we need?
4. **What to monitor?**
1. Key metrics to pay attention to (basics and specific for tsdb)
2. Which exporters and dashboards do we need?
5. **Troubleshooting from console**
1. Useful sql - queries and utilities, that may help you
2. Applying it in action. Production cases
6. **Advices and our own experience with mistakes**
1. When to add resources and when to tune the software itself?
2. TSDB/Patroni/Promscale wins & failures

This talk takes you on a journey through the history of SQL as an Open Standard, emphasizing its pivotal role in shaping the database industry. It also highlights the pressing need for a similar standard in MongoDB-compatible open databases. The presentation introduces FerretDB as a groundbreaking solution bridging MongoDB and open databases, ensuring seamless transitions without extensive application-level changes. This talk illuminates the importance of open standards and presents a path forward for enhanced compatibility and collaboration within the open-source database community.

This year was exciting for open-source. We saw more choices and a bigger focus on the cloud. We're going to talk about the big things from 2023, covering the most notable open-source software releases, the importance of cloud-native solutions in a multi-vendor, multi-cloud environment, the heightened focus on security challenges, and the evolution of the open-source software industry.

Cartridge is a tool for managing distributed applications based on Tarantool NoSQL Database. One of the main requirements for our applications is fault tolerance. The load from fallen nodes in the cluster should be switched to live ones. This does not seem like a difficult task, but there are many pitfalls in practice.

In Cartridge, this problem is solved by an automatic failover. I will talk about the history of its development and implementation features, describe the problems we encountered during its maintenance, and share valuable ideas on the development of similar systems.

As Data Engineer Database Performance, Efficiency should be among your priorities, and to optimize those you need to understand what influences query Performance and what you can do about it. In this presentation we will look into all the factors which influence query performance - the database engine, data structures and algorithms it uses, query optimizer, various types of indexes and other data access optimization methods as well as hardware innovations which allow us to reach modern performance. After attending this talk you will be better empowered to take the optimal choices to help your team to get the best performance while minimizing your costs.

While the kubernetes could run databases for a quite long time, production databases taking more attention to important details:
* crash recovery
* disaster recovery
* backups
* access control
* user management and security benchmarks
* Performance at scale (100GB+ databases)

Using PostgreSQL for all backend technologies can make your stack simpler, reduce the number of moving parts, speed up development, lower your risk, and deliver more features to your users. PostgreSQL can replace many other backend technologies, such as Kafka, RabbitMQ, Mongo, and Redis, and can handle millions of users.

In modern world you have many options for tooling.
You can use different SQL databases/NoSQL databases/full text search engines/queues/messaging systems/etc.

But what if you could simplify your tech stack (in accordance with expected tradeoffs) and focus on one technology instead of many tools?

And it's name is PostgresSQL! :)

You can use it as:
1. Message queue
2. NoSQL database
3. GEOspatial search engine
4. Full text search engine
5. And more coming in this talk

Storage is the heart of every database. But which storage is fastest? And which is best for your analytic application? This talk explores the trade-offs between the main storage types available in all major public clouds. We’ll start with basic performance metrics. Using ClickHouse as an example, we’ll show how databases access different storage types and how it translates to query speeds visible to your users. Spoiler: the fastest storage does not always give the best query performance. We’ll reveal standard tricks like caching, volume stacking, sorting, and compression that help you build fast analytic applications even on so-called “slow” storage.

ClickHouse is an ultra-fast analytic database. Object Storage is cheap. Can they work together? Let's learn!

ClickHouse is an ultra-fast database originally designed for local storage. Since 2020 a lot of effort has been made in order to make it efficient with object storage, like S3, that is essential for big clusters operated in clouds. In this talk I will explain ClickHouse storage model, and how Object Storage support is implemented. Finally, we will see performance results and discuss further improvements.

In this session I want to present AutoGluon - open source library created by Amazon to train custom ML model close to SOTA models with just a few lines of code. This library could be used for tabular, image, textual and multi modal datasets to solve different problems like classification, regression, forecasting, Gen AI.

Looking to transform your apps with real-time analytics? Kubernetes is an outstanding platform operating high performance databases and ClickHouse runs well on it. This talk starts from the basics of Kubernetes and introduces an operator we implemented that enables you to stand up ClickHouse clusters. We'll walk through the installation process and bring up a ClickHouse cluster in real-time during the talk. We'll then show how running on Kubernetes enables emergent behavior like independent scaling of compute and storage, server fault tolerance, cross-AZ high availability, and rolling upgrades. You'll have enough guidance from this talk to start your journey to real-time data on a robust, cloud native architecture.

The task of content moderation requires a lot of resources and time using a manual approach. That is why we are implementing ML models to solve this problem.

However, under conditions of high loads and the need for maximum fault tolerance, it's needed to choose the right solution for integrating ML models. NVIDIA's Triton Inference Server turned out to be such a tool for us.

Triton Inference Server is a powerful software that supports inferencing of several models at once and can allocate and use computing resources efficiently. However, in situations where high fault tolerance and maximum automation are required, features of pure Triton are not enough.

To meet the requirements that arise when working with a ML models in production, a number of solutions have been developed to improve stability and fault tolerance.
Main topics to be covered:
* Ensuring scalability
* Additional condition monitoring tools
* Full control and automation of model updates
* Ability to create individual instances for different models for efficient resource utilizing and fault tolerance

Thus, an attempt was made to create a Triton as a Service to make the models integration be easy and improve the stability of the system as a whole.

SoCalGas, The USA's largest natural gas utility, collects hourly gas usage data for over 6 million residential customers through advanced meters. With that information, we are able to chart usage patterns and assess various profiles that correspond to different real world scenarios. Some of them are faulty appliances, like leaking water heaters. With this information we are able to proactively reach out to customers and connect them with our field team for no cost repairs and information about other energy efficiency programs.

This talk is about bringing large scale data from large scale IoT implementation into a real-world use case benefits many people. The content will provide a brief overview of the device and tech stack the company uses, how the information is profiled, some examples of usage profiles, and then how that information is leveraged through many departments to benefit the customer. The beneficiaries of this talk will be senior management who could be inspired by how everything connects from IT, to data science, to call centers, to field techs, into a single package.

Kubernetes has blossomed into a popular vessel for running databases. But is your data really safe from pirates? This talk introduces security for data on Kubernetes, focusing on basic techniques that any developer can apply using open source tools. The talk starts with basic ways to harden the environment like container scanning, the use of secrets, and encryption. Next, we will show how to lean on operators to protect databases running on Kubernetes. Finally, we’ll consider ways to protect Kubernetes itself. Attend the talk to find out how!

Context: setting the task - a feed of personal recommendations on the main page. How to launch recommendations in production when you have 150 million items and 100 million users? I will share my experience, tell you about the pitfalls
A quick overview of the arsenal of models: classic ML approach
A quick overview of metrics starts with product metrics.
The basis of everything: fast experiments and analytics on actual data
Where to start? Classical matrix factorization and its launch pattern.
What problems did you encounter at this stage
Little more advanced: switching real-time user features and history. An alternative approach with simpler models.
Advanced models: Let's add neural networks, the strength is in diversity.
Mixing models - great blender
How does it work in production? Replaced Go with Python, what happened to time to market?
And again, about the experiment cycle, I'll tell you about product metrics.

I will share my experience in event sourcing and show some pitfalls of this approach:
- EventSourcing terminology (event, stream, snapshot, projection)
- Technical advantages of events storing in comparison of storing states
- Is it possible to implement EventSourcing without CQRS?
- Is it possible to use transactional consistency instead of eventual consistency with Event Sourcing?
- Which business tasks can be more effective solved using EventSourcing
- How to avoid snapshot expiration
- The fastest way to build SQL projections
- Myths about Event Sourcing (it allows to avoid soft delete, events allows to do any analysis)
- Typical problems which has another solution with EventSoucing
* unable to remove user's events with sensitive data so events are encrypted and removed encryption key
* it is difficult to implement unique constraints
* unable to load aggregate with any relations, only data from stream
* HTTP Patch doesn't work
* projections shouldn't have unique indexes and foreign keys
* production data anonymizer should fill new event store with anonymized events

Also I will show Event Sourcing frameworks like Marten, describe its pros and cons, and does it make sense to use it in production.

There are many overviews about the WebAssembly technology or its internals. In this presentation, Andrey will focus on the practical side. He will share his experience of porting the real-world C++ networking application to the browser with WebAssembly and Embind.

There were many obstacles hiding in this way. Andrey will explain how to deal with some of them. We will see how to start porting, how tooling works, how to debug WebAssembly in the browser, and more.

Andrey will show some examples of WebAssembly applications and demos. We will see the pros and cons of using this technology and learn when it is applicable.

Almost everyone has monitoring. In the ideal world it becomes a reliable tool for detecting issues and preventing them at an early stage. No less often, APM on a free plan with out-of-the-box reports acts as monitoring. As a result, something is measured, some alerts are sent into the chat, no one responds to them, and one day the major incident happens.

In the talk we will:

- discuss monitoring antipatterns;

- learn to represent the system in the terminology of queuing theory;

- select the most critical metrics and configure them;

- figure out what are the less critical metrics and learn to see the meaning in their graphs;

- discuss why alerts are helpful, and when they are not needed.

Strong SLA tends to be a requirement in the modern digital world, and it's actually required in fintech like companies. But some things are not important at the first look could dramatically breach SLA, especially when we deal with highly loaded services.
Our team works on an observability platform we created at Tinkoff and named "Sage". Sage is an internal product and covers the whole ecosystem of the company. Sage is a pretty loaded system and gets 4 Gigabytes/s of incoming traffic and holds 7.5 Petabytes of user's data.
In my talk, I'm going to share with you experience of overcoming several failures (hardware and software) we got operating that system due to small things we didn't pay enough attention.

I will be delivering a presentation on how to improve the developer experience by using the Backstage Developer's Portal. Backstage is an open-source platform that allows you to create your own developer portal. Many well-known companies, including Unity, Netflix, and Spotify, have already implemented this highly adaptable platform.

My discussion will center around the key features of Backstage, such as software templating, cataloging, searching, and a straightforward portal for all documentation. By utilizing Backstage, you can overcome various developer challenges, such as managing documentation, clarifying relationships between different parts of your software, identifying the responsible person for a particular module or source code piece, or launching a new project with best practices.

Furthermore, I will demonstrate how you can manage multiple applications from a single portal by creating plugins in the backend, and how you can enhance the user experience by offering.

The purpose of this talk is to help DevOps engineers to understand GitOps pattern and take decisions about using GitOps or not. Also, I will discuss the most frequent problems and ways to solve them.

Self-driving vehicles, as any mobile robots, are complex systems of hardware and software components, each with potentially unique failure scenarios. Ability to quickly respond to suboptimal performance and component failure is key to getting from a prototype to production and then scaling the business.

One of the most popular frameworks for building high-level robotic software, the Robot Operating System (ROS), allows convenient hands-on debugging, but requires additional integrations for remote monitoring.

I’ll give an overview of ROS and the unique challenges of robotic systems, talk about the standard diagnostics capabilities in ROS, and then show how we use VictoriaMetrics and Grafana to greatly enhance observability of our fleet of autonomous trucks.

Over 6 years of writing Dockerfiles for living and helping other teams/companies to understand and use containers better gives a full picture about our modern devops fundamentals

ClickHouse is not an out-of-the box solution for logs (like ELK & Grafana Loki) and requires some additional work to make it suitable for storing & querying logs. But, due to it's powerful SQL capabilities, fast data ingestion and good data compression it allows to use it even for logs. In this talk I will describe
* Why did we choose ClickHouse instead of other solutions
* How logs are propagated from apps to ClickHouse
* Logs structure: we use structured-based logging, so what exactly we collect
* How we designed ClickHouse tables for storing logs: column based storage, data retention, storage tiers, etc
* How ClickHouse storage works in context of logs structure
* How we implemented full-text search on a top of ClickHouse, which does not contain it out-of-the box
* How ClickHouse performs against Loki & Elastic in terms of storage size

During this session, I will first discuss the capabilities and practical applications of Ansible. Later on, I will demonstrate how we can use Ansible for automation, write Ansible playbooks, and utilize them for scaling instances and deployment. Furthermore, I will explain how developers can take advantage of Ansible by utilizing various plugins.


During my discussion, I will delve into the principal workings of Ansible and provide guidance on how to get started configuring your cloud infrastructure. This will include the configuration of the Manager, Application Deployment, Orchestration, and Cloud Provisioning using Ansible.

With Ansible, you can deploy multitier applications quickly and easily, without the need to write custom code for system automation. Instead, you can compile a list of tasks in a playbook, and Ansible will determine how to configure your systems to the desired state. Ansible has been designed to ensure that configuration management is simple, reliable, and consistent, making it an ideal choice for IT professionals. Additionally, Ansible offers various APIs that can be utilized to expand connection types, callbacks, and other functions.

Furthermore, I will explore Ansible's provability and audibility while reproducing applications in Docker on the Cloud, as well as provide guidance on how to create your own plugins that can be used with any cloud service provider.

Join Dhrumil Dhanesha in an immersive session that uncovers the transformative power of passion, perseverance, and audacious goals. Starting from the humble beginnings of a 6-year-old boy who spent countless hours exploring the wonders of gaming, Dhrumil's story transcends boundaries and exemplifies the boundless potential within us all.

Discover how Dhrumil's insatiable curiosity propelled him on a self-taught journey of discovery, diving headfirst into the world of programming and coding. Fueling his passion, he diligently honed his skills, spending countless nights researching and experimenting, determined to unravel the secrets of app development.

At the tender age of 12, Dhrumil achieved a remarkable milestone by publishing his first app on the Google Play Store. The thrill of success ignited a flame within him, and he yearned for more. With unwavering determination, he took the leap into entrepreneurship, establishing his own company, and offering web and app development services to startups and businesses. What started as a bold step evolved into a flourishing business, with clients flocking to Dhrumil's doorstep, drawn by his professionalism, expertise, and unwavering commitment.

Great presentations are a powerful tool for conveying ideas, sharing knowledge, and engaging audiences. This talk will delve into the fusion of MARP, a simple yet powerful presentation framework, and Markdown, a lightweight markup language, to create captivating presentations from Readme files.

Key Takeaways

Understand the fundamentals of using MARP and Markdown for creating engaging presentations from Readme files.
Discover the features and customization options offered by MARP, such as themes, layouts, slide transitions, and interactive elements.
Learn how to effectively communicate your ideas, projects, and expertise in a visually compelling and engaging manner using tools like VS code, Github actions and other common editors.
Learn best practices for structuring content, incorporating visuals, and utilizing storytelling techniques to deliver compelling presentations from Readme files.

Describe what DEvSecOps processes we have and why
Our DevSecOps tools and know hows.
How to use DevSecOps for complex hardware and software and hardware products
On-premise vs Cloud CI/CD and DEvSecOps tools
How to prevent zero day vulnerabilitues in open source components

How do AWS security services work together and how do you deploy them? The AWS Security Reference Architecture (AWS SRA) provides prescriptive guidance for deploying the full complement of AWS security services in a multi-account environment. AWS SRA describes and demonstrates how security services should be deployed and managed, the security objectives they serve, and how they interact with one another. In this session, learn about these assets, the AWS SRA team’s design decisions, and guidelines for how to use AWS SRA for your security designs. Discover an authoritative reference to help you design and implement your own security architecture on AWS.

Each new technology brings us not only speed and convenience, but also dozen attack vectors, which, in turn, give new defense tools.

And, solving the problem of protecting your container infrastructure, it would be nice to understand the tactics and techniques of attacks on it, as well as to understand the completeness and accuracy of the tools that promise you security.

Container Attack Simulation Framework is an attempt to create a framework for simulating attacks with an architecture that allows you to cover all tactics and techniques by popular classifications of attacks on containers.

Each new technology brings us not only speed and convenience, but also dozen attack vectors, which, in turn, give new defense tools.

And solving the problem of protecting your container infrastructure, it would be nice to understand the tactics and techniques of attacks on it, as well to understand how to prevent and detect them.

In the talk we will try to understand top of the threats of containers on each stage of attack and operation mapped on popular framework matrices. And what to check after you will return to office!

Artists, copywriters, and journalists are already at the factory. Is it time for security officers to go to the store for jumpsuit?
In this talk, we will explore how GPT3+ models are already being used by security specialists, developers, and administrators.

Who is ChatGPT? Friend or enemy?

Demo-based session.

Since the cloud is growing in popularity, more companies are moving to the cloud. Low initial investments make the entry much easier, but there is a chance to misconfigure security settings.
Session demonstrates typical anti-patterns used by many companies.

LLM has long been on the slope of enlightenment in its small own hypecycle, which means that it’s time to dive into all aspects of the security of models and applications that use them.

As part of the talk, we will consider the top 10 threats to LLMA, real attack cases and best ways to prevent threats. We will carry out prioritization of risks, compare it with familiar examples, and on the sidelines we will share our findings and “cases in wildlife”.

Whether you’re migrating an existing Microsoft Active Directory (AD) or starting from scratch on AWS, this chalk talk will help you choose the right Microsoft directory service for your needs. Learn about AWS Managed Microsoft AD, AD Connector, Simple AD, and AD Domain Services on Amazon EC2. Learn about the features, scalability, security, and cost implications of these services to help you make informed decisions about how to seamlessly integrate and manage your directory services on AWS.

Let's get acquainted with the modern Yandex Data Center. And also let's talk about the hardware in Data centers and the people who work there.

It's time to find out how Yandex approaches the process of designing, building and operating its data centers.
How Yandex's own developments affect the application and widespread introduction of new technologies in its data centers, and what role servers of its own design and production play in this.

Let's talk about how to cool servers with air from the street and not spend extra money at the same time. And we will also find out how many people are needed to service a data center with a capacity equal to a small city.

Million RPS on Demand. Highload By Schedule. How works Ozon Performance Testing platform.

About topic:
Ozon is growing up twice every year since 2019. Main technologies are: Go/ C#, gRPC, Kafka, A lot of code Generation, S2S Routing and security etc.
Performance testing platform was started as service, that helps regular Ozon engineers starts Performance Tests by one cli-util command or one click on UI.

Also, there are 3 main paradigms in Ozon Performance testing:
1) Confidence from Performance tests, can be achieved only on Production.
2) Bandwidth target for next season for concrete service, calculates by analytics, and uploads to Performance Testing platform.
3) Once a week, IT management, looks at consolidated performance reports, provided by our performance testing platform and collect confidence of Readiness Ozon for upcoming Season.
The platform grew with Ozon. It contains several microservices, that helps us and our users to start performance tests easier.
We standardize and simplified most performance Testing activities and provides a lot of integrations with Ozon Infrastructure.
Also we created CPU-effective load generators for http, gRpc and scenario traffic.

All activities, described below accompany by problems, caused by HighLoad nature of our environment.
Such as:
- Problems with payload collection system and Kafka.
- Load Generators, that generate too much load for our Performance testing system.
- Statistics, that overload our statistics Storage.
- Bandwidth limits in our k8s cluster, that was reached one day.
- CPU limit, also was reached one day.
How we solved all these problems, we run 27 thousand tests a month, as well as how we generate more than a Million RPS on production every night, you will learn at my speech.

Learn techniques from an experience Dungeon Master that work both at the gaming and business table to keep people from becoming murder hobos ;)

My talk is going to be about discovering what's really going on in a company and noticing how changes in platform affect organisational structure of product teams. We will start discussion with minimal basics of Team Topologies. It's approach I used to visualise teams interactions and understand how company truly works. We will see how different teams block each other in real life and a way platform can solve this kind of problems.