Greetings everyone, I hope that you are at the peak of your health. Get ready for another article on DevOps. Now DevOps is a combination of a lot of things. It has evolved with time. The development of DevOps is not only based on philosophies but is also based on tools and real-time experiences. This is the reason why DevOps is accepted, implemented, and proven successful worldwide. It facilitates applications and services with high velocity. This is pretty much helpful for big organizations. They can serve their customers in a better way and can compete effectively.

In this article, we are going to discuss the importance of DevOps for companies like Facebook and Amazon. Yes, both these IT giants have adopted and implemented DevOps in their own way. But before switching over to it, let us quickly understand the basic working of DevOps. This will give you a clear idea of how the companies have molded DevOps into their utensils, as per their requirements.

The working of DevOps

Image Source: https://dzone.com/storage/temp/3872960-devops-cycle.png

The DevOps model offers unlimited development and sustainability. The teams who work for a particular application can be basically divided into two main categories. The first category is the development team and the second category is the operation team. Please note that we are discussing DevOps in a generalized manner. In real-time, there are many teams working on different modules. But we can sum up the teams into development based and operation based. Sometimes, both these teams are merged into one. Under such circumstances, the engineers work across the entire application lifecycle from deployment to operations. While working for all the aspects, the engineers develop a range of skills. They are not confined to a single function.

Everything depends on the type of application. For example, in some applications, the quality assurance and security teams integrate tightly with the development and operations team. But most of the applications nowadays require high security. So the security team, development team, and the operation teams integrate. It is referred to as DevSecOps.

What do these teams do? They implement measures by automating processes. These processes were manual and slow in the past.  But now, they are quick. Different kind of tools and technology stack are used for boosting up the speed. Mind well, sustainability is not compromised with speed. The tools empower engineers to accomplish tasks independently. For example, code deployment and infrastructure provisioning require help from other teams. But with the tools in action, the game changes. So DevOps is not just good for the application, it is also good for the engineers.

The main benefits of DevOps

(1) Speed: With DevOps comes high velocity. So the developers can innovate faster and solve queries. Till date, the results have been precise and optimum.

(2) Delivery: The frequency and pace of releases are faster. This helps in quick product improvement. Fixings bugs might not be easy, but one can certainly fix it in less time with rapid delivery. On top of all this, DevOps offers continuous integration and continuous delivery to automate the software release process.

(3) Reliability: DevOps helps in maintaining the quality of application updates and infrastructure changes. So, at a higher velocity, the delivery is of the same quality. This is why DevOps is quite reliable.

(4) Bigger Scale and Collaboration: DevOps is adopted by IT giants. This means that it is capable of operating and managing big infrastructures with reduced risk. Under the DevOps cultural model, one can build more effective teams emphasizing on values like ownership and accountability. Team collaboration is also easier with DevOps.

(5) Security: Moving quickly is good, but one should also be able to retain control and preserve compliance, while in quick action. The DevOps model makes sure that one doesn’t give up on any security concerns. DevOps offers features like automated compliance policies, fine-grained controls, and configuration management techniques.

DevOps certainly offers good features, but this is just a generalized approach. So let us move on to specific case studies.

Facebook and DevOps

Image Source: https://image.slidesharecdn.com/pdffbpetdcpresentation-180530142540/95/tdc2018fln-trilha-devops-the-hacker-way-how-facebook-operates-at-scale-1-638.jpg?cb=1527690368

Some years ago, Professor Dror Feitelson (Hebrew University), Eitan Frachtenberg (Research Scientist at Facebook), and Kent Beck (working at Facebook) published an academic paper. It described Facebook’s approach to developing and deploying the front-end software. On the basis of that academic paper, let us understand the working of Facebook in tune with DevOps.

Continuous Deployment at Facebook: Is it really a Continuous Deployment??

Planning and working out is good, but this might not be the case with Facebook developers. While they have clear goals, they generally work in an independent manner. Small changes are released frequently, especially with Facebook’s online business model. The developers are keen to try out new options and applications, as per the user communities. Many changes are done independently.

Also, Facebook doesn’t follow continuous deployment, the way others do! For example, every change isn’t pushed out to the customers immediately. The code can be released twice a day, usually for bug fixes and internal code. The new production code is released once a week. So how is it done? There might be a lot of changes! Yes, the updates are wrapped up and run through an automated regression testing on Sunday. Once successful, they are released on Tuesday, only if the contributing developers are present on the day of release.

The team of release engineers asses on the risk of changes. It is based on the size of changes and the amount of discussion during the code review. There are some other factors as well! The engineers use a tool, known as “Gatekeeper”. This tool helps release the updates to specific customers, so if the changes aren’t successful, it is rolled back.

The concern of code ownership

With responsibility, people get more serious about everything. Same way, developers at Facebook are individually responsible for the code. From submitting the code, testing, and supporting production, the developer needs to cooperate. Their code ownership model reflects it.

So here comes DevOps, “Dev” and “Ops”. The developers support the operational use of their software, which together makes “DevOps”. So this is a motivation to write precise code. For example, if you write a complicated and faulty code, then you need to face the consequences of it. So code ownership is taken quite seriously in Facebook. There are only a few engineers who modify the code, and there is at least one engineer who reviews all these changes. 

The Testing Team: Does it even exist?

You must be thinking that codes undergo strict testing from testing teams at Facebook. Well, they don’t have an independent test team!!! First of all, Facebook emphasis a lot on code reviews for finding bugs. The code is reviewed by different engineers. Due to this, the author of the code ensures high-quality and the reviewer tends to learn new things by reviewing different codes. So it is a win-win situation for both.

Developers write their own unit tests, regression tests and then, they have automated tests. They also test the software by using a different version of Facebook, known as the development version. Customer reviews are also important for Facebook. They do practice A/B testing and live experimentation.

How about security?

Facebook relies on the use of libraries and frameworks when it comes to testing. While we don’t have much information on the security aspect of Facebook, it definitely uses libraries and frameworks to handle AppSec problems. Now, this also includes finding security bugs in the code reviews. There is less information on security probably because Facebook has a long list of public security failures and privacy violations.

The most interesting idea or concept is how the developers take responsibility for their code. The code reviews concept and dark launches is also a good thing. Small companies can also adapt to these concepts, developers can take their own code responsibility. It reduces the workload to a great extent.

Amazon AWS and DevOps

Image Source: https://d2908q01vomqb2.cloudfront.net/7719a1c782a1ba91c031a682a0a2f8658209adbf/2017/08/10/devsecops2_1.jpg

Amazon is one the most admired and prolific tech company. After 2006, the company switched its gears from just being an online retailer to a pioneer company working in the cloud space. The release of AWS (Amazon Web Services) approved this fact. So what is AWS? It is an on-demand infrastructure as a Service (IaaS). AWS is widely used by many companies. But coming up with AWS wasn’t easy, it involved a lot of risks. They literally entered an unknown domain by developing one of the first massive public cloud services. It included many unknown challenges and unproven solutions. But the outcome was and is good. So let us learn Amazon’s success story but discussing the right questions.

Number 1: What steps did Amazon take to minimize the risky venture?

Number 2: How did the engineers define their process to ensure quality?

Both these questions are important and luckily, there is a chance to get the answers. How? Google engineer Steve Yegge (a former Amazon engineer) accidentally shared an internal memo. It referred to Amazon’s successes at platform engineering. The memo outlines some decisions by CEO Jeff Bezos’s. These decisions explain his understanding and the background principles of DevOps. It includes some of the primary attributes of the AWS platform like interoperability, availability, reliability, and security. Jeff Bezos had issued a mandate during the early development of the AWS platform. Let us see what was included in it.

(1) “All teams will henceforth expose their data and functionality through service interfaces.”

This means that everyone has to follow a generalized approach. Even updating or representing the data/code should be done using the channel.

(2) “Teams must communicate with each other through these interfaces.”

The benefit of this is that the teams get familiar with the infrastructure and environment. Even for basic communication, they should use the interface.

(3) “There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.”

Now, this promotes progressive and precise communication. Until and unless the teams are not thorough with their own code or explanation, they won’t initiate a conversation. So indirectly, this means that communication should be point-to-point and precise.

(4) “It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.”

True, the main thing is to get the task done in the most optimum way! Here, Bezos is giving freedom to the engineers, they can choose their own technology. The beneifit is that the developers will go through the pros and cons of different technologies. They will then decide which one is the most suitable for a particular task or module.

(5) “All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.”

This is a clear indication that Bezos wants the team to be independent and confident. They should work from the ground level, they should know everything, and this certainly leads to quality development.

(6) “Anyone who doesn’t do this will be fired.”

There is nothing to explain in the above point. Pretty simple, if they can’t follow it, they should simply leave!

Now, this approach seems straight-forward or rather strict, but it has helped the company attain great heights!

The Outcome

If you ignore the strict part, you will notice that the engineering processes are being changed. The engineers must develop web service APIs to share data and communicate. So for this, the designated teams have to build usable APIs. If the APIs are not up to the mark, they will receive complaints from other teams that are using it. So testing is done naturally. The APIs should be reliable and available. Sharing data on a common platform also means that it needs some kind of protection. So for this, the APIs need to be secure. The data should be protected. Similarly, the data should also be stored to consume as fewer resources as possible. So then comes the data storage, reduction, auditing, and access control techniques.

The most important part is that these guidelines or rather rules must be followed by all the teams, not just the development teams. So for example, if the marketing team wants to access the data that you have collected, then they have to find a developer and use your API. So all this helped create an array of users, use cases, user types, scenarios, etc.

Conclusion

DevOps teaches a lot! It is not only about development, the approach matters as well! The desired attributes can be achieved, but DevOps teaches to create a process that helps attain quality attributes. One can say that the Amazon version of DevOps is the authoritarian version. The API improvements at Amazon are inspired by such authoritarian version.

Nowadays, software is not just supporting the business, it has rather become an integral part of it. Softwares aren’t just used for management, companies use it to communicate with the customers and for internal communications. So the concepts of DevOps perfectly match the criteria of building something that could transform the business. And what is that something? That something is a reliable, sustainable, flexible, deliverable, and responsible software. DevOps exactly helps attain it.

So why wait? Start with DevOps, right now!

To begin with DevOps, I recommend the Free E-Book, because I don’t want you to spend a single penny to get started with DevOps. Download it!

Here is the link:

https://level-up.one/devops-pdf-book/