Cloud anti-patterns
•Download as PPTX, PDF•
5 likes•2,707 views
The document discusses various "cloud anti-patterns" or common mistakes made when developing cloud-native applications and microservices. It identifies 9 anti-patterns: 1) ignoring cloud platforms like Cloud Foundry, 2) prioritizing risk mitigation over innovation, 3) creating monolithic microservices, 4) prematurely decomposing services, 5) ignoring APIs, service discovery, and fault tolerance, 6) trying to rewrite entire monoliths at once, 7) not having proper logging and tracing for microservices, 8) not using continuous integration/delivery pipelines, and 9) having siloed search capabilities. The document provides explanations and recommendations for addressing each anti-pattern.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (13)
Similar to Cloud anti-patterns
Similar to Cloud anti-patterns (20)
Recently uploaded
Recently uploaded (20)
Cloud anti-patterns
- 2. whoami Mallika Iyer Cloud Foundry Specialist @ Pivotal Twitter @cloudfoundryart LinkedIn in/imallika @cloudfoundryart
- 3. Certified TRX trainer | Fitness junkie | German Shepherd Fanatic @cloudfoundryart
- 5. Agenda • Cloud Anti-Patterns • #1 Ignoring the Sweet Spot • #2 Risk Mitigation v/s Innovation • #3 The Monolithic Microservice • #4 The Logic Leak • #5 The 3 musketeers of cloud-native apps • #6 Boil tea, not the ocean • #7 The micro-service push & shove • #8 Build Pipelines are your BFFs • #9 Siloed Search • Summary @cloudfoundryart
- 6. Before we begin… • Let’s define things! @cloudfoundryart
- 7. Microservices Microservices is a software architecture design pattern, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, autonomous, highly decoupled, work together and focus on doing a small task. @cloudfoundryart
- 8. Containers A container is an isolated and lightweight environment that can run a service or application without reliance on a separate operating system eg: Docker, Warden, Garden, Rocket… @cloudfoundryart
- 9. Continuous Integration The practice of merging all developer working copies to a shared mainline several times a day @cloudfoundryart
- 10. Continuous Delivery An approach where teams produce valuable software in short cycles and release the software reliably, predictably and at times, automatically eg: Concourse, Jenkins, Bamboo… @cloudfoundryart
- 12. #1 Finding the sweet spot Sweet spot cnp CNP= Cloud Native Platform as a Service like Cloud Foundry @cloudfoundryart
- 13. #1 Ignoring the sweet spot @cloudfoundryart
- 14. #1 Ignoring the sweet spot If I close my eyes it doesn’t exist… cnp CNP= Cloud Native Platform as a Service like Cloud Foundry @cloudfoundryart
- 15. #2 Risk Mitigation v/s Innovation • Problem • Need to innovate • Want to release cool features to production NOW • Ops simply cannot support this because of uptime, HA, DR and other concerns • Result • Everyone is unhappy • Business is angry • Everyone blames IT-Ops • It’s not really fair... @cloudfoundryart
- 16. Hai ya! New cool features tomorrow!! No more github for you… Code Ninjas/Developers Special Ops/Operations @cloudfoundryart
- 17. #2 Risk Mitigation v/s Innovation • Solution • You don’t have to choose! • Select the right platform • Something like Cloud Foundry… • Self-healing • Application distribution across Availability Zones • Application resurrection • Self-monitoring and resurrection • VM recreation • Inherently HA • Visibility into all development activity @cloudfoundryart
- 18. #3 The monolithic microservice • Temptation: • Grouping similar microservices in the same container • Problem: • Unable to scale • Unable to deploy changes • The monolithic creep • Solution: • ONE Micro Service Per container @cloudfoundryart
- 19. #4 The Logic Leak Temptation: Premature decomposition of microservices • Problem: • Company ‘Amazing-Stuff!!!’ has a product called ‘Awesome’ • They plan to create a new offering called ‘Super- Awesome’ • Similarities between the 2 products cause them to split microservices and consume them across both products • ‘Super-Awesome’ really KICKS off…takes a life of its own • Causing the developers to rewrite the microservices for the new product @cloudfoundryart
- 20. This micro service smells of too many beers and sweat… @cloudfoundryart
- 21. #4 The Logic Leak • Lesson Learned: • DON’T BE IN A HURRY to GO MICRO – Let it be gradual! @cloudfoundryart
- 22. #5 Ignoring the 3 Musketeers APIs Service Registry & Discovery Fault Tolerance @cloudfoundryart
- 23. #5 The 3 Musketeers : APIs Problem • 100+ microservices need to talk to each other • Many are changing simultaneously • And they are in about 5 different languages Solution • Use language- independent APIs and API interfaces like swagger.io • Honor the contract between microservices • Interactively document the API and integrate it with your project tracker @cloudfoundryart
- 24. #5 The 3 Musketeers : Service Discovery & Registry Problem • 100+ microservices are now talking to each other… • Every time a new microservice is added, all the others must manually be informed of its presence Solution • Use a service discovery and registry tool like Eureka (part of Spring Cloud Services) • Automate Service Discovery and Registration • No errors at scale @cloudfoundryart
- 25. #5 The 3 Musketeers : Fault Tolerance Problem • A couple of internal services that feed your application fail for some reason • The failure has now propagated to the API • Your customers now experience a disruption in service causing $$$$$$ loss in revenue Solution • Use a circuit breaker like Hystrix (part of Spring Cloud Services) • Isolate the point of origin of the failure • Contain the error and prevent cascading failure • Graceful degradation of service while we work furiously behind the scenes to fix it @cloudfoundryart
- 26. #6 Boil Tea, Not the Ocean • Problem: • The temptation to lift and shift a monolith • Trying to rewrite the entire application • Too much, too fast, too soon • Challenges: • Unrealistic • Might not even be possible due to IaaS restrictions • Moving a problem from a place you (kind of) understand to a place you absolutely don’t • Result: • The Cloud Native Initiative lives on PowerPoint for eternity @cloudfoundryart
- 27. #6 Boil Tea, Not the Ocean • Solution: • Identify a function that can be rebuilt • Something that would benefit from innovation • Something that is hard to modify • Something new • With minimum impact on the rest of the monolith • Clearly outline the technical debt associated with that function • Rewrite following best practices for microservices • Start really…really small • Or really…really new @cloudfoundryart
- 28. #7 The microservice push & shove @cloudfoundryart
- 29. #7 The microservice push & shove • Problem: • In a distributed application architecture, how do you figure out where to look? • Solution: • It doesn’t have to be that way… • Logging is your friend… • Pivotal Ops Metrics • New Relic, App Dynamics, Sumo Logic, ELK, Splunk…and so many more • Dynamic Tracing is your friend… • Explore Zipkin • Application Performance Monitoring tools… • New Relic, Drip Stat… @cloudfoundryart
- 30. #8 Build Pipelines are your BFFs KEEP CALM AND HUG YOUR BUILD PIPELINES @cloudfoundryart
- 31. #9 Siloed Search • Problem: • Users cannot perform unified search across data silos • Search data is stale @cloudfoundryart
- 32. #9 Cloud-Native Federated Search Solution: • Create an Enterprise-Wide Data Bus with RabbitMQ or Kafka • Multiple microservices can asynchronously publish interesting data points • Search Event Listeners will listen to these events and update the search indices in real-time • Basically going from a data push model to Real- time Data Pull Model @cloudfoundryart
- 33. Summary • Don’t ignore the sweet spot – A Cloud Native Platform as a Service like Cloud Foundry is your best friend • You don’t have to choose between Risk Mitigation and Innovation – A Cloud Native Platform is your ally • The Monolithic Micro service – don’t be THAT guy • Be wary of the micro service smells – Don’t Repeat Yourself • The 3 Musketeers are your best friends: APIs(swagger.io), Service Registry & Discovery (Eureka – Spring Cloud Services), Fault Tolerance (Hystrix-Spring Cloud Services) @cloudfoundryart
- 34. Summary • Boil tea, not the ocean – Start small, start new • Microservices need not be murder mysteries – Logging and Tracing are your BFFs • Automation is your friend – Keep calm and hug your build pipelines across environments • Siloed Search will ruin your customer experience – Search should NEVER been an afterthought @cloudfoundryart
- 35. Thank you! Mallika Iyer @ Pivotal Twitter @cloudfoundryart LinkedIn in/imallika
Editor's Notes
- Elaborate on visibility into all development activity
- The goal is to deliver tested, mature software after every development iteration, without being a burden on Ops – Ops needs to be the invisible glue that is holding this together, hardening it constantly with every change, every automation, and the focus should be on building great software, not worry about HOW to deploy it. If you get to that point, Ops has most definitely ‘arrived’
- When you have a lot of data, and accuracy and relevance of the search results are important to you – the likelihood is that you will use large scale search technologies like Solr. This was a problem I saw at one of the largest users of Solr in the world And a lot of microservices simultaneously updating the data – you start to get search silos , and stale data is the result How do you get around this