Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Save 42% off Microservices in
Action with code slbruce at
manning.com.
Imagine that you’re a developer for SimpleBank.
You have designed a feature for SimpleBank that involves the
interaction o...
When using public clouds like AWS or GCE, the obvious
solution is to deploy each service to a group of virtual
machines.
L...
Long story short, let’s say that you compiled that code, ftp’d it
onto those VMs, got the databases up and running, and tr...
This arrangement worked well enough… for a while.
Over the next few weeks, you made a few changes and
pushed out the new c...
A few problems soon reared their ugly heads:
you were the only person at SimpleBank who knew how to
release a new version...
From the info at hand, it’s probably safe to say that your
feature was deployed prematurely.
How can we ensure that a micr...
We need to consider the following:
Reliability: is our service available and error-free? Can we
rely on our deployment pr...
At this early stage in the lifetime of our microservice
application, it is most important to establish the following two
f...
The greater development speed that comes with using the
microservice architecture won’t be of much use if you can’t get
se...
Companies are often tempted to impose change control and
approval processes – to avoid problematic deployments.
In a micro...
To ensure that developmental freedom and flexibility, and to
minimize the occurrence of errors and outages, we need two
th...
We can achieve stability through standardization and
automation:
The development process should be standardized: code
cha...
A microservice should be transparent: at any point in time, we
should be able to determine whether the service is healthy
...
Last week, there was an
outage at SimpleBank that
affected every customer. This
image shows the possible
points of failure...
A quick investigation turned up that requests made to our
order creation service were timing out.
At this point, it was cl...
Through a combination of manual testing, we managed to
isolate the problem: the Account Transaction service was
unresponsi...
To stop this from happening again, we decided to make a
change:
we set up infrastructure to aggregate the basic logs that...
A logging collection agent is
installed on each instance. This
ships application log data to a
central repository where th...
However, inadequate logging wasn’t the only problem. It was
embarrassing that SimpleBank only identified an issue once
a c...
Building thorough monitoring for a microservice application is
a complex task. The level of depth of monitoring that you a...
Save 42% off Microservices in
Action with code slbruce at
manning.com.
Also see:
Microservices in Action: putting microservice-based applications into production
Upcoming SlideShare
Loading in …5
×

Microservices in Action: putting microservice-based applications into production

1,638 views

Published on

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

Published in: Software
  • Be the first to comment

Microservices in Action: putting microservice-based applications into production

  1. 1. Save 42% off Microservices in Action with code slbruce at manning.com.
  2. 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. 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. 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.
  5. 5. 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.
  6. 6. 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!
  7. 7. 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?
  8. 8. 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?
  9. 9. 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.
  10. 10. 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.
  11. 11. 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!
  12. 12. 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
  13. 13. 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.
  14. 14. 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.
  15. 15. Last week, there was an outage at SimpleBank that affected every customer. This image shows the possible points of failure within the service.
  16. 16. 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.
  17. 17. 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.
  18. 18. 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.
  19. 19. 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.
  20. 20. 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.
  21. 21. 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.
  22. 22. Save 42% off Microservices in Action with code slbruce at manning.com. Also see:

×