The term microservices has gotten a lot of attention lately as IT organizations look for ways to release quality software faster. Traditionally, development teams have built and depended on monolithic architectures for the applications running their businesses, and these monoliths may still work for applications with few dependencies. So why the rush to adopt a microservices architecture? Because microservices are the engine to improve an organization’s software speed, independence, and innovation.
What are microservices?
Microservices refers to an architectural approach that different teams use for single-purpose services. Loosely coupled and bounded contexts are key attributes of this service-oriented architecture. In other words, microservices are independent, smaller pieces of code that are part of a larger system but don’t need to be updated with or know about the services around them.
When developers choose microservices and microservices design patterns to create new apps or break apart older ones, they are helping to get software released faster across teams and through better processes. The microservices approach and set of tools let teams adapt to changing demands and accelerate shipping new features to customers.
The microservices model is the opposite of traditional monolithic software which consists of tightly integrated modules that ship infrequently and have to scale as a single unit. Although the monolithic approach works fine for some teams and some applications, microservices have become popular with companies that need greater agility and scalability.
Microservices characteristics and operations are distinct:
- A collection of small services where each service implements business capabilities
- Runs in its own process and communicates via an HTTP API
- Can be deployed, upgraded, scaled, and restarted independent of other services in the application
- When managed by an automated system, microservices can be frequently updated in live applications without negatively impacting users
Today, IT teams in businesses across industries—from retail to financial services to manufacturing—are using microservices for new applications and to break down monoliths. Yet not all should make the cut because microservices aren’t a simple code rewrite. They require a different mindset, approach, and operational model.
Teams can be more responsive to customer needs. Organizations that adopt a microservices architecture can rapidly ship capabilities when customers need them, and not be stuck with fixed release schedules.
Organizations improve system scalability and reliability. A successful microservices architecture just keeps going. It relies heavily on repeatable automation, supports fine-grained scaling of services, and uses patterns designed to keep the system running even when individual components fail.
Microservices vs. Traditional Architecture
Traditional Architecture (Monolith)
Has a single focus. It does one thing, and does it well! Microservices are targeted at a specific problem domain, and contain everything they need (data included) to own that experience. The “micro” in microservices is about scope, not size.
Has a wide focus. Tightly integrated software packages attempt to solve many business challenges at once, creating many code dependencies.
Is loosely coupled. A microservices architecture demands that services be as self-sufficient as possible, and avoid hard-coded references to other services.
Is tightly coupled. Systems are often a tangled web of interdependent components that cannot be deployed without a carefully crafted sequence of steps.
Is delivered continuously. Microservices are ideal for teams that have apps with constantly changing needs. To deliver value to market as quickly as possible, microservices are delivered to production regularly, through automation.
Relies on scheduled delivery. Applications are developed and updates are made when scheduled. Often, they are performed on a quarterly or annual cadence.
Has independent teams that own the service lifecycle. The microservices transformation is as much about team structure as it is about technology. Microservices are built, shipped, and run by independent teams. Not every service needs this treatment, but it’s a powerful model for business-critical services.
Has many teams that own the service lifecycle. Project teams are responsible for building the first iteration of software, and then pulled apart for the next assignment. Software is handed over to an operations team to maintain.
Has design patterns and technology emphasizing distributed systems at scale. A microservices architecture depends on a set of capabilities for service discovery, messaging, network routing, failure detection, logging, storage, identity, and more. Teams cannot build and run microservices with the same approach and tools that produce monolithic software.
Has design patterns and technology, putting process first. Siloed tools and processes, focused on key development stages, QA, and release to production produce monolithic software.
What to keep in mind if you’re considering microservices architecture
Microservices aren’t a fit for every organization or application. If not correctly implemented, a microservices architecture can result in higher costs. If you’re thinking about getting started, it’s helpful to consider these key questions.
Is your organization ready?
A microservices transition is as much an organizational one, as a technology one. Teams have to be ready to embrace an automation-centric, continuously delivered approach to building software. Is your company ready to eliminate functional silos and have self-sufficient teams that build and operate services? Can your change management process tolerate a deployment pipeline with no human involvement? The way you answer these will let you know how well you are prepared.
Do you have overeager developers?
Not every application warrants the microservices treatment. In the rush to “microservices all things,” developers may commit to significant coding time on existing applications that the business doesn’t believe need to change. Low-use applications or ones that don’t serve business-critical functions may be better off in their monolithic states. Microservices increase agility while adding complexity. Ensure you need the former before signing up for the latter.
Stay current on important topics
Are your services coordinated?
Microservices are loosely coupled to one another, and are constantly changing. How do you find the current URL of a service, or route traffic to an elastic number of service instances? How do services exchange data? In many cases, the technology you have in place today to handle service discovery, load balancing, and messaging are woefully inadequate for the dynamics introduced by microservices. Do you have the dedication and budget to invest in change?
How is your Day 2 management for a complex environment?
As the number of apps and services to manage grows so does the operational risk. Creating hundreds or thousands of microservices across hundreds or thousands of servers will absolutely result in management headaches without a new approach. Is it difficult to patch or upgrade underlying machines? Can you track dependencies and identify applications at risk? How hard will it be to keep dozens of microservices instances up to date with the latest application configuration? The components you use to build a microservices platform, and where those components and services run will have a massive impact on your organizational agility for years to come.
- Is your organization ready to eliminate silos and have self-sufficient teams that build and operate services?
- Can your change management process tolerate a deployment pipeline with no human involvement?
- Do you have over-eager developers that will try to microservice every application?
- Do the key applications you want to transition serve business-critical functions?
- Are your services coordinated?
- Do you have the team dedication and budget to invest in microservices?
- Is it difficult to patch or upgrade underlying machines?
- Can you track dependencies and identify applications at risk?
- Will it be hard to keep dozens of microservices up to date with the latest application configuration?
Guiding principles for qualifying a microservice
Your teams are writing more code than ever. Should some of it be microservices? Here’s how to know what apps and systems are best qualified to move to microservices:
- Multiple rates of change. If parts of your system need to evolve at different speeds or in different directions, separate them into microservices to enable each component to have an independent lifecycle (e.g., in an e-commerce app, split the cart function code from the search or recommendation engine code).
- Independent lifecycles. If a code commit to production flow of a module needs to have a completely independent lifecycle, make it a microservice with its own code repository and CI/CD pipeline.
- Independent scalability. When the load or throughput are unique in parts of the system, it’s likely scaling requirements are, too, which makes the app ideal as independent microservices—scaling at different rates
- Need for isolated failure. When failure of an app isn’t an option, create a microservice with failover options to isolate unreliable dependencies from the rest of the system.
- Need to simplify interactions with eternal dependencies. When you need to focus on protecting systems from external dependencies that change frequently, create a microservice (e.g., a payment processor).
- Freedom of choice. Allow teams to rely on their preferred technology stacks by creating microservices.
3 steps from monoliths to microservices
Teams grappling with legacy portfolios have modernization decisions to make. Many are choosing to break their monoliths into microservices with the ultimate goal of moving to cloud native applications. Available tools coupled with best practices processes and techniques can make the transition easier.
Step 1: Start with monoliths.
We believe monoliths are an appropriate early stage choice, but when too many developers and others start using the same code base, problems start. Developers report the portfolio is complicated, documentation is limited, and resources are too tightly coupled—and that they aren’t learning new skills because they have to maintain legacy apps and infrastructure. That’s when you turn to microservices.
Step 2: Find the seams to discover bounded contexts.
The key to gleaning microservices from a monolith is to find the “seams” of an application—so you know the bounded contexts. Then you have to take the bounded context out of the application. But first, you need to find out who is calling by putting a fence around the bounded context and figuring out who is calling inbound and outbound. What are the dependences? What are the constraints? This will give you an understanding of the coupling and what events are attached to it. Then, you can put an API fence around the bounded context and start pulling out the bounded context into its own application.
Step 3: Scientifically approach refactoring code: The Mikado Method.
For each change, find the dependencies that create errors, fix them, find more, then fix them again. This is a proven depth-first way of tackling refactoring, understanding the outcome at each point. The Mikado Method and other decomposition patterns, including leveraging the anti-corruption layer, strangling the monolith, smart routing, and dark launching, are effective for pulling a monolith apart. Teams also have to migrate ESB composite and provider services to effectively transition to microservices.
How to deploy microservices
- Choose cloud infrastructure or cloud Kubernetes services to enable microservices. Connect them with REST APIs—which are rules, commands, and routines—so many microservices can work together in one application.
- Eliminate dependencies and create independent, loosely coupled code with bounded contexts to run a microservice. Because a microservices-based application is a distributed system that typically runs in more than one place as a process, also choose a communication protocol (e.g., HTTP, AMQP, or TCP).
- Avoid relying on the same data repositories to simplify and decentralize data. This will ensure not every application goes down should one database need to be upgraded or patched.
- Separate how code is governed to optimize for speed. When you use REST APIs, security is built in via SSL.
- Adopt continuous integration/continuous delivery and automate infrastructure deployment to scale without human intervention.
- Continuously monitor and fix code used in and to deploy microservices.
“We used to spend 80% of our time managing the platform. Today, it’s flipped. We spend 80% of the time creating services for customers.”
Neville George, Principal Engineer, Comcast
Watch 10 Lessons We Learned
Achieve your microservices vision with VMware
At VMware, we help you design a high-performing microservices architecture, and then provide a world-class environment to run your microservices.
Team with VMware Tanzu Labs to initially target applications that require feature iterations and extreme scalability, and then learn how to build teams focused on delivery.
Deploy and manage microservices with VMware Tanzu Application Service—our multi-cloud product for rapidly delivering apps, containers, and functions. Quickly build loosely coupled, secure, resilient applications that sit behind a high-performing routing tier and use a robust logging and monitoring subsystem with VMware Tanzu Application Service. Deliver all of this to production continuously using integrated deployment components.
Empower your developers with patterns from Spring Cloud Services that overcome key challenges and operational overheads when building distributed systems with microservices.