Microservices in Action is a practical book about building and deploying microservice-based applications. Written for developers and architects with a solid grasp of service-oriented development, it tackles the challenge of putting microservices into production. Save 42% off Microservices in Action with code slbruce at: https://www.manning.com/books/microservices-in-action

1. Save 42% off Microservices in
Action with code slbruce at
manning.com.

2. Imagine that you’re a developer for SimpleBank.
You have designed a feature for SimpleBank that involves the
interaction of multiple services, an event queue, and an API
gateway.
Let’s say you’ve taken the next step, built those services, and
now the CEO is pushing you to get those into production.

3. When using public clouds like AWS or GCE, the obvious
solution is to deploy each service to a group of virtual
machines.
Load balancers would be used to spread load evenly across
instances of each web-facing service, while a managed event
queue, such as AWS’s Simple Queue Service, could be used
to distribute events between services.

4. Long story short, let’s say that you compiled that code, ftp’d it
onto those VMs, got the databases up and running, and tried
some test requests.
This all took about a week.
The next slide depicts what your production infrastructure
might look like.

6. This arrangement worked well enough… for a while.
Over the next few weeks, you made a few changes and
pushed out the new code.
But soon, you started to run into trouble. It was hard to tell if
the services were working as expected.

7. A few problems soon reared their ugly heads:
you were the only person at SimpleBank who knew how to
release a new version
the person who wrote the Transaction service went on
holiday for a few weeks, and no one else knew how that was
deployed
These services won’t survive the disappearance of team
members – we’re going to be in a pickle soon!

8. From the info at hand, it’s probably safe to say that your
feature was deployed prematurely.
How can we ensure that a microservice feature is production-
ready, without having to resort to rounds of time-consuming
debates (which slow down deployment) within the
development team?

9. We need to consider the following:
Reliability: is our service available and error-free? Can we
rely on our deployment process?
Scalability: do we understand the resource and capacity
needs of a service? How will we maintain responsiveness
under load?
Transparency: can we observe a service in operation
through logs and metrics? If something goes wrong, is
someone notified?
Fault-tolerance: have we mitigated single points of failure?
How do we cope with the failure of other service
dependencies?

10. At this early stage in the lifetime of our microservice
application, it is most important to establish the following two
fundamentals:
stable, automated deployments
transparent operation
Let’s see how we can address these issues in the scope of
your work at SimpleBank.

11. The greater development speed that comes with using the
microservice architecture won’t be of much use if you can’t get
services to production reliably and rapidly.
The pain of unstable deployments – such as introducing a
serious error – will eliminate any gains in velocity.

12. Companies are often tempted to impose change control and
approval processes – to avoid problematic deployments.
In a microservice architecture, however, this won’t work. The
system will be in a state of continuous evolution, which
allows fast and tangible innovation.
This is likely the reason you’re using microservices in
the first place!

13. To ensure that developmental freedom and flexibility, and to
minimize the occurrence of errors and outages, we need two
things:
we need to ensure that we can trust our development and
deployment processes
we need to minimize the effort required to release or
change a new service

14. We can achieve stability through standardization and
automation:
The development process should be standardized: code
changes should be reviewed, appropriate tests should be
written, and source should be version-controlled.
The deployment process should be standardized and
automated: the delivery of a code change to production
should be thoroughly validated and require minimal
intervention from an engineer.
This is called a deployment pipeline.

15. A microservice should be transparent: at any point in time, we
should be able to determine whether the service is healthy
and whether it’s processing its workload in the way that we
expect.
If something isn’t working correctly, an alert should be going
out to an engineer automatically.

16. Last week, there was an
outage at SimpleBank that
affected every customer. This
image shows the possible
points of failure within the
service.

17. A quick investigation turned up that requests made to our
order creation service were timing out.
At this point, it was clear that we had a major operational
problem, but we lacked logging to determine exactly what
went wrong and where things were falling apart.

18. Through a combination of manual testing, we managed to
isolate the problem: the Account Transaction service was
unresponsive.
The damage, however, was done. Customers had been
unable to place orders for several hours and they weren’t
happy about it.

19. To stop this from happening again, we decided to make a
change:
we set up infrastructure to aggregate the basic logs that our
services produced, sending them to a service that allowed
them to be tagged and searched
This will allow the engineering team to quickly identify and
diagnose problems.

20. A logging collection agent is
installed on each instance. This
ships application log data to a
central repository where they
can be indexed, searched and
analyzed further.

21. However, inadequate logging wasn’t the only problem. It was
embarrassing that SimpleBank only identified an issue once
a customer called.
We should have had alerting in place to ensure that each
service was meeting its responsibilities and service goals.
This could be achieved with a recurring heartbeat check,
which would alert the team if a service becomes
unresponsive.

22. Building thorough monitoring for a microservice application is
a complex task. The level of depth of monitoring that you apply
will evolve as your system increases in complexity and
number of services. As well as the operational metrics and
logging we’ve described, a mature microservice monitoring
solution will address business metrics, inter-service tracing
and infrastructure metrics.
To be able to trust your services, you’ll need to constantly
work at making sense of that data.

23. Save 42% off Microservices in
Action with code slbruce at
manning.com.
Also see: