Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
Building Serverless Microservices in Python
Building Serverless Microservices in Python

Building Serverless Microservices in Python: A complete guide to building, testing, and deploying microservices using serverless computing on AWS

eBook
€17.98 €19.99
Paperback
€24.99
Subscription
Free Trial
Renews at $19.99p/m

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Product feature icon AI Assistant (beta) to help accelerate your learning
OR
Modal Close icon
Payment Processing...
tick Completed

Billing Address

Table of content icon View table of contents Preview book icon Preview Book

Building Serverless Microservices in Python

Serverless Microservices Architectures and Patterns

Microservices architectures are based on service. You could think of the microservices as a lightweight version of SOA but enriched with more recent architectures, such as the event-driven architecture, where an event is defined as a state of change that's of interest. In this chapter, you will learn about the monolithic multi-tier architecture and monolithic service-oriented architecture (SOA). We will discuss the benefits and drawbacks of both architectures. We will also look at the microservices background to understand the rationale behind its growth, and compare different architectures.

We will cover the design patterns and principles and introduce the serverless microservice integration patterns. We then cover the communication styles and decomposition microservice patterns, including synchronous and asynchronous communication.

You will then learn how serverless computing in AWS can be used to quickly deploy event-driven computing and microservices in the cloud. We conclude the chapter by setting up your serverless AWS and development environment.

In this chapter we will cover the following topics:

  • Understanding different architecture types and patterns
  • Virtual machines, containers, and serverless computing
  • Overview of microservice integration patterns
  • Communication styles and decomposition microservice patterns
  • Serverless computing in AWS
  • Setting up your serverless environment

Understanding different architecture types and patterns

In this section, we will discuss different architectures, such as monolithic and microservices, along with their benefits and drawbacks.

The monolithic multi-tier architecture and the monolithic service-oriented architecture

At the start of my career, while I was working for global fortune 500 clients for Capgemini, we tended to use multi-tier architecture, where you create different physically separate layers that you can update and deploy independently. For example, as shown in the following three-tier architecture diagram, you can use Presentation, Domain logic, and Data Storage layers:

In the presentation layer, you have the user interface elements and any presentation-related applications. In domain logic, you have all the business logic and anything to do with passing the data from the presentation layer. Elements in the domain logic also deal with passing data to the storage or data layer, which has the data access components and any of the database elements or filesystem elements. For example, if you want to change the database technology from SQL Server to MySQL, you only have to change the data-access components rather than modifying elements in the presentation or domain-logic layers. This allows you to decouple the type of storage from presentation and business logic, enabling you to more readily change the database technology by swapping the data-storage layer.

A few years later at Capgemini, we implemented our clients' projects using SOA, which is much more granular than the multi-tier architecture. It is basically the idea of having standardized service contracts and registry that allows for automation and abstraction:

There are four important service properties related to SOA:

  • Each service needs to have a clear business activity that is linked to an activity in the enterprise.
  • Anybody consuming the service does not need to understand the inner workings.
  • All the information and systems are self-contained and abstracted.
  • To support its composability, the service may consist of other underlying services

Here are some important SOA principles:

  • Standardized
  • Loosely coupled
  • Abstract
  • Stateless
  • Granular
  • Composable
  • Discoverable
  • Reusable

The first principle is that there is a standardized service contract. This is basically a communication agreement that's defined at the enterprise level so that when you consume a service, you know exactly which service it is, the contract for passing in messages, and what you are going to get back. These services are loosely coupled. That means they can work autonomously, but also you can access them from any location within the enterprise network. They also offer an abstract version, which means that these services are a black box where the inner logic is actually hidden away, but also they can work independently of other services.

Some services will also be stateless. That means that, if you call a service, passing in a request, you will get a response and you would also get an exception if there is a problem with the service or the payload. Granularity is also very important within SOA. The service needs to be granular enough that it's not called inefficiently or many times. So, we want to normalize the level and the granularity of the service. Some services can be decomposed if they're being reused by the services, or services can be joined together and normalized to minimize redundancy. Services also need to be composable so you can merge them together into larger services or split them up.

