SOA and DevOps v0.1

SOA and DevOps
Contradictory or Complementary
Mohamed Ismail Mostafa
SOA Certified Architect & Trainer
DevOps Transformation Lead
mmostafa@devopsi.io
Devopsi.io
V 0.1

Disclaimer
What we will discuss today
is being taught in 2 courses,
each is 5 days
So bear with me J
Service-Oriented Solution Logic

Agenda
1. Service Oriented Architecture (SOA)
2. Intro to Microservices Architecture
3. DevOps and Architecture
Service-Oriented Solution Logic

Section 1/3
Service Oriented Architecture (SOA)

Service Oriented Architecture Agenda
• SOA Strategic Goals and Benefits
• Service-Oriented Architectural Characteristics
• SOA basic building component: Service
• Fundamental Service Patterns
• Service Orientation Principles
• Building Mediums of SOA
• Service Design Patterns
• Enterprise Service Bus Patterns
• Orchestration Patterns

SOA Strategic Goals and Benefits

SOA Strategic Goals and Benefits
• Reduce IT burden
• Increase organizational agility
• Increase ROI
• Increase vendor diversification options
• Increase federation
• Increase intrinsic interoperability.
• Increase business and technology alignment

SOA Strategic Goals and Benefits…
• Reduce IT burden
• Increase organizational agility
• Increase ROI
• Increase vendor diversification options
• Increase federation
• Increase intrinsic interoperability.
• Increase business and technology alignment

SOA Architecture Characteristics

SOA Architecture Characteristics
• Business Driven
• Vendor-neutral
• Enterprise-centric
• Composition-centric

SOA Architecture Characteristics…
• Business Driven
• Vendor-neutral
• Enterprise-centric
• Composition-centric

SOA basic building component: Service

Three individuals, each capable of providing a distinct service

Services are Collections of Capabilities

Service contractService logic
Encapsulated resources

Fundamental Service Patterns
• Service
• Service composition
• Functional Context [Context Boundary]
• Agnostic/Non-Agnostic
• Service Layers Modeling

Fundamental Service Patterns
• Service
• Service composition
• Functional Context
• Agnostic/Non-Agnostic
• Service Layers Modeling

Service Orientation Principles

Service Orientation Principles
• Standardized service contract
• Service loose coupling
• Service abstraction
• Service reusability
• Service autonomy
• Service statelessness
• Service discoverability
• Service composability

Service Oriented Principles…
Services within the same service inventory are
in compliance with the same contract design standards.

Service contracts impose low consumer coupling requirements and are
themselves decoupled from their surrounding environment

Service contracts only contain essential information and
information about services is limited to what is published in service
contracts.
Service Abstraction also plays a significant role in the positioning and
design of service compositions.

Services contain and express agnostic logic (agnostic functional
Context) and can be positioned as reusable enterprise
resources/assets.

Services exercise a high level of control over their underlying runtime
execution environment fostering design characteristics that increase a
service’s reliability and behavioral predictability.
Does that remind you of something!!

Services minimize resource consumption by deferring the management
of state information when necessary.
Surrounding technology architecture to provide state management
delegation and state deferral options

Services are supplemented with communicative metadata by which
they can be effectively discovered and interpreted.

Services are effective composition participants, regardless of the size and
complexity of the composition.

Building Mediums of SOA
• Components
• Web Services
• REST services

Web Services
• Architecture:
• Service Contract
• WSDL definition
• XML definition
• WS-Policy definition
• Message Processing Logic
• Core service logic
• Discovery
• Design-time discovery
• Run-time discovery
• Industry Standards:
• SOAP
• WSDL
• UDDI
• XML Schema
• WS-*
• Coordination
• WS-Coordination
• Transaction
• WS-AtomicTransaction
• WS-BusinessActivity
• Orchestration
• WS-BPEL
• Addressing
• WS-Addressing
• Reliable Messaging
• WS-ReliableMessaging
• Policies
• WS-Policy
• Security
• WS-Security

Rest Services
• Service Contract
• Uniform contract
• HTTP Methods
• Architecture
• Resources
• HTTP Headers
• Caching
• Redirect
• Industry Standards
• XML
• JSON
• YAML
• …

Rest Services…
• RESTful Web Services Maturity Model:
• Richardson Maturity Model
https://martinfowler.com/articles/richardsonMaturityModel.htmlhttps://restfulapi.net/richardson-maturity-model/

