Microservices tenets
01 Jul 2017-Computer Science - Research and Development (Springer Science and Business Media LLC)-Vol. 32, Iss: 3, pp 301-310
TL;DR: This analysis confirms that microservices indeed can be seen as a development- and deployment-level variant of SOA; such microservices implementations have the potential to overcome the deficiencies of earlier approaches to SOA realizations by employing modern software engineering paradigms and Web technologies.
Abstract: Some microservices proponents claim that microservices form a new architectural style; in contrast, advocates of service-oriented architecture (SOA) argue that microservices merely are an implementation approach to SOA. This overview and vision paper first reviews popular introductions to microservices to identify microservices tenets. It then compares two microservices definitions and contrasts them with SOA principles and patterns. This analysis confirms that microservices indeed can be seen as a development- and deployment-level variant of SOA; such microservices implementations have the potential to overcome the deficiencies of earlier approaches to SOA realizations by employing modern software engineering paradigms and Web technologies such as domain-driven design, RESTful HTTP, IDEAL cloud application architectures, polyglot persistence, lightweight containers, a continuous DevOps approach to service delivery, and comprehensive but lean fault management. However, these paradigms and technologies also cause a number of additional design choices to be made and create new options for many "distribution classics" type of architectural decisions. As a result, the cognitive load for (micro-)services architects increases, as well as the design, testing and maintenance efforts that are required to benefit from an adoption of microservices. To initiate and frame the buildup of architectural knowledge supporting microservices projects, this paper compiles related practitioner questions; it also derives research topics from these questions. The paper concludes with a summarizing position statement: microservices constitute one particular implementation approach to SOA (service development and deployment).
Citations
More filters
TL;DR: This work systematically analyzes the industrial grey literature on microservices, to identify the technical/operational pains and gains of the microservice-based architectural style.
247 citations
05 Sep 2016
TL;DR: Results as well as early feedback from members of the target audience in industry and academia suggest that the coupling criteria catalog and tool-supported service decomposition approach have the potential to assist a service architect's design decisions in a viable and practical manner.
Abstract: Decomposing a software system into smaller parts always has been a challenge in software engineering. It is particularly important to split distributed systems into loosely coupled and highly cohesive units. Service-oriented architectures and their microservices deployments tackle many related problems, but remain vague on how to cut a system into discrete, autonomous, network-accessible services. In this paper, we propose a structured, repeatable approach to service decomposition based on 16 coupling criteria distilled from the literature and industry experience. These coupling criteria form the base of Service Cutter, our method and tool framework for service decomposition. In the Service Cutter approach, coupling information is extracted from software engineering artifacts such as domain models and use cases and represented as an undirected, weighted graph to find and score densely connected clusters. The resulting candidate service cuts promise to reduce coupling between and promote high cohesion within services. In our validation activities, which included prototyping, action research and case studies, we successfully decomposed two sample applications with acceptable performance; most (but not all) test scenarios resulted in appropriate service cuts. These results as well as early feedback from members of the target audience in industry and academia suggest that our coupling criteria catalog and tool-supported service decomposition approach have the potential to assist a service architect’s design decisions in a viable and practical manner.
131 citations
TL;DR: This work provides a detailed analysis of the differences between Service-Oriented Architecture (SOA) and Microservices, and describes both research and industry perspectives on the strengths and weaknesses of both architectural directions.
Abstract: Current industry trends in enterprise architectures indicate movement from Service-Oriented Architecture (SOA) to Microservices By understanding the key differences between these two approaches and their features, we can design a more effective Microservice architecture by avoiding SOA pitfalls To do this, we must know why this shift is happening and how key SOA functionality is addressed by key features of the Microservice-based system Unfortunately, Microservices do not address all SOA shortcomings In addition, Microservices introduce new challenges This work provides a detailed analysis of the differences between these two architectures and their features Next, we describe both research and industry perspectives on the strengths and weaknesses of both architectural directions Finally, we perform a systematic mapping study related to Microservice research, identifying interest and challenges in multiple categories from a range of recent research
130 citations
01 Dec 2017
TL;DR: The comparison and evaluation show that, the dataflow-driven identification mechanism is able to deliver more rational, objective, understandable and consistent microservice candidates, through a more rigorous and practical implementation procedure.
Abstract: Emerging from the agile practitioner communities, the microservice-oriented architecture emphasizes implementing and employing multiple small-scale and independently deployable microservices, rather than encapsulating all function capabilities into one monolithic application. Correspondingly, microservice-oriented decomposition, which has been identified to be an extremely challenging and complex task, plays a crucial and prerequisite role in developing microservice-based software systems. To address this challenge and reduce the complexity, we proposed a top-down analysis approach and developed a dataflow-driven decomposition algorithm. In brief, a three-step process is defined: first, engineers together with users conduct business requirement analysis and construct a purified while detailed dataflow diagram of the business logic; then, our algorithm combines the same operations with the same type of output data into a virtual abstract dataflow; finally, the algorithm extracts individual modules of "operation and its output data" from the virtual abstract dataflow to represent the identified microservice candidates. We have employed two use cases to demonstrate our microservice identification mechanism, as well as making comparisons with an existing microservice identification tool. The comparison and evaluation show that, our dataflow-driven identification mechanism is able to deliver more rational, objective, understandable and consistent microservice candidates, through a more rigorous and practical implementation procedure.
117 citations
TL;DR: Service-oriented architecture and microservices insiders Mike Amundsen, James Lewis, and Nicolai Josuttis share their experiences and predictions with department editors Cesare Pautasso and Olaf Zimmermann.
Abstract: Service-oriented architecture (SOA) and microservices insiders Mike Amundsen, James Lewis, and Nicolai Josuttis share their experiences and predictions with department editors Cesare Pautasso and Olaf Zimmermann.
111 citations
References
More filters
TL;DR: The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns.
Abstract: The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns. Architects capture their design decisions in four views and use the fifth view to illustrate and validate them. The logical view describes the design's object model when an object-oriented design method is used. To design an application that is very data driven, you can use an alternative approach to develop some other form of logical view, such as an entity-relationship diagram. The process view describes the design's concurrency and synchronization aspects. The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. The development view describes the software's static organization in its development environment. >
2,177 citations
Book•
05 Nov 2002
TL;DR: This book discusses the evolution of Layers in Enterprise Applications, Concurrency Problems, and Object-Relational Behavioral Patterns, as well as some Technology-Specific Advice.
Abstract: Preface. Who This Book Is For. Acknowledgements. Colophon. Introduction. Architecture. Enterprise Applications. Kinds of Enterprise Application. Thinking About Performance. Patterns. The Structure of the Patterns. Limitations of These Patterns. I. THE NARRATIVES. 1. Layering. The Evolution of Layers in Enterprise Applications. The Three Principal Layers. Choosing Where to Run Your Layers. 2. Organizing Domain Logic. Making a Choice. Service Layer. 3. Mapping to Relational Databases. Architectural Patterns. The Behavioral Problem. Reading in Data Structural Mapping Patterns. Mapping Relationships. Inheritance. Building the Mapping. Double Mapping. Using Metadata. Database Connections. Some Miscellaneous Points. Further Reading. 4. Web Presentation. View Patterns. Input Controller Patterns. Further Reading. 5. Concurrency (by Martin Fowler and David Rice). Concurrency Problems. Execution Contexts. Isolation and Immutability. Optimistic and Pessimistic Concurrency Control. Preventing Inconsistent Reads. Deadlocks. Transactions. ACID. Transactional Resources. Reducing Transaction Isolation for Liveness. Business and System Transactions. Patterns for Offline Concurrency Control. Application Server Concurrency. Further Reading. 6. Session State. The Value of Statelessness. Session State. Ways to Store Session State. 7. Distribution Strategies. The Allure of Distributed Objects. Remote and Local Interfaces. Where You Have to Distribute. Working with the Distribution Boundary. Interfaces for Distribution. 8. Putting it all Together. Starting With the Domain Layer. Down to the Data Source. Data Source for Transaction Script. Data Source Table Module (125). Data Source for Domain Model (116). The Presentation Layer. Some Technology-Specific Advice. Java and J2EE. .NET. Stored Procedures. Web Services. Other Layering Schemes. II. THE PATTERNS. 9. Domain Logic Patterns. Transaction Script. How It Works. When to Use It. The Revenue Recognition Problem. Example: Revenue Recognition (Java). Domain Model. How It Works. When to Use It. Further Reading. Example: Revenue Recognition (Java). Table Module. How It Works. When to Use It. Example: Revenue Recognition with a Table Module (C#). Service Layer(by Randy Stafford). How It Works. When to Use It. Further Reading. Example: Revenue Recognition (Java). 10. Data Source Architectural Patterns. Table Data Gateway. How It Works. When to Use It. Further Reading. Example: Person Gateway (C#). Example: Using ADO.NET Data Sets (C#). Row Data Gateway. How It Works. When to Use It. Example: A Person Record (Java). Example: A Data Holder for a Domain Object (Java). Active Record. How It Works. When to Use It. Example: A Simple Person (Java). Data Mapper. How It Works. When to Use It. Example: A Simple Database Mapper (Java). Example: Separating the Finders (Java). Example: Creating an Empty Object (Java). 11. Object-Relational Behavioral Patterns. Unit of Work. How It Works. When to Use It. Example: Unit of Work with Object Registration (Java) (by David Rice). Identity Map. How It Works. When to Use It. Example: Methods for an Identity Map (Java). Lazy Load. How It Works. When to Use It. Example: Lazy Initialization (Java). Example: Virtual Proxy (Java). Example: Using a Value Holder (Java). Example: Using Ghosts (C#). 12. Object-Relational Structural Patterns. Identity Field. How It Works. When to Use It. Further Reading. Example: Integral Key (C#). Example: Using a Key Table (Java). Example: Using a Compound Key (Java). Foreign Key Mapping. How It Works. When to Use It. Example: Single-Valued Reference (Java). Example: Multitable Find (Java). Example: Collection of References (C#). Association Table Mapping. How It Works. When to Use It. Example: Employees and Skills (C#). Example: Using Direct SQL (Java). Example: Using a Single Query for Multiple Employees (Java) (by Matt Foemmel and Martin Fowler). Dependent Mapping. How It Works. When to Use It. Example: Albums and Tracks (Java). Embedded Value. How It Works. When to Use It. Further Reading. Example: Simple Value Object (Java). Serialized LOB. How It Works. When to Use It. Example: Serializing a Department Hierarchy in XML (Java). Single Table Inheritance. How It Works. When to Use It. Example: A Single Table for Players (C#). Loading an Object from the Database. Class Table Inheritance. How It Works. When to Use It. Further Reading. Example: Players and Their Kin (C#). Concrete Table Inheritance. How It Works. When to Use It. Example: Concrete Players (C#). Inheritance Mappers. How It Works. When to Use It. 13. Object-Relational Metadata Mapping Patterns. Metadata Mapping. How It Works. When to Use It. Example: Using Metadata and Reflection (Java). Query Object. How It Works. When to Use It. Further Reading. Example: A Simple Query Object (Java). Repository (by Edward Hieatt and Rob Mee). How It Works. When to Use It. Further Reading. Example: Finding a Person's Dependents (Java). Example: Swapping Repository Strategies (Java). 14. Web Presentation Patterns. Model View Controller. How It Works. When to Use It. Page Controller. How It Works. When to Use It. Example: Simple Display with a Servlet Controller and a JSP View (Java). Example: Using a JSP as a Handler (Java). Example: Page Handler with a Code Behind (C#). Front Controller. How It Works. When to Use It. Further Reading. Example: Simple Display (Java). Template View. How It Works. When to Use It. Example: Using a JSP as a View with a Separate Controller (Java). Example: ASP.NET Server Page (C#). Transform View. How It Works. When to Use It. Example: Simple Transform (Java). Two Step View. How It Works. When to Use It. Example: Two Stage XSLT (XSLT). Example: JSP and Custom Tags (Java). Application Controller. How It Works. When to Use It. Further Reading. Example: State Model Application Controller (Java). 15. Distribution Patterns. Remote Facade. How It Works. When to Use It. Example: Using a Java Session Bean as a Remote Facade (Java). Example: Web Service (C#). Data Transfer Object. How It Works. When to Use It. Further Reading. Example: Transferring Information about Albums (Java). Example: Serializing Using XML (Java). 16. Offline Concurrency Patterns. Optimistic Offline Lock (by David Rice). How It Works. When to Use It. Example: Domain Layer with Data Mappers (165) (Java). Pessimistic Offline Lock (by David Rice). How It Works. When to Use It. Example: Simple Lock Manager (Java). Coarse-Grained Lock (by David Rice and Matt Foemmel). How It Works. When to Use It. Example: Shared Optimistic Offline Lock (416) (Java). Example: Shared Pessimistic Offline Lock (426) (Java). Example: Root Optimistic Offline Lock (416) (Java). Implicit Lock (by David Rice). How It Works. When to Use It. Example: Implicit Pessimistic Offline Lock (426) (Java). 17. Session State Patterns. Client Session State. How It Works. When to Use It. Server Session State. How It Works. When to Use It. Database Session State. How It Works. When to Use It. 18. Base Patterns. Gateway. How It Works. When to Use It. Example: A Gateway to a Proprietary Messaging Service (Java). Mapper. How It Works. When to Use It. Layer Supertype. How It Works. When to Use It. Example: Domain Object (Java). Separated Interface. How It Works. When to Use It. Registry. How It Works. When to Use It. Example: A Singleton Registry (Java). Example: Thread-Safe Registry (Java) (by Matt Foemmel and Martin Fowler). Value Object. How It Works. When to Use It. Money. How It Works. When to Use It. Example: A Money Class (Java) (by Matt Foemmel and Martin Fowler). Special Case. How It Works. When to Use It. Further Reading. Example: A Simple Null Object (C#). Plugin (by David Rice and Matt Foemmel). How It Works. When to Use It. Example: An Id Generator (Java). Service Stub (by David Rice). How It Works. When to Use It. Example: Sales Tax Service (Java). Record Set. How It Works. When to Use It. References Index. 0321127420T10162002
1,922 citations
Book•
01 Jan 2003
TL;DR: Enterprise Integration Patterns provides an invaluable catalog of sixty-five patterns, with real-world solutions that demonstrate the formidable of messaging and help you to design effective messaging solutions for your enterprise.
Abstract: Would you like to use a consistent visual notation for drawing integration solutions? Look inside the front cover. Do you want to harness the power of asynchronous systems without getting caught in the pitfalls? See "Thinking Asynchronously" in the Introduction. Do you want to know which style of application integration is best for your purposes? See Chapter 2, Integration Styles. Do you want to learn techniques for processing messages concurrently? See Chapter 10, Competing Consumers and Message Dispatcher. Do you want to learn how you can track asynchronous messages as they flow across distributed systems? See Chapter 11, Message History and Message Store. Do you want to understand how a system designed using integration patterns can be implemented using Java Web services, .NET message queuing, and a TIBCO-based publish-subscribe architecture? See Chapter 9, Interlude: Composed Messaging.Utilizing years of practical experience, seasoned experts Gregor Hohpe and Bobby Woolf show how asynchronous messaging has proven to be the best strategy for enterprise integration success. However, building and deploying messaging solutions presents a number of problems for developers. Enterprise Integration Patterns provides an invaluable catalog of sixty-five patterns, with real-world solutions that demonstrate the formidable of messaging and help you to design effective messaging solutions for your enterprise.The authors also include examples covering a variety of different integration technologies, such as JMS, MSMQ, TIBCO ActiveEnterprise, Microsoft BizTalk, SOAP, and XSL. A case study describing a bond trading system illustrates the patterns in practice, and the book offers a look at emerging standards, as well as insights into what the future of enterprise integration might hold.This book provides a consistent vocabulary and visual notation framework to describe large-scale integration solutions across many technologies. It also explores in detail the advantages and limitations of asynchronous messaging architectures. The authors present practical advice on designing code that connects an application to a messaging system, and provide extensive information to help you determine when to send a message, how to route it to the proper destination, and how to monitor the health of a messaging system. If you want to know how to manage, monitor, and maintain a messaging system once it is in use, get this book. 0321200683B09122003
1,374 citations
Book•
01 Aug 2003
TL;DR: This chapter discusses Modeling Paradigms and Tool Support, which focuses on Designing Objects for Relational Databases, and the Pitfalls of Infrastructure-Driven Packaging.
Abstract: Foreword. Preface. Acknowledgments. I. PUTTING THE DOMAIN MODEL TO WORK. 1. Crunching Knowledge. Ingredients of Effective Modeling. Knowledge Crunching. Continuous Learning. Knowledge-Rich Design. Deep Models. 2. Communication and the Use of Language. UBIQUITOUS LANGUAGE. Modeling Out Loud. One Team, One Language. Documents and Diagrams. Written Design Documents. Executable Bedrock. Explanatory Models. 3. Binding Model and Implementation. MODEL-DRIVEN DESIGN. Modeling Paradigms and Tool Support. Letting the Bones Show: Why Models Matter to Users. HANDS-ON MODELERS. II. THE BUILDING BLOCKS OF A MODEL-DRIVEN DESIGN. 4. Isolating the Domain. LAYERED ARCHITECTURE. Relating the Layers. Architectural Frameworks. The Domain Layer Is Where the Model Lives. THE SMART UI "ANTI-PATTERN" Other Kinds of Isolation. 5. A Model Expressed in Software. Associations. ENTITIES (A.K.A. REFERENCE OBJECTS). Modeling ENTITIES. Designing the Identity Operation. VALUE OBJECTS. Designing VALUE OBJECTS. Designing Associations That Involve VALUE OBJECTS. SERVICES. SERVICES and the Isolated Domain Layer. Granularity. Access to SERVICES. MODULES (A.K.A. PACKAGES). Agile MODULES. The Pitfalls of Infrastructure-Driven Packaging. Modeling Paradigms. Why the Object Paradigm Predominates. Nonobjects in an Object World. Sticking with MODEL-DRIVEN DESIGN When Mixing Paradigms. 6. The Life Cycle of a Domain Object. AGGREGATES. FACTORIES. Choosing FACTORIES and Their Sites. When a Constructor Is All You Need. Designing the Interface. Where Does Invariant Logic Go? ENTITY FACTORIES Versus VALUE OBJECT FACTORIES. Reconstituting Stored Objects. REPOSITORIES. Querying a REPOSITORY. Client Code Ignores REPOSITORY Implementation Developers Do Not. Implementing a REPOSITORY. Working Within Your Frameworks. The Relationship with FACTORIES. Designing Objects for Relational Databases. 7. Using the Language: An Extended Example. Introducing the Cargo Shipping System. Isolating the Domain: Introducing the Applications. Distinguishing ENTITIES and VALUE OBJECTS. Role and Other Attributes. Designing Associations in the Shipping Domain. AGGREGATE Boundaries. Selecting REPOSITORIES. Walking Through Scenarios. Sample Application Feature: Changing the Destination of a Cargo. Sample Application Feature: Repeat Business. Object Creation. FACTORIES and Constructors for Cargo. Adding a Handling Event. Pause for Refactoring: An Alternative Design of the Cargo AGGREGATE. MODULES in the Shipping Model. Introducing a New Feature: Allocation Checking. Connecting the Two Systems. Enhancing the Model: Segmenting the Business. Performance Tuning. A Final Look. III. REFACTORING TOWARD DEEPER INSIGHT. 8. Breakthrough. Story of a Breakthrough. A Decent Model, and Yet... The Breakthrough. A Deeper Model. A Sobering Decision. The Payoff. Opportunities. Focus on Basics. Epilogue: A Cascade of New Insights. 9. Making Implicit Concepts Explicit. Digging Out Concepts. Listen to Language. Scrutinize Awkwardness. Contemplate Contradictions. Read the Book. Try, Try Again. How to Model Less Obvious Kinds of Concepts. Explicit Constraints. Processes as Domain Objects. SPECIFICATION Applying and Implementing SPECIFICATION. 10. Supple Design. INTENTION-REVEALING INTERFACES. SIDE-EFFECT-FREE FUNCTIONS. ASSERTIONS. CONCEPTUAL CONTOURS. STANDALONE CLASSES. CLOSURE OF OPERATIONS. DECLARATIVE DESIGN. Domain-Specific Languages. A Declarative Style of Design. Extending SPECIFICATIONS in a Declarative Style. Angles of Attack. Carve Off Subdomains. Draw on Established Formalisms, When You Can. 11. Applying Analysis Patterns. 12. Relating Design Patterns to the Model. STRATEGY (A.K.A. POLICY). COMPOSITE. Why Not FLYWEIGHT? 13. Refactoring Toward Deeper Insight. Initiation. Exploration Teams. Prior Art. A Design for Developers. Timing. Crisis as Opportunity. IV. STRATEGIC DESIGN. 14. Maintaining Model Integrity. BOUNDED CONTEXT. Recognizing Splinters Within a BOUNDED CONTEXT CONTINUOUS INTEGRATION. CONTEXT MAP. Testing at the CONTEXT Boundaries. Organizing and Documenting CONTEXT MAPS. Relationships Between BOUNDED CONTEXTS. SHARED KERNEL. CUSTOMER/SUPPLIER DEVELOPMENT TEAMS. CONFORMIST. ANTICORRUPTION LAYER. Designing the Interface of the ANTICORRUPTION LAYER. Implementing the ANTICORRUPTION LAYER. A Cautionary Tale. SEPARATE WAYS. OPEN HOST SERVICE. PUBLISHED LANGUAGE. Unifying an Elephant. Choosing Your Model Context Strategy. Team Decision or Higher. Putting Ourselves in Context. Transforming Boundaries. Accepting That Which We Cannot Change: Delineating the External Systems. Relationships with the External Systems. The System Under Design. Catering to Special Needs with Distinct Models. Deployment. The Trade-off. When Your Project Is Already Under Way. Transformations. Merging CONTEXTS: SEPARATE WAYS-SHARED KERNEL. Merging CONTEXTS: SHARED KERNEL-CONTINUOUS INTEGRATION. Phasing Out a Legacy System. OPEN HOST SERVICE-PUBLISHED LANGUAGE. 15. Distillation. CORE DOMAIN. Choosing the CORE. Who Does the Work? An Escalation of Distillations. GENERIC SUBDOMAINS. Generic Doesn't Mean Reusable. Project Risk Management. DOMAIN VISION STATEMENT. HIGHLIGHTED CORE. The Distillation Document. The Flagged CORE. The Distillation Document as Process Tool. COHESIVE MECHANISMS. GENERIC SUBDOMAIN Versus COHESIVE MECHANISM. When a MECHANISM Is Part of the CORE DOMAIN. Distilling to a Declarative Style. SEGREGATED CORE. The Costs of Creating a SEGREGATED CORE. Evolving Team Decision. ABSTRACT CORE. Deep Models Distill. Choosing Refactoring Targets. 16. Large-Scale Structure. EVOLVING ORDER. SYSTEM METAPHOR. The "Naive Metaphor" and Why We Don't Need It. RESPONSIBILITY LAYERS. Choosing Appropriate Layers. KNOWLEDGE LEVEL. PLUGGABLE COMPONENT FRAMEWORK. How Restrictive Should a Structure Be? Refactoring Toward a Fitting Structure. Minimalism. Communication and Self-Discipline. Restructuring Yields Supple Design. Distillation Lightens the Load. 17. Bringing the Strategy Together. Combining Large-Scale Structures and BOUNDED CONTEXTS. Combining Large-Scale Structures and Distillation. Assessment First. Who Sets the Strategy? Emergent Structure from Application Development. A Customer-Focused Architecture Team. Six Essentials for Strategic Design Decision Making. The Same Goes for the Technical Frameworks. Beware the Master Plan. Conclusion. Appendix: The Use of Patterns in This Book. Glossary. References. Photo Credits. Index. 0321125215T08272003
885 citations
Book•
31 Aug 2007
TL;DR: The soft file concept is offered right here is the art of distributed system design theory in practice by reading this site and you can easily find and get this soa in practice.
Abstract: If you get the printed book in on-line book store, you may also find the same problem. So, you must move store to store and search for the available there. But, it will not happen here. The book that we will offer right here is the soft file concept. This is what make you can easily find and get this soa in practice the art of distributed system design theory in practice by reading this site. We offer you the best product, always and always.
439 citations
"Microservices tenets" refers background in this paper
...Tables 2 and 3 map the defining elements in the two above definitions to SOA principles and patterns as defined in the academic literature, including our own work [33], but also practitioner articles and books such as the ones byMurer and Hagen [21] and Josuttis [12]....
[...]
...practitioner articles and books such as the ones byMurer and Hagen [21] and Josuttis [12]....
[...]
...These choices do not violate any SOAprinciples or patterns such as loose coupling and service contract [9,12,33], but rather embrace and leverage them....
[...]