Inspiring quality through devops

Editor's Notes

• #2: Thanks Anushka for introducing me Ladies and Gentlemen Thank you so much for joining with us for the keynote speech for the quality quest It’s an honour to be here and deliver the key note speech for this special occasion
• #3: Do you remember the days where we used to carry heavy phone as a sign of prestigious lifestyle? Even Though you had to climb on top of rooftop to get a call, it was considered as an amazing technology. Call quality was very poor. But users were fascinated about the wireless technology. But over time the technology has shifted gears and transformed into an ever changing overwhelming life partner Or a business partner. Same as all the other technologies, IT has evolved into a necessity from a luxury 95% of the all capital projects have an integral IT component. 50% of capital spending are technology related. More and more Business is relying on IT. More and more people are relying on IT. Because of this, the demand for "IT as a service" is increasing. I’m using “IT as a service” term in much broader context… I’m not just referring the infrastructure. PaaS, IaaS, SaaS Delivering an end to end service is important as IT organizations. Especially the quality is very important as customers are not mesmerized by the technology itself as they did in the 90s.
• #4: Smelly code.. when a very important customer demanded that the bug be fixed mmediately, and you put in the most awful hack just to get it working as quickly as possible. The plan was to come back and sort it out later, but somehow that never happened. And then there’s that class that just kept on growing, little by little, and now it’s 5000 lines long and no one dares touch it for fear of breaking it.’ Feature Bloat As the years roll by, the features in your application just keep on rising. You add everything the customers asked for, everything your competitor’s product can do and every cool idea that the sales team thought up. While some of these desirable features play a role in your application’s success, you’ll end up with plenty of useless ones, too.’ Production instability is the biggest problem we have…. NFR backup,deployment.interoperability,performance,security,maintainability
• #5: Why we couldn't demolish some of the challenges with “Agile” itself? Which is something that needs to be carefully analyzed. “IT service delivery” or more accurately “IT as a service” is comprised of four phases. Namely design, development, Release and operation/maintenance. Agile was an only solution for development and part of design and maintenance phases. But we didn't have a solution for challenges in other phases. Although Related, But in a different context, Agile was a great solution for Dev and QA. But operations left out and they had their own problems and solution Pegani Roadster Mercedes Benz AMG engine 12 cyclinder 48 valve 7200cc engine. Agile is a great answer for most of the IT service delivery challenges. Agile methodologies like rapid delivery of working software, co-location, simplicity, self organizing teams, Test driven development are used in almost all of the successful modern organizations. Yet we couldn’t achieve the quality which we were expecting. Some of the underlying core challenges were still existing and pulling the hair out of CIOs, CEOs. Business was not totally happy. eventhough agile expects to deliver software frequently, Operation teams were not ready for that.
• #6: throwing brick ops reluctant change Operation people like App, Network, DBA engineers were not ready to continuously change the code in production environments or to introduce new features, Because they were feared of inevitable truth which they believed in. I.e. “All the releases will break the production” On the other hand, with agile dev teams were kept creating small replaceable meaningful chunks of code and throwing them over the “ Berlin Wall of Dev and Ops”. But it was not a synchronized effort. Dev ownership was scoped and limited to creating code only. They were not responsible for neither how code is running and serving customers in production environment nor the production stability after they threw the code over the wall. When there is a production incident, Dev was not keen on getting their hands dirty and jump in as it was someone else’s responsibility. They had lots of things in their backlog, which they tend to focus on. On the other hand Operations teams were never engaged in the design and development phases of the products. Operations feedback was not sent to the design phase to improve the code and ops never involved in non functional requirement development. Agile teams were kept missing non functional requirements like instrumentation, monitoring, fault tolerance mechanisms, vendor interoperability, security... Etc.. As a result of that, technical debt increased over time. What happens when technical debt is increasing? It creates the vicious cycle of production instability Infrastructure Readiness Meanwhile, infrastructure was not ready to support agile software development. Rigid infrastructure technologies and lack of human resources made this problem more and more challenging. For an example, let's consider a new server provisioning request for a feature. When the requirement was picked up from the backlog scrum team starts working on building the new feature. But since there isn’t an Ops representation in the scrum team nobody is concerned about the time taken to provision servers,set up monitoring,setup network and other non functional requirements for the feature. When a scrum team is nearing the finish line they tend to worry about and start thinking about those NFRs. But rigid technologies and manual procedures don’t allow ops teams to create servers on the fly or setup network easily. Then the conflict begins. This is just a small example from practical world. Dev was ready to take the “IT as a service Challenges” with agile. But Ops was moving in a different way.
• #7: Remove boundaries between Dev & Ops – Improve cross silo collaboration. •Dev – Work together on stability, monitoring, backup from the start •Ops – Involve in design phase and NRF development Automated Deployment Pipeline – same flow for changes to code, infra & data Automation is a key driving factor in DevOps adoption. Automation enables rapid, seamless deployment of software. Modern “IT as service” providers are having multiple releases per day through appropriate automation. Some organizations release 30 to 50 times a day to the production environment. Automation leads us to continuous integration, continuous delivery and then to continuous deployment. The final goal of all automation is the continuous operation. In an ideal DevOps world, feature team should be able to automatically push the code upto production environment without any manual intervention and downtimes. As mentioned earlier rigid infrastructure is the biggest bottleneck of the Continuous operation. As a solution to that, PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) concepts gained the popularity and infrastructure provisioning has reached to a new dimension due to that. With the appropriate automation and cloud computing technologies, infrastructure provisioning has become seamless. Especially with the use of the A/B deployment mechanism, modern operation teams are equipped for DevOps transformation. Sharing is very important in a true DevOps culture. Coding the software is merely a one activity in provisioning “IT as a service”. There is a lot more into it. Everyone understands the big picture is important in developing the DevOps culture. Also Everyone as a unit should be responsible for the entire flow of work while engaged in one or more actions to complete the flow. Developers getting alerts and reacting in the middle of the nights and operations involving in non functional development activities is a healthy example of sharing responsibilities. Most importantly What we need to understand is “DevOps is a culture which has its own set of values. If these values are not understood by everyone in the organization, DevOps can drive you to an endless maze.
• #11: dev involvement in prod stability