Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Surviving microservices

110 views

Published on

With microservices gone mainstream a few years ago, many organizations have now adopted them; even though all are paying the price in terms of training, solution complexity and operational costs, few are reaping the promised benefits.
Lower velocity, quality and performance issues, along with an overall lack of visibility are what we hear about most often.
In this session, working from our experience as advisors to software development teams, we’ll walk you through some of the symptoms you might experience, their possible causes and some potential solutions.

Published in: Software
  • Be the first to comment

Surviving microservices

  1. 1. OptionFactory Surviving Microservices Challenges and risks during adoption, and what to look for beyond
  2. 2. Francesco Degrassi Enthusiastic yet pragmatic Lean Software Developer. Uppish and cynical nihilist from time to time.
  3. 3. OptionFactory ■ Lean Software Development ● Continuous Delivery - High availability - Scale-up ● Security sensitive & high uncertainty domains ■ Software Architecture Consultancy ● Technical Due Diligence
  4. 4. So you adopted microservices... ● After several years, microservices have gone mainstream now ● All adopters are paying the price in terms of ○ training requirements ○ solution complexity ○ operational costs ● Few are reaping the promised benefits
  5. 5. What are the pain points? Implementing new features takes forever… Lower velocity We’re receiving a lot of complaints for lost documents High defects rate The import process takes hours! Performance issues It is really hard to understand what is going on. Lack of visibility Lack of benefits Side effects
  6. 6. What are microservices anyway? “[...] an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. -- James Lewis and Martin Fowler (2014)
  7. 7. What are microservices anyway? ● Modeling ○ Components organized around Business Capabilities ○ Evolutionary Design ● Organization ○ Products not Projects ○ Infrastructure Automation ● Technical ○ Componentization via Services ○ Smart endpoints and dumb pipes ○ Decentralized Governance ○ Decentralized Data Management ○ Design for failure
  8. 8. What is the trade-off? How microservices should help: ● Enabling Technology diversity (adopt the best tool for each job) ● Independent component scaling ● Enforced module boundaries ● Scale-up development by decoupling teams The price: ● Managing all the technology diversity ● Distribution: new failure modes require handling ● Eventual consistency ● Operational Complexity ● High training requirements ● High impact of design mistakes (becoming architectural ones)
  9. 9. First issue: (Lack of) Solution fit
  10. 10. (Lack of) solution fit (1) Most organizations don’t have such simple business logic, huge scalability requirements, risk appetite of Netflix, Twitter, Instagram.
  11. 11. (Lack of) solution fit (2) Netflix (Most of) us Microservices impact Number & complexity of operations Few, simple Many, complex Emerging requirements harder to accomodate, hard to model, refactoring difficult Coupling of components Low High Complexity moved in inter-service communication, which is the hardest to monitor and inspect Concurrent users Millions Hundreds / Thousands Unnecessary complexity Need to scale individual components Definitely, e.g. transcoding, streaming vs browsing catalog, subscription Possibly (needs hard data) Unnecessary complexity Teams, developers Tens, hundreds Few, dozens No advantages Ops resources Abundant Low to average Inability to cope with increased complexity Team skill and training budget Very high Average Risk of implementation mistakes, inability to spot potential issues timely Risk appetite Higher (seeks technical competitive advantage) Lower Higher risk
  12. 12. Second issue: Implementation mistakes
  13. 13. ● Failure to address organizational change ○ Ops and security requirements not considered in development ○ Lack of visibility of ops team on mapping of business processes over the entire platform Implementation mistakes (1)
  14. 14. ● Modularization: ○ services should map to bounded contexts, but often are too fine-grained ○ services should expose transactional business operations ● API granularity: network calls are expensive; too fine-grained APIs are unsustainable ○ wrong perception of remoting cost, possibly due to it not being hidden by middleware ○ mistakes in modularization can make services too interdependent ○ failure to adapt when splitting a service out Implementation mistakes (2)
  15. 15. ● Encapsulation: data should only be exposed through the service API ○ databases shared by multiple services are a huge red flag ● Coupling: services, in general, should not share code with one another ○ deployment independendence depends on it ○ shared model libraries are a common mistake, indicative of an erroneous interpretation of microservices ● Complexity moving into interactions: ○ implicit state in asynchronous messaging ○ hardest thing to inspect and monitor Implementation mistakes (3)
  16. 16. Third issue: Failure to address impact on NFRs
  17. 17. ● Operability ○ Monitoring infrastructure ○ Infrastructure and configuration management ○ Deployment automation ○ Service Discovery ○ Tracing of calls through multiple systems ○ Logging context and centralized infrastructure Failure to address impact on NFRs
  18. 18. ● Correctness, Performance, Scalability: ○ Skillset, Training, on e.g.: ■ DDD ■ Distributed systems ■ CI / CD, infrastructure management ■ Tooling ○ Development environment ● Availability, Resilience, Integrability, Compatibility ○ API versioning ○ Cater for cascading failure scenarios ○ Compound availability Failure to address impact on NFRs
  19. 19. ● Data integrity, Retention, Durability, Disaster recovery ○ Backups and restores of individual services ● Security ○ Authentication, Access control, Accounting throughout services ○ Integrity and confidentiality of data in transit ● Testability ○ Automation, Infrastructure provisioning Failure to address impact on NFRs
  20. 20. Are there no alternatives? Not at all. Many tenets of microservices can be applied to any other architectures too: ● Teams and components organized around Business Capabilities is (uncommon) common sense ● Evolutionary Design, Cross-functional teams are not specific of microservices at all ● Infrastructure Automation, CI & CD are useful even with a single deployable
  21. 21. A false dichotomy Storefront WebApp Account Service Inventory Service Shipping Service Order Service UI Business logic Data access layer Storefront UI Account Service Inventory Service Shipping Service Order Service Accounts Orders ShipmentsInventory
  22. 22. No exclusive deal here... Benefit Microservices Alternative Strong module boundaries Enforced by architecture (which is hard to change by definition) Responsibility of the team (empowerment) If you need to enforce compliance, you might not afford microservices. Why would you think the same team that built the big ball of mud can design a functional set of microservices? Independent deployment and scaling Possible (but not guaranteed) Possible (opportunistic, by extracting a service) Technology diversity Unconstrained Constrained, but available Scale up development by decoupling teams By service By component / library / service
  23. 23. What now? ● Seek external guidance ○ Assess the state of the project ○ Without preconception ○ Using hard data ● Plan for remediation ○ Addressing NFRs can make the situation manageable short-term ● Avoid sunken cost fallacy ○ Architectural changes, by definition, are hard and costly, but... ○ there is no better time to change course than right now
  24. 24. ● Strive for simplicity ○ What is the simplest thing that could possibly work? ○ Not “is it too complex?” but “is there an actual need for any added complexity?” ● Do not buy into the hype: ○ there’s always a trade-off, make sure it is known and explicit ○ validate one choice at a time ● Make sure agency comes with responsibility ○ beware seagull engineering and CV padding What next time?
  25. 25. Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams “ ” I hope you found this useful
  26. 26. Get in touch https://www.optionfactory.net
  27. 27. Thanks for your time! @EdMcBane fdegrassi@gmail.com francesco.degrassi@optionfactory.net http://www.optionfactory.net

×