This chapter is from the book
This chapter is from the book
This chapter is from the book
Designing for the Cloud
Several exciting possibilities open up if we are designing the system for the cloud. We have two choices:
Shallow cloud integration: We write our services, pack them as containers, and run them in the cloud using cloud services for databases and storage only. Such a design architecturally behaves similarly to on-premises systems.
Deep cloud integration: We build the system using the cloud as much as possible, replacing all services with serverless functions and as much functionality with cloud and SaaS services.
Figure 2.2 shows an example of architecture for a bookshop that uses the cloud as much as possible.
)
FIGURE 2.2 Software architecture for a bookshop that uses the cloud.
Choosing such an architecture yields several advantages. First, it provides a faster time to market because it
Needs less coding and configuration
Avoids boilerplate code such as security logic with configurations
Replaces functionality with API calls
Focuses on business logic instead of plumbing
Provides HA, scalability, and DevOps out of the box
Second, it lowers platform costs by providing a true, pay-as-you-go model while eliminating idle time costs. Most applications have variable loads. However, according to the central limit theorem, when many of those variable loads are aggregated, the resulting workload has a predictable distribution curve even if the individual workloads are not predictable. Consequently, cloud platforms can operate with fewer resources despite the additional overhead. As a result, cloud providers enjoy substantial savings through economies of scale, which they can pass on to the users.
Third, cloud platforms lower development costs by taking over DevOps and monitoring costs. Cloud platforms can deliver DevOps and monitoring for a fraction of the cost, using economies of scale, tools, and optimized operations. They can also pass on some of those savings to the end user, creating a win-win situation for both.
Fourth, cloud architectures provide predictable costs, tying costs to the amount of work the system receives, thus reducing capital expenditures and the risks of operating the system. Usually, doing more work brings organizations more money; hence, having cost tied to future revenues is a welcome development. Because cloud platforms are metered with fine granularity, they provide greater insights into managing costs.
Cloud-based architectures also have disadvantages:
A deep cloud integration invariably creates a lock-in restriction, making it hard and expensive to move away from a cloud provider after going to production.
Using the cloud requires the team to learn new programming models. Furthermore, cloud platforms are opinionated, forcing programmers to follow preset patterns, allowing users little or no leverage to get those fixed if cloud features do not fit well with their requirements.
The cloud can be more expensive than other options if the system receives a significant load around the clock.
An architect must balance these pros and cons and decide on which approach to use, based on the key questions we discussed in this chapter. Sometimes, it may be more economical to accept the lock-in and commit to rewriting if we have to move out of the cloud.
Next, we move on to Part II, where we discuss performance and UX concepts, which are key tools for good design. However, if you do not want to delve into technical details, you can skip to Part III, where we discuss macro-level and micro-level design.