WavebreakmediaMicro - Fotolia
My company has been talking about transitioning to microservices. What are the important things to know from a test and quality perspective?
Like the advice to the heroes in The Hitchhikers Guide to the Galaxy: don't panic. Yes, microservices is a new buzzword, but getting to adopt and roll with new trends is how we develop professionally. Sometimes, these new ideas -- like testing microservices -- are actually refinements applied to a very old idea. As the new waves crash over the beach, the answer is the same as it always was: keep calm and continue testing.
Microservices as a strategy boils down to creating interfaces -- typically APIs -- to expose business processes. Wrapping services like create member, create claim, pay bill, search and so on makes it possible to compose applications by stitching together API calls with a user interface on top. That's not really new, but the emphasis is different. With microservices, the goal is to refactor these services into smaller contiguous parts so it will be easier to balance, load and interact with the APIs. The goal of microservices is to have modules that handle certain entities or tasks that are all done through a specific well-defined API, for example, REST.
The impact of microservices is easier reuse, easier refactoring and less code because the code is DRY -- don't repeat yourself and more concise. At the end of this logical conclusion, the company has a large number of public microservices, each created to handle specific issues.
For example, imagine a program like Google Maps that may interact with a login service that handles authentication and fetching of user preferences for use of the maps. It may have a directory of businesses archived by GPS coordinates along with their names, addresses and telephone numbers. Now imagine that login service we mentioned gets more load than the rest of the functionality, you might not want to spin up whole servers for Google Maps. Instead, choose to distribute the login service in a manner that could be both load and geographically balanced. Keep it insulated from some of the uptime and downtime issues that might impact it if it was on the same server as the directory service that the Maps application interacts with.
So what are some things to consider when testing microservices from a quality perspective? I would first look at the API. Is it REST? Is it using Internet of Things Database, Message Queuing Telemetry Transport or some other protocol or standard? Identifying the type of interfaces being used will open knowledge for how to build some requests to communicate with the underlying microservice. You might then want to look at a tool like Ready! API, cURL, HTTPie, Postman or some other tool like Fiddler that enables you to see the requests as they are built and interact with them.
Of course, it is likely that management doesn't know the answer to that. They are just looking at microservices. That is a fantastic opportunity for you. Don't complain that these people are "idiots" who "don't know what they are doing," be part of the solution: read a few books over the weekend, come up with your own ideas and suggest things. Make assumptions about how things will work so you can drive forward. At worst, this will force other people to decide -- but it is more likely that they will just go with what you decided.
Next, ask or help figure out how the service is deployed. Does it require a pre-distributed access key? Does it require some type of authentication -- HTTP Auth, oAuth? Does it handle authorization -- access based on user or role type? Then, you could dig and look at how it handles data types for certain calls. Does it let you change data with a POST or a PATCH call? Does it handle invalid characters gracefully, and is it able to throttle requests when under unexpectedly high load from a given user?
From there, you may find other things of value. For example, look at the client applications. Do the clients handle API errors gracefully? You can test that by using stubs that return errors or nothing. You might look at the published contracts for the microservice and see if what is returned is consistent and acts in a way that is intuitive and reliable to a user.
First, read about the type of microservice that is being used or built and consider tools that can help you better test and compare results. Then, evaluate details of how it is implemented, how that compares to other similar services, and how the API and clients will behave when confronted with exceptional conditions or when users try to use it in a way it may not be intended. What happens if the microservice goes down, and does your application cover it gracefully?
There is a lot of fodder there to consider, but the more you learn about testing microservices, the better understanding you may have in the long run.
Are microservices the new documentation nightmare?
Microservice architecture for mobile -- yea or nay?
Onboarding can help improve microservices projects