Impact on organizations when moving to cloud native
There are hundreds of companies out there, such as Netflix, Uber, Airbnb, and WeChat, that use cloud native in their production. With cloud native applications, these organizations manage huge amounts of incoming traffic into the system. Some of these organizations have not only moved to cloud native architectures, but have also developed many open source tools to develop cloud native applications. Moving to cloud native is not easy, as there are a lot of obstacles to get over. Yet switching to cloud native makes a company even more agile and efficient in terms of organization management.
Challenges of moving to a cloud native architecture
Cloud native offers scalable, cost-effective architecture that can easily be managed. But without adequate system analysis, moving to a cloud native architecture is challenging. As technology evolves rapidly, switching from one software architecture to another is not that easy. With long-standing legacy software written in a monolithic architecture, migration is more difficult. Moving to cloud native is not just a technological transition but also a cultural change in the organization as a whole. The following are some of the difficulties of switching from a monolithic architecture to a cloud native architecture.
Outdated technologies
Outdated technologies have problems with rising costs, lack of competition, decreased productivity, lack of flexibility, and problems with security. Technologies used to construct the system may no longer be supported. Using the same technology stack without production support is challenging. Also, cloud native concepts might not suit these old technologies. When those technologies are no longer community-supported, things get worse. Often, certain components need to be designed from scratch. This takes a substantial amount of time and cost.
Operational and technology costs
It isn't an easy task to switch from one technology to another, and it takes both time and money. It is not only expensive to switch but also to support and maintain the new technology as it needs highly skilled engineers. Even though it comes at a cost, the advantages of cloud native make the end user experience much better.
Building cloud native delivery pipelines
Cloud native applications are expected to run on the cloud. The cloud may be public, private, or hybrid. Traditional apps can use an on-premises infrastructure to deploy the system. Moving from monolithic deployment to cloud native deployment is complicated, as there are many moving parts that need to be configured. A cloud native application cannot be deployed manually, as hundreds of different applications need to be deployed. Developers should build an automated deployment to automatically deploy the system. Building these delivery pipelines costs both time and money.
Interservice communication and data persistence
Unlike monolithic applications, the cloud native application database is divided into several databases where each service has its own database. Changing the database architecture can be a huge pain point for the developer, since the entire application architecture and systems may need to be updated. In addition, the architecture of microservices allows developers to use asynchronous communication methods rather than a synchronized communication pattern. If the previous system was designed with tightly coupled synchronized communication, there will be significant changes required to accommodate event-driven architecture.
In the next section, we will discuss Conway's law, which fits the cloud native architecture well. We can use this law to build more sophisticated cloud applications.
Conway's law
Moving to cloud native is not only an architectural change in technology but also a cultural change for the organization as a whole. Cloud native will deliver much more agile development than monolithic application development. Melvin E. Conway came up with Conway's law in 1967, stating that any organization that designs a system will design it with a structure that copies the organization's communication structure. After decades of microservices coming to the fore, Conway's law provides guidelines on how a team should be organized:
Simply put, the communication structure of the organization is often focused on the process of product development. For example, in the order management system, different teams in the order management system interact with each other as separate teams. The order service calls the inventory service to confirm whether the products are available. The order service calls the payment service to complete the transaction. The product we are creating has a communication structure similar to that of the organization.
Note
Conway's idea was initially not limited to software development. After Harvard Business Review rejected his article, Conway published it in a programming journal. Fredrick P. Brooks later quoted these ideas as Brooks's law in his book The Mythical Man-Month.
Next, we'll review Conway's laws.
The first law
The first of Conway's laws is about the size of teams in an organization. This law requires that a team be as small as possible. To understand how small it should be, consider how much of a personal relationship you have with each team member. If the relationships are weak, this means that the team size is big. Increasing the number of people to get things done quickly is not as straightforward as expected. Having bigger teams makes the coordination overhead bigger. Brooks proposes a method to calculate the cost of communication and complexity depending on the number of team members (n):
Communication cost =n(n-2)/2
Complexity = O(n2)
According to the equation, you can clearly see that communication costs and complexity increase exponentially while increasing the number of team members. Therefore, to create a part of a product, small teams must be preferred as they perform much better.
The second law
The second law is all about there being no perfect systems. Human resources are limited in an organization, as is human intelligence. It is okay to neglect certain components when constructing a complex system. The focus of production is more on the delivery of the key components. There may be issues with a distributed system. You should develop a system that can withstand failures and recover from them instead of building a perfect failure-proof system. A system might fail at some point, but your system should be able to recover fast from a failure.
The third law
The third law discusses the homomorphism between the system and the design of the organization. As I mentioned earlier, the communication structure depends mostly on the process of product development. Team boundaries are also mapped to the system boundaries. Each team has its own business domain. Inter-team communication is often less frequent than intra-team communication. Make teams smaller and let team members concentrate on the task and do it in collaboration with other team members, only engaging with other teams if they must. This reduces the cost of communication between multiple teams.
The fourth law
The fourth law is about building organizational architecture with a divide and conquer approach. When a team gets bigger, we need to divide the team into smaller teams. Every team manager reports to a higher-level manager, with each manager in the company reporting to a manager in a higher layer in a pyramidal structure. The divide and conquer strategy helps to create and maintain a large organization.
By comparing the architecture of microservices and Conway's laws, we can clearly see similarities between these two approaches:
- Systems have distributed services/teams that solve a particular problem.
- Systems/organizations are separated by business lines.
- Services/teams focus on building the product rather than delivering the project.
- Believe that nothing works perfectly. Failures should be expected.
Next, we will look at an organization that has moved to cloud native technology and serves its products to millions of customers. Netflix is a video streaming company that migrated to cloud native architecture successfully, and also generates new open source tools for developers. Let's look at their journey to cloud native architecture in the next section.
Netflix's story of moving to cloud native architecture
Netflix was founded in 1997 by Reed Hastings and Marc Randolph in Scotts Valley, California. Initially, Netflix was a movie rental service where customers ordered movies on the Netflix website and received a DVD in the mail. As a result of the advancement of cloud technologies, Netflix announced in 2007 that it would launch a video streaming service and move away from selling DVDs.
In 2008, Netflix encountered major database corruption, which forced it to transfer all of its data to the AWS cloud. Netflix was deeply concerned about possible future failures since they were heavily focused on cloud streaming rather than renting DVDs. They started moving into the cloud by moving all customer databases to a highly distributed NoSQL database called Apache Cassandra.
Constructing a highly available, scalable, and high-performance infrastructure is a key aspect of moving into the cloud. It wasn't that easy for Netflix to move on-premises data centers to the public cloud. The migration process began in 2009 by transferring movie encodings and non-customer-facing applications. Netflix transferred account registration and movie selection by 2010 and completed cloud migration by 2011. The migration process was not simple since migration had to be carried out without any downtime.
They ensured that all on-premises servers and cloud servers were kept together to provide customers with continued operation. However, during the transition phase, they had to deal with lots of latency and performance problems. During this migration, Netflix implemented the following open source tools for the company to transition to cloud native architecture:
- Eureka: A service discovery tool
- Archaius: A configuration management tool
- Genie: A job orchestration tool
- Zuul: A layer 7 application gateway
- Fenzo: A scheduler Java library
You can find out about all of Netflix's cloud native tools in the official Netflix Open Source Software (OSS) Center in the GitHub repositories.
John Cianutti, Netflix VP of engineering, mentioned that they do not need to be concerned about upcoming traffic into the system. Since the platform is deployed on AWS, they can add resources as per requirements dynamically. Cloud native is about scaling the system when it is required. An organization can be scaled up on the basis of the traffic it receives. When an organization deploys services on the public cloud, it can quickly scale up with the dynamic resource allocation features provided by cloud providers. This means Netflix can focus on streaming services rather than maintaining data centers.
According to 2020 reports, Netflix serves more than 192 million subscribers worldwide. Netflix became a cloud native role model with how it converted on-premises monolithic applications into a scalable cloud native architecture. The tools it has developed are indeed very useful for constructing a cloud native application.