Downloaded 12 times
Uploaded byMallika Iyer
Cloud anti-patterns
The document discusses various "cloud anti-patterns" or common mistakes made when developing cloud-native applications and microservices. Some of the anti-patterns covered include ignoring cloud-native platforms, focusing too much on risk mitigation over innovation, creating monolithic microservices, prematurely decomposing services, failing to implement proper APIs, service discovery, and fault tolerance, trying to rewrite entire monolithic applications at once instead of gradually, failing to implement proper logging and tracing across services, and having siloed search capabilities. The presentation emphasizes the importance of using cloud-native platforms, gradual refactoring, clear APIs, service discovery, fault tolerance patterns, logging, tracing, test automation, and unified search.
More Related Content
Cloud anti-patterns
- 1.
- 2. whoami Mallika Iyer CloudFoundry Specialist @ Pivotal Twitter @cloudfoundryart LinkedIn in/imallika @cloudfoundryart
- 3. Certified TRX trainer| Fitness junkie | German Shepherd Fanatic @cloudfoundryart
- 4.
- 5. Agenda • Cloud Anti-Patterns •#1 Ignoring the Sweet Spot • #2 Risk Mitigation v/s Innovation • #3 The Monolithic Microservice • #4 The Microservice Smell • #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 asoftware 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 isan isolated and lightweight environment that can run a service or application without reliance on a separate operating system eg: Docker, Warden, Garden… @cloudfoundryart
- 9. Continuous Integration The practiceof merging all developer working copies to a shared mainline several times a day @cloudfoundryart
- 10. Continuous Delivery An approachwhere teams produce valuable software in short cycles and release the software reliably, predictably and at times, automatically eg: Concourse, Jenkins, Bamboo… @cloudfoundryart
- 11.
- 12. #1 Finding thesweet spot Sweet spot cnp CNP= Cloud Native Platform as a Service like Cloud Foundry @cloudfoundryart
- 13. #1 Ignoring thesweet spot @cloudfoundryart
- 14. #1 Ignoring thesweet 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 Mitigationv/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 coolfeatures tomorrow!! No more github for you… Code Ninjas/Developers Special Ops/Operations @cloudfoundryart
- 17. #2 Risk Mitigationv/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 MonolithicMicroservice • 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 MicroserviceSmell 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 servicesmells of too many beers and sweat… @cloudfoundryart
- 21. #4 The MicroserviceSmell • Lesson Learned: • DON’T BE IN A HURRY to GO MICRO – Let it be gradual! @cloudfoundryart
- 22. #5 Ignoring the3 Musketeers APIs Service Registry & Discovery Fault Tolerance @cloudfoundryart
- 23. #5 The 3Musketeers : 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 3Musketeers : 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 3Musketeers : 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 microservicepush & shove @cloudfoundryart
- 29. #7 The microservicepush & 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 Pipelinesare 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 ignorethe 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 – Know When to 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 friends • 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
- #18 Elaborate on visibility into all development activity
- #31 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’
- #32 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