This article is published by netease Cloud
Author: Lin Fan
preamble
With the maturity of cloud infrastructure technologies such as IaaS and PaaS, “cloud on Application” has become a priority for many enterprise software departments. By moving traditional software systems to the cloud, on the one hand, businesses can gain more resource flexibility, and on the other hand, operators can reduce the cost pressure, so that hardware resources will no longer be an obstacle to traffic and business growth. Cloud on this seemingly easy thing, but in fact it is a systematic project. Not to mention the changes introduced in technology, estrangement between organizations and departments, outdated development process, backward supporting tools, conservative consciousness of staff… Anything that pops up at any moment is enough to make what many initially thought was just an architectural redeployment far more complicated than expected.
Especially in the early years, the concept of “cloud native applications” was vague and there was no authoritative definition of what the cloud was supposed to do. Although there are Google, Facebook and many domestic and foreign Internet enterprises summed up the case, but are not universal, some small enterprises copy copy, trying to reach the position in one step, the result is to learn from handan end. From this perspective, netease cloud from the cloud native application architecture practice is indeed a book can let a person shine at the moment, it is aimed at the early stage of the Internet application spelling a flexible, medium-term growth spell and characteristics of the stable stage, clearly pointed out that in different size and period of the enterprise, on the implementation of cloud strategy should be completely different, It also expounds the practice and transformation approaches that enterprises should adopt in view of three typical development stages.
From DevOps to Cloud Native
One of the most important principles for using the “cloud native Application” architecture is to maximize the value that the cloud adds to your business. It might be tempting to think of another popular term, “DevOps.”
The spread of cloud computing has changed the delivery assistance model as it has turned expensive infrastructure resources into tap water. As computing resources become readily available to everyone through apis and self-service, development teams gain a great deal of autonomy and operations teams become more focused and efficient. The boundaries between development and operations in some mature Internet companies are becoming less clear. It was in this environment that Patrick Debois, a Belgian consultant, came up with the idea of DevOps in 2009, inspired by the practices of Flickr. It was earlier than The Twelve-Factor App manifesto proposed by Heroku founder Adam Wiggins in 2012, and The practice advocated by this manifesto later formed The basis of Cloud Native architecture.
Both DevOps and Cloud Native were born in the context of Cloud infrastructure. There are also many similarities between the ideas advocated by the two. For example, DevOps advocates global optimization from the perspective of end-to-end delivery efficiency, reduces cross-team collaboration friction, and promotes the organizational structure of full-function teams, which leads to the emergence of microservices practice. The architectural form of microservices is exactly an architectural mode that can give full play to the capabilities of Cloud infrastructure advocated in Cloud Native practice. Similar examples are advocating service capability API, delivery process automation and visualization, and so on.
At a higher level. DevOps focuses on process and collaboration improvements and introduces technical tools; Cloud Native originally focuses on the design of architecture and the utilization of Cloud infrastructure, but it also involves processes and tools. So rather than disassociate the two, think of Cloud Native as an extension of DevOps in the architectural realm.
Cloud native architecture for startups
Many startups choose to use cloud platforms to launch their applications, not because of the scalability, openness, or rich functionality of these clouds, but simply because of the “cost-effective” characteristics of the platform, such as accurate billing and stability, reliability, and ease of use. Enterprises at this stage typically require very few server instances and a simple, easy-to-use architecture without the need to partition components and therefore without the hassle of integration.
Using complex delivery tools and processes in such an enterprise is like killing a chicken with a knife. I made this empirical mistake once on a brief, small project, a very simple Web service, and out of habit I took care to design an automated release pipeline for the project: build, package, release test environment, release live environment. Everything is deployed on a cloud host with container isolation, the test environment and the online environment just use different ports, and everything works fine. Until one day, when the server changed its password, the Jenkins service running in the container could not connect to the host port, and kept printing error logs, which soon filled up the entire host disk. Fortunately, the problem occurred during working hours and was detected in time without causing any damage. The thing that struck me about this was not that the pipeline wasn’t right, but that we focused on doing a lot of automation and didn’t use the cloud to do the things that we needed to do, like monitoring.
The biggest value of cloud architecture for startups is that it simplifies operations. Having dedicated operations staff for small projects can be a luxury, but already overworked developers don’t want to devote much time to the day-to-day grind of an online environment. At this point, if the server monitoring, database backup, service health check and other capabilities provided by the Cloud platform can be used, it is equivalent to the full interaction between the application and the Cloud, which is the embodiment of Cloud Native design.
Cloud native architecture for growing enterprises
When the business model of the enterprise is verified, more and more access traffic and user data is not only the performance that product managers are eager to see, but also the huge test and challenge that the project development team is facing. At this stage, service complexity reaches a point where splitting components is the inevitable choice and cross-team integration begins to emerge. At the same time, in order to withstand the greater pressure of concurrent access, horizontal scalability of services becomes very important. In addition, security of services is increasingly on the agenda.
The twelve-factor App principle mentioned above is now coming into play, and this stage is The most valuable phase of Cloud infrastructure and The state of business scale assumed by The numerous articles on Cloud Native practice that have flooded The Internet. Continuous integration and continuous delivery practices often need to be introduced in order to coordinate and visualize delivery schedules between teams. Gray scale publishing and A/B testing are the local trial-and-error methods that are commonly used in the face of A diverse user group. Monitoring is still an essential topic, and more comprehensive, accurate and timely failure event notification is the key to ensuring service scale. As the number of services increases, log management will also be brought to the table. By analyzing business logs, users’ behavior and potential system problems can be predicted earlier. Fluctuating morning and evening traffic also often requires massive service expansion. At the same time, more databases and more message-oriented middleware bring more day-to-day administration. If the project team had to start from scratch to design solutions to these problems, it would have taken a long time.
Chips are enterprises, give full play to the advantages brought by the cloud platform, means a API call can achieve change in the server storage capacity, a CPU overload alarm can immediately trigger a new node of creation, initialization and cluster expansion, zero maintenance workload of efficient message queue, zero cost management more copies of a highly available database. On the one hand, the application is designed as a service group that can make full use of the capabilities of cloud integration facilities, have horizontal expansion conditions, and can be arranged and deployed. On the other hand, try to avoid reinventing wheels on infrastructure capabilities and simplify the complexity of the overall architecture by using cloud platforms. These Cloud Native factors are also external guarantee and internal motivation for the success of many Internet products.
Cloud native architecture for stable enterprises
There are few enterprises and products that can truly withstand the market’s grinding and enter a stable period. Once enough sticky users are accumulated and the gap in the product growth period is crossed, it seems that they have entered a deep sea that shows calm but actually undercurrents are surging. The Internet products that survive are often deeply rooted in Cloud Native practices, whether or not they are actively aware of Cloud Native’s existence: No team of a few thousand people can succeed without relying on the platform and the cloud, or without adopting advanced delivery process practices, leaving it to developers to implement all the basic services all over again, and adopting a simple and crude release process of a small workshop.
The problem these enterprises are facing is no longer how to use Cloud Native, but how to make better use of Cloud capabilities to replicate the advantages of existing business areas from 1 to 100 to other areas, so as to achieve greater success. So constant reorganisation and search for innovative breakthroughs are commonplace. Microservice architecture is the direction that many enterprises entering the stable period are exploring. Through the separation of microservices, especially the advanced practice of domain-driven design, it can better match the technical architecture and business architecture of enterprises and provide confidence and guarantee for the possible expansion of business domains in the future.
At this stage, cash-rich enterprises will start to consider building their own data centers to save costs over a longer period of time through one-time investment up front. Issues such as geo-redundant disaster recovery, active/Standby disaster recovery, or multi-active disaster recovery are 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 public cloud (Yi Xiaoyun: Don’t forget exclusive cloud, which is also public cloud in nature, but with stronger privacy and customization), or combine the two to form a hybrid cloud architecture. The practice of highly integrated application and Cloud can be regarded as the ultimate form of Cloud Native.
conclusion
When everyone is still clamoring for the application of Cloud, there is such a group of people, they calm down to settle down their various practices in Cloud development, gathered into a very wonderful Cloud Native Application Architecture Practice pillow book. It is believed that it can accompany everyone on the road of technology growth, cross the growth gap of Internet products, and walk towards the broad road of Cloud Native.
About the author: Lin Fan, DevOps and Container technology consultant, currently working at ThoughtWorks, is engaged in software development operation and maintenance consulting and community promotion, with rich experience in container scale operation and maintenance. StuQ Guest lecturer, author of CoreOS Practical Road, and has published many articles in the field in CSDN, InfoQ and other industry media.
Understand netease Cloud:
The official website of netease Cloud is www.163yun.com/
New user package: www.163yun.com/gift
Netease Cloud community: sq.163yun.com/