Author: Lin Fan
preface
With the maturity of cloud infrastructure technologies such as IaaS and PaaS, "applying to the cloud" has become a major concern of many enterprise software departments. By moving traditional software systems to the cloud, on the one hand, the business side can gain more resource flexibility, and on the other hand, it can also ease the cost pressure on the operator, so that hardware resources are no longer an obstacle to traffic and business growth. The seemingly easy task of migrating to the cloud is actually a systematic project. Only when it is really done will the problem of chicken feathers be discovered, not to mention the changes introduced in technology, organizational divisions, outdated development processes, outdated supporting tools, and conservative personnel awareness. What many initially thought was just changing the architecture and redeploying it turned out to be far more complex than expected.
Especially in the early years, the concept of "cloud-native applications" was relatively vague, and there was no authoritative and clear definition of what to do when applications migrated to the cloud. Although there are cases summarized by Google, Facebook, and many domestic and foreign Internet companies, they are not universal. Some small-scale companies have copied and copied them, trying to do it in one step, but ended up in Handan as a toddler. From this point of view, NetEase Cloud's "Cloud Native Application Architecture Practice" is indeed a book that can make people's eyes shine. It aims at the characteristics of flexible early stage, mid-term growth, and later stage stability of Internet applications. It points out that enterprises in different scales and periods should implement different strategies for migrating to the cloud, and expounds the practices and transformation approaches that enterprises should adopt for three typical development stages .
Pictures from the Internet
From DevOps to Cloud Native
A very important principle of using the "cloud-native application" architecture is to maximize the value of the cloud to the business. Mentioning this is probably easy to think of another word "DevOps" that is also very popular now.
The popularization of cloud computing has turned expensive infrastructure resources into tap water and “weighing” billing, and it has also brought about changes in the delivery assistance model. Computing resources have become easily accessible to everyone through APIs and self-service, development teams have gained great autonomy, and operations and maintenance teams have become more focused and efficient. In some mature Internet companies, the boundaries between development and operation and maintenance have become less clear. In such an environment, Belgian consultant Patrick Debois came up with the concept of DevOps in 2009, inspired by the practice of Flickr. It predates The Twelve-Factor App manifesto proposed by Heroku founder Adam Wiggins in 2012, and the practices advocated by this manifesto later formed the basis of the Cloud Native architecture.
It can be said that both DevOps and Cloud Native were born in the context of cloud infrastructure. The ideas advocated by the two also have many similarities. For example, DevOps starts from the perspective of end-to-end delivery efficiency, advocates global optimization, reduces cross-team collaboration friction, and advocates the organizational structure of full-featured teams, which has led to the emergence of microservice practices. The architectural form of microservices is precisely an architectural mode advocated in Cloud Native practice that can give full play to the capabilities of cloud infrastructure. Similar examples also advocate API-based service capabilities, delivery process automation and visualization, and so on.
From a higher level. DevOps focuses on the improvement of processes and collaboration, and by the way introduces some technical tools; while Cloud Native originally focused on the design of the architecture and the utilization of cloud infrastructure, but also involved processes and tools . Therefore, rather than distancing the relationship between the two, it is better to think of Cloud Native as an extension of DevOps in the field of architecture.
Cloud-native architecture for startups
Many start-ups choose to use cloud platforms to publish their applications, not because these clouds provide good scalability, openness, or rich functions, but only because of the platform's accurate billing and stable, reliable, Ease of use and other "high cost performance" characteristics. Enterprises at this stage usually only need a few server instances, and a simple and easy-to-use architecture that does not need to divide components, so there is no integration trouble.
Using complex delivery tools and processes in such a business is tantamount to killing the chicken with a knife. I made this empirical mistake once in a short-lived small project, it was a very simple web service, and out of habit, I designed an automated release pipeline for the project: build, package, publish Test environment, release online environment. Everything is deployed on a cloud host, isolated with containers, the test environment and the online environment just use different ports, and everything works well. Until one day the server changed the password, the Jenkins service running in the container could not connect to the host port, kept printing the error log, and quickly filled the entire host disk. Fortunately, the problem occurred during working hours and was discovered in time without causing any losses. What inspired me is not that the use of pipelines is wrong, but that we focus on doing a bunch of automated things, but we do not use the cloud platform to do the best things in advance, such as monitoring.
The greatest value of cloud architecture for start-ups is that it can simplify operation and maintenance. It is a luxury to add full-time operation and maintenance personnel for small projects, but developers who are already exhausted are obviously not willing to take too much time to take care of the online environment. daily chores. At this time , if you can make good use of the server monitoring, database backup, service health check and other capabilities provided by the cloud platform, it is equivalent to fully interacting the application and the cloud , which is the embodiment of Cloud Native design.
Pictures from the Internet
Cloud-native architecture for growing enterprises
When the business model of the enterprise is verified, more and more access traffic and user data are not only the results that product managers are eager to see, but also the huge test and challenge faced by the project development team. At this stage, the service complexity has reached a certain scale, splitting components is an inevitable choice, and cross-team integration begins to appear. At the same time, in order to resist greater concurrent access pressure, the horizontal scalability of services has become a very important thing. In addition, the security of services also needs to be put on the agenda gradually.
The Twelve-Factor App principle mentioned above is now in play. This stage is the stage where cloud infrastructure can best reflect the value, and it is also the business assumed by a large number of articles introducing Cloud Native practice on the Internet. scale status. Continuous integration and continuous delivery practices are often introduced in order to coordinate and visualize delivery progress between teams. In the face of difficult user groups, grayscale publishing and A/B testing are usually partial trial-and-error methods. Monitoring is still an essential topic, and more comprehensive, accurate and timely notification of failure events is the key to ensuring service scale. With the increasing number of services, log management is also a matter of priority. By analyzing business logs, user behavior and potential system problems can be predicted earlier. The fluctuating traffic in the morning and evening often requires large-scale service expansion and contraction. At the same time, more databases and more message middleware also bring more daily management work. For these various problems, if the project team is to redesign the solution by themselves, I don’t know if it should be done in the year of the monkey.
For enterprises in the growth stage, making full use of the platform advantages brought by the cloud means that the server storage capacity can be changed by calling an API, and a CPU overload alarm can immediately trigger the creation, initialization and cluster expansion of new nodes. Efficient message queue with zero maintenance workload, and multi-copy high-availability database with zero management cost. On the one hand, the application is designed as a service group that can fully utilize the capabilities of cloud integration facilities, has horizontal expansion conditions, and can orchestrate and deploy ; These Cloud Native factors are also the external guarantee and internal driving force for the success of many Internet products.
Cloud-native architecture for stable enterprises
There are few companies and products that can really withstand the market’s polishing and enter a stable period. Once they accumulate enough sticky users and cross the gap between the product growth period, they seem to have entered a deep sea that is calm but actually undercurrent. . These surviving Internet products are usually deeply rooted in Cloud Native practices, regardless of whether they are actively aware of the existence of Cloud Native: no team as large as several thousand people can be independent of the platform and cloud, or It is possible to make the product successful by not adopting advanced delivery process practices, completely letting developers re-implement all basic services, and adopting a simple and rough release process in a small workshop style.
The problem faced by these enterprises is no longer how to use Cloud Native, but how to make better use of cloud capabilities to replicate the advantages in existing business areas from 1 to 100 to other areas in order to obtain greater success. Therefore, continuous organizational restructuring and finding breakthroughs for innovation are commonplace. Microservice architecture is the direction that many enterprises entering the stable period are currently exploring. Through the splitting of microservices, especially based on advanced practices such as domain-driven design, the technical architecture of the enterprise can be better matched with the business architecture . Potential expansion of business areas provides confidence and assurance.
At this stage, companies with sufficient funds will start to consider building their own data centers, and save costs in a longer time span through a one-time investment in the early stage. Issues such as three centers in two places, active/standby or multi-active disaster recovery have begun to be put on the agenda. Next, build your own customized private cloud platform on top of these data centers and continue to explore more advanced cloud-based delivery practices. Some enterprises will still choose to continue to expand their business in the public cloud (Yi Xiaoyun: Don’t forget the dedicated cloud, which is also a public cloud in essence, but with stronger privacy and customization), or combine the two to form a hybrid cloud. Architecture. This highly integrated practice of application and cloud can be regarded as an ultimate form of Cloud Native.
Pictures from the Internet
Summarize
When everyone is still clamoring to apply applications to the cloud, there are such a group of people who calm down and settle down the various practices of their own development in the cloud and gather them into "Cloud Native Application Architecture Practice" This is very exciting. Cloud Native Pillow Book. I believe that it can accompany everyone on the road of technological growth, cross the growth gap of Internet products, and move towards the clear road of Cloud Native.
About the author : Lin Fan, DevOps and container technology consultant, currently works at ThoughtWorks, engaged in software development operation and maintenance consulting and community promotion, and has rich experience in container scale operation and maintenance. StuQ special course lecturer, author of the book "CoreOS Practice Road", and published many articles in related fields in CSDN, InfoQ and other industry media.