Friday, June 25, 2021
You can think about the granularity, try to fix the consistency with sagas,
evaluate various communication protocols, think about partial failures or ...just ignore the CAP and ship a nice monolith, save time and take vacations.
In this session, I would create the smallest possible Java monolith (actually a microlith) from scratch, discuss the design choices, tradeoffs and patterns.
At the end, I will discuss the killer use cases for microservices and how to break the microlith into several nanoliths.
Questions are highly appreciated!
Microservices have become a prevalent architectural approach to developing applications. Moving from a monolithic application to multiple container-based services has many advantages. One of the largest is dynamic scalability; spinning up and shutting down instances of services to adapt to dynamic loads is very cost-effective in a public cloud environment.
For JVM-based applications, running in a managed environment using JIT compilation, this provides additional challenges. Primarily, this is around the time required for a service to warm up and reach the optimum level of performance. To address this, we have seen various approaches such as the Graal VM and Quarkus that use an AOT approach rather than JIT compilation.
In this session, we will explore the pros and cons of both approaches to help in understanding the tradeoff between initial performance and overall
performance. At the end of the session, you will have a clear idea of how to approach your Java microservice design from the AOT and JIT perspective.
Microservices are one of the big trends in software engineering of the last few years; organizing business functionality in several self-contained, loosely coupled services helps teams to work efficiently, make the most suitable technical decisions, and react quickly to new business requirements.
In this session, we'll discuss and showcase how open-source change data capture (CDC) with Debezium can help developers with typical challenges they often face when working on microservices. Come and join us to learn how to:
* Employ the outbox pattern for reliable, eventually consistent data exchange between microservices, without incurring unsafe dual writes or tight coupling
* Gradually extract microservices from existing monolithic applications, using CDC and the strangler fig pattern
* Coordinate long-running business transactions across multiple services using CDC-based saga orchestration, ensuring such activity gets consistently applied or aborted by all participating services
Dividing a huge system into modules is the only way to develop large systems. After Microservices became popular, people realized that the structure of a system is very important. Some took these ideas and applied them to monoliths. The basic concept of modularization is not new, however. These talks show the fundamental concepts and how they apply to microservices and monoliths alike. Because the architecture and the split into modules are so very important, the talk, therefore, shows basic concepts and prerequisites for successful projects.
Ever wondered what is a Cloud-Native Application? Is it a microservice or a monolith? oh, it must be made for Cloud? Ever wondered how to develop a Cloud-Native Application? Come to this session to find out about what makes an application Cloud-Native and then learn how to build a Cloud-Native Application using the latest MicroProfile technologies (MicroProfile 4.0) such as Config, Fault Tolerance, Rest Client, JWT, Metrics, etc. This session finishes with a live demo on developing Cloud-Native applications using MicroProfile 4.0 running on Open Liberty and deploying them on k8s.
Saturday, June 26, 2021
Kubernetes enables possibilities to develop cloud-native microservices or decompose traditional applications making them more technologically advanced with the help of containers. Currently, most of the Kubernetes solutions are offered on top of VMs and there is room for further improvements. Implementing nested architecture of application containers running inside system containers opens additional flexibility of resource allocation and management, accelerates provisioning of the clusters and pods, as well as cuts the overall costs. During this session, we’ll review the possibilities of running a Java-based application inside the Kubernetes cluster with nested container architecture, what configurations should be taken into account, and how to overcome the barriers on the way to more efficient Kubernetes hosting.
How does one choose to architect a system that has a Microservice / REST API endpoints? There are many solutions out there. Some are better than others. Should state be held in a server side component, or externally? Generally, we are told this is not a good practice for a Cloud-Native system, when the 12-factor guidelines seem to be all about stateless containers, but is it? It’s unclear and this confusion may lead to poor technology stack choices that are impossible or extremely hard to change later on as your system evolves in terms of demand and performance.
While stateless systems are easier to work with, the reality is that we live in a stateful world, so we have to handle the state of data accordingly to ensure data integrity beyond securing it.
We will examine and demonstrate the fundamentals of a Cloud Native system with Stateful Microservices that’s built with Open Liberty in Kubernetes:
- Microservices/REST API – Options to use when running your apps in the JVM
- Concurrency – how to take advantage of multi-core CPUs and clustered distributed systems
- Stateful vs Stateless - while stateless apps are easier to implement, the bulk of the apps in production are stateful which involve a higher level of complexity and risk, especially when data would need to travel across multiple machines and network boundaries
- Deployment – how about containerization and orchestration using Kubernetes?
The food wastage in India is 70 tonnes per year, and there is mismanagement at several layers. Approximately 20-30% of the wastage happens in the last mile, between wholesale traders, and retail mom-and-pop stores. Is there something we can do about food wastage?
This was the problem statement I attempted to solve as a first engineering hire at a startup. Our customers were 12.8 million retail owners that deal in FMCG (Fast-moving consumer goods, such as food grains, tooth paste, etc.). The goal was to develop a platform for retail traders (mom and pop shop owners / small and medium business owners) to buy FMCG products from wholesale traders using an Android app.
We were attacking a deeply entrenched business practice to help solve a societal goal. For a section of the population which is not very well versed with smartphones and technology, the user experience had to be designed from the ground up to be multilingual, fungible, unstructured, and relevant. In this talk, I cover how we went about iterating the solution from a simple SMS based system to a full fledged app backed by micro-services. Having a micro-service architecture provided us the agility to experiment and iterate quickly, and we were able to push out changes much faster, and help solve wastage problems even sooner.
I will discuss the several problems we faced in this segment with regards to unstructured data, and how our data models had to adapt. We used cloud services extensively, so I will also cover how different pieces came together in a cogent form to build a better experience for our customers.
The talk will include an explanation of asynchronous non-blocking programming with code snippets. It will demonstrate how asynchronous non-blocking code helps with resource utilization, isolation beyond just performing I/O in parallel and show how it can be measured/benchmarked. I will present a quick primer on reactive programming. Using a scenario where we need to fetch data from different microservices, we will solve it by leveraging reactive operators to combine different sources of data, perform non-blocking I/O, exception handling, retries, fallbacks and explain how work is scheduled on different threads. Finally, we will go over common mistakes and gotchas with project reactor.