tiero - Fotolia
Overcome 9 microservices challenges for platform flexibility
It's all well and good to tear apart your monolith, but a careless microservices approach can result in the same old problems. Watch out for these nine hurdles.
More IT shops want to put microservices inside containers, a technique that holds great promise for the future of open and flexible hybrid IT platforms.
Developers can encapsulate a range of functions within a single container and then use it across multiple composite applications, but there are several microservices challenges enterprises can encounter. Watch out for these nine specific concerns.
1. Granularity
The end is near for the age of large, monolithic applications. Many organizations struggle to rapidly improve or replace selected parts of a monolith. Instead, small, replaceable and pluggable items of code make more sense, but users first need to find the right level of granularity. If it's overly granular, the composite application will be too slow, as it might not be able to handle the number of calls made across the network. If there's not enough granularity, organizations are right back where they started, with a myriad of microservices challenges stemming from large pieces of code.
2. Open standards
Organizations too often get locked in by proprietary approaches. Ensure that all external interfaces adhere to open standards so that you can easily reuse each microservice.
However, many open standards are actually de facto standards, such as the S3 storage standards developed and set by AWS. The majority of IT pros will use a strong standard: one that has been argued over and compromised on by a group of people and then published as an IEEE, IETF or ISO standard. A standard that no one ever adopts is worthless.
That said, proprietary technology can be helpful, as long as it doesn't impact the overall approach, gets the job done and is used with eyes open. But proprietary technology should largely be kept to events that happen within the microservice, and users should maintain standardized interfaces between the microservice and the external world as much as possible. Only use proprietary software within an external interface for tactical reasons, and make sure those reasons are well-documented within the microservices code and all its supporting documentation.
3. Loose coupling
The original service-oriented architecture approach did not work because too many organizations replaced hard-coded, monolithic applications with hard-coded, linked services. As a result, it was hard for an organization to easily replace a service with another when needed, as it had to break existing hard links and replace them with new hard links. Make sure that you can freely call modern microservices through means such as XML and that the responses are provided in an equally open manner.
4. Microservices portability
Microservices are ideal for hybrid cloud environments, provided that code is portable and can take all required linkages with it. For example, an organization might want to make the most of cheap public cloud resources for general usage but also want to pull a function back on-site for heavy usage to gain performance improvements. The rest of the composite application must understand this workflow and be able to link intelligently to the changes in the microservice. The more you share a component, the more microservices challenges you can encounter. Make sure to design the entire architecture for portability.
5. A directory of functions
Developers rarely change. They see the functionality as something that begets more code. The whole premise behind microservices is that code is only written when it's needed; instead, use the microservices as many times as possible so that they earn their keep. Developers need a directory that provides enough information to understand which microservices are available, what those microservices do and what is needed to use them. Administrators might also want to monitor how developers use microservices and incentivize optimal usage.
6. Feedback loops
In its original form, a microservice might be ideal for one-off usage, but that could leave the next developer wanting. It's important to understand that developer's needs and act upon them so that the original microservice can be modified, rather than replaced.
7. Monitor usage
Microservices challenges can snowball quickly. Admins must continuously monitor microservices usage across environments. Flag underused microservices, and ask the developer responsible if they are still needed or whether an alternative microservice could be used. Shut down unused microservices, and scavenge any available licences.
8. Updates and patches
Never fall for the idea that a microservice is perfect. Each microservice must receive updates and patches. Afterward, integrate it into your organization's DevOps and orchestration systems.
9. Elasticity of resources
An overshared microservice will not work well if it's written and provisioned to respond to a particular size. Make sure to provision enough resources in real time to meet the needs of the microservice.