There's a standardized set of contracts, but the service also needs to be discoverable. Discoverable means that there is a way to automatically discover what service is available, what endpoints are available, and a way to interpret them. Finally, the reasonable element, reuse is really important for SOA, which is when the logic can be reused in other parts of the code base.

Benefits of monolithic architectures

In SOA, the architecture is loosely coupled. All the services for the enterprise are defined in one repository. This allows us to have good visibility of the services available. In addition, there is a global data model. Usually, there is one data store where we store all the data sources and each individual service actually writes or reads to it. This allows it to be centralized at a global level.

Another benefit is that there is usually a small number of large services, which are driven by a clear business goal. This makes them easy to understand and consistent for our organization. In general, the communication between the services is decoupled via either smart pipelines or some kind of middleware.

Drawbacks of the monolithic architectures

The drawback of the monolithic architecture is that there is usually a single technology stack. This means the application server or the web server or the database frameworks are consistent throughout the enterprise. Obsolete libraries and code can be difficult to upgrade, as this is dependent on a single stack and it's almost like all the services need to be aligned on the same version of libraries.

Another drawback is that the code base is usually very large on a single stack stack, which means that there are long build times and test times to build and deploy the code. The services are deployed on a single or a large cluster of application servers and web servers. This means that, in order to scale, you need to scale the whole server, which means there's no ability to deploy and scale applications independently. To scale out an application, you need to scale out the web application or the application server that hosts the application.

Another drawback is that there's generally a middleware orchestration layer or integration logic that is centralized. For example, services would use the Business Process Management (BPM) framework to control the workflow, you would use an Enterprise Service Bus (ESB), which allows you to do routing your messages centrally, or you'd have some kind of middleware that would deal with the integration between the services themselves. A lot of this logic is tied up centrally and you have to be very careful not to break any inter-service communication when you're changing the configuration of that centralized logic.

Overview of microservices

The term microservice arose from a workshop in 2011, when different teams described an architecture style that they used. In 2012, Adrien Cockcroft from Netflix actually described microservice as a fine-grained SOA who pioneered this fine-grained SOA at web scale.

For example, if we have sensors on an Internet of Things (IoT) device, if there's a change of temperature, we would emit an event as a possible warning further downstream. This is what's called event-stream processing or complex-event processing. Essentially, everything is driven by events throughout the whole architecture.

The other type of design used in microservices is called domain-driven design (DDD). This is essentially where there is a common language between the domain experts and the developers. The other important component in DDD is the bounded context, which is where there is a strict model of consistency that relies in its bounds for each service. For example, if it's a service dealing with customer invoicing, that service will be the central point and only place where customer invoicing can be processed, written to, or updated. The benefits are that there won't be any confusion around the responsibilities of data access with systems outside of the bounded context.

You could think of microservice as centered around a REST endpoint or application programming interface using JSON standards. A lot of the logic could be built into the service. This is what is called a dumb pipeline but a smart endpoint, and you can see why in the diagram. We have a service that deals with customer support, as follows:

For example, the endpoint would update customer support details, add a new ticket, or get customer support details with a specific identifier. We have a local customer support data store, so all the information around customer support is stored in that data store and you can see that the microservice emits customer-support events. These are sent out on a publish-subscribe mechanism or using other publishing-event frameworks, such as Command Query Responsibility Segregation (CQRS). You can see that this fits within the bounded context. There's a single responsibility around this bounded context. So, this microservice controls all information around customer support.

Benefits and drawbacks of microservice architectures

The bounded context, and the fact that this is a very small code base, allow you to build very frequently and deploy very frequently. In addition, you can scale these services independently. There's usually one application server or web server per microservice. You can obviously scale it out very quickly, just for the specific service that you want to. In addition, you can have frequent builds that you test more frequently, and you can use any type of language, database, or web app server. This allows it to be a polygon system. The bounded context is a very important as you can model one domain. Features can be released very quickly because, for example, the customer services microservice could actually control all changes to the data, so you can deploy these components a lot faster.

