Book Image

Building Microservices with Go

By : Nic Jackson
Book Image

Building Microservices with Go

By: Nic Jackson

Overview of this book

Microservice architecture is sweeping the world as the de facto pattern to build web-based applications. Golang is a language particularly well suited to building them. Its strong community, encouragement of idiomatic style, and statically-linked binary artifacts make integrating it with other technologies and managing microservices at scale consistent and intuitive. This book will teach you the common patterns and practices, showing you how to apply these using the Go programming language. It will teach you the fundamental concepts of architectural design and RESTful communication, and show you patterns that provide manageable code that is supportable in development and at scale in production. We will provide you with examples on how to put these concepts and patterns into practice with Go. Whether you are planning a new application or working in an existing monolith, this book will explain and illustrate with practical examples how teams of all sizes can start solving problems with microservices. It will help you understand Docker and Docker-Compose and how it can be used to isolate microservice dependencies and build environments. We finish off by showing you various techniques to monitor, test, and secure your microservices. By the end, you will know the benefits of system resilience of a microservice and the advantages of Go stack.
Table of Contents (18 chapters)
Title Page
Credits
About the Author
About the Reviewers
www.PacktPub.com
Customer Feedback
Preface
Index

Logging best practices


In the free e-book, The Pragmatic Logging Handbook, by Jon Gifford of Loggly (https://www.loggly.com/), Jon proposes the following eight best practices to apply when determining your logging strategy:

  • Treat application logging as an ongoing iterative process. Log at a high level and then add deeper instrumentation.
  • Always instrument anything that goes out of the process because distributed system problems are not well behaved.
  • Always log unacceptable performance. Log anything outside the range in which you expect your system to perform.
  • If possible, always log sufficient context for a complete picture of what happened from a single log event.
  • View machines as your end consumer, not humans. Create records that your log management solution can interpret.
  • Trends tell the story better than data points.
  • Instrumentation is NOT a substitute for profiling and vice versa.
  • Flying more slowly is better than flying blind. So the debate is not whether to instrument, just how much.

I think...