![DevOps Engineer [Arabic]](https://cdn.slidesharecdn.com/ss_thumbnails/arabicdevops-devopsengineerarabic-200211211127-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Similar to SOA vs Microservices vs SBA (20)
Ad
More from Michael Sukachev (8)
Ad
Recently uploaded (20)
SOA vs Microservices vs SBA
- 1. SOA vs Microservices vs SBA
- 7. Microservices Architecture Benefits • Each microservice is relatively small • Easier for a developer to understand • The IDE is faster making developers more productive • The web container starts faster, which makes developers more productive, and speeds up deployments • Each service can be deployed independently of other services - easier to deploy new versions of services frequently • Easier to scale development. It enables you to organize the development effort around multiple teams. Each team is responsible a single service. Each team can develop, deploy and scale their service independently of all of the other teams. • Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. • Eliminates any long-term commitment to a technology stack
- 8. Microservices Architecture Drawbacks • Developers must deal with the additional complexity of creating a distributed system. • Developer tools/IDEs are oriented on building monolithic applications and don’t provide explicit support for developing distributed applications. • Testing is more difficult • Developers must implement the inter-service communication mechanism. • Implementing use cases that span multiple services without using distributed transactions is difficult • Implementing use cases that span multiple services requires careful coordination between the teams • Deployment complexity. In production, there is also the operational complexity of deploying and managing a system comprised of many different service types. • Increased memory consumption. The microservices architecture replaces N monolithic application instances with NxM services instances. If each service runs in its own JVM (or equivalent), which is usually necessary to isolate the instances, then there is the overhead of M times as many JVM runtimes. Moreover, if each service runs on its own VM (e.g. EC2/Azure instance), as is the case at Netflix, the overhead is even higher.
- 9. Service-Based Architecture (SBA - SOA and Microservices Hybrid)
- 14. Coupling Types in Software Architecture • Content Coupling (Pathological Coupling) • One module modifies or relies on the internal implementation of another module • Common Coupling (Global coupling) • Two modules share the same global data (e.g., a global variable) • External Coupling • Two modules share an externally imposed data format, communication protocol or device interface • Control Coupling • One module controlling the flow of another, by passing it an information on what to do (e.g., passing what-to-do flags/codes) • Stamp Coupling (Data-structured Coupling) • Modules share a composite data structure and use only a part of it, possibly a different part (e.g., passing the whole JSON structure to a function that only uses specific fields from it) • Data Coupling • Data sharing through parameters, for example. Each peace piece of information is elementary and the only shared data (like SOAP) • Message Coupling • Data is shared through the message-based exchange (like REST)