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.
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.
Put your knowledge of microservice architecture to the test
Exploring the pros and cons of microservices for developers