Beyond cloud-native with microservices

About usIvan Dugalic. Software Architect. Namics. Belgrade.

Technology. Business. Communication. Tata. Fun. Music. Passion. Erfolgsfaktor. ivan.dugalic@namic.com

Vladan Simic. Software Engineer. Namics. Belgrade.Technology. Passion. Smile. Football. Beer. vladan.simic@namic.com

The motivation

- "It is not necessary to change. Survival is not mandatory.” -W. E. Deming

- It’s critical to reduce time-to-production.

- Software - for many organizations and industries - is a competitive advantage

Traditional Architecture

Continuous deployment is difficult

Scaling the application can be difficult

Obstacle to scaling development

Requires a long-term commitment to a technology stack

http://microservices.io/patterns/

monolithic.html

Microservices“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 (RESTful).

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

Microservice Architecture ● When to use it?● How to partition system into

microservices? ○ By verb or use case? ○ By noun or resources?

● What about the data?

http://microservices.io/patterns/microservices.html

Microservices - BenefitsEach microservice is relatively small

Easier for a developer to understand

The IDE is faster making developers more productive

The web container starts faster, which makes developers more productive, and speeds up deployments

Each service can be deployed independently of other services - easier to deploy new versions of

services frequently

Improved fault isolation. For example, if there is a memory leak in one service then only that service will be

affected. The other services will continue to handle requests. In comparison, one misbehaving component of a

monolithic architecture can bring down the entire system.

Eliminates any long-term commitment to a technology stack.

Project vs Product. You built it, you run it.

Easier to scale development (and application). It enables you to organize the development effort around

multiple teams. Each (two pizza) team is responsible for a single service. Each team can develop, deploy and scale

their service independently of all of the other teams.

Microservices - Benefits - Conway’s law

“organizations which design systems ... are constrained to produce designs which are copies of

the communication structures of these organizations”

—  M. Conway

One team ~ one service

High trust within the team ~ High cohesion

Low trust over the team boundaries ~ Loose coupling

Microservices - Benefits - The scale cube● X-axis scaling consists of running

multiple copies of an application behind a load balancer.

● Y-axis scaling splits the application into multiple, different services.

● When using Z-axis scaling each server runs an identical copy of the code. In this respect, it’s similar to X-axis scaling. The big difference is that each server is responsible for only a subset of the data.

Microservices - DrawbacksAdditional complexity of creating a distributed system.

Developer tools/IDEs are oriented on building monolithic applications and don’t provide explicit support for developing distributed applications.

Testing is more difficult

Developers must implement the inter-service communication mechanism.

Implementing use cases that span multiple services without using distributed transactions is difficult

Deployment complexity.

Increased memory consumption.

Operational complexity

If you look at the concerns typically expressed about microservices, you will find that they areexactly the challenges that a PaaS (Cloud) is intended to address.

CloudWe can use cloud in three primary service models:

Software as a Service (SaaS)

Software that is owned and managed remotely by a provider that delivers their software to users remotely at any time. Customers are often charged for service on a “pay-as- you-go” basis or by subscription.

Platform as a Service (PaaS)

PaaS functions at a lower level than SaaS, typically providing a platform on which software can be developed and deployed. PaaS providers abstract much of the work of dealing with servers and give clients an environment in which the operating system and server software, as well as the underlying server hardware and network infrastructure are taken care of, leaving users free to focus on the business side of scalability, and the application development of their product or service.

Infrastructure as a Service (IaaS)

IaaS is comprised of highly automated and scalable compute resources, complemented by cloud storage and network capability which can be self-provisioned, metered, and available on-demand

Being Cloud Native - maturity levels

The Twelve FactorsI. CodebaseOne codebase tracked in revision control, many deploys

II. DependenciesExplicitly declare and isolate dependencies

III. ConfigStore config in the environment

IV. Backing servicesTreat backing services as attached resources

V. Build, release, runStrictly separate build and run stages

VI. ProcessesExecute the app as one or more stateless processes

VII. Port bindingExport services via port binding

VIII. ConcurrencyScale out via the process model

IX. DisposabilityMaximize robustness with fast startup and graceful

shutdown

X. Dev/prod parityKeep development, staging, and production as similar as

possible

XI. LogsTreat logs as event streams

XII. Admin processesRun admin/management tasks as one-off processes

Twelve Factor App - BeyondSecurity

In an ideal world, all cloud-native applications would secure all of their endpoints with RBAC (role-based access control)

With tools like OAuth2, OpenID Connect, various SSO servers and standards, security should be something that is baked into the application’s development from day one

API first

Recognize your API as a first-class artifact of the development process, ‘API first’ gives teams the ability to work against each other’s public contracts without interfering with internal development processes

