Hands-On Docker for Microservices with Python

Design, deploy, and operate a complex system with multiple microservices using Docker and Kubernetes

Jaime Buelta

• Publisher: Packt Publishing
• Year: 2019
• Print ISBN: 9781838823818
• eBook ISBN: 9781838822552
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming in Python
• Index: Computer Science

A step-by-step guide to building microservices using Python and Docker, along with managing and orchestrating them with Kubernetes

Key Features

• Learn to use Docker containers to create, operate, and deploy your microservices
• Create workflows to manage independent deployments on coordinating services using CI and GitOps through GitHub, Travis CI, and Flux
• Develop a REST microservice in Python using the Flask framework and Postgres database

Book Description

Microservices architecture helps create complex systems with multiple, interconnected services that can be maintained by independent teams working in parallel. This book guides you on how to develop these complex systems with the help of containers.

You'll start by learning to design an efficient strategy for migrating a legacy monolithic system to microservices. You'll build a RESTful microservice with Python and learn how to encapsulate the code for the services into a container using Docker. While developing the services, you'll understand how to use tools such as GitHub and Travis CI to ensure continuous delivery (CD) and continuous integration (CI). As the systems become complex and grow in size, you'll be introduced to Kubernetes and explore how to orchestrate a system of containers while managing multiple services. Next, you'll configure Kubernetes clusters for production-ready environments and secure them for reliable deployments. In the concluding chapters, you'll learn how to detect and debug critical problems with the help of logs and metrics. Finally, you'll discover a variety of strategies for working with multiple teams dealing with different microservices for effective collaboration.

By the end of this book, you'll be able to build production-grade microservices as well as orchestrate a complex system of services using containers.

What you will learn

• Discover how to design, test, and operate scalable microservices
• Coordinate and deploy different services using Kubernetes
• Use Docker to construct scalable and manageable applications with microservices
• Understand how to monitor a complete system to ensure early detection of problems
• Become well versed with migrating from an existing monolithic system to a microservice one
• Use load balancing to ensure seamless operation between the old monolith and the new service

Who this book is for

This book is for developers, engineers, or software architects who are trying to move away from traditional approaches for building complex multi-service systems by adopting microservices and containers. Although familiarity with Python programming is assumed, no prior knowledge of Docker is required.

Section 1: Introduction to Microservices

This section covers the first chapter of the book. It introduces the microservice architecture and the problems it aims to solve from a classic monolith system.

Chapter 1, Making the Move – Design, Plan, Execute, describes a typical situation for a monolith system, its problems, and how the move to microservices can improve the development speed and independent features implementation. It also produces a plan in several steps to facilitate making the move from the initial unique monolith to a multiple RESTful microservice. It also introduces using Docker to implement the different microservices as containers.

In this section, we describe the example system that we will use throughout the book to give a real example of going from a monolithic application to a microservice architecture.

This section comprises the following chapter:

• Chapter 1, Making the Move – Design, Plan, and Execute

Making the Move – Design, Plan, and Execute

As web services get more and more complex, and software service companies grow in size, we require new ways of working to adapt and increase the speed of change, while setting a high quality standard. Microservices architecture has emerged as one of the best tools to control big software systems, enabled by new tools such as containers and orchestrators. We will start by presenting the differences between the traditional monolith architecture and the microservices architecture, as well as the advantages of moving to the latter. We will cover how to structure an architecture migration and how to plan to succeed in this difficult process.

