API & Microservices
Wednesday, November 17, 2021
In April 2021 we were facing a challenge. Due to the nature of our product we had to develop in a multi-framework approach. However, reality forced us to think differently. We soon realized it was unscalable, inefficient, silly even, really! The challenge was that our application is embedded within our customers’ application, which they can build on top of any framework. Beyond that, we had to expose our components’ state and to receive state from the hosting application.
At the end of the day, we had to adopt an approach that would support both our product technical requirements, while optimizing our frontend development process.
In this session we will go deeply into real life examples of how Frontegg used micro frontend strategies (to name a few…) to overcome those challenges, and how it made a significant impact over our frontend development, architecture, CI/CD, and overall processes.
To truly scale application security testing, developers need to maintain their role in the security process beyond SCA and SAST, continuing the automation you are already achieving and rely less on manual testing.
Traditional DAST scanners are a blocker to this automation. They are hard to use, impossible to integrate, not developer friendly and produce too many false positives. This results in crippling human bottlenecks that stifle CI/CD, whether it's the need for security to constantly tweak scanners or the drain of manually validating vulnerabilities.
Either way, technical and security debt is compounded, resulting in insecure product hitting production. Change is needed, and fast.
In this session with you will discover:
1. Key features that your dev-first DAST needs to enable developers to take ownership of security
2. How you can detect, prioritise and remediate security issues early, automated in the pipeline
3. Insights into reducing the noise of false alerts to remove your manual bottlenecks to shift left
4. Steps you can take to achieve security testing automation as part of your CI/CD, to test your applications and APIs.
Cassandra is an incredibly powerful, scalable and distributed open source database system. Companies with extremely high traffic use it to provide their users with consistent uptime, blazing speed, and a solid framework. However, many developers find Cassandra to be challenging because the configuration can be complex and learning a new query language (CQL) is something they just don't have time to do.
Stargate is an Open Source project which sits on top of Cassandra and provides HTTP interfaces to your data - it provides a REST API, a GraphQL API, and a document-oriented Schemaless API.
You can install it on top of your own Cassandra instance and participate in the community. During this presentation we will demo, detail purpose, capabilities and internals of the tool. We also give a working sample as a docker-ready configuration file.
As software is becoming more pervasive, APIs are fast becoming the building blocks of business enterprises. And with that, the role of the API developer is gaining more responsibility for driving growth ranging from small to large companies. In this session, we will discuss how API developers can leverage tools to deliver quicker time to market value for both the business and the consumers.”
Over 2.5 trillion PDFs are created every year and contain a huge amount of valuable data. However, PDFs continue to be a challenge to reliably extracting data from.
In this session, we will learn:
- How you can use Adobe PDF Extract API to convert PDFs into JSON data use within your app.
- Introduce to the Adobe PDF Services SDKs (NodeJS, Python, Java)
- Extract tables easily to import into your own apps and databases
- Perform automated actions such as splitting PDFs, combining them, or flagging them based on certain criteria in the PDF.
The business demanded rapid innovation. Software development and IT figured out how to provide it. But now we have a whole host of new problems. In the resulting world of cloud-native apps, microservices, and API-driven applications, what we came to rely on for keeping it all running and secure is no longer enough.
In this new fog, we are basically “flying blind”. Modern applications are extremely hard to secure and protect as they are complex and continuously changing. Our visibility of what we have, how it is behaving, and how it is being used (and abused) has diminished tremendously. So how do we begin to see through the fog once again?
In this session you’ll learn:
Why are we flying blind
4 key areas to focus on to stop flying blind
A way to get started quickly (for free!)
For more information on Traceable AI, visit us at: www.traceable.ai
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 machine and network boundaries * Deployment – how about containerization and orchestration using Kubernetes?
You wouldn't build a house without a blueprint. Why build APIs without a plan? But you also can't build a house without the proper infrastructure. It'll take work to get your organization ready to shift left into a design-first API strategy. Learn how to prepare your organization to create a winning API program. -Why APIs? -What is holding organizations back? -What is design-first and why does it matter?
Have you ever wanted to make your apps “smarter”? This session will cover what every ML/AI developer should know about Open Neural Network Exchange (ONNX) . Why it’s important and how it can reduce friction in incorporating machine learning models to your apps. We will show how to train models using the framework of your choice, save or convert models into ONNX, and deploy to cloud and edge using a high-performance runtime.
Thursday, November 18, 2021
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.
Troubleshoot.sh is a tiny kubectl plugin that is capable of big things, including but not limited to drastically reducing the amount of time needed between problem & solution. Join our workshop to see troubleshoot.sh in action in a live demo, plus the opportunity to learn how to customize troubleshoot components to fit your needs.
Today, API software solutions are usually designed first for the cloud, and often a particular cloud services provider. This was the case for rev.ai, our speech to text API. However, many use cases still require on-premise or at least private cloud deployments - whether due to privacy, latency or cost considerations.
This session will describe how we adapted our cloud-based speech-to-text API for on-premise deployment and the challenges we faced in doing so. We will discuss maintaining consistency between cloud and on-premise APIs, maximizing code reuse, and enabling platform-agnostic scalability.
In 2019, Zhamak Dehghani published a thought-provoking article highlighting common failure modes of centralized data architectures and advocated instead for a decentralized, domain-oriented approach in which data is managed as a product. This paradigm is described as a Data Mesh and it builds upon prior architectural concepts such as microservices, domain bounded contexts and elastic platform infrastructure solutions that unlock scalability. In this talk, we will discuss how Data Mesh can be applied by organizations that are looking to expand their product offerings, perhaps even through growth strategies that include mergers and acquisitions. If you are struggling to derive value from your organization’s data due to overly complex and coupled ETL pipelines or monolithic big data stores, Data Mesh will likely be a refreshing new take that intuitively resonates with teams who need agility in managing, serving and composing novel insights from their product offerings. Additionally, if you are leading development teams, Data Mesh can provide the missing blueprint that allows you to escape an org chart in which data engineers are siloed from the subject matters experts who can best articulate how your organization’s data can be utilized to great effect.