Microservices is not a panacea, it doesn't fit all cases. You can implement a microservices solution in App Engine cloud functions and using Node.js and Kubernetes. The platforms have overlapping coverage. Do you know when you might choose one platform over another for microservices solution? Coordinating a transaction across stateless microservices is tricky. You have to store the state externally and retrieve and use it in each function. Microservices architectures are commonly used and implemented in Cloud Functions or in App Engine. Containers bundle application code and dependencies into a single unit, abstracting the application from the infrastructure. Make sure you know the difference between containers and VMs. Make sure you know the basics of Kubernetes. When might you use a different pod? How does code maintenance and migration to a new version work? Understand AB testing and deployment. A pod is Kubernetes engine abstraction to represent an application. It holds one or more containers. The containers in the pod share a single IP address and a single namespace. A pod can share other items such as access to storage. Any data access mattered on a pod called a volume is available to all containers in the pod. Containers that are part of the same pod are guaranteed to be scheduled together on the same VM and can share state via local volumes. Persistent volumes using persistent disks in Compute Engine survive instance and container restarts. How do you balance resiliency, scalability, and cost? Well, small stateless servers are more scalable and reliable closer to a microservices designed. Of course, you have to coordinate all the messaging and state storage and retrieval. So the cost is increased complexity. Large stateful servers reduce application complexity. They allow you to combine activities and organize them making the application more manageable. However, this comes at a cost of decreased scalability and a greater chance that if something goes wrong it will take down the service. What you want to do is blend the approaches where it makes sense to the business. This is another case where what the client wants is what's most important to the design and on an exam it means being sensitive to and looking out for those trade-offs. Services, managed services, and serverless services, knowing the differences between them will help distinguish solutions that meet all the requirements. A managed service gives you visibility to servers but limited control. You give up control for automation. It's great for popular use cases and eliminating overhead. Serverless services completely hide all servers. Generally, it's more fast scalable and efficient than you could create on your own. The key trade off their proprietary. To be fair, all services are sometimes called managed services even if they're really serverless services. I mentioned previously that there are common assemblies of services that work together. If you review solutions and diagrams, you'll start to recognize some. There's a great resource for becoming familiar with a variety of solution architectures online. Look for it at cloud.google.com/solutions. The core assembly here is IoT Core, Cloud Functions, Cloud Pub Sub, and Cloud Dataflow. The IoT core device manager. Google Cloud IoT Core provides a fully managed service for device registration, authentication, authorization, metadata and configuration. Cloud Pub Sub. Google Cloud Pub Sub provides a globally durable message ingestion service. Cloud Pub Sub can act like a shock absorber and rate level or for incoming data. Cloud Pub Sub scales to handle data spikes that can occur when swarms of devices respond to events in the physical world. It buffers these spikes to help isolate them from applications monitoring their data. Cloud Dataflow. Google Cloud Dataflow provides the open Apache beam programming model as a managed service for processing data in multiple ways including batch, extract transform load ETL patterns, and continuous streaming patterns. Cloud Dataflow performs well with high volume data processing. Cloud Functions. IoT events and data can be sent to the cloud at a high rate and need to be processed quickly. Cloud functions allow you to write custom logic that can be applied to each event as it arrives. This can be used to trigger alerts, filter invalid data, or invoke other APIs. Cloud Functions can operate on each published event individually.