What Is Microservices? Lessons, Pitfalls, and Best Practices

What Is Microservices

Buzzwords often provide a label for evolving concepts, and microservices has become that label for a new architectural approach. While industry discussions focus on companies like Netflix, Amazon, and Google, the author shares personal experiences that offer practical insights for successful microservice adoption.

Three standard business drivers for any architecture are:

Increased agility – the ability to respond quickly to business demands and growth.

Improved customer experience – enhancing satisfaction and reducing churn.

Cost reduction – lowering the expense of adding new products, customers, or solutions.

These goals are also the purpose of Service‑Oriented Architecture (SOA). Large vendors claim their suites enable enterprises to deliver SOA, but without the right people, culture, and investment, SOA cannot deliver business value.

Microservices share the same goals as SOA but improve the approach: they shift from a monolithic implementation to a distributed set of fine‑grained services that support many applications. Success depends on service independence and flexibility.

The author defines microservices as a way to build SOA by creating fine‑grained services that map to functional business domains. No pattern is a silver bullet; enterprises must thoughtfully design and tailor patterns to their needs.

Many SOA projects fail because organizations do not fully analyze their business capability model and mistakenly assume that simply developing web services or buying a vendor suite will automatically deliver SOA benefits.

Example

In a previous job the company aimed to improve agility, customer experience, and reduce cost. They built a multi‑tenant SOA platform that emphasized fine‑grained services for frequent, manageable changes. If the same approach were taken today, it would be called a microservice architecture.

The services were modeled on a business capability model, initially using JMS‑based XML services to expose functionality to web, voice, and agent channels, enabling seamless, small‑scale deployments and A/B testing.

As demand grew, integration complexity made rapid releases difficult. Manual processes caused a ten‑fold increase in change frequency, leading to delivery entropy and missed business expectations.

Lessons – What Not to Do and What to Do Instead

The author shares several lessons learned:

1) Cohesion chaos – Services should align with distinct business capabilities. Adding unrelated logic for a single consumer creates a “big ball of mud” and harms agility, performance, and scalability.

2) Neglecting automation – Lack of automated deployment and runtime monitoring increases operational costs and manual errors. Continuous deployment, automated unit, functional, security, and performance tests are essential; otherwise, avoid microservices.

3) Layered service architecture – Treating services as technical layers (e.g., data‑access, orchestration) leads to tight coupling and delivery complexity. Services should be highly autonomous and organized around business capabilities.

4) Relying on consumer sign‑off – Waiting for channel owners (agent, web, voice) to approve releases creates bottlenecks. Each service must have a comprehensive test suite covering functionality, security, performance, and error handling for all current and future consumers.

5) Manual configuration management – As the number of services grows, manual config handling leads to errors (wrong passwords, URLs, values). Using a centralized configuration management tool integrated with PaaS or CD pipelines is critical.

6) Version avoidance

Assuming a single version per service leads to version proliferation as multiple consumers require different capabilities. Without a version‑control strategy, container counts explode and governance suffers. Adopt forward‑compatible versioning and allow consumers to migrate gracefully.

As the number of microservices grows, complexity rises. A clear versioning policy limits parallel major versions and simplifies management.

7) Building a gateway in each service – Without a centralized API gateway and runtime governance, each service implements its own authentication, rate‑limiting, and routing, increasing complexity and inconsistency. An API gateway can provide unified non‑functional concerns and reduce cross‑service overhead.

Conclusion

The goal of microservices is to address three common problems: improve customer experience, achieve high agility for new requirements, and reduce cost by decomposing business functions into fine‑grained services. It is not a magic solution; it requires a well‑designed platform, high‑quality automation, and cultural change. Learning from the listed anti‑patterns and avoiding them is the first step before tackling containerization and cloud adoption. Successful adoption also depends on executive sponsorship and organizational culture transformation.