Book Image

Python Microservices Development – 2nd edition - Second Edition

By : Simon Fraser, Tarek Ziadé
Book Image

Python Microservices Development – 2nd edition - Second Edition

By: Simon Fraser, Tarek Ziadé

Overview of this book

The small scope and self-contained nature of microservices make them faster, cleaner, and more scalable than code-heavy monolithic applications. However, building microservices architecture that is efficient as well as lightweight into your applications can be challenging due to the complexity of all the interacting pieces. Python Microservices Development, Second Edition will teach you how to overcome these issues and craft applications that are built as small standard units using proven best practices and avoiding common pitfalls. Through hands-on examples, this book will help you to build efficient microservices using Quart, SQLAlchemy, and other modern Python tools In this updated edition, 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. Python Microservices Development, Second Edition describes how to use containers and AWS to deploy your services. By the end of the book, you’ll have created a complete Python application based on microservices.
Table of Contents (14 chapters)
Other Books You May Enjoy

Multi-cloud deployments

When assessing the risks involved in running a service, it's easy to come to the realization that your organization is completely dependent on one cloud provider. A common desire to improve redundancy is to deploy services to multiple providers and spread the workload across Azure, GCP, Amazon, and others. This might seem like a great idea, but it also introduces a lot of complexity as different providers have different feature sets available, will need unique security arrangements, and be unable to share storage and secrets management.

While Terraform can help with this situation, it is often more achievable to aim for multiple regions within the same provider, and if several cloud providers are really required, to separate what's running in them based on how things interact. It's far easier to put a completely independent service somewhere else. There are parallels with the strategic approach and splitting a monolith into microservices...