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)

Introduction

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 (Cloud Computing, Big Data Frameworks, etc).

This phenomenon is resulting in mounting pressure not only for IT technicians but also for recruiters. Skilled developers and automation specialists were already heavily sought after but a continuous increase in complexity is making it 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 less demanding tasks are deferred to users who are not as proficient in code but understand automation and business goals.

In this white paper, we’ll see how the concepts of Automation as a Service and our platform implementation (step) can help clients achieve this goal.

Automation isn’t just about code

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.

Unfortunatly, it often seems that the feedback loop between human users and automation technology is long and fairly inefficient. Through traditional software development, it usually takes many engineers and complex release processes to deliver 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 on the fly. 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.

Coupled with a user-friendly web editor, this approach allows users to define automation routines and execute them based on atomic automated 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

Scaling use-cases

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.

Conclusion

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.