Enterprises of all sizes are adopting the microservice approach, but not everyone is adopting it correctly. According to Chase Aucoin, developer evangelist for AppDynamics, too often, businesses think if they move their monolith applications to microservices, their problems will just magically go away. However, once they start to move to microservices and realize their problems aren’t going away, they try to place blame on the technology.

Aucoin explained the reason businesses are having such a hard time is that they don’t realize their problems are embedded within the culture of their business, not the technical aspect of the service.

“The biggest challenge when it comes to adopting microservices is businesses think they can throw more technology at a culture problem and fix it, which unfortunately you can’t,” he said.

At its core, microservices are self-contained, domain-specific services that are able to be deployed and tested in isolation. But according to Aucoin, too many businesses are overcomplicating it.

After realizing that this was an ongoing pattern within the industry, Aucoin decided to create the Microservice Manifesto. The manifesto is an online template that consist of six pillars and responsibilities. According to Aucoin, it is similar to the Agile Manifesto in that it is not an all-encompassing book. It is meant to guide the discussion of microservices. Unlike the Agile Manifesto, the Microservice Manifesto’s pillars are designed to be stacked on top of each other in order of importance.

“We all have the same goal — getting out great software quickly, securely, and error free. Microservices can be a great approach for large teams and codebases to help address this need, but there is not a lot of codification around what exactly Microservices are and why they help solve problems,” according to the manifesto’s website. “This document hopes to address that in an opinionated, but dogma-free approach with the end result being happier teams, companies, and clients.”

The six pillars, in order of importance, are:

 

 

    1. Ownership: Ownership is the most important pillar, according to Aucoin. “Without creating ownership, without really valuing your team members and knowing that they are all trying to work towards the same goal of making your company successful, you won’t be successful,” he said. According to the manifesto, businesses typically organize systems in a multi-tier way with segmented teams. However, if you create cross-functional teams that have full ownership and are aligned with the business, it allows solutions to be delivered faster, and the company to respond to hurdles quicker.
    2. Automation: Automation is a top pillar because it helps businesses break down large monoliths quicker, with fewer errors. “If you don’t have automation, trying to break down a monolith or deploy several new greenfield microservices becomes an exercise in madness, and no one wants that,” the manifesto states. Aucoin added that automation enables the success of the other pillars, such as testing.
    3. Testing: Testing as much as possible requires being able to automate as much as possible, which is why testing is the third pillar. “Having automated tests that can run during each deployment ensures that we are delivering quality products and not regressing. The benefit to automating that testing is that we get much better use of people time so that instead of executing tests, quality engineers can be writing tests instead,” the manifesto states.
    4. Discoverability: Discoverability refers to being able to find what you need, when you need it. This is important from a business perspective as well as a technical perspective, Aucoin explained. It enables the business and teams to manage and utilize the system’s functionality. In addition, discoverability refers to data governance and making sure data is consistent and accessible.
    5. Accessibility: Accessibility is making sure services can access each other regardless of the program they are in. “After your services can be found, other services need to be able to connect to them. Within the world of microservices, the preferred methodology for this is to expose your services via HTTP(s) and use standard serialization formats that have excellent support across multiple languages such as JSON,” according to the manifesto.
    6. Responsibility: Lastly, after you build something, you need to be responsible for it — not just how it impacts your team, but how it might impact other teams, services and people, Aucoin explained. “Responsibility also means being responsible for the care and feeding of the services your team owns,” according to the manifesto. “It is your responsibility not only to make services that fulfill the needs of the business; you also need to make sure that the services are fault tolerant, stable, and new releases don’t interrupt consumers.”

“You may notice that these pillars aren’t very technical and do not feature some of the standard terminologies that we associate with microservices such as gateways, circuit breakers, service registration, etc. This is intentional as the most significant hurdles in adopting a microservice architecture for your organization are not technical,” the manifesto states.

Going forward, Aucoin hopes to gain signatures from community and industry leaders. He does expect the core pillars to expand over time and hopes to eventually provide reusable patterns and practices for microservices.

“The world around us is not static, and we don’t know what we don’t know. As we learn new lessons and find out what works and what doesn’t, these pillars can certainly change, grow, develop and create more clarity around them,” he said.