Microservices:Splitting the monolith

Yusuf Hakan Oklay

22.02.2017

Microservicessmall,services

that work together

Monolithic Architecture

Monolithic Architecture

Benefits of Monolithic Architecture• Simple to develop.• Simple to test. • Simple to deploy. • Simple to scale horizontally by running multiple copies behind a load

balancer.

Drawbacks of Monolithic Architecture• Complex• Overloaded IDE • Overloaded web container• Continuous deployment is difficult• Scaling• Obstacle to scaling development• Requires a long-term commitment to a technology stack

Microservice DefinitionThe 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.

- James Lewis and Martin Fowler

Microservices

Benefits ofMicroserviceArchitecture

• Tackling the complexity by decomposing application into• Faster to develop• Easier to understand• Easier to maintain • Manageable services

• Small, Autonomous• Each service can be developed and deployed independently• Change without requiring consumers to change• Expose APIs

• Improved fault isolation (Resilience)• Bulkheading: manage failure without having it cascade

throughout the services participating in the workflow

• Technology Heterogeneity

• Scaling

• Organizational Alignment• Smaller teams working on smaller codabases becomes more

productive• which design systems ... are constrained to produce designs

which are copies of the communication structure Organizations of these organizations.

16

Organizational Alignment

• Ease of Deployment• Composability

• Reuse of functionality

• Optimizing for Replaceability

What Makes a Good Service• Loose Coupling • High Cohesion• Do One Thing, and Do It Well

"This is the Unix philosophy: Write programs that do one thing

and do it well. Write programs to work together.”

Inter-ProcessCommunication

Inter-Process Communication• Shared Database• Synchronous Versus Asynchronous• Orchestration Versus Choreography• REST and HTTP Versus Apache Thrift

21

Inter-Process Communication

Shared Database• Most common form of integration• In this world, if other services want information from a service, they

reach into the database. And if they want to change it, they reach into the database

• Fastest form of integration

• Goodbye, loose coupling• Goodbye, cohesion

Synchronous Versus Asynchronous

Synchronous Versus Asynchronous

Synchronous Asynchronous

Synchronous Versus Asynchronous

Orchestration Versus ChoreographyUse Case : Customer Enrollment

• A new record is created in the loyalty points bank for the customer.• Our postal system sends out a welcome pack.• We send a welcome email to the customer.

OrchestrationUse Case : Customer Enrollment

ChoreographyUse Case : Customer Enrollment

Message-Based Communication• Decouples the client from the service • Message buffering • Flexible client-service interactions • RabbitMQ, Apache Kafka, Apache ActiveMQ

• Additional operational complexity

REST and HTTP• Representational State Transfer (REST) is an architectural style

inspired by the Web

Richardson Maturity Model• Level 0: Clients of a level 0 API invoke the service by making HTTP

POST requests to its sole URL endpoint • Level 1 : API supports the idea of resources• Level 2 – A level 2 API uses HTTP verbs to perform actions: GET to

retrieve, POST to create, and PUT to update. • Level3 : HATEOAS (Hypertext As The Engine Of Application State).

HATEOAS

Thrift• Apache Thrift is an interesting alternative to REST • framework for writing cross- language RPC clients and servers. • supports various message formats: JSON, binary, and compact

binary • transport protocols including raw TCP and HTTP. • C++, Java, Python, PHP, Ruby, Erlang, and Node js

JSON vs XML

Using anAPI Gateway

Simple Shopping ExampleGET api.company.com/productdetails/productId

Using an API GatewayGET api.company.com/productdetails/productId

• Request Routing• Composition• Protocol Translation

• Load Balancing• Caching• Access Control• API metering• Monitoring

Benefits and Drawbacks of an API Gateway• encapsulates the internal structure of the application • reduces the number of round trips between the client and application • simplifies the client code

• highly available component that must be developed, deployed, and managed • There is also a risk that the API Gateway becomes a development bottleneck

ServiceDiscovery

Service Discovery

A

A client or API Gateway needs help finding services

The Client-Side Service Discovery

A

Clients can take on the task of discovering services

The Server-Side Service Discovery

A

The load balancer queries the service registry and routes each request to an available service instance

Service Registry• key part of service discovery • database containing the network locations of service instances • provides a REST API for registering and querying service instances • Netflix Eureka, etcd, Consul, Apache ZooKeeper• Kubernetes, Marathon, and AWS do not have an explicit service

registry.

Self-Registration vs Third-Party Registration

• Services can handle their own registration• Simple• Not require any other system component

• But coupling

Self-Registration vs Third-Party Registration

• service registrar handles the registration • services are decoupled from the service registry • centralized • Registrator, Netflix Prana

• Another component highly available

Splitting the monolith

Incremental Refactor• Strategy #1 – Stop Digging

Implementing new functionality as a separate service instead of adding a module to the monolith.

Incremental Refactor• Strategy #2 – Split Fronted and Backend

split the presentation layer from the business logic and data access layers

Incremental Refactor• Strategy #3 – Extract Services

o Finding Seamso Resource requirements

partso changing frequently

parts

Database• Breaking Foreign Key Relationships

Database• Shared Static Data

– Duplication– Static data as code or config file– Own service

Database• Shared Mutable Data

Database• Shared Table

Staging the Break

Transactional Boundaries

Transactional Boundaries

Transactional Boundaries• Try Again Later• Abort the Entire Operation• Distributed Transactions

• So What To Do?

Handling Partial Failures• Timeouts• Limiting the number

of outstanding requests• Circuit breaker pattern• Provide fallbacks• Netflix Hsytrix

Reporting

Reporting• Data Retrieval via Service Calls• Data Pumps• Event Data Pump

Reporting• Data Pumps

Reporting• Event Data Pumps

Microservices Trade-Offs

Known Useshttps://www.infoq.com/presentations/migration-cloud-native

https://vimeo.com/29719577

http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html

Known Uses

https://www.youtube.com/watch?v=RrX_28s70ww

https://eng.uber.com/tag/microservice/

iyzico?

next?

• Event-Driven Architecture• Consumer-Driven Contract Testing• Containerization• Deployment• Monitoring• Security

69

Resources

• Books

• Linkshttps://www.martinfowler.com/microservices/#what https://www.nginx.com/blog/introduction-to-microservices/ http://microservices.io/patterns/monolithic.html

thanks22.02.2017