Microservices:
Deliver Scalable Software, Faster

Share

What are Microservices?

Microservices refers to an architectural approach that independent teams use to prioritize the continuous delivery of single-purpose services. 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 organizations and some applications, microservices is becoming popular with companies that need greater agility and scalability.

In businesses across industries—from telecommunications and retail to financial services and manufacturing—IT teams are choosing microservices to develop new applications and break down monoliths. A collection of small services where each service implements business capabilities, a microservice runs in its own process and communicates via an HTTP API. Every microservice can be deployed, upgraded, scaled, and restarted independent of other services in the application. When managed by an automated system, teams can frequently update live applications without negatively impacting users.


Microservices Cartoon


Why Microservices Matter

Teams can be more responsive to customer needs

Companies that adopt a microservices architecture can rapidly ship capabilities when customers need them—and not be stuck with fixed release schedules.

There’s greater software team throughput

Microservices build on the principles of Agile and DevOps, and help software teams run in parallel while iterating quickly on discrete capabilities.

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 at Pivotal

At Pivotal, we help you design a high-performing microservices architecture, and then provide a world-class environment to run your microservices.

Work with our Pivotal Labs team 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 Pivotal Cloud Foundry—our cloud-native platform that accelerates your time to value.

Empower your developers with patterns from Spring Cloud Services that overcome key challenges and operational overheads when building distributed systems with microservices



Considering Microservices Architecture?
What to Keep in Mind

Microservices aren’t a fit for every organization or application, and can result in higher costs if not correctly implemented. What to find out before you get started:

Is your organization ready?

A microservices transition is as much an organizational one, as 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?

Do you have over eager 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 don’t have the business imperative to change. Slow-changing applications, or ones that don’t serve mission-critical functions, may be better off in their monolithic state. Microservices increase agility at the cost of additional complexity. Ensure you need the former before signing up for the latter!

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.

How is your Day 2 management for a complex environment?

As the number of items 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 if you don’t take a new approach. How are underlying machines patched or upgraded? Can you track dependencies and identify applications at risk? What about keeping dozens of microservices instances up to date with the latest application configuration? The components you use to build a microservices platform, and where you choose to run these components and services, will have a massive impact on your organizational agility for years to come.



The Big Differences: Microservices Versus Traditional Architecture
Microservices Architecture
Traditional Architecture
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. Solutions attempt to solve many business challenges at once in a tightly integrated software package.
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 quarterly or annual rhythms.
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 life cycle. 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. Teams cannot build and run microservices with the same approach and tools that produced monolithic software. A microservices architecture depends on a set of capabilities for service discovery, messaging, network routing, failure detection, logging, storage, identity, and more.
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.