Please enable JavaScript.
Coggle requires JavaScript to display documents.
Building Microservices: Designing Fine-Grained Systems (The Evolutionary…
Building Microservices: Designing Fine-Grained Systems
Microservices
- We’ll begin with an introduction to microservices, including the key benefits as well as some of the downsides.
Microservices
are
an approach to distributed systems modeled around
business domains
. The fact that
using larger numbers of services
with their own independent life‐ cycles resulted in more
headaches
that had to be dealt with.
Microservices are
small, autonomous
services that work together.
Codebases grow
and it can be difficult to know where a change needs to be made.
Single Responsibility Principle
means we focus our service boundaries on business boundaries.
How
small
is better when you maximize the benefits and downsides of microservice architecture.
Autonomous
means these services need to be able to change independently of each other, and be deployed by themselves without requiring consumers to change.
With
Technology Heterogeneity
we can decide to use different technologies inside each one and pick the right tool for each job.
In a
Resilience
system If one component of a system fails, but that failure doesn’t cascade, you can isolate the problem and the rest of the system can carry on working.
Scaling
with microservices we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.
Ease of Deployment
with microservices, we can make a change to a single service and deploy it independently of the rest of the system.
Organizational Alignment
decrease the problems associated with large teams and large codebases.
Composability
enables fast circumstances changes supported by building things in different ways.
About
SOA
- Service-oriented architecture (SOA) is a design approach where multiple services collaborate to provide some end set of capabilities.
Think Microservices as a specific approach for SOA
Think XP and Scrum as a specific approaches for Agile software development.
No
Silver bullet
- you’ll have to get much better at handling deployment, testing, and monitoring to unlock the benefits we’ve covered so far. You’ll also need to think differently about how you scale your systems and ensure that they are resilient.
The Evolutionary Architect
- the difficulties we face in terms of making trade-offs as architects.
Responsability
- Making sure we have a joined-up technical vision, one that should help us deliver the system
our customers need
.
An advice
: “if I give you advice down at the pub about how to build some‐ thing and it’s wrong, I get held to account.
I could get sued
, as in the eyes of the law I am now a qualified architect and I should be held responsible if I get it wrong.”
The town planner
- Erik Doernenburg first shared with me the idea that we should think of our role more as town planners than architects for the built environment. The town planner does his best to
anticipate these changes
, but accepts that trying to exert direct control over all aspects of what happens is futile. They need to ensure that the system is fit for
purpose now
, but also a platform for the future.
The context
- That means we need to spend time thinking about how our services
talk to each other
, or ensuring that we can properly monitor the overall
health
of our system. Making decisions in system design is all about
trade-offs
.
A tip:
“be worried about what happens between the boxes, and
be liberal
in what happens inside.”
The tools
- Your inclination/
freedom
to let teams
pick the right tool
for the job may be tempered by the fact that it becomes harder to hire people or move them between teams if you have 10 different technology stacks to support.
Strategic goals, principles and practices
- The key is that this is where your organization is headed, so you need to make sure the technology is aligned to it. Over the course of a couple years, the practices on the far right will change fairly regularly, whereas
the principles remain fairly static
.
Guidelines
- Our practices are how we ensure our principles are being carried out. They are a set of detailed, practical guidance for performing tasks. They will often be technology specific, and should be low level enough that any developer can understand them.
One of the key ways to identify what should be constant from service to service is to define what a
well-behaved, good service looks like
.
Practical examples or templates
- But developers also like code, and code they can run and explore. If you have a set of standards or best practices you would like to encourage, then having exemplars that you can point people to is useful.
Technical Debt
- The architect’s job is to look at the bigger picture, and understand this balance. Having some view as to the level of debt, and where to get involved, is important.
Building a team
- I am a strong believer that great software comes from great people.
Bullet points
- But the worst reaction to all these forces that push us toward change is to become more rigid or
fixed in our thinking
.
Vision
- Ensure there is a clearly communicated technical vision for the system that will help your system meet the requirements of your customers and organization.
Empathy
- Understand the impact of your decisions on your customers and colleagues.
Collaboration
- Engage with as many of your peers and colleagues as possible to help define, refine, and execute the vision.
Adaptability
- Make sure that the technical vision changes as your customers or organization requires it.
Autonomy
- Find the right balance between standardizing and enabling autonomy for your teams.
Governance
- Ensure that the system being implemented fits the technical vision.
How to Model Services
- define the boundary of microservices, using techniques from domain-driven design.