Manage Learn to apply best practices and optimize your operations.

Testing microservices and APIs in the cloud

While app architects and developers find that microservices and RESTful APIs provide much-needed agility, it's also complicating testing efforts. Tom Nolle explains why.

The Internet and cloud computing are quickly shifting application focus from SOA and service busses to microservices...

and RESTful design.  Application architects and developers find the new models to be more agile, but the very cloud environment that's helping to spawn both trends is making testing microservices and RESTful APIs notoriously difficult.

To avoid being "trapped in flexibility," developers need to first understand the issues of multidimensional agility the cloud presents, build an approach by applying abstraction principles effectively to reduce complexity, and design services and APIs to be flexible in the functional and deployment dimensions without becoming disorderly.

Application agility, meaning the ability of application development to quickly address changes in business needs and opportunities, is increased in large part by componentization and component reuse.  Rather than building a totally new application every time something is needed, componentized development builds an inventory of reusable components that can be easily assembled and reassembled.

Cloud computing also improves agility by shortening the deployment cycle through the use of public server pools and by facilitating application scaling and component replacement under changes in load or resource status.  Beyond that, the cloud is a handy platform to host microservices or components that are not only broadly useful within a company, but also broadly useful across the market at large.

Cloud development maturity quickly exposed a critical interdependency here.  Testing microservices or APIs in a traditional application can be challenging, but adding a dimension of resource independence and agile component instantiation meant that an application could be tested and certified in one environment and yet fail in what seems a logical evolution of that environment.  Quality of experience (QoE) for workers was particularly vulnerable to the interplay of these application agility dimensions.

To avoid being 'trapped in flexibility,' developers need to first understand the issues of multidimensional agility the cloud presents.
Tom NolleCIMI Corporation

The testing process falls victim to too many unconstrained variables and a lack of specific performance or availability objectives for key components of the application.  Obviously, the performance of a microservice will depend on where it is hosted in the network relative to the users of the service and how many instances are available to share the load. Yet in most cases the design of the microservice or API did not include any assumptions on variability in deployment location, number of instances, distribution of work or other things clearly related to cloud deployment.

Behind the concept of microservices, REST and the cloud is the concept of abstraction, which is a technique to expose the features of something without exposing the implementation.  A microservice is a functional abstraction, REST abstracts processes to look like simple resources and the cloud creates virtual infrastructure that can map to whatever real resources are available.  The challenge for testing microservices and APIs in the cloud is that the implementation of microservice and REST can collide with cloud resource mapping.  Fortunately, that can be fixed if you take care in how your abstractions are created in the first place.

A microservice or API is not a singular web server; that violates the principle of abstracting features from implementation.  Thus, microservices and APIs should be viewed as a gateway to an agile collection of implementations below.  Experienced cloud developers have said: it's essential to have to view a microservice or RESTful API as a virtual connection that, when implemented, includes agile resource positioning through DNS or other directory services, load balancing to manage work among instances, and management of collective resources against singular virtual presence.  That's exactly correct; the key to testing microservices and APIs in the cloud successfully is the abstraction of the services and APIs to include the resource allocation and component scaling features to be used, both in terms of objectives to be met and practices to be employed.  This will enable a test plan to include the cloud-related elements and deal with cloud quality of experience.

Preparing a test plan of this type means including not only the expected load variations, QoE or scalability requirements, but also what the cloud implementation is expected to do to respond to them.  While the number of specific things such a plan has to address varies depending on the application, in general it will be important to do each of the following:

  • Identify the specific way in which application component locations are registered on deployment, including the time required. 
  • Specify how work will be distributed among instances of services and ensure that the needed components are also deployed and connected.  Load balancing practices may dictate special attention be paid to state control, though in general REST or microservice APIs are not stateful.
  • Identify the means whereby applications or components will detect either a component failure or a need to scale the number of instances and verify these are deployed.  It's especially important to set response time goals for this process to set verifiable user-level performance and availability parameters.
  • Prepare test data and procedures to drive the collected resource control and functional elements of the application through their expected range of operations, to collect performance data, and validate functionality.

The process of performing the steps above may expose service design or API design issues.  The issue of state control has already been noted, but it is possible that stateless service behavior, when applied to horizontally scaled services, could result in issues of transaction recovery or data reliability.  This illustrates the importance of designing applications to optimize cloud usage.

Where there might be a profound impact of the cloud on service and API design, it's important to try to capture the specific factors that make this true.  This information can then be used to target additional design attention at those applications most likely to benefit from it.  Also, record all decisions made for each of the steps above, and be prepared to change your practices if operating experience shows you may have missed important issues.  With a little effort, microservice and API design and testing in the cloud can become routine.

Next Steps

Put your knowledge of microservice architecture to the test

Exploring the pros and cons of microservices for developers

A guide to the world of microservices and container technologies

This was last published in January 2016

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

API integration tutorial: Latest trends and strategies

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How have microservices and REST affected your testing procedures?
Cancel
There are many ways in which microservices affect testing. I recommend “Testing Strategies in a Microservice Architecture” on Martin Fowler’s web site for an excellent overview.
Cancel
Unfortunately, too many companies see these kinds of testing as programmers' activities while QA do "traditional functional" testing "manually".
Cancel
It makes testing more difficult. More technologies, more moving pieces. Our microservices utilize queues in NServiceBus. It also makes writing testable stories is a bit more challenging.

I will have to check out Martin Fowler’s post.
Cancel
The big thing is having services.  A lot of Business logic can be abstracted from the logic which controls user interaction, and because of that becomes a lot more testable and perhaps more resilient too.


Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close