读书笔记《cloud-native-applications-in-java》作为服务集成
本章讨论了各种类型的Anything as a Service（XaaS )，其中包括 基础设施即服务（IaaS）， 平台即服务（PaaS），集成平台即服务（iPaaS）和数据库即服务 (DBaaS)，以及在公开基础设施时需要考虑的所有因素或平台元素作为服务。在云原生模式下，您的应用程序可能与社交媒体 API 或 PaaS API集成，或者您可能托管的服务将被其他应用程序使用。本章节 涵盖了您需要处理 在构建自己的 XaaS 模型时使用。
本章将涵盖以下主题：
- Architecture and design concerns when building your own XaaS
- Architecture and design concerns when building your mobile application
- Various backend as a service providers—database, authorization, cloud storage, analytics, and so on
云计算开创了distribution 模型，用于弹性、按需付费、按需的 IT 托管服务。作为服务交付的 IT 的任何部分都松散地涵盖在云计算的广泛主题下。
在云计算主题中，根据 IT 服务的类型，云的特定服务有不同的术语。大多数术语是术语 XaaS 的不同变体，其中 X 是一个占位符，可以更改以表示多个事物。
让我们看看最常见的云计算交付模型：
- IaaS: When the computing resources (compute, network, and storage) are provided as a service to deploy and run operating systems and applications, it is termed as IaaS. If the organization does not want to invest in building data centers and buying servers and storage, this is a right choice of service to take advantage of. Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP) are leading examples of IaaS providers. In this model, you are responsible for the following:
- Managing, patching, and upgrading all operating systems, applications, and related tools, database systems, and so on.
- From a cost optimization perspective, you will be responsible for the bringing the environment up and down.
- Provisioning of compute resources is almost instantaneous. The elasticity of the compute resources is one of the biggest selling factors for IaaS vendors.
- Typically, the server images can be backed up by the cloud provider, so backup and restore is easily managed when using a cloud provider.
- PaaS: Once the compute, network, and storage have been sorted out, next comes the requirement for a development platform and related environment to build applications. A PaaS platform provides services across the software development life cycle (SDLC). Services such as runtime (such as Java and .NET), database (MySQL and Oracle), and web servers (such as Tomcat and Apache web server) are considered to be PaaS services. The notion is that the cloud computing vendor will still manage the underlying operational aspects of runtime, middleware, OS, virtualization, servers, storage, and networking. In this model, you will be responsible for the following:
- The developer's concern will be limited to managing applications and the associated data. Any change/updates to the application need to be managed by you.
- Abstraction of the PaaS is at a high level (messaging, Lambda, container, and so on), allowing the team to focus on the core competency of working for customer needs.
- SaaS: Next comes the model where you rent the entire application. You are not required to build, deploy, or maintain anything. You subscribe to the application, and the provider will provide an instance of the application for you or your organization for use. You can access the application over the browser or can integrate with the public APIs provided by the provider. Services such as Gmail, Office 365, and Salesforce are examples of SaaS services. In this model, the provider provides a standard version of the feature/functionality for all the tenants with very limited customization capabilities. The SaaS vendor might provide a security model where you can integrate your Lightweight Directory Access Protocol (LDAP) repository with the vendor using Security Assertion Markup Language (SAML) or OAuth models. This model works very well for standard software where the need for customization is low. Office365 and Salesforce are some of the biggest poster children of SaaS vendors:
在构建组织及其应用程序组合时，您可能会为不同的供应商订阅各种类型的服务。现在，如果您尝试构建下一个 Facebook、Instagram 或 Uber，您将需要解决特定的架构问题，以解决数十亿用户的各种需求。
让我们回顾一下在构建 XaaS 并提供这些服务以供消费时需要解决 的关键设计问题：
- Multi-tenancy: When you start designing your service for public consumption, one of the first requirements is the ability to support multiple tenants or customers. As people start signing up to use your service, the service needs to support be able to provide a secure boundary for customer data. Typically, SaaS is a good candidate for the multi-tenancy design concerns. For every tenant, the data and application workload might need to be partitioned. Tenant requests are within the confines of the tenant data. To design multi-tenancy within your application, you will need to look at the following:
- Isolation: Data should be isolated between the tenants. One tenant should not be able to access any other tenant's data. This isolation is not only restricted to the data, but can be extended to underlying resources (including compute, storage, network, and so on) and operational processes (backup, restore, DevOps, admin functionality, application properties, and so on) marked for each tenant.
- Cost optimization: The next big concern is how to optimize the design to lower the overall cost of the cloud resources and still address all kinds of customers. You can look at multiple techniques to manage your costs. For example, for free-tier customers, you can have a tenancy model based on the tenant ID. This model allows you to optimize the database licenses, overall compute and storage costs, DevOps processes, and so on. Similarly, for large customers, you can even look at dedicated infrastructure to provide a guaranteed service-level agreement (SLA). There are a number of small companies that do millions worth of business from a handful of large customers. On the other hand, you have large companies that cater to millions of small customers.
- DevOps pipeline: If you end up building multiple instances of the same service for customers, you will encounter problems when customers demand specific features for them. This soon leads to code fragmentation and becomes an unmanageable code problem. The question becomes how to balance the ability to roll out new features/functionality for all customers and still able to provide the level of customization or individuality required by each of them. The DevOps process needs to support multi-tenancy isolation and maintain/monitor each tenant process and database schema to roll out the changes across all the service instances. Unless DevOps is streamlined, rolling out changes across the service can become very complex and daunting. This all leads to increased cost and lower customer satisfaction.
- Scalability: One of the basic requirements is to be able to sign up new customers and scale up the services. As the scale of customers grows, the expectation is cost/service or overall service cost should fall. Unless our service is built keeping in mind the preceding three types of tenants, the service will not be able to scale and provide an artificial moat around your business model.
接下来，当您着手设计多租户服务时，您有以下设计选项：
-
- Database per tenant: Every tenant has its own database. This model provides complete isolation to tenant data.
- Shared database (single): All tenants are hosted within a single database and identified by a tenant ID.
- Shared database (sharded): In this model, a single database is sharded into multiple databases. Typically, the shard key is derived from hash, range, or list partitioning. The tenants are spread across the shard and are accessible by a combination of tenant ID and shard:
- Faster provisioning: When building an XaaS model, another key concern is the ability to provision new customers, meaning customer onboarding should be self-service. Upon signing up, the customer should be immediately able to start making use of the service. All this requires a model where a new tenant can be provisioned effortlessly and very quickly. The ability to provide the underlying compute resources, any database schema creation, and/or specific DevOps pipelines should be very efficient and fully automated. From a customer experience point of view also, the ability to provide a running version of the application to the user helps. For any service that is aiming to be mass market, faster provisioning is given. But if you are providing a very specific service and that requires integration with enterprise customer on-premises data centers, then it may not be possible to provide split-second provisioning. In that case, we should build tools/scripts that can address some of the common integration scenarios to onboard the customer as soon as possible.
- Auditing: Another key concern around security is the ability to audit for the access and changes to the service and underlying data store. All of the audit trail needs to be stored for any breaches or security issues or compliance purposes. There will be the requirement for a centralized audit repository that keeps track of the events being generated across the system. You should be able to run analysis on top of the audit repository to flag up any abnormal behavior and take preventive or corrective actions:
您可以利用 Lamda 架构，该架构同时使用实时流以及从历史数据生成的模型来标记异常行为。一些公共云提供商将其作为服务提供。
- Security: Depending on the nature of the service, the tenants need to have secure access to their data. The service needs to incorporate the basic requirement of authentication and authorization. All the customers have a secure key and passphrase to connect and access their information. There might be requirements for enterprise access and multiple users. In that case, you might have to build a delegated administration model for enterprise(s). You can also use a security mechanism such as OAuth (through Google, Facebook, and so on) to enable access to the service.
- Data storage: Your service might require storage of different types of data; depending on the type of the data, the storage requirements will be different. The storage requirement typically falls into the following areas:
- Relational data storage: Tenant data might be relational and we talked of the various multi-tenant strategies to store that data. Tenant-specific application configuration data might need to be stored in a relational model.
- NoSQL storage: Tenant data might not be relational all the time; it might be a columnar, key value, graph, or document-oriented model. In that case, appropriate data storage needs to be designed and then constructed.
- Blob storage: If your service requires Blob storage or storage of binary data, then you will require access to object file storage. You can make use of Blob storage from the likes of AWS or Azure to store your binary files:
- Monitoring: The entire application stack needs to be monitored. You might sign up customers and guarantee them stringent SLAs. In that scenario, monitoring is not just about service or system availability but also about any cost penalty and loss of reputation. At times, individual components might have redundancy and high availability but at a stack level, all the failure rates can be compounded to reduce the overall availability of the stack. Monitoring resources across the stack becomes important and key to managing the availability and defined SLAs. Monitoring encompasses both hardware and software. There is a need to detect any abnormal behavior and automate the corrective response. Typically, the ability to monitor and automate the healing takes multiple iterations to mature.
- Error handling: One of the key aspects of the service will be the ability to handle failures and how to respond to the service consumer. Failures can occur at multiple levels; a data store not being available, tables getting locked, queries getting timed out, service instances going down, session data being lost, and so on are some of the issues you will encounter. Your service needs to be robust to handle all these and then some more failure scenarios. Patterns such as CQRS, circuit breaker, bulkheading, reactive, and so on will need to be incorporated into your service design.
- Automated build/deployment: As the number of service consumers goes up, the ability to roll out new features and fix bugs will require an automated build and deployment models. This is akin to changing the tires of a car while it is moving. The ability to upgrade the software and release patches / security fixes without any impact on the calls from the consumer is a delicate art and takes time to master. Earlier, we could look for some system downtime during the night when the traffic comes down, but with customers from around the world, there is no longer such a time. Blue-green deployment is a technique that can help in releasing new changes with minimum impact to the customers and reduction of overall risk:
- Customer tiers: Another key concern is how to build and price your service for different sets of customers. Companies have been creating multiple tiers to address the needs of myriad customers. These needs help the companies decide the customer tier and then start pricing the service cost. These factors are as follows:
- Compute: Limiting the number of calls made by hour/day/month. This allows you to predict the capacity required by the tenant along with the networking bandwidth requirements.
- Storage: Another parameter is the storage required for the underlying data store. This allows you to balance database shards appropriately.
- Security: For enterprise customers, there might be separate requirements for integration with enterprise security models using SAML. This might require additional hardware and support.
- SLAs/support model: This is another area which needs to be accounted for when deciding the customer tiers. Support models—community, on-call, dedicated, and so on—come with different cost structures. Depending on the target market—consumer or enterprise—you can evaluate which of the support models will work best for your service.
- Feature flags: When building an XaaS model, one of the key questions is how to deal with code changes, feature releases, and so on for multiple tenants. Should I have multiple code branches for each customer or should I use one code base across all the customers? If I use one code base, how do I release features/functionality that are specific to one tenant? If your target market is 8-10 customers, then having specific code branches for each customer is a potential viable option. But if the target market is hundreds of customers, then code branching is a bad option. Code branching is usually a bad idea. To handle differences in features/functionality for different customers or manage new upcoming features not ready for release, a feature flag is a great way to handle such requirements:
功能标志允许您在生产中发布代码，而无需立即为用户发布功能。您可以使用功能标志来根据他们购买的服务级别向不同的客户提供/限制您的应用程序的某些功能。您还可以将特性标志与 A/B 测试结合使用，向部分用户发布新特性/功能，以检查他们的响应和功能正确性，然后再推广给更广泛的受众。
- Self-service portal: A key aspect of your service will be a self-service portal where the users can sign up, provision the service, and manage all aspects of the application data and service. The portal allows users to manage enterprise aspects such as authentication/authorization (using a delegated admin model), monitor the provisioned service for availability, set up custom alarms/alerts on the key metrics of the service, and decipher any issues that might be cropping on the server side. A well-crafted portal helps increase overall customer confidence in the service performance. You can also build advanced monitoring and analytics services for your paid customers based on the customer tiers. Remember, anybody can copy the features/functionality your service provides, but building additional value-added features around your service becomes a distinct differentiator for your service.
- Software development kits (SDKs): As one of the key measures of enabling user adoptability of your service, you might want to build and provide SDKs for your consumers. This is not a must-have, but a desirable feature, especially when a customer integrates with your service at an application code level on their side. In this case, SDKs should provide support for multiple languages and come with good examples and documentation to help onboard the developers on the customer side. If your application or service is complex, having an SDK that explains how to invoke your services or integrate within existing services (such as SAML, OAuth, and so on) becomes key to faster adoptability of your service.
- Documentation and community support: One more aspect of service adoptability is the level of documentation available along with community support for the product/service. Documentation should minimally cover the following points:
- How to sign up for the service
- How to invoke and use the service
- How to integrate the service within the customer landscape and the SDKs available for integration
- How to bulk import or bulk export your data
- How to securely integrate for authentication/authorization with enterprise LDAP / Active Directory (AD) servers
您需要考虑的下一件事是建立积极的社区支持。您需要提供适当的论坛供人们互动。您需要有活跃的 主题专家 (SME)回答来自论坛（内部和外部）人们的问题。 Stack Overflow的like得到很多问题；您应该设置警报、监控线程并帮助回答用户的问题/查询。活跃的社区是对您的产品感兴趣的标志。许多组织还使用这个论坛来确定早期采用者并在产品路线图中寻求他们的反馈。
- Product roadmap: A good product might start with a minimum viable product (MVP) but it usually backed a solid vision and product roadmap. As you receive feedback from the customer, you can keep on updating the product roadmap and reprioritizing the backlog items. A good roadmap indicates the strength of the product vision. When you meet external stakeholders—customers, partners, venture capitalists (VCs), and so on—the first thing they ask for is a product roadmap. A roadmap typically consists of strategic priorities and planned releases along with high-level features and plans for maintenance/bug-fixing releases, among others:
我们已经介绍了在尝试构建 XaaS 模型时需要考虑的一些设计问题。我们已经涵盖了每个问题的基础知识。每个问题都需要至少一章。希望它能让您了解在尝试围绕 XaaS 构建业务模型时需要考虑的各种其他非服务方面。服务的实际设计和开发基于我们从 Chapter 2, 编写您的第一个云原生应用程序，继续。
在上一节中，我们看到了构建自己的服务提供者时的设计关注。在本节中，如果您尝试构建消费者应用程序，我们将了解如何利用第三方公司提供的 REST 服务。例如，您正在尝试构建一个漂亮的移动应用程序，您的核心能力是构建视觉设计和创建移动应用程序。您不想承担管理与托管/管理应用程序数据相关的所有复杂性的负担。该应用程序将需要包括存储、通知、位置、社交集成、用户管理、聊天功能和分析等在内的服务。所有这些提供商都在 后端即服务（BaaS ) 提供者。无需为这些服务与单一供应商签约；您可以挑选和选择哪些提供商适合您的业务需求和预算。每个提供商通常都运行免费增值模式，每月免费提供一定数量的 API 调用，以及收费的商业模式。这也属于构建无服务器应用程序的范畴，作为开发人员，您无需维护任何运行任何软件的服务器。
在这方面，我们将研究构建成熟的无服务器应用程序所需的第三方服务：
- Authentication services: One of the first things any application requires is the ability to sign up or register users. A registered user allows the opportunity for application developer to provide personalized services and know his likes/dislikes. This data allows him to optimize the user experience and provide the necessary support to get maximum value out of the application.
身份验证即服务侧重于围绕用户身份验证的业务功能封装。身份验证需要身份提供者。此提供程序可以映射到您的应用程序或企业，或者您可以使用一些消费者公司，例如 Google、Facebook、Twitter 等。有多个身份验证服务提供者可用，例如 Auth0、Back&、AuthRocket 等。这些提供商至少应提供以下功能：
- Multi-factor authentication (MFA) (including support for social identity providers): One of the primary requirements, the provider should provide identity provider instance where the application can manage the users. The functionality includes user registration, two-factor authentication either by SMS or by email, and integration with social identity providers. Most of the providers make use of OAuth2/OpenID model.
- User management: Along with the MFA, the authentication provider should provide user interface that allows for user management that has signed up for the application. You should be able to extract the emails and phone numbers for sending push notifications to the customers. You should be able to reset the user credentials and protect resources either by using security realms or adding users to certain predefined roles based on the needs of the application.
- Plugins/widgets: Last but not least, the provider should provide widgets/plugins that can be embedded in the application code to provide user authentication as a seamless service:
- Serverless services: Gone are the days when you needed to manage application servers and the underlying VM to deploy your code. The level of abstraction has moved to what is called the business function. You write a function that takes as input a request, processes the same, and outputs the response. There is no runtime, no application server, no web server, nothing. Just a function! The provider will automatically provision the runtime to run that function, along with the server. You, as developer, need not worry about anything. You are charged on a combination of the number of calls to the function and how long the functions ran, meaning, during lean times, you are incurring zero cost. From the function, you can access the data store and manage user- and application-specific data. Two functions can talk to each other using a queue model. Functions can be exposed as APIs using the API gateway of the provider. All the public cloud vendors have a version of the serverless model—AWS has Lamda, Azure has Azure Functions, Google has Cloud Functions, Bluemix has Openwhisk, and so on:
- Database/storage services: An application typically requires storage to manage the customer data. This can be as simple as user profile information (such as photo, name, email ID, password, and application preferences) or user-specific data (such as messages, emails, and application data). Depending on the type of data and the format in which it is stored, an appropriate database/storage service can be chosen. For binary storage, we have services such as AWS S3 and Azure Blob Storage for all kind of binary files. For storing data in JSON format directly from the mobile application, you have cloud providers such as Google Firebase, or you can use MongoDB as a service (www.mlab.com). Multiple database models are provided by AWS, Azure, and GCP that can be used to manage all kinds of different storage needs.You might need to use AWS Lambda or Google Cloud Functions to be able to access the store the data. For example, if the application request needs to do some validation or processing before storing the data, you can write a Lambda function, that can be exposed as an API. The mobile application accesses the API that invokes the Lambda function, where, after request processing, data gets stored in the data store.
- Notification services: An application typically registers the user and device to be able to send notifications to the device. AWS provides a service called Amazon Simple Notification Service (SNS) that can be used to register and send notifications from your mobile application. AWS service supports push notifications to iOS, Android, Fire OS, Windows, and Baidu-based devices. You can also send push notifications to macOS desktops and voice over IP (VoIP) applications on iOS devices, emails, and SMS messages to users across over 200 countries.
- Analytics services: Once customers start adopting the application, you will want to know what features of the application are being used, where the users are facing issues or challenges and where are the users dropping off. To understand all this, you will need to subscribe to an analytics service that allows you to track the user actions which are then collated to a central server. You can go to that central repository and get an insight into the user activities. You can use this insight into customer behavior to improve the overall customer experience. Google Analytics is a popular service in this area. You track users' overall multiple parameters including location, browser used, device used, time, session details, and so on. You can also enhance it by adding custom parameters. The tools typically provide a certain amount of canned reports. You can also add/design your own reporting templates.
- Location services: Another service used by applications is the location service. Your application might require features that require the functionality to be curated for a given context (in this case, location can be one of the context attributes). Context-aware functionality allows you to personalize the features/services to the needs of the end customer and help to improve the overall customer experience. The Google Play service location API provides such a functionality. There is a complete set of services/applications around the location services. For example, companies such as Uber, Lyft, and Ola (India) are great examples of business cases that are built around location services. Most logistics businesses (especially the last mile ) make use of location services for route optimization and delivery, among other things.
- Social integration services: Your application might warrant social integration with popular social networks (Facebook, Twitter, Instagram, and so on). You will need to be able to access the social feeds of the logged-in user, post on their behalf, and/or get access to their social network. There are multiple ways to access these social networks. Most of these networks provide access for other applications and expose a set of APIs to connect to them. Then there are aggregators that will allow you to provide integration with a set of social networks out of the box.
- Advertisement services: Another key service used by applications, especially mobile applications, is to serve advertisements to the user. Based on the application model (free/paid), you need to decide the model for monetization of your application. To serve advertisements (called in-app advertising) to your users, you will need to sign up with the advertising network providers and invoke their API service. Google's AdMob service is one of the pioneers in this area.
在构建您的应用程序时，您 可能希望查看许多其他服务提供商。我们已经涵盖了关键的突出类别。根据您的应用程序的需求，您可能希望在该特定需求领域搜索提供者。我相信会有人已经在提供服务。有一些综合提供商称为 BaaS。这些 BaaS 提供商通常会提供多种服务以供使用，并减少应用程序方面的整体集成工作量。您不必与多个提供商打交道；相反，您使用一个。这一个提供商可以满足您的多种需求。
BaaS 作为细分市场竞争激烈。在多家供应商竞争的情况下，您会发现许多并购活动也在此细分市场中。最近，发生了以下情况：
- Parse: Acquired by Facebook. Parse provides a backend to store your data, the ability to push notifications to multiple devices, and a social layer to integrate your application.
- GoInstant: Acquired by Salesforce. GoInstant provides a JavaScript API for integrating real-time, multi-user experiences into any web or mobile application. It's easy to use and provides the full stack needed, from client-side widgets to publish/subscribe messaging to a real-time data store.
有纵向和横向的 BaaS 提供商，它们围绕特定领域提供服务或 API。电子商务领域、游戏领域、分析领域等都有供应商。
请记住在注册之前检查提供商的可信度。请记住，如果提供程序关闭，您的应用程序也会遇到麻烦。确保你了解他们的商业模式、产品路线图、融资模式（尤其是对于初创企业）以及他们对客户的倾听程度。您想搭便车，搭上一路带您的伙伴。