Download to read offline
Uploaded byRubiX BV
Microservices - an integration perspective
The document discusses microservices from an integration perspective, describing them as small, autonomously deployable services that focus on business capabilities and communicate through lightweight mechanisms. It highlights key characteristics of microservices, such as composability, loose coupling, and runtime independence, while also addressing the challenges and best practices associated with adopting this architectural style. Benefits include scalability and agility, but it acknowledges the complexities of distributed systems and the need for resilience in application design.
More Related Content
![[WSO2Con EU 2017] Creating Composite Services Using Ballerina](https://cdn.slidesharecdn.com/ss_thumbnails/creatingcompositeservicesusingballerinaisuruedited-171108114658-thumbnail.jpg?width=640&height=640&fit=bounds)
![[WSO2Con EU 2017] Resilience Patterns with Ballerina](https://cdn.slidesharecdn.com/ss_thumbnails/myteul0aqxm9m9aefn37-signature-25a03a0dd11bea2cb4b5d302614dc9fa369274823e87b86d7bcc419612b27068-poli-171106131830-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Microservices - an integration perspective
Microservices - an integration perspective
- 1. Who am I? •Coert van den Thillart • Solution Architect at rubiX • coert@rubix.nl • http://rubix.nl/coert-van-den-thillart
- 2. Microservices from an integrationperspective
- 3. Assumptions About you: • Youhave at least heard/read/done/seen something about Microservices • You are active in or at least familiar with the system integration space
- 4. The "what aremicroservices?" slide"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 http://martinfowler.com/articles/microservices.html
- 5.
- 6. The Microservice difference? Autonomy Independentlife cycle Runtime independence Dedicated development team Autonomous deployment
- 7. Nothing else? Other benefitsand concepts associated with microservices aren’t exclusive to microservices. They are good practices applicable to any service oriented architecture. • Bounded context • High cohesion, low coupling • Focus on business functionality But they are very valuable in achieving autonomy.
- 8.
- 9.
- 10. What changes? Just another service Nomore "integration" effort Choreography > Orchestration
- 11. That’s it? • UsingREST doesn't make something a microservice anymore than using SOAP meant you were doing SOA. • The emphasis on autonomy does drive integration patterns in a certain direction: • Asynchronous > Synchronous • Choreography > Orchestration • These decisions shouldn’t be exclusive to Microservices
- 12. Reasons to adoptmicroservices • Scalability • Independent LCM • Runtime independence & Autonomous deployment
- 13. Only good things?Not quite… • Distributed systems are still hard • What about those pesky "enterprise features"? • Resilience doesn’t come included in the box • Applications and services still need to be built for failure • On top of "existing" service challenges like contract versioning • Eventual consistency
- 14. Sign of thetimes? Microservices Agile Continuous Delivery Develop something in a couple of weeks Deploy it whenever and properly Run it autonomously
- 15.
- 16. Other concepts ofinterest • Domain Driven Design (Eric J. Evans) • Vertically Aligned Synergistically Partitioned or 'Snowman' Architecture (Roger Sessions) • Simple Iterative Partitions • Autonomous Business Capabilities • Self-Contained Systems (http://scs-architecture.org/)
Editor's Notes
- #4 This presentation won’t go into the details of microservices.
- #5 Autonoom ("own process", "lightweight", "independently deployable") "Built around business capabilities" —> ABC Implementatie agnostisch ("may be written in different programming languages and use different data storage technologies.")
- #6 Composability, Autonomy, Loose Coupling & Abstraction are all principles of service design (Erl, 2007). Almost 10 years old but still applicable to (micro)services.
- #7 Autonomy is the key with microservices. And not just on a functional level. But at all levels: design, run and deployment time.
- #9 Standaard 5 lagen architectuur. Van beneden naar boven: Applicaties hebben functionaliteit, die worden door technische services (T) ontsloten. Deze technische services worden gebruikt door business services (B) om algehele business functies te implementeren. Deze business services worden gebruikt in processen welke op hun beurt weer aansluiten op een of meer presentatie lagen.
- #10 Microservices implementeren de volledige stack vanaf het "business service" niveau. Maar ze kunnen ook "hoger" gaan door een stuk proces te implementeren (order lifecycle bijvoorbeeld) of zelf een UI (otto.de model)
- #11 On the presentation & process layer basically nothing changes. For either it’s just a bunch of new services. That said, for the process layer things might change as due to the autonomous nature of microservices there is a preference for choreography over orchestration. Biggest change is with implementing mircroservices. Basically they are full stack applications with their own stack from datastore to UI.
- #12 Technology choice doesn’t drive the architecture. Integration patterns don’t define the architecture either.
- #13 Runtime, no dependency on a runtime platform, other services etc. Because of runtime independence deployment becomes autonomous Develop what you want and need (but contracts remain a worry) Given their bounded context it should be easier to assign a dedicated team
- #14 Distributed systems put a lot more load on your ops. CD is practically a requirement. Automated monitoring tools as well. Little mature platforms out there, but a lot emerging. Enterprise features like logging, monitoring, security, auditability etc. While an asynchronous/EDA approach might help with resilience, it’s not a given. Eventual consistency is a result of using asynchronous communications across vertically scaled services.
- #15 Agile aims to deliver "done" code every sprint. This is usually a smaller package than with monolithic systems. Because of the smaller size there should be less risk involved to test it and deploy it. Because of this automated deployment should be less scary and it it goes wrong more easily rolled back. Combine that with the autonomous nature of microservices and the impact is limited even further.