For Moving Fast and Not Breaking Things – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn For Moving Fast and Not Breaking Things – InApps Technology in today’s post !
Read more about For Moving Fast and Not Breaking Things – InApps Technology at Wikipedia
You can find content about For Moving Fast and Not Breaking Things – InApps Technology from the Wikipedia website
After selling his company to Cisco for $3.7 billion a year ago, AppDynamics founder Jyoti Bansal wasted little time addressing other problems customers said they faced.
He unveiled a new startup called Harness.io in October aimed at taking on the challenges of continuous delivery.
“Facebook and others say, ‘Move fast and break things.’ But if you go into a bank and say the only way they can do DevOps and move faster is to break things, it doesn’t fly there. We want to move fast and not break things,” said Bansal, explaining the name alludes to the safety net the technology provides.
Most organizations have continuous integration in place, he said, but continuous delivery is a less mature space.
One bank he talked to had 700 DevOps engineers writing automation scripts in addition to 6,000 or 7,000 developers. With salaries for DevOps engineers around $200,000, it was spending 140 million a year on automation scripts, yet still could not keep up with continuous delivery.
“They were afraid Google, Facebook and Silicon Valley would be eating their space because they could not move fast enough,” he said.
Many large companies come back from DevOps conferences fired up to implement the practices in-house but become frustrated by the complexity of it all.
“The problem is many try to use CI to do CD and it’s not the same thing,” he said. In a guest post for InApps Technology, Wercker CEO Micha “mies” Hernandez van Leuffen agrees.
Explained Bansal: “There are so many different parts: How do you provision your infrastructure? How do you automate deployments? How do you plan deployments, canary vs. blue/green? How do you verify what’s happening with availability, performance, logs? And if something goes wrong, how do you rollback? How do you manage pipelines? Passwords for all the different systems and how do you track all of this?” he said.
Forrester analyst Robert Stroud calls Continuous Delivery and Release Automation (CDRA) tools the missing link in business transformation.
“Forward-thinking [infrastructure and operations] pros are using CDRA tools to move beyond cumbersome, complex and often error-prone scripts. These professionals use the tools to model the complete application ecosystem including infrastructure, middleware, application and all dependencies. Using this model, they then orchestrate the release in a structured release process — either canary, blue-green, A/B testing or dark deployments.”
Bansal teamed with Rishi Singh, who was running continuous delivery for Apple, for the San Francisco-based company. It has raised $40 million.
The technology consists of two parts: smart automation and continuous verification.
Now, you write script in Chef, Puppet, Ansible, you write scripts to call APIs in Amazon or Kubernetes. Instead of scripting, Harness uses a model to define what you want to achieve. With emphasis on ease of use, the user interface allows developers to model a pipeline by drawing lines between tasks that the system will automate. You also can do it code with simple YAML and check it in Git, then it automatically syncs from Git.
Bansal explained it this way:
If you want to say: My developers will check code in Git. Then someone will pull the code out, run a build in Jenkins. From the build, run unit tests, and if that passes, we want to provision a new staging environment, with infrastructure with certain characteristics to it. Then on this environment, we want to deploy this new code, run these tests on the new stuff, and if it passes, we want to start deploying to production.
“Say we want a canary deployment, 1 percent of the new code. We want to verify our monitoring and logging systems; if everything is good, we want to go to the next 5 percent. We’re allowing people to specify that in that kind of English, really,” he said.
That scenario could involve two months of scripting, he said, but modeling it in Harness could take about five minutes, and it would generate all the automation for it.
It provides an abstraction framework and library of all the pieces: How do you get things from Git; how to connect to Jenkins; how to provision resources in Amazon; how to provision resources in Kubernetes, how to run a selenium test against it, how to get data from AppDynamics or New Relic or Elk.
For the smart automation, customers deploy a 6GB Harness “delegate” in their environment. It connects with a Harness server running in the cloud or on-premise. The delegate connects to SSH or APIs in the customer’s artifact repositories, cloud environments, orchestration systems, monitoring systems and more to orchestrate everything.
The second part, continuous verification, involves an artificial intelligence layer to ensure nothing broke, either from a quality, security or performance perspective.
The system pulls in data from all your monitoring systems and logging systems to create complex neural nets and AI models of what’s normal for the application, not only about performance, but also from a user and business perspective. If, for example, the normal conversion rate in your shopping cart is 70 percent, but once you push new code, it’s 65 percent, it’s abnormal.
If there is a problem, you can roll it back automatically.
He names Spinnaker, the continuous delivery platform that Netflix developed internally to help development teams release software changes with confidence that nothing will break, as Harness’s closest competitor.
Customers such as Jobvite and Build.com report dramatic results.
Online Home Depot competitor Build.com had been using six or seven senior engineers for verification once deployments had gone live, on which they each spent three hours a week. Rollbacks took 32 minutes. Now the company uses one less-senior engineer on verification, which takes 10 minutes and rollback takes 90 seconds. It recently outlined one production rollback of just 32 seconds.
Job site Jobvite reports deployment time has been reduced by 10X to 27 minutes. Rollbacks take 2 minutes. Developers now build, deploy and fix their own code. It has reassigned two engineers from its three-person deployment team to more business-critical projects.
A General availability release is expected some time in the early part of this year.
Feature image via Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.