Martin Fowler defines microservices as an architectural style where single applications are developed as independent services that communicate with each other via lightweight mechanisms often using HTTP. Microservices are built around business capabilities, independently deployable, and owned by small teams. When developing microservices, continuous integration, deployment and automated testing are required. An API is not the same as a microservice - APIs expose data and behavior via contracts while microservices implement business capabilities. Microservices should only be used for large, complex systems that are hard to manage as a monolith.
3. ARCHITECTURAL STYLE
"In short, 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. These services are built
around business capabilities and independently deployable by
fully automated deployment machinery. "
Martin Fowler Author, Speaker, Chief Scientist for ThoughtWorks
4. MICROSERVICES ARE…
• Loosely coupled
• Independently deployable
• Organized around business capability
• Owned by small team
• Easily maintained and tested
5.
6. MATURITY IS DEMANDED
“Microservices require a mature delivery capability. Continuous
integration, deployment, and fully automated tests are a must. The
developers who write code must be responsible for it in production. Build
and deployment chains need significant changes to provide the right
separation of concerns for a microservices environment. ”
Kim Clark – IBM Technical Strategist
8. AN API IS NOT A MICROSERVICE
• APIs expose data and behavior to consumers
• APIs are contracts between a system and its consumers
• Microservices is an architectural style
• Microservices are fine grained
• Microservices may make up an API, but there is not a one-to-one
relationship
• More than one microservice may make up a single API endpoint
9.
10. WHEN TO USE MICROSERVICES?
“My primary guideline would be don't even consider microservices unless you have a
system that's too complex to manage as a monolith. The majority of software systems
should be built as a single monolithic application. Do pay attention to good modularity
within that monolith, but don't try to separate it into separate services.
The complexity that drives us to microservices can come from many sources including
dealing with large teams, multi-tenancy, supporting many user interaction models, allowing
different business functions to evolve independently, and scaling. But the biggest factor is
that of sheer size - people finding they have a monolith that's too big to modify and deploy.”
Martin Fowler Author, Speaker, Chief Scientist for ThoughtWorks
12. TRADITIONALLY…
• Development teams deploy applications to one or more servers
• Servers are managed by development or DevOps teams
• Development or DevOps teams are responsible for ensuring uptime, applying security
updates, patches, etc.
• Teams must manage scaling up and or out as demand increases or decreases
• Equipment, licensing, maintenance and people all equate to $$$
13. SERVERLESS
• Cloud provider concept
• Cloud providers execute code by
dynamically allocating resources
• Charged only for what you use
• Code executed is stateless and triggered by
various events (http, file upload, database
event, queues, etc.)
• Development & DevOps teams are
abstracted away from maintaining servers
• Scaling is automatically handled by cloud
providers
15. PROBLEM
• Potential customers have either a leak or clog and require a
plumber quickly
• Plumbing issues occur at inconvenient times
• Plumbing rates can vary from company to company and times
of the day or year
• How do you know what plumber is reputable?
16. SOLUTION
• Provide a service where all plumbers have been previously
“vetted”
• Plumbers agree to work under Fix-a-Leak fixed rates
• Customers use Fix-a-Leak app to submit a job anytime of the
day
• Available plumbers near by are notified and accept the job
• Fix-a-Leak monitors the job and communicates with the
customer
17. S I M P L E W O R K F LO W
Basic flow of the Fix-a-leak
service is starts with a
customer submitting a job.
Plumber have the chance to
accept the job on a first-
come first-serve basis.
Once the job is started
other plumbers are notified
and we monitor the
progress.