Microservices is not for every business
Businesses that have embraced microservices have realized significant benefits, and organizations that ignore this fact may be left behind. But while microservices looks promising, not every business can capitalize on the architecture. Make sure your business is capable enough to manage it. Here are some organizational caveats.
You’ll need to be equipped for rapid provisioning and app deployment
With incremental development and continuous delivery, microservices keeps your organization on its toes. Staff should be able instantly to provision resources to keep up with the pace required to make the most of microservices. If it takes days or months to provision a server, you’ll run into serious trouble. Similarly, you should be able quickly to deploy new services or applications.
Robust monitoring is a must
Because each service relies on its own language, platform, and APIs, and you will be orchestrating multiple teams working simultaneously on different entities of your microservices project, you need robust monitoring to effectively monitor and manage the entire infrastructure, because if you don’t know when a service fails or a machine goes down, it may be impossible to track down issues when they arise.
You must embrace devops culture
To work in cross-functional teams, your business should incorporate devops practices and culture. In a traditional setting, developers are focused on features and functionalities, and the operations team is on the hook for production challenges. In devops, everyone is responsible for service provisioning -- and failure.
Testing can be complex
With microservices, testing isn’t straightforward. Each service has its own dependencies, some direct, others transitive. As features are added, new dependencies will pop up. Keeping tabs on all this quickly becomes impractical. Plus, as your number of services increases, so too does the complexity. Whether it’s database errors, network latency, caching issues, or service unavailability, your microservices architecture better be able to handle a reasonable level of faults. So, resiliency testing and fault injection are a must.
You need to design with failure in mind
Designing for failure is essential. You should be prepared to handle multiple failure issues, such as system downtime, slow service and unexpected responses. Here, load balancing is important, but having a plan B is another important option. When a failure arises, the troubled service should still run in a degraded functionality without crashing the entire system.
Sign up for Computerworld eNewsletters.