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 – jeppe@tigerteam.dk

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