If you saw my recent article on the Elastic Execution Grid (E2G), you know I’ve been exploring newer releases in the Tosca ecosystem. It’s been a great learning experience. recent article on the Elastic Execution Grid (E2G) But I was thinking that for some readers, you might be sitting comfortably with your DEX testing workflows. And you might be a little stuck in the “hey it works fine for me—no need to change” mindset. Or even sitting on the “sounds like way too much work” excuse. hey it works fine for me—no need to change If you are, I think you should reconsider. Because not only is it simple to switch to E2G, but by doing so you’ll see some substantial benefits that will be worth your time. In this article, I want to look again at the Elastic Execution Grid. But this time, I’ll walk through how simple the changeover is from DEX to E2G and why I think you should go for the upgrade. Elastic Execution Grid. Should I switch to E2G? First, let’s talk about why you should switch. My first reason for changing—flexibility. Instead of being locked into the expense and time of configuring and maintaining your own fleet of machines, with E2G you have much more flexibility. flexibility You can pick from three types of agents in E2G. (Note: if you don’t know much about E2G, or its agent types, you can read all the details in my previous article). Personal Agents: your own local agents for one-off runs
Team Agents: self-managed VMs (on-prem or cloud) that run under your control
Cloud Agents: fully managed, disposable instances offering zero-footprint execution Personal Agents: your own local agents for one-off runs Personal Agents Team Agents: self-managed VMs (on-prem or cloud) that run under your control Team Agents Cloud Agents: fully managed, disposable instances offering zero-footprint execution Cloud Agents It’s up to you which agent you use for each test, giving you lots of flexibility. My next reason to switch—simplicity. As you’ll see below, running tests with E2G is simple. For most cases, XML, scripting, and network configs are no longer needed. Now, just tell E2G what agent type, then check if your playlist can run in parallel or if it needs to be run sequentially. Add some characteristics to your tests, and you’re off. If for some reason you still need to control the hardware/VM (such as specialized hardware, custom middleware, etc.) you can always still choose to use the team agents. simplicity My third reason to switch—money! If you pick a cloud option, you no longer need to keep your testing machines. That means you can repurpose your hardware, shut off those pay-by-the-hour VMs, and stop patching and maintaining machines you only use when running tests. money And my final reason? Scaling. When you use the Cloud Agents, you also gain easy scaling. Need more resources? E2G auto-scales your agent pool to match. Need less resources? E2G tears down idle instances. You don’t have to worry about it. Scaling Now let’s look at the other side. Here are some reasons you may not want to switch. You have strict requirements for on-prem or air-gapped environments. You can’t run on the cloud if you can’t get to the internet!
You have highly predictable, always-on workloads. In some of these cases, a dedicated DEX VM might be more cost-effective and convenient. It’s worth evaluating to see.
As I’ll mention later, there is a cold-start latency with the first run on E2G. If you have ultra-low-latency needs, you may not be able to handle the start time (~60s or less). If every second truly counts and there’s no workaround, a DEX solution is probably better. You have strict requirements for on-prem or air-gapped environments. You can’t run on the cloud if you can’t get to the internet! You have highly predictable, always-on workloads. In some of these cases, a dedicated DEX VM might be more cost-effective and convenient. It’s worth evaluating to see. highly predictable, always-on workloads As I’ll mention later, there is a cold-start latency with the first run on E2G. If you have ultra-low-latency needs, you may not be able to handle the start time (~60s or less). If every second truly counts and there’s no workaround, a DEX solution is probably better. ultra-low-latency needs How can I move from DEX to E2G? Now that you know why (or why not) you should make the move, let’s get into how to move from DEX to E2G. First, we all know that infrastructure changes can present risks. It takes many hours—and headaches—to make major changes. But in most cases, it actually takes minimal effort to change from DEX to E2G. Your core tests don’t need to change. While there will be some effort configuring agents (especially if you have a large number), the actual switching is easy. Team agents Your first option is to start with E2G Team Agents. Maybe your organization (or you) just isn’t comfortable with cloud yet. Maybe you have lingering requirements to continue using your boxes. With Team Agents, you still manage your own infrastructure, but E2G manages the Team Agents. So you can retire your old distribution server, but still keep the infrastructure. It’s a baby step to Cloud Agents. This move is straightforward. 1 - Spin down the DEX server. It’s probably safest to keep the machine provisioned, though, until you’re comfortable with the switch. 2 - Create your E2G Team Agents. Download and install the Tosca Cloud launcher Follow the three-step wizard to name the agents, assign them to pool, and define their characteristics. 3 - Execute your playlist! E2G will distribute the tests to available agents and report back with the results. Cloud Agents You can also jump straight into Cloud Agents and run your tests on the cloud. No more managing and configuring local hardware. It’s still simple to get started—basically the difference is just a checkbox and some options. 1 - Open the Playlist Details, find the Agent Characteristics tab, and check the “Cloud-agent” box. 2 - Choose your options for run order and recording. If your tests can run in parallel, you could see significant time savings by choosing that option. 3 - That’s it! Now execute your tests. Regardless of whether you choose Cloud, Person, or Team Agents, the results and logs are shown in the E2G dashboard. Again, keep in mind that even if you’re using Team Agents, if you ever need specific hardware or configurations, you can always drop back to Team Agents. Edge cases The above clear path is pretty easy. But let’s look at some potential problems I’ve run across that you should watch out for: Mismatched characteristics — Tag mismatches can cause problems. If you mistype or forget to update a tag, E2G won’t find a matching agent, and your runs might get stuck on “Pending.”
Network/data access — Since Cloud Agents live on Tricentis-managed resources, if your app sits behind a VPN, you’ll need to configure appropriately for access.
Cold starts — The first run of a fresh flow can take a bit of time (~60s or less) while the cloud VM spins up.
Custom plugins — If you use custom plugins, you may need extra packaging or installation scripts. Mismatched characteristics — Tag mismatches can cause problems. If you mistype or forget to update a tag, E2G won’t find a matching agent, and your runs might get stuck on “Pending.” Mismatched characteristics Network/data access — Since Cloud Agents live on Tricentis-managed resources, if your app sits behind a VPN, you’ll need to configure appropriately for access. Network/data access Cold starts — The first run of a fresh flow can take a bit of time (~60s or less) while the cloud VM spins up. Cold starts Custom plugins — If you use custom plugins, you may need extra packaging or installation scripts. Custom plugins Once you’ve accounted for these edge cases, you should be good to go. Conclusion As you can see, moving to the Elastic Execution Grid is pretty easy, and I think the benefits are well worth it. Compared to using DEX Agents, E2G is simple and flexible. It’s exciting to stop managing machines and simply “check a box.” I can’t wait to keep exploring! For more info, check out this detailed getting started guide. detailed getting started guide Have a really great day!

dashboard

Custom Threat Feeds Are the Future — Here’s How to Get Started

Doing More With Less? Not Without Better Logs and Better Tools

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Too Long; Didn't Read

Make resilience your competitive advantage

The 4 Big Reasons You’ll Regret Not Moving to E2G Sooner

The 4 Big Reasons You’ll Regret Not Moving to E2G Sooner

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

0–100 in Django: Starting an app the right way

The Noonification: How to Deal With Flapping or Broken Tests (11/29/2023)

The Noonification: OpenAI is Sam Altman; Sam Altman is OpenAI (11/30/2023)

The Noonification: Panda Power (11/28/2023)

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

0–100 in Django: Starting an app the right way

The Noonification: How to Deal With Flapping or Broken Tests (11/29/2023)

The Noonification: OpenAI is Sam Altman; Sam Altman is OpenAI (11/30/2023)

The Noonification: Panda Power (11/28/2023)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps