Microservices are a way to organize complex software systems. Instead of putting all your code into one app, you break your app into microservices that are deployed independently and communicate with each other. This tutorial teaches you how to get up and running with Python microservices using gRPC, one of the most popular frameworks.
Implementing a microservices framework well is important. When you’re building a framework to support critical applications, you must ensure it’s robust and developer-friendly. In this tutorial, you’ll learn how to do just that. This knowledge will make you more valuable to growing companies.
In order to benefit most from this tutorial, you should understand the basics of Python and web apps. If you’d like a refresher on those, read through the links provided first.
By the end of this tutorial, you’ll be able to:
- Implement microservices in Python that communicate with one another over gRPC
- Implement middleware to monitor microservices
- Unit test and integration test your microservices and middleware
- Deploy microservices to a Python production environment with Kubernetes
You can download all the source code used in this tutorial by clicking the link below:
Get the Source Code: Click here to get the source code you’ll use to learn about creating Python microservices with gRPC in this tutorial.
Why Microservices?
Imagine you work at Online Books For You, a popular e-commerce site that sells books online. The company has several hundred developers. Each developer is writing code for some product or back-end feature, such as managing the user’s cart, generating recommendations, handling payment transactions, or dealing with warehouse inventory.
Now ask yourself, would you want all that code in one giant application? How hard would that be to understand? How long would it take to test? How would you keep the code and database schemas sane? It definitely would be hard, especially as the business tries to move quickly.
Wouldn’t you rather have code corresponding to modular product features be, well, modular? A cart microservice to manage carts. An inventory microservice to manage inventory.
In the sections below, you’ll dig a bit deeper into some reasons to separate Python code into microservices.
Modularity
Code changes often take the path of least resistance. Your beloved Online Books For You CEO wants to add a new buy-two-books-get-one-free feature. You’re part of the team that’s been asked to launch it as quickly as possible. Take a look at what happens when all your code is in a single application.
Being the smartest engineer on your team, you mention that you can add some code to the cart logic to check if there are more than two books in the cart. If so, you can simply subtract the cost of the cheapest book from the cart total. No sweat—you make a pull request.
Then your product manager says you need to track this campaign’s impact on books sales. This is pretty straightforward, too. Since the logic that implements the buy-two-get-one feature is in the cart code, you’ll add a line in the checkout flow that updates a new column on the transactions database to indicate the sale was part of the promotion: buy_two_get_one_free_promo = true. Done.
Next, your product manager reminds you that the deal is valid for only one use per customer. You need to add some logic to check whether any previous transactions had that buy_two_get_one_free_promo flag set. Oh, and you need to hide the promotion banner on the home page, so you add that check, too. Oh, and you need to send emails to people who haven’t used the promo. Add that, too.
Several years later, the transactions database has grown too large and needs to be replaced with a new shared database. All those references need to be changed. Unfortunately, the database is referenced all over the codebase at this point. You consider that it was actually a little too easy to add all those references.
That’s why having all your code in a single application can be dangerous in the long run. Sometimes it’s good to have boundaries.
The transactions database should be accessible only to a transactions microservice. Then, if you need to scale it, it’s not so bad. Other parts of the code can interact with transactions through an abstracted API that hides the implementation details. You could do this in a single application—it’s just less likely that you would. Code changes often take the path of least resistance.
Flexibility
Splitting your Python code into microservices gives you more flexibility. For one thing, you can write your microservices in different languages. Oftentimes, a company’s first web app will be written in Ruby or PHP. That doesn’t mean everything else has to be, too!
You can also scale each microservice independently. In this tutorial, you’ll be using a web app and a Recommendations microservice as a running example.
Your web app will likely be I/O bound, fetching data from a database and maybe loading templates or other files from disk. A Recommendations microservice may be doing a lot of number crunching, making it CPU bound. It makes sense to run these two Python microservices on different hardware.
Robustness
Read the full article at https://realpython.com/python-microservices-grpc/ »
[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]
from Real Python
read more
No comments:
Post a Comment