The document discusses the benefits of using a microservices architecture, including improved ability to adapt to changes quickly through reduced coupling between services, and outlines key considerations for how to structure microservices including ensuring each service owns its own data and communicating between services asynchronously using events rather than synchronous requests.
Autonomous microservices for a Financial SystemINPAY
There are many articles about microservices, but few cover how to apply Microservice principles to non-trivial domains. In this presentation, Jeppe will show how INPAY design highly autonomous microservices and composite applications. We will get into the underlying principles, such as how to discover service boundaries, how to communicate between services, what role does the UI play. Finally we will look at how services are implemented and supported by the infrastructure.
Keywords: DDD, Microservices, CQRS, Event Sourcing, Event Driven Architecture, Federated Bus, Composite UI
Join SOA thought leader and Microservices Expo editor Jason Bloomberg for an insightful look into the nature of microservices architecture. For it to be SOA -- let alone SOA done right -- we need to pin down just what "SOA done wrong" might be. First-generation SOA with Web Services and ESBs, perhaps?
But then there's second-generation, REST-based SOA. More lightweight and cloud-friendly, but many REST-based SOA practices predate the microservices wave.
Today, microservices and containers go hand in hand -- only the details of "container-oriented architecture" are largely on the drawing board -- and are not likely to look much like SOA in any case.
An ode to the underrepresented and underused pattern of events and asynchrony in the design and development of Microservices.
Prepared by Saul Caganoff, and delivered by Saul at Melbourne Microservices, and by Yamen Sader at Sydney Microservices.
In this talk, I address two topics.
The first topic is the "one size fits all" dogma that we see quite often in IT. I try to explain, why we do it but also what the pitfalls are and how oversimplified solution spaces lead to the same kind of accidental complexity when trying to solve a given business problem as overly complex solution spaces.
The second and core topic is the influence that a communication paradigm you use has on your functional design. Based on the observation that synchronous request/response in all its flavors is the usually used "one size fits all" communication paradigm, I use a real-life example to demonstrate how two different communication paradigms (synchronous request/response and asynchronous event-based communication) can lead to very different functional service designs - and that synchronous request/response not necessarily leads to the more appropriate functional design.
The bottom line of the talk is that you should not give up your design options prematurely in order to be able to find the best problem-solution fit and that the choice of the communication paradigm is a more important options than most people usually think it is.
As always the voice track is missing and therefore quite a bit of the information (or probably most of the information) contained in the talk. But hopefully the slides still give you some useful pointers.
Autonomous microservices for a Financial SystemINPAY
There are many articles about microservices, but few cover how to apply Microservice principles to non-trivial domains. In this presentation, Jeppe will show how INPAY design highly autonomous microservices and composite applications. We will get into the underlying principles, such as how to discover service boundaries, how to communicate between services, what role does the UI play. Finally we will look at how services are implemented and supported by the infrastructure.
Keywords: DDD, Microservices, CQRS, Event Sourcing, Event Driven Architecture, Federated Bus, Composite UI
Join SOA thought leader and Microservices Expo editor Jason Bloomberg for an insightful look into the nature of microservices architecture. For it to be SOA -- let alone SOA done right -- we need to pin down just what "SOA done wrong" might be. First-generation SOA with Web Services and ESBs, perhaps?
But then there's second-generation, REST-based SOA. More lightweight and cloud-friendly, but many REST-based SOA practices predate the microservices wave.
Today, microservices and containers go hand in hand -- only the details of "container-oriented architecture" are largely on the drawing board -- and are not likely to look much like SOA in any case.
An ode to the underrepresented and underused pattern of events and asynchrony in the design and development of Microservices.
Prepared by Saul Caganoff, and delivered by Saul at Melbourne Microservices, and by Yamen Sader at Sydney Microservices.
In this talk, I address two topics.
The first topic is the "one size fits all" dogma that we see quite often in IT. I try to explain, why we do it but also what the pitfalls are and how oversimplified solution spaces lead to the same kind of accidental complexity when trying to solve a given business problem as overly complex solution spaces.
The second and core topic is the influence that a communication paradigm you use has on your functional design. Based on the observation that synchronous request/response in all its flavors is the usually used "one size fits all" communication paradigm, I use a real-life example to demonstrate how two different communication paradigms (synchronous request/response and asynchronous event-based communication) can lead to very different functional service designs - and that synchronous request/response not necessarily leads to the more appropriate functional design.
The bottom line of the talk is that you should not give up your design options prematurely in order to be able to find the best problem-solution fit and that the choice of the communication paradigm is a more important options than most people usually think it is.
As always the voice track is missing and therefore quite a bit of the information (or probably most of the information) contained in the talk. But hopefully the slides still give you some useful pointers.
This slide deck basically tries to address functional service design not only from a maintainability point of view, but also form an operational point of view. How to spread your business functionality across your service landscape to maximize availability and responsiveness?
It starts with the observation that virtually all system landscapes these days, including cloud-native, are distributed systems. Due to the failure modes of distributed systems every remote communication basically is a predetermined breaking point of your system.
After briefly discussing other options to increase availability and responsiveness the biggest part of the deck discusses the question how a good functional design can positively influence the aforementioned system properties.
Using a very simple eCommerce application as an example, first a typical design is shown and why it is suboptimal in terms of availability and responsiveness. After that, we briefly dive into classical CS papers and see what we can learn from them. We also learn that while the core insights of those papers are mostly timeless, their implementation instructions are not and that we need to update them to our current context.
Then we use the learnt ideas to derive a different functional decomposition approach starting with the system behavior and apply it to our example - which leads to a lot better system behavior in terms of availability and responsiveness. Finally we discuss the most important trade-offs of the different design approach - as every design decision of course also has its downsides ... ;)
As always, the voice track is missing (but afaik there will be a recording released from KanDDDinsky 2018). Still, I hope the slides on their own also offer you a few valuable ideas.
In this presentation, I will explain event driven architecture, describe the different types of events, demonstrate how events can be related and orchestrated, and provide a basic understanding of how this method can drive the architecture of enterprise systems. In addition to understanding the concepts of event driven architecture, we will explore a working sample built using an open-source .NET messaging framework called MassTransit.
We have identified issues related to composition of a business process and discussed the requirements for event-driven composition and event-driven service-oriented architecture.
Why should SOA be adopted?
For successful adoption what all are required?
Maximum benefits can be obtained only with executive level support, proper training and implementing process discipline.
SOA is essential for service bureau industry. Prime brokers, fund administrators in the financial services are prime candidates, where customization, integration and speedy problem resolution are critical. SOA takes commitment, time and patience.
There are many design patterns for building microservices, and most of them are wrong. Actually, that is not true. The fundamental objectives for implementing microservice systems are speed and agility. Speed, of course, is how quickly you can get things done. Regardless of what design patterns you use, if you can quickly build, fix, enhance, and rapidly evolve your microservices, you are heading in the right direction. Agility is the flexibility to move rapidly across the entire development lifecycle while living happily in production.
But we can always do better. Right?
That is what this talk is about. We will take a look at some of the more common microservice design patterns. And we will compare them to some of the alternatives. For example, what is the more common microlith design pattern, and how getting serious about loose coupling guides the evolution to ways that increase your speed and agility? We will also look at why it is micro at the code level and the data level. Finally, we will cover some practical guidelines, such as why your microservices should do the least amount of work while your users are waiting and techniques for doing that.
JUG Frankfurt - Orchestration of microservicesBernd Ruecker
Slides from my talk held at JUG Frankfurt on 27th of September 2017 about microservice orchestration. Source code for the live hacking is here: https://github.com/flowing/flowing-retail
November 2017: Collaboration of (micro-)servicesBernd Ruecker
Slides from a talk held at WJAX Munic on 9th of November (and some other meetups later in November) about how to tackle collaboration of microservices.
Most of the talk was live coding, the respective code is here: https://github.com/flowing/flowing-retail.
This presentation, given on the Software Architecture course at the University of Brunel, discusses the interplay between architecture and design. How the designer and architect are really different roles and ones that often have competing goals.
Saturn 2018: Managing data consistency in a microservice architecture using S...Chris Richardson
A revised and extended version that I gave at Saturn 2018.
The services in a microservice architecture must be loosely coupled and so cannot share database tables. What’s more, two phase commit (a.k.a. a distributed transaction) is not a viable option for modern applications. Consequently, a microservices application must use the Saga pattern, which maintains data consistency using a series of local transactions.
In this presentation, you will learn how sagas work and how they differ from traditional transactions. We describe how to use sagas to develop business logic in a microservices application. You will learn effective techniques for orchestrating sagas and how to use messaging for reliability. We will describe the design of a saga framework for Java and show a sample application.
Yura Nikonovich is the first to set up a tradition with his research “CAP theorem and distributed systems”.
In the first part of the report, find his insights into what distributed systems are and what challenges he faced in the course of his work with them.
In the second part of the report Yura tells us about CAP theorem, it's varieties and the future of distributed databases.
Microservices for Mortals by Bert Ertman at Codemotion DubaiCodemotion Dubai
With popular poster children such as Netflix and Amazon, Microservices based architecture seems to be the killer approach to 21st century architectures. But are they only for Hollywood Coders pioneering on the bleeding edge of our profession? Or are they ready to be used for your projects and your customers? I will go over the benefits, but more so the pitfalls, of using a Microservices based architecture. What impact does it have on your organization, your applications, on dealing with scale and failures, and how do you prevent your landscape from becoming an unmaintainable nightmare.
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Servicesallingeek
Presented in Pittsburgh, PA for Abstractions.io in August, 2016. "The greater your adoption success, the greater your retirement pain." The number of APIs has exploded and will continue growing as more teams adopt microservices. In my time at Amazon my team of eight owned hundreds of microservices, covering every possible life cycle phase. Two of our services were more than a decade old. These lingered despite several interface iterations launched to cover alternative use-cases, multiple ownership changes, and funded retirement initiatives. The reason was simple: hundreds of internal and external clients had a dependency on these services. A coordinated migration effort was nearly impossible to prioritize across the whole of Amazon and integrated third-party merchant software. To make matters worse, many of our clients were as old as the services themselves. Several were owned by teams that had long since forgotten about them. We were all victims of these successful services. As I took over as manager of the team I knew that failure to retire these services in the next year would be a critical blow to our system scalability in Q4. Failure was not an option. I was hellbent on hitting the power switch. Every service owner will eventually encounter this problem. Few want to talk about it. In this session I'll elaborate on the challenges facing service owners, my approach to solving them, the impact of our success, and the lessons learned. I'll share the highs and lows - smooth migrations, and the pain of scream test victims. It is my hope that an attendee will be able to learn from these experiences and succeed in their own retirement efforts.
MuCon 2015 - Microservices in Integration ArchitectureKim Clark
Discusses the how microservices fit into the ever evolving integration architecture, looking at how these concepts are often seen very differently through the eyes of enterprises with different lanscapes.
CPU and RAM costs continue to plummet. Multi-core systems are ubiquitous. Writing code is easier than it has ever been. Why, then, is it still so darn hard to make a scalable system?
This slide deck basically tries to address functional service design not only from a maintainability point of view, but also form an operational point of view. How to spread your business functionality across your service landscape to maximize availability and responsiveness?
It starts with the observation that virtually all system landscapes these days, including cloud-native, are distributed systems. Due to the failure modes of distributed systems every remote communication basically is a predetermined breaking point of your system.
After briefly discussing other options to increase availability and responsiveness the biggest part of the deck discusses the question how a good functional design can positively influence the aforementioned system properties.
Using a very simple eCommerce application as an example, first a typical design is shown and why it is suboptimal in terms of availability and responsiveness. After that, we briefly dive into classical CS papers and see what we can learn from them. We also learn that while the core insights of those papers are mostly timeless, their implementation instructions are not and that we need to update them to our current context.
Then we use the learnt ideas to derive a different functional decomposition approach starting with the system behavior and apply it to our example - which leads to a lot better system behavior in terms of availability and responsiveness. Finally we discuss the most important trade-offs of the different design approach - as every design decision of course also has its downsides ... ;)
As always, the voice track is missing (but afaik there will be a recording released from KanDDDinsky 2018). Still, I hope the slides on their own also offer you a few valuable ideas.
In this presentation, I will explain event driven architecture, describe the different types of events, demonstrate how events can be related and orchestrated, and provide a basic understanding of how this method can drive the architecture of enterprise systems. In addition to understanding the concepts of event driven architecture, we will explore a working sample built using an open-source .NET messaging framework called MassTransit.
We have identified issues related to composition of a business process and discussed the requirements for event-driven composition and event-driven service-oriented architecture.
Why should SOA be adopted?
For successful adoption what all are required?
Maximum benefits can be obtained only with executive level support, proper training and implementing process discipline.
SOA is essential for service bureau industry. Prime brokers, fund administrators in the financial services are prime candidates, where customization, integration and speedy problem resolution are critical. SOA takes commitment, time and patience.
There are many design patterns for building microservices, and most of them are wrong. Actually, that is not true. The fundamental objectives for implementing microservice systems are speed and agility. Speed, of course, is how quickly you can get things done. Regardless of what design patterns you use, if you can quickly build, fix, enhance, and rapidly evolve your microservices, you are heading in the right direction. Agility is the flexibility to move rapidly across the entire development lifecycle while living happily in production.
But we can always do better. Right?
That is what this talk is about. We will take a look at some of the more common microservice design patterns. And we will compare them to some of the alternatives. For example, what is the more common microlith design pattern, and how getting serious about loose coupling guides the evolution to ways that increase your speed and agility? We will also look at why it is micro at the code level and the data level. Finally, we will cover some practical guidelines, such as why your microservices should do the least amount of work while your users are waiting and techniques for doing that.
JUG Frankfurt - Orchestration of microservicesBernd Ruecker
Slides from my talk held at JUG Frankfurt on 27th of September 2017 about microservice orchestration. Source code for the live hacking is here: https://github.com/flowing/flowing-retail
November 2017: Collaboration of (micro-)servicesBernd Ruecker
Slides from a talk held at WJAX Munic on 9th of November (and some other meetups later in November) about how to tackle collaboration of microservices.
Most of the talk was live coding, the respective code is here: https://github.com/flowing/flowing-retail.
This presentation, given on the Software Architecture course at the University of Brunel, discusses the interplay between architecture and design. How the designer and architect are really different roles and ones that often have competing goals.
Saturn 2018: Managing data consistency in a microservice architecture using S...Chris Richardson
A revised and extended version that I gave at Saturn 2018.
The services in a microservice architecture must be loosely coupled and so cannot share database tables. What’s more, two phase commit (a.k.a. a distributed transaction) is not a viable option for modern applications. Consequently, a microservices application must use the Saga pattern, which maintains data consistency using a series of local transactions.
In this presentation, you will learn how sagas work and how they differ from traditional transactions. We describe how to use sagas to develop business logic in a microservices application. You will learn effective techniques for orchestrating sagas and how to use messaging for reliability. We will describe the design of a saga framework for Java and show a sample application.
Yura Nikonovich is the first to set up a tradition with his research “CAP theorem and distributed systems”.
In the first part of the report, find his insights into what distributed systems are and what challenges he faced in the course of his work with them.
In the second part of the report Yura tells us about CAP theorem, it's varieties and the future of distributed databases.
Microservices for Mortals by Bert Ertman at Codemotion DubaiCodemotion Dubai
With popular poster children such as Netflix and Amazon, Microservices based architecture seems to be the killer approach to 21st century architectures. But are they only for Hollywood Coders pioneering on the bleeding edge of our profession? Or are they ready to be used for your projects and your customers? I will go over the benefits, but more so the pitfalls, of using a Microservices based architecture. What impact does it have on your organization, your applications, on dealing with scale and failures, and how do you prevent your landscape from becoming an unmaintainable nightmare.
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Servicesallingeek
Presented in Pittsburgh, PA for Abstractions.io in August, 2016. "The greater your adoption success, the greater your retirement pain." The number of APIs has exploded and will continue growing as more teams adopt microservices. In my time at Amazon my team of eight owned hundreds of microservices, covering every possible life cycle phase. Two of our services were more than a decade old. These lingered despite several interface iterations launched to cover alternative use-cases, multiple ownership changes, and funded retirement initiatives. The reason was simple: hundreds of internal and external clients had a dependency on these services. A coordinated migration effort was nearly impossible to prioritize across the whole of Amazon and integrated third-party merchant software. To make matters worse, many of our clients were as old as the services themselves. Several were owned by teams that had long since forgotten about them. We were all victims of these successful services. As I took over as manager of the team I knew that failure to retire these services in the next year would be a critical blow to our system scalability in Q4. Failure was not an option. I was hellbent on hitting the power switch. Every service owner will eventually encounter this problem. Few want to talk about it. In this session I'll elaborate on the challenges facing service owners, my approach to solving them, the impact of our success, and the lessons learned. I'll share the highs and lows - smooth migrations, and the pain of scream test victims. It is my hope that an attendee will be able to learn from these experiences and succeed in their own retirement efforts.
MuCon 2015 - Microservices in Integration ArchitectureKim Clark
Discusses the how microservices fit into the ever evolving integration architecture, looking at how these concepts are often seen very differently through the eyes of enterprises with different lanscapes.
CPU and RAM costs continue to plummet. Multi-core systems are ubiquitous. Writing code is easier than it has ever been. Why, then, is it still so darn hard to make a scalable system?
“ The Microservices architecture has many appealing qualities, but the road towards it has painful traps for the unwary. This book will help you figure out if this path is for you, and how to avoid those traps on your journey.”
—Martin Fowler Chief Scientist, ThoughtWorks
Pitfalls & Challenges Faced During a Microservices Architecture ImplementationCognizant
Microservices are the de facto design approach for building digital applications. However, issues highlighted in this paper can and do lead to implementation challenges and even failures. Here are a few strategies to avoid and overcome them.
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv...Chris Richardson
YOW! Perth 2019 presentation
The microservice architecture is becoming increasing important. But what is it exactly? Why should you care about microservices? And, what do you need to do to ensure that your organization uses the microservice architecture successfully? In this talk, I’ll answer these and other questions using shapes as visual metaphors. You will learn about the motivations for the microservice architecture and why simply adopting microservices is insufficient. I describe essential characteristics of microservices, You will learn how a successful microservice architecture consist of loosely coupled services with stable APIs that communicate asynchronous. I will cover strategies for effectively testing microservices.
(BDT312) Using the Cloud to Scale from a Database to a Data Platform | AWS re...Amazon Web Services
Scaling highly available database infrastructure to 100x, 1000x, and beyond has historically been one of the hardest technical challenges that any successful web business must face. This is quickly changing with fully-managed database services such as Amazon DynamoDB and Amazon Redshift, as the scaling efforts which previously required herculean effort are now as simple as an API call.
Over the last few years, Twilio has evolved their database infrastructure to a pipeline consisting of Amazon SQS, Sharded MySQL, Amazon DynamoDB, Amazon S3, Amazon EMR and Amazon Redshift. In this session, Twilio cover show they achieved success, specifically:
- How they replaced their data pipeline deployed to Amazon EC2 to meet their scaling needs with zero downtime.
- How they adopted Amazon DynamoDB and Amazon Redshift at the same scale as their MySQL infrastructure, at 1/5th the cost and operational overhead.
- Why they believe adopting managed database services like Amazon DynamoDB is key to accelerating delivery of value to their customers.
Sponsored by Twilio.
The Reality of Managing Microservices in Your CD PipelineDevOps.com
As we shift from monolithic software development practices to microservices, our well-designed CD pipeline will need to change. Microservices are small functions, deployed independently and linked via APIs at run-time. While these differences seem minor, they actually have a large impact on your overall CD structure. Think hundreds of workflows, small of any builds and the loss of a monolithic 'application.'
Join Tracy Ragan, CEO of DeployHub and Brendan O'Leary, Developer Evangelist at GitLab, to learn more.
It's never too early to start the conversation.
Cloud Native is more than a set of tools. It is a full architecture, a philosophical approach for building applications that take full advantage of cloud computing and a organisational change. Going Cloud Native requires an organisation to shift not only its tech stack but also its culture, processes and team setup. In this talk I'll dive into possible operating models for Cloud Native Systems.
How Cloud Changes Business Expectationstimhill2000
Peter Sharples, CA Technologies discusses the evolution of the role of the CIO and how the Cloud is changing business expectations put on them - in his words 'Adapt or Die'
JFokus: Cubes, Hexagons, Triangles, and More: Understanding MicroservicesChris Richardson
The microservice architecture is becoming increasing important. But what is it exactly? Why should you care about microservices? And, what do you need to do to ensure that your organization uses the microservice architecture successfully? In this talk, I’ll answer these and other questions using shapes as visual metaphors. You will learn about the motivations for the microservice architecture and why simply adopting microservices is insufficient. I describe essential characteristics of microservices, You will learn how a successful microservice architecture consist of loosely coupled services with stable APIs that communicate asynchronous. I will cover strategies for effectively testing microservices.
Edge 2014: Maintaining the Balance: Getting the Most of Your CDN with IKEAAkamai Technologies
Maintaining the Balance: Getting the Most of Your CDN by Johannes Eckerdal, Product Specialist, IKEA
Join Johannes Eckerdal, CDN Product Specialist of Ikea for an informative supersession where he will discuss how to transform your Content Delivery Network into an Experience Delivery Network and other topics including: Why the Edge matters, Considerations around CDN agnostic versus CDN dependent approaches, How to extract the most of your CDN
Akamai Edge is the premier event for Internet innovators, tech professionals and online business pioneers who together are forging a Faster Forward World. At Edge, the architects, experts and implementers of the most innovative global online businesses gather face-to-face for an invaluable three days of sharing, learning and together pushing the limits of the Faster Forward World. Learn more at: http://www.akamai.com/edge
Similar to The "Why", "What" & "How" of Microservices - short version (20)
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
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.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
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.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
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
13. Coupling causes ripple effect –
much like circles in the water
• You want to change a little thing and all of a sudden you need to change 25
other seemingly unrelated things
• Zero coupling is impossible
• Question is what is the right level of coupling?
• This highly depends on how likely the component/system/service is to change and what
parts that change together
18. MICROSERVICES TELL US TO MAKE
THINGS SMALLER
Adhering to the Single Responsibility Principle (SRP) –
“A Microservice should have one reason – and only one reason – to change”
19. THERE IS VALUE IN MAKING
THINGS SMALLER
For one thing it is easier to reason about them in isolation
It’s easier to replace them – since coupling is explicit
25. Nano Services
Unless we have a very good reason for doing so,
we risk building services
that are so fine-grained
that their costs outweigh their utility*
*Read Arnon Rotem-Gal-Oz’s Nano Services Anti Pattern:http://arnon.me/wp-content/uploads/2010/10/Nanoservices.pdf
26. IS YOUR MICROSERVICE
VALUABLE?
The value of a microservice must
exceed the cost of building &
operating it.
Microservices entail costs for serializations, deserializations,
security, communication, maintenance, configuration,
deployment, monitoring, etc.
27. Let’s transform our monolith to microservices
“The” DB
UI
Logic
Microservices
Data Access
Microservices
UI-3
MS-3
MS-C
UI-2
MS-D
UI-4
MS-4MS-2
MS-B MS-E
UI-1 UI-5
MS-5MS-1
MS-A
28. BEWARE…
When we break up big things into small
pieces we invariably push the complexity to
their interaction.
Michael Feathers
https://michaelfeathers.silvrback.com/microservices-until-macro-complexity
29. Let’s zoom in on the data tier
MS-A
“The” DB
MS-C
MS-D
MS-B
MS-E
30. IF OUR MONOLITHS CODE IS COUPLED AND MESSY
Chances are that the data(base) model is equally coupled
and messy
39. SOA PRINCIPLE
SERVICES ARE AUTONOMOUS
Autonomy means that our service is independent and self-
contained and as far as possible doesn’t directly depend on
other services to be functional.
45. Let’s refactor the data tier
MS-C
MS-D
MS-B
MS-E
MS-A A’s
DB
B’s
DB
C’s
DB
D’s
DB
E’s
DB
UI
Logic
Microservices
Data Access
Microservices
UI-3
MS-3
MS-C
UI-2
MS-D
UI-4
MS-4MS-2
MS-B MS-E
UI-1 UI-5
MS-5MS-1
MS-A
A’s
DB
B’s
DB
C’s
DB
D’s
DB
E’s
DB
47. Things that are not Services
• A Service with only functionality (and no data) is a FUNCTION
• Like: check if order is valid
• A Service that only has data is a DATABASE
• Like: Entity CRUD
• A database already has a nice API - we don’t need to bubble wrap it with REST or Asynchronous messages
• Don’t split the atom – we need cohesion as well as decoupling!
• If we want datastore abstraction (so we can swap out Postgresql with Mongo or Redis) there this little
pattern called Respository.
This is typically seen in a lot of layered SOA usages where a function calls a
function that calls a function that calls a database
48. Let’s refactor the “microservices”
UI
Microservices
UI-3
MS-3
UI-2 UI-4
MS-4MS-2
UI-1 UI-5
MS-5MS-1
1’s
DB
2’s
DB
3’s
DB
4’s
DB
5’s
DB
53. Synchronous calls lower our tolerance for faults
• When you get an IO error
• When servers crash or restarts
• When databases are down
• When deadlocks occurs in our databases
• Do you retry?
With synchronous style Service interaction we can loose business data, there’s no automatic retry or we risk creating
data more than once because idempotence* often is an after though
53
Client Server
Duplicated
Response
Duplicated Request
Processing
Response
Request Processing
The same message can be
processed more than once
*Idempotence describes the quality of an
operation in which result and state does not
change if the operation is performed more
than 1 time
55. WITH CROSS SERVICE INTEGRATION
WE’RE BOUND BY THE LAWS OF
DISTRIBUTED COMPUTING
56. The 8 Fallacies of Distributed Computing
These fallacies are assumptions architects, designers and developers of
distributed systems are likely to make. The fallacies will be proven
wrong in the long run - resulting in all sorts of troubles and pains for
the solution and architects who made the assumptions.
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the fallacies and why they’re fallacies
57. A DISTRIBUTED SYSTEM IS ONE
WHERE A MACHINE I’VE NEVER
HEARD OF CAN CAUSE MY PROGRAM
TO FAIL.
— Leslie Lamport
58. Essential complexity of 2 way integration
Component
C
Component
B
Component
A
UI
Service Service
B:Service()
call C:Service()
call A:Service()
commit()
Service
Local transaction
between System A, B
and C
59. B:Service()
call C:Service()
call A:Service()
if (A:Call-Failed:Too-Busy?)
Wait-A-While()
call A:Service()
if (A:Call-Failed:Too-Busy?)
Wait-A-Little-While-Longer()
call A:Service()
if (A:Call-Failed:IO-Error?)
Save-We-Need-Check-If-Call-A-Succeded-After-All
AND We-Need-To-Retry call C:Service and call B:Service
AND Tell-Customer-That-This-Operation-Perhaps-Went-Well
if (A:Call-Went-Well?)
commit()
Accidental complexity from distributed service integration
Component
C
Component
B
System A
UI
Service Service Service
Local transaction
between System B and
C
60. Consequence: Availability goes down
(without additional instances of each service)
Service
A
Service
B
Service
C
Availability: 99% Availability: 99% Availability: 99%
Combined availability: 97%
61. DECIDE IF YOU CAN LIVE WITH THE
CONSEQUENCES OF COUPLING
SERVICES TO EACH OTHER USING
REQUEST/RESPONSE
Different situations – different tradeoffs
62. HOW CAN WE BUILD SERVICES THAT
DON’T EXPERIENCE THESE
PROBLEMS?
63. GUIDANCE CAN BE FOUND IN
Pat Hellands
“Life Beyond Distributed Transactions? An Apostate ‘s Opinion”
Link: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
64. Life Beyond Distributed Transactions?
According to Pat Helland, we must find the solution to our problem by looking
at:
1. How do we split our data / services
2. How do we identify our data
3. How do we communicate between our services
65. 1. How do we split our data / services
Data must be collected in pieces called aggregates. These aggregates should
be limited in size (but not smaller), so that, after a transaction they are
consistent.
Rule of thumb:
One transaction involves only one aggregate.
67. Aggregates
Invoice
InvoiceLine
*
Account *
What:
• Cluster coherent Entities and Value Objects,
with complex associations into Aggregates
with well defined boundaries.
• Choose one entity to be root and control
access to objects inside the boundary
through the root.
Motivation:
Control invariants and consistency through the aggregate root.
Enables: Loading schemes, coarse grained locking and…
Ensuring consistency & transactional boundaries for Distributed
scenarios
Root
*
*
72. 2. How do we identify our data
According to Pat Helland we need to be able to uniquely identify each
Aggregate using an ID.
• This ID will usually a UUID/GUID
• Aggregates refer to each other by their ID
• they NEVER use memory pointers, join tables or remote calls
{21EC2020-3AEA-4069-A2DD-08002B30309D}
2122 (approximately 5.3×1036) combinations
74. 3. How we communicate between our services
• What do we do when our use case involves more than one aggregate and
therefore likely more than one service?
75. Synchronous calls are the crystal meth of programming
At first you make good progress but then the sheer horror
becomes evident when you realise the scalability
limitations and how the brittleness holds back both
performance and development flexibility. By then it is too
late to save.
http://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2
We need the reactive properties and then apply
protocols for the message interactions. Without
considering the protocols of interaction this world
of micro-services will become a coordination
nightmare.
Martin Thompson
76. IF WE WANT TO DECOUPLE OUR SERVICES AS MUCH
AS POSSIBLE
THEN WE NEED TO LOOK TOWARDS
COMPOSITE UI’S
AND
EVENTS
77. WHAT’S A COMPOSITE UI
A Composite UI is a way to allow different services to
participate an applications UI without revealing their
internals and thereby removing the need for other
services to know the this services internal data
This helps us keep coupling low and encapsulation high
78. Applications and Services
iOS Homebanking Call center support portal
Bank Backoffice application
Customer information service
Legal and contract information service
Accounts service
Credit card service
Mortgage loans service
79. Who owns the UI?
• For a service to be fully autonomous
is must be self contained – which
means it must:
• Own its UI
• Own its Business Logic
• Own its Data model
User interface
Business Logic
Data model &
storage
Service
A similar approach is available under the name Self Contained Systems http://scs-architecture.org/
80. If a Service doesn’t own its UI we often find the need for
a Gateway or Backend For a Frontend (BFF)
• Experience shows if you get
your Service API wrong the
first time around, it is really
expensive to fix it*
• The granularity of APIs
provided by microservices is
often different than what a
client needs*
* See http://thenewstack.io/microservices-calls-robust-api-management-tools/
81. Gateway or Backend For a Frontend (BFF)
• Unfortunately Gateways & BFF’s
introduce a lot of coupling
between the Gateway and the
underlying services
• If an underlying service changes
its contract in a non-backwards
compatible way the gateway
needs to change
• In these cases the clients of the
gateway may also need to change
since the changes can permeate
upwards (the gateway abstraction is
leaky)
* See http://thenewstack.io/microservices-calls-robust-api-management-tools/
83. Application UI’s
• An applications is a composition of different services
• The composition can be:
• Resource Oriented Client Architecture (ROCA) style service
integration (http://roca-style.org/)
• Mashup of Service UI components in a dedicated Application –
aka. Composite UI
Both solutions involve
integration via Services
web interfaces to minimize
coupling to other services.
Image from http://scs-architecture.org/
85. Widget Widget
Page
Widget
Service A Service B Service C
Widget
Widget
Widget
Service A
Service B
Service C
Widget
Service C
• Overall structure of the page
is “owned” by the application.
• Each widget is owned and
delivered by the
underlying Service.
Page layout
86. A SERVICE OWNS ITS UI IN ALL
CONTEXTS AND FOR ALL COMPOSITE
UI’S
Not just for HTML clients
87. Invoice Composite UI example
InvoiceHeader
Order:ShippingI
nfo
Invoice:
InvoiceNumber
Invoice:
Data and Due
date
Order:
RelationInformation
Order:Item-
Qty
Product:Ite
m
Product:
Description
Order:
Item-Unit-Price
Order:
Item-
Total-
Price
Order:Total
Billing:Balance
All Services
participate at
the UI level for
each individual
Item in the
Order
88. Coupling matrix*
* Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/
Behavioral
coupling
Temporal
coupling
Low High
Low
High
Event oriented Command oriented
Emergency services Distributed 3 layer
89. TO BREAK TEMPORAL COUPLING &
BEHAVIORAL COUPLING
SERVICES NEEDS TO COMMUNICATE
ASYNCHRONOUSLY USING BUSINESS EVENTS
Services communicate facts without making
assumptions about what other services intend
to do with the events
90. Let’s make the implicit explicit!
Old wisdom seems to have been forgotten. Let’s introduce:
Business/Domain Events
Which:
• Signal that something has happened
• Closely aligned to the Domain Model
• Are handled by a messaging system
• They are in the past tense:
• CustomerBilled
• ParcelShipped
• CustomerCreated
• ReviewCreated
• CommentAdded
• CommentDeleted
91. Events are often the side effect of Commands
A Command message is prescriptive of what should happen. This is a stronger form of coupling than Events.
A Command’s primary goal is to capture USER INTENT
A Command supports a single usecase and targets a single Aggregate
Commands always carry a name in its imperative form: CreateOrder, ShipOrder, CancelOrder, ReimburseCustomer, etc.
“A command describes a Task that you want someone else to
carry out for you and the recipient can reject the Command”
92. Commands & Events
Commands mutate Aggregate state –
and if succesful – will result in one or more Events being published
Command Event(s)
AcceptOrder OrderAccepted
ShipOrder OrderShipped
AddComment CommentAdded
QuarantineReview ReviewQuarantined
UnquarantineReview ReviewUnquarantined
93. WE NEED TO CHANGE FOCUS FROM
SHORT TECHNICAL TRANSACTIONS
To long running business transactions
supporting business processes
94. Using Business Events to drive Business Processes
Sales Service
Shipping
Billing
Sales
Customers
MessageChannel
Online Ordering System
Web Shop
(Composite UI)
Billing Service
Shipping Service
Order
Accepted
Event
AcceptOrder
Command
The sales
fulfillment
processing
can now
begin…
95. Choreographed Event Driven Processes
Sales Service
Order
Accepted
Invoicing Service
Order Fulfilment
(Saga/
Process-Manager)
Shipping Service
Online Ordering System
MessageChannel(e.g.aTopic)
Order
Accepted
Order
Accepted
Customer
Billed
Customer
Billed
Order
Approved
Order
Approved
Works as a Finite
State Machine
(WorkFlow)
handling the life
cycle of Shipping
and thereby forms
a very central new
Aggregate in the
System
96. Choreography is very different from the classical
orchestrated integration process
99. Different perspectives on data
With in a given Domain, e.g. Retail, there will exist multiple bounded contexts/sub-domains/business
capabilities such as:
• Product management
• Purchase
• Sales
• Pricing
• Inventory
• Shipping
• Support
• Accounting
• Management
Each of these lines of business have very specific and unique needs which are relevant for them alone in order
to conduct their business. They might use the same name for the entities they’re interested in or they might use
different names for the same logical entity.
100. Many perspectives on data
Online Retail System
Product
Unit Price
Promotional Price
Promotion End Date
Stock Keeping Unit (SKU)
Quantity On Hand (QOH)
Location Code
Price
Quantity Ordered
Name
The lifecycle of the data is VERY important!
Customer
Pricing
Inventory
Sales
Management Reporting
101. Smaller models & clear data ownership
Retail System
Pricing
Product
ProductID
Unit Price
Promotional
Price
…
Pricing
Inventory
Product
ProductID
SKU
QOH
Location Code
…
Inventory
Sales
Product
ProductID
Name
Description
Quantity
Ordered
…
Sales
Shared Entity identitySOA:
Service
103. What’s a macro architecture
• It’s the static/stable(r) parts of your architecture
• Which are very costly to refactor and change
• Business capabilities are stable
• Therefore we should strive to align services with business
capabilities / bounded contexts (DDD)
104. Service and Business Capability alignment
“The advantage of business capabilities is their remarkable level
of stability. If we take a typical insurance organisation, it will likely
have sales, marketing, policy administration, claims management,
risk assessment, billing, payments, customer service, human
resource management, rate management, document management,
channel management, commissions management, compliance, IT
support and human task management capabilities. In fact, any
insurance organisation will very likely have many of these
capabilities.”
See http://bill-poole.blogspot.dk/2008/07/business-
capabilities.html
105. A Service is
• The technical authority for a given business capability
• It is the owner of all the data and business rules that support this business
capability – everywhere (including the UI)
• It forms a single source of truth for that capability
• This form of business and IT alignment ensures that we can maintain service
Autonomy & Encapsulation
108. Services, Applications and code
• Each Service and Application is maintained in separate Git repositories
• Common IT Operations libraries and infrastructure are maintained in other
separate Git repositories
109. So what’s inside a Service source repository?
• Autonomous Components
• Libraries
• Adapters
• Front-end UI components
• API contracts (mainly Events)
• DB Schemas
• Build file(s)
111. Service and deployment
• A Service represents a logical responsibility
boundary
• Logical responsibility and physical deployment of a Service DOES
NOT have to be 1-to-1
• It’s too constraining
• We need more degrees of freedom
• Philippe Krutchen 4+1 views of architecture: Logical and Physical designs
should be independent of each other
A service needs to be deployed everywhere its data is needed
112. Service deployment
• Many services can be deployed to the same physical server
• Many services can be deployed in the same application
• Application boundary is a Process boundary which is a physical boundary
• A Service is a logical boundary
• Service deployment is not restricted to tiers either
• Part of service A and B can be deployed to the Web tier
• Another part of Service A and B can be deployed to the backend/app-service
tier of the same application
• The same service can be deployed to multiple tiers / multiple applications
• ie. applications and services are not the same and does not share the
same boundaries
• Multiple services can be “deployed” to the same UI page (service mashup)
• Multiple services can cooperate to fulfill a larger use-case (e.g. a workflow or a
business process)
113. Service
Autonomous
Component
1..*
Is implemented by
A Service is the technical authority
of a specific Business Capability
e.g. Sales, Shipping, Billing
Services support business processes.
Business processes naturally span multiple services, but
there will always be a single service that is the actual
authority on the business process.
Service vs Autonomous Components
114. Also known as Microservices
Service
Autonomous
Component
1..*
Is implemented by
Service vs Autonomous Components
Autonomous-Components/Microservices are a division of Services along Transactional
boundaries (a transaction stays within the boundary of a Microservice)
Microservices are the individually logical deployable units of a Service with their own
Endpoints. Could e.g. be the split between Read and Write models (CQRS) - each would be
their own Microservice
115. Services are the corner stone
• We talk in terms of Services/business capabilities and the processes/use-
cases they support
• Autonomous-Components/Microservices are an implementation detail
• They are much less stable (which is a good thing – it means they’re easier to replace)
• With regards to other Services
• subscribe to events from
• send commands to (less common)
• call operations (in rare occasions)
116. Services/Bounded Contexts and Aggregates
Sales
Service
PSP
ServiceVirtual Banking
Service
Finance
Service
Customer
customerId
…
Contract
contractId
customerId
…
VBFeeSchedule
contractId
…
PSPFeeSchedule
contractId
…
BillingTemplate
contractId
…
119. Commands and Events
public class RegisterBankCmd extends AbstractCommand {
@TargetAggregateIdentifier
public final BankId bankId;
public final String name;
public final Country countryOfOperation;
public RegisterBankCmd(BankId bankId, String name, Country countryOfOperation) {
Objects.requireNonNull(bankId, "bankId");
Objects.requireNonNull(name, "name");
Objects.requireNonNull(countryOfOperation, "countryOfOperation");
this.bankId = bankId;
this.name = name;
this.countryOfOperation = countryOfOperation;
}
}
120. Commands and Events
The generic business event interface includes the
name of the topic that subscribers must use
public class BankRegistered extends AbstractEvent implements BankEvent {
@AggregateIdentifier
public final BankId bankId;
public final String name;
public final Country countryOfOperation;
public BankCreated(BankId bankId, String name, Country countryOfOperation) {
this.bankId = bankId;
this.name = name;
this.countryOfOperation = countryOfOperation;
}
}
public interface BankEvent extends Serializable {
TopicName TOPIC_NAME = BankingServiceId.ID.topicName("bank-events");
}
121. CQRS
A single model cannot be
appropriate for reporting,
searching and transactional
behavior
Greg Young, 2008
122. Commands, Events and Query Models
Read model
Read model
Events
UI
Domain modelQuery/Read model
”AcceptOrder”
command
”OrderAccepted”
event
”Find all
Accepted Orders”
Query
Commands are Imperative: DoStuff
Events are Past tense: StuffDone
123. Event Sourcing
Aggregates track their own Domain Events
and derive state from them
Time
07:39
Time
07:40
Time
07:41
Time
07:45
Time
07:46
Time
07:50
124. Full CQRS
With EventSourcing
UI Domain
Event
Store
(can e.g. be a real
EventStore DB or
a Relational DB)
Commands – Change data
Commands Events
SQL DB Document DB Graph DB
UI Data
Queries – Ask for data
Events
Query Build
Our single
source of truth
125. Aggregate
public class Bank extends InPayEventSourcedAggregate {
@AggregateIdentifier
private BankId bankId;
@EventSourcedMember
private Map<BankAccountId, BankAccount> bankAccounts = new HashMap<>();
public Bank(BankId bankId, String name, Country countryOfOperation) {
apply(new BankRegistered(bankId, name, countryOfOperation));
}
public void addBankAccount(BankAccountId bankAccountId, …) {
if (!bankAccounts.containsKey(bankAccountId)) {
apply(new BankAccountAdded(bankId,
bankAccountId,
…));
}
}
@EventSourcingHandler
private void on(BankRegistered e) {
bankId = e.getBankId();
}
@EventSourcingHandler
private void on(BankAccountAdded e) {
BankAccount bankAccount =
bankAccounts.put(e.getBankAccountId(), new BankAccount(e.getBankId(), e.getBankAccountId(), …));
}
}
126. Service project structure sales_service
sales_api
sales_contract_ac
sales_customer_ac
frontend
sales_contract_manager_adapters
contract
adapters
sales/modules
customer
psp_service
psp_api
psp_fees_ac
…
frontend
psp_contract_manager_adapters
fees
adapters
psp/modules
fx
Legend:
Service/Business-Capability
External Event/Command Contracts
Autonomous Component
Autonomous Component Adapter
Angular.js Module
Builds into a Java JAR
Uses Spring MVC/REST
All Java 8 artifacts are built
using Gradle
127. Autonomous Component Library
• Can be deployed alone or co-located
• Usually deployed together with one or more adapters
• Works transparently in a clustered environment
• Completely Spring free
• Only depends on our Core infrastructure library
• Common types and Id’s
• Bus infrastructure
• Service lookup
• CQRS building blocks (backed by Axon framework)
128. Client handled subscriptions
• Highly resilient pattern for an Event Driven Architecture that’s backed by AC’s that
use EventSourcing.
• In this model the publisher of the Events is responsible for the durability of all its
Events, typically to an EventStore/EventLog.
• Each client (subscriber) maintains durable information of the last event it received
from each publisher.
• When ever the client starts up it makes a subscription to the publisher where it
states from which point in time it wants events published.
• This effectively means that publisher can remain simple and the client (subscriber)
can remain simple and we don’t need additional sophisticated broker infrastructure
such as Kafka+ZooKeeper.
136. Autonomous Components can be co-deployed together
with Application backends
contract_manager (Spring Boot fat–jar)
sales_contract_ac
sales_customer_ac
sales_contract_manager_adapters
psp_api
psp_fees_ac
psp_contract_manager_adapters
frontend
sales_api
app
libs
contract
customer
fees
137. Application in code
@Configuration
@ComponentScan(basePackages = { "com.inpay.contractmanager",
"com.inpay.adapters",
"com.inpay.itops.spring" })
public class Application extends InpaySpringBootApplication {
public Application() {
super();
}
@Override
protected String getApplicationName() {
return "ContractManager";
}
@Override
protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() {
CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc();
return list(
new IDMCoreAc(),
new PSPFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()),
new VBFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()),
new ContractAc(),
new CustomersAc(),
currencyExchangeRateAc
);
}
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
138. AC in code public class PSPAgreementAc extends HzBackedAutonomousComponent {
public static AutonomousComponentId SERVICE_AC_ID = PSP_SERVICE_ID.ac("psp_agreement_ac");
…
public PSPAgreementAc(CurrencyConverter currencyConverter) {
this.currencyConverter = currencyConverter;
}
@Override
public void onInitialize(IConfigureACEnvironment acSetup) {
acSetup.withAutonomousComponentId(SERVICE_AC_ID).usingServiceDataSource()
.withBusConfiguration(cfg -> {
cfg.getAxonContext()
.subscribeAnnotatedCommandHandler(new TemplateCmdHandler(
cfg.getAxonContext().eventSourcedRepository(PSPTemplate.class),
currencyConverter));
….
manageLifecycleFor(templateViewRepository = new TemplateViewRepository(cfg, currencyConverter));
})
.runOnBusStartup((bus, axonContext) -> {
bus.registerAxonReplayableTopicPublisher(InternalTemplateEvents.TOPIC_NAME,
replayFromAggregate(PSPTemplate.class)
.dispatchAggregateEventsOfType(InternalTemplateEvents.class));
bus.subscribeTopic(SERVICE_AC_ID.topicSubscriber("ContractEvents"),
ExternalContractEvents.TOPIC_NAME,
new SalesTopicSubscription(bus));
});
}
public TemplateViewRepository getTemplateViewRepository() { return templateViewRepository; }
}
139. AC, autonomy and “shared” service data
Service
DB
DB
Autonomous
Component
Autonomous
Component
Autonomous
Component
Autonomous
Component DB
140. 50 shades of inter service AC Autonomy*
Endpoint Process Database Storage
Shared Shared Shared Shared
Own Shared Shared Shared
Own Own Shared Shared
Own Shared Own Shared
Own Own Own Shared
Own Own Own Own
Lower Autonomy
Higher Autonomy
* No RPC in use!