Welcome to the world of micro-applications
•
2 recomendaciones•862 vistas
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.
![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](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (17)
Similar a Welcome to the world of micro-applications
Similar a Welcome to the world of micro-applications (20)
Más de Sander Hoogendoorn
Más de Sander Hoogendoorn (20)
Último
Último (20)
Welcome to the world of micro-applications
- 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. 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. 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. 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. Monoliths Why we like ‘m, why we hate ‘m
- 6. Continue Monoliths. Advantages A single (layered) architecture A single technology stack A single code base maintained by multiple teams
- 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. Submit Dependencies will kill you every time A typical systems landscape
- 9. More … Monoliths Hard to deliver. Harder to test. Impossible to maintain. @aahoogendoorn | www.ditisagile.nl | It's a small world after all
- 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. 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. Greenfield or brownfield? That is the question
- 13. Click here Opinions, opinions, opinions
- 14. Promises and challenges Of building microservices Continue @aahoogendoorn | www.ditisagile.nl | It's a small world after all
- 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. 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. About applications Building a single application versus building micro-applications
- 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. Click here Product Order Customer Credit card Vendor Web ordering system A single application
- 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. 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. 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. Start with some guiding principles
- 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. 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. Smart use cases Archeology to the rescue
- 28. Click here Different levels of granularity OTOPOP
- 29. Click here Smart use cases (services)
- 30. Click here Smart use cases (app)
- 32. Continue Microservices require an evolutionary software architecture And so do micro-applicationsAristotle
- 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. Submit Resource
- 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
- 38. Submit Use case
- 41. Designing micro-apps Where bounded contexts come in
- 42. Continue The SOLID principles Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
- 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. Click here Single responsibility principle Group together things that change together Separate things that change for different reason
- 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. 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. 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. Click here The single unified domain model Or more often the humongous data model Product Vendor Stock Order Client Delivery Payment
- 50. Click here
- 53. Communication breakdown Using REST & JSON & Promises
- 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. Click here Postel’s Law Be conservative in what you send, be liberal in what you accept Postel’s Law
- 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. 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. Navigating micro-apps Creating a RESTful API for your apps
- 59. Click here App Use case
- 60. Click here App Use case
- 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. 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. 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. 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. 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. Submit A list of use cases (Flow)
- 68. Submit A use case provider (Flows)
- 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. 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. 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. Click here Demo?
- 73. Click here In retrospective Some final thoughts
- 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