Integration Flashcards
What’s the difference Between SOA and microservices?
Service-oriented architecture (SOA) is a method of software development that uses software components called services to create business applications. Each service provides a business capability. They can also communicate with each other across platforms and languages. Developers use SOA to reuse services in different systems or combine several independent services to perform complex tasks. Microservices architecture is an evolution of the SOA architectural style. While each SOA service is a full business capability, each microservice is a much smaller software component that specializes in a single task only. Microservices address the shortcomings of SOA to make the software more compatible with modern cloud-based enterprise environments.
Read about SOA »
Read about microservices »
What limitations of monolithic architecture does SOA architecture solve?
In monolithic architecture, developers write code for all service functions in a single code base. With service-oriented architecture (SOA), developers can address the challenges of the monolithic architecture, such as the following:
Scaling challenges that require the entire application to scale, even if only a specific component needs additional resources.
The inability to add or modify features flexibly, as functionality is distributed across the code base.
The inability to reuse components across different applications.
Limited fault tolerance. Failure in one component can potentially bring down the entire system.
The challenge of adopting new technologies or integrating with external systems that use different technologies.
Monolithic architectures also centralize ownership and development teams responsible for the entire application. They face challenges with continuous delivery and DevOps practices due to the size and complexity of the architectures.
With SOA, developers break down the software functionalities into service provider and service consumer layers. These layers communicate and exchange data through an enterprise service bus (ESB). Developers use SOA to simplify complex applications into multiple reusable services.
What limitations of SOA architecture does the microservices architecture solve?
While service-oriented architecture (SOA) might work well for building large enterprise applications, it needs more flexibility to scale smaller, business-specific applications. These are some limitations of SOA:
The enterprise service bus (ESB) connects multiple services together, which makes it a single point of failure.
All services share a common data repository. This makes the services difficult to manage individually.
Every service has a broad scope. So, if one of the services fails, the entire business workflow will be affected.
So, developers turn to microservices architecture for a more fine-grained approach to building applications.
Name architectures you know
SOA arc., Api-led Arch, microservice architecture, Event-driven arc., DDD, Hexagonal or ports and adapters.
Api-led vs Microservices architecture differences (with regards to definition)
Definition: Api-led is more about strategic use of assets and focus on connectivity while microservices ark. is about being small and independently deployable which Api-led often is but dont have to be. you could broadly characterize API-led architecture as a more top-down approach and microservices architecture as more bottom-up in the context of designing and working with web services, although such a distinction can be somewhat simplified and not universally applicable.
Api-led vs Microservices architecture differences (with regards to uses cases and Service Orientation)
Api-led is focused on integrating systems and exposing data to external consumers. Micrservices being free from 3-layer constraing is suitable for more complex scenarios.
DDD vs Api-led
DDD says little about how to access the data and events that are held in the core business applications. Nor does it say much about the needs of consumers – who often need to write lots of custom code in order to translate the output of domain entities into what they need. But DDD can help to design good domains in a good way, and it can help designing bounded context models
IBM taking on event driven architect and data models.
Ref: https://ibm-cloud-architecture.github.io/refarch-eda/concepts/model/
One object model per interface: Using an independent data model for every service interface assures the highest level of decoupling between services. As negative, the consumers have to understand different representations of the same business entities across multiple services and have to cope with all the relative data transformations. This strategy can be very effective for coarse-grained service operations that do not exchange large amount of data with consumers.
One object model per business domain: the service information models are organized in domains, every domain sharing the same data model. The downside of this approach, is once domains are defined, changing their boundaries can be costly.
A single object model for the whole enterprise: the approach is to define a single common set of data structures shared across all the enterprise service interfaces. The amount of model customization is kept to a minimum and its management is centralized. The negatives are having overly complicated model the consumers need to process. As of now it becomes a bad practices to adopt such canonical model at the API, persistence and eventing level.
