From monolithic to cloud platform to financial-grade hybrid cloud
Cloud computing has grown rapidly for years. Moving to the cloud is no longer a major issue. The next challenge is how to use the cloud effectively and efficiently. Data from the 2019 RightScale report shows that 22% of customers use only public cloud and 3% use only private cloud. Most customers use a hybrid model. A hybrid cloud helps them strike a balance between data privacy, security, efficiency, and elasticity.
In the global IT industry, public cloud accounts for only 10% of the total IT market. The market still has significant room to grow. Many of the remaining customers are traditional enterprises. A key reason traditional enterprises cannot fully use the public cloud is that most have built their own data centers over time. Others have stable business operations and do not have a strong need to move to the public cloud. These enterprises often develop a hybrid cloud strategy. They keep their core business on a private cloud while placing edge or innovative business on a public cloud.
These characteristics are also evident in the finance industry. In addition, the finance industry has two other distinct features:
Business models are becoming more open and Internet-based. Because the Internet and the digital economy are growing, financial institutions require digital transformation. They also need business agility and scenario-based services to adapt to new business models.
The need for regulatory compliance. The nature of the finance industry requires strong isolation and strict regulation. Therefore, the shared resource model of the public cloud presents significant compliance challenges.
A hybrid cloud strategy is therefore more suitable for financial institutions. A report from Nutanix supports this conclusion. It shows that the global finance industry is adopting hybrid cloud faster than other industries. The deployment rate in finance is 21%, compared to the global average of 18.5%.
So, what kind of hybrid cloud is right for financial institutions? The following sections answer this question by examining the evolution of Ant's technical architecture.
Stage 1: Centralized
The first Alipay system was built by developers without experience in large-scale systems. The first-generation architecture was very simple. It was a monolithic application deployed on a single application server. It used one database and served one major customer: Taobao. This simple system supported Alipay's early growth from 2005 to 2006. Although simple, it allowed for rapid changes. When a product manager wanted a change, it could be implemented immediately with a simple code modification. For example, the Alipay Red Packet feature went from request to online in just four days. But as the business grew, this simple system could not support higher transaction volumes or more complex business needs.
Stage 2: Distributed
Starting at the end of 2006, the drawbacks of the monolithic application became clear. The Alipay team decided to take a path no one had taken before. They started building the second-generation Alipay architecture, which involved making the system service-oriented. This distributed architecture was named SOFA, which stands for Service Oriented Fabric Architecture. The first generation of SOFA solved two main problems. First, it provided a "glue" mechanism, or a connector, to connect the distributed systems. Second, it ensured each service was component-based. The first generation of SOFA used OSGi, a Java modularity specification for building applications from reusable and collaborative components. This allowed each engineer to focus on their own components. These components could then be assembled into services, and the services could be assembled into the larger system. This entire framework was the first generation of the SOFA framework. After solving the service-oriented problem, the next challenge was consistency. Solving the distributed consistency problem requires a distributed commit protocol. If this protocol is implemented at the database layer, it is very inefficient. This is because the database layer has no knowledge of business logic. It can only implement the protocol in a generic way, which prevents optimization for the business logic layer. So, the team decided to place the commit protocol in the service layer. Around January 2008, the eXtended Transaction Service (XTS) project went online. After its release, it was continuously refined. It still supports all business transactions for Ant Group today.
Stage 3: Self-developed platform
The most important development in this stage was the launch of a self-developed database, now known as OceanBase (OB). Using SOFA and OB, Ant replaced its stack of IBM AIX servers, Oracle databases, and EMC storage. At this point, Ant's overall financial distributed architecture was complete.
Stage 4: Cloud platform
In the fourth stage, Ant's technical architecture evolved into a cloud platform architecture. To meet the demand for elastic resources caused by burst traffic from Internet-based business, Ant also evolved its architecture into an elastic hybrid cloud during this stage.
Stage 5: Cloud-native
Ant has now evolved to its fifth-generation cloud-native architecture. The evolution to a financial-grade hybrid cloud on a cloud-native architecture was guided by a core set of principles. These principles, which Ant applied to its development at every stage, include autonomy, cost, security, stability, massive scale, and agility. For online finance, these are the requirements for a cloud-native architecture.