In the traditional SaaS (Software-as-a-Service) industry, around 2013, companies had three distinct organizations: Development, QA and Operations. Developers built the code for the application that was tested by QA and the operations team was responsible for deploying it in production and managed the uptime of the service. Applications were largely monolithic with very few moving pieces. It was fairly easy for development teams to come up with deployment topology along with operations. The topology also largely remained unchanged through the release cycles. Cloud, micro services, and Containers (Docker) were not mainstream. People used public cloud still largely as IaaS (Infrastructure-as-a-Service) for on demand storage, compute and network.
While this was state-of-art then, inside AWS in Amazon which was already 8 years old, there was a different application technology and supporting that was a different organization structure and culture. They had mastered what was known as a SOA (Service Oriented Architecture). Applications were broken down into scores of sub-modules called services which interacted with each other using APIs.
There were two main advantages:
- The release cycles were exponentially faster because individual services had a smaller footprint.
- Failures in one service had a limited impact on the overall system.
SOA soon came to be known as microservices. While these were the obvious advantages, this new way of doing things significantly increased the infrastructure and operations complexity simply because of the number of moving pieces, the associated configuration management and distributed security footprint. The silos of development, QA and operations could no longer scale. There would have been too much back-and-forth between developers who owned the configurations and APIs and Operators who were responsible to apply these and maintain uptime. AWS solved this problem by creating a culture that came to be known as “DevOps.” The literal meaning of the word DevOps is Developer Operations i.e., Developers owning the full lifecycle of the software application from coding and deployment to operations that includes maintaining uptime. This transformation was not easy nor did it come overnight.
Over the years AWS had built a whole set of infrastructure tooling whose purpose was to abstract operations from engineering in such a way that engineers could operate their application in production with guard rails and without in fact having to understand many of the lower nuances of IT operations. The deployment tools at AWS by 2013 were a generation ahead of what is available even today in mainstream IT. Certainly AWS had operators but their role was not to pick up deployments. Instead they assisted in ongoing operations and error situations, especially in a system that scaled millions of workloads across the globe. It certainly helped that the general IQ of AWS engineers was also high which further helped operate in the DevOps culture.
Venkat Thiruvendagam was an early engineer in Azure and remembers in 2009 when it used to take them a month to push out a single line change across the data centers with slow painful rollouts involving tens of people and seeing his roommate push his change to production while making dinner which would be done by the time food was ready!
But did the DevOps Culture make its way to mainstream IT? Or did DevOps morph from Developers doing operations to Operators becoming automation developers to build operations tools. DevOps today is basically a new job profile, IT version 2. Developers are still far from infrastructure and operations. DevOps is mainstream but most don’t even know that the concept originally meant the exact opposite of what it is today!
The post Part 1: How Service Oriented Architecture Gave Birth to DevOps appeared first on DuploCloud.
Top comments (0)