Microservices are getting a lot of hype these days and traditional SOA is seen as deprecated. However, microservices architecture is not the best solution for everything, so this presentation contains the considerations that need to be made to be ready for microservices and shows where they are applicable or not.

2. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
SAY NO TO MICROSERVICES!
2
NLOUG Tech Experience – June 8, 2018

3. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
ABOUT ME
• Lykle Thijssen
• Principal Architect
• Scrum Master
• Working for eProseed
• Process & Integration
Twitter: @lyklethijssen
Blog: http://undertheredcloud.blogspot.com
3

4. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
AGENDA
What are Microservices?
Why do we want Microservices?
Are you ready for Microservices?
When are Microservices not applicable?
What can we learn from Microservices?
Summary
1
2
3
4
5
4
6

5. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
“Microservices are loosely coupled service
oriented architecture with bounded
contexts” – Adrian Cockcroft
Microservices are:
• Scalable
• Polyglot
• Self-contained
• Owning their own data
• Choreographed, not orchestrated
• Not the answer to everything
• Interpreted in many ways
5
WHAT ARE MICROSERVICES?

6. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
WHY DO WE WANT MICROSERVICES?
6
Monoliths cause chaos and destruction, because:
1. They are tightly coupled and inflexible
2. They are hard to maintain
3. They are hard to break down
Introduce SOA. Now our monoliths are:
1. Semi-loosely coupled and inflexible
2. Very hard to maintain
3. Still hard to break down
Will Microservices deliver us from evil?

7. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
• Because we are disappointed with SOA
• Because we want scalability
• Because we want loosely-coupled services
• Because we want to deliver faster
7
WHY DO WE WANT MICROSERVICES?

8. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
ARE YOU READY FOR MICROSERVICES?
8
Microservices require a lot to make the most out of them:
1. DevOps/Agile Culture
2. Continuous Delivery
3. Containers
4. APIs
5. Cloud
6. Programming Skills
7. Event Driven Architecture
8. Distributed Data

9. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
• Conway’s Law
• Unclear Domains
• Sloppy Coding
• Organizational Problems
• Operations: Monitoring & Management
9
ARE YOU READY FOR MICROSERVICES?

10. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
WHEN ARE MICROSERVICES NOT APPLICABLE?
10
“So my primary guideline would be
don't even consider microservices
unless you have a system that's too
complex to manage as a monolith.
The majority of software systems should be built as a
single monolithic applications.
Do pay attention to good modularity
within that monolith, but don't try to
separate it into separate services.”
Martin Fowler

11. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
CAN WE HAVE BOTH?
11
Typically, enterprises have two types of systems:
1. Systems of Record
2. 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.

12. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
WHAT CAN WE LEARN FROM MICROSERVICES?
12
1. Standards of 2011 no longer apply
2. 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

13. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
WHAT CAN WE LEARN FROM MICROSERVICES?
13
1. Standards of 2011 no longer apply
2. 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

14. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
WHAT CAN WE LEARN FROM MICROSERVICES?
14
1. Standards of 2011 no longer apply
2. 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

15. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
WHAT CAN WE LEARN FROM MICROSERVICES?
15
1. Standards of 2011 no longer apply
2. 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

16. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
WHAT CAN WE LEARN FROM MICROSERVICES?
16
1. Standards of 2011 no longer apply
2. 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

17. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
WHAT CAN WE LEARN FROM MICROSERVICES?
17
1. Standards of 2011 no longer apply
2. 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

18. Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential
SUMMARY
18
• 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