Date post: | 21-Mar-2017 |
Category: |
Technology |
Upload: | lykle-thijssen |
View: | 120 times |
Download: | 0 times |
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