Let's begin by looking at microservices in more details. Microservices divide a large program into a number of smaller independent services as shown on the right. Unlike a monolithic application, which implements all features in a single code base with the database for all data, as shown on the left, Microservices are the current industry trends. However, it's important to ensure that there is a good reason to select this architecture. The primary reason is to enable teams to work independently and deliver through to production at their own cadence. This support scaling the organization, adding more teams, increases speed. There's also the additional benefit of being able to scale the microservices independently based on their requirements. Architecturally an application designed as a monolith or around microservices should be composed of modular components with clearly defined boundaries. With the monolithic all the components are packaged at deployment time and deployed together. With microservices the individual components are deployable. Google Cloud provides several compute services that facilitate deploying micro services. These include app engine, cloud, Ron G K and cloud functions. Each offers different level of granularity and control, and will be discussed later in the course. To achieve independence on services, each service should have its own data store. This lets the best data store solution for that service to be selected and also keeps the services independent. We do not want to introduce coupling between services through a data store. A properly designed micro service architecture can help achieve the following goals, define strong contracts between the various microservices, allow for independent deployment cycles including rollback. Facilitate concurrent a be released testing on subsystems, minimize test automation and quality assurance overhead, improve clarity of logging and monitoring, provide fine grained cost accounting, increase overall application scalability and reliability through scaling smaller units. However, the advantages must be balanced with the challenges this architectural style introduces. Some of these challenges include. It can be difficult to define clear boundaries between services to support independent development and deployment, increased complexity of infrastructure with distributed services having more points of failure. The increased latency introduced by network services and the need to build in resilience to handle possible failures and delays. Due to the networking involved there is a need to provide security for service to service communication, which increases complexity of infrastructure. Strong requirement to manage and version source interfaces with independent deployable services. The need to maintain backward compatibility increases. Now, decomposing applications into microservices is one of the biggest technical challenges of application design. Here, techniques like domain driven design are extremely useful in identifying logical functional groupings. The first step is to decompose the application by feature or functional groupings to minimize dependencies. Consider, for example, an online retail application, logical functional groupings could be product management, reviews, accounts and orders. These groupings then for many applications which expose an API. Each of these many applications will be implemented by potentially multiple microservices internally. Internally these microservices are then organized by architectural layer and each should be independently deployable and scalable. Any analysis will also identify shared services such as authentication, which are then isolated and deployed separately from the mini applications. When you're designing microservices services that do not maintain state but obtain their state from the environment or stateless services are easier to manage. That is they are easy to scale to administer and to migrate to new versions because of their lack of state. However, it is generally not possible to avoid using state full services at some point in a micro service based application. It is therefore important to understand the implications of having state full services on the architecture of the system. These include introducing significant challenges in the ability to scale and upgrade the services. Being aware of how state will be managed is important in the very early stages of microservice application design. Let me introduce some suggestions and best practices on how this can be achieved, in memory shared state has implications that impact and negate many of the benefits of a microservice architecture. The auto scaling potential of individual microservices is hindered because subsequent client requests have to be sent to the same server that the initial request was made to. In addition, this requires configuration of the load balancers to use sticky sessions, which in google cloud is referred to as session affinity. A recognized best practice for designing state full services is to use back in storage service that are shared by fronted stateless services. For example, for persistent state, the google cloud managed data services such as fire store or cloud sequel may be suitable, then to improve the speed of data access the data can be cashed. The memory store which is a highly available red is based service is ideal for this. This diagram displays a general solution that shows the separation of the front end and backend processing stages. A load balancer distributes the load between the backend and fronted services. This allows the backend to scale if it needs to keep up with the demand from the frontend. In addition, the state full services or servers are also isolated. The stateful services can make use of the persistent storage services and cashing as previously discussed. This layout allows a large part of the application to make use of the scalability and fault tolerance of google cloud services as stateless services. By isolation of the stateful servers and services, the challenges of scaling and upgrading are limited to a subset of the overall set of services.
