Microservices are a service-oriented architecture composed of loosely coupled elements that have bounded contexts. Each microservice can be updated independently without risking other services. Considerations for microservices include the complexity of building distributed systems, increased number of components to manage, steps needed to maintain data consistency across services, and increased network latency and API traffic. Iron.io advocates for empowering developers by providing abstraction, self-service tools, and focusing on code.
2. About Iron.io
Infrastructure
Runtime Apps Async Workloads
APIs
>50% of the modern workload processing
happens in the background asynchronously.
IronMQ IronScheduler
IronWorker
5. A service-oriented architecture composed of
loosely coupled elements that have bounded contexts.
Microservices
Every service can be updated
independently and without risk
Model where you don’t need to
know internals of peer services.
Adrian Cockcroft, Battery Ventures
(previously lead cloud architect for Netflix)
6. Monolith vs Microservices
All functions, single process Single function per process
scale by replicating monolith across nodes scale by distributing services across nodes
7. Considerations
➔ Building and maintaining highly available
distributed systems is complex
➔ More moving parts means more components to
keep track of and configure properly
➔ Loosely coupled services means steps must be
taken to keep data consistent
➔ Distributed asynchronous processes create
network latency and more API traffic
➔ Testing and monitoring individual services is
challenging
9. Empowering Developers
⬢ Innovation depends on developers
⬢ Developers want abstraction
⬢ Developers want self-service
⬢ Developers want tools to get out of the
way
⬢ Developers want to write code!
10. Code API
URL HTTP Verb Purpose
/projects/{Project ID}/codes GET List Code Packages
/projects/{Project ID}/codes POST Upload or Update a Code Package
/projects/{Project ID}/codes/{Code ID} GET Get Info About a Code Package
/projects/{Project ID}/codes/{Code ID} DELETE Delete a Code Package
/projects/{Project ID}/codes/{Code ID}/download GET Download a Code Package
/projects/{Project ID}/codes/{Code ID}/revisions GET List Code Package Revisions
IronWorker makes it easy to write, package, and upload code to our system
11. Task API
URL HTTP Verb Purpose
/projects/{Project ID}/tasks GET List Tasks
/projects/{Project ID}/tasks POST Queue a Task
/projects/{Project ID}/tasks/webhook POST Queue a Task From a Webhook
/projects/{Project ID}/tasks/{Task ID} GET Get Info About a Task
/projects/{Project ID}/tasks/{Task ID}/log GET Get a Task's Log
/projects/{Project ID}/tasks/{Task ID}/cancel POST Cancel a Task
/projects/{Project ID}/tasks/{Task ID}/progress POST Set a Task's Progress
/projects/{Project ID}/tasks/{Task ID}/retry POST Retry a Task
16. Stateless using Webhooks
● Job can be kicked off using a webhook
URL and HTTP Post
● Create powerful workflow between
workers, services, and other endpoints
17. Case Study
● Before: A single process that handles the entire ETL pipeline
● After: A set of stateless services that only understand their single
purpose functions. Each scale independently.
Result: Dozens of sources syncing 24x7 with NO infrastructure
Cloud ETL
18. Queue all the Things
➔ Decouples
➔ Buffers
➔ Delivery/Order properties
➔ Async Communication
19. Services: Collection, Process, Send
● Intelligent speed bumps that activate only when needed
● Road modules collect speed, vehicle type, and other data
● Ops gains intelligence for traffic management and flow
Result: Faster and simpler data collection
and processing
Case Study
IoT Data Collection and Processing
20. Containerize Everything
⬢ Can be any but Docker is winning
⬢ Stateless and horizontal scaling
⬢ Deploy anywhere
⬢ Enables full developer workflow and CI/CD
26. Iron.io
325 9th St
San Francisco, CA 94103
1-888-939-4623
www.iron.io
sales@iron.io
THANK YOU
QUESTIONS?
Editor's Notes
This is part 1 of a series of webinars on Microservices architecture for the modern enterprise. We will start broad and gather a high-level understanding and feel for the architecture using use cases and stories from some of our customers. These techniques can of course be applied whether or not you use the Iron platform to deploy and orchestrate your microservices.
Broad then dive into a little code.
In the next webinar we’ll discuss building an individual microservice, and then follow that with managing dozens of them in a live environment.
Github once said 50% of most clock happens in the background
This number is most likely low now with how much heavy lifting computing has been created
Many “i need just this” solutions
Resque, Sidekiq, Starling, Celery, delayed_job, etc etc.
None address from a completely heterogeneous model with inherent multi-tenancy and “as a service” built in
Update independently and without knowing anything about the internals of another service
Microservices are inherently distributed
Exponentially more difficult to design and develop
network latency, implicit interfaces, unreliably networks, async,
Assume a monolithic service with 99.99% uptime
Now imagine 30 microservices with that SLA..
The story goes -- at an Amazon executive offsite, one manager said “we need more communication”. Jeff responded: “No. Communication is horrible!”
n(n-1) / 2 == links in group
Conways Law: organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations