staging-devopsy.kinsta.cloud

Tag: eaas

  • Best of 2022: Environments-as-a-Service: Free Your Devs

    Best of 2022: Environments-as-a-Service: Free Your Devs

    As we close out 2022, we at staging-devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Environments are the bane of a DevOps engineer’s existence and have been since the invention of the server. They can create giant bottlenecks that hamper productivity and suck the life and motivation out of developers. But they’re also completely necessary.

    DevOps teams spend a ton of time building and maintaining their development environments. They are critical to testing new websites, apps, products and updates; making sure everything works the way it is supposed to. And not having enough environments can slow down workflows as developers wait their turn to use an environment.

    There is a new push in the software industry to provide environments-as-a-service (EaaS), removing the annoying yet necessary work of building and maintaining environments and giving DevOps engineers more freedom to tackle more challenging, revenue-generating projects.

    EaaS enables companies to use a third-party service to create a new development environment on-demand, including data, infrastructure and code—all the things necessary to build and run an app. Environments-as-a-service bring major improvements to businesses, saving money and time while increasing the velocity, delivery and deployment speed.

    EaaS offers automation and codification of all the things that would otherwise waste DevOps and infrastructure folks’ time. They should be focused on higher-value tasks, like creating and refining what makes the company or product unique.

    Removing Bottlenecks

    When prepping for a new product or service, teams have to test all associated code to make sure it is functional, secure and that there are no hiccups. Multiple environments are crucial to this process. However, in many cases, teams work within a single, shared staging environment.

    This setup means developers have to wait in line to test their part of the product. These bottlenecks are among the biggest causes of delayed releases.

    Time is money, and in this case, lost time costs money. We estimated the total cost of managing environments exceeded $45 billion annually, and release delays cost organizations millions of dollars every year.

    Organizations can layer EaaS on top of their infrastructure-as-code (IaC) frameworks, agile workflows and other important software. By doing this, developers can create a new environment with a single click.

    That means developers can make a new environment for every feature branch pull request. EaaS also unlocks customization capabilities, as well. For example, testing requires larger and faster environments that integrate with other key services, while more scaled-down environments work well for processes like demos.

    Now, developers are free to test and develop software, without waiting or stepping on anyone else’s toes. Plus, on-demand environments can also be destroyed when they are no longer needed. That’s capacity planning in real-time.

    Save Time and Money

    Capacity knowledge and better capacity planning mean money saved. Knowing how many environments are needed, and what types, helps organizations avoid over- or under-spending on cloud infrastructure.

    Building out environments can take more than a year for even sizable DevOps teams and cost hundreds of thousands of dollars, not to mention the challenges of ongoing management, integration of new tech and management of cloud resources and costs. A third-party EaaS provider takes care of all of that, freeing DevOps engineers to work on hard problems, rather than maintenance and repeating work that has already been done as technology advances.

    Is Your Organization EaaS Ready?

    Any time a company automates something as important as staging and testing environments, though, it’s important to have all their ducks in a row. Luckily, the best ways to do that match up pretty well with best practices for building out any infrastructure platform:

    â—Ź Using infrastructure-as-code automates the provisioning of infrastructure instead of doing it manually.

    â—Ź Containerizing custom code makes it easier to quickly reproduce it for new environments.

    â—Ź Finally, carefully think about how your environments will behave when they are created dynamically. Simple things like creating environment variables for hostnames and trying not to hardcode variables that are environment-specific are a must.

    Organizations that have followed these steps are EaaS-ready. By automating these painstaking tasks, companies can unleash their DevOps teams to be superheroes for the organization, solving the biggest problems and letting tech take care of the rest.

  • Beyond IaaS: The Benefits of Using EaaS

    Beyond IaaS: The Benefits of Using EaaS

    Beyond IaaS: The Benefits of Using EaaS

    The market for cloud infrastructure is growing at a rapid clip. Driving factors include IT’s need to cut costs, provide more services, respond faster to business needs, and enable innovation and digital transformation. For many years, Infrastructure-as-a-Service (IaaS) offerings have been both the first and most used cloud services consumed by businesses. But increasingly, more is needed. That has opened the door for Environment-as-a-Service (EaaS), what some call IaaS Plus.

    To put the demand for such services into perspective, consider cloud spending. While most organizations were already executing on their cloud migration strategies pre-COVID, the pandemic was a serious wake-up call for those lagging behind. Gartner predicts public cloud services global spending will grow to $332.3B this year, up from $270B in 2020. Gartner also anticipates that by 2024 almost half of all IT spending on software, system infrastructure, and process outsourcing will have pivoted from traditional solutions to the cloud.

    Within those numbers, the IaaS segment is predicted to have the largest growth (percentage-wise) over the next few years. The IaaS market will nearly double from roughly $60,000 in 2020 to about $107,000 in 2022. Looking beyond next year, ResearchAndMarkets.com predicts the IaaS market will reach $74.63 billion in 2025 with a compound annual growth rate (CAGR) of 13.8%.

    Why the big jump? Cloud-based service models can provide significant financial advantages for businesses, allowing them to quickly access new functionalities without requiring heavy upfront investments. Cloud services rotate some capital expenditure costs into operational costs, with infrastructure-as-a-service (IaaS) enabling organizations to move fundamental storage and networking functions to the cloud and away from on-premises hardware.

    Enter EaaS

    One of the greatest fundamental changes companies have encountered in the last few years is that business demands for new applications and services have rapidly grown, causing a need to accelerate application development.

    And most importantly, development is no longer a one-time effort, and applications must continuously be patched, updated, and enhanced. Each change or addition requires one or more development environments, plus infrastructure and applications for performance testing, quality assurance and deployment.

    That’s where EaaS helps. EaaS extends the capabilities and benefits of IaaS into the development environment. It offers the infrastructure, applications, and data that DevOps teams need to develop, deploy and maintain their applications.

    An ideal EaaS solution will offer certain features to increase the efficiency of the DevOps staff, reduce costs and help businesses maintain control over fast-paced development environments.

    For example, a well-suited EaaS would use automation to configure servers for a specific application. It would be a self-service offering that integrated with normal DevOps workflows, tools, and methodologies. For example, a business might look for an EaaS offering that gives users a choice in how they access the services. That might include access via a web portal, command-line interface, or directly through a developer’s CI/CD tools.

    That last capability is particularly important today, given the way applications are developed and maintained. An EaaS must integrate into the existing DevOps ecosystem and CI/CD pipeline to support today’s demand for complete, ready-to-run environments delivered on demand. The way to ensure this is to look for an EaaS provider that supports out-of-the-box plugins and an extensive REST API for common CI/CD and DevOps tools.

    One additional issue that businesses need to address is cost control. Costs can quickly add up with the use of cloud services being so easy and with some providers offering self-service options. In many situations, cloud service users have no insights into their cloud spending until after the monthly bill arrives. And even then, there is often no granular view into where the costs were incurred.

    What’s needed is an EaaS offering that incorporates cloud cost management capabilities that are implemented in such a way as to not slow down application development and delivery. In particular, cost visibility and control are required but cannot be implemented in a way that adds friction to the process. Many cost management approaches fail in this regard. A good EaaS solution will provide the needed visibility and control while not hindering development and deployment.

    Last word

    Modern applications development must be based on CI/CD to deliver new applications, services and updates in a timely manner to match fast-changing business opportunities and requirements.

    While IaaS platforms satisfy many of the core infrastructure requirements, EaaS complements these capabilities by offering the complete environments delivered on-demand needed for DevOps to work. EaaS also offers tight integration into DevOps workflows and CI/CD pipelines.

     

  • 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