Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Welcome to the world of micro-applications

437 visualizaciones

Publicado el

Microservices have been around since a few years, and many organizations are starting to benefit from these autonomous, independently deployable and easy maintainable small blocks of code. However, if you examine some of the popular definitions of microservices, we are still building a single application as a suite of small services.

During this talk Sander Hoogendoorn will explain and demonstrate how front-end development can also benefit from building it in small autonomous, independently deployable blocks of code, instead of implementing a single monolithic web application. Of course, Sander will use many code examples in Java, Angular and Typescript (and probably some live coding) to illustrate even better how to build micro-applications similar to your microservices.

Publicado en: Software
  • Sé el primero en comentar

Welcome to the world of micro-applications

  1. 1. Welcome to the world of micro-applications Combing microservices, smart use cases & web applications (with Angular) Sander Hoogendoorn | ditisagile.nl @aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of. Next
  2. 2. Sander Hoogendoorn Independent dad, software architect, agile coach, programmer, speaker, writer [Former] CTO ANVA Former CTO insurance company Former global agile thoughtleader Capgemini sanderhoogendoorn.com aahoogendoorn aahoogendoorn sander@ditisagile.nl Next
  3. 3. Click here @aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
  4. 4. Click here @aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
  5. 5. Monoliths Why we like ‘m, why we hate ‘m
  6. 6. Continue Monoliths. Advantages A single (layered) architecture A single technology stack A single code base maintained by multiple teams
  7. 7. Continue Monoliths. Disadvantages All parts are interconnected Many other systems are connected to your system Hard to change, hard to maintain Long time between releases, thereby increasing risks Slow innovation Hard to move to newer technologies Doesn’t scale very well
  8. 8. Submit Dependencies will kill you every time A typical systems landscape
  9. 9. More … Monoliths Hard to deliver. Harder to test. Impossible to maintain. @aahoogendoorn | www.ditisagile.nl | It's a small world after all
  10. 10. Enter microservices The world of small component that do one thing only Continue @aahoogendoorn | www.ditisagile.nl | It's a small world after all
  11. 11. Continue Microservices In short, the microservice architectural style is 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. Martin Fowler @aahoogendoorn | www.ditisagile.nl | It's a small world after all
  12. 12. Greenfield or brownfield? That is the question
  13. 13. Click here Opinions, opinions, opinions
  14. 14. Promises and challenges Of building microservices Continue @aahoogendoorn | www.ditisagile.nl | It's a small world after all
  15. 15. Continue Promises Products not projects Scalable Decentralized governance Replaceable parts High performance Technology independent Polyglot persistence Easy to build Easy to test Easier deployment than monoliths Continuous delivery
  16. 16. Continue Challenges What is a microservice exactly? How small is a microservice? Requirements in a microservice world Components or services Who owns a microservice? What technologies do you use? What communication patterns do you apply? How to test microservices How to build deployment pipelines? Containers anyone?
  17. 17. About applications Building a single application versus building micro-applications
  18. 18. Continue Microservices In short, the microservice architectural style is 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. Martin Fowler
  19. 19. Click here Product Order Customer Credit card Vendor Web ordering system A single application
  20. 20. Click here A business process Select product Select product Show cart Check out cart Register client Register CC Show order Product Order Customer Credit card Vendor Apps, workers and microservices Validate CC Confirm order via email
  21. 21. Continue Benefits Small and thus simple Built around a single business capability Easy to build East to test Deploy individually Allows for frequent change without regression Reuse A platform of small services instead of having a single application
  22. 22. Continue Challenges How to model requirements in micro-applications? What does the architecture look like? Do micro-apps have there own domain model or bounded context? How to handle communication between micro-apps and services? What does the API look like? How to unify the user interface? How to handle navigation?
  23. 23. Start with some guiding principles
  24. 24. Business processes first
  25. 25. Continue Some guiding principles We implement business processes We move towards a systems landscape consisting of micro-applications and microservices Requirements are modeled (in smart use cases) Micro-applications implement a single elementary business process step Micro-applications and microservices all have their own bounded context
  26. 26. Continue Some guiding principles Micro-applications do not have storage, and only talk to other micro-applications and microservices Microservices have their own storage (in MongoDB), and only talk to other microservices Communication uses a simple open protocol – JSON on REST We avoid transactions like the plague We make it work first, and build (security and) performance in next
  27. 27. Smart use cases Archeology to the rescue
  28. 28. Click here Different levels of granularity OTOPOP
  29. 29. Click here Smart use cases (services)
  30. 30. Click here Smart use cases (app)
  31. 31. Evolutionary architecture
  32. 32. Continue Microservices require an evolutionary software architecture And so do micro-applicationsAristotle
  33. 33. Click here Service interface Process Domain Data / Services Outside world Resources Representations Use cases Flow Factories, Repositories Entities, Enums, Value objects Gateways StorageRelations Dossiers Intermediaries MongoDB
  34. 34. Submit Resource
  35. 35. Submit Resource next generation
  36. 36. Click here Presentation Process Domain Services Outside world Pages Grids, Panels, Controls Use cases Flow Factories, Repositories Entities, Enums, Value objects Gateways ComponentsRelations Dossiers Intermediaries Accounts Rates
  37. 37. Submit Presentation (Angular)
  38. 38. Submit Use case
  39. 39. Submit Repository
  40. 40. Submit Service gateway
  41. 41. Designing micro-apps Where bounded contexts come in
  42. 42. Continue The SOLID principles Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
  43. 43. Continue Single Responsibility Principle Every “module” should have responsibility over a single part of the functionality provided by the software, That responsibility should be entirely encapsulated by that module All its services should be narrowly aligned with that responsibility
  44. 44. Click here Single responsibility principle Group together things that change together Separate things that change for different reason
  45. 45. Continue Domain driven design The paradigm of designing software based on models of the underlying domain The domain model helps the business and the developers to reason about the functionality
  46. 46. Continue Bounded context A model needs to be unified – internally consistent without contradictions The bounded context is a central pattern in domain driven design
  47. 47. Click here Bounded context When you model larger domains, it becomes progressively harder to create this single unified model. Instead of creating a single unified model, you create several, all valid within their bounded context
  48. 48. Click here The single unified domain model Or more often the humongous data model Product Vendor Stock Order Client Delivery Payment
  49. 49. Click here Bounded contexts Product Vendor Stock Order Client Delivery Payment Product
  50. 50. Click here
  51. 51. Submit Domain objects (TypeScript)
  52. 52. Submit Domain objects (TypeScript)
  53. 53. Communication breakdown Using REST & JSON & Promises
  54. 54. Click here Communcation breakdown Presentation Process Domain Services Outside world Pages Grids, Panels, Controls Use cases Flow Factories, Repositories Entities, Enums, Value objects Gateways ComponentsRelations Dossiers Intermediaries Accounts Rates Service interface Process Domain Data / Services Outside world Resources Representations Use cases Flow Factories, Repositories Entities, Enums, Value objects Gateways StorageRelations Dossiers Intermediaries MongoDB
  55. 55. Click here Postel’s Law Be conservative in what you send, be liberal in what you accept Postel’s Law
  56. 56. Click here Open closed principle Software entities (classes, modules, functions, microservices, JSON objects, API’s) should be open for extension, but closed for modification
  57. 57. Click here HTTP Return Codes Cheat Sheet 1**. Hold on 2**. Here you go 3**. Go away 4**. You fucked up 5**. I fucked up
  58. 58. Navigating micro-apps Creating a RESTful API for your apps
  59. 59. Click here App Use case
  60. 60. Click here App Use case
  61. 61. Click here Parameters
  62. 62. Click here Navigating micro-apps First step: entering Home Home app Change Password Reset Password ManageAccount app Find Account Manage Account Find Contact Manage Contact ManageContact app View Contact Flows https://integratie.anva.live/home/#/Home
  63. 63. Submit Angular takes care of the routing @aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
  64. 64. Submit An actual use case @aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
  65. 65. Submit A use case layer supertype (Step) @aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
  66. 66. Click here Navigating micro-apps From use case to use case Home Home app Change Password Reset Password ManageAccount app Find Account Manage Account Find Contact Manage Contact ManageContact app View Contact Flows https://integratie.anva.live/managecontact/#/FindContact Flows.start(Flow.FindContact)
  67. 67. Submit A list of use cases (Flow)
  68. 68. Submit A use case provider (Flows)
  69. 69. Submit Navigating use cases @aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
  70. 70. Click here Navigating micro-apps Finishing work on a use case Home Home app Change Password Reset Password ManageAccount app Find Account Manage Account Find Contact Manage Contact ManageContact app View Contact Flows Flows.ok(this.contact.id) https://integratie.anva.live/home/#/Home?c=Cancel&backFrom=managecontact.FindContact back(id)
  71. 71. Submit Going back @aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
  72. 72. Click here Demo?
  73. 73. Click here In retrospective Some final thoughts
  74. 74. Continue Why micro-applications? All the benefits from “regular” microservices Easy to build Easy to test Flexible and frequent deployment of individual functions Allows application of domain driven design easily Takes time to implement the mechanism Keep UI unified by creating library of reusable UI components Works with any technology
  75. 75. Click here References and questions www.sanderhoogendoorn.com www.ditisagile.nl aahoogendoorn aahoogendoorn sander@ditisagile.nl

×