8 simple rules for avoiding microservice chaos

Many organizations are finding microservices, or fine-grained, reusable units of functionality, the way to go in breaking down monolithic, slow-responding systems to something more agile. But as with any new business technology approach, microservices are not a panacea, and things can go wrong pretty quickly. As requirements and change requests pile up, software delivery may get bogged down, and schedules may go out the window, especially in development shops where a lot of things are still done the manual way.

Two recent posts -- from Vijay Alagarasan, principal architect for enterprise architecture and strategy of Asurion, and Tony Bradley, an IT strategy consultant -- express caution about diving into microservices development and deployments too quickly.

What are microservices? They're "an approach to delivering service-oriented architecture by building fine-grained services to support business capabilities that are distributed and organized as functional domains," Alagarasan says. In other words, it's a more scalable form of SOA. Bradley draws a connection between microservices and DevOps,calling them "an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components."

With that in mind, here are some guidelines to help plan and implement microservices-based projects. Seasoned IT people may see familiar patterns with previous technology initiatives; indeed, like the laws of gravity, there are certain truths that always remain:

1. Deliver value to the business -- not just to IT. As noted above, this is a tried-and-true rule that has bedeviled many technology initiatives over the years, and certainly may call microservices projects into question. "Make sure that your approach to microservices benefits your organization--that it adds value and meshes with business objectives and isn't just microservices for the sake of following the microservices trend," Bradley says.

2. Provide guidance to current and future managers and developers. They may be "micro," but these services require the same level of documentation and support as any major software project.

3. Put governance in place. As with any technology-based initiative, lack of cohesive governance will knock a microservices initiative off track. "The preventative cure is to govern business functionalities that are not relevant to the service," Alagarasan points out. "Services must align clearly to a business capability and should not try to do something outside of their boundary." He warns that otherwise, the services will end up in "a tightly coupled architecture, resulting in delivery entropy and cohesion chaos."

4. Automate early and automate often. "There are a variety of moving parts involved in doing microservices successfully," says Bradley. Enterprises working with microservices need, at a minimum, "a way to automatically test and deploy," Alagarasan urges. "Microservices are aiming to drive agility, with the speed we need to change; quality assurance involves each service having automated unit, functional, security and performance testing."

5. Separate services by business capabilities, not technical concerns. This gets down to the ability of microservices to operate independently of one another, rather than attempting to fuse them in the name of technical cohesion. "Creating multiple, technical, physical layers of services would only cause delivery complexity and runtime inefficiency," says Alagarasan. "Try to look at a service as one atomic business entity, which must implement everything to achieve the desired business functionality. The self-contained services are more autonomous and scalable than the layered services."

6. Test everything. Along with the autonomy described above, "every service that you deliver must have a test suite, which should cover all the service functionality, security, performance, error handling, and consumption driven testing for every current and future consumer,"Alagarasan says. "This must be included as part of the build pipeline for automated regression testing."

7. Stay on top of versioning. Don't expect to simply require one version of the service, Alagarasan says. Once the service is deployed, end-users will demand changes, requiring new releases that keep adding up. "Some enterprises foolishly try to avoid versioning," he points out. "Services need to be architected assuming that change is inevitable. Have a strategy to manage the forward compatible service changes and allow your consumers to upgrade gracefully. Otherwise, it will lead to having consumers tightly bound to a service version and break when there is a change."

8. Stay on course. There's no going back, says Bradley, who notes that "it's exceptionally difficult to switch back once you start down the microservices path. The changes that have to happen in terms of culture, tools, and processes to embrace microservices are not easily undone."