REST Maturity Level 0
• RPC over HTTP
https://martinfowler.com/articles/richardsonMaturityModel.html

REST Maturity Level 0…
• RPC over HTTP
POST /appointmentService
HTTP/1.1 [various other headers]
<openSlotRequest date = "2010-01-04" doctor = "mjones"/>
HTTP/1.1 200 OK
[various headers]
<openSlotList>
<slot start = "1400" end = "1450">
<doctor id = "mjones"/>
</slot>
<slot start = "1600" end = "1650">
<doctor id = "mjones"/>
</slot>
</openSlotList>

• RPC over HTTP
<appointmentRequest>
<slot doctor = "mjones" start = "1400" end = "1450"/>
<patient id = "jsmith"/>
</appointmentRequest>
HTTP/1.1 200 OK
[various headers]
<appointment>
</appointment>

• RPC over HTTP
</appointmentRequest> HTTP/1.1 200 OK
[various headers]
<appointmentRequestFailure>
<slot doctor = "mjones" start = "1400" end = "1450"/> <patient id = "jsmith"/>
<reason>Slot not available</reason>
</appointmentRequestFailure>

• Resources

REST Maturity Level 1..
• Resources
POST /doctors/mjones
<openSlotRequest date = "2010-01-04"/>
HTTP/1.1 200 OK
[various headers]
<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
</openSlotList>

REST Maturity Level 1..
• Resources
POST /slots/1234
HTTP/1.1 200 OK
[various headers]
<appointment>
</appointment>
http://royalhope.nhs.uk/slots/1234/appointment

• HTTP Verbs
Use HTTP verbs as closely as possible to
how they are used in HTTP itself

HTTP Verbs
How Many HTTP verbs you know?

HTTP Verbs / Request Methods
1. GET
• The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and
should have no other effect
2. HEAD
• The HEAD method asks for a response identical to that of a GET request, but without the response body
3. POST
• The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web
resource identified by the URI
4. PUT
• The PUT method requests that the enclosed entity be stored under the supplied URI
5. DELETE
• The DELETE method deletes the specified resource
6. TRACE
• The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been
made by intermediate servers.
7. OPTIONS
• The OPTIONS method returns the HTTP methods that the server supports for the specified URL
8. CONNECT
• The CONNECT method converts the request connection to a transparent TCP/IP tunnel
9. PATCH
• The PATCH method applies partial modifications to a resource

HTTP Verbs/ Request Methods
Post
• The POST method requests that the server accept the entity
enclosed in the request as a new subordinate of the web
resource identified by the URI
• The PUT method requests that the enclosed entity be stored
under the supplied URI
• Create • Create Or Update
Put

• HTTP Verbs and Codes
GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk
HTTP/1.1 200 OK
[various headers]
<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400" end =
"1450"/>
<slot id = "5678" doctor = "mjones" start = "1600" end =
"1650"/>
</openSlotList>

POST /slots/1234 HTTP/1.1
[various other headers]
HTTP/1.1 201
Created Location: slots/1234/appointment
[various headers]
<appointment>
</appointment>

HTTP/1.1 409
Conflict [various headers]
<openSlotList>
</openSlotList>

• Hypermedia Controls
• Referred to under the ugly acronym of HATEOAS (Hypertext As The Engine Of Application State)
• It addresses the question of how to get from a list open slots to knowing what to do to book an
appointment

GET /doctors/mjones/slots?date=20100104&status=open
HTTP/1.1 Host: royalhope.nhs.uk
HTTP/1.1 200 OK
[various headers]
<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
<link rel = "/linkrels/slot/book" uri = "/slots/1234"/>
</slot>
<slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
<link rel = "/linkrels/slot/book" uri = "/slots/5678"/>
</slot>
</openSlotList>

HTTP/1.1 201
Created Location: http://royalhope.nhs.uk/slots/1234/appointment
[various headers]
<appointment>
<link rel = "/linkrels/appointment/cancel" uri = "/slots/1234/appointment"/>
<link rel = "/linkrels/appointment/addTest" uri = "/slots/1234/appointment/tests"/>
<link rel = "self" uri = "/slots/1234/appointment"/>
<link rel = "/linkrels/appointment/changeTime" uri = "/doctors/mjones/slots?date=20100104&status=open"/>
<link rel = "/linkrels/appointment/updateContactInfo" uri = "/patients/jsmith/contactInfo"/>
<link rel = "/linkrels/help" uri = "/help/appointment"/>
</appointment>