However, there are some drawbacks to using a microservices architecture. First, there's a lot of complexity in terms of distributed development and testing. In addition, the services talk a lot more, so there's more network traffic. Latency and networks become very important in microservices. The DevOps team has to maintain and monitor the time it takes to get a response from another service. In addition, the changing of responsibilities is another complication. For example, if we're splitting up one of the bounded contexts into several types of sub-bounded context, you need to think about how that works within teams. A dedicated DevOps team is also generally needed, which is essentially there to support and maintain much larger number of services and machines throughout the organization.

SOA versus microservices

Now that we have a good understanding of both, we will compare the SOA and microservices architectures. In terms of the communication itself, both SOA and microservices can use synchronous and asynchronous communication. SOA typically relied on Simple Object Access Protocol (SOAP) or web services. Microservices tend to be more modern and widely use REpresentational State Transfer (RESTApplication Programming Interfaces (APIs).

We will start with the following diagram, which compares SOA and microservices:

The orchestration is where there's a big differentiation. In SOA, everything is centralized around a BPM, ESB, or some kind of middleware. All the integration between services and data flowing is controlled centrally. This allows you to configure any changes in one place, which has some advantages.

The microservices approach has been to use a more choreography-based approach. This is where an individual service is smarter, that is, a smart endpoint but a dumb pipeline. That means that the services know exactly who to call and what data they will get back, and they manage that process within the microservice. This gives us more flexibility in terms of the integration for microservices. In the SOA world or the three-tier architecture, there's less flexibility as it's usually a single code base and the integration is a large set of monolith releases and deployments of user interface or backend services. This can limit the flexibility of your enterprise. For microservices, however, these systems are much smaller and can be deployed in isolation and much more fine-grained.

Finally, on the architecture side, SOA works at the enterprise level, where we would have an enterprise architect or solutions architect model and control the release of all the services in a central repository. Microservices are much more flexible. Microservices talked about working at the project level where they say the team is only composed of a number of developers or a very small number of developers that could sit around and share a pizza. So, this gives you much more flexibility to make decisions rapidly at the project level, rather than having to get everything agreed at the enterprise level.

Virtual machines, containers, and serverless computing

Now that we have a better understanding of the monolithic and microservice architectures, let's look at the Amazon Web Service (AWS) building blocks for creating serverless microservices.

But first we'll cover virtual machines, containers, and serverless computing, which are the basic building blocks behind any application or service hosted in the public cloud.

Virtual machines are the original offering in the public cloud and web hosting sites, containers are lightweight standalone images, and serverless computing is when the cloud provider fully manages the resources. You will understand the benefits and drawbacks of each approach and we will end on a detailed comparison of all three.

Virtual machines

In traditional data centers, you would have to buy or lease physical machines and have spare capacity to deal with additional web or user traffic. In the new world, virtual machines were one of the first public cloud offerings. You can think of it as similar to physical boxes, where you can install an operating system, remotely connect via SSH or RDP, and install applications and services. I would say that virtual machines have been one of the key building blocks for start-up companies to be successful. It gave them the ability to go to market with only small capital investments and to scale out with an increase in their web traffic and user volumes. This was something that previously only large organizations could afford, given the big upfront costs of physical hardware.

The advantages of virtual machines are the pay per usage, choice of instance type, and dynamic allocation of storage, giving your organization full flexibility to rent hardware within minutes rather than wait for physical hardware to be purchased. Virtual machines also provides security, which is managed by the cloud provider. In addition, they provide multi-region auto-scaling and load balancing, again managed by the cloud provider and available almost at the click of a button. There are many virtual machines available, for example, Amazon EC2, Azure VMs, and Google Compute Engine.

However, they do have some drawbacks. The main drawback is that it takes a few minutes to scale. So, any machine that needs to be spun up takes a few minutes, making it impossible most to scale quickly upon request. There is also an effort in terms of configuration where the likes of Chef or Puppet are required for configuration management. For example, the operating system needs to be kept up to date.

Another drawback is that you still need to write the logic to poll or subscribe to other managed services, such as streaming analytics services. In addition, you still pay for idle machine time. For example, when your services are not running, the virtual machines are still up and you're still paying for that time even if they're not being actively used.

Containers

The old way with virtual machines was to deploy applications on a host operating system with configuration-management tools such as Chef or Puppet. This has the advantage of managing the application artifacts' libraries and life cycles with each other and trying to operate specific operating systems, whether Linux or Windows. Containers came out of this limitation with the idea of shipping your code and dependencies into a portable container where you have full operating-system-level virtualization. You essentially have better use of the available resources on the machine.

These containers can be spun up very fast and they are essentially immutable, that is, the OS, library versions, and configurations cannot be changed. The basic idea is that you ship the code and dependencies in this portable container and the environments can be recreated locally or on a server by a configuration. Another important aspect is the orchestration engine. This is the key to managing containers. So, you'd have Docker images that will be managed, deployed, and scaled by Kubernetes or Amazon EC2 container service (ECS).

The drawbacks are that these containers generally scale within seconds, which is still too slow to actually invoke a new container per request. So, you'd need them to be pre-warmed and already available, which has a cost. In addition, the cluster and image configuration does involve some DevOps effort.

Recently AWS introduced AWS Fargate and Elastic Kubernetes Service (EKS), which have helped to relieve some of this configuration-management and support effort, but you would still need a DevOps team to support them.

The other drawback is that there's an integration effort with the managed services. For example, if you're dealing with a streaming analytics service, you still need to write the polling and subscription code to pull the data into your application or service.

Finally, like with virtual machines, you still pay for any containers that are running even if the Kubernetes assists with this. They can run on the EC2 instance, so you'll still need to pay for that actual machine through a running time even if it's not being used.

Serverless computing

You can think of service computing as focusing on business logic rather than on all the infrastructure-configuration management and integration around the service. In serverless computing, there are still servers, it's just that you don't manage the servers themselves, the operating system, or the hardware, and all the scalability is managed by the cloud provider. You don't have access to the raw machine, that is, you can't SSH onto the box.

The benefits are that you can really focus on the business logic code rather than any of the infrastructure or inbound integration code, which is the the business value you are adding as an organization for your customers and clients.

In addition, the security is managed by the cloud provider again, auto-scaling and the high availability options also managed by the cloud provider. You can spin up more instances dynamically based on the number of requests, for example. The cost is per execution time not per idle time.

There are different public cloud serverless offerings. Google, Azure, AWS, and Alibaba cloud have the concept of Functions as a Service (FaaS). This is where you deploy your business logic code within a function and everything around it, such as the security and the scalability, is managed by the cloud provider.

The drawback is that these are stateless, which means they have a very short lifetime. After the few minutes are over, any state maintained within that function is lost, so it has to be persisted outside. It's not suitable for a long-running processes. It does have a limited instance type and a duration too. For example, AWS Lambdas have a duration of 15 minutes before they are terminated. There's also constraints on the actual size of the external libraries or any custom libraries that you package together, since these lambdas need to be spun up very quickly.

Comparing virtual machines, containers, and serverless

Let's compare Infrastructure as a Service (IaaS), Containers as a Service (CaaS), and Functions as a Service (FaaS). Think of IaaS as the virtual machine, CaaS as pool of Docker containers and FaaS an example will be Lambda functions. This is a comparison between IaaS, CaaS, and FaaS:

The green elements are managed by the user, and the blue elements are managed by the cloud service provider. So, on the left, you can see that IaaS, as used with virtual machines, have a lot of the responsibility on the user. In CaaS, the operating-system level is managed by the provider, but you can see that the container and the runtime are actually managed by the user. And, finally on the right, FaaS, you can see the core business logic code and application configuration is managed by the user.

So, how do you choose between AWS Lambda containers and EC2 instances in the AWS world? Check out the following chart:

If we compare virtual machines against the containers and Lambda functions on the top row, you can see that there is some configuration effort required in terms of the maintenance, building it for high availability, and management. For the Lambda functions, this is actually done on a pre-request basis. That is, it's request-driven. AWS will spin up more lambdas if more traffic hits your site to make it highly available (HA), for example.

In terms of flexibility, you have full access in virtual machines and containers, but with AWS Lambda, you have default hardware, default operating system, and no graphics processing units (GPU) available. The upside is that there is no upgrade or maintenance required on your side for Lambdas.

In terms of scalability, you need to plan ahead for virtual machines and containers. You need to provision the containers or instances and decide how you are going to scale. In AWS Lambda functions, scaling is implicit based on the number of requests or data volumes, as you natively get more or fewer lambdas executing in parallel.

The launch of virtual machines is usually in minutes and they can stay on perhaps for weeks. Containers can spin up within seconds and can stay on for minutes or hours before they can be disposed of. Lambda functions, however, can spin up in around 100 milliseconds and generally live for seconds or maybe a few minutes.

In terms of state, virtual machines and containers can maintain state even if it's generally not best practice for scaling. Lambda functions are always stateless, when they terminate their execution, anything in memory is disposed of, unless it's persisted outside in a DynamoDB table or S3 bucket, for example.

Custom integration with AWS services is required for virtual machines and Docker containers. In Lambda functions, however, event sources can push data to a Lambda function using built-in integration with the other AWS services, such as Kinesis, S3, and API Gateway. All you have to do is subscribe the Lambda event source to a Kinesis Stream and the data will get pushed to your Lambda with its business logic code, which allows you to decide how you process and analyze that data. However, for EC2 virtual machines and ECS containers, you need to build that custom inbound integration logic using the AWS SDK, or by some other means.

Finally, in terms of pricing, EC2 instances are priced per second. They also have a spot instance that uses market rates, which is lot cheaper than on-demand instances. The same goes for containers, except that you can have many containers on one EC2 instance. This makes better use of resources and is a lot cheaper, as you flexibility to spread different containers among the EC2 instances. For AWS Lambda functions, the pricing is per 100 milliseconds, invocation number, and the amount of random-access memory (RAM) required.

Overview of microservice integration patterns

In this section, we'll discuss design patterns, design principles, and how microservice architectural patterns relate to traditional microservice patterns and can be applied to serverless microservices. These topics will help you gain an overview of different integration patterns.

Design patterns

Patterns are reusable blueprints that are a solution to a similar problem others have faced, and that have widely been reviewed, tested, and deployed in various production environments.

Following them means that you will benefit from best practices and the wisdom of the technical crowd. You will also speak the same language as other developers or architects, which allows you to exchange your ideas much faster, integrate with other systems more easily, and run staff handovers more effectively.

Why are patterns useful?

Useful applications almost never exist in isolation. They are almost always integrated in a wider ecosystem, which is especially true for microservices. In other words, the integration specification and requirements need to be communicated and understood by other developers and architects.

When using patterns, you have a common language that is spoken among the technical crowds, allowing you to be understood. It's really about better collaborating, working with other people, exchanging ideas, and working out how to solve problems.

The main aim of patterns is to save you time and effort when implementing new services, as you have a standard terminology and blueprint to build something. In some cases, they help you avoid pitfalls as you can learn from others' experience and also apply the best practices, software, design patterns, and principles.

Software design patterns and principles

Your will probably be using object-oriented (OO) or functional programming in your microservices or Lambda code, so let's briefly talk about the patterns linked to them.

In OO programming, there are many best practice patterns or principles you can use when coding, such as GRASP or SOLID. I will not go into too much depth as it would take a whole book, but I would like to highlight some principles that are important for microservices:

  • SOLID: This has five principles. One example is the Single Responsibility Principle (SRP), where you define classes that each have a single responsibility and hence a single reason for change, reducing the size of the services and increasing their stability.
  • Package cohesion: For example, common closure-principle classes that change together belong together. So when a business rule changes, developers only need to change code in a small number of packages.
  • Package coupling: For example, the acyclic dependencies principle, which states that dependency graphs of packages or components should have no cycles.

Let's briefly go into some of the useful design patterns for microservice:

  • Creational patterns: For example, the factory method creates an instance of several derived classes.
  • Structural patterns: For example, the decorator adds additional responsibilities to an object dynamically.
  • Behavioral patterns: For example, the command pattern encapsulates a request as an object, making it easier to extract parameters, queuing, and logging of requests. Basically, you decouple the parameter that creates the command from the one that executes it.
  • Concurrency patterns: For example, the reactor object provides an asynchronous interface to resources that must be handled synchronously.

Depending on you coding experience, you may be familiar with these. If not, it's worth reading about them to improve you code readability, management, and stability, as well as your productivity. Here are some references where you can find out more:

  • SOLID Object-Oriented Design, Sandi Metz (2009)
  • Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1995)
  • Head First Design Patterns, Eric T Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra (2004)
  • Agile Software Development, Principles, Patterns, and Practices, Robert C. Martin (2002)

Serverless microservices pattern categories

On top of the software design patterns and principles we just discussed are the microservices patterns. From my experience, there are many microservices patterns that I recommended that are relevant for serverless microservices, as shown in the following diagram:

I created this diagram to summarize and illustrate the serverless microservices patterns we will be discussing in this book:

  • Communication styles: How services communicate together and externally.
  • Decomposition pattern: Creating a service that is loosely coupled by business capability or bounded context.
  • Data management: Deals with local and shared data stores.
  • Queries and messaging: Looks at events and messages that are sent between microservices, and how services are queried efficiently.
  • Deployment: Where ideally we would like uniform and independent deployments, you also don't want developers to re-create a new pipeline for each bounded context or microservice.
  • Observability and discovery: Being able to understand whether a service is functioning correctly, monitor and log activity allow you to drill down if there are issues. You also want to know and monitor what is currently running for cost and maintenance reasons, for example.
  • Security: This is critical for compliance, data integrity, data availability, and potential financial damage. It's important to have different encryption, authentication, and authorization processes in place.

Next we will have a look at the communication styles and decomposition pattern first.

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Create a secure, cost-effective, and scalable serverless data API
  • Use identity management and authentication for a user-specific and secure web application
  • Go beyond traditional web hosting to explore the full range of cloud hosting options

