In this chapter, you'll see some code examples using Go. I recommend that you install Go and try to build and run the code examples yourself.

On macOS, I recommend using Homebrew:

$ brew install go

Next, make sure the go command is available:

$ ls -la `which go`
lrwxr-xr-x  1 gigi.sayfan  admin  26 Nov 17 09:03 /usr/local/bin/go -> ../Cellar/go/1.11.2/bin/go

To see all the options, just type go. Also, make sure that you define GOPATH in your .bashrc file and add $GOPATH/bin to your path.

Go comes with the Go CLI that provides many capabilities, but you may want to install additional tools. Check out https://awesome-go.com/.

Think about the time you learned to program. You wrote little programs that accepted simple input, did a little processing, and produced some output. Life was good. You could hold the entire program in your head.

You understood every line of code. Debugging and troubleshooting was easy. For example, consider a program to convert temperatures between Celsius and Fahrenheit:

package main

import (
        "fmt"
        "os"
        "strconv"
)

func celsius2fahrenheit(t float64) float64 {
        return 9.0/5.0*t + 32
}

func fahrenheit2celsius(t float64) float64 {
        return (t - 32) * 5.0 / 9.0
}

func usage() {
      fmt.Println("Usage: temperature_converter <mode> <temperature>")
      fmt.Println()
      fmt.Println("This program converts temperatures between Celsius and Fahrenheit&quot...

One of the best ways to fight complexity is to make your microservice autonomous. An autonomous service is a service that doesn't depend on other services in the system or third-party services. An autonomous service manages its own state and can be largely unaware of the rest of the system.

I like to think of autonomous microservices as similar to immutable functions. Autonomous services never change the state of other components in the system. The benefit of such services is that their complexity remains the same, regardless of how the rest of the system evolves and however they are being used by other services.

Interfaces are one of the best tools a software engineer can use. Once you expose something as an interface, you can freely change the implementation behind it. Interfaces are a construct that's being used within a single process. They are extremely useful for testing interactions with other components, which are plentiful in microservice-based systems. Here is one of the interfaces of our sample application:

type UserManager interface {
   Register(user User) error
   Login(username string, authToken string) (session string, err error)
   Logout(username string, session string) error
}

The UserManager interface defines a few methods, their inputs, and outputs. However, it doesn't specify the semantics. For example, what happens if the Login() method is called for an already logged-in user? Is it an error? Is the previous session terminated...

Microservices interact with each other and sometimes with the outside world over the network. A service exposes its capabilities through an API. I like to think of APIs as over-the-wire interfaces. Programming language interfaces use the syntax of the language they are written in (for example, Go's interface type). Modern network APIs also use some high-level representation. The foundation is UDP and TCP. However, microservices will typically expose their capabilities over web transports, such as HTTP (REST, GraphQL, SOAP), HTTP/2 (gRPC), or, in some cases, WebSockets. Some services may imitate other wire protocols, such as memcached, but this is useful in special situations. In 2019, there is really no reason to build your own custom protocol directly over TCP/UDP or use proprietary and language-specific protocols. Approaches such as Java RMI...

Interfaces are very convenient to work with. You operate within your programming language environments, calling methods with native data types. Working with network APIs is different. You need to use a network library, depending on the transport. You need to serialize your payload and responses and deal with network errors, disconnects, and timeouts. The client library pattern encapsulates the remote service and all these decisions and presents you with a standard interface that, as a client of the service, you just call. The client library behind the scenes will take care of all the ceremony involved with invoking a network API. The law of leaky abstractions (https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) says that you can't really hide the network. However, you can hide it pretty effectively from the consumer service and...

Modern systems have a lot of dependencies. Managing them effectively is a big part of the software development life cycle (SDLC). There are two kinds of dependencies:

• Libraries/packages (linked to the running service process)
• Remote services (accessible over the network)

Each of these dependencies can be internal or third party. You manage libraries or packages through your language's package management system. Go had no official package management system for a long time and several solutions, such as Glide and Dep, came along. These days (Go 1.12), Go modules are the official solution.

You manage remote services through the discovery of endpoints and tracking API versions. The difference between internal dependencies and third-party dependencies is the velocity of change. Internal dependencies will change much faster. With microservices, you&apos...

When comparing a monolith system with a microservice-based system, one thing is clear. There is more of everything. The individual microservices are simpler and it's much easier to reason, modify, and troubleshoot individual services. But, understanding the whole system, making changes across multiple services, and debugging problems are more challenging. Many more interactions also happen over the network between separate microservices, where, with a monolith, these interactions would occur within the same process. It means that to benefit from microservices, you need a disciplined approach, you need to apply best practices, and have good tools at your disposal.

Since microservices are small. A single developer can own a whole microservice and understand it completely. Other developers may also be familiar with it, but even if just a single developer is familiar with a service, it should be relatively simple and painless for a new developer to take over because the scope is so limited and ideally similar.

Sole ownership can be very powerful. The developer needs to communicate with the other developers and teams though the service API, but can iterate very fast on the implementation. You may still want other developers on the team to review the internal design and implementation, but even in the extreme case that the owner works completely on their own with no supervision, the potential damage is limited because the scope of each microservice is small and it interacts with the rest of the system through well...

Conway's law is defined as follows:

This means the structure of the system will reflect the structure of the team building it. A famous variation by Eric Raymond is this:

This is very insightful and I've personally witnessed it time and again in many different organizations. This is very relevant to microservice-based systems. With lots of small microservices, you don't need a dedicated team for each microservice. There will be some higher-level groups of microservices that work together to produce some aspect of the system. Now, the question is how to think about the high-level structure...

Since most of the functions of the system will involve interactions between multiple microservices, it's important to be able to follow a request coming in across all those microservices and various data stores. One of the best ways to accomplish this is distributed tracing, where you tag each request and can follow it from beginning to end.

The subtleties of debugging distributed systems in general and microservice-based ones take a lot of expertise. Consider the following aspects along the path of a single request through the system:

• The microservices processing the request may use different programming languages.
• The microservices may expose APIs using different transports/protocols.
• Requests may be part of asynchronous workflows that involve waiting in queues and/or periodical processing.
• The persistent state of the request may...

If you choose the uniform microservices approach, it is very useful to have a shared library (or several libraries) that all services use and implement many cross-cutting concerns, such as the following:

• Configuration
• Secret management
• Service discovery
• API wrapping
• Logging
• Distributed tracing

This library may implement whole workflows, such as authentication and authorization, that interact with other microservices or third-party dependencies and do the heavy lifting for each microservice. This way, the microservice is only responsible for using these libraries properly and implements its own functionality.

This approach can work even if you choose the polyglot path and support multiple languages. You can implement this library for all the supported languages and the services themselves can be implemented in different languages.

However, there...

This is a very interesting scenario. There are two main approaches: monorepo and multiple repos. Let's explore the pros and cons of each.

In the monorepo approach, your entire code base is in a single source control repository. It is very easy to perform operations over the entire code base. Whenever you make a change, it is reflected immediately in your entire code base. Versioning is pretty much off the table. That's great for keeping all your code in sync. But, if you do need to upgrade some parts of your systems incrementally, you'll need to come up with workarounds, such as creating a separate copy with your new changes. Also, the fact that your source code...

One the most important responsibilities of a software system is to manage data. There are many types of data, and most of the data, should survive any failure of the system or you should be able to reconstruct it. Data often has complex relationships with other data. This is very explicit with relational databases, but exists in other types of data, too. Monoliths typically use large data stores that keep all the related data and, as a result, can perform queries and transactions over the entire set of data. Microservices are different. Each microservice is autonomous and responsible for its data. However, the system as a whole needs to query and operate over data that is now stored in many independent data stores and managed by many different services. Let's examine how to address this challenge using best practices.

In this chapter, we covered a lot of ground. We discussed the basic principle of microservices—less is more—and how breaking down your system to many small and self-contained microservices can help it scale. We also discussed the challenges that face developers utilizing the microservices architecture. We provided a slew of concepts, options, best practices, and pragmatic advice on architecting microservice-based systems. At this point, you should appreciate the flexibility that microservices offer, but also be a little apprehensive of the many ways you can choose to utilize them.

In the rest of the book, we will explore the terrain in detail and together build a microservice-based system using some of the best available frameworks and tools and deploy it on Kubernetes. In the next chapter, you'll meet Delinkcious—our sample application—...

If you are interested in microservices, I recommend the following article as a starting point: https://www.martinfowler.com/