Richardson MM relationship to common
design techniques
Level 1 Tackles the question of handling complexity by using
divide and conquer, breaking a large service endpoint
down into multiple resources
Level 2 Introduces a standard set of verbs so that we handle
similar situations in the same way, removing unnecessary
variation
Level 3 Introduces discoverability, providing a way of making a
protocol more self-documenting

Agenda
• Service Design Patterns
• Enterprise Service Bus Patterns
• Orchestration Patterns

Service Design Patterns
• Decoupled Contract
• Contract Centralization
• Official Endpoint
• Service Facade
• Concurrent Contracts
• Redundant Implementation
• Service Data Replication
• Legacy Wrapper

• Service Facade
• Legacy Wrapper
How can a service express its capabilities independently of its
implementation?
The service contract is physically decoupled from its implementation https://patterns.arcitura.com/soa-patterns/design_patterns/decoupled_contract

• Service Facade
• Legacy Wrapper
How can direct consumer-to-implementation coupling be avoided?
Access to service logic is limited to the service contract, forcing
consumers to avoid implementation coupling
https://patterns.arcitura.com/soa-patterns/design_patterns/contract_centralization

• Service Facade
• Legacy Wrapper
https://patterns.arcitura.com/soa-patterns/design_patterns/logic_centralization
How can the misuse of redundant service logic be avoided?
Access to reusable functionality is limited to official agnostic services.

• Service Facade
• Legacy Wrapper
https://patterns.arcitura.com/soa-patterns/design_patterns/service_facade
How can a service accommodate changes to its contract or
implementation while allowing the core service logic to evolve
independently?
A service façade component is used to abstract a part of the service
architecture with negative coupling potential.

• Service Facade
• Legacy Wrapper
https://patterns.arcitura.com/soa-patterns/design_patterns/concurrent_contracts
How can a service facilitate multi-consumer coupling requirements and
abstraction concerns at the same time?
Multiple contracts can be created for a single service, each targeted at a
specific type of consumer

• Service Facade
• Legacy Wrapper
https://patterns.arcitura.com/soa-patterns/design_patterns/redundant_implementation
How can the reliability and availability of a service be increased?
Reusable services can be deployed via redundant implementations or
with failover support.

• Service Facade
• Legacy Wrapper
https://patterns.arcitura.com/soa-patterns/design_patterns/service_data_replication
How can service autonomy be preserved when services
require access to shared data sources?
Services can have their own dedicated databases with
replication to shared data sources

• Service Facade
• Legacy Wrapper
How can wrapper services with non-standard contracts be prevented from
spreading indirect consumer-to-implementation coupling?
The non-standard wrapper service can be replaced by or further wrapped with a
standardized service contract that extracts, encapsulates, and possibly eliminates
legacy technical details from the contract
StranglerFigApplication :
https://martinfowler.com/bliki/StranglerFigApplication.html
https://patterns.arcitura.com/soa-patterns/design_patterns/legacy_wrapper

Enterprise Service Bus Patterns

• Base Patterns
• Service Broker
• Data Format Transformation
• Data Model Transformation
• Protocol Bridging
• Intermediate Routing
• Asynchronous Queuing
• Extended Patterns
• Policy Centralization
• Rules Centralization
• Event-Driven Messaging
https://patterns.arcitura.com/soa-patterns/compound_patterns/enterprise_service_bus
An enterprise service bus represents an environment designed to foster
sophisticated interconnectivity between services.
It establishes an intermediate layer of processing that can help overcome
common problems associated with reliability, scalability, and
communications disparity.

• Base Patterns
• Service Broker
How can services interact with programs that communicate with
different data formats?
Intermediary data format transformation logic needs to be introduced in
order to dynamically translate one data format into another. https://patterns.arcitura.com/soa-patterns/design_patterns/data_format_transformation

• Base Patterns
• Service Broker
https://patterns.arcitura.com/soa-patterns/design_patterns/data_model_transformation
different data Models?
A data transformation technology can be incorporated to convert data
between disparate schema structures.

• Base Patterns
• Service Broker
https://patterns.arcitura.com/soa-patterns/design_patterns/protocol_bridging
How can a service exchange data with consumers that use different
communication protocols?
Bridging logic is introduced to enable communication between different
communication protocols by dynamically converting one protocol to
another at runtime.