Description

Over the last few years, there has been a massive shift from monolithic architecture to microservices, thanks to their small and independent deployments that allow increased flexibility and agile delivery. Traditionally, virtual machines and containers were the principal mediums for deploying microservices, but they involved a lot of operational effort, configuration, and maintenance. More recently, serverless computing has gained popularity due to its built-in autoscaling abilities, reduced operational costs, and increased productivity. Building Serverless Microservices in Python begins by introducing you to serverless microservice structures. You will then learn how to create your first serverless data API and test your microservice. Moving on, you'll delve into data management and work with serverless patterns. Finally, the book introduces you to the importance of securing microservices. By the end of the book, you will have gained the skills you need to combine microservices with serverless computing, making their deployment much easier thanks to the cloud provider managing the servers and capacity planning.

Who is this book for?

If you are a developer with basic knowledge of Python and want to learn how to build, test, deploy, and secure microservices, then this book is for you. No prior knowledge of building microservices is required.

What you will learn

  • Discover what microservices offer above and beyond other architectures
  • Create a serverless application with AWS
  • Gain secure access to data and resources
  • Run tests on your configuration and code
  • Create a highly available serverless microservice data API
  • Build, deploy, and run your serverless configuration and code

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Last updated date : Feb 11, 2025
Publication date : Mar 29, 2019
Length: 168 pages
Edition : 1st
Language : English
ISBN-13 : 9781789533422
Languages :
Concepts :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Product feature icon AI Assistant (beta) to help accelerate your learning
OR
Modal Close icon
Payment Processing...
tick Completed

