API first Design und API as a Service sind die neuen Trendthemen in den IT-Abteilungen. Als primärer Kommunikationspartner für Fat-, Mobile- und Webclients sind APIs das Rückgrat moderner verteilter Anwendungen. „From zero to hero“ ist unser Motto auf der Reise in die Welt des API Designs, und nach dem Motto "API first" starten wir in dem Workshop mit dem Design einer simplen API. Kaum haben wir die erste Version geschafft, widmen wir uns gleich größeren Herausforderungen wie einer immer aktuellen Dokumentation, Abwärtskompatibilität bei der Weiterentwicklung, Einsatz von Caching-Features und dem Aufbau erster Sicherheitsmaßnahmen. Lebensnahe Beispiele, jede Menge Best Practices und viel Code, der nahtlos in eigene Projekte übernommen werden kann, bilden die Grundlage für einen erfolgreichen Tag, an dem neue API-Designer geschaffen werden.
In this hands on workshop you will learn the concepts behind Consumer-driven Contracts and dive into a showcase application to code Consumer-driven Contracts between Spring Boot services and an Angular UI. You can choose whether to use Pact or Spring Cloud Contract as an implementation framework so that we can share our respective experiences at the end of the workshop.
So, what’s the fuzz about Consumer-driven Contracts? In a distributed system, we have to deal with many interfaces between different components. No need to say that there should be automated tests in place to regularly verify that these interfaces still work from both sides. One concept for implementing those tests is Consumer-driven Contracts. The contract is created by the API consumer and both sides test against this contract.
Cloud-native Architekturen sind derzeit in aller Munde.
Wir vertreten den Standpunkt: Cloud-native ohne APIs macht keinen Sinn.
Wie passt dann noch das Thema API Management in diese neue Welt?
Welche Trends und Entwicklungen werden erkennbar?
Are you using RESTful web services to provide data for your apps? "Sure, what else?" Well, then you should take a closer look at GraphQL. GraphQL is a query language for your API and is used by Facebook, GitHub and others as an alternative to RESTful web services.
In this session you will find out what GraphQL is and how it can improve your daily work. Furthermore, you will see how GraphQL works on the client and on the server side.
You love REST? You “hate” REST? You are somewhere in-between or you think “REST, what else?”. Take a look over the rim of the tea cup and maybe fall in love with GraphQL.
Payment Service Directive 2 was inured in 2018 by the European Commission to enable a competitive, regulated environment for banking and non-banking organizations within the European Union. Competitive markets such as China's fast growing mobile payment market, Australia's New Payment Platform, and evolving FinTech Start-ups strongly impact the disintermediation of payment transactions, disrupting the banking sector globally. The need for fulfilling future customer needs by providing convenient payment solutions demand for faster adoption, agile methods and MVP (Minimal Viable Product) approaches that must lead to cultural changes in the banking sector to keep up with the market. How can one bank bear up to the competing environment by investing in digital payment solutions without losing control over regulation and cost?
When organizations exceed a certain number of people, the main problems go from being technological to sociological in nature. It is not only about scalability, resilience, or availability. Concerns such as cross-team dependencies, need for alignment, or meeting overload are all sociological stress catalysts that must be incorporated in the architecture design process.
In this talk we will explore how choosing the right architectural abstraction and an API-centric strategy can pave the way to a self-service platform in which team autonomy is reinforced, unnecessary dependencies are removed, and accountability is clearly stated.
Im Zuge der voranschreitenden Digitalisierung werden Projekte im Umfeld der API-Economy immer wichtiger. Die Umsetzung solcher Projekte hat in der Regel enorme Auswirkungen auf das gesamte Unternehmen. Vor allem vor dem Hintergrund, dass es im Grunde in jedem Unternehmen sog. Legacy-Systeme gibt, die integriert werden müssen, denn kaum ein Unternehmen im Bereich der Financial Services hat den Vorteil, auf der grünen Wiese starten zu können.
Durch den Schwenk von Legacy-Systemen, die eher monolithisch aufgebaut sind, hin zu Microservices kommen weitere Herausforderungen auf die Projekte zu. Die weitreichenden Auswirkungen erstrecken sich von technischen Herausforderungen verbunden mit der Neuausrichtungen der Softwarearchitektur bis hin zu Konsequenzen bzgl. Betriebsführung und organisatorischen Veränderungen. Im Grunde bleibt hier im Unternehmen kein Stein auf dem anderen.
Wir wollen in dieser Session zeigen, welche Fragestellungen exemplarisch auftreten können und welche Lösungsalternativen diskutiert werden müssen. Dabei werden wir auf die organisatorischen und die technischen Problemfelder in Verbindung mit der veränderten Softwarearchitektur genauer eingehen. Am Ende der Session sollten die Teilnehmer ein Gespür dafür bekommen, wo die Herausforderungen bei solchen Projekten liegen.
Der Erfolg eines API steht und fällt mit einer guten Dokumentation. Doch API-Betreiber haben die Qual der Wahl: Zahlreiche Werkzeuge konkurrieren um ihre Gunst. Im Bereich der Schnittstellenbeschreibungssprachen ist nun eine gewisse Konsolidierung im Gange: Das aus Swagger hervorgegangene OpenAPI soll zum Standard entwickelt werden. Doch während Swagger/OpenAPI weit verbreitet ist und viele Anhänger hat, sind neben den vielen positiven Eigenschaften und Vorteilen auch einige Nachteile und Schwächen festzustellen. In diesem Vortrag werden zunächst OpenAPI und eine Auswahl der zahlreich erhältlichen Tools vorgestellt. Im Anschluss werden die guten und weniger guten Seiten der Beschreibungssprache gegenübergestellt, Fallen aufgezeigt und dargestellt, auf welchen Teil der Toolunterstützung man vielleicht besser verzichten sollte.
Nicht immer genügt ein synchrones REST API den funktionalen Anforderungen an die Performance.
In diesem Talk wird eine Umsetzung eines High Performance Messaging API mit Apache Kafka an konkreten Use Cases gezeigt. Es werden die Konzepte der Datenpartitionierung zur Skalierung der Lösung mit den Daten vorgestellt.
Praktisch werden ein JEE-basierter Producer, die Aggregation mit Kafka-Streaming und Consumer auf Basis von sowohl Kafka Connect als auch JEE vorgestellt.
Hier wird insbesondere auf die nötigen Schritte zur Erzielung einer hohen Performance und Skalierbarkeit eingegangen. Des Weiteren werden auch Themen wie das Deployment der Lösung in der Cloud und die Umsetzung von Transaktionsgarantien und Hochverfügbarkeit betrachtet.
This keynote will explore the 3 waves: SOA, API Management, and Microservice Management (based on Istio), explain lessons learnt and give advice on how to succeed.
SOA had great design principles such as service contracts, loose coupling, etc. But SOA came with its own challenges and is not always perceived as a great success. Also, ESB is often used for SOA and represents huge investments that you cannot rip and replace overnight.
API Management opened the door for easy internal and external (mobile/partner/IoT) consumption with self-service. API Management is clearly evolving in large organizations towards self-service, DevOps and multi-cloud.
Microservices management is the new trend. With microservices being distributed in nature, there’s a need to easily establish reliable and secured communications, often through APIs. Both East/West communication (service to service) as well as North/South (Edge) need to be addressed. Istio brings a great foundation layer on top of which you need a management layer and easy integration with API lifecycle management capabilities.
Testing microservices is challenging. This is because, despite their independence, they are often still coupled via API calls. It's this coupling that can lead to issues such as:
This talk will introduce the consumer-driven contract testing technique, a TDD at the API level approach for Microservices. It aims to resolve all of these issues and more, leading to truly independently testable and releasable services.
Galten “Nanoservices” im Kontext von Microservices noch als Anti-Pattern, kann dieses Muster seine Vorteile im Rahmen von “Serverless”-Backends voll ausspielen. Die Session soll zeigen, welche Vorteile Nanoservices bieten und mit welchen Lösungen sie umgesetzt werden können. Auch wird auf die besondere Rolle von Querschnittsfunktionen wie Authentifizierung und Persisten, sowie Themen des Entwicklungsprozesses wie Deployment- und Testautomatisierung eingegangen. Exemplarisch soll die Umsetzung auf der AWS-Plattform gezeigt werden.
OAuth and OpenID Connect are the two most important security specs that API providers need to be aware of. In this session, Travis Spencer, CEO of Curity, will cram in as much about these two protocols as will fit into 60 minutes.
Nicht erst seit dem Hype um Microservices ist Schnittstellendesign ein essenzieller Bestandteil von Softwareentwicklung. Doch jede noch so gut definierte Schnittstelle kann an einen Punkt geraten, an dem sie weiterentwickelt werden muss. Sei es nur, weil sich die Anforderungen geändert haben.
Kommt man an diesen Punkt, stellt sich die Frage: Muss ich meine Schnittstelle versionieren? Wenn ja, wie gehe ich vor? Wie müssen sich die Clients der Schnittstelle verhalten, um nicht plötzlich (nach einem neuen Release des Servers) eine böse Überraschung zu erleben?
Die Weiterentwicklung einer Schnittstelle wird initial leider häufig nicht mit bedacht. Hoher Wartungsaufwand für die Bedienung alter und neuer Schnittstellen sind die Folge. Wie kann ich das verhindern? Wie muss ich bei der Weiterentwicklung vorgehen, um alte Clients nicht inkompatibel werden zu lassen und dennoch nicht in der Versionierungshölle zu landen? Diese und weitere Fragen werden in dieser Session behandelt.
The exponential growth of APIs, further accelerated by IoT, micro-services, and FaaS, brought many challenges both technical and economical. On the one hand, businesses are struggling with establishing successful API programs to connect with their customers. On the other side, engineering teams are facing out-of-the-scale complexity.
In this talk, we will explore the problems and shortcomings of current APIs, both with regards to the technical aspects and the API economy. We will discuss the possible solutions to these problems, and introduce Autonomous APIs.
In the second part, we will take a look at what Autonomous APIs are and how they can solve the problems for both businesses and engineering. We will introduce the classification of autonomous systems and take a peek at the building blocks of autonomous systems.
Remember the times when setting up a login page was easy? It seems like nowadays, it takes many weeks to start a project just to create a sign-up form, a login form and a forgot password screen. And that is if you don’t need two-factor or passwordless authentication. During this presentation, you will be introduced to OpenID and OAuth. You will also learn how to leverage this to create secure application or, most importantly, how to delegate to a third party so you can focus on their real work.
In unseren Assignments rund um Digitalisierung werden wir immer häufiger gefragt, was ein erfolgreiches API Management ausmacht. Ersetzt es meinen verhassten ESB, oder ist es mehr? Ist es ein reines IT-Thema oder etwa doch nicht? Was brauche ich, um erfolgreich zu sein? In dieser Session stellen wir die Zutaten eines erfolgreichen API-Managements dar. Wir werden in ein paar Grundlagen einführen und anschließend die notwendigen Enterprise Capabilities darstellen, bevor wir die IT Capabilities im Kontext API-Management genauer diskutieren werden. Abgerundet wird diese Session durch eine Aufbereitung von Best Practices, die wir in unseren verschiedenen Assignments in unterschiedlichen Industrien und Kontexten sammeln konnten, die sich unabhängig der jeweiligen Unternehmen als erfolgskritisch bewiesen haben.
Informationsflüsse zu beherrschen ist eine komplexe Aufgabe für mittelständische Unternehmen. API-led Connectivity ist eine moderne Alternative zu den bereits bekannten Architekturpattern (ESB, MoM) und bietet viele Vorteile. API-Landschaften sind dokumentationsgetrieben, fully-managed (Monitoring, Security, SLA) und können in überschaubarer Zeit zur Reduktion der Komplexität und zur Generierung eines Mehrwerts aus den bestehenden IT-Systemen verwendet werden. Anhand eines praktischen Beispiels bei einer Bank wird in diesem Vortrag gezeigt, welche Vorteile der Einsatz von MuleSoft-ESB-Produkten und API-led Connectivity im Vergleich zu alternativen Architekturen bietet.
Many API initiatives start as integration projects. Despite noble aspirations around simplicity and cost control, the impact to the business is incremental, and many projects fall into common traps.
APIs are critical to a modern digital business and are a primary channel for any of the platform businesses. We have worked with some of the world’s largest companies. Whatever your organisation’s size or complexity, achieving 10 times as much is possible. Executing ambitious digital initiatives are hard rather than complex.
Learn how to excite and significantly shift your organisation, and take away key principles of success so that you can execute on your journey with confidence.
As we try to build APIs that are valuable, usable, and feasible, are there lessons we can learn from Product Management and how we approach this? This session will be a fun look at some anecdotes and cautionary tales shared by Product Managers, and reflect how they can help our thinking when designing and building APIs.
The concept of "APIs as a Product" and the need for a Product Manager for APIs is a growing trend (in 2017 Thoughtworks added an entry tracking the idea to their Tech Radar) - so what exactly does this mean? And what can we learn from Product Management? From dog psychology experiments to lessons from Netflix, we will take a whistle-stop tour through the discipline to look at what we can learn that might help us build great APIs.
Durch den Trend zu Microservices-Architekturen und die Bereitstellung von Public APIs ist die Verbreitung HTTP-basierter APIs noch weiter angestiegen. In der Praxis ist jedoch zu beobachten, dass bei der Umsetzung von APIs und ihren Clients wohlbekannte Fehler und Anti-Patterns wiederholt zum Einsatz kommen. Erneut entstehen Integrationslösungen mit sehr enger Kopplung, bei denen selbst kleinste Änderungen des API eine Änderung der Clients notwendig macht - und das selbst bei Änderungen, die eigentlich rückwärtskompatibel sein müssten. Zudem weist die Architektur der Kommunikationspartner oftmals keine ausreichende Widerstandsfähigkeit auf. Auch die Weiterentwicklung eines produktiven API erweist sich nicht selten als deutlich aufwendiger als erhofft. Dieser Vortrag beleuchtet typische Fallen und zeigt alternative Lösungswege auf.
Providing an API as an enterprise is not only spinning up a server or container deploying the backend – it’s a process that can and should be streamlined.
But it does not stop there - functional and load testing, creating test data pools, publishing it to the developers and last but not least getting an in-depth monitoring from end to end are also topics that need to be taken care of.
Chances are your shiny new single API will need authentication. And probably some security and resource access control. But how to integrate all of that in your new React application? How can you ensure that your users only have access to the resources they are authorized to visualize and that they can’t view secure sections by hacking their way in through the console? In this talk, you will learn about the powerful JSON Web Tokens (JWT) and see how they can be used to secure their APIs and front ends.
Immer mehr Unternehmen wandeln ihr Business von einer SOA- hin zu einer API-basierten Architektur. Ein wesentlicher Aspekt dabei ist die Integration der APIs mit einer dedizierten Identity-Management-Lösung, die externe und interne Identitäten validiert und Zugriffstokens ausgibt. Diese IDPs wie Ping, Okta und Keycloak bieten spezielle Sicherheitsfunktionen wie eine Multi-Factor-AuthN, die Verbindung zu verschiedenen Identity-Stores und die Unterstützung der gängigsten Sicherheitsstandards wie JWT-Tokens. Darüber hinaus ermöglicht Federated Login die Integration von Social-Media-Identitätsanbietern wie Google und Facebook, sodass die Nutzer ihren bevorzugten Identitätsanbieter verwenden können.
In diesem Vortrag erfahren und sehen Sie anhand von Demos, wie Sie Ihre API-Management-Lösung mit verschiedenen Identity-Providern zusammenspielen lassen können und was es dabei zu beachten gibt.
In dieser Session werden keine technischen Details oder Technologien dargestellt, sondern gezeigt, wie die sogenannte APIfication eine der Grundvoraussetzungen plattformbasierter Geschäftsmodelle ist. Im klassischen Geschäft redet man üblicherweise von Pipe-basierten Geschäftsmodellen. Im Zuge der digitalen Transformation kann man beobachten, dass der Weg Richtung Plattformen und entsprechenden Geschäftsmodellen geht - und das mit Lichtgeschwindigkeit. Ohne APIs bzw. ein API-Management sind Plattformen nur schwer und langsam umzusetzen. In dieser Session gebe ich einen Überblick über plattformbasierte Geschäftsmodelle und stelle den Zusammenhang zur notwendigen APIfication (API-Management und deren APIs) dar. Ich berichte aus einer aktuellen Studien zu diesem Thema wie auch aus meinem Projektalltag bei großen Kunden, die ihre ersten Gehversuche Richtung Plattformen (als Provider und auch Consumer) unternehmen.
As an industry, we've been building API based software for years, but the work of managing those APIs is still a big challenge. Whether you are supporting a single API for thousands of third party developers or a tiny microservice for your own developers, you'll need to solve the problems of managing API work, API products and the system they live in. How should an API be designed, built and implemented? How much effort is good enough to get a return on investment? What needs to change when the number of APIs grows? In this talk, you'll learn about three important lifecycle concepts: API maturity, API landscapes and organizational design. We'll explore how understanding the interplay of these forces will allow you to define an API strategy that works for you.
To stay ahead of competition, an enterprise must deliver its services or products in a very short time to the market at the lowest possible costs and lowest entry-level for its partner or customers. So, you have to know your partner or customer, and understand his or her need at any specific point in time. That can be done by finding the correct way to identify your partner or customer, and integrate the information you have of that specific person to deliver a personal engagement experience.
In this talk, Ruben will explain and illustrate with customer cases, the logic behind the Digital Transformation revolution and why you cannot avoid it any longer. Key take-aways are the choices companies have to make and the position you want to take. Inspiring, humorous, real life cases of the Digital Transformation revolution. Are you a Believer?
In dieser Session erfahren Sie, wie sich unter Nutzung von COAP Restful Services aufbauen lassen, um Daten von Narrow-Band IoT-Devices in möglichst kleinen Paketen zur Weiterverarbeitung senden zu können. Dabei zeige ich zum einen, wie COAP intern funktioniert, und zum anderen, wie wir sehr einfach neue Use Cases mithilfe unseres Backend auf Basis der Daten umsetzen können.
Welche technischen Treiber sehen wir allgemein im Markt und wie entstehen API Initiativen?
Welche Treiber gab es bei der NÜRNBERGER Versicherung bzgl. APIs?
Wie ging man vor und was sind die Lessons Learned und verbliebenen Herausforderungen?
Hier erfahren Sie von einem konkreten Projekt aus der Praxis.