Book Overview & Buying
Table Of Contents
Feedback & Rating

Python Microservices Development

4 (5)

Buy this Book

Python Microservices Development

4 (5)

Buy this Book

Overview of this book

We often deploy our web applications into the cloud, and our code needs to interact with many third-party services. An efficient way to build applications to do this is through microservices architecture. But, in practice, it's hard to get this right due to the complexity of all the pieces interacting with each other. This book will teach you how to overcome these issues and craft applications that are built as small standard units, using all the proven best practices and avoiding the usual traps. It's a practical book: you’ll build everything using Python 3 and its amazing tooling ecosystem. You will understand the principles of TDD and apply them. You will use Flask, Tox, and other tools to build your services using best practices. You will learn how to secure connections between services, and how to script Nginx using Lua to build web application firewall features such as rate limiting. You will also familiarize yourself with Docker’s role in microservices, and use Docker containers, CoreOS, and Amazon Web Services to deploy your services. This book will take you on a journey, ending with the creation of a complete Python application based on microservices. By the end of the book, you will be well versed with the fundamentals of building, designing, testing, and deploying your Python microservices.

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Free Chapter

Understanding Microservices

Origins of Service-Oriented Architecture

The monolithic approach

The microservice approach

Microservice benefits

Microservices pitfalls

Implementing microservices with Python

Summary

Discovering Flask

Which Python?

How Flask handles requests

Flask built-in features

A microservice skeleton

Summary

Coding, Testing, and Documenting - the Virtuous Cycle

Different kinds of tests

Using WebTest

Using pytest and Tox

Developer documentation

Continuous Integration

Summary

Designing Runnerly

The Runnerly application

Monolithic design

Splitting the monolith

Data Service

Using Open API 2.0

More splitting

Summary

Interacting with Other Services

Synchronous calls

Asynchronous calls

Testing

Summary

Monitoring Your Services

Centralizing logs

Performance metrics

Summary

Securing Your Services

The OAuth2 protocol

Token-based authentication

Web application firewall

Securing your code

Bringing It All Together

Building a ReactJS dashboard

ReactJS and Flask

Authentication and authorization

Packaging and Running Runnerly

The packaging toolchain

Running all microservices

Process management

Summary

Containerized Services

What is Docker?

Docker 101

Running Flask in Docker

The full stack - OpenResty, Circus and Flask

Docker-based deployments

Summary

Deploying on AWS

AWS overview

Routing - Route53, ELB, and AutoScaling

Execution - EC2 and Lambda

Storage - EBS, S3, RDS, ElasticCache, and CloudFront

Deploying on AWS - the basics

Deploying with ECS

Route53

Summary

What Next?

Iterators and generators

Coroutines

The asyncio library

The aiohttp framework

Sanic

Asynchronous versus synchronous

Customer Reviews

4 (5)

5 star

40%

4 star

40%

3 star

2 star

20%

1 star

Developer documentation

So far, we've looked at the different kinds of tests a microservice can have, and we've mentioned that the documentation should evolve with the code.

We're talking here about developer documentation. This includes everything a developer should know about your microservices project, things such as:

How it's designed
How to install it
How to run the tests
What are the exposed APIs and what data comes in and out, and so on

The Sphinx tool (http://www.sphinx-doc.org/), which was developed by Georg Brandl to document Python itself, became the standard in the Python community.

Sphinx treats documents like source code by separating the content from the layout. The usual way to use Sphinx is to have a docs directory in the project that contains the documentation content, and then call Sphinx's command-line utility to generate the documentation...