Billing Address

Product Details

Last updated date : Feb 11, 2025
Publication date : Mar 29, 2019
Length: 168 pages
Edition : 1st
Language : English
ISBN-13 : 9781789533422
Languages :
Concepts :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $ 99.97
Building Serverless Microservices in Python
€24.99
Hands-On Docker for Microservices with Python
€32.99
Python Microservices Development
€41.99
Total $ 99.97 Stars icon

Table of Contents

7 Chapters
Serverless Microservices Architectures and Patterns Chevron down icon Chevron up icon
Creating Your First Serverless Data API Chevron down icon Chevron up icon
Deploying Your Serverless Stack Chevron down icon Chevron up icon
Testing Your Serverless Microservice Chevron down icon Chevron up icon
Securing Your Microservice Chevron down icon Chevron up icon
Summary and Future Work Chevron down icon Chevron up icon
Other Books You May Enjoy Chevron down icon Chevron up icon

Customer reviews

Rating distribution
Full star icon Full star icon Full star icon Empty star icon Empty star icon 3
(5 Ratings)
5 star 20%
4 star 20%
3 star 20%
2 star 20%
1 star 20%
User Sep 16, 2019
Full star icon Full star icon Full star icon Full star icon Full star icon 5
Found this is a really good book to get me up and running with Serverless in AWS using Python, wish it were bit longer. Really like how the author introduces microservice architecture theory, with practical examples I can use and the in-depth and hands-on section on many forms of testing.
Amazon Verified review Amazon
Amazon Customer May 06, 2019
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
best for aws users trying to learn python scripting
Amazon Verified review Amazon
Andres G. T. Jul 25, 2020
Full star icon Full star icon Full star icon Empty star icon Empty star icon 3
It has a good intro to microservices concepts and good practice with lambda. However, if you plan to follow the exercises you may find it difficult. For example, sometimes the code it's repetitive and the author doesn't explain why, or he doesn't tell you that, after writing some python scripts, you have to run them locally first before running a test for a lambda function in AWS. Also, the GitHub site for the book is hard to find the code for the corresponding section in the book (at the least in the Kindle edition).
Amazon Verified review Amazon
Rob Shearer Apr 08, 2021
Full star icon Full star icon Empty star icon Empty star icon Empty star icon 2
This can't really be called a "book". It's a tutorial, where you follow the directions given to create an AWS serverless service. There is a brief description of what each command does, but very little discussion of why or what other approaches are possible. Many of the steps are literally "cut and paste this code into the box".The real issue is that even as a tutorial it's atrocious. The quality of the code itself wouldn't pass muster in any serious programming team. There seems to be no rhyme or reason to what is abstracted or parameterized, leading to code that is overcomplicated and verbose while providing no real value for reuse. But it's also terribly written for a tutorial. When code from one step is expanded with a little bit of additional functionality in the next step, that isn't added as a few extra lines of code; instead the entire code is arbitrarily rewritten with slightly different function names for no obvious reason. There was clearly no intention of readers ever actually "working through" the tutorial by coding it up themselves (and experimenting with variations), only cutting and pasting.I wish I had the knowledge to comment on whether the tutorial genuinely offers modern best practice for developing serverless applications. I don't. But the author's obvious lack of any production software engineering expertise or experience does not inspire confidence.That this "book" was pushed out the door in this state must be taken as a reflection of its publisher. Based on this book, I will make sure not to waste money on any other Packt releases in the future.
Amazon Verified review Amazon
utente Sep 09, 2019
Full star icon Empty star icon Empty star icon Empty star icon Empty star icon 1
Terribile. È scritto coi piedi. Sembra il risultato di una persona a cui è stato detto che dovrebbe scrivere un libro, e ha buttato giù quattro appunti. Termini usati senza definirli, o con la definizione dopo il primo utilizzo. Frasi senza capo ne coda. Mi sono fermato quando ho visto una immagine in bianco e nero con la spiegazione: "I rettangoli in verde indicano i servizi...". QUesto genere di libri distruggono la fiducia in un autore e in una casa editrice. Non li conoscevo prima, li eviterò in seguito. Mi spiace perchè l'argomento mi interessava davvero :-(
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see www.packtpub.com/support and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to www.packtpub.com/account
  • To contact us directly if a problem is not resolved, use www.packtpub.com/contact-us
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.

Modal Close icon
Modal Close icon