DevConf.US 2019 - 3 Pitfalls Everyone Ignores with Microservices
•Download as PPTX, PDF•
1 like•378 views
The daily hype is all around you. Microservices are a necessary step along the path to integration for a digitally successful future for your organization. The choices you’ve got to make don’t preclude the daily work of developing amazing applications. From containers, cloud, multicloud, and beyond, microservices are the core infrastructure ensuring your organization's flexibility in the digital world. Join us for an hour of power, where real life developer experiences are used to highlight the three top lessons we're all learning as we transition our integration infrastructure into modern day microservices. Video recording session: https://youtu.be/il9s8WJYqho Internal google slides: https://docs.google.com/presentation/d/1GcrBo3w3oRfcn2QaOuCg4etv62qO1Ms1CV7UMZ2EHqI
Recommended
Recommended
More Related Content
More from Eric D. Schabell
More from Eric D. Schabell (20)
Recently uploaded
Recently uploaded (20)
DevConf.US 2019 - 3 Pitfalls Everyone Ignores with Microservices
- 1. 3 PITFALLS EVERYONE IGNORES WITH MICROSERVICES Eric D. Schabell Global Technology Evangelist and Portfolio Architect Director @ericschabell Roel Hodzelmans Senior Solution Architect, Benelux @roelhodzelmans DevConf. US 2019, Boston
- 2. ORGANIZATION NOT READY DEFINE MICROSERVICE MICROSERVICES < MONOLITHS #1 #2 #3
- 4. PITFALL #1 Opinion: Traditional siloed organizations coulda-shoulda-woulda transformed before tackling microservices YOUR ORGANIZATION CAN’T HANDLE MICROSERVICES
- 5. It’s Hard!
- 6. PITFALL #2 CAN YOU DEFINE A MICROSERVICE? Opinion: Sceptical developers define small SOA services as microservices
- 8. PITFALL #3 MICROSERVICES < MONOLITHS Opinion: Fast moving monoliths are better than microservices
- 9. ORGANIZATION NOT READY DEFINE MICROSERVICE MICROSERVICES < MONOLITHS #1 #2 #3
- 10. PITFALL (BONUS) DATA, DATA, AND MICROSERVICES Opinion: Developers be warned - are you ready for the distributed data store (or falling back to tightly coupled SOA with shared data store)
- 11. ● Microservices: The Good, The Bad, and The Ugly ● The Death of Microservice Madness in 2018 ● To go or not to go micro: the pros and cons of microservices
- 12. 3 PITFALLS EVERYONE IGNORES WITH MICROSERVICES Eric D. Schabell Global Technology Evangelist and Portfolio Architect Director @ericschabell Roel Hodzelmans Senior Solution Architect, Benelux @roelhodzelmans DevConf. US 2019, Boston THANK YOU
Editor's Notes
- DevConf.US 2019: The daily hype is all around you. Microservices are a necessary step along the path to integration for a digitally successful future for your organization. The choices you’ve got to make don’t preclude the daily work of developing amazing applications. From containers, cloud, multicloud, and beyond, microservices are the core infrastructure ensuring your organization's flexibility in the digital world. Join us for an hour of power, where real life developer experiences are used to highlight the three top lessons we're all learning as we transition our integration infrastructure into modern day microservices.
- This session is about giving you the insights into pitfalls that we see our customers, partners, and contacts stumbling over with they decide to tackle microservices (a cloud-native approach) in their organizations. We provide the top 3 pitfalls; organizational change needed, how you define microservices, and whether microservices are better than monoliths. We’ll even share a few bonus pitfalls at the end, so let’s dive right in.
- Taking you on a ride that started with Red Hat Summit 2018 as a conversational session. We split the room into two groups, sit on the right if you are or have implemented microservices in your organization and sit left if you have not yet but are exploring the idea. We then walked through 3-5 pitfalls and discussions ensued.
- First up, organizations have to be ready to change before microservices will work.
- Think about how monolithic apps have to be divided up and each of the microservices is then owned by a team, that team you treat like a B2B connection. They live on their own release cycles, their own API data, etc. Are you ready for this? (Photo source: http://www.beastrace.co.uk)
- Very true and resonates, talked about quarkus speed lift and shift, stateless, change in organization (devops). It’s often started as a discussion around performance and how to split monoliths. (Photo: free online webfonts)
- The first question comes up every time, usually once the initial strategy planning is completed and a start made on migrating an existing (monolithic) application. “How to approach the performance impact in communications when a monolith gets split up into distributed services (microservices), such as from internal calls to distributed rest api's?” The basis of the question is uncertainty in what’s going to happen once they start decomposing existing monolithic applications in favor of microservices where possible. What we need to understand is that the goal of splitting out these services is to favor deployment speed over API invocation speed. The main reason to split off microservices out of an existing monolith should be to isolate the development of the service within a team completely separate from the application development team. The service engineering team can now operate at their own intervals, deploying changes weekly, daily, or even hourly if a noteworthy CVE is applicable. The penalty for unknown network invocations is the trade off to your monolith’s highly regimented deployment requirements that cause it to move at 2-3 month deployment intervals. Now with microservice teams you can start reacting quicker to the business, competition, and security demands with faster delivery intervals. Equally critical for network invocations is to look closely at how course-grained your network calls become in this new distributed architecture. (Photo: Eric Rolph at English Wikipedia - English Wikipedia)
- Not everything should be a microservice by default. Logic in applications moves to infrastructure when you go to microserivces. (Photo: Burr Sutter)
- This session provided insights into pitfalls that we see our customers, partners, and contacts stumble over with they decide to tackle microservices (a cloud-native approach) in their organizations. We provided the top 3 pitfalls; organizational change needed, how you define microservices, and whether microservices are better than monoliths. We’ll even shared a few bonus pitfalls at the end, so hopefully you won’t have to make the same mistakes in your approach.
- So developers own the decisions and tech, for example, monolith decomposition into new cloud-native microservices means teams of developers own and manage development, testing, patching, CVE fixes, etc all the way to production autonomously from the main applications. Integration layer is nice for microservices to abstract away the handling of stateful information. State discussions are central to the move to microservices for many developers and architects. Following that train of thought leads to questions around how to create a consistent state view using the data sources currently in their architecture. “How to deal with databases backing distributed services so that the state is a single state view in the entire system, (along with how to admin and manage this)?” The best part about this discussion is that a colleague of ours has addressed this quite extensively in a book. Even better, it’s free to download (bit.ly/mono2microdb) and provides a lot of tips. Another option you can look at might be Debezium for smart database change data capturing.
- DevConf.US 2019: The daily hype is all around you. Microservices are a necessary step along the path to integration for a digitally successful future for your organization. The choices you’ve got to make don’t preclude the daily work of developing amazing applications. From containers, cloud, multicloud, and beyond, microservices are the core infrastructure ensuring your organization's flexibility in the digital world. Join us for an hour of power, where real life developer experiences are used to highlight the three top lessons we're all learning as we transition our integration infrastructure into modern day microservices.