Download - Microservices: Yes or not?
![Page 1: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/1.jpg)
Microservices… Yes or not?Eduard Tomàs – Dev @ Plain concepts@eiximenis
http://geeks.ms/etomas
#Gapand2017
![Page 2: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/2.jpg)
Colaboradores
![Page 3: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/3.jpg)
How we reach here?
![Page 4: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/4.jpg)
N-tier apps
• Distributed aplications
• Implicit boundaries
• RPC-like
Common Object Request Broker Architecture
DCOM & DNA Architecture
RMI
…
![Page 5: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/5.jpg)
SOA
• Services have explicitboundaries
• Services are autonomous
• Services share schema and contract, not classes
• Services interoperate based on policy
“Four SoA Tenets” by Don Box
• OASIS Web Services• WS-*
• SOAP
• Enterprise Service Bus (ESB)• WebSphere ESB
• BizTalk
• Oracle ESB
• …
![Page 6: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/6.jpg)
Don Box @ Teched 2001 (BCN)
![Page 7: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/7.jpg)
![Page 8: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/8.jpg)
Microservices
The term "Microservice Architecture" has sprung up over the last few years to
describe a particular way of designing software applications as suites of
independently deployable services. While there is no precise definition of this
architectural style, there are certain common characteristics around organization
around business capability, automated deployment, intelligence in the endpoints,
and decentralized control of languages and data.
https://martinfowler.com/articles/microservices.html
Microservices - also known as the microservice
architecture - is an architectural style that structures an
application as a collection of loosely coupled services,
which implement business capabilities. The microservice
architecture enables the continuous delivery/deployment
of large, complex applications. It also enables an
organization to evolve its technology stack.
![Page 9: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/9.jpg)
SOA vs Microservices
SOA Microservicios
Services are generally big Services are generally small
ESB centric role Usually no need for ESB
Favours orchestration over coreography Favours coreography over orquestration
Share as much as possible Share as Little as posible
OASIS WS-*, SOAP, XML, HTTP, … REST, HTTP, …
Who cares about SOA now? Everybody talks about Microservices!
Just one comparison…
But, the reality is…
![Page 10: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/10.jpg)
https://www.youtube.com/watch?v=wgdBVIX9ifA
![Page 11: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/11.jpg)
Microservices are a way to do SOA
![Page 12: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/12.jpg)
SOAP vs REST
• Heavy message format: XML and <soap:Envelope> schema
• RPC based: service -> method (i.e. doctorSvc->GetAllPatients)
• Uses HTTP merely as transport protocol. Can use other transports.
• Small messages. No format assumed
• Resource based (i.e. /doctors/<id>/patients
• Embraces HTTP semantics: use HTTP verbs and return codes
![Page 13: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/13.jpg)
Orchestration
• Main logic business belongs to a single central service (the orchestrator)
• Central service calls other services and combines its results
• Typical example: BPEL process
![Page 14: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/14.jpg)
Coreography
• Logic distributed.
• No central point that coordinates other services
• Best with event source model
![Page 15: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/15.jpg)
The 8 key aspects of Microservices (byFowler)
1. Componentization via Services
2. Organized around Business Capabilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
https://martinfowler.com/articles/microservices.html
![Page 16: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/16.jpg)
The 7 sins of Microservices
• LUST: Using the latest & greatest tech
• GLUTTONY: Excessive communication protocols
• GREED: All your Service are belong to us
• SLOTH: Creating a distributed monolith
• WRATH: Blowing up when bad things happen
• ENVY: The shared single domain fallacy
• PRIDE: Testing in the world of transcience
https://opencredo.com/the-seven-deadly-sins-of-microservices-redux/
![Page 17: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/17.jpg)
LUST
• Do not believe that using the latest tech will solve all your problems
• Docker, k8s, Terraform, Swarm are great technologies
• But sometimes the right choice is to pick some old and boring techs
![Page 18: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/18.jpg)
GLUTTONY
• HTTP, Protobuff, AMQP, 0MQ, gRPC, MQTT, …
• All are great communication protocols…
• …But not all together!
• Choose one synchronousprotocol…
• … And an asynchronous one
![Page 19: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/19.jpg)
GREED
• Organization needs to adapt a “microservices culture”
• Each microservice belongs to specific team
• Deployment, technologies & tools, processes… are team responsabilities
![Page 20: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/20.jpg)
SLOTH
• If you don’t change your mind and develop each microservice with using same patterns and decisions used to create monoliths
• You’ll finish not having microservices at all. Instead...
• You’ll have a set of microservices that can’t be deployed and updated independently
![Page 21: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/21.jpg)
WRATH
• Failure happens all of time
• Must embrace DevOps mentality of shared understanding and responsibility
• Rapid provisioning, monitoring and deployment are mandatory pre-requisites
![Page 22: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/22.jpg)
ENVY
• Using a Shared Single Domain is OK when developing a monolith
• In microservices is better to follow the DDD concept of ‘bounded context’ to encapsulate better our services
• Anyway: there is no rule. Don’t assume that one bounded context == one microservice
![Page 23: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/23.jpg)
PRIDE
• Testing microservices is often harder (or much harder) than testing a monolith
• Test as much as you can in your CI/CD pipelines
• Unit tests, integration tests, component tests, end-to-end tests. Automate them all.
![Page 24: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/24.jpg)
12 factor apps
https://12factor.net/
![Page 25: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/25.jpg)
I - Codebase
• One codebase, many deploys
• If there is more than onecodebase, it is not an app, it is a distributed system
![Page 26: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/26.jpg)
II - Dependencies
• Explicity declare and isolate dependencies
• 12 factor app never relies on the existence of “system-wide” packages
• All dependencies are declared by the app…
• … and a dependency isolation tool is required also
![Page 27: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/27.jpg)
III - Config
• Store config in the environment
• Configuration vary between deploys. So can’t be part of the app
• Try to avoid config files, and never store them to repo
• Store configuration in environment variables
![Page 28: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/28.jpg)
IV – Backing services
• A backing Service is any external Service consumed by the app (database, rabbitmq, external mail service,…)
• App must make not distinction between local and 3rd party backingservices
• All backing services are just attached resources that can be accessedthrough an URI
• Any backing Service can be changed from local to 3rd party at anytime, only changing configuration
![Page 29: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/29.jpg)
V – Build, Release, Run
• Strictly separate the build & run stages
• A codebase is transformed to a deploy through 3 stages• Build stage: Creating an executable from source code
• Release stage: Deploying the executable to specific environment and applyconfig
• Run stage: Starts the app by starting specific executables on the environment
• These 3 stages must be completely isolaged (i. e. can’t change thecode during run or release stages)
![Page 30: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/30.jpg)
VI - Processes
• Execute the app as one or more stateless processes
• Any app is stateless and share nothing. Any state must be stored in a stateful backing Service
• Using local storage and/or memory is OK, only if it used as a cache in a single request lifetime
• Sticky sessions are (of course) a violation of 12 factor apps
![Page 31: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/31.jpg)
VII – Port binding
• Expose Services via port binding
• A 12 factor app is completely self-contained
• No runtime injection of any webserver or similar is allowed
• App expose its functionality using a configurable port
![Page 32: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/32.jpg)
VIII - Concurrency
• Scale out via process model
• In 12 factor apps process is a 1st class citizen
• Scale using more processes, instead of any other way (like threads)
• As 12 factor apps are stateless and share nothing, concurrency and scale using processes is a safe and simple operation
![Page 33: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/33.jpg)
IX - Disposability
• Maximize robustness with fast startup and graceful shutdown
• 12 factor apps are disposable: can be stopped at any momento
• App must shutdown gracefully at SIGTERM
• App should be robust when a sudden death happen (i. e. hardware failure)
![Page 34: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/34.jpg)
X – Dev / prod parity
• Keep development, staging, and production as similar as possible
• App must be designed for Continuous deployment in mind: gap between prod and dev must be as small as posible
• Code authors are code deployers. No “deployment team”
![Page 35: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/35.jpg)
XI - Logs
• Treat logs as event streams
• A twelve-factor app never concerns itself with routing or storage of its output stream
• App never manages its logfiles: just log to the stream
• Environment maps the stream wherever appropiate
![Page 36: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/36.jpg)
XII – Admin processes
• Run admin/management tasks as one-off processes
• One-off admin processes should be run in an identical environment as the regular long-running processes of the app.
• Admin code must ship with application code to avoid synchronization issues.
![Page 37: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/37.jpg)
When to use microservices?
![Page 38: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/38.jpg)
![Page 39: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/39.jpg)
Microservices are not a free lunch!
• Significant Operations Overhead
• Substantial DevOps Skills Required
• Implicit interfaces management
• Duplication Of Effort
• Distributed System Complexity
• Asynchronicity Is Difficult!
• Testability Challenges
![Page 40: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/40.jpg)
So… when to use them?
• If your organization has a strong devops culture
• Microservices allow to break a very big monolith in small pieces. Eachpiece can be managed by one pizza team.
• Microservices biggest advantage is agility: you can update, test and deploy each microservice in an independent way.
![Page 41: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/41.jpg)
Agility in Microservices
• Amazon is a heavy user of microservices
• A single shop product use case can interact with 100+ microservices
• Amazon deploy to production…
• Once each 11 hours
![Page 42: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/42.jpg)
Agility in Microservices
• Amazon is a heavy user of microservices
• A single shop product use case can interact with 100+ microservices
• Amazon deploy to production…
• Once each 11 hours minutes
![Page 43: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/43.jpg)
Agility in Microservices
• Amazon is a heavy user of microservices
• A single shop product use case can interact with 100+ microservices
• Amazon deploy to production…
• Once each 11 hours minutes seconds
![Page 44: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/44.jpg)
Agility in Microservices
• NEVER try to use microservices if the organization do not have anstrong Devops culture
• NEVER try to use microservices if a CI/CD pipeline is not established
• Doing Microservices is harder then doing Monoliths. Onlyorganizations that do monoliths well have a chance to do microservices well.
![Page 45: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/45.jpg)
So…
• Use Microservices if really need them
• Don’t use them only because Amazon and Netflix do (probably yourproblems and Amazon problems are not the same).
• Remember: There are not silver bullets
![Page 46: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/46.jpg)
Finally: Serverless
• Serverless means that you don’t need to bother about server management
• A step forward than PaaS
• Services are exposed as functions(FaaS) which are very-micro services!
• Scale per invocation, not per server
• More on this GAPAND at 11:30 by @adiazcan & @shmancebo ;-)
![Page 47: Microservices: Yes or not?](https://reader033.vdocuments.mx/reader033/viewer/2022051123/5a64be147f8b9aa6148b470f/html5/thumbnails/47.jpg)
Thanks!!! Eduard Tomàs – Dev @ Plain concepts@eiximenis
http://geeks.ms/etomas
#Gapand2017