Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortrag greift den Aspekt der Softwarearchitektur auf - insbesondere dem Thema "Microservice-Architektur".
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortrag greift den Aspekt der Softwarearchitektur auf - insbesondere dem Thema "Microservice-Architektur".
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortrag zeigt Ihnen, ob Ihr Unternehmen reif für Microservices ist und wie Ihr Unternehmen starten sollte, wenn Sie sich für Microservices entschieden haben.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortag beleuchtet aktuelle Trends aus der agilen Welt und räumt mir Mythen rund um Agilität auf.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortag beleuchtet aktuelle Trends aus der agilen Welt und räumt mir Mythen rund um Agilität auf.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Microservice Builder: A Microservice DevOps Pipeline for Rapid Delivery and P...David Currie
Presentation from IBM InterConnect 2017.
Abstract: Acceleratate your microservice delivery and promotion with an out-of-box DevOps pipeline! In this session, you'll learn how to use the Project Liber8 DevOps pipeline. We will explore its anatomy, operation, visualization, customization and ecosystem integration. We will further examine its use in deploying to IBM Cloud and on-premise deployments. A live demo will be used to reinforce concepts.
Metrics-Driven DevOps discusses how Dynatrace has shifted to continuous delivery of software using a DevOps approach. Some key points:
- Dynatrace has moved to releasing major updates 26 times per year with 170 production deployments daily, up from a previous model of major releases every 6 months.
- They implemented practices like continuous integration/delivery, performance testing pipelines, and monitoring of production metrics to optimize lead time and catch issues earlier.
- Dynatrace uses its own products to monitor pipelines and applications, enabling teams to get feedback and fail builds quickly when issues arise.
- Culture change and collaboration across teams was important to align engineers as the company transformed practices to support continuous delivery at
Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.
Join me in this talk to hear about first hand experience from building Microservices with Protocol Buffers. You will find out about good and bad. After this talk you should know, if you should use Protocol buffers in your project or not.
A presentation about deploy, scaling and the coordination problem. We will focus on redis as a coordination system in order to simplify the migration to ETCd as coordination system
Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortrag greift den Aspekt der Softwarearchitektur auf - insbesondere dem Thema "Microservice-Architektur".
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortrag zeigt Ihnen, ob Ihr Unternehmen reif für Microservices ist und wie Ihr Unternehmen starten sollte, wenn Sie sich für Microservices entschieden haben.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortag beleuchtet aktuelle Trends aus der agilen Welt und räumt mir Mythen rund um Agilität auf.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Zwei Aspekte der Softwareentwicklung nehmen auf die Komplexität und Flexibilität Einfluss: Die Vorgehensweise und die Softwarearchitektur. Dieser Vortag beleuchtet aktuelle Trends aus der agilen Welt und räumt mir Mythen rund um Agilität auf.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Microservice Builder: A Microservice DevOps Pipeline for Rapid Delivery and P...David Currie
Presentation from IBM InterConnect 2017.
Abstract: Acceleratate your microservice delivery and promotion with an out-of-box DevOps pipeline! In this session, you'll learn how to use the Project Liber8 DevOps pipeline. We will explore its anatomy, operation, visualization, customization and ecosystem integration. We will further examine its use in deploying to IBM Cloud and on-premise deployments. A live demo will be used to reinforce concepts.
Metrics-Driven DevOps discusses how Dynatrace has shifted to continuous delivery of software using a DevOps approach. Some key points:
- Dynatrace has moved to releasing major updates 26 times per year with 170 production deployments daily, up from a previous model of major releases every 6 months.
- They implemented practices like continuous integration/delivery, performance testing pipelines, and monitoring of production metrics to optimize lead time and catch issues earlier.
- Dynatrace uses its own products to monitor pipelines and applications, enabling teams to get feedback and fail builds quickly when issues arise.
- Culture change and collaboration across teams was important to align engineers as the company transformed practices to support continuous delivery at
Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.
Join me in this talk to hear about first hand experience from building Microservices with Protocol Buffers. You will find out about good and bad. After this talk you should know, if you should use Protocol buffers in your project or not.
A presentation about deploy, scaling and the coordination problem. We will focus on redis as a coordination system in order to simplify the migration to ETCd as coordination system
JUG - Soup to Nuts with Self Contained SystemsDonovan Muller
A "soup to nuts" look at implementing Self Contained Systems. From selecting a microservice architecture, implementation and onto deploying to an OpenShift container platform using a CI/CD pipeline.
Authentication as a microservice talk given by Brian Pontarelli at the Denver Microservices meetup. Want to learn how to implement authentication in your microservices architecture, this presentation covers the basic concepts.
MuCon 2015 - Microservices in Integration ArchitectureKim Clark
The document discusses integration architecture in a microservices world. It begins by defining integration architecture as how data and functions are shared between applications. It then discusses challenges with large enterprise landscapes that have undergone mergers and acquisitions. The document outlines different types of integration architectures like external, enterprise, batch-based, and event-based integration. It also discusses common misconceptions around microservices, such as thinking microservices refer to exposed APIs rather than application components. The summary concludes by noting debates around the differences between microservices and service-oriented architecture (SOA).
Presentation from a talk given by Diogo Monteiro (@diogogmt) at a recent NATS Meetup in Toronto. The talk covered why NATS is a simple, fast method for microservices communication, and provides some latency benchmarks from Diogo's design of a solution using NATS.
You can learn more about NATS at http://www.nats.io
Building microservices with azure functionsJustin Maurer
Getting started in Microservice can be a steep hill to climb, but with Azure Functions we can begin building them within minutes. Azure Functions is a "serverless" computing offering, that allows you to run small bits of JavaScript, C#, Python, PHP, Bash, Batch, and PowerShell that is managed by Azure to scale as needed. In this talk we will cover what are the best applications for Azure Functions, where they fit amongst the many options in cloud computing and go over specific use cases, including building a completely serverless backend for a web application and how it can be used for home automation.
The document discusses microservice architecture, including concepts, benefits, principles, and challenges. Microservices are an architectural style that structures an application as a collection of small, independent services that communicate with each other, often using RESTful API's. The approach aims to overcome limitations of monolithic architectures like scalability and allow for independent deployments. The key principles include organizing services around business domains, automating processes, and designing services to be independently deployable.
Google has been using containers for over 12 years to manage applications. Kubernetes was created by Google to manage container clusters and provide basic building blocks for microservices. Kubernetes allows containers to be scheduled across a cluster, provides health checking and rolling upgrades, and handles naming, discovery, load balancing and other functions. Apigee extended Kubernetes to enable multi-tenancy and container-native API management.
This document provides an overview of architecting microservices using .NET. It discusses why microservices are used, common architecture patterns, and implementation considerations. Key points include:
- Independent, loosely coupled services that are fault tolerant and easy to scale are goals of a microservices architecture.
- Communication between services should be kept simple, using either synchronous HTTP or asynchronous messaging. Synchronous calls can lead to temporal coupling so circuit breakers and failure handling are important.
- Domain-driven design principles like bounded contexts and separating queries from commands (CQRS) can help define appropriate service boundaries and responsibilities.
- Event sourcing avoids shared state and two-phase commits by persisting a sequence of events rather than
Microservice With Spring Boot and Spring CloudEberhard Wolff
Spring Boot and Spring Cloud are an ideal foundation for creating Microservices based on Java. This presentation explains basic concepts of these libraries.
Microservices: Where do they fit within a rapidly evolving integration archit...Kim Clark
Do microservices force us to look differently at the way we lay down and evolve our integration architecture, or are they purely about how we build applications? Are microservices a new concept, or an evolution of the many ideas that came before them? What is the relationship between microservices and other key initiatives such as APIs, SOA, and Agile. In this session, we will unpick what microservices really are, and indeed what they are not. We will consider whether there is something unique about this particular point time in technology that has enables microservice concepts to take hold. Finally, we will look at if, when, where and how an enterprise can take on the benefits of microservices, and what products and technologies are applicable for that journey.
Microservices + Oracle: A Bright FutureKelly Goetsch
The document provides an overview of a presentation on microservices and Oracle products. It begins with copyright information and a safe harbor statement. It then outlines the agenda, which includes an introduction to microservices, their history, prerequisites for adopting them, how to implement them, and how Oracle products support them. The document discusses how microservices decompose monolithic applications into independent, self-contained services.
Microservices Done Right: Key Ingredients for Microservices SuccessApigee | Google Cloud
This document discusses microservices and keys to microservices success. It defines microservices as independently deployable services that work together. Microservices allow for agility, reuse, and productivity. The document outlines how enterprises are adopting microservices with containers, registries, auto-scaling and blue/green deployments. It emphasizes that REST APIs are a key ingredient for microservices success by enabling consumption and shielding consumers from complexity. The document also notes that microservices will fail without API management for issues like API sprawl, security threats and lack of visibility. It positions Apigee as providing the API layer and management capabilities needed for successful microservices.
This document discusses serverless computing on AWS. It states that serverless computing allows you to build highly available and cost-effective applications that scale automatically without having to manage servers. It then provides an overview of various AWS services that can be used to build serverless applications, including AWS Lambda for event-driven compute, Amazon S3 for static hosting, Amazon DynamoDB for data storage, AWS Step Functions for microservice coordination, and others.
This document discusses Haufe-Lexware's API strategy. It advocates adopting a microservices architecture with independently working teams that follow an API style guide. APIs are organized by domain and sit at the domain boundary rather than for internal communication. API management follows a DevOps approach with immutable infrastructure, containerization, and green-blue deployments. The role of APIs is to act as a shock absorber by decoupling domains, systems, teams, and development speeds through outside-in design and self-service.
Simulating APIs for Effective Testing: (Micro)Service Virtualisation for the ...Andrew Morgan
This document discusses service virtualization and API simulation for testing distributed systems and microservices. It outlines some of the challenges in testing these systems, such as flaky dependencies, non-deterministic responses, and difficulty triggering faults. It then provides an overview of service virtualization as an approach to emulate services in a non-intrusive way. Key benefits include isolation, handling flaky dependencies, and enabling deterministic and configurable testing. Specific tools and techniques are presented for recording service interactions, replaying them in tests, and injecting faults.
The document provides "10 Tips for failing badly at Microservices". It is a presentation given by David Schmitz with tips on how to sabotage a microservices project if your boss wants you to modernize your systems. Some of the tips include going full polyglot with many technologies, having all microservices share the same database or event store, building your own frameworks and tools instead of using existing ones, treating infrastructure as an afterthought, and prioritizing hiring for buzzword technologies over architectural quality. The overall tone is humorous, presenting anti-patterns and bad practices to intentionally undermine a microservices project.
Master the flow of microservices - because your business is more complex than...Bernd Ruecker
- The document discusses using microservices and event-driven architecture together with orchestration. It notes that while events allow for loose coupling, tracking logical flows across services can become difficult.
- An order handling example is presented to illustrate challenges like a payment service needing to know all possible events that could trigger a payment. This calls for introducing an order service to handle event-command transformation and orchestration across services.
- The document argues that modern lightweight workflow engines can be embedded within microservices to enable orchestration without introducing a centralized point of control. This allows logical flows to be modeled and changes to be made without affecting individual services.
Die Mobiliar setzt seit 2014 Microservices ein. Schrittweise wurden bis heute 450 Microservices in die Produktion gebracht.
Dabei haben wir viel über die Schnittstellen, Granularität, Plattformarchitektur aber auch viel über Continous Delivery von
Microservices gelernt.
Wir implementierten einen Approach wie man eine lose Architektur für die Teams und die IT Architektur messen und verwalteten kann (Architecture as Code). Die Veränderung der Entwicklungskultur (DevOps, Leadership) konnte ebenfalls beobachtet werden. Einige Aspekte dieser Erfahrungen werden vorgestellt und geteilt.
Um agile Entwicklung sinnvoll in einem Projekt zu ermöglichen, spielt die Architektur des Systems eine entscheidende Rolle. In einem agilen Projekt sind Architektureigenschaften wie Installierbarkeit und Prüfbarkeit entscheidend, da die Software in kurzen Abständen regelmäßig geliefert und im besten Fall dem Endnutzer zur Verfügung gestellt wird. Diese kurzen Releasezyklen gelingen nur durch ein hohes Maß an Automatisierung. Agile Projekte benötigen bereits passende Lösungsansätze in der Architektur, die es erlauben eine Continous Delivery Pipeline möglichst einfach zu realisieren; das Architekturmuster „Microservices“ versucht u.A. diesen Anforderungen gerecht zu werden.
Weitere Vorteile des Architekturmusters ergeben sich bei der Skalierung von Projekten. Durch den Einsatz von „Microservices“ können Projekte einfach aufgeteilt und parallel von mehreren Cross-Functional Teams mit agilen Methoden umgesetzt werden.
Die Idee eines Microservice ist nicht neu: das System wird in kleine, losgelöste Anwendungen (sog. Microservices) aufgeteilt. Diese Bausteine stellen Ihre Funktionalität als Service zur Verfügung. Der Vortrag gibt einen Praxiseinblick, auf welche Weise man vom Einsatz des Architekturmusters „Microservice“ in einem agilen Projektumfeld profitieren kann. Es wird aufgezeigt, wo sich in der Praxis Schwierigkeiten ergeben und wie man diesen vorbeugen kann. Der gesamte Vortrag gibt einen grundlegenden Einblick in die agile Entwicklung auf Basis einer Microservice-Architektur.
JUG - Soup to Nuts with Self Contained SystemsDonovan Muller
A "soup to nuts" look at implementing Self Contained Systems. From selecting a microservice architecture, implementation and onto deploying to an OpenShift container platform using a CI/CD pipeline.
Authentication as a microservice talk given by Brian Pontarelli at the Denver Microservices meetup. Want to learn how to implement authentication in your microservices architecture, this presentation covers the basic concepts.
MuCon 2015 - Microservices in Integration ArchitectureKim Clark
The document discusses integration architecture in a microservices world. It begins by defining integration architecture as how data and functions are shared between applications. It then discusses challenges with large enterprise landscapes that have undergone mergers and acquisitions. The document outlines different types of integration architectures like external, enterprise, batch-based, and event-based integration. It also discusses common misconceptions around microservices, such as thinking microservices refer to exposed APIs rather than application components. The summary concludes by noting debates around the differences between microservices and service-oriented architecture (SOA).
Presentation from a talk given by Diogo Monteiro (@diogogmt) at a recent NATS Meetup in Toronto. The talk covered why NATS is a simple, fast method for microservices communication, and provides some latency benchmarks from Diogo's design of a solution using NATS.
You can learn more about NATS at http://www.nats.io
Building microservices with azure functionsJustin Maurer
Getting started in Microservice can be a steep hill to climb, but with Azure Functions we can begin building them within minutes. Azure Functions is a "serverless" computing offering, that allows you to run small bits of JavaScript, C#, Python, PHP, Bash, Batch, and PowerShell that is managed by Azure to scale as needed. In this talk we will cover what are the best applications for Azure Functions, where they fit amongst the many options in cloud computing and go over specific use cases, including building a completely serverless backend for a web application and how it can be used for home automation.
The document discusses microservice architecture, including concepts, benefits, principles, and challenges. Microservices are an architectural style that structures an application as a collection of small, independent services that communicate with each other, often using RESTful API's. The approach aims to overcome limitations of monolithic architectures like scalability and allow for independent deployments. The key principles include organizing services around business domains, automating processes, and designing services to be independently deployable.
Google has been using containers for over 12 years to manage applications. Kubernetes was created by Google to manage container clusters and provide basic building blocks for microservices. Kubernetes allows containers to be scheduled across a cluster, provides health checking and rolling upgrades, and handles naming, discovery, load balancing and other functions. Apigee extended Kubernetes to enable multi-tenancy and container-native API management.
This document provides an overview of architecting microservices using .NET. It discusses why microservices are used, common architecture patterns, and implementation considerations. Key points include:
- Independent, loosely coupled services that are fault tolerant and easy to scale are goals of a microservices architecture.
- Communication between services should be kept simple, using either synchronous HTTP or asynchronous messaging. Synchronous calls can lead to temporal coupling so circuit breakers and failure handling are important.
- Domain-driven design principles like bounded contexts and separating queries from commands (CQRS) can help define appropriate service boundaries and responsibilities.
- Event sourcing avoids shared state and two-phase commits by persisting a sequence of events rather than
Microservice With Spring Boot and Spring CloudEberhard Wolff
Spring Boot and Spring Cloud are an ideal foundation for creating Microservices based on Java. This presentation explains basic concepts of these libraries.
Microservices: Where do they fit within a rapidly evolving integration archit...Kim Clark
Do microservices force us to look differently at the way we lay down and evolve our integration architecture, or are they purely about how we build applications? Are microservices a new concept, or an evolution of the many ideas that came before them? What is the relationship between microservices and other key initiatives such as APIs, SOA, and Agile. In this session, we will unpick what microservices really are, and indeed what they are not. We will consider whether there is something unique about this particular point time in technology that has enables microservice concepts to take hold. Finally, we will look at if, when, where and how an enterprise can take on the benefits of microservices, and what products and technologies are applicable for that journey.
Microservices + Oracle: A Bright FutureKelly Goetsch
The document provides an overview of a presentation on microservices and Oracle products. It begins with copyright information and a safe harbor statement. It then outlines the agenda, which includes an introduction to microservices, their history, prerequisites for adopting them, how to implement them, and how Oracle products support them. The document discusses how microservices decompose monolithic applications into independent, self-contained services.
Microservices Done Right: Key Ingredients for Microservices SuccessApigee | Google Cloud
This document discusses microservices and keys to microservices success. It defines microservices as independently deployable services that work together. Microservices allow for agility, reuse, and productivity. The document outlines how enterprises are adopting microservices with containers, registries, auto-scaling and blue/green deployments. It emphasizes that REST APIs are a key ingredient for microservices success by enabling consumption and shielding consumers from complexity. The document also notes that microservices will fail without API management for issues like API sprawl, security threats and lack of visibility. It positions Apigee as providing the API layer and management capabilities needed for successful microservices.
This document discusses serverless computing on AWS. It states that serverless computing allows you to build highly available and cost-effective applications that scale automatically without having to manage servers. It then provides an overview of various AWS services that can be used to build serverless applications, including AWS Lambda for event-driven compute, Amazon S3 for static hosting, Amazon DynamoDB for data storage, AWS Step Functions for microservice coordination, and others.
This document discusses Haufe-Lexware's API strategy. It advocates adopting a microservices architecture with independently working teams that follow an API style guide. APIs are organized by domain and sit at the domain boundary rather than for internal communication. API management follows a DevOps approach with immutable infrastructure, containerization, and green-blue deployments. The role of APIs is to act as a shock absorber by decoupling domains, systems, teams, and development speeds through outside-in design and self-service.
Simulating APIs for Effective Testing: (Micro)Service Virtualisation for the ...Andrew Morgan
This document discusses service virtualization and API simulation for testing distributed systems and microservices. It outlines some of the challenges in testing these systems, such as flaky dependencies, non-deterministic responses, and difficulty triggering faults. It then provides an overview of service virtualization as an approach to emulate services in a non-intrusive way. Key benefits include isolation, handling flaky dependencies, and enabling deterministic and configurable testing. Specific tools and techniques are presented for recording service interactions, replaying them in tests, and injecting faults.
The document provides "10 Tips for failing badly at Microservices". It is a presentation given by David Schmitz with tips on how to sabotage a microservices project if your boss wants you to modernize your systems. Some of the tips include going full polyglot with many technologies, having all microservices share the same database or event store, building your own frameworks and tools instead of using existing ones, treating infrastructure as an afterthought, and prioritizing hiring for buzzword technologies over architectural quality. The overall tone is humorous, presenting anti-patterns and bad practices to intentionally undermine a microservices project.
Master the flow of microservices - because your business is more complex than...Bernd Ruecker
- The document discusses using microservices and event-driven architecture together with orchestration. It notes that while events allow for loose coupling, tracking logical flows across services can become difficult.
- An order handling example is presented to illustrate challenges like a payment service needing to know all possible events that could trigger a payment. This calls for introducing an order service to handle event-command transformation and orchestration across services.
- The document argues that modern lightweight workflow engines can be embedded within microservices to enable orchestration without introducing a centralized point of control. This allows logical flows to be modeled and changes to be made without affecting individual services.
Die Mobiliar setzt seit 2014 Microservices ein. Schrittweise wurden bis heute 450 Microservices in die Produktion gebracht.
Dabei haben wir viel über die Schnittstellen, Granularität, Plattformarchitektur aber auch viel über Continous Delivery von
Microservices gelernt.
Wir implementierten einen Approach wie man eine lose Architektur für die Teams und die IT Architektur messen und verwalteten kann (Architecture as Code). Die Veränderung der Entwicklungskultur (DevOps, Leadership) konnte ebenfalls beobachtet werden. Einige Aspekte dieser Erfahrungen werden vorgestellt und geteilt.
Um agile Entwicklung sinnvoll in einem Projekt zu ermöglichen, spielt die Architektur des Systems eine entscheidende Rolle. In einem agilen Projekt sind Architektureigenschaften wie Installierbarkeit und Prüfbarkeit entscheidend, da die Software in kurzen Abständen regelmäßig geliefert und im besten Fall dem Endnutzer zur Verfügung gestellt wird. Diese kurzen Releasezyklen gelingen nur durch ein hohes Maß an Automatisierung. Agile Projekte benötigen bereits passende Lösungsansätze in der Architektur, die es erlauben eine Continous Delivery Pipeline möglichst einfach zu realisieren; das Architekturmuster „Microservices“ versucht u.A. diesen Anforderungen gerecht zu werden.
Weitere Vorteile des Architekturmusters ergeben sich bei der Skalierung von Projekten. Durch den Einsatz von „Microservices“ können Projekte einfach aufgeteilt und parallel von mehreren Cross-Functional Teams mit agilen Methoden umgesetzt werden.
Die Idee eines Microservice ist nicht neu: das System wird in kleine, losgelöste Anwendungen (sog. Microservices) aufgeteilt. Diese Bausteine stellen Ihre Funktionalität als Service zur Verfügung. Der Vortrag gibt einen Praxiseinblick, auf welche Weise man vom Einsatz des Architekturmusters „Microservice“ in einem agilen Projektumfeld profitieren kann. Es wird aufgezeigt, wo sich in der Praxis Schwierigkeiten ergeben und wie man diesen vorbeugen kann. Der gesamte Vortrag gibt einen grundlegenden Einblick in die agile Entwicklung auf Basis einer Microservice-Architektur.
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...engelschall
Microservices sind seit einiger Zeit in aller Munde. Allerdings ist dieser Architekturansatz mit durchaus grossen Herausforderungen verbunden und bringt auch gewisse Nebenwirkungen mit sich. In dieser Präsentation wird deshalb ein absichtlich ketzerischer Blick auf das Thema Microservices geworfen. Ziel ist es, dass Software Architekten sich der zahlreichen Herausforderungen bewusst werden und diese explizit in ihren Microservice-basierten Lösungen adressieren.
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPChristian Guenther
Software Architecture Design Patterns für Cloud Service Entwicklungen
Domain Principles für Cloud Services und Cloud Anwendungsentwicklung
In den letzten zehn bis fünfzehn Jahren haben sich eine Reihe von Architekturparadigmen etabliert, die heute die Grundlage für Unternehmensanwendungen definieren und in vielfältigen Standards, Frameworks und Best Practices so fest verankert sind, dass man kaum noch darüber nachdenkt.
Wendet man diese Paradigmen unreflektiert auf Cloud-Anwendungen an, führt das in der Regel zu ernüchternden Resultaten. Insbesondere die für Cloud Computing wichtigen Eigenschaften Skalierbarkeit, Elastizität und Robustheit sind auf diese Weise nicht erreichbar.
Ein Umdenken ist also notwendig, um die Potenziale der Cloud freizusetzen.
Die COMLINE Cloud Computing Platform (CSP) ist die Antwort hierauf, sie ist eine moderne Plattform für Cloud-Computing und wurde als reaktives System konzipiert.
Reaktive Systeme müssen stets antwortbereit, widerstandsfähig, elastisch und nachrichtenorientiert sein. Systeme und Plattformen, die nach diesen Anforderungen entwickelt werden, erweisen sich als anpassungsfähiger, mit weniger starr gekoppelten Komponenten und in jeder Hinsicht skalierbarer. Sie sind einfacher weiterzuentwickeln und zu verändern. Sie reagieren zuverlässiger und eleganter auf Fehler und vermeiden so desaströse Ausfälle. Reaktive Systeme bereiten dem Anwender durch ihre fortwährende Antwortfreudigkeit eine interaktive und höchst befriedigende Erfahrung.
All diese Anforderungen erfüllt die COMLINE Cloud Service Plattform.
Aus Sicht der COMLINE eine PaaS (Platform as a Service) dar, auf der COMLINE Cloud-Dienste entwickelt.
Betrieben wird die CSP auf einem IaaS Modell in COMLINE-eigenen Rechenzentren in Berlin
Die Cloud-Dienste werden zu Anwendungen zusammengefasst, die von Kunden der COMLINE im Sinne eines SaaS (Software as a Service) Modells gemietet und genutzt werden können.
Sowohl die Plattform selber, als auch die Services und Anwendungen werden entlang einer Reihe von Guidelines entwickelt und betrieben. Diese Guidelines bilden die Grundlage aller Aktivitäten (von Design, über Konzeption bis hin zu Entwicklung und Betrieb) auf der CSP
Die Folien auf Slideshare zeigen die Prinzipien, Paradigmen und Design Patterns auf, nach denen wir sowohl die CSP selber betreiben, als auch die Anwendungen auf ihr entwickeln und betreiben.
Die CSP wurde massgeblich von Christian Günther konzipiert und stellt heute die DeFacto Entwicklungsplattform für COMLINE dar.
Anatomie von Microservice LandschaftenMichael Plöd
Building a Microservice is no hard task these days. With current frameworks it is fairly easy to create a self contained application that exposes Services via a RESTful interface. The Challenge for Microservices lies within the overall landscape: how to they interact with each other? How about service lookup? What about resilience? This session adresses the usual building blocks that are needed for Microservice landscapes and gives an overview of suitable open source frameworks in the market.
Innovations- und Informationskultur mit Web 2.0 (2010)Intelliact AG
Von der wachsenden Flut an Information werden auch die „Wissensarbeiter“ im Unternehmen nicht verschont. Was kann ein Unternehmen von der neuen Kultur im Umgang mit Information und Innovation lernen? Wo verbergen sich die Risiken und wie kann kontrolliert ein Nutzen aus der Informationsvielfalt gewonnen werden?
Was bringen Micoservicearchitekturen im Enterpriseumfeld? Warum lohnt es sich, in die höhere Komplexität verteilter Systeme und von deren Deployment und Betrieb zu investieren, selbst wenn man nicht skalieren können muss wie Amazon oder Google? Wo sind die Grenzen, welche Patterns sollte man beachten um mit Microservices erfolgreich zu sein?
In diesem Vortrag zeige ich auf, warum es sich meiner Meinung nach auch im Enterpriseumfeld oft lohnen kann Microservice-architekturen in einer ihrer verschiedenen Ausprägungen einzusetzen, was meine Erfahrungen damit sind und was die Vorrausetzungen dafür sind.
Osudio + commercetools Webinar: Microservices - Flexibilität und Geschwindigk...Dirk Hoerig
Microservices verhelfen Händlern und Herstellern zu mehr Agilität und unterstützen sie dabei, Innovationen schnell umzusetzen und zu iterieren. In dieser Präsentation zeigen wir, warum ein granularer Architekturansatz wesentliche Vorteile gegenüber monolithischen E-Commerce-Lösungen bietet und dass man nicht Amazon und Netflix heißen muss, um in ihren Genuss zu kommen.
Mind the Gap - Architecture versus Code @ W-JAX 2016Oliver Fischer
Mind the Gap is a talk by Oliver Fischer on the problem of keeping the intended architecture and the existing one very close to each other. One supposed way is to use jQAssistant to analyse any Java software system and to validate its conformance with the intended architecture.
Kunden erwarten heute eine permanente Verfügbarkeit von Services in allen Lebenslagen: Von unterwegs, zuhause, im Büro und in der Freizeit. Der Service muß das Anliegen schnell, einfach und zuverlässig bearbeiten. Und das alles unter Einbeziehung vorhandener Plattformen, Technologien und Geräte.
Das erfordert Serviceinnovationen, mit denen sich Kunden selbst oder untereinander helfen können. Die Relevanz von Self-Services, Kontext- Services, Tragbarer und Vernetzter Services wird weiter deutlich zunehmen. Aus Unternehmenssicht müssen diese Angebote vor allem effizient und zuverlässig im Zusammenspiel funktionieren, um positive Kundenerlebnisse zu schaffen und so die Weiterempfehlungsquote und damit Umsatz und Ergebnis zu steigern.
Innovative Services bieten je nach situativen Anforderungen des Nutzungskontexts eine umfassende Unterstützung des Kunden. Dabei steht der Einsatz neuer Technologien immer im Dienst des Kundennutzens und der Serviceziele. Es sind Lösungen gefragt, die in relevanten Kundenszenarien persönlichen Service und technische Möglichkeiten in perfekter Art und Weise miteinander zu verknüpfen.
Die Wechselwirkungen zwischen Service- und Technologieentwicklung intensivieren sich: Neue Technologien – insbesondere aus den Bereichen Informations- und Kommunikationstechnik – ermöglichen neue Arten von Services und neue Mechanismen ihrer Entwicklung und Erbringung.
Zugleich befördern innovative Servicekonzepte die Entwicklung neuer technischer Lösungen. Schließlich erfordern innovative Technologien neue Dienstleistungen, um überhaupt nutzbar zu werden. Es kommt zu einer engeren Verzahnung von Produktion und Dienstleistungen: Immer häufiger werden materielle Produkte und Dienstleistungen zu „Komplettangeboten“ gebündelt.
Wenn neue Services in Zukunft professionell entwickelt werden sollen, muß das genauso akribisch und methodisch geschehen, wie das bei Produkten der Fall ist. Dazu gehören Entwurf, Evaluierung, Test und Prototyping von neuen, innovativen Ideen. Dazu müssen - auch mit wissenschaftlicher Unterstützung – Labore eingerichtet werden, in denen Services entwickelt und getestet werden können.
Schließlich ist es im Entwicklungsprozeß des Service unverzichtbar, den Kunden einzubinden, denn es geht bei den Lösungsangeboten nicht nur um „Hightech“, sondern vor allem um „Hightouch“.
Die kompletten Ergebnisse der Studie können auf der Internetseite des Instituts unter www.DieServiceForscher.de bezogen werden.
Pragmatic SOA - Beschränken auf das Wesentliche1&1
SOA ist mittlerweile ein weit bekanntes Paradigma. Leider bleibt es oftmals zu abstrakt, um greifbar zu sein, oder es wird auf einzelne Technologien reduziert. Darüber geraten leicht die eigentlichen Ziele für den Einsatz einer SOA aus dem Blickfeld. Diese Session stellt eine pragmatische Herangehensweise bei Aufbau und Einführung einer SOA vor und geht dazu auf Theorie und Praxis ein.
Wenn es um Innovationsfähigkeit und Geschwindigkeit in der IT geht, fällt in der Regel das Stichwort DevOps. DevOps steht für die gemeinsame Betrachtung von technischen und organisatorischen Abläufen in der Anwendungsentwicklung (Dev) und dem IT-Betrieb (Ops), sowie der engen Verzahnung dieser Bereiche über den gesamten Lebenszykus der Software hinweg. Der Vortrag beleuchtet die organisatorischen und technischen Themen anhand der Geschichte hinter dem neuen dm-onlineShop.
Speaker: Alexander Pacnik, inovex GmbH
DevOpsCon, 24.11.2015
Weitere Vorträge von inovex: https://www.inovex.de/de/content-pool/vortraege/
Mobile Days Kongress mobile Instandhaltung 2019RODIAS GmbH
Jahreskongress für mobile Instandhaltungslösungen in Düsseldorf. Diverse Vorträge von Anwendern bzgl. Systemeinführungen, Implementierungen im Reinraum, Cloudplattform-basierte Lösungen, Einsatz von Smartphones, Tabletts und Datenbrillen. Chancen von 5 G, Einsatz von Drohnen und KI, Workforce Management Lösungen etc.
Mit den passenden Algorithmen lassen sich aus Daten Erkenntnisse, Muster und Schlüsse gewinnen. Data Scientists steigen tief in die Welt der Daten und Algorithmen ein und entwerfen die zum Anwendungsfall passende Lösung.
Auch Führungskräfte sollten ein Grundwissen über die wichtigsten Begriffe und Zusammenhänge der Welt der Data Science haben.
Unser Vortrag gibt einen Überblick über Möglichkeiten von Big Data und Machine Learning und zeigt, wie mit agilen Mitteln und den richtigen Skills der Einstig in die neue Welt gelingt
Der Vortrag zeigt die Grenzen bisheriger Lösungen und gibt einen Überblick über neue Lösungen.
Er zeigt, wie Systemlandschaften weltweit tätiger (Internet-)Konzerne aussehen und leitet daraus herunterskalierte, praktikable Lösungen auch für kleinere Unternehmen mit weit weniger Datenvorkommen ab.
Unser Vortrag gibt einen Überblick über Möglichkeiten von Big Data und Machine Learning und zeigt, wie mit agilen Mitteln und den richtigen Skills der Einstig in die neue Welt gelingt.
Unser Vortrag gibt einen Überblick über Möglichkeiten von Big Data und Machine Learning und zeigt, wie mit agilen Mitteln und den richtigen Skills der Einstig in die neue Welt gelingt
Der Vortrag zeigt die Grenzen bisheriger Lösungen und gibt einen Überblick über neue Lösungen.
Er zeigt, wie Systemlandschaften weltweit tätiger (Internet-)Konzerne aussehen und leitet daraus herunterskalierte, praktikable Lösungen auch für kleinere Unternehmen mit weit weniger Datenvorkommen ab.
Mit den passenden Algorithmen lassen sich aus Daten Erkenntnisse, Muster und Schlüsse gewinnen. Data Scientists steigen tief in die Welt der Daten und Algorithmen ein und entwerfen die zum Anwendungsfall passende Lösung.
Auch Führungskräfte sollten ein Grundwissen über die wichtigsten Begriffe und Zusammenhänge der Welt der Data Science haben.
Unser Vortrag gibt einen Überblick über Möglichkeiten von Big Data und Machine Learning und zeigt, wie mit agilen Mitteln und den richtigen Skills der Einstig in die neue Welt gelingt.
Mit den passenden Algorithmen lassen sich aus Daten Erkenntnisse, Muster und Schlüsse gewinnen. Data Scientists steigen tief in die Welt der Daten und Algorithmen ein und entwerfen die zum Anwendungsfall passende Lösung.
Auch Führungskräfte sollten ein Grundwissen über die wichtigsten Begriffe und Zusammenhänge der Welt der Data Science haben.
Der Vortrag zeigt die Grenzen bisheriger Lösungen und gibt einen Überblick über neue Lösungen.
Er zeigt, wie Systemlandschaften weltweit tätiger (Internet-)Konzerne aussehen und leitet daraus herunterskalierte, praktikable Lösungen auch für kleinere Unternehmen mit weit weniger Datenvorkommen ab.
Mehr von IKS Gesellschaft für Informations- und Kommunikationssysteme mbH (20)
2. Micro, Nano, Mono? Microservices verständlich erklärt 2 | 48
Agenda
Softwaresysteme unter Veränderungen
Was sind Microservices?
Aspekte der Microservice-Architektur
Zum Abschluss
4. Micro, Nano, Mono? Microservices verständlich erklärt 4 | 48
Auch Softwaresysteme altern
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
5. Micro, Nano, Mono? Microservices verständlich erklärt 5 | 48
Treiber der Alterung von Softwaresystemen
Veränderungen über die Zeit lassen Softwaresysteme altern.
Änderungen von fachlichen Anforderungen
Fehlererkennung und -behebung
Änderungen von nicht-funktionalen Anforderungen
Plattformwechsel
Teamwechsel
technologischen Anpassungen
Abbau technischer Schulden
Das macht die Komplexität von Softwaresystemen aus.
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
6. Micro, Nano, Mono? Microservices verständlich erklärt 6 | 48
Mögliche Auswirkungen von Veränderungsprozessen
Es dauert immer länger, um Releases freizugeben
Es ist fast nicht mehr möglich, neue Technologien zu integrieren
Fehler im System nehmen von Release zu Release zu
Fachliche Änderungen verstreuen sich über Ihre gesamte Anwendung
Oft ist gar nicht klar, welche Teile des Systems betroffen sind
Kleine Änderungen haben große Auswirkungen
Z.B. aufwendige Abnahme des Gesamtsystems
Ihre Datenbankstruktur ist unübersichtlich
Es ist nicht klar, welche Tabellen miteinander zu tun haben
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
7. Micro, Nano, Mono? Microservices verständlich erklärt 7 | 48
Was sind Microservices?
8. Micro, Nano, Mono? Microservices verständlich erklärt 8 | 48
Das sind Microservices!
Modularisierung
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
9. Micro, Nano, Mono? Microservices verständlich erklärt 9 | 48
Microservice(s)-Architektur
beschreibt einen Architektur-Stil
Unabhängig von Technologien
D.h. Microservices = Microservice-Architektur
unterstützt Evolution von Architektur in komplexen Systemen
Unterstützt die Änderung der Architektur (Eigendynamik) durch Modularisierung
Architektur ist so dynamisch, wie die Einflüsse auf das System
Es gibt keine normierte Definition
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
10. Micro, Nano, Mono? Microservices verständlich erklärt 10 | 48
Eigenschaften von Microservice-Architekturen1)
Microservice-Architektur beschreibt ein System von lose gekoppelten
Services, welche sich über leichtgewichtige Kommunikation verständigen.
Kommunikation nur zwischen Microservices
Das Innere der Microservices ist strikt von der Außenwelt isoliert
Microservices sind unabhängig voneinander deploybar
1) Sehr häufig finden Sie eine Definition von Microservices über diese Eigenschaften [Fowler]
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
11. Micro, Nano, Mono? Microservices verständlich erklärt 11 | 48
Membran des Microservice – Public Interfaces
Membran regelt den
Austausch mit der Umwelt
Nachricht an den Service
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
12. Micro, Nano, Mono? Microservices verständlich erklärt 12 | 48
Membran des Microservice – Public Interfaces
Microservices bieten öffentliche Schnittstellen an
Kommunikation mit der Außenwelt nur über diese Schnittstellen
Public Interfaces
Public Interfaces erlauben die kontrollierte Abschottung eines Services
Es wird nur sichtbar, was sichtbar sein soll
Schnittstellen-Design muss auch evolutionär sein
Umgang mit Schnittstellenänderungen
Umgang mit Daten der Schnittstelle
Fehler im Design der Schnittstelle sind teuer
REST over HTTP(S) ist gängige Technologie für Public Interfaces
Es gibt noch weitere Technologien
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
13. Micro, Nano, Mono? Microservices verständlich erklärt 13 | 48
Isoliertes Deployment gegen Dependency Hell
Monolith Microservices
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
15. Micro, Nano, Mono? Microservices verständlich erklärt 15 | 48
Es gibt nicht die eine Microservices-Architektur
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
16. Micro, Nano, Mono? Microservices verständlich erklärt 16 | 48
Spannungsfelder der Microservices-Architektur
Granularität – Größe von Microservices
Kommunikation zwischen den Microservices
Datenhaltung
Steuerung der Zusammenarbeit der Microservices
Technologische Autonomie der Microservices
Deployment-Strategien
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
17. Micro, Nano, Mono? Microservices verständlich erklärt 17 | 48
Granularität – Größe von Microservices
Regel für die Größe eines Microservices
100 – 1000 LOC findet man oft
one/two Pizza Team
Exakte Metrik für der Größe ist m.E. nicht zielführend
Die Größe wird durch Verantwortlichkeit definiert
?
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
18. Micro, Nano, Mono? Microservices verständlich erklärt 18 | 48
Wo kommen Services her?
Services werden durch Geschäftsprozesse und (Fach-)Domänen bestimmt
Services werden durch das Business definiert
Stabilisiert das System
Microservices sind die technische Umsetzung von Geschäftsvorfällen
Grob, grob, grob ….
Facharchitektur muss die Services fachlich vorgegeben
Zwischen Business und Entwicklung muss eine Brücke geschlagen sein
Domain Driven Design (DDD) liefert eine Methode, Microservices konsistent zu
designen
Microservices entstehen durch technische Adaption des DDD
Vereinfacht
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
19. Micro, Nano, Mono? Microservices verständlich erklärt 19 | 48
Servicezentriert – Durchgängigkeit der Microservices
Facharchitektur
Domain Driven
Design
Deployment
Betrieb
Services sind ein durchgängiges Konzept
Stabil über alle Lebenszyklen eines Systems
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
20. Micro, Nano, Mono? Microservices verständlich erklärt 20 | 48
Wo kommen Services her?
Microservices scheitern, falls sie nicht durch eine
Facharchitektur gestützt werden.
Falls Microservices nicht die Fachlichkeiten wiederspiegeln,
ergeben sich die gleichen Probleme wie bei Monolithen.
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
21. Micro, Nano, Mono? Microservices verständlich erklärt 21 | 48
Services sind . . .
kohärent
Ein Microservices ist für abgeschlossene, konsistente Menge an Funktionalität zuständig
Siehe auch Single Responsibility Principle (SRP)
autonom
Die Erledigung seiner Aufgabe hängt nicht von anderen Services ab
Wir sehen später, welche Konsequenzen diese Forderungen haben können
Dies sind Ziele, keine Gesetze
Können im Zweifel aufgeweicht werden
Aber nicht zu sehr ;-)
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
22. Micro, Nano, Mono? Microservices verständlich erklärt 22 | 48
Granularität – Größe von Microservices
Große Microservices Kleine Microservices
| | |
Enge Kopplung durch mehr Kommunikation
Überschaubar/verstehbar
Aufwendigeres Deployment
Lose Kopplung durch weniger Kommunikation
Starke innere Kopplung
Monolithische Tendenzen
Wird durch fachliche Verantwortlichkeit bestimmt
Dennoch bleibt eine Bandbreite …
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
23. Micro, Nano, Mono? Microservices verständlich erklärt 23 | 48
Kommunikation
Microservices-Architektur führt zu verteilten Systemen
=> verteilte Kommunikation
7 irrige Annahmen über verteilte Systeme (7 fallacies of distributed Computing [wikipedia-2])
Netzwerk ist stabil und verlässlich
Es gibt keine Latenzzeiten
Netzwerk ist sicher und geschützt
. . .
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
24. Micro, Nano, Mono? Microservices verständlich erklärt 24 | 48
Kommunikation zwischen Microservices
Synchrone Kommunikation
Synchrone Kommunikation wartet auf Antwort
Microservice hängt vom Antwortverhalten des Partnerservice ab
Erhöht die Kopplung der Microservices
Verringert Autonomie
Beispiel: REST
Asynchrone Kommunikation
Fire and Forget
Beispiel: Messagequeues
Synchrone Kommunikation Asynchrone Kommunikation
| | |
Enge(re) Kopplung
Einfaches Programmiermodell
Anfällige Kommunikation
Lose Kopplung
Komplexes Programmiermodell
Stabile Kommunikation
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
25. Micro, Nano, Mono? Microservices verständlich erklärt 25 | 48
Datenhaltung
Enge und implizite Kopplung
Einfaches Programmiermodell
Anfällige Kohärenz
Lose Kopplung
Sehr gute Skalierbarkeit
Komplexes Betriebsmodell
Stabile Kohärenz
Shared Database
Shared Database System,
Database per Service
Database System per Service
| | |
Lose Kopplung
Komplexeres Programmiermodell
Stabile Kohärenz
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
26. Micro, Nano, Mono? Microservices verständlich erklärt 26 | 48
Steuerung der Zusammenarbeit
Orchestrierung
Zentrale Instanz koordiniert die Zusammenarbeit der Services
Automatische Workflows (BPEL, BPMN )
Massive Kenntnis über Services <-> viel implizites Wissen der Services
Choreographie
Interaktion unter Gleichgestellten
Keine zentrale Instanz
Koordination statt zentraler Kontrolle
ChoreographieOrchestrierung
| | |
Zentrale Kontrolle
Synchrone Kommunikation
Enge Kopplung
Koordination unter Gleichgestellten
Asynchrone Kommunikation möglich
Lose Kopplung
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
27. Technologische Autonomie
Isoliertes Deployment verbessert die technologische Autonomie
Kommunikationsverfahren müssen immer zwischen Microservices abgestimmt
werden
Fragestellungen:
Wie viele Technologien kann meine Entwicklung vertragen/beherrschen?
Wie viele verschiedene Datenbanksysteme kann mein Betrieb beherrschen?
Wie viel Wert lege ich auf Abbau technischer Schulden pro Microservice?
Technologische Autonomie
des Services
Enge technologische
Rahmenbedingungen
| | |
Enge technologische Kopplung
Technologische Koordination
Kleiner Zoo an Technologien
Lose technologische Kopplung
Wenig technologische Koordination
Umfangreicher Zoo an Technologien
Abbau technischer Schulden pro Service
28. Micro, Nano, Mono? Microservices verständlich erklärt 28 | 48
Deployment-Strategien – Mehrere Service-Instanzen
per Host Managed Laufzeitumgebung für Services
Ist in der Regel ein Prozess
z.B. ApplicationServer, OSGi, ESB
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
29. Deployment-Strategien – Service Instanz pro
Virtueller Maschine Infrastruktur, um Services
• zu verteilen
• zu starten
• zu finden
Ein Service pro Maschine/VM
Public Infrastructure, z.B. Amazon EC2
Tools, z.B. Netflix Stack mit
Eureka, Ribbon, Zuul,…
30. Deployment-Strategien – Service Instanz pro
Container Infrastruktur, um Container
• zu verteilen
• zu starten
• zu finden
Ein Service pro Container
Mehrere Container pro Host/VM
Public Infrastructure, z.B. Amazon EC2, GAE
Cloud Foundry, OpenStack
Tools, z.B. Docker Engine, Kubernetes, Apache
Mesos, . . .
31. Deployment-Strategien – Serverless Deployment
Amazon Web Services
z
λλλλ
Datenhaltung
Streaming
E-Mail
HTTP
λλλλ
λλλλ
λλλλ
Infrastruktur-Services
Nano-Services
Bsp: Amazon AWS Lambda
Kinesis
S3, DynamoDB
API Gateway
32. Micro, Nano, Mono? Microservices verständlich erklärt 32 | 48
Deployment-Szenarien
Mehrere Service-Instanzen
pro Host/Maschine (JEE)
Service-Instanz
pro Container (Docker)
Service-Instanz
pro VM (Netflix)
Nicht für Skalierung optimierte Infrastruktur
Klassisches Deployment
Nicht isolierte Laufzeitumgebung
Nicht automatisierte Infrastruktur
Geht ohne DevOps
Für Skalierung optimierte Infrastruktur
Isolierte Laufzeitumgebung
Automatisierte Infrastruktur
Geht nicht ohne DevOps
| | |
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
33. Micro, Nano, Mono? Microservices verständlich erklärt 33 | 48
| | |
Synchrone Kommunikation Asynchrone Kommunikation
| | |
Shared
Database
Database System
per Service
Database
per Service
| | |
Enge technologische
Rahmenbedingungen
Technologische Autonomie
des Service
| | |
Orchestrierung Choreographie
| | |
Große Microservices Kleine Microservices
| | |
Mehrere Services
pro Instanz
Service-Instanz
pro Container (Docker)
Service-Instanz
pro VM (Netflix)
Jede Domäne ist anders
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
34. Micro, Nano, Mono? Microservices verständlich erklärt 34 | 48
Weitere Herausforderungen
Logging und Monitoring
Je mehr Beteiligte, desto entscheidender ist Logging und Monitoring
Informationen aller Microservices müssen zentral zusammengeführt werden
Sammeln, speichern, suchen und aufbereiten
Jeder Microservice integriert sich selbst
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
35. Micro, Nano, Mono? Microservices verständlich erklärt 35 | 48
Weitere Herausforderungen
Logging und Monitoring
Security
Autorisierung und Authentifizierung der Kommunikation
SSO + Loadbalancing
Delegationsverfahren wie OAuth2, ….
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
36. Micro, Nano, Mono? Microservices verständlich erklärt 36 | 48
Weitere Herausforderungen
Logging und Monitoring
Security
Testverfahren
Testverfahren auf Ebene der Microservices
Consumer-Driven-Tests
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
37. Micro, Nano, Mono? Microservices verständlich erklärt 37 | 48
Weitere Herausforderungen
Logging und Monitoring
Security
Testverfahren
Fehlertoleranz und Resilienz – design for failure
Absicherung gegen Nicht-Erreichbarkeiten
Implementiert jeder Microservice für sich
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
38. Micro, Nano, Mono? Microservices verständlich erklärt 38 | 48
Jede Domäne ist anders
Es gibt nicht die eine Microservice-Architektur
Ihre Microservices-Architektur muss
Ihre Probleme lösen
Ihren Anforderungen entsprechen
Ihre Gegebenheiten respektieren
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
40. Micro, Nano, Mono? Microservices verständlich erklärt 40 | 48
Microservices . . .
sind ein Architekturstil
Unterstützen evolutionäre Architektur
werden durch fachliche Geschäftsvorfälle bestimmt
Architektur ist individuell
Muss an Anforderungen und Gegebenheiten Ihres Unternehmens angepasst werden
müssen in einem System bewusst und konsequent angewendet werden
Systeme neigen zu impliziten Kopplungen
sind an keine Technologie gebunden
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
41. Micro, Nano, Mono? Microservices verständlich erklärt 41 | 48
Microservices . . .
basieren auf einem übergreifenden, durchgängigen fachlichen Servicekonzept
Ohne dieses durchgängige Konzept sind Microservices nur sehr schwer zu beherrschen
spielen ihre Stärken und Potential voll aus, wenn sie
durch agile Methoden unterstützt werden
durch automatisierte Infrastruktur unterstützt werden (DevOps)
durch passende Organisationsstrukturen unterstützt werden
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
42. Micro, Nano, Mono? Microservices verständlich erklärt 42 | 48
Vielen Dank!
Fragen?
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
43. Micro, Nano, Mono? Microservices verständlich erklärt 43 | 48
Referenzen
[Fowler] http://martinfowler.com/articles/microservices.html
[schlemm] A. Schlemm http://www.thur.de/philo/som/somkomplex.htm
[schoeneberg] Komplexitätsmanagement in Unternehmen; Schoeneberg
http://www.springer.com/de/book/9783658012830
[Peinl] Überblick über Docker-Cluster-Technologien - Peinl 2016 (SIGS-
DATACOM)
http://www.sigs-
datacom.de/uploads/tx_dmjournals/peinl_OTS_Microservices_Docker_16.pdf
[SOA-Manifest] http://soa-manifest.de/
[RAML] http://raml.org/
[wikipedia-1] https://de.wikipedia.org/wiki/Komplexit%C3%A4t
[wikipedia-2] https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
[wikipedia-3] https://de.wikipedia.org/wiki/Cynefin-Framework
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
44. Micro, Nano, Mono? Microservices verständlich erklärt 44 | 48
https://blog.iks-gmbh.com/was-ist-eine-microservice-architektur/
http://samnewman.io/blog/2015/04/07/microservices-for-greenfield/
https://genehughson.wordpress.com/2015/05/18/microservices-
sharpening-the-focus/
https://genehughson.wordpress.com/2014/05/23/carving-it-up-
microservices-monoliths-conways-law/
http://simplearchitectures.blogspot.de/2012/09/snowman-architecture-
part-one-overview.html
https://genehughson.wordpress.com/2014/11/24/microservice-principles-
and-enterprise-it-architecture/
https://genehughson.wordpress.com/2014/06/04/more-on-microservices-
boundaries-governance-reuse-complexity/
https://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-
matters-its-also-how-you-use-them-part-1/ Teile 1-6
http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
Weiterführende Literatur
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
45. Micro, Nano, Mono? Microservices verständlich erklärt 45 | 48
Bildreferenzen
https://pixabay.com/de/fischernetze-fischernetz-fischerei-101992/
https://pixabay.com/de/bienen-bienenstock-imkerei-honig-486872/
https://pixabay.com/de/bienenwabe-honigwabe-honig-lecker-1564956/
https://pixabay.com/de/blumenwiese-wiesenblumen-sommerwiese-
1657016/
https://pixabay.com/de/himmel-wolken-sonnenstrahlen-414198/
https://pixabay.com/de/sonne-abendrot-morgenrot-209495/
https://pixabay.com/de/adler-vogel-raubvogel-greifvogel-339125/
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur
46. Micro, Nano, Mono? Microservices verständlich erklärt 46 | 48
Impulsvorträge für Ihr Unternehmen
Überblick über das gesamte Angebot an Impulsvorträgen unter:
www.iks-gmbh.com/impulsvotraege
Ihr Nutzen:
Unabhängiges, aktuelles Expertenwissen.
Individuell auf Ihr Publikum und Ihr Unternehmen zugeschnittene Vorträge.
Referenten mit langjähriger und branchenübergreifender Expertise in der IT-
Beratung.
Praxisnahe Vorträge, die aus Projektarbeit entstanden sind, frei von
Produktwerbung.
Ideale Ergänzung für Ihre Führungskräftetreffen, Abteilungsmeetings, Hausmessen,
Innovation Days, Konferenzen, Open Spaces, Kick-off-Meetings oder
Zukunftsworkshops.
Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der
Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur