(Long version) Microservices - SOA reminded of what it was supposed to deliver
-
Upload
jeppe-cramon -
Category
Technology
-
view
321 -
download
0
Transcript of (Long version) Microservices - SOA reminded of what it was supposed to deliver
MicroservicesSOA reminded of what it was supposed to deliver?
Jeppe Cramon - @jeppecL&B Faglig Fredag - May 2015
SOA or Microservices?
Better ROI, More Security, Fewer Defects, Reusable assets, Better Maintainability, More reuse, Better parallelism in development, Better scalability, Higher availability….
… building blocks that can be reused and tweaked as needed. There’s also a redundancy benefit: Should one … fail the other ones will work in the app.
Higher reusability, significant reduction of development cost, increased reliability, improved maintainability, enhanced quality…
SOA
Microservices
Component based development
For years no one talked about SOA
Mostly because of the many failures…
Example:I've used service-oriented architecture for the better part of a decade, and I can honestly report the following …
Source: http://www.techrepublic.com/blog/tech-decision-maker/the-unfulfilled-promise-of-soa/
• I have never seen the "contract" feature of any service I've written or designed be leveraged to enable its re-use
• I have never seen a service from one system be recoupled to another• I have never seen encapsulated logic used in multiple applications
In my opinion SOA is not to blame for the disappointment
Perhapsyou’re holding it wrong?
Actually what is SOA?
Is this SOA?Webshop Order Management
CRM ERP
Customer data
Product data
Or is this SOA?
ERP
Webshop Order Management
CRM
ESB
What is an architecture?
It’s the • Overall macroscopic system
structure– How responsibilities are assigned and
divided– How connectors can be placed between
systems– Principles for connectors
Architecture is essential
Because it influences how fast we can respond to
changes and what the cost of these changes are
Spaghetti SOA?Webshop Order Management
CRM ERP
Customer data
Product data
Spaghetti integration can result in a lot of accidental
complexity
Because we’re bound by the rules of distributed
computing
Essential complexity of local component integration
CBA
UI
Service Service
B:Service() call C:Service() call A:Service() commit()
Service
Local transaction between A, B and C
B:Service() call C:Service() call A:Service() if (A:Call-Failed?) call A:Service() if (A:Call-Failed?) Wait-A-While() call A:Service() if (A:Call-Failed-Due-To-IO?) 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 integrations
CBA
UI
Service Service Service
Local transaction between B and C
If we can, we should fight to avoid this complexity
Why?
Cost of Software Development
• The 60/60 rule*• The cost of software maintenance
consumes 40%-80% (60 % in average)– Of this, 60% is consumed by
enhancements– And only 17% is consumed by error
corrections
* "Frequently Forgotten Fundamental Facts about Software Engineering" by Robert L. Glass, IEEE Software May/June 2001
There’s a big risk that enhancements permeate into multiple systems
(because systems often overlap with regards to
responsibilities)
What are the sources of enhancements?
• New business requirements– Changed processes– Changed calculations– New features– New corporate strategies– Ability to sell individual “components” of our systems
• Management decisions to purchase 3rd party applications– Upgrades/replacement to existing 3rd party systems– Replacing existing functionality in our application with new
components/systems (e.g. best of breed or golf course deals)
• Mergers• Golf course deals• …
So what does this have to do with Microservices?
I believe that Microservices is a welcome opportunity to brush off the dust from SOA,
(re)learn form the past and perhaps improve going forward
Beware of
sales pitches
The fine-grained, stateless, self- contained nature of microservices creates decoupling between different parts of a code base and is what makes themeasy to update, replace, remove, or augment.
Microservices: The resurgence of SOA principles and an alternative to the monolith
Trying hard to pretend it’s not difficult to develop distributed systems
It seems the argument is that just by making things fine grained
We by magic achieve decoupling
Decoupled?
Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
Monoliths are often blamed for being the the cause of all our
problems due to hidden coupling
And microservices are claimed to be the solution
Monoliths start simple
“The” DB
UI
Logic
Data Access
Next step is spaghetti in layers
And finally we drown
Characteristics of a monolith
• Hard to adapt to new technology• Low Reusability
– Functionality of a part cannot be reused alone
• Slow Delivery train– Introducing a new feature often requires coordination with other
features to deliver all of them at the same time
• Higher and higher maintenance cost over time• Change to control flow is often hard• Starting the application often takes a long time• Testing the application often takes a long time• Forces high requirements on mental capacity to keep the
entire monolith in your head• Tends to grow bigger and bigger and bigger• Low Reliability
– When one thing fails => potentially everything fails (e.g. due to OutOfMemoryException)
If we keep up the same habits that resulted in messy monoliths
What’s makes us think that we won’t end up with
Question
Microservice spaghetti?
Most “Services” today are built on top of Monoliths
Monolith A Monolith B
Monolith C Monolith D
Service A.1
Service A.2
Service A.3
Service A.4
Service B.1
Service B.2
Service B.3
Service B.4
Service D.1
Service D.4
Service D.3
Service D.2
Service C.4
Service C.3
Service C.2
Service C.1
DB DB
DB DB
Monolith A Monolith B
Monolith C Monolith D
So if we create naïve microservices
Service A.1
Service A.2
Service A.3
Service A.4
Service B.1
Service B.2
Service B.3
Service B.4
Service D.1
Service D.4
Service D.3
Service D.2
Service C.4
Service C.3
Service C.2
Service C.1
DB
DB
DBDB
DB
DB DB DB
DBDBDB
DB
DB DB
DB
DB
DB DB
DB DB
Then we’ve IMO just gone from bad
To Worse
So does that mean that breaking things apart is a bad thing?
Definitely NOT!
But we need some guidelines to avoid things becoming
messy (once again)
So how do we get there?
Let’s look at some of the characteristics of
Microservices(that most seem to agree
upon)
Microservice characteristics • Single Responsibility Principle (SRP) • Small• Own process• Valuable• Replaceable• Upgradeable• Independent• Encapsulated• Composable• Testable• Fast startup/shutdown• Client friendly
Single Responsibility Principle (SRP)
Billing
DB
Order Fulfillment
DB
SMS Gateway
Shipping
DB
Management Reporting
DB
A MicroService should have a single responsibility and
this responsibility should be entirely encapsulated within the service
So how big/small should a microservice/responsibility
be?
Does a Microservice own its data?
• Remember layered SOA?
Layered SOA
Data Storage
Data Storage
Data Storage
DataService
DataService
DataService
ActivityService
ActivityService
Process Service
Process Service
Client Client
Client
DataService
If one service is down, you risk everything is
down
Does a Microservice own its data?
• Remember layered SOA?• IMO a service that only deals with data
persistence is best called a database/datastore• It already has a nice API– We don’t need to bubble wrap it with REST or Async
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.
What’s the right size?
I’ve heard that a “Microservice should be no larger than
100 Lines of Code!?”
No 500 lines!
No 10 lines and they
should be functional and
have no side effects!
Is that with or without frameworks?
Only Clojure is the right language for
microservices!NodeJS is the only way
No SpringBoot!
Bad programmers worry about the code.Good programmers worry about data structures and their relationships
Linus Thorvald
Bad programmers worry about microservices code size. Good programmers worry about their data ownership and relationships
Jeppe Cramon
Enough with the size!
When did we get away from solving business problems and start
talking technology, JSON over XML, REST, LoC’s, Frameworks again?
It reminds me of the early SOA days
All that was talked about then was which ESB to purchase, to how set it up, etc.
No body discussed the problems that the ESB was supposed to solve (or when it was appropriate) or what services to build.
We were caught in technology silver bullet again!
We kind of forgot that SOA was about business
agilityIt was too much
“Build it and they will come”
There is value in making things smaller
For one thing it easier to reason about them in isolation
Going small has its advantages
Source: @aviranm
SRP
This sounds really good but what about cross Service
relationships?
Customer Orders
Products
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
Should we replace joins with RPC?
The Query of Despair
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
Size this and Size that!Be Careful
If Microservices are good, then Nanoservices must be
even better?Why not one-liner services?
Nano Services
Unless we have a very 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
Microservices are valuable
The value of a microservice must exceed the cost of building &
operating it.Microservices entails costs for serialization, deserialization, security,
communication, maintenance, configuration, deployment, monitoring, etc.
Too small services
With too small services there’s a big risk that what’s left of coherence goes out the window and we get:• Communication-related and Layered coupling
– E.g. Logic and persistence are not the same service
• Temporal coupling – Our service can not operate if it is unable to communicate with
the services it depends upon
• Behavioral coupling– Our services assume behaviors with regards to what and who.– The sender/client determines what to do and knows something
about how the receiver/server should satisfy the request
Microservices == distributed objects?
Service star chart
Service Dependencies
Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
All of this means that we need to take care of how we design our service
boundaries
Guidance can e.g. 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
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 / services2. How do we identify our data 3. How do we communicate between
our services
1. How do we split our data / services
Data must be collected in pieces called entities. These entities should be limited in size (but not smaller), so that, after a transaction they are consistent.
Rule of thumb: One transaction involves only one
entity.
What can we learn from DDD
DDD has a similar concept called Aggregate
Aggregates
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.
• External objects hold references to the root • Aggregates only refer to other aggregates by
identity (their id)
Motivation:Control invariants and consistency through the aggregate root.Enables: Loading schemes, coarse grained locking and…
Ensuring consistency & transactional boundaries for Distributed scenarios
Root
Aggregate is another name for an Entity
Pat Hellands “Entity” is the same as DDD’s “Aggregate” concept
By adopting DDD’s terminology we gain a richer vocabulary:• Entity• Value Object• Aggregate
The smallest service
Would be responsible for all logic and data related to a
single Aggregate
Why?
Because consistency can only be guaranteed with in an Aggregate It cannot span aggregates due to lack of coordinating transactions
Example of bad aggregate boundaries
In this case we can fix it
All use cases shows that LegalEntity and Address are created and delete together
Parent - Child
An improved aggregate design
Address turned out to NOT be
an Entity
LegalEntity is an Entity and forms the Root of our LegalEntity aggregate
This gives us this rule of thumb
1 use case = 1 transaction = 1 aggregate
With this improved design
Client that wants to use our LegalEntity
ServiceLegalEntity Service
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
We still haven’t conquered the temporal coupling
problem
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?
What about using RPC/REST/…?
We can just make it async or?
Change Address Response
Consumer
Change Address RequestProvider
RPC or Request/Response - Synchronous 2 way communicationRemote Procedure Call
Request/Reply – Asynchronous 2 way communication
Consumer Provider
Change Address Request Change Address
Request
Change Address Reply
Change Address Reply
Request Channel
ReplyChannel
VS.
Synchronous Remote Calls can lower our Fault tolerance
• When servers crashes• When databases are down• When deadlocks occurs in the database
– Do you retry?
With synchronous RPC style Services interaction we can easily loose business data unless we use an Orchestration engine or find another way to achieve call/retry semantics, combined with compensations and lifecycle handling.
Note: Automatic retry of calls only works if our Service operations are idempotent.
Also remember: REST isn’t magic!
Also, what’s less fat – XML or JSON?
• They’re equally slim and fast!• http://balisage.net/Proceedings/
vol10/html/Lee01/BalisageVol10-Lee01.html
RPC and Distributed computing
• As soon as a service request/response calls to another service across the network we must adhere to the laws of distributed computing*.– Reliability, Latency, Bandwidth,
Transportation costs, Security
• If the other services is not available then my service cannot conduct its business, which minimizes my services autonomy
* See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the 8 fallacies of distributed computing
Service autonomy
Service B
Service C
Service A
System X
Service A
System Y
Service B
Service C
System X
Slow/unreliable networkDifferent SLASlow system
A distributed system is one where a machine I’ve never heard of can cause my program to fail.
— Leslie Lamport
Availability goes down(without additional instances of each service)
Service A
Service B
Service C
Availability: 99% Availability: 99% Availability: 99%
Combined availability: 97%
Decide if you can live with the consequences of coupling services to each other using Request/Response
Different situations – different tradeoffs
To break things up
We need to understand our business and its processes
-How is data flowing?
In order to build the right boundaries
Claim
Most of us are trained to think in Entities and Structural models and this is where we get our selves into trouble.
We create big entangled models and forgetabout model boundaries and different consistency level
requirements!
The mental capacity required to understand big domain models is
huge
Many perspectives on dataOnline Retail System
Product
Unit PricePromotional PricePromotion End Date
Stock Keeping Unit (SKU)Quantity On Hand (QOH)Location Code
PriceQuantity OrderedName
The lifecycle of the data is VERY important!
Customer
Pricing
Inventory
Sales
Management Reporting
Different perspectives on entities
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.
BillingBounded Context
Product Catalogue
Bounded Context
Shipping Bounded Context
Sales Bounded Context
Inventory Bounded Context
PricingBounded Context
Retail domain split into a Macro architecture
These splits should be fairly small (but not too small)
and share as little as possible with each other
Sales Pricing InventoryShipping
✕ ✕ ✕
What’s a macro architecture
• It’s the static/stable(r) parts of your architecture –Which are very costly to refactor and
change
• Closely aligns business capabilities / bounded contexts with services
DDD doesn’t enforce problem domain and solution
domain alignment for Bounded Contexts
Which is why I prefer to use the term Business
Capability
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
Don’t split into services too early
Cross boundary refactoring is costly
So what is a Service?
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
• 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
Does a Service own its UI?
Degrees of coupling
UI
UI
Service
ServiceData
Data Events
Events
If we want to decouple our services as much as possible
then we need to look towards Composite UI’s
andEvents
What’s a Composite UI
A Composite UI is a way to allow different services to participate in the 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
Composite UI’s require that the Service owns its
UI
A Service contains all parts related to it
in order to minimize coupling to other services
DB Schema
Domain Services
Application Services(MessageHandlers)
Aggregates, Entities,
Value Objects, Events
Integration
Endpoints (REST, SOAP,
Pub/Sub)
User Interface
Business-capability/Bounded-Context/Service
Composite UI’sRetail System
Sales Pricing Inventory
Web/Applicationtier
Background servertier
Storage tier
Composite UI
UI LayeredApplicationData Access
Layer
Read m
odel
Wri
te m
odel
✕ ✕
Remember
Layers !=
Tiers
No synchronous
communication between sub
domains – ONLY
asynchronous Events
Composite UI - exampleContext:
Book ISBN-10 0-321-83457-7
Composite UI - examplePage Context:
{ type: Book, id: ISBN-10 0-321-83457-7 }
ImageServiceBookService
ReviewService
PriceService
InventoryService
OthersAlsoBoughtService
PriceService
ReviewService
BookService
ImageService
BookService
Composite UI - HTML
#DIV – Book:Reviews
#DIV – Book:Image
#DIV – Book:TitleAndAuthor
#DIV – Book:Pricing
#DIV – Book:Availability
#DIV - Header
#DIV - Body
Conceptual View
The Service owns it UI in all Contexts and for all Composite UI’s
Not just for HTML clients
Why?
Because of System/Application
boundaries cross Business Capabilities
Physical service view
Application X Application Y
UI
Service A
UI
Service B
UI
Service B
UI
Service C
UI
Service C
Data Cach
e
Service A
AppServic
e
Service C
Process
Handler
Service B
Domain
LogicData
Access
Service B
Domain
Data Acces
Service C
Data Cach
e
Service B
Data Cach
e
Service C
Service deployment
• Many services can be deployed in the same system/application/process– Process boundary is a physical boundary– A Service is a logical boundary
• Service deployment is not restricted to tiers– Part of service A and B can be deployed to the Web tier– And 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
systems– i.e. Systems and services are not the same and does not share
the same boundaries• Many services can be deployed to the same server• Multiple services can be deployed to the same page (service
mashup)• Multiple services can cooperate to fulfill a service (e.g. a workflow
or a business process)
A service needs to be deployed everywhere its data is needed
Invoice Composite UI example
InvoiceHeader
Order:ShippingInfo
Invoice:InvoiceNoInvoice:
Data and Due date
Order:RelationInformation
Ord
er:
Item
-Qty
Pro
du
ct:
Item 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
So where does that leave microservices?
Service implementation
• A Service represents a logical 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
Service
Service Microservice
1..*
Is implemented by
A Service is the technical authority of a specific Business Capabilitye.g. Sales, Shipping, Billing
Services are the implementation of business processes.Business processes can span multiple services, but there will always be a single service that is the actual authority on the business process.
Service
Service Microservice
1..*
Is implemented by
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
Also known as Autonomous Components
Microservices are logical deployable units
That doesn’t mean they HAVE to be deployed individually.
Design for DistributionBut take advantage of locality
Services are the corner stone
• We talk in terms of services, business capabilities and the processes/usecases they support
• Microservices are an implementation detail• Microservices are much less stable (which is a
good thing – it means they’re easier to replace) • A microservice in one service can subscribe to
events from another Service or call operations on another Service (which again is implemented/supported by an internal microservice)
Coupling matrix*
* Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/
Behavioral coupling
Temporalcoupling
Low High
Low
High
Event oriented Command oriented
Emergency services Distributed 3 layer
Using Business Events to drive Business Processes
Sales Service
Shipping
Billing
Sales
CustomersB
us
Online Ordering System
Web Shop(Composite
UI)
Billing Service
Shipping ServiceOrder
Accepted
Event
AcceptOrderCommand
The sales fulfillment processing can now begin…
Cascading events give rise to business processes
Event driven process
Sales ServiceOrder
Accepted
Billing Service
Orderfulfilment ServiceProcess Manager/
Saga/Orchestration-Engine
Shipping Service
Online Ordering System
Bus
Order Accepte
d
Order Accepte
d
Customer Billed
Customer Billed
OrderAuthoriz
ed
OrderAuthoriz
ed
Works as a Finite State Machine
(WorkFlow)handling the life cycle of Shipping
and thereby forms a very central new
Aggregate in the System
This form of architecture is called anEvent Driven Architecture (EDA)
SOA and EDA are two sides of the same coin
SOA Analysis Patterns
How do we determine service boundaries?
A department is a physical construction
and not a good candidate for a
service boundary anymore
Departments have overlapping
responsibilities that don’t align with
business capabilitiesanymore
A department uses application(s) which
uses multiple services
(mashup/composite)
So how do we determine service
boundaries?
Recommendation: Divide and concour
• Start from the outside and model business capabilities
• Design your Macro Architecture around this
• Determine communication and interaction principles
• Ensure common monitoring and logging facilities
How do I model?
For example: Event Storming
• Event Storming is a fun way of driving your analysis from the outside and quickly explore complex business domains (in hours instead of days/weeks).
SOA was about business agility through IT/Business
alignment
Final thoughts
Doing SOA require maturity
• Organizational maturity
Be aware of Conways Law“organizations which design
systems ... are constrained to produce designs which are copies of the
communication structures of these organizations”
Teams are typically aligned with Systems/Projects and NOT with Services as I
believe they should
Which require maturity
• Organizational maturity• Technical/operations maturity* –
DevOps– Build– Test– Deployment–Monitoring– Etc.
* See: http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
We need a strong foundation for development to achieve this
Alig
nmen
tH
ighl
y al
igne
dLe
ss a
ligne
d
EffciencyLess effective Highly effective
”Maintenance Zone” ”Well-Oiled IT”
”Alignment Trap”
11%
74%
7%
8%
+13
-14
-2 -15
+11
-6
+35
”IT enabled Growth”
% of the 504 respondents % difference compared to the overall averages IT spending
Combined yearly growth-rate over a 3 year period
Sour
ce: B
ain
Anal
ysis
+0
So are Microservices the future?
Gartners Pace layered Application strategy:
• Systems of Record — Established packaged applications or legacy home-grown systems that support core transaction processing and manage the organization's critical master data. The rate of change is low, because the processes are well-established, common to most organizations, and often are subject to regulatory requirements.
• Systems of Differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium lifecycle (one to three years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements.
• Systems of Innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short lifecycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies.
• "These layers correspond to the notion of business leaders having common ideas, different ideas, and new ideas,"
Conclusions
• In my opinion Microservices is a SOA delivery model• Focus should be on aligning Services to Business
Capabilities– Make service as small as possible and as big as
necessary• Beware of the coupling matrix – avoid synchronous
communication between services unless you’re ready to pay the price
• Implement Services as a set of Microservices that are logically deployable and divide them along transactional boundaries
• Be aware of the requirements for organizational, business and technical maturity
• If we can get there then I believe Microservices will be able to help us achieve a some of what SOA promised, but due to different factors rarely delivered
Thank you
Jeppe Cramon – [email protected]
www.tigerteam.dk www.tigerteam.dk/category/soa/
www.tigerteam.dk/category/soa/microservices/
Twitter: @tigerteamdk and @jeppec
Want to learn more?Contact me for training and mentoring