beyond cloud-native with microservices
TRANSCRIPT
Beyond cloud-native with microservices
About usIvan Dugalic. Software Architect. Namics. Belgrade.
Technology. Business. Communication. Tata. Fun. Music. Passion. Erfolgsfaktor. [email protected]
Vladan Simic. Software Engineer. Namics. Belgrade.Technology. Passion. Smile. Football. Beer. [email protected]
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.