In the best of all possible worlds, API development, testing, and operations teams always work together in perfect synchrony, delivering high-quality APIs on schedule, under budget and completely error-free. But the likelihood of achieving this ideal may seem like a mere dream to some API delivery teams. As applications become increasingly complex, consisting of multiple interdependent components and using several APIs, both internal and external, to connect them – what is the best way to strive for delivery greatness? There is a concept that can speed your time to market, reduce testing costs and reduce risk to your production API – and that’s API virtualization.
Let’s start with a simple definition; API virtualization is the process of using a tool that creates a virtual copy of your API, which mirrors all of the specifications of your production API, and using this virtual copy in place of your production API for testing. Instead of setting up a whole separate server stack to mimic production, API virtualization aims to simulate the minimum behaviors of one or more API endpoints.
To illustrate, API virtualization is the equivalent of allowing you (or, in this case, your testing team) to taste a cake – its flavor, texture, and all – before it has finished baking.
With API virtualization, your development teams can create virtual APIs instead of production APIs, enabling frequent and comprehensive testing even when the API is still in the midst of being developed. By emulating behaviors and specifications that will be present in the final production API, virtualization allows for testing much earlier in the development process, removing key bottlenecks that would otherwise delay production and time-to-market. More and more companies are using virtualization to improve productivity, reduce testing costs, and deploy higher-quality APIs in a shorter timeframe. By quickly and easily removing dependency constraints across your organization through virtualization, you can gain a competitive advantage over other companies still waiting in the linear-development limbo.
API Virtualization vs. API Mocking
API virtualization is often compared with mocking, but they’re not the same thing. Mocks are imitation software components that are used by developers to emulate real software components for testing purposes, which initially sounds a lot like virtualization. However, one of the biggest distinctions between mocking services and virtual APIs is that mocking functions tend to be very context-specific, simulating a specific behavioral response to fulfill a certain development need at a certain time (i.e., injecting a missing dependency in order to bypass its absence, or temporarily test its presence, perhaps in isolation from the rest of the application under test).
API virtualization, on the other hand, delivers—for all development intents and testing purposes—the same behavior and functionality for any developer or tester who wants to use the API, at any time. Thus, once they’re created and exist as part of a project-wide test environment, virtual components eliminate the need for individual developers to write and rewrite their own mocks, saving time and effort for all concerned.
API Virtualization vs. Service Virtualization
Service virtualization typically refers to the process of simulating many or all components in an application stack. Traditionally, enterprise service virtualization solutions require standing up a full-stack of resources, training and management over software suites, and incur an enormous financial burden with entry costs into the hundred-thousands.
The total cost of ownership over an enterprise service virtualization solution, typically in the range of $50,000 - $200,000, includes:
- Time identifying an appropriate solution
- Initial Licensing costs
- Implementation and professional services costs
- Cost to reconfigure virtualization strategy due to project changes
- Employee training
The magnitude of these costs can often be overwhelming for agile project teams either just getting started on implementation of a service oriented architecture (SOA) or formulating a larger enterprise API strategy. Delays in budgeting and purchasing such a costly solution prevent teams from being efficient in their projects long after the need for service virtualization is realized.
API virtualization, on the other hand, is a ground-up attitude to mimicking system behaviors and does not assume that an entire environment is required in order to simulate realistic behavior, just what is necessary. Service virtualization itself is only a supportive task to building the actual system, and any time spent on it is time not spent on building or testing the actual system. Therefore, minimizing the amount of work and time it takes to configure virtual APIs improves both opportunity cost and minimizes unnecessary enterprise licensing costs.
In essence, service virtualization mimics an entire system, with all its complexity. When working with API virtualization, the only virtual asset is the API, which makes the virtualization itself a significantly easier process. Far fewer skills and much less knowledge about an enterprise service virtualization strategy is required for these teams to inherit the benefits of virtualizing one or more of their APIs.
Minimizing Project Costs
Modern apps depend on APIs built by other teams or external companies, and many commonly-utilized 3rd party APIs operate under a pay-per-use model – the more you test against these APIs, the higher the cost. Time and budget can get rapidly depleted by performing tests, especially load and continuous integration testing. API virtualization eliminates the need to use 3rd party APIs directly, ensuring that you don’t sink your project’s budget in the testing phase.
Particularly in regression and load testing, relying on 3rd party APIs can incur fees well beyond established budget constraints. As important as these types of testing methods are, without API virtualization, there is no way to perform these tests without either hitting rate limits or incurring overage fees. Some 3rd parties don’t even automatically cut off clients who exceed their limit, resulting in an unanticipated explosion in cost to the client at the end of the billing cycle. Virtualization of these external APIs is the easiest and fastest way to avoid these situations.
With the increasing trend of systems connected by web APIs, software teams looking to speed their delivery process via shorter Agile sprints have less time between development and testing phases. Traditionally, testing only begins when there is something to test, an early alpha build deployed to a testing environment. In waiting for development to produce an initial implementation, downstream members of the team waste valuable time and often fall out of cadence with sprint or goal timeframes.
Likewise, agile teams often work on multiple overlapping projects at once, some dependent on others to complete work required for the next project. Significant delays in delivery can cause multiple projects to be delayed due to a single project interruption, especially so with API projects as they are often a root dependency to front-end development and testing processes.
With API virtualization, front-end designers, testers, and system integrators can begin their work as soon as developers produce an initial specification (WSDL, RAML, Swagger, etc.) early on in the design process. Using virtual APIs, testing teams can immediately begin to build out test artifacts, front-end designers can establish designs around realistic data, and system integrators can establish expected behavior characteristics between new systems.
API virtualization can dramatically expedite time to delivery of API project-based teams by providing a streamlined and lightweight approach to simulating just the necessary technologies involved in an API project.
Performance testing an application with live, external services will create extra traffic that can cause serious issues with the actual company network infrastructure; it could cause bandwidth problems at the point of the ISP and in extreme cases trigger a Denial of Service.
API virtualization makes it possible to test an API in isolation, gauging the reaction against real data, under a variety of load conditions. This allows testing teams to conduct load tests repeatedly until the API demonstrates that it can perform under the strain of the desired number of concurrent users - no production system required or harmed.
Once you’ve weighed the benefits of API virtualization and implemented a program internally, you will want to promote within your organization to increase adoption. It is likely that many of your teams haven’t even heard of API virtualization, or they’re skeptical of its value.
Implement A Pilot Program
First and foremost, it’s important to not overinflate the whole team’s expectations. In other words, start small - select the right pilot project, and roll out additional virtualized APIs as your organization sees successes in your initial implementations of API virtualization.
In the first iterations of your pilot, your goals should be to familiarize yourself with your new API virtualization tool, prove it works, and project how much time and effort it will save you in the future.
Some tips: don’t select a new API that’s in development, or one with several interfaces, or one that calls multiple third-party APIs. Start by picking one small, stable API that seldom changes.
It will be tempting to initiate your API virtualization program based on a major pain point in order to prove that your API program can solve all of your existing API woes. However, in some cases, the complexity of the problem will overshadow your initial goals. The risk in piloting your program based on a problematic API is that due to complexity and high visibility, should your initial implementation require fine-tuning, the perception of failure can doom your program’s future. So, follow this process: familiarize, prove, project.
Pick the Right Team
You don’t always get to handpick your team. But to ensure the pilot succeeds – and your API program gets adopted – you need a small innovative team. Select team members who are positive and imaginative, people who want new ideas to work.
Second, find a project champion. A dev manager or scrum master who already believes in the technology and how it can benefit is ideal. Their enthusiasm can help drive the team forward and later can help socialize the technology across all of DevOps.
It’s likely that you already have employees in your organization that meet the criteria above. Make sure that you seek them out and make a case to build them into your team – you need their positive attitude to succeed.
Brag About Your Results
It’s important to set specific and realistic goals for the outcome. There are several possible results that can occur during a pilot, such as personnel reassignment and project reprioritization. APIs may also change rapidly, causing team members to lose sight of the value of virtualization, so defining success for your project is crucial. Be specific, and don’t hesitate to state exclusions – tangent issues that can kill a pilot.
Lay out your project plan or your first sprint, and go meet those goals.
As you’re rolling out your first virtualized API, don’t hide your progress along the way. You don’t have to detailed emails each day to the whole department to socialize how your implementation is progressing. But your team will benefit if you’re vigilant about communicating results. Let your organization know you’re doing something big – and they will reap the benefits. Broadcast your success - post messages or articles on SharePoint, Yammer, Jive or whatever enterprise social network you use. Host brown-bag lunches to answer questions. Publish yourself in internal communications or e-newsletters, focusing on the broader benefits or API virtualization to groups besides your own.
Of course, there will be skeptics along the way, and you need the rest of DevOps to not only accept, but embrace your virtualized API program. Because naturally, the program will not be a success if your virtual APIs go unused by the stakeholders for which it was designed. Some people are naturally open to new technology and new processes – you probably picked those for your pilot team. Others are entrenched with “the way we’ve always done things.” After all, change is hard, especially without proven benefits.
So how can you counter that inertia? Paint the broader picture and be transparent. Make sure that you communicate the following often: the reason for virtualizing your APIs, the method for implementing your pilot, and the results as compared to project goals. Ensure your organization is aligned on the checklist for API virtualization tool selection. Be honest about what successes you saw in your roll out, and what improvements could be made in future iterations of your virtualized APIs - focus on the positive, but don’t hide the negative.
And finally, let the numbers talk. The beginning of this guidebook outlined the benefits associated with API virtualization – these are actually not difficult to quantify:
- Staff hours or days saved: how many hours did your testing team work on a virtualized API while the production API was still in development? What would the time implication have been if these processes were not parallel? Given the cost of staff, how many man-hours and dollars were saved?
- Time to market shortened: using the hours above, how much sooner were you able to deploy your API and move forward with the next development cycle?
- Pay-as-you-go 3rd party API costs reduced: you already know how much you have paid to test 3rd party APIs, historically. How much was that cost reduced?
For the pilot, these numbers may be small or non-existent. But for future implementations, keep the above questions in mind and make these calculations as a method to prove your success.
Finding the right people and processes are great first steps to successfully launching lightweight API virtualization to your team, but you need the right tools to accomplish your goals quickly and painlessly. Here are some features you’ll want to consider when virtualization solutions:
- Web protocols – SOAP, REST, JMS, other?
- Payloads: XML, JSON, XML-RPC, JDBC, other?
- Ease-of-use: Installation, setup, configuration and support?
- Lightweight: API virtualization versus server virtualization?
- Simulations: Support for latency and error simulation for 3rd party APIs?
- Training requirements: Can existing resources standup and modify an API?
- Scalability: Support for performance and load testing?
- Evaluation copy of full-featured product?
- Quality and responsive support and assistance?
Make yourself a checklist, and weight those that are absolute requirements over just nice-to-haves. If you want to get started, you can start a free trial of ServiceV Pro to see how easy service virtualization can be.