• Base Patterns
• Service Broker
https://patterns.arcitura.com/soa-patterns/design_patterns/intermediate_routing
How can dynamic runtime factors affect the path of a message?
Message paths can be dynamically determined through the use of
intermediary routing logic.

• Base Patterns
• Service Broker
https://patterns.arcitura.com/soa-patterns/design_patterns/asynchronous_queuing
How can a service and its consumers accommodate isolated failures and
avoid unnecessarily locking resources?
A service can exchange messages with its consumers via an intermediary
buffer, allowing service and consumers to process messages
independently by remaining temporally decoupled.

• Base Patterns
• Service Broker
https://patterns.arcitura.com/soa-patterns/design_patterns/reliable_messaging
How can services communicate reliably when implemented in an
unreliable environment?
An intermediate reliability mechanism is introduced into the inventory
architecture, ensuring that message delivery is guaranteed.

• Base Patterns
• Service Broker
https://patterns.arcitura.com/soa-patterns/design_patterns/policy_centralization
How can policies be normalized and consistently enforced across
multiple services?
Global or domain-specific policies can be isolated and applied to multiple
services

• Base Patterns
• Service Broker
https://patterns.arcitura.com/soa-patterns/design_patterns/rules_centralization
How can business rules be abstracted and centrally governed?
The storage and management of business rules are positioned within a
dedicated architectural extension from where they can be centrally
accessed and maintained.

• Base Patterns
• Service Broker
https://patterns.arcitura.com/soa-patterns/design_patterns/event_driven_messaging
How can service consumers be automatically notified of runtime service
events?
The consumer establishes itself as a subscriber of the service. The
service, in turn, automatically issues notifications of relevant events to
this and any of its subscribers.

Orchestration Patterns
• Base Patterns
• Process Abstraction
• Process Centralization
• State Repository
• Compensating Service Transaction
• Atomic Service Transaction
An orchestration platform is dedicated to the effective maintenance and
execution of parent business process logic. Modern-day orchestration
environments are especially expected to support sophisticated and
complex service composition logic that can result in long-running
runtime activities

• Base Patterns
https://patterns.arcitura.com/soa-patterns/design_patterns/process_abstraction
How can non-agnostic process logic be separated and governed
independently?
A dedicated parent business process service layer is established to
support governance independence and the positioning of task services as
potential enterprise resources.

• Base Patterns
https://patterns.arcitura.com/soa-patterns/design_patterns/process_centralization
How can abstracted business process logic be centrally governed?
Logic representing numerous business processes can be deployed and
governed from a central location.

• Base Patterns
https://patterns.arcitura.com/soa-patterns/design_patterns/state_repository
How can service state data be persisted for extended periods without
consuming service runtime resources?
State data can be temporarily written to and then later retrieved from a
dedicated state repository.

• Base Patterns
https://patterns.arcitura.com/soa-patterns/design_patterns/compensating_service_transaction
How can composition runtime exceptions be consistently accommodated
without requiring services to lock resources?
Compensating routines are introduced, allowing runtime exceptions to
be resolved with the opportunity for reduced resource locking and
memory consumption

• Base Patterns
https://patterns.arcitura.com/soa-patterns/design_patterns/atomic_service_transaction
How can a transaction with rollback capability be propagated across
messaging-based services?
Runtime service activities can be wrapped in a transaction with rollback
feature that resets all actions and changes if the parent business task
cannot be successfully completed.

• Base Patterns
https://patterns.arcitura.com/soa-patterns/design_patterns/rules_centralization
How can business rules be abstracted and centrally governed?
he storage and management of business rules are positioned within a
dedicated architectural extension from where they can be centrally
accessed and maintained.

• Base Patterns
different data formats
A data transformation technology can be incorporated to convert data
between disparate schema structures
https://patterns.arcitura.com/soa-patterns/design_patterns/data_model_transformation

Section 2/3
Intro to Microservices Architecture

Intro to Microservices Architecture

https://medium.com/@rmzoni/soa-vs-microservices-
349c9f1f5b41
SOA Vs Microservices Architecture Style

