Anti-patterns have evolved as the project progresses for the following causes: Major requirement adjustments exist, but no corresponding changes are made in the architecture. Performance and security needs require changes to the current architecture, and teams or organizations decide to adjust the technology. This article describes the common anti-patterns of cloud-native architecture.
If you have ever maintained or developed giant monolithic applications, you have encountered annoying problems, such as a huge Git warehouse, slow IDE startup, compilation, application startup, and too many dependent services. It is next to impossible for novice developers to be able to copy the code, compile it successfully, and start the application normally. More often, it takes at least 1-2 weeks for O&M personnel to understand a huge application. Otherwise, they cannot start writing code. However, huge monolithic applications still apply to certain scenarios. This article will not discuss circumstances where microservices are not suitable. You need to make reasonable decisions based on real-world situations. However, the microservice architecture is suitable for most business scenarios.
The division of applications conforms to a scientific methodology. We can make changes with ease only by understanding the principles of the system and getting rid of the one-size-fits-all mindset. The core is the division idea of Domain-Driven Design (DDD).
The essence of DDD is to divide the system into different business areas based on business attributes, such as members, commodities, transactions, and logistics in the e-commerce system. We need supporting systems to cooperate with these business operations, such as CMS and social operation platforms. Big data and AI platforms are also essential for the business needs of personalized recommendations.
After you divide a business into subdomains based on the Domain principle of DDD, Bounded Context is used to implement the subdomains. Consider Bounded Context as a microservice application. Multiple Bounded Contexts can jointly support a subdomain to implement the required business functions. DDD provides a complete mechanism for association and communication between Bounded Contexts. For example, the latest DDD + Reactive pattern brings asynchronization and the event-driven idea to the microservice architecture.
The subdomains of DDD are divided into core, common, and supporting subdomains. The common and supporting subdomains are generic subdomains. The specific business form of a generic domain can be a SaaS service or a technical product provided by cloud service providers, such as business-related operation, distribution, storage management systems, CRM management systems, and social marketing platforms.Technical products include application performance monitoring, picture recognition service, and data analysis platform. In the early and middle stages of the project R&D, we recommend integrating the common and supporting subdomain services provided by third parties or cloud service providers and focusing on the core subdomain of the business. The core subdomain must be launched with complete features as scheduled, and the development progress and imperfect features of the common and supporting subdomains cannot affect the core domain. You can consider whether to implement the common and supporting subdomain services independently later in the project. You can learn from typical customers. Generic services that support core businesses have gained success along with the development of commercial projects, such as the AWS cloud service of Amazon.
When the number of microservice applications is small, the system can be maintained manually. However, if the number of applications becomes huge, manual maintenance becomes impossible. You need automated methods to manage a large number of microservice applications. Automated management of applications involves multiple aspects, such as compilation, deployment, and monitoring. Currently, most PaaS platforms and cloud service providers provide services that have automation capabilities. You do not need to develop the services. You only need to integrate with them, configure a few settings, or add relevant tracking points for monitoring.
You can find multiple frameworks on the market that support testing automation, such as CI/CD and IaaS. Kubernetes command tools and service APIs are available, such as Testcontainer for the automated testing environment, Database Rider for testing data automation, and Hoverfly-Java, which allows you to simulate HTTP REST API. These frameworks and tools facilitate automation. However, building automation capabilities depend more on the awareness of the team than on the technical products. If you decide to use the microservice architecture, we recommend thinking ahead about the automation capability of microservices and planning in a unified manner. This way, you can avoid making mistakes even when faced with situations, such as a sharp increase in the number of microservice applications and inconsistent technology stacks. When developers are engaged in the development and maintenance of 3-5 microservice applications at the same time, switching between different applications without making mistakes is difficult. Therefore, automated CI/CD is the minimum requirement for microservices.
The architecture of a cloud computing service can be divided into IaaS, PaaS, and SaaS, as shown in the figure.
IaaS sits at the bottom and provides services, such as servers, storage, and networking. These are all infrastructure, such as cloud servers and storage services. PaaS is on top of IaaS, PaaS is an abstraction of IaaS resources and shields the details in IaaS, and Kubernetes belongs to PaaS. SaaS is at the top and directly provides services and service connections. OpenAPI integration and calling short message sending service of Alibaba Cloud are two sample SaaS services.
In theory, we recommend directly using the SaaS services, while SaaS service providers are responsible for servers, storage, and resource expansion. On the PaaS layer, you need to develop internal applications, which will involve issues (such as application deployment). Therefore, the PaaS layer is highly automated (such as automatic management of resources). If you need auto scaling, we recommend auto scaling on the PaaS platform. Auto scaling for IaaS is difficult because you cannot purchase cloud servers or storage resources randomly. After you purchase these resources, you need to perform a series of operations to initialize the environment, set up an Ops monitoring system, deploy applications, and launch applications.
After an application is turned into microservices, small teams must be responsible for different microservice applications. You may need to reorganize the management team, development team, and infrastructure O&M team. This will lead to adjustments in the organizational structure and management methods.
One of the changes is that team management tends to be flat. In the scenario of developing and maintaining a huge application, each developer focuses on one module. Before requirements changes are made or a new feature is developed, all developers go through the standard procedure: evaluation, task breakdown, and planning development progress. Developers know the modules best and can ensure that all the processes are controllable. The application is launched as a whole after complete testing in the end. A microservice application is also required to adjust based on business needs. However, the process no longer involves the whole team working or launching the application or services together. The development and adjustment of features are likely to be divided into multiple stages for development and launch. Since different service conventions exist between microservices, applications can be gradually developed and launched. In this development mode, a microservice can be developed fast, one step at a time. Huge applications can also adopt this method.
After an application is turned to microservices, each service becomes more focused and smaller for the development team. However, all components of an application are also needed in a microservice application. Microservice application development also requires a developer to have rich knowledge. The developer can seek help from others on the team, but this causes communication costs and reduces R&D efficiency. Therefore, a developer must be able to solve 90% of the problems. In addition, microservice application development especially requires the capability of working independently. The microservice architecture is a multi-language, multi-technology stack architecture. A developer is not required to have an in-depth understanding of the programming language and technology stack of each microservice, but the corresponding development techniques are a must. For example, if you are a Java programmer and you are required to maintain Node.js applications, you do not need to know the underlying knowledge of Node.js (such as V8 and EventLoop). You can do the work as long as you understand JavaScript syntax, module management, Promise, and Async/Await. These changes bring new challenges to the development team because team members need to learn and understand more knowledge than before.
The infrastructure O&M team needs better PaaS services to cooperate with the development team (such as custom development based on Kubernetes or PaaS platforms provided by cloud service providers). Only with a sufficient guarantee can the O&M team work faster and better.
482 posts | 48 followers
FollowAlibaba Cloud Native - November 23, 2022
Alibaba Developer - January 9, 2020
Alibaba Clouder - July 14, 2020
OpenAnolis - December 7, 2022
Aliware - July 27, 2020
Alibaba Cloud Native Community - September 20, 2022
482 posts | 48 followers
Follow
Bastionhost
A unified, efficient, and secure platform that provides cloud-based O&M, access control, and operation audit.
Learn More
Managed Service for Grafana
Managed Service for Grafana displays a large amount of data in real time to provide an overview of business and O&M monitoring.
Learn More
Microservices Engine (MSE)
MSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.
Learn More
Architecture and Structure Design
Customized infrastructure to ensure high availability, scalability and high-performance
Learn MoreMore Posts by Alibaba Cloud Native Community