In this book, we will deal with web server services, though some of the ideas can be used for other kinds of software applications, obviously by adapting them. The monolith/microservice architectures have some similarities with the monolithic/microkernel discussions in operating system design, including the famous debate (https://www.oreilly.com/openbook/opensources/book/appa.html) between Linus Torvalds and Andrew S. Tanenbaum, back in 1992. This chapter is relatively agnostic about tools, while the following chapters will present specific ones.

The following topics will be covered in this chapter:

• The traditional monolith approach and its problems
• The characteristics of a microservices approach
• Parallel deployment and development speed
• Challenges and red flags
• Analyzing the current system
• Preparing and adapting by measuring usage
• Strategic planning to break the monolith
• Executing the move

At the end of the chapter, you'll be familiar with the basic concepts we will be using throughout the book, different strategies for how to proceed with and structure work during the migration to microservices, and a practical example that we will be working on in the remaining chapters.

Technical requirements

This chapter does not focus on specific technologies, going for a more agnostic approach. We will discuss a Python Django application for our monolith example.

The monolith example can be found at: https://github.com/PacktPublishing/Hands-On-Docker-for-Microservices-with-Python/tree/master/Chapter01/Monolith. Installation and running instructions can be found in its README.md file.

The traditional monolith approach and its problems

The traditional approach to the software when developing a system has been to create a monolith. This is a fancy word to say a single element, containing everything, and it is the way virtually every project starts. In the context of web applications, that means creating deployable code that can be replicated so that requests can be directed to any of the deployed copies:

After all, every project will start off small. Making strict divisions early on is inconvenient and even doesn't make sense. A newly created project is small and probably handled by a single developer. While the design can fit in the head of a few people, making strict boundaries between parts of the system is counterproductive.

There are a lot of options for running a web service, but one will typically consist of one or more servers (physical boxes, virtual machines, and cloud instances such as EC2 and more) running a web server application (such as NGINX or Apache) to direct requests directed to HTTP port 80 or HTTPS port 443 toward one or more Python workers (normally, through the WSGI protocol), run by mod_wsgi—https://github.com/GrahamDumpleton/mod_wsgi (Apache only), uWSGI, GNUnicorn, and so on.

If more than one server is used, there will be a load balancer to spread the load among them. We'll talk about them later in this chapter. The server (or load balancer) needs to be accessible on the internet, so it will have a dedicated DNS and a public IP address.

In other programming languages, the structure will be similar: a frontend web server that exposes the port in HTTP/HTTPS, and a backend that runs the monolith code in a dedicated web worker.

But things change, successful software grows and, after some time, having a big ball of code is maybe not the best way of structuring a big project.

Monoliths can have, in any case, internal structure, meaning they don't necessarily get into the realms of spaghetti code. It may be perfectly structured code. What defines a monolith is the requirement to deploy the system as a whole, without being able to make partial deployments.

Spaghetti code is a common way of referring to code that lacks any structure and is difficult to read and follow.

As the monolith grows, some of its limitations will start to show up:

• The code will increase in size: Without strict boundaries between modules, developers will start having problems understanding the whole code base. While good practices can help, the complexity naturally tends to increase, making it more difficult to change the code in certain ways and increasing subtle bugs. Running all tests will become slow, decreasing the speed of any Continuous Integration system.
• Inefficient utilization of resources: Each individual deployed web worker will require all the resources required for the whole system to work, for example, the maximum amount of memory for any kind of request, even if a request that demands a lot of memory is rare and just a couple of workers will be sufficient. The same may happen with the CPU. If the monolith connects to a database, each individual worker will require a connection to it, whether that's used regularly or not, and so on.
• Issues with development scalability: Even if the system is perfectly designed to be horizontally scalable (unlimited new workers can be added), as the system grows and the development team grows, development will be more and more difficult without stepping on each other's toes. A small team can coordinate easily, but once several teams are working on the same code base, the probability of clashing will increase. Imposing boundaries for teams in terms of ownership and responsibility can also become blurry unless strict discipline is enforced. In any case, teams will need to be actively coordinated, which reduces their independence and speed.
• Deployment limitations: The deployment approach will need to be shared across teams, and teams can't be individually responsible for each deployment, as deployment will probably involve work for multiple teams. A deployment problem will bring down the whole system.
• Interdependency of technologies: Any new tech needs to fit with the tech in use in the monolith. A new technology, for example, a tool that's perfect for a particular problem, may be complicated to add to the monolith, due to a mismatch of technologies. Updating dependencies can also cause issues. For example, an update to a new version of Python (or a submodule) needs to operate with the whole code base. Some required maintenance tasks, such as a security patch, can cause a problem just because the monolith already uses a specific version of a library, which will break if changed. Adapting to these changes requires extra work too.
• A bug in a small part of the system can bring down the whole service: As the service is a whole, any critical issue that affects the stability affects everything, making it difficult to generate quality service strategies or causing degraded results.

As you can see in the examples, most of the monolith issues are growing issues. They are not really important unless the system has a sizeable code base. There are some things that work very well in monoliths, such as the fact that, because there are no boundaries in the code, the code can be changed very quickly and efficiently. But as teams grow and more and more developers are working in the system, boundaries help to define objectives and responsibilities. Too much flexibility becomes a problem in the long term.

The characteristics of a microservices approach

The monolith approach works until the point it doesn't. But, what is the alternative? That's where the microservices architecture enters into the scene.

A system following a microservices architecture is a collection of loosely coupled specialized services that work in unison to provide a comprehensive service. Let's divide the definition a bit, in more specific terms:

1. A collection of specialized services, meaning that there are different, well-defined modules.
2. Loosely coupled, meaning that each of the microservices can be independently deployed.
3. That work in unison—each microservice is capable of communicating with others.
4. To provide a comprehensive service, because our microservice system will need to replicate the same functionalities that were available using a monolith approach. There is an intent behind its design.

In contrast to the previous diagram, the microservice architecture will look like this:

Each of the external requests will be channeled to either Microservice A or Microservice B, each one specializing in a particular kind of requests. In certain cases, Microservice B communicates with Microservice C, not directly available externally. Note that there may be multiple workers per microservice.

There are several advantages and implications to this architecture:

1. If the communication between microservices is done through a standard protocol, each microservice can be programmed in different languages.

Throughout the book, we will use HTTP requests with data encoded in JSON to communicate between microservices. Though there are more options, this is definitively the most standard and widely-used option, as virtually every widely-used programming language has good support for it.

This is very useful in cases where a specialized language is ideal for a specialized problem, but limiting its use so that it is contained, not requiring a drastic change in the company.

2. Better resource utilization—if Microservice A requir...

Table of contents

• Title Page
• Copyright and Credits
• Dedication
• About Packt
• Contributors
• Preface
• Section 1: Introduction to Microservices
• Making the Move – Design, Plan, and Execute
• Section 2: Designing and Operating a Single Service – Creating a Docker Container
• Creating a REST Service with Python
• Build, Run, and Test Your Service Using Docker
• Creating a Pipeline and Workflow
• Section 3:Working with Multiple Services – Operating the System through Kubernetes
• Using Kubernetes to Coordinate Microservices
• Local Development with Kubernetes
• Configuring and Securing the Production System
• Using GitOps Principles
• Managing Workflows
• Section 4: Production-Ready System – Making It Work in Real-Life Environments
• Monitoring Logs and Metrics
• Handling Change, Dependencies, and Secrets in the System
• Collaborating and Communicating across Teams
• Assessments
• Other Books You May Enjoy