• Maximizes application reusability
• A systematic change requires modifying the
monolith (Legacy Systems)
• DevOps and Continuous Delivery are not
mainstream
• Focused on business functionality reuse
• For communication it uses Enterprise Service
Bus — Monolith Structure
• Supports multiple message protocols
• Use of a common platform for all services
deployed to it
• Use of containers (such as Docker) is less
popular
• SOA services share the data storage
• Common governance and standards
• Decoupling
• A systematic change is to create a new service
• DevOps and Continuous Delivery as core value
• More importance on the concept of “bounded context” —
Products over Projects
• For communication uses less elaborate and simple
messaging systems
• Uses lightweight protocols such as HTTP, REST, and
Ligthweight Messaging
• Application Servers are not really used, it’s common to use
cloud platforms
• Containers work very well with microservices
• Each microservice can have an independent data storage
• Decentralized governance, with greater focus on teams
collaboration and freedom of choice
•

https://martinfowler.com/articles/microservices.html
Microservices a definition of this new architectural term
• Componentization via Services
• Organized around Business Capabilities
• Products not Projects
• Smart endpoints and dumb pipes
• Decentralized Governance
• Decentralized Data Management
• Infrastructure Automation
• Design for failure
• Evolutionary Design

https://medium.com/@nathankpeck/microservice-principles-smart-endpoints-and-dumb-pipes-5691d410700f

https://medium.com/@nathankpeck/microservice-principles-decentralized-governance-4cdbde2ff6ca

https://medium.com/@nathankpeck/microservice-principles-decentralized-data-management-4adaceea173f

https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture

Section 3/3
DevOps and Architecture

DevOps Ultimate Goal
115
Streamlining the complete Value Stream
from customer’s need to value
DevOps is Agile + Lean Management.

Technology Value Stream Map
117
Value Stream Efficiency = VAT / Lead Time = 49.5 days / 81 days = 61%
0 days 1 days 3 months 2 weeks 2 weeksNo Value Added Time (NVAT)
0.5 days 9 days 3 weeks 3 weeks 1 week 1 weekValue Added Time (VAT)
Iteration
Planning
Design
Code
Unit Test
Acceptance
Testing
Create
Training
Materials
Distribute
Release
Install
Release
45
points
45
points
270
points
270
points
270
points
Business
Unit
UsersIdea ValueValue
Lead Time

DevOps Technical Practices
Continuous Integration (CI)

Continuous Testing

Continuous Delivery / Deployment (CD)

DEV SITCI PROD
PRODSITCIDEV
DATACENTER
Platform blueprints define topology
for all application environments
Automated Provisioning

Metrics & Monitoring

Security

Architect for Low-Risk Releases…
124ARCHITECTURAL ARCHETYPES

Architect for Low-Risk Releases
• Create a loosely coupled architecture:
• Tightly-Coupled Architecture; small
changes can result in large scale failures.
• In contrast, when we have an architecture
that enables small teams of developers to
independently implement, test, and
deploy code into production safely and
quickly.
• Having architecture that is loosely-
coupled means that services can update
in production independently, without
having to update other services.
125

“The canary release pattern (Source: Humble and Farley, Continuous Delivery, 263.)

Architectural Archetypes
127
asdasd
Architecture style Pros Cons
Monolithic V1
(All functionality in one application)
• Simple at first
• Low inter-process Latencies
• Single codebase, one deployment unit
• Resource-efficient at small scales
• Coordination overhead increases as
team grows
• Poor enforcement of modularity
• Poor scaling
• All-or nothing deploy(downtime,
failures)
• Long build times.
Monolithic V2
(Sets of monolithic tiers: “front end
presentations, application server, database
layer”)
• Simple at first
• Join queries are easy
• Single schema deployment
• Resource-efficient at small scales
• Tendency for increase coupling over
time
• Poor scaling and redundancy (all or
nothing, vertical only)
• Difficult to tune properly
• All-or-nothing schema management
Microservices
(Modular, independent, graph relationship
Vs. Tiers, isolated persistence)
• Each unit is simple
• Independent scaling and performance
• Independent testing and deployment
• Can optimally tune performance
(Caching, replication…)
• Many cooperating units
• Many small repos
• Requires more sophisticated tooling
and dependency management
• Network latencies
Monoliths Vs. Microservices

SOA and DevOps
Contradictory or Complementary
Mohamed Ismail Mostafa
SOA Certified Architect & Trainer
DevOps Transformation Lead
mmostafa@devopsi.io
Devopsi.io

SOA and DevOps v0.1

More Related Content

What's hot (14)

Similar to SOA and DevOps v0.1 (20)

Recently uploaded (20)

SOA and DevOps v0.1