devopsy.kinsta.cloud

Author: Maya Ber Lerner

  • How to Calculate ROI on Infrastructure Automation 

    How to Calculate ROI on Infrastructure Automation 

    Infrastructure and cloud automation. You know you want it. Infrastructure as code and programmable infrastructure are hot topics these days. The possibilities opened by applying software development practices to infrastructure make the vision of transparent infrastructure closer than ever.

    But before you start automating, you may want to look at the value you get from your investment and make sure your plan makes sense. After working in automation for over a decade, I’ve seen the importance of having a clear understanding of the value of automation time and again. It’s about time I write about calculating the return on investment (ROI) on infrastructure automation. But before getting to the specifics of infrastructure and cloud automation, it may be wise to start with the value of automation in general.

    The Value of Automation

    The equation is simple. You have a long, manual process. You figure out a way to automate it. Ta-da! What once took two hours now takes two minutes. And you save sweet 118 minutes. If you run this lovely piece of automation very frequently, the value is multiplied. Saving 118 minutes 10 times a day is very significant. Like magic.

    The Value Formula

    The formula for the value from automation can be very simple:

    Time or Money Saved by Automating a Manual Task

    Time or money saved by automating a manual task should include any benefit you can attribute to the automation. Here are some examples:

    1. The time saved by automation to accomplish a complex task (this process took eight hours. Automation does it in eight minutes. Now we can do it more often).
    2. The time saved for the person who used to do it manually (the person who used to do it manually now has eight free hours, while automation does the work).
    3. The time saved for a person who was waiting for the task to be completed (the person who used to wait eight hours for the task to be done, now waits eight minutes; they can do more).
    4. The time saved by not making human errors (the person who used to spend 10 hours troubleshooting after the eight-hour person finished saves 10 hours).
    5. The time saved by not having to document a manual process (the two people who spend five hours a month teaching other people how to do the eight-hour thing …).

    Investment in Automation

    Investment in automation is often naively calculated as the investment in building automation, but the real investment in automation also includes maintaining and supporting what you have built. So, if someone tells you it took five minutes to whip up this little Bash script, ask yourself what it would look like to update it and support it forever (and when there are 300 more of these scripts). Your calculation of the investment in automation must include building, maintaining and supporting your automation.

    What Should I Automate?

    The formula makes it easy to decide what your automation targets should be—or, in other words, where you would find the most value in automation.

    A good start would be to look for tasks that take a long time to do manually or tasks that are done very often, as automating them will save more time and money. But you need to make sure the investment in automating them would justify the gain.

    I wish I had a dollar for every time I talked to someone who wanted to automate the “most difficult task” to prove the value of automation. This follows the logic, “If you can do the hardest thing, you can also do the simplest thing.”—a bit like making it in New York City. But this is not how automation works. Why? Because automation is very much like software development.

    In the software development world, one of the most common answers product teams gets from developers when they ask, “Is it possible to implement feature X?” is: “Everything is possible. It’s just a matter of effort.”

    Well, automation works the same (and that’s not the only similarity to software product development).

    Pretty much everything can be automated. The question is whether it’s worth it.

    If you automate something that takes a whole day to do manually, but you only need to do it once a year ,  it may not be worth automating.

    You could be automating the stupidest thing, and only save 20 minutes, but this thing happens 2,000 times every day, so that may very well be worth it. And the more stupid it is to automate, the better.

    Real Life Infrastructure Automation

    Back to the value formula. In real life, there are more facets to this formula. One of the factors that affect the value you get from automation is how many people have access to it.

    You can automate something that can potentially run 2,000 times a day, every day; this could be a game-changer in terms of value. But if this is something that 2,000 different people need to do, there is also the question of how accessible your automation is.

    Getting your automation to run smoothly by other people is not always a piece of cake (“What’s your problem?! It’s in git! Yes, you just get it from there. I’ll send you the link. You don’t have a user? Get a user! You can’t run it? Of course, you can’t, you need a runtime. Just get the runtime. It’s all in the readme! Oh, wait, the version is not in the readme. Get 3.0, it only works with 3.0. Oh, and you edited the config file, right?”).

    Your calculation of the time or money saved by automating a manual task needs to consider the value derived from automation accessibility:

    The more people involved, and the more distributed they are, the more difficult it is to achieve accessibility. Your calculation of the investment in automation should therefore also include the investment in self-service:

    Adding Self-Service

    The self-service part of the equation is often neglected when looking at the value of automation, especially when the focus is very technical. It’s very easy to show a promise of value if you can automate a task, and by the time the question of self-service surfaces, it may be too late.

    This is very common with grassroots automation. In my field, I see this time after time, with teams that adopt free infrastructure automation tools (Ansible, Terraform, Cloudformation, ARM, you name it). In 2020, most people understand that there are no free lunches and that it takes precious time to develop and maintain this automation. Most already get that supporting it over time results in an automation team that is often too swamped to do much else.

    But I dare say that few properly estimate how difficult it is to provide this automation as a service to other teams. I don’t blame them. For an engineer, the thought “This is too slow! I will automate it” comes very naturally. It’s much more difficult to imagine as a developer a user who doesn’t understand the beautiful capabilities of Terraform; someone who freezes when they hear, “It’s in GitHub”; someone who isn’t as fascinated by the elegance of the code and has no #$$%$@ idea what to do with code.

    In a company with multiple teams, the gap between the people who can automate to the people who need the automation can be huge. And if you ignore it, your automation value formula can be very skewed.

    Can Everyone Run This Automation?

    When you consider automation, the technical question, “Can it be automated?” is not enough. How efficient the code will be, or how much time it would take to build the automation, is also not enough.

    The question, “Can all relevant users run it as a seamless part of their workflow?” has to be asked and weighed in. You may be surprised, but highly accessible yet technically mediocre automation can actually win in some cases.

    How the Value Equation Works in RPA

    Robotic process automation (RPA) is a great example. RPA systems typically provide users with lists of automated actions by recording tasks that the user performs on a graphical user interface.

    For many coders and automation professionals, this approach is almost sacrilegious. You can automate fast, but scaling the technology is extremely limited. It gives a wide audience access to automating tasks without enforcing coding best practices (we already know the masses can’t be automation experts). But RPA can offer high ROI in some cases. If we return to the value formula, this quick-and-dirty type of automation is highly accessible, and therefore the investment in self-service is low. If using RPA means x100 or x1000 people can benefit from automation, compared to high-code tools that only a few can use, we may be able to get impressive ROI.

    Does this mean we should use RPA for DevOps automation? Not really. RPA is not always the right tool for the job, and it won’t always provide the best value in automation. RPA works well when you want to eliminate toil in small tasks (e.g. it is very popular for accounting tasks that a person triggers manually), but the value is lower when you have strict scale, efficiency and reliability requirements, which is typical in DevOps.

    In the case of DevOps, with machine-to-machine heavy interfaces, the investment you will have to make in scaling and maintaining RPA can be very high and the ROI would eventually be very low. RPA may therefore not provide the greatest value in this field, and it makes sense to opt for more scalable options. But this doesn’t mean you should focus solely on good engineering and the question of accessibility and self-service must be addressed in your ROI calculation.

    Infrastructure Automation in DevOps

    In the past years, there has been a growing awareness of self-service in traditional infrastructure automation. Often led by IT and Ops, some of it started with simple means, such as connecting ticketing systems (JIRA, Service Now) to automation tools.

    However, in DevOps infrastructure automation, accessibility of automation is often an afterthought. DevOps automation initiatives usually start with developers. The natural tendency is to invest in high-code automation and to focus on value derived by the time saved on the execution of a task rather than the multiplication of the value through the enablement of a broader user base. Existing self-service mechanisms are thrown aside,  and for good reasons: they are too slow and they don’t seamlessly fit into the DevOps process.

    Ignoring self-service is one of the reasons why DevOps initiatives show great value-promise in small-scale and fail in larger scales.

    Moreover, since DevOps spans so many areas of subject matter expertise, the chances of leaving critical expertise outside the coders’ silo is very high—especially expertise in operations, security and finance. Ignoring these experts’ accessibility to automation leaves them outside the DevOps loop.

    I was very happy to see Gartner’s “Market Guide for Infrastructure Automation Tools,” published in April. If you don’t have access to the gated content, I recommend taking a look at Manju Bhat’s post on the topic. Gartner finally highlights self-service as a critical capability for infrastructure automation:

    “Infrastructure automation tools provide DevOps teams with on-demand, self-service access to standardized environments. Adopting these tools enhances their ability to deliver customer-focused agility and velocity improvements while consuming new technology platforms with limited disruption.”

    I see this acknowledgment in the importance of customer-facing accessibility as a crucial milestone on the way to realizing value in larger-scale DevOps initiatives.

    Additional Value Factors in Infrastructure Automation

    Unlike general automation, infrastructure automation is a field in which there are additional factors in the value formula, which fall under the Infrastructure Governance category:

    1. Cloud security.
    2. Cloud cost.
    3. Compliance with industry standards.

    These elements need to be taken into consideration when addressing the value derived from automation. Infrastructure automation, especially in public cloud, involves sensitive assets: compute, network, storage, data and security elements. These elements can be expensive, and they could be very vulnerable to attacks.

    If ignored,  these three factors can diminish value. But handling them properly in automation can also generate value.

    The “time/money saved by automating a manual task” could, therefore, include an additional value segment:

    And the investment calculation should also include embedded governance:

    Build Your Value Formula

    If you are working on an automation initiative, don’t forget your value formula. It will help you build a business case, get management buy-in and achieve a better understanding of value factors you should focus on.

    The TLDR version:

  • Predictions 2020: 7 DevOps Predictions Shaping 2020

    Predictions 2020: 7 DevOps Predictions Shaping 2020

    2019 was an exciting year for DevOps practitioners, with DevOps adoption continuing to grow at a fast pace. Most organizations were either executing or evaluating their DevOps strategies. So, what is 2020 going to bring in DevOps, infrastructure and application automation? Here are seven DevOps predictions for emerging trends in the new year.

    Customer Experience

    CX will become the guiding light of the DevOps journey, and not necessarily just technology. This is a big mindset shift from the early days of pure-technologist enthusiasm. As DevOps matures, we have to remind ourselves that it’s all about making business faster, not just the cool tech.

    Take advantage now:

    • Tie DevOps achievements to business needs and results to get executive buy-in and budgets.
    • Successful QA teams will start looking at their role as guardians of customer experience and not just testers.

    Trust

    Everyone will be talking about trust—not only in the context of zero trust networks but also in the context of making it possible for Dev and Ops to trust one another as the foundation for DevOps.

    Take advantage now:

    • Proactively invest in creating a culture of trust. Identify causes for lack of trust in your value stream and make trust a 2020 goal.
    • Encourage product-level conversation and define methodology and ownership when it comes to value stream management, application and infrastructure automation. It is the foundation that everyone is working on.
    • Invest in staging environments—Staging environments are needed to ensure things work before you put them in production. For many of us, jumping directly to automatically deploying to production is a big step. The risk can be mitigated by investing in staging environment automation, which will be the first step toward deployment to production.

    Value Stream

    The DevOps toolchain is going away. In 2020 we will think value stream. The industry is maturing beyond the notion of chaining together dozens of open source tools and trying to make it work together. In previous years many felt comfortable saying that if they have a CI system in place it means they “do DevOps.” This is no longer the case. DevOps is not just CI, and DevOps cannot be established in silos. Mature DevOps needs to take into consideration the entire value stream—from planning a new capability and the business requirement, all the way to the customer getting more value and a wonderful experience.

    In 2019, Gartner announced it’s the last year of the ARO MQ, as it’s not the right perspective. In 2020 we finally gain a system-level view on the value stream. More players are announcing end-to-end value stream management including Atlassian’s new Forge platform, GitLab and CloudBees. Companies are maturing and adopting system-level solutions. 

    Take advantage now: 

    • Plan for platform operations. System-level value stream perspective requires roles that take ownership of orchestration and automation throughout the value stream and not just in silos.

    The SRE Role Will Continue to Mature

    The SRE role that started with Google bringing software development practices into Operations will continue to evolve. Increasing volume, velocity and variety of data will make AIOps solutions thrive. Also, increasing levels of automation will require smart ways to handle dynamic infrastructure and applications without losing control, and being able to track changes all the way back to the coder. 

    Take advantage now:

    • If you haven’t implemented the SRE role yet, consider how SREs can be part of your teams in 2020. Define SRE areas of responsibility and KPIs, and how the SREs communicate with the teams. Is it a centralized position or are the SREs part of the team?
    • Make sure you provide SREs with the tools they need to succeed including:
      • What are the observability solutions you use? Who uses them today? How do you analyze it and how is it communicated?
      • What are the production environment orchestration, deployment and configuration tools that you use today?  How do you connect them to application and infrastructure automation that happens before production?

    Seamless Infrastructure

    We will have to make infrastructure seamless for our teams. Internal customers are also customers, and their experiences will be just as important. Self-service and empowering teams will be the main themes in the bridges that need to be built between Dev and ITOps. Public cloud, Kubernetes and serverless technologies will grow. And while it makes automation more feasible than ever, the emphasis will shift to self-service and to the end users. With more companies adopting similar approaches, the need to develop internal expertise will decrease, and we will see more off-the-shelf solutions.

    Take advantage now:

    • Map how infrastructure is used throughout your value stream, and work on unifying the approach in product-level.
    • Make sure you build self-service solutions with strong focus on the end-user in order to enable and balance both speed and control. Make sure developers and ITOps are equally represented when determining an approach to infrastructure automation.

    Infrastructure Automation

    Infrastructure automation is going to get smarter, with a lot of AI and ML. Making sure automation is properly governed will also increasingly be important. Take into consideration security and compliance, as well as cost.

    Take advantage now:

    • Assess infrastructure automation practices throughout your value stream. Who builds the automation? What teams and systems consume it? How do you enforce security best practices (e.g. no passwords in public repositories, using proper data sets for testing, compliance of automation blueprints)? How do you enforce cost control (e.g. tagging, reviewing cloud spend reports)?
    • Invest in control mechanisms before you lose control, especially in public cloud automation. If you don’t have governance in place, look at baking governance into automation, rather than adopting traditional cloud management approaches. Invest in automatic de-commissioning of infrastructure, automatic tagging, analysis of infrastructure consumption data and connecting it back to the business requirement, secrets and key management and access control.

    SaaS

    Open source is nice. SaaS is great. While big open source projects set the pace (K8S, Github) and are strongly backed up and funded by the industry’s giants, smaller projects are increasingly difficult to scale and glue together, especially when trying to assure enterprise readiness. The need to “do it yourself” is gradually fading, as more vendors offer products and services for supporting DevOps with clear business and support models and, as important, with OOB integrations with the ecosystem. Just Rest API is no longer enough.

    Take advantage now:

    • If your enterprise-readiness requirements make it difficult for you to scale DevOps initiatives, consider evaluating new SaaS offerings that eliminate much of the heavy-lifting and gluing that were typical to the skills-heavy early-days implementations. If you were concerned with security, cost and skill requirement, today you can find tools that are purpose-built to support DevOps for enterprise at scale. The good news is that most of the vendors are well-aware of the criticality of integrating to your ecosystem, making it easier to achieve your end-to-end value stream vision.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Maya Ber Lerner

  • Speaking the Language of Applications

    Speaking the Language of Applications

    I arrived early to a meeting, and the pleasant security guard at AT&T suggested I take a look at their innovation museum while I wait. Among motion picture sound technology and life-size photos of switchboard operators on roller-skates stood a transistor prototype. The transistor was invented in Bell labs in 1947, and it changed the world. Steve Wozniak considered it the greatest innovation of all time in his 2014 article.

    But almost nobody needs to think about transistors anymore. The transistor had to become transparent and abstracted, so the next generations can build great things in higher level. The transistor made a huge influence on our lives as an enabler, but if people had to keep talking about transistors it wouldn’t be possible.

    Abstracting technologies is key to advancing to a higher level, making it possible to solve real business problems.

    The language of a client-focused business is applications. If we want to make a business execute faster these days, we need to make the development and release of its applications execute faster. But one thing stands in our way: the infrastructure. Applications reside on infrastructure–they are installed on servers, bundled in containers, on cloud instances, in networks, using storage.

    If we want to speak the language of applications, we need to abstract them from the infrastructure, and make the infrastructure transparent.

    The concept of abstracting applications is what stands at the basis of every new approach to application development and release around us.

    • Containers are all about abstracting services from specific infrastructure and making them mobile.
    • Serverless takes it to the extreme.
    • Public cloud makes it easier not to worry about owning physical infrastructure.

    Technology screams, “Think applications, soon you will not have to worry about infrastructure!”

    And yet, most of us mix applications and infrastructure in an unhealthy way when we try to automate them. It is unhealthy because mixing applications and infrastructure prevents reuse of automation assets and makes it very difficult to connect infrastructure usage to a business context.

    Understanding how mixing applications and infrastructure is manifested requires looking back into the evolution of infrastructure and application automation.

    The Evolution of Infrastructure: Manual Deployment and the Inception of Its Automation

    In the beginning there was manual. We got a server; it was sitting on a shelf. We got the application artifacts, maybe on a CD or a USB stick. We installed the application on the server. Our application was ready for use. When we needed to upgrade, we went back to the shelf and installed the update on our server. It was very hard to make this operation faster.

    This is where automation of applications and infrastructure started.

     

    Behind any automation tool or standard stands a model. This model reflects how its creators originally perceived the problem they were trying to solve. It consists of the entities they defined as first-class citizens, the operations they wanted to apply on these entities, their attributes.

    “All models are wrong, some are useful,” said George E. P. Box in 1976. This is true for automation models too. Automation models are usually nice and clean when we start off. But as the problems we try to solve transform, our models need to grow and adapt. Until at some point they are not useful anymore and we need to replace them with next generation modelling approaches.

    The Configuration Management Model

    Configuration management tools such as Puppet and Chef were originally built to manage application deployment and configuration on static infrastructure. This new approach to Ops optimized manually updating applications on servers. Better network connectivity made it possible for this model to thrive, with the ability to configure applications on servers remotely.

    But within a decade we witnessed the fast rise of immutable infrastructure. Immutable infrastructure is an approach to deploying applications where the infrastructure components are replaced instead of updated. This approach somewhat pulled the rug from under the configuration management model. With each update or change, the application must be re-deployed. This forced adding dynamic infrastructure provisioning to the configuration management model. Combining infrastructure automation and immutable infrastructure concepts into the configuration management model is a difficult task, since this model was never designed to accommodate something like that.

    The Infrastructure-as-Code Model

    Pure Infrastructure-as-Code tools were built to provision infrastructure dynamically. Terraform is an example for an open source tool that does this well. This model is created with infrastructure in mind.

    Whether we look into Terraform, AWS, CloudFormation or ARM templates, we will see the infrastructure is the starting point (defining network connectivity, VM instances and services) and the applications are an implicit addition. They are artifacts that happen to be deployed on and are tightly coupled to the infrastructure. We may look at a component that says “App A” but it actually stands for “specific infrastructure with app A installed on it.”

    This seems natural, because it’s the same way it worked in the good old physical-infrastructure world: We fetch a box, we install something on it. We focus on the infrastructure, because this is our starting point. The application is the artifacts we put on the infrastructure and scripts we run after we provision it. Presumably, the application cannot live without something to be on.

    Infrastructure-as-Code tools evolved the way open tools do–their base model was extended by the community because there was a need to automate applications deployment and not just infrastructure. But it is becoming difficult to extend this model to reflect a world where applications are built to move between clustered servers, and the starting point is no longer the infrastructure, but rather the application’s requirements.

    Mixing Infrastructure and Applications

    Trying to fit infrastructure provisioning and application deployment in a single model that was originally designed for just one of them creates issues. Infrastructure is lower level than applications. Applications reside on the infrastructure. The same app can reside on different infrastructure configurations. This critical relationship is completely flattened if you mix them.

    Moreover, from a business perspective it is important to make applications explicit. It’s our product. Our website. Our mobile app. The applications need to be the center of the attention and discussion. This kind of modelling puts applications in the shade of infrastructure.

    Four Great Reasons to Model Applications as a First-Class Citizen Right Now

    The models we use today are broken, and it is time to evolve. No matter if your applications reside in containers, or on cloud instances, or include native cloud services or a mix of them. Applications should be a first-class citizen, and not some artifact installed as an afterthought on the infrastructure we started from.

    The notion that applications should be abstracted from infrastructure doesn’t eliminate all the challenges of infrastructure provisioning and application deployment, but it creates a foundation for better and more scalable automation.

    1. Achieve Application Re-Use

    Modelling applications as a first-class citizen is the only way to make applications a re-usable element throughout the development and release pipeline.

    If there’s one thing I learned in my automation journey, it is that if automation doesn’t get frequently and consistently reused, you don’t get value for your money.

     2. The Path to Multi-Cloud

    Abstracting application is also the best approach for moving application workloads between cloud providers. If everything starts from infrastructure, we need to start from scratch when we move. If our applications are abstracted and defined separately—this definition stays the same when we move, only the infrastructure changes.

    3. The Path to Breaking Silos

    The vision of Dev, Sec, and Ops all dealing with the same language (code) is wonderful. But bringing everyone to the same code pool is not always easy. Applications and infrastructure are not the same thing, even though we can code both. Mixing them makes them unnecessarily hard to build and troubleshoot. It forces us to deal with fuzzy boundaries when it comes to responsibility for this code. Basing automation on a model that organizes the world in a way the different stakeholders can understand it, can help overcome this barrier.

    4. Connect Infrastructure to Business Needs

    Infrastructure-as-Code is a huge breakthrough, but the bigger story is about making application development and release faster. This doesn’t undermine the importance of infrastructure; infrastructure is the foundation of everything. But if we want to solve business problems, we need to talk the language of the business, and that’s the language of applications. Our automation should be built in a way that reflects this.

    — Maya Ber Lerner

  • Why Your Test Automation Is Failing

    Why Your Test Automation Is Failing

    If you have been investing in test automation, but it’s not getting you where you think it should, it could be that you approached it superficially.

    One of the most common issues is that the test part of test automation is rather straightforward to automate, especially with today’s abundance of great automation tools. But jumping straight into automated testing leaves you with a big heap of automation scripts, and often not the best ROI. Understanding why requires looking into the automation process.

    When an engineer builds an automated test, they do it in a test environment that they (or someone in the organization) set up. Usually, this is the same way manual testers get access to test environments.

    Before the engineers start automating, they have a working copy of the product they are testing, with relevant data on it. They have a good idea of the test they want to write. Everything looks promising.

    They write the test and give it a few runs. Everything is looking nice and stable. Now, to provide the ROI we were hoping for, the test must run a million times. Or, at least, a few thousand times, right?

    To reap the benefits of automation, it needs to happen frequently enough. However, the bottleneck is often discovered after creating a bunch of tests. Because the tests must run on a similar test environment to the one used to create them, with the new versions of the product or with any introduced changes that are being tested, you need access to hundreds of environments. This requirement makes it difficult to test effectively.

    Below are three test environment approaches that inhibit test automation.

    Manually Setting Up an Environment Each Time to Run Automated Tests

    For tests that don’t need to run as frequently, such as security testing and performance testing, it’s common to set up an environment for automated tests every time the test needs to be executed. As a result, testers must wait for the environment to be ready, perhaps do some additional configurations and then run a suite of tests. And, if they’re trying to optimize utilization, the environment is left to run overnight or weekend.

    The problem with this approach is it takes the “auto” out of automated testing. When automation depends on a manual step, the test is only as efficient as this manual step.

    If the manual step isn’t very efficient, automation may not be helping at all. I’ve seen companies take so long to get an environment to work that running automated tests on it didn’t make any difference from a time perspective.

    Setting Up a Static Environment That Automation Always Runs On

    When setting up an environment takes a long time, it’s natural to assume it’s worth leaving an environment running so test automation can run on it. The preparations were made, the infrastructure is all in place, the product is configured and the data is ready, so let the automation party begin.

    While complex, static test environments may seem ideal, but the party doesn’t last long. First, since it usually takes some time to put the environment together (same as the previous case), it often becomes high-maintenance. It can be scary to make changes that could ruin things, and you can end up needing someone to manage change full-time. Much like chocolate cake in the office kitchen, an environment that mimics production with good data on it tends to attract everyone. Soon, these nice environments become shared assets and tests start conflicting for the same resources. The natural next step is to set up another static environment. This loop usually ends with an angry manager saying something about cutting CAPEX.

    Automating the Environment and Cutting Ourselves Some Slack

    With the rise of infrastructure as code (IaC) and immutable infrastructure, there are more ways to spin up a test environment. Resourceful test teams will try to automate the environment creation or use built-in test tool or CI system capabilities to run tests on a public cloud instance or a container, if the product they test allows that. This is cheap and useful—and could work for some simple tests. The challenge usually starts with everything this approach doesn’t cover. It can be difficult to use IaC to spin up a test environment and handle all aspects of it—from security and isolation to dependencies, data, third-party integration and more. This is where this approach is often blocked and sends us back to the previous two approaches for a big part of the testing load—which again makes test automation investment less fruitful.

    The Right Way to Set Up Test Environments: Test Automation on Dynamic Environments

    The test automation world needs a game changer. You can make your car faster, but if the road is full of potholes, you won’t be able to get that fast or far. Test automation is similarly limited by the pace of environment creation, with its infrastructure, application, data and all.

    This challenge becomes critical when adopting DevOps and testing stops being a stage in the pipeline, instead becoming an overall pipeline service. QA is no longer about being the gate between development to operations. It’s about overseeing the quality of the product during its entire life cycle. This means automated tests should always be able to run, and the environment they run on must be dynamic.

    The solution to this challenge is environments as a service (EaaS). EaaS is all about packaging the environment, including the application, infrastructure and data, as an entity that can be provided as a service to a business process. Once defined, it can be provided on-demand for manual or automated users. Since it’s a well-defined entity, it also can be decommissioned when the process finishes using it. Playing an important role in making infrastructure horizontal, EaaS is also the key for paving the road for brilliant test automation.

    If you think you should get more from your test automation initiative, it may be a good time to make EaaS part of your automation strategy.

    — Maya Ber Lerner