Stateless Processes

A stateless application makes no assumptions about the contents of memory prior to handling a request, nor does it make assumptions about memory contents after handling that request

Data Caching, Share Nothing patterns

Telemetry

Telemetry = Monitoring

Auditing and monitoring cloud applications are often overlooked but are perhaps some of the most important things to plan and do properly for production deployments

Microservices - Hype or Not● Still increasingly popular topic

● After initial hype, number of patterns

and techniques are accepted as best

practices

● Variety of technologies helping us apply

those solutions

● 12 Factor app as reference

*https://www.google.com/trends/

Sample application

https://github.com/idugalic/micro-company ● Technologies○ Spring(Boot, Cloud, Security …)○ Netflix OSS○ Axon Framework ( Messaging

framework )○ AMQP ( RabbitMQ)○ Docker

Sample application - backing servicesRegistry and client side load balancing

@EnableEurekaServer

Authorization server (Oauth 2.0)

@EnableAuthorizationServer

Configuration server

@EnableConfigServer

API gateway

@EnableZuulProxy

@EnableHystrix

Sample application - API Gateway

BenefitsProvides the optimal API for each client

Reduces the number of requests/roundtrips

Simplifies the client by moving logic for calling multiple

services from the client to API gateway

Drawbacks● Increased complexity - the API gateway is yet another

moving part.● Increased response time due to the additional network

hop through the API gateway

● Introducing separate services causes integration issue

● Netflix Zuul

Sample application - Latency & Fault tolerance● Circuit breaker - Netflix Hystrix

● Logic that prevents error to occur constantly

Sample application - Registry service

Netflix/Spring Eureka Server

Benefits:

● Loosely coupled services discoverable by name

● Client side load balancing (Ribbon)

Drawbacks:

● Application relies on Registry service

Sample application - Configurations server

Netflix/Spring Config Server

● Configuration and code should be separated strictly

● Pull configurations on startup

● Update values on the fly

Sample application - Authorization server

● OAuth 2.0

○ Authorization server ~ backing service

○ Resource servers ~ microservices

○ Client ~ cURL

Client can use any of the four standard authorization grant flows to get an access token from the authorization server and then use the access token to make a secure request to the resource servers through the API gateway component.

Api Gateway is acting as token relay

Sample application - backend microservicesBlog service - command side

Blog service - query side

Project service - command side

Project service - query side

Sample application - Event Sourcing & CQRSPatterns:

● CommandQueryResponsabilitySeparation ● Event sourcing

Write model as append-only stream of events driven by commandsAxon FrameworkKey Benefits:

1. Eventually consistent business transactions that span multiple microservices

2. Automatic publishing of events whenever data changes

3. Faster and more scalable querying by using materialized views

4. Reliable auditing for all updates

Sample application - how it works

The domain is literally split into a command-side microservice application and a query-side

microservice application (this is CQRS in its most literal form).

Communication between the two microservices is event-driven and the demo uses RabbitMQ

messaging as a means of passing the events between processes (VM's).

The command-side processes commands. Commands are actions which change state in some way.

The execution of these commands results in Events being generated which are persisted by Axon

(using MongoDB / Event Store) and propagated out to other VM's (as many VM's as you like) via

RabbitMQ messaging.

The query-side is an event-listener and processor. It listens for the Events and processes them in

whatever way makes the most sense. In this application, the query-side just builds and maintains a

materialised view which tracks the state of the individual aggregates (Product, Blog, ...).

Sample application - video

https://youtu.be/PtKynxjNQ5Y

● Clone the repository● Run all services with docker● Explore the application

Docker (beta) demo - deploy on cluster of VMsDocker has evolved from a container engine, to a complete end-to-end solution for orchestrating cloud-native applications.# Docker Machine Setup - masterdocker-machine create -d virtualbox swmaster# Docker Machine Setup - node 1,2 and 3docker-machine create -d virtualbox swnode1...# Configure swarm mode cluster - initialization on masterdocker $(docker-machine config swmaster) swarm init --advertise-addr $(docker-machine ip swmaster):2377# Configure swarm mode cluster - join nodesdocker $(docker-machine config swnode1) swarm join --token TOKEN $(docker-machine ip swmaster):2377...# Create Bundle from compose filedocker-compose bundle -o micro-company.dsb# Point your local docker client to the swarm mastereval $(docker-machine env swmaster)# Create a stack using docker deploy commanddocker deploy --file micro-company.dsb micro-company

Migration from legacy systemsBig bang migration

Hybrid approaches (strangle legacy systems that are still on-premises)

Use practices from Martin Fowler’s Strangler Application to slowly strangle domain data away from a legacy system using microservices.

Thank you

Stay tuned. Namics.