Background
As developers many years ago, we began by using simplified systems in which small, individual, properly defined tasks were undertaken one per time. However, our clients grew dissatisfied, and began demanding for multi-purpose services that solved many issues simultaneously. Well, soon enough, we had morphed into a complex multi-purpose unit where one request would have all issues attended to at once.
Cool idea? Well, yes… until a time came when the clients started getting something like a ‘-10001’ response code when they tried to reach us via telephone. This got them quite perplexed and having no idea of where and why what went wrong went wrong, what the so-called ‘exception’ meant, and if any of the transactions eventually went through.
A similar scenario occurred with the SOAP Web Services. What was initially a case of creating a customer eventually turned out to be the handling of the entire order! Not to talk of the abundant error sections the user would be required to handle using a code: “the address is not correct”, “this customer already exists!”, “credit card cancelled” and etc., not to talk of the more technical errors from the database and servers.
Well, now we’re returning to our first love- simplified communication using Restful web services which relies on HTTP Protocol, plainer processes that do one good task very well at a time! All these simplifies and reduces Restful web services development time.
Micro-services affect different groups in the delivery cycle: How?
You must discover what specific changes occur for your group when putting micro-services into effect…especially considering the fact that a macro-services ideal is difficult to change.
To realize the effects of Micro-services, there exist three principal players you must consider; and you will understand how Micro-services architecture affects each and how the different development teams collaboration should work.
The Architects
Architects best relate with the advent of designs in software. They understand the consequences of transiting to a micro-service system or structure, and can also comprehend why at times, archaic systems suddenly become sensible.
Consider micro-services as similar mechanisms to some of the features of languages in programming that are object-oriented. Much unlike their fore-runners, those processes each did one little job on a specified object. The developers were even able to regulate the behavior of the object at a good level; and all errors or exceptions were easily resolved.
Much later, we utilized those processes in developing APIs and more complex objects, to simplify the life of the user. Not long after that, these super-APIs morphed into new ‘black cubes’, concealing every detail. So, when an error arises way down, exception/error code will make no sense to the caller, and even the tester.
Well, basically, our APIs are just like that at the moment. This ideal is most important to the Architect because:
It is Plain, Pure and Simplified.
Every single micro-service performs just one task at once, and that it does very well; not a million other functions that the client has little or no knowledge of. It can even utilize other APIs; but it just doesn’t delve into functions that are not imminently important.
It is quite safe and involves less risk.
This is perfectly logical. Risks don’t correlate linearly with the size of the codes; rather, they do so exponentially. When few codes are performed in individual unit, removing bugs- when they do occur- would be very easy. Same goes vice-versa.
Only an Architectural expert, who has structured a system makeup with very few points of entry, can enjoy and experience these advantages.
The Developers
The developers also get to enjoy a number of these advantages. However, many programmers happen to be a bit too practical and unwilling to shift ground until they are certain about what they stand to gain.
No offences; it is very normal though. In fact, many of us are guilty of doing that, especially when making comparisons between our usual systems and new systems- which seem to have the tendency of increasing the work. Well, to an extent, accepting Micro-services will definitely create a bit more work; as smaller bits of tasks here and there calls for more little processes and planning.
Well, more methods? Yes: but more effort and time taken? Not exactly! Let’s examine a few ways micro-services will be advantageous to the developer.
Agility
This day, many software teams either already utilize or regret not using agile methods. It helps decapitate the workload into smaller, ‘eatable’ bits; and well, that is exactly what micro-services is all about! They offer little bits of processes, rather than large, ingrained APIs. For this reason, micro-services are the best for agile systems.Favors Restful API Parallel Development
Development is free to go on in a parallel manner, given the fact that each micro-service is not dependent on another.
Also, it hinders the wastage of useful time, which may result from a programmer waiting idly for another person to finish, or instead busying himself creating unnecessary elements.Faster Debugging
The reporting of results with micro-services is more accurate. Thus, the tester can declare, “99 percent worked out well, but one percent, for some reason, didn’t: and since the procedure is simplified, the issue can be easily fixed.
Many developers would likely admit that utilizing agile systems and developing parallels would boost efficiency and save time: however, since it’s now known that micro-services also simplify debugging processes, you are sure to get a good remark.
The Testers
Well, most times, when presented with micro-services, testers usually complain about the high volume of the work.
Truthfully, the work is increased. Compared to one gigantic service that does everything at once, they will be required to test many more- howbeit smaller ones. This usually means more time and effort: but it’s not all bad! Here are some advantages the Tester would experience:
Testing large services might take a longer period of time
Even though running a test on a large API requires only a few methods, the exceptions to be examined and tested for are numerous! Recall that, a super-large service can relate with many others, and A FAILURE CAN OCCUR ANYWHERE! Also, every single error situation that arises while working with the API must be properly recorded! (I wish you well in trying to identify and resolve all the exception codes!)
Simplicity
Micro-services are far simpler! True, they may indeed involve testing more APIs; you however are free from the burden of trapping numerous error codes, as is the case with large systems. Micro-services only have a few numbers of possible points of failure, with few error codes to be tested by you!
Lesser Changes in Codes
We earlier established that risks grow in multiples, with regard to the code size. So, it’s like this; would you prefer to have over 25% of your large services fail after upgrading- of course, with no means of deciphering the reason- or you would rather prefer a paltry one percent? Choice is yours.
Another vital thing test groups need to take note of is this: once you put all the extra tests in place, they can actually be used again, without modifying them. Also, making use of an automated device to make and perform these tests means that the real testing process would not require more time, or more people.
Conclusion
It looks like the micro-services architecture are becoming more and more popular and many companies tries to implement or refactor existing systems to micro-services. As of now it seems that there is still a long way for architects, developers and testers to realize how micro-services should work in their own organizations and work places but as it is getting more and more popular, there will not be a way to disregard this.