On the face of it, the term application service automation (or ASA for the sake of this blog) appears to be one of those wooly IT industry terms used to describe some element of the so-called ‘operations’ team’s daily workload.
In practical terms, ASA comes down to automating application deployment, maintenance and management, which will typically involve remediation and recovery processes. Or to put it even more simply, a serious helping hand for data centre employees.
Nolio announced that it was selected by City Index, a global leader in Contracts for Difference, FX and spread betting, to be the de facto standard for data center application deployment. “Nolio ASAP” allows City Index to deliver 25% more software releases each week.
This is an older article written on Patrick Debois’ blog Just Enough Developed Infrastructure, by guest writer Stephen Nelson-Smith @lordcope a Technical Manager and Devop based in Hampshire, UK and author of Agile Sysadmin.
Discussing the two major questions in the DevOps movement; What problems are we trying to solve? and How does DevOps help?, Stephen dives head first into the details and explains about fear, risk, and siloisation. As a well behaved author, Stephen provides points for criticism and explains how one can get involved with this new movement.
John Vincent is a System Architect from a consumer loyalty company in Atlanta, and he’s in love with DevOps. Every #devops tweet, every SlideShare presentation, conference, keynote, or book, if it’s got the DevOps stamp on it then John has most probably read it, been there, done that.
You can read his blog post to learn more how John’s company formed the new dedicated DevOps team, and how they managed the migration from a waterfall approach to agile. John goes on to explain how DevOps effects Sarbanes-Oxley (SOX), Security Controls, and Corporate Hierarchy.
What’s most amazing about it is that, I personally think implementing a DevOps philosophy across the board would make compliance EASIER. All change control is AUTOMATICALLY documented. Traditional access rules aren’t an issue because no human actually logs onto servers for instance.
To some people, developers are ingenious innovative software generators. To others, they’re code hacking. Either way, the world they know is changing, and their role must evolve to take on more responsibility and be more accountable for the code and applications they create.
One of the more pressing challenges facing software development and delivery teams occurs when software is released and running in production. Deployment, release management and maintenance issues (especially in resolving problems once applications are working out in the field) are the bane of both the software production teams (the developers) and the operation teams alike. The problems are getting harder, not easier, with each technological and platform advance.
Knowing this hardship, you’d be hard pressed not to think that relationships between the developer and operations teams, called the DevOps bond, would be more in-tune to their respective requirements, shared challenges and goals, and be in general a lot more collaborative. Nothing can be further from the truth. The disconnect that exists between many development and operations teams is both legendary and ingrained.
The “throw it over the wall” attitude, a key culprit to the strained DevOps relationship, partly stems from the lack of deep and connected insight into deployed assets, process transactions and system configurations, as well as patches and management policies that exist in many production environments.
Over at the “The abyss between dev and ops” blog, Christian has a nice post describing some scenarios that essentially creates the infamous gap between Dev and Ops (check out this hilarious Monty Python take on DevOps) . In Christian’s opinion, lack of communication is a major cause. I would also expand this to the lack of communication tools, or as we like to call it at Nolio, the lack of a common interface for development, QA, and operations.
It’s great to sit with customers and get the spiel about what’s going on inside the organisation. Yesterday I heard the first-hand account and in my opinion also the most accurate narration of the relationship between the Development and Operations of a SaaS business. Referring to a scene in Monty Python and the Holy Grail, the Operations are like the English who are getting clobbered with cows and other livestock by the French, protecting their castle. The castle resembles the wall or gap between Dev and Ops, and I would image that the livestock are application releases, patches, bug fixes, configuration changes, and the such.
Faced with this ugly situation, our customer is in the midst of creating a new DevOps team, that will sit in the Operations and manage all application releases, deployments, and ongoing updates. In other words – application services. This new DevOps team will also undertake first level application support and debugging. Interesting approach, and definitely something that we’ll see more of as SaaS IT Operations adopt continuous integration and release automation, and start to build new DevOps teams in order to keep up with the ever increasing rate of application releases and updates.
Anyway, with some effort, here’s a one minute clip of what life looks like inside the organization.
Dan Woods, the Forbes blogger and analyst wrote a nice article about servicing applications in the data center and the cloud. Dan mentions that Nolio is attacking managing the complexity of the application head on. He writes that Nolio’s product makes it possible “to rapidly configure and adapt an application or set of applications to changing circumstances. Managing such application complexity is a big part of the undifferentiated heavy lifting.”
A combination of forces, including skyrocketing complexity and severe economic pressure, are radically and irreversibly altering the IT landscape. New methods, new functional sourcing, and new organizational structures are needed to address this onslaught, but one theme is obvious throughout all of these approaches — a need to automate more of what you do in IT. The typical IT organization wastes a significant portion of its budget on inefficiencies that only get worse as complexity grows. Automate many of these tasks and you become leaner and more responsive to business changes. Evidence indicates an automation “tipping point” is already under way this year. All IT shops need to consider their plans for automation, including the many derivative outcomes for process refinement, staffing, tools, and the organization itself.