We decide to dig into the details of what makes a microservice and do we really understand them as Joe tells us why we really want microservices, Allen incorrectly answers the survey, and Michael breaks down in real time.
The full show notes for this episode are available at https://www.codingblocks.net/episode165. Stop by, check it out, and join the conversation.
Sponsors
- Datadog – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
Survey Says
News
- Want to know why we're so hot on Skaffold? Check out this video from Joe: Getting Started with Skaffold (YouTube)
- Atlanta Code Camp is coming up October 9th, come hang out at the CB booth!
Want to know what's up with Skaffold?
We Thought We Knew About Microservices
What are Microservices?
- A collection of services that are…
- Highly maintainable and testable
- Loosely coupled (otherwise you just have a distributed monolith!)
- Independently deployable
- Organized around business capabilities (super important, Microservices are just as much about people organization as they are about code)
- Owned by a small team
- A couple from Jim Humelsine (Design Patterns Evangelist)
- Stateless
- Independently scalable (both in terms of tech, but also personnel)
- Note: we didn't say anything about size but Sam Newman's definition is: "Microservices are small, autonomous services that work together."
- Semantic Diffusion (vague term getting vaguer)
- Enables frequent and reliable delivery of complex applications
- Allows you to evolve your tech stack (reminiscent of the strangler pattern)
- They are NOT a silver bullet – Many downsides
A Pattern Language
- A collection of patterns for apply microservice patterns
- Example Microservice Implementation: https://microservices.io/patterns/microservices.html
- 3 micro-services in the example:
- Inventory service
- Account service
- Shipping service
- Each services talks to a separate backend database – i.e., inventory service talks to inventory DB, etc.
- Fronting those micro-services are a couple of API's – a mobile gateway API and an API that serves a website
When an order is placed, a request is made to the mobile API to place the order, the mobile API has to make individual calls to each one of the individual micro-services to get / update information regarding the order - This setup is in contrast to a monolithic setup where you'd just have a single API that talks to all the backends and coordinates everything itself
Pros of the Microservice Architecture
- Each service is small so it's easier to understand and change
- Easier / faster to test as they're smaller and less complex
- Better deployability – able to deploy each service independently of the others
- Easier to organize development effort around smaller, autonomous teams
- Because the code bases are smaller, the IDEs are actually better to work in
- Improved fault isolation – example they gave is a memory leak won't impact ALL parts of the system like in a monolithic design
- Applications start and run faster when they are smaller
- Allows you to be more flexible with tech stacks – you can change out small pieces rather than entire systems if necessary
Cons of the Microservice Approach
- Additional complexity of a distributed system
- Distributed debugging is hard! Requires additional tooling
- Additional cost (overhead of services, network traffic)
- Multi-system transactions are really hard
- Implementing inter-service communication and handling of failures
- Implementing multi-service requests is more complex
- Not only more complex, but you may be interfacing with multiple developer teams as well
- Testing interactions between services is more complex
- IDEs don't really make distributed application development easier – more geared towards monolithic apps
- Deployments are more complex – managing multiple services, dependencies, etc.
- Increased infrastructure requirements – CPU, memory, etc.
- Distributed debugging is hard! Requires additional tooling
How to Know When to Choose the Microservice Architecture
This is actually a hard problem.
- Choosing this path can slow down development
- However, if you need to scale in the future, splitting apart / decomposing a monolith may be very difficult
Decomposing an Application into Microservices
- Do so by business capability
- Example for e-commerce: Product catalog management, Inventory management, Order management, Delivery management
- How do you know the right way to break down the business capabilities?
- Organizational structure – customer service department, billing, shipping, etc
- Domain model – these usually map well from domain objects to business functions
- Which leads to decomposing by domain driven design
- Decompose by "verb" – ship order, place order, etc
- Decompose by "noun" – Account service, Order service, Billing service, etc
- Follow the Single Responsibility Principal – similar to software design
Questions About Microservices
- Are Microservices a conspiracy?
- Isn't this just SOA over again?
- How can you tell if you should have Microservices?
- Who uses Microservices?
- Netlifx
- Uber
- Amazon
- Lots of other big companies
- Who has abandoned Microservices?
- Lots of small companies…seeing a pattern here?
Resources We Like
Tip of the Week
- NeoVim is a fork of Vim 7 that aims to address some technical debt in vim in hopes of speeding up maintenance, plugin creation, and new features. It supports RPC now too, so you can write vim plugins in any language you want. It also has better support for background jobs and async tasks. Apparently the success of nvim has also led to some of the more popular features being brought into vim as well. Thanks Claus/@komoten! (neovim.io)
- Portable Apple Watch charger lets you charge your watch wirelessly from an outlet, or a usb. Super convenient! (Amazon)
- Free book from Linode explaining how to secure your Docker containers. Thanks Jamie! (Linode)
- There is a daily.dev plugin for Chrome that gives you the dev home page you deserve, delivering you dev news by default. Thanks @angryzoot! (Chrome Web Store)
- SonarQube is an open-source tool that you can run on your code to pull metrics on it's quality. And it's available for you to run in docker Thanks Derek Chasse! (hub.docker.com)
The macro problem with microservices (Stack Overflow)