Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential2

ABOUT ME

• Lykle Thijssen

• Technical Process & Integration Architect

• Over 10 years of experience

• Netherlands, Turkey and Australia

Twitter: @lyklethijssenBlog: http://undertheredcloud.blogspot.com

“Lykle is a BPM gun”

“Lykle is a SOA genius”

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential3

SAY NO TO MICROSERVICES!

OUGN Vårseminar 2017 - Friday, 10-03-2017, 16:00-16:45

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential4

SAY NO TO MICROSERVICES!

The Evil Monolith

Microservices

Thresholds & Choices

What Can We Learn?

Summary – A Hybrid Approach

1

2

3

4

5

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential5

THE EVIL MONOLITHMonoliths cause chaos and destruction, because:1. They are tightly coupled and inflexible2. They are hard to maintain3. They are hard to break down

Introduce SOA. Now our monoliths are:4. Semi-loosely coupled and inflexible5. Very hard to maintain6. Still hard to break down

Will Microservices deliver us from evil?

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential6

MICROSERVICES ARE AWESOME

Microservices are fighting many of the problems related to monoliths:1. Microservices don’t have terrible dependencies2. Microservices are relatively easy to maintain3. Microservices have clear boundaries4. Microservices scale well5. Teams are easy to organize around microservices6. Ownership of Microservices is clear

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential7

THE HYPE

Microservices

Traditional SOA

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential8

…BUT THEY HAVE DOWNSIDES TOO

Microservices require a lot:1. DevOps culture2. Continuous Delivery3. Containers4. APIs5. Cloud6. Programming skills7. Event Driven Architecture8. Where is my request???

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential9

THE COMPLEXITY THRESHOLD“So my primary guideline would bedon't even consider microservicesunless you have a system that's toocomplex to manage as a monolith.

The majority of software systems should be built as asingle monolithic applications.

Do pay attention to good modularitywithin that monolith, but don't try toseparate it into separate services.”

Martin Fowler

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential10

CAN WE HAVE BOTH?

Typically, enterprises have two types of systems:1. Systems of Record2. System of Innovation

For the first, a more traditional approach is appropriate.For the second, microservices can be a great idea.

Generally, systems that are highly volatile benefit the most from the flexibility of Microservices,while systems that have high stability benefit the most from the reusability within a Monolith.

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential11

WHAT CAN WE LEARN FROM MICROSERVICES?

1. Standards of 2011 no longer apply2. Scaling:

• Domains• Partitions• Work managers

3. Performance• Why so stateful?• Do we need that many layers?

4. Dependencies• CDM• Orchestration vs choreography

5. Purpose• Granularity• Bounded context

6. API awareness

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential12

WHAT CAN WE LEARN FROM MICROSERVICES?

1. Standards of 2011 no longer apply2. Scaling:

• Domains• Partitions• Work managers

3. Performance• Why so stateful?• Do we need that many layers?

4. Dependencies• CDM• Orchestration vs choreography

5. Purpose• Granularity• Bounded context

6. API awareness

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential13

WHAT CAN WE LEARN FROM MICROSERVICES?

1. Standards of 2011 no longer apply2. Scaling:

• Domains• Partitions• Work managers

3. Performance• Why so stateful?• Do we need that many layers?

4. Dependencies• CDM• Orchestration vs choreography

5. Purpose• Granularity• Bounded context

6. API awareness

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential14

WHAT CAN WE LEARN FROM MICROSERVICES?

1. Standards of 2011 no longer apply2. Scaling:

• Domains• Partitions• Work managers

3. Performance• Why so stateful?• Do we need that many layers?

4. Dependencies• CDM• Orchestration vs choreography

5. Purpose• Granularity• Bounded context

6. API awareness

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential15

WHAT CAN WE LEARN FROM MICROSERVICES?

1. Standards of 2011 no longer apply2. Scaling:

• Domains• Partitions• Work managers

3. Performance• Why so stateful?• Do we need that many layers?

4. Dependencies• CDM• Orchestration vs choreography

5. Purpose• Granularity• Bounded context

6. API awareness

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential16

WHAT CAN WE LEARN FROM MICROSERVICES?

1. Standards of 2011 no longer apply2. Scaling:

• Domains• Partitions• Work managers

3. Performance• Why so stateful?• Do we need that many layers?

4. Dependencies• CDM• Orchestration vs choreography

5. Purpose• Granularity• Bounded context

6. API awareness

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential17

SUMMARY – A HYBRID APPROACH

• SOA Monoliths can be highly problematic• Don’t use Microservices prematurely• Take a domain driven approach to SOA• Keep modernizing your architecture

The eternal struggle: reusability vs flexibility