Following topics will be addressed into presentation:
Motivation and goals of splitting monolith application
Criteria and markers to start splitting process. Is it necessary at all?
Optimal order of extracting microservices
How organize the whole process in closed iterative steps?
What can be done with common libraries and shared code?
Options for technology and deployment of target microservices
How organize and motivate the teams and convince management?
Speaker Bio
Andrei is a Software Architect in VMWare Tanzu Labs. The areas of his interest are REST API design, Microservices, Cloud, resilient distributed systems, security and agile development. Andrei is PMC and committer of Apache CXF and committer of Syncope projects.
Software Architecture and Architectors: useless VS valuableComsysto Reply GmbH
Abstract:
This talk introduces definitions of system architecture and proposes a way to achieve "good enough" architecture covers project requirements
Andrei will show several cases from real projects, where wrong, missing or over-sophisticated architecture decisions really hurt the development teams:
Painful sharing: do shared modules increase reusability or will be the source of problems?
Non-extensible extensibility: too sophisticated configuration hurts
Over fine-grained: incorrect splitting to microservices can make life even harder as with monolith
Cargo cult: blindly following patterns and rules can produce an unmaintainable system
Freestyle architecture: what happens if teams completely ignore architecture
Improve with less intelligence: smart endpoint and dumb pipes
We are looking forward to meet many of you in person and have great discussions around this topic!
https://www.meetup.com/de-DE/meetup-group-tfyvuydp/
Abstract
The idea of this talk is to help development teams to make correct architectural decisions.
Andrei will highlight the basic architectural principles and show ways to achieve architecture that is good enough to cover the project requirements and evolve in the future.
He will also present several cases from real projects, where wrong, missing, or over-sophisticated architecture decisions really hurt the development teams:
- Painful sharing: do shared modules increase reusability or will be the source of problems?
- Microservices are the solution to every problem!
- Non-extensible extensibility: too sophisticated configuration hurts
- Over fine-grained: incorrect splitting to Microservices can make life even harder as with monolith
- Convey horizontal split: how organizational driven split can jeopardise the architecture
- Model-driven: central responsibility blocks and limits the team
- Cargo cult: blindly following patterns and rule can produce an unmaintainable system
- Freestyle architecture: what happens if teams completely ignore architecture
- Improve with less intelligence: smart endpoint and dumb pipes
Abstract
The idea of this talk is to help development teams to make correct architectural decisions.
Andrei will highlight the basic architectural principles and show ways to achieve architecture that is good enough to cover the project requirements and evolve in the future.
He will also present several cases from real projects, where wrong, missing, or over-sophisticated architecture decisions really hurt the development teams:
- Painful sharing: do shared modules increase reusability or will be the source of problems?
- Microservices are the solution to every problem!
- Non-extensible extensibility: too sophisticated configuration hurts
- Over fine-grained: incorrect splitting to Microservices can make life even harder as with monolith
- Convey horizontal split: how organizational driven split can jeopardise the architecture
- Model-driven: central responsibility blocks and limits the team
- Cargo cult: blindly following patterns and rule can produce an unmaintainable system
- Freestyle architecture: what happens if teams completely ignore architecture
- Improve with less intelligence: smart endpoint and dumb pipes
Building Cloud-Native App Series - Part 5 of 11
Microservices Architecture Series
Microservices Architecture,
Monolith Migration Patterns
- Strangler Fig
- Change Data Capture
- Split Table
Infrastructure Design Patterns
- API Gateway
- Service Discovery
- Load Balancer
Istio as an enabler for migrating to microservices (edition 2022)Ahmed Misbah
This session is targeted towards teams and organizations considering to migrate their applications from monolithic to Microservice architecture by proposing Istio as an enabler. Istio is an implementation of service mesh, a technology useful for migrating to Microservices iteratively and safely.
Migrating application architectures to Microservices is considered a key area of transformation in the IT world. Modernizing legacy applications to Kubernetes-based Microservices can prove to be very challenging if not planned correctly, taking into consideration the right technologies and enablers.
This session explains how Istio can be used as a bridge and enabler for modernizing legacy monolithic applications to Microservices. Topics covered in the session will include:
1- Advantages of migrating to Microservices and service mesh .
2- Designing a Microservice application based on splitting an existing monolithic application.
3- Implementing Microservices iteratively as a strangler fig application with Istio.
4- Features Istio provides as a service mesh platform.
Software Architecture and Architectors: useless VS valuableComsysto Reply GmbH
Abstract:
This talk introduces definitions of system architecture and proposes a way to achieve "good enough" architecture covers project requirements
Andrei will show several cases from real projects, where wrong, missing or over-sophisticated architecture decisions really hurt the development teams:
Painful sharing: do shared modules increase reusability or will be the source of problems?
Non-extensible extensibility: too sophisticated configuration hurts
Over fine-grained: incorrect splitting to microservices can make life even harder as with monolith
Cargo cult: blindly following patterns and rules can produce an unmaintainable system
Freestyle architecture: what happens if teams completely ignore architecture
Improve with less intelligence: smart endpoint and dumb pipes
We are looking forward to meet many of you in person and have great discussions around this topic!
https://www.meetup.com/de-DE/meetup-group-tfyvuydp/
Abstract
The idea of this talk is to help development teams to make correct architectural decisions.
Andrei will highlight the basic architectural principles and show ways to achieve architecture that is good enough to cover the project requirements and evolve in the future.
He will also present several cases from real projects, where wrong, missing, or over-sophisticated architecture decisions really hurt the development teams:
- Painful sharing: do shared modules increase reusability or will be the source of problems?
- Microservices are the solution to every problem!
- Non-extensible extensibility: too sophisticated configuration hurts
- Over fine-grained: incorrect splitting to Microservices can make life even harder as with monolith
- Convey horizontal split: how organizational driven split can jeopardise the architecture
- Model-driven: central responsibility blocks and limits the team
- Cargo cult: blindly following patterns and rule can produce an unmaintainable system
- Freestyle architecture: what happens if teams completely ignore architecture
- Improve with less intelligence: smart endpoint and dumb pipes
Abstract
The idea of this talk is to help development teams to make correct architectural decisions.
Andrei will highlight the basic architectural principles and show ways to achieve architecture that is good enough to cover the project requirements and evolve in the future.
He will also present several cases from real projects, where wrong, missing, or over-sophisticated architecture decisions really hurt the development teams:
- Painful sharing: do shared modules increase reusability or will be the source of problems?
- Microservices are the solution to every problem!
- Non-extensible extensibility: too sophisticated configuration hurts
- Over fine-grained: incorrect splitting to Microservices can make life even harder as with monolith
- Convey horizontal split: how organizational driven split can jeopardise the architecture
- Model-driven: central responsibility blocks and limits the team
- Cargo cult: blindly following patterns and rule can produce an unmaintainable system
- Freestyle architecture: what happens if teams completely ignore architecture
- Improve with less intelligence: smart endpoint and dumb pipes
Building Cloud-Native App Series - Part 5 of 11
Microservices Architecture Series
Microservices Architecture,
Monolith Migration Patterns
- Strangler Fig
- Change Data Capture
- Split Table
Infrastructure Design Patterns
- API Gateway
- Service Discovery
- Load Balancer
Istio as an enabler for migrating to microservices (edition 2022)Ahmed Misbah
This session is targeted towards teams and organizations considering to migrate their applications from monolithic to Microservice architecture by proposing Istio as an enabler. Istio is an implementation of service mesh, a technology useful for migrating to Microservices iteratively and safely.
Migrating application architectures to Microservices is considered a key area of transformation in the IT world. Modernizing legacy applications to Kubernetes-based Microservices can prove to be very challenging if not planned correctly, taking into consideration the right technologies and enablers.
This session explains how Istio can be used as a bridge and enabler for modernizing legacy monolithic applications to Microservices. Topics covered in the session will include:
1- Advantages of migrating to Microservices and service mesh .
2- Designing a Microservice application based on splitting an existing monolithic application.
3- Implementing Microservices iteratively as a strangler fig application with Istio.
4- Features Istio provides as a service mesh platform.
Application Centric Microservices from Redhat Summit 2015Ken Owens
When Cisco started envisioning the future of its application development platforms, the ability to create applications that are cloud-native with elastic services, network-aware application policies, and micro-services was strategic to the company. When the decision to build and operate a Cisco cloud service delivery platform for collaboration, video, and Internet of Things (IoT) application development was made, OpenStack and micro-services became central to our application architectures and strategic to our vision as a company. This presentation will look at the journey Cisco developers took to transform to an application-centric OpenStack platform for application development in a secure, network-centric, and completely open source manner. The importance of the platform being Red Hat Enterprise Linux OpenStack Platform and using OpenShift by Red Hat and the contribution to the community will be described. The micro-services architecture and service-oriented DevOps lessons learned for enabling massive scalable and continuous delivery of software will be presented and demoed.
Speaker:
Owen Garrett
Sr. Director, Product Management
NGINX, Inc.
On-Deman Link: https://www.nginx.com/resources/webinars/need-service-mesh/
About the webinar:
Service mesh is one of the hottest emerging technologies. Even though it’s a nascent technology, many vendors have already released their implementation. But do you really need a service mesh?
Attend this webinar to learn about the levels of maturity on the journey to modernizing your apps using microservices, and the traffic management approaches best suited to each level. We’ll help you figure out if you really need a service mesh.
A Story of Cultural Change: PayPal's 2 Year Journey to 150,000 Containers wit...Docker, Inc.
Adopting containers at scale is fundamentally a cultural change. In late 2015, PayPal decided to migrate en masse to containers for applications built on many different frameworks over the last 15 years. It was a bold and strategic plan that included how to showcase value of containers to leadership, a phased execution strategy, building the right team to lead, and cultural transformation. Changing application code, deployment methods, and operational tools were at onset non-negotiable. This session will share how the plan was pitched and the learnings that unfolded as PayPal carefully changed everything - and nothing at the same time - to get to 150,000 containers running in production in 2 years.
This is a must-read for all engineers interested in developing a Micro services architecture. Turn your monolithic server into a prolific and multiple instance solution! Includes well-known example such as Netflix. Please contact me for more details.
Migrating to Microservices Patterns and Technologies (edition 2023)Ahmed Misbah
This session is targeted towards teams and organizations considering to migrate their applications from Monolithic to Microservice architecture. Migrating application architectures to Microservices is considered a key area of transformation in the IT world. Modernizing legacy applications to Kubernetes-based Microservices can prove to be very challenging if not planned correctly, taking into consideration the right technologies and enablers.
The session proposes Istio as an enabler for migrating to Microservices. Istio is an implementation of service mesh, a technology useful for migrating to Microservices iteratively and safely. We explain how Istio can be used as a bridge and enabler for modernizing legacy Monolithic applications to Microservices.
Move fast and make things with microservicesMithun Arunan
1. How to apply microservices patterns & anti-patterns to design the right architecture
2. Why & how to build a core framework to ensure consistency & manage complexity
3. What are the challenges in adopting gRPC for inter-service communication
4. How to orchestrate & manage microservices at scale with Kubernetes
5. How to leverage Cloud Native ecosystem to move fast & avoid vendor lock-in
An introduction to {code} by Dell EMC, our mission on containers, and our core project REX-Ray. This will give the audience an understanding of why REX-Ray is important and where you can go to learn more.
Fan-out, fan-in & the multiplexer: Replication recipes for global platform di...HostedbyConfluent
This session will dive into our most successful (and unsuccessful!) multi-cluster event replication patterns.
An x-ray of the cross cluster distribution model that powers our globally distributed APIs will touch on the benefits that this model has provided in terms of client API experience, delivery agility and developer experience.
We will focus on recipes for effective use of Mirror Maker event replication to power platform distribution including the challenges of managing a 'fan in' event replication workflow - pulling events created in satellite clusters back to a mothership cluster for processing.
We will introduce the elegant technique of replication event multiplexing - which can be used to simplify the burden of managing a 'fan-in' replication topology by eliminating regional awareness from the application domain and improving replication health monitoring & observability.
Business and IT agility through DevOps and microservice architecture powered ...Lucas Jellema
IT needs to run in production in order to generate business value. DevOps is among other things a way of thinking focusing on production software. A business application requires a tailor made platform to generate business value. The combination of application and its platform is a DevOps product. The DevOps team has full responsibility for that product through its entire lifecycle.
The microservices architecture promises flexibility, scalability, and optimal use of compute resources. Via independent components with well-defined scope and responsibility, interface, and ownership that are evolved and managed in an automated DevOps process, this architecture leverages current technologies and hard-learned insights from past decades.
This session defines the objectives of Business with IT, of microservices and DevOps and introduces Containers and the container platform Kubernetes as crucial ingredients for making DevOps happen.
In this presentation, we show how Data Reply helped an Austrian fintech customer to overcome previous performance limitations in their data analytics landscape, leverage real-time pipelines, break down monoliths, and foster a self-service data culture to enable new event-driven and business-critical use cases.
{code} and Containers - Open Source Infrastructure within Dell TechnologiesThe {code} Team
Learn how The {code} Team is building new infrastructure possibilities for persistent storage in all the major container ecosystems such as Kubernetes, Docker, and Mesos with native integrations and contributing the Container Storage Interface
The introduction covers the following
1. What are Microservices and why should be use this paradigm?
2. 12 factor apps and how Microservices make it easier to create them
3. Characteristics of Microservices
Note: Please download the slides to view animations.
Developing Enterprise Applications for the Cloud,from Monolith to MicroservicesDavid Currie
Presented at IBM InterConnect 2105. Is your next enterprise application ready for the cloud? Do you know how to build the kind of low-latency, highly available, highly scalable, omni-channel, micro-service modern-day application that customers expect? This introductory presentation will cover what it takes to build such an application using the multiple language runtimes and composing services offered on IBM Bluemix cloud.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Application Centric Microservices from Redhat Summit 2015Ken Owens
When Cisco started envisioning the future of its application development platforms, the ability to create applications that are cloud-native with elastic services, network-aware application policies, and micro-services was strategic to the company. When the decision to build and operate a Cisco cloud service delivery platform for collaboration, video, and Internet of Things (IoT) application development was made, OpenStack and micro-services became central to our application architectures and strategic to our vision as a company. This presentation will look at the journey Cisco developers took to transform to an application-centric OpenStack platform for application development in a secure, network-centric, and completely open source manner. The importance of the platform being Red Hat Enterprise Linux OpenStack Platform and using OpenShift by Red Hat and the contribution to the community will be described. The micro-services architecture and service-oriented DevOps lessons learned for enabling massive scalable and continuous delivery of software will be presented and demoed.
Speaker:
Owen Garrett
Sr. Director, Product Management
NGINX, Inc.
On-Deman Link: https://www.nginx.com/resources/webinars/need-service-mesh/
About the webinar:
Service mesh is one of the hottest emerging technologies. Even though it’s a nascent technology, many vendors have already released their implementation. But do you really need a service mesh?
Attend this webinar to learn about the levels of maturity on the journey to modernizing your apps using microservices, and the traffic management approaches best suited to each level. We’ll help you figure out if you really need a service mesh.
A Story of Cultural Change: PayPal's 2 Year Journey to 150,000 Containers wit...Docker, Inc.
Adopting containers at scale is fundamentally a cultural change. In late 2015, PayPal decided to migrate en masse to containers for applications built on many different frameworks over the last 15 years. It was a bold and strategic plan that included how to showcase value of containers to leadership, a phased execution strategy, building the right team to lead, and cultural transformation. Changing application code, deployment methods, and operational tools were at onset non-negotiable. This session will share how the plan was pitched and the learnings that unfolded as PayPal carefully changed everything - and nothing at the same time - to get to 150,000 containers running in production in 2 years.
This is a must-read for all engineers interested in developing a Micro services architecture. Turn your monolithic server into a prolific and multiple instance solution! Includes well-known example such as Netflix. Please contact me for more details.
Migrating to Microservices Patterns and Technologies (edition 2023)Ahmed Misbah
This session is targeted towards teams and organizations considering to migrate their applications from Monolithic to Microservice architecture. Migrating application architectures to Microservices is considered a key area of transformation in the IT world. Modernizing legacy applications to Kubernetes-based Microservices can prove to be very challenging if not planned correctly, taking into consideration the right technologies and enablers.
The session proposes Istio as an enabler for migrating to Microservices. Istio is an implementation of service mesh, a technology useful for migrating to Microservices iteratively and safely. We explain how Istio can be used as a bridge and enabler for modernizing legacy Monolithic applications to Microservices.
Move fast and make things with microservicesMithun Arunan
1. How to apply microservices patterns & anti-patterns to design the right architecture
2. Why & how to build a core framework to ensure consistency & manage complexity
3. What are the challenges in adopting gRPC for inter-service communication
4. How to orchestrate & manage microservices at scale with Kubernetes
5. How to leverage Cloud Native ecosystem to move fast & avoid vendor lock-in
An introduction to {code} by Dell EMC, our mission on containers, and our core project REX-Ray. This will give the audience an understanding of why REX-Ray is important and where you can go to learn more.
Fan-out, fan-in & the multiplexer: Replication recipes for global platform di...HostedbyConfluent
This session will dive into our most successful (and unsuccessful!) multi-cluster event replication patterns.
An x-ray of the cross cluster distribution model that powers our globally distributed APIs will touch on the benefits that this model has provided in terms of client API experience, delivery agility and developer experience.
We will focus on recipes for effective use of Mirror Maker event replication to power platform distribution including the challenges of managing a 'fan in' event replication workflow - pulling events created in satellite clusters back to a mothership cluster for processing.
We will introduce the elegant technique of replication event multiplexing - which can be used to simplify the burden of managing a 'fan-in' replication topology by eliminating regional awareness from the application domain and improving replication health monitoring & observability.
Business and IT agility through DevOps and microservice architecture powered ...Lucas Jellema
IT needs to run in production in order to generate business value. DevOps is among other things a way of thinking focusing on production software. A business application requires a tailor made platform to generate business value. The combination of application and its platform is a DevOps product. The DevOps team has full responsibility for that product through its entire lifecycle.
The microservices architecture promises flexibility, scalability, and optimal use of compute resources. Via independent components with well-defined scope and responsibility, interface, and ownership that are evolved and managed in an automated DevOps process, this architecture leverages current technologies and hard-learned insights from past decades.
This session defines the objectives of Business with IT, of microservices and DevOps and introduces Containers and the container platform Kubernetes as crucial ingredients for making DevOps happen.
In this presentation, we show how Data Reply helped an Austrian fintech customer to overcome previous performance limitations in their data analytics landscape, leverage real-time pipelines, break down monoliths, and foster a self-service data culture to enable new event-driven and business-critical use cases.
{code} and Containers - Open Source Infrastructure within Dell TechnologiesThe {code} Team
Learn how The {code} Team is building new infrastructure possibilities for persistent storage in all the major container ecosystems such as Kubernetes, Docker, and Mesos with native integrations and contributing the Container Storage Interface
The introduction covers the following
1. What are Microservices and why should be use this paradigm?
2. 12 factor apps and how Microservices make it easier to create them
3. Characteristics of Microservices
Note: Please download the slides to view animations.
Developing Enterprise Applications for the Cloud,from Monolith to MicroservicesDavid Currie
Presented at IBM InterConnect 2105. Is your next enterprise application ready for the cloud? Do you know how to build the kind of low-latency, highly available, highly scalable, omni-channel, micro-service modern-day application that customers expect? This introductory presentation will cover what it takes to build such an application using the multiple language runtimes and composing services offered on IBM Bluemix cloud.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Neuro-symbolic is not enough, we need neuro-*semantic*
Microservices.pdf
1. Andrei Shakirin, VMware Tanzu Labs
Splitting Monolith Application to Microservices:
gains and challenges
2. Agenda
• Monolith vs Microservices architecture
• Introduction into eCommerce use case
• Overview of monolith architecture
• What were good with monolith?
• What were the pain points in monolith?
• Iterative way to microservices world
• Challenges in microservice architecture and possible
solutions
• Conclusions and recommendations
3. About Me
• Senior Engineer by VMWare Tanzu
• PMC in Apache CXF
• Contributions in Apache Syncope,
Apache Aries and Apache Karaf
• Speaker in technological and
methodological conferences
4. 4
Monolith vs Microservices Architecture Styles
Monolith Microservices
System design Build as single system Build as set of independent subsystems based
on business subdomain (binding context)
Codebase Normally single code repository Multiple code repositories per subsystem
(microservice)
Deployment Whole system deployed as
single deployment unit
Subsystems are deployed independently
Datastore Normally single shared
datastore
Every subsystem owns it’s database
Communication Local inside the application
modules
Remote sync or async communication between
subsystems
Technology Build on single homogenues
technology
Can use different technolgies in subsystems
5. E-Commerce Project Setup for Monolith
• Backend for E-Commerce system (provide Rest APIs and functionality
to manage users, carts, checkouts, products, orders, fulfilments)
• 3 Teams, each about 7-8 persons
• Technologies: Java, OSGi, Hibernate, PostgreSQL, Apache Karaf,
ActiveMQ, Apache CXF
• Methodology: scrum
6. eCommerce Platform Architecture
Middleware
Web Browser
Frontend
PostgreSQL
Mobile App
Credit-Worthiness
Check System
Active
MQ
SAP
Online Finance
System
External consumers
REST API
Mongo DB
7. Core Middleware Design
Customer Domain Article Domain Order Domain
Core User Service Core Cart Service Core Article Service Core Order Service
SAP
Messaging
REST REST REST REST
Core Domain
DAOs
DB DB DB
OSGi Container (Karaf)
SAP Connector JMS Connector
8. What is Good With Monolith?
• Quick start and first achievement
• Homogenous approaches to design APIs, GUIs, architecture
• Simple build and deployment pipelines
• Easy communicate between system components (Java Interfaces)
• Easy monitoring
• Teams have single development and deployment guideline (not
always optimal)
• Less complexity in administration by DevOps
9. What Hurts the Teams with Monolith?
Issue Description Prio
Keeping up to date Upgrade of JDK or third parties is possible only for all
services and all teams: all or nothing
high
Resilience l Services share a common HTTP thread pool
l DB connections share DB connection pool
high
Shared deployment One vertical team can easily break the environment shared
by three other teams
high
Development cycle Long development cycle: implement → deploy → test high
Innovations New technologies applied by one team as third party
dependencies can affect other teams
medium
Scalability All services and components can be scaled only together medium
Learning curve New developers have long learning curve, often are scared
to refactor the system, because of complex interrelations
medium
10. Step 0: Decouple consumers using Gateway
Gateway
Old Service1
inside Monolith
New
Microservice1
Container
Consumer 1 Consumer 2 Consumer 3
Routing / Canary release
90% 10%
Old Service2
inside Monolith
Old Service3
inside Monolith
11. Step 1: Extract Services with Minimum Dependencies on Monolith
Gateway
Old Service2
inside Monolith
Address
Microservice
Monolith container
Consumer 1 Consumer 2 Consumer 3
Routing / Canary release
90% 10%
Old Service1
inside Monolith
Old Service3
inside Monolith
• Minimum dependendencies
from rest monolit
• Independent data store
• Low complexity
12. Step 2: Extract Services with High Availability Requirements
Gateway
Old Service2
inside Monolith
Price&Availability
Microservice
Monolith container
Consumer 1 Consumer 2 Consumer 3
Routing / Canary release
90% 10%
Old Service1
inside Monolith
Old Service3
inside Mnolith
• Request load is essentially
higher (or lower) as rest
monolith components
13. Step 3: Split Code Base due domain duplication
User Customer
Domain
Checkout
Article Domain
Order Domain
User Service Cart Service Checkout Service Order Service
SAP
Messaging
REST REST REST REST
User Core
Domain
DAOs
DB
OSGi Container (Karaf)
Cart Customer
Domain
Cart Core
Domain
Core Order
Domain
Cart Article
Domain
Checkout Core
Domain
Core
framework as
thridparty
14. Step 4: Extract core services with shared Database and Connectors
Docker
Order Service
REST
R
E
S
T
Docker
Checkout
Service
REST
R
E
S
T
Docker
Cart Service
REST
R
E
S
T
DB
Docker
User Service
REST
R
E
S
T
SAP
Messaging
DB
15. Step 5: Decentralize Data Management
Docker
Order Service
REST
R
E
S
T
Docker
Checkout
Service
REST
R
E
S
T
Docker
Cart Service
REST
R
E
S
T
Docker
User Service
REST
R
E
S
T
SAP
Messaging
DB
DB
DB DB
16. K8S Cluster
Target View
PODs
Order Service
REST
R
E
S
T
PODs
Checkout
Service
REST
R
E
S
T
PODs
User Service
REST
R
E
S
T
PODs
Cart Service
REST
R
E
S
T
DB
DB
DB
DB
Messaging
17. Microservice Architecture Challenges
Technical
l CI/CD pipelines
l Monitoring solution
l Central logs with elastic search functionality
l Messages Tracing and debugging
Organizational
l Teams use heterogeneous style in APIs, GUIs, architecture
l Features required changes in multiple services
l Release cycles and central QA
l Mistakes in subdomains split and teams responsibilities
20. K8S Cluster
3. Logging Solution
PODs
Order Service
REST
R
E
S
T
PODs
Checkout
Service
REST
R
E
S
T
PODs
User Service
REST
R
E
S
T
PODs
Cart Service
REST
R
E
S
T
L
o
g
s
Fluentbit parser Fluentbit parser Fluentbit parser Fluentbit parser
Graylog server
24. Organizational Challenges
Issue Solution
Heterogenous design style: APIs,
GUIs, architecture
Explain best practices, show success stories, organize
common workshops, but avoid to force and press teams
decisions
Features span multiple services Well defined contracts between microservices. Compatible
changes, especially in APIs
Communication between teams
If too match dependencies → rethink splitting of
microservices
Release cycles and central QA Prolong teams responsibility to production deployment and
maintenance
25. Wrong Split of Subdomains
These mistakes can be very expensive, especially if organisation is not flexible
enough
Recommendations:
l Train on Monolith:
l Isolate subdomains in packages
l Decouple through the interfaces and dependency injection
l Use consistent names for contexts across application
l Move and split classes around until boundaries are clear
l Use pair reviews to ensure the architecture design
l Clearly communicate with managers and/or business to plan time for split
l Constantly review the boundaries and update them by project evolving
26. Conclusions
l There is not single silver bullet architecture: the right choice depends on your
requirements, business domain and development perspective
l Often starting from monolith is faster and pragmatic
l Split monolith to microservices only because of good reasons
l Prefer iterative splitting process to Big Bang, use Strangler and Gateway
patterns
l Start splitting from more simple and critical services
l Be aware of technical and organisational challenges after the split and provide
solutions (CI/CD, logging, tracing, monitoring, async communication)
l Mistakes in microservices boundaries definition are expensive: train on
monolith and check and rethink the boundaries by system evolving
34. Questions to Tanzu Labs
• Are the Pivotal principles like TDD & Pair Programming still applied by
the customer engagements?
• Are there any principle structural changes on Pivotal after acqusition?
• Are most of engagements related to CloudFoundry product?
• Describe typical phases of engagement
• Do the customers use Quarkus Graal VM / Micronaut as alternative to
SpringBoot?
• Which Cloud Providers customers typicaly used: Amazon, Azure, GCP?
• VMware: internal conferences, presentation, team events?