Estimated read time: 30 min Technical level: Beginner+ What you’ll learn: What Automation As A Service is and why it’s useful. Ideal profile(s): Automation Specialist, CTO, Load or Functional Tester, Ops Engineer, Developer Author: Dorian Cransac (exense GmbH)
A recent study by McKinsey & Company suggests that as many as 800 million jobs could be lost to automation in the near future. This process isn’t likely to slow down as companies worldwide keep investing in automation tools and historic entry barriers such as infrastructure are disappearing due to technological advances such as cloud computing.
This phenomenon is resulting in mounting pressure for recruiters. Developers and automation specialists were already heavily sought after but with a continuous increase in complexity, it is becoming ever more difficult to find technicians capable of building and maintaining automation stacks. In order to reduce their burden, part of the solution is to make sure that developers focus on the most technical aspects of automation while passing on technically less demanding tasks to users who are not as proficient in code and automation. A pre-requisite for this is to expose core technical services to these users in a way that they can understand.
Having been involved in many different automation projects serving fundamentally different purposes, we’d like to take the time to report on how our clients have been able to achieve this.
Automation isn’t just about code
What is the difference between software and automation? Quoting from Wikipedia, automation is “the technology by which a process or procedure is performed with minimal human assistance”. Whether it is the result of a purely mechanical process, of the execution of a code routine or a combination of both, the idea is to have a machine perform a certain task so a human doesn’t have to.
As pointed out in the intro, automation is everywhere and takes on a bigger role every day, but it often seems that the feedback loop and the level of interactivity between humans and automation technology is poor. It takes a whole set of engineer and complex processes and months if not years to design and refine new automation routines.
As part of the design of our next-generation automation platform, we wanted to close this gap and make it as easy as possible for business users to create and use new automation routines. We wanted to place the end user back at the heart of our automation strategy. We’ve achieved this by creating a clear interface between code and business logic and by exposing core services in a way that’s understandable and easily accessible to non-technical users.
This allows users to defined automation routines and execute them based on atomic actions which are familiar to them. Feel free to check out our innovative keyword-driven approach and become familiar with step’s Plans and Keywords objects if you’re interested in how this interface works.
Reducing redundant work in IT
As an IT professional, if you’ve served or been involved with an administration, a bank or an insurance, you’ve probably witnessed how difficult it can be to bring people to work together. The segmentation of IT departments and the overlap in responsibilities across departements often leads to redundancy or at least sub-optimal efficiency.
When it comes to collaborating on automation projects, we believe this is an important problem which can be helped if not solved by using a common automation platform. Automation usually involves tools, services, files, servers and other shareable assets which are all somehow connected together. Multiple teams or departments might need to share any of these assets by sending screenshots via email, sharing them on a common drive or such. The following diagram illustrates what an unorganized (or maybe, empirically organized) automation project may look like, with satellite teams working on it for different reasons.
This satellite teams implement and use automation in potentially different contexts (testing, monitoring, etc), yet using more or less the same type of ingredients regardless of this context.
Each of them will use their own set of tools, follow slightly different conventions, and will struggle to share their work with others among the organization. For instance, a functional testing team will automate every step of an application’s use case and won’t pass the resulting scripts to the load testing team, although they could be used as a major building block of their test scenario. We’ve payed a lot of attention to this issue over the last decade and decided to work on tapping into the tremendous potential that we saw in solving it.
Over the years, we’ve evolved a broader concept of automation platform, which encompasses the needs of the different purposes served by automation in the context of IT and provides enough structure and guidance to maximize efficiency in every phase of its implementation. We are now covering a very wide range of practices, from service monitoring to all variations of testing, as well as pure robotic process automation in production.
These efforts have lead to a software platform called step, which comes with strong opinions regarding the structure of an automation’s code base, everything people need to execute automation scenarios at scale, and yet, provides the flexibility needed to avoid vendor lock-in.
Exposing code and data as a service
One of the key differienciating aspects which we believe an automation platform should feature is the ability to consolidate the way the different assets involved in automation are accessed and managed.
When deploying automation code onto the platform, users can use them to compose their own scenarios and execute them concurrently and at scale.
Users can also freely collaborate and share automation artefacts or results with one another.
Automation at scale
Let’s take a look at how large the overlap can be across a large IT organisation. From monitoring in production, to support teams using automation reports as a reference for comparitive incident analysis, all the way to end-to-end testing teams or developers involved with continuous integration, use cases and affinities come in large numbers. The following figure shows, based on our experience as engineers and consultants just how wide the spectrum really can be.
A quick technical note: from an operational perspective, most clients prefer to split automation platform into at least two instances: one for services related to production use and one for internal purposes. This often results in isolated deployments and distinct operational procedures.
Scaling the platform
As the number of users and use cases increase, the need for capacity and infrastructure resources increases as well. It is therefore critical that the automation platform be designed from the ground up for horizontal scalability.
In step’s case, the workload is split in the form of keywords whose executions are then distributed across an agent grid at runtime, providing near-unlimited capacity (assuming that platform admins add enough physical resources to support new agents).
Many of our clients have chosen to use step directly in our cloud, thus avoiding operational headaches such as installation, upgrades and housekeeping. In order to quickly understand how much a SaaS cluster costs, feel free to check out our (online price calculator)[https://step.exense.ch/pricing/#pills-cloud] which will give you precise numbers based on the most common use cases of the platform.
We hope this high-level rundown of step’s core principles will help you see the potential that we saw ourselves through a number of years working with large IT corporations. We feel this is an exciting challenge are very pleased with the results achieved after now almost 5 years of implementing these concepts for multiple fortune-size companies in Switzerland, France and Germany.
If the topics discussed in this article resonate with you, feel free to contact us through our official form here, or have an automation specialist download and try out the community edition of step by following our Getting Started guide.