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.

Anti fragile and microservice architecture

4,512 views

Published on

The good old three tiers architecture is not able to cope with current IT needs today. The industry is moving towards anti-fragile architecture, based on microservice. The microservice architecture is enabling low granularity and polyglot services.

Published in: Technology

Anti fragile and microservice architecture

  1. 1. Anti-fragile and Microservice Architecture William El Kaim Oct. 2016 - V 2.2
  2. 2. This Presentation is part of the Enterprise Architecture Digital Codex http://www.eacodex.com/Copyright © William El Kaim 2016 2
  3. 3. Plan • Some Definitions • Looking for the Next Gen Architecture • Antifragile Architecture • Microservice Architecture • Microservice Technical Ecosystem • References and Resources Copyright © William El Kaim 2016 3
  4. 4. Some Definitions Copyright © William El Kaim 2016 4
  5. 5. A “Service” is software that … • … is owned, built, and run by an organization • … is responsible for holding, processing, and/or distributing particular kinds of information within the scope of a system • … can be built, deployed, and run independently, meeting defined operational objectives • … communicates with consumers and other services, presenting information using conventions and/or contract assurances • … protects itself against unwanted access, and its information against loss • … handles failure conditions such that failures cannot lead to information corruption Source: Clemens VastersCopyright © William El Kaim 2016 5
  6. 6. • ... “Cloud” • … “Server” • … “ESB” • … “API” • … XML • … JSON • … REST • … HTTP • … SOAP • … WSDL • … Swagger • … Docker • … Mesos • … Svc Fabric • … Zookeeper • … Kubernetes • … SQL • … NoSQL • … MQTT • … AMQP • … Scale • … Reliability • … “Stateless” • … “Stateful” • … OAuth2 • … OpenID • … X509 • … Java • … Node • … C# • … OOP • … DDD • etc. pp. “Service” does not imply… Principles of Service-Based Architecture are independent of implementation choices. Source: Clemens VastersCopyright © William El Kaim 2016 6
  7. 7. • A system is a federation of services and systems, aiming to provide a composite solution for a well-defined scope. • The solution scope may be motivated by business, technology, policy, law, culture, or other criteria • A system may appear and act as a service towards other parties. • Systems may share services • Consumers may interact with multiple systems System Source: Clemens VastersCopyright © William El Kaim 2016 7
  8. 8. Layers: Code Organization • We usually structure implementation (code) into several distinct layers. • Most commonly: • “Interface” captures information • Presentation Events • HTML, GUI, Web Services, Pipes, Queues, RPC, … • System Events • Timers, OS Wait Objects, Alerts, … • “Logic” filters, validates, and processes information • Functions, Classes, Lambdas, Actors, etc. • “Resources” are platform • Web Services, Databases, Queues, … Interface Logic Resources Source: Clemens VastersCopyright © William El Kaim 2016 8
  9. 9. Tiers: Runtime Organization • Tiers are about meeting operational objectives • Aspects of one service or even one layer may have different scalability and reliability goals • Resource governance (I/O, CPU, Memory) needs may differ between particular functions • UX tier will be more efficient and more adaptable with client-based rendering • Tier boundary most often is a process boundary • On same machine, across machines • In same organization, across organizations • In trusted environment, across trust boundaries • Tier boundaries often cut through layers • Cuts may separate “yours” and “theirs” • Ex: “Your” hosted web code and “their” browser • Ex: “Your” data access code and “their” database API Gateway Service Backend Browser Web Server 2 tiers, 1 layer 2 tiers, 2 layers Source: Clemens VastersCopyright © William El Kaim 2016 9
  10. 10. Tier Tier Tier • Tiers have different shapes • "Fat“ or “Thin“ • Tiers have different relationships • "Far", “Near" or “Local“; "Connected" or “Disconnected" • Focus is on boundaries • Relation between Layers and Tiers • Tiers may combine layers or split layers • Tier != Layer • Tier: Autonomous runtime entity • Can be independently operated and deployed Shaping Tiers Layer Layer Layer Layer Tier Layer Layer Layer Tier Layer Layer Tier Layer Layer Far, sparsely connected Near Local Far Source: Clemens VastersCopyright © William El Kaim 2016 10
  11. 11. Tiers: Fat vs. Thin • “Thin” Tiers • May implement only parts of layers • Web Browser provides client portion of an interactive Web user-interface layer • GUI toolkits (Windows Forms, WPF, Cocoa, etc) may provide client portion of a GUI/Web services user- interface layer • “Fat” Tiers • Implement full or even multiple layers • “Classic” Client/Server typically implements desktop application with tier boundary through data layer – connecting to remote RDBMS Tier Tier Tier Layer Layer Layer Layer Tier Layer Layer Layer Tier Layer Layer Tier Layer Layer Fat Thin Source: Clemens VastersCopyright © William El Kaim 2016 11
  12. 12. Tiers: Far vs. Near vs. Local • Local Tiers • Separated by logical or actual (process) boundary on local machine. • Logical means: InProc/OutProc via config / no recompile • Mandates dynamic loading, factories and activators • Local Tiers never become “Near” or “Far” • Near Tiers • Separated by actual process boundary across machines, inside trust domain and “local network” • Never become “Far” • Far Tiers • Separated by trust, ownership and (possibly) oceans • May be “connected” or “disconnected” Tier Tier Tier Layer Layer Layer Layer Tier Layer Layer Layer Tier Layer Layer Tier Layer Layer Far, sparsely connected Near Local Far Source: Clemens VastersCopyright © William El Kaim 2016 12
  13. 13. Layers, Tiers, and Services • Layers: Code Management • Tiers: Runtime Management • Services: Ownership Management The implementation of a service consists of one or multiple deployment tiers that implement one or multiple layers A “service” is a software and operations deliverable owned by an autonomous organization. Source: Clemens VastersCopyright © William El Kaim 2016 13
  14. 14. Looking for the Next Gen Architecture Copyright © William El Kaim 2016 14
  15. 15. Three-tier Architecture Lacks Scalability • Designed in an era where the idea of elasticity and rapid scaling did not broadly exist. • Functional components of the application are packaged together as a unit (the monolith), so the only way you can respond to changing levels of client demand is to scale the entire application. Applications running on the three-tier architecture are typically unable to scale specific pieces of the application independently because the entire application is coupled together. • Regardless of whether you have an e–commerce store, a social media application, or a blog, a basic requirement for today’s applications is the ability to scale up and down on demand; preferably at as low cost as possible. Source: Andreas SchroederCopyright © William El Kaim 2016 15
  16. 16. Three-tier Architecture Lacks Scalability Shift of User Interface logic from the server to the client Source: Octo technologyCopyright © William El Kaim 2016 16
  17. 17. Three-tier Architecture Lacks Scalability • Still huge codebases (one per layer) • … with the same impact on development, building, and deployment • Scaling works better, but still limited • Staff growth is limited: roughly speaking, one team per layer works well • Developers become specialists on their layer • Communication between teams is biased by layer experience (or lack thereof) Source: Andreas SchroederCopyright © William El Kaim 2016 17
  18. 18. Four-Tier Engagement Platform Source: Mobile Needs A Four-Tier Engagement Platform, Forrester report, October 18, 2013Copyright © William El Kaim 2016 18
  19. 19. Four-Tier Engagement Platform • Client tier • Packages the unique capabilities of both the experience and the device requesting information—anything from various mobile clients and wearables, to objects within the Internet of Things. • Frees developers from having to customize development to each mobile device, which allows them instead to focus on building out a single app, increasing productivity, and decreasing maintenance load. • Delivery tier • Optimizes delivery of the digital experience to the user using intelligence received from the client layer. • Uses intelligence-driven solutions such as content delivery networks (CDNs) and on-the- fly optimization tools such as those used for compressing images to decrease bandwidth • Utilizes sophisticated caching algorithms and tools that enable devops to monitor and resolve application performance and delivery issues in real time. Source: Tibco BlogCopyright © William El Kaim 2016 19
  20. 20. Four-Tier Engagement Platform • Aggregation tier • Serves as the center of application logic, performing tasks like translating between SOAP to JSON encoding or combining third-party and in-house algorithms to perform complex calculations • Manages the API layer and facilitates simple service composition. • This tier connects app requests to the right services with bidirectional, real-time translation to the right data format for back-end and third-party systems, as well as client requests. • Services tier • Continues to maintain functionality for data both internally and externally. • By architecting this layer to continuously deploy services, the rate of consumption does not affect the other tiers within the system. • Without a strong services layer providing the foundation, and ultimately the execution for your application, maintenance and updating can be costly and difficult. • The services tier is designed for a microservices approach, one that is designed to be open and pluggable, and focuses on the integration and composition of existing services a company has already built as well as new open source libraries. Source: Tibco BlogCopyright © William El Kaim 2016 20
  21. 21. Four-Tier Engagement Platform – So What? • The most dramatic difference in this new model is the client tier • User-facing layer has its own independent set of functionality that leverages the delivery, aggregation, and services layers beneath it to create device-specific and highly tailored experiences. • Isolation gives front-end and user-experience designers much more control to create memorable digital experiences by tailoring them to the specific user context Copyright © William El Kaim 2016 21
  22. 22. “Next-Gen” Architecture • Technology that Scales • Common migrations to {Python, Go, JVM languages} • Concurrency • Asynchrony • Independent systems • Fit-for-purpose systems: analytics, search • Layered services: caching, etc. • Event queue • Scalable persistence • Break up the monolithic database • Functional partitioning • Sharding • Scalable Infrastructure • IaaS for some systems Looking for the “Minimal Viable Architecture” Source: Randy SoupCopyright © William El Kaim 2016 22
  23. 23. Learn From Others http://stackshare.io/ Copyright © William El Kaim 2016 23
  24. 24. Learn From Others Source: The New StackCopyright © William El Kaim 2016 24
  25. 25. Antifragile Architecture Copyright © William El Kaim 2016 25
  26. 26. Antifragile • In Antifragile, Nassim Taleb discusses the behavior of complex systems and distinguishes three kinds: • those that are fragile: Shatters when exposed to even a small stressor. Unlike risk, fragility is actually measurable! • those that are robust or resilient: Fragile with a thicker skin, vulnerable to unanticipated events • those that are antifragile: when exposed to stress it gets stronger . • These types of systems differ in how they respond to volatility: “The fragile wants tranquility, the antifragile grows from disorder, and the robust doesn’t care too much.” Copyright © William El Kaim 2016 26
  27. 27. Antifragile While fragile systems are easily injured and suffer from volatility, antifragile systems grow stronger in response to volatility. So-called robust systems remain unchanged. Copyright © William El Kaim 2016 27
  28. 28. Antifragility as an Outgrowth of Agile Source: PWCCopyright © William El Kaim 2016 28
  29. 29. Antifragile: “Black Swan” Problem • “Black Swan” • Impossibility of calculating the risks of consequential rare events and predicting their occurrence. • Taleb proposes that systems should be built to handle Black Swan events – unpredictable and irregular events of massive consequence – instead of building systems based on known, predictable patterns. • Systems are generally purposely designed to deal with known risks so when a shock to a system occurs that was not predicted, all hell breaks loose. Copyright © William El Kaim 2016 29
  30. 30. Antifragile: Event Driven Architecture • Developing software as an aggregation of events that respond to change in data or state is not a new trend. • Cloud lets developers the ability to focus on the projects they are doing and not the infrastructure. • And Functional reactive programming takes this to the next level. • By idealizing continuous event streams and building subscribers to the event streams, it simplifies the idea of event driven systems. • For developers, it is about minimizing the moving parts of building large scale event driven systems. • A definition of a modern online application is now a collection of services that persist their state outside itself, run independently on independent infrastructure, can be scaled horizontally and upgraded to avoid minimum or no downtime to the end user. Copyright © William El Kaim 2016 30
  31. 31. Anti-Fragile IT Systems • For many years, the focus in IT has been on building robust systems that invested heavily in avoiding failures. • To accomplish this goal, methodical processes were implemented to guide IT through a list of known use cases so that systems could try to avoid failing and have a plan for recovery if a failure did occur. • This approach often led to long delivery cycles and a high degree of complexity which in reality, increased the risk of failure and created fragile systems. • Fragile systems are those systems that cannot adapt to unpredictable, volatile, and random events often referred to as “shocks to the system”. • There is a fundamental difference in designing systems that do not fail versus designing systems that expect all parts of the system to fail. Source: Mike Kavis Copyright © William El Kaim 2016 31
  32. 32. Anti-Fragile IT Systems • What should be done? • Assume everything will fail • Cause failure to validate resiliency • Test design assumption by stressing them • Don’t wait for random failure. Remove its uncertainty by forcing it periodically. • Microservices are a natural design approach for Antifragile • Gives you the full power of embracing change as you are able to evolve parts of your application that change at similar rates, typically microservices, at the rate at which they need to evolve at. • Enable clients must respond gracefully to provider failure • Devops and Aggressive monitoring • Try to break your IT systems using techniques such as game days and systems like chaos monkey. Copyright © William El Kaim 2016 32
  33. 33. Netflix Chaos Monkey • “One of the first systems our engineers built in AWS is called the Chaos Monkey. • The Chaos Monkey’s job is to randomly kill instances and services within our architecture. • If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.” http://luckyrobot.com/netflix-chaos-monkey-keeps-movies-streaming/ http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html Copyright © William El Kaim 2016 33
  34. 34. Then, Netflix Simian Army • Simian Army consists of services (Monkeys) in the cloud for generating various kinds of failures, detecting abnormal conditions, and testing our ability to survive them. • The goal is to keep our cloud safe, secure, and highly available. More details can be found at this blog. • Currently the simians include Chaos Monkey, Janitor Monkey, and Conformity Monkey. • Refer to the Quick start guide to get started setting up and using the Monkeys. https://github.com/Netflix/SimianArmy Copyright © William El Kaim 2016 34
  35. 35. MicroService Architecture Copyright © William El Kaim 2016 35
  36. 36. Conway’s Law • “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Melvin Conway • Siloed functional teams lead to siloed application architectures • Objective: Do the opposite • Create cross-functional team organized around capabilities and responsibility • Fight against the monolith … Source: Neal Ford, ThoughtWorks Copyright © William El Kaim 2016 36
  37. 37. Software Monolith • A Software Monolith • One build and deployment unit • One code base • One technology stack (Linux, JVM, Tomcat, Libraries) • Benefits • Simple mental model for developers • one unit of access for coding, building, and deploying • Simple scaling model for operations • just run multiple copies behind a load balancer Source: Andreas SchroederCopyright © William El Kaim 2016 37
  38. 38. Software Monolith Issues • Huge and intimidating code base for developers • Development tools get overburdened • refactorings take minutes • builds take hours • testing in continuous integration takes days • Scaling is limited • Running a copy of the whole system is resource-intense • It doesn’t scale with the data volume out-of-the-box • Deployment frequency is limited • Re-deploying means halting the whole system • Re-deployments will fail and increase the perceived risk of deployment Source: Andreas SchroederCopyright © William El Kaim 2016 38
  39. 39. What is a Microservice Architecture? • Definitions • Functional system decomposition into manageable and independently deployable components. • The term “micro” refers to the sizing: a microservice must be manageable by a single development team (5-9 developers) • Functional system decomposition means vertical slicing (in contrast to horizontal slicing through layers) • Independent deployability implies no shared state and inter-process communication (often via HTTP REST-ish interfaces) • Enables separation and independent evolution of code base, technology stacks, scaling and, features. • Loosely coupled service oriented architecture with bounded context. • Microservice is the first architectural style developed post-Continuous Delivery • Each service has its own software repository Copyright © William El Kaim 2016 39
  40. 40. Microservice History • 2011: First discussions using this term at a software architecture workshop near Venice • May 2012: microservices settled as the most appropriate term • March 2012: “Java, the Unix Way” at 33rd degree by James Lewis • September 2012: “μService Architecture“ at Baruco by Fred George • All along, Adrian Cockroft pioneered this style at Netflix as “fine grained SOA” Source: Andreas SchroederCopyright © William El Kaim 2016 40
  41. 41. Principles of Microservice Source: PWC Decentralized Governance: Enterprise Architects suffer from less pressure to make the correct choice(s) in microservice architectures. Source: Andreas Schroeder Copyright © William El Kaim 2016 41
  42. 42. Monolithic vs. Microservices Architecture Copyright © William El Kaim 2016 42
  43. 43. Monolithic vs. Microservices Architecture Source: PWCCopyright © William El Kaim 2016 43
  44. 44. Monolithic vs. MicroServices Architecture Source: Martin FowlerCopyright © William El Kaim 2016 44
  45. 45. Monolithic vs. MicroServices Architecture Source: Neal Ford, ThoughtWorks Small enough to fit in your head Rewrite over maintain (10—1000 LOC)-ish / service Copyright © William El Kaim 2016 45
  46. 46. Monolithic vs. SOA Source: PWC Source: Neal Ford, ThoughtWorks Copyright © William El Kaim 2016 46
  47. 47. MSA = SnowMan Architecture From Horizontal to Vertical decomposition Source: The Snowman architectureCopyright © William El Kaim 2016 47
  48. 48. Microservice Architecture Pattern Source: Microservices.ioCopyright © William El Kaim 2016 48
  49. 49. Examples • eBay • 5th generation today • Monolithic Perl  Monolithic C++  Java  microservices • Twitter • 3rd generation today • Monolithic Rails  JS / Rails / Scala  microservices • Amazon • Nth generation today • Monolithic Perl / C++  Java / Scala  microservices Re-architecting is a sign of success! If you never need to, either you overbuilt or nobody cares. Source: Randy SoupCopyright © William El Kaim 2016 49
  50. 50. MSA Drawbacks • Complexity is moved not removed • Understanding, managing and testing dependencies is difficult • Centralized governance is not possible • Large numbers of Microservices are difficult to orchestrate • Increase network communication • Independently running component interact with each other using calls. Such system require reliable and fast network connections. • Network Security • Inter-service communication need to be secured to avoid any security breach • Microservice based application are more prone to security vulnerabilities. • Production Monitoring • Monitoring the application in production becomes a complex job, with multiple services • Usage of Containers could help Source: WSO2Copyright © William El Kaim 2016 50
  51. 51. MicroService Technical Ecosystem Copyright © William El Kaim 2016 51
  52. 52. MSA Ecosystem • Compared with traditional packaging methods for monolithic applications, microservice architecture gives you significantly more flexibility in terms of deployment options and scalability configurations. • However, microservice architecture also underscores the need for a robust automation infrastructure; given the vast number of moving parts, the prospect of deploying and managing microservices manually is simply untenable. • Microservice architecture increases the complexity of coordination, error handling, monitoring and state management across services. • The cost of achieving extreme scalability and resiliency in this architecture places a burden on architects to understand the implications of decoupling, of increased independence between services, and of apps and applications that must aggregate and consume a larger number of services. Copyright © William El Kaim 2016 52
  53. 53. Microservice Ecosystem Copyright © William El Kaim 2016 53
  54. 54. MSA: Agile Development & Devops Scale enable elastic Cloud Architecture and devops techniques Speed enables and encourages new microservice architectures Scale breaks Hardware Speed breaks Software Source: Adrian CockcroftCopyright © William El Kaim 2016 54
  55. 55. MSA: Deployed in Containers Source: PWCCopyright © William El Kaim 2016 55
  56. 56. Microservice: Container • Dedicated Solution • Cap Gemini Apollo / Mantl / Mesos / NOMAD / Terraform • Container • Docker / Amazon EC2 Container Service / Apache Karaf • Other container tools • Deis: open source PaaS that makes it easy to deploy and manage applications on your own servers. • Packer: tool for creating identical machine images for multiple platforms from a single source configuration. • Google Kubernetes: open source orchestration system for Docker containers • Container specific OS • Snappy Ubuntu Core (Snappy) • RedHat Atomic Copyright © William El Kaim 2016 56
  57. 57. Microservice Communication Protocol: gRPC • Thanks to the rise of JavaScript frameworks, Node.js, and document databases, REST has become wildly popular among web developers. • Many applications started to rely on REST even for internal serialization and communication patterns. • But is HTTP the most efficient protocol for exchanging messages across services running in the same context, same network, and possibly the same machine? • HTTP’s convenience comes with a huge performance trade-off, which takes us back to the issue of finding the most optimal communication framework for microservices. • Enter gRPC, the modern, lightweight communication protocol from Google. • It’s a high-performance, open-source universal remote procedure call (RPC) framework that works across a dozen languages running in any OS. Source: GRPCCopyright © William El Kaim 2016 57
  58. 58. Microservice Communication Protocol: gRPC • Declare the service in a language-agnostic Interface Definition Language (IDL), and then generate language-specific bindings • Make the clients believe that the server is on the same machine. • Clients invoke a method on the Stub, which gets transparently handled by the underlying protocol. • gRPC’s secret sauce lies in the way the serialization is handled. • Based on Protocol Buffers, an open source mechanism for serializing structured data, which is language and platform neutral. • The latest version of Protocol Buffer is proto3, which supports code generation in Java, C++, Python, Java Lite, Ruby, JavaScript, Objective-C, and C#. When a Protocol Buffer is compiled for a specific language, it comes with accessors (setters and getters) for each field definition. Source: GRPCCopyright © William El Kaim 2016 58
  59. 59. Microservice: Frameworks • DropWizard (Java) • Gizmo • Kite (Go) • Micro • NancyFX (.net and Mono) • Playframework (Java & Scala) • Qbit (Java) • Rodent (Ruby) • Seneca: micro-services toolkit for Node.js • ServiceStack (F#) • Spring Boot (Java) • Vert.x (Java, JavaScript, CoffeeScript, Ruby, Python or Groovy) Copyright © William El Kaim 2016 59
  60. 60. Microservice: Platform and Automation Source: Adrian CockcroftCopyright © William El Kaim 2016 60
  61. 61. Microservice: Platform and Automation • Platform for microservices • Colossus / Gilliam / Hivepod / Lagom / Netflix OSS / Silex • Deployment automation • Jenkins, uDeploy, Capistrano, Chief, Puppet or custom scripts. • Distributed tracing and context propagation • Circonus, Nexflix Suro, OpenTracing, Prometheus, Riemann.io, Sensu, Trace, Zipkin • Application Performance Monitoring • AppDynamics, Datadog, New Relic, Scout, SignalFx, and Sysdig • Latency and Fault Tolerance • Hystrix • Security • Open Source Identity & Access Management OSIAM • VAddy (http://vaddy.net): Continuous web security testing service connected with CI tools. Copyright © William El Kaim 2016 61
  62. 62. Lagom https://www.lightbend.com/lagomCopyright © William El Kaim 2016 62
  63. 63. Hivepod https://www.hivepod.io/Copyright © William El Kaim 2016 63
  64. 64. MSA Platform Ex: Netflix OSS http://netflix.github.io/ Source: Adrian CockcroftCopyright © William El Kaim 2016 64
  65. 65. MSA Platform Examples Twitter Microservice Platform Gilt Microservice Platform Source: Adrian CockcroftCopyright © William El Kaim 2016 65
  66. 66. References and Resources Copyright © William El Kaim 2016 66
  67. 67. References: Microservice Introduction • Introduction to Microservice by Martin Fowler. • Introduction to Microservices by Nginx. • InfoQ series of articles • David Morgantini series of Blog Posts • Microservice Architectures, Dr. Andreas Schroeder • High Scalability Article • Microservices: The resurgence of SOA principles and an alternative to the monolith, PWC • Why a microservice approach to building Application by Microsoft. • State of the Art in Microservices, Adrian Cockcroft and Microservices: State of the Union by Adrian Cockcroft. Copyright © William El Kaim 2016 67
  68. 68. Best Practices & Lessons Learned • Microservice.com: Pragmatic advice for microservices practitioners. • Microservice Architecture Pattern. • Minimimum Viable Architecture in startup, Randy Soup • It’s Time to Move to a Four-Tier Application Architecture, Nginx • Developing applications with a microservice architecture, Chris Richardson • Sam Newman’s 14 Tips For Microservices, ThoughtWorks • Building SaaS enabled architecture, Twelve Factor App • Building PaaS enabled architecture, ActiveState Blog • Failing at Microservice by Richard Clayton • Microservices Reality Check, CapGemini • Migrating to Microservices and Slides, Adrian Cockcroft • Seven microservices architecture problems and solutions, Eugene Dvorkin • bla bla microservices bla bla Copyright © William El Kaim 2016 68
  69. 69. Microservice: Case Studies • Microservice Architecture by Netflix • Using Services to Break Down Monoliths by Yelp • Adopting Microservices at Netflix • Effectively Monitor Your Micro-Service Architectures by wheretoe.at • A Journey into Microservices by Hailo • Scaling Gilt: from Monolithic Ruby Application to Distributed Scala Micro- Services Architecture by Gilt • I-Tier: Breaking Up the Monolith by Groupon • What has Soundcloud learned about Microservices? by Soundcloud • Microservices from Theory to Practice: Creating Applications in IBM Bluemix by IBM Copyright © William El Kaim 2016 69
  70. 70. Microservice: Books and News • News • Microservice Weekly • The New Stack • StackShare • Books • “Antifragile Software: Building Adaptable Software with Microservices” by Russ Miles • “Building Microservices: Designing Fine-Grained Systems” by Sam Newman • “Drift into Failure: From Hunting Broken Components to Understanding Complex Systems” by Sidney Dekker • “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” by Gene Kim, Kevin Behr, & George Spafford. Copyright © William El Kaim 2016 70
  71. 71. Twitter http://www.twitter.com/welkaim SlideShare http://www.slideshare.net/welkaim EA Digital Codex http://www.eacodex.com/ Linkedin http://fr.linkedin.com/in/williamelkaim Claudine O'Sullivan Copyright © William El Kaim 2016 71

×