say no to microservices
TRANSCRIPT
![Page 1: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/1.jpg)
![Page 2: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/2.jpg)
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”
![Page 3: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/3.jpg)
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
![Page 4: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/4.jpg)
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
![Page 5: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/5.jpg)
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?
![Page 6: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/6.jpg)
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
![Page 7: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/7.jpg)
Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | Confidential7
THE HYPE
Microservices
Traditional SOA
![Page 8: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/8.jpg)
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???
![Page 9: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/9.jpg)
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
![Page 10: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/10.jpg)
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.
![Page 11: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/11.jpg)
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
![Page 12: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/12.jpg)
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
![Page 13: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/13.jpg)
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
![Page 14: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/14.jpg)
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
![Page 15: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/15.jpg)
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
![Page 16: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/16.jpg)
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
![Page 17: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/17.jpg)
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
![Page 18: Say no to microservices](https://reader035.vdocuments.us/reader035/viewer/2022062310/58d1296a1a28abe3298b4c87/html5/thumbnails/18.jpg)