To keep pace with changing market demands, as well as innovations from industry leaders like Amazon, Google, and Netflix, businesses need to continuously modernize and re-invent their services and business models. This requires engineers to gain agility in design, development and deployment processes in order to ultimately speed innovation. To accomplish this, engineers must be able to create applications that are independently deployable and scalable, and which can be improved or replaced without disrupting the business. Migrating to a microservices architecture can assist in modernizing the ways companies deliver new services.
Why businesses reject the monolith
Many startups and mid-market businesses recognize the need for continuous and sustainable innovation to fuel growth. As a result, they’re looking to avoid monolithic applications, which can slow the pace of innovation and prevent the rollout of new features in response to market demands, customer needs or breakthrough ideas. With monolithic applications, each change or update requires substantial time and resources to build and deploy what is essentially a whole new application. In this model, rapid innovation and product evolution becomes impossible.
Microservices stand in sharp contrast to monolithic applications. Rather than all operations running inside a single application, a microservice approach breaks things down into multiple discrete processes, or services. Each individual service performs or supports a distinct functional set. The model creates a set of autonomous services that work together, organized around a business domain.
So microservices are basically SOA?
Yes and no. Many developers who favor service-oriented architecture (SOA) position microservices as the next generation of SOA. They see microservices as a more granular way of implementing the same idea. This is with good reason; indeed many of the underlying principles are similar.
However, SOA was driven by an idea of services that interconnect disparate systems. These services demanded that all participants compromise on standards of communication and data exchange, with an enterprise service bus serving as the central nervous system of the whole operation. Implementations became more vendor-focused and groaned under the weight of standards, documentation and XML schemas. Deployments were often monolithic in nature, which meant that not only could SOA not scale easily, it slowed work request changes.
Microservices, on the other hand, leverage standards already in place, and demand a discipline of DevOps that can rapidly and easily independently deploy service changes with minimal or no disruption to the platform. A good example of a DevOps discipline is the use of containers. With containers, developers can use lightweight virtualization to deploy applications without needing to launch a virtual machine for each app. This makes microservices deployment (and runtime) faster than SOA.
With Java microservices apps delivered via Docker through DevOps techniques — there’s potential for much more agility and scalability than with SOA applications.
Benefits of microservices architecture
Focused service design, cross-functional teams
The first benefit of a microservices architecture is focused service design and administration. By breaking down a complex application into smaller, discrete microservices — each with its own processes and database — it’s possible to work on one portion of an app without affecting the other services.
In addition, services tend to focus on a specific business domain, with cross-functional teams responsible for the full stack, from UI to data). Teams focus on services and functionalities, rather than architectural layers.
The second benefit surrounds scalability. Not only are microservices scalable in the cloud, they are independently scalable. Not all services are equally used, so why should they all run the same number of instances? When services are allowed to scale independently, the business saves unnecessary resource costs.
Different services — different platforms
The ability to leverage the right tool for the job empowers the service teams to implement the best design for each service.
The fourth benefit covers resiliency and security. The concept of “designed for failure” (Fowler) is important to understand here. Distributed systems are not intrinsically more resilient than monoliths.
Your services need to be able to recover from unexpected failure and pick up where they left off once restarted. They should not leave the system in an inconsistent state.
In addition, you need to consider external dependencies. Services must be able to operate, regardless of whether external services are operational. Without this very important design pattern, you could see cascading failures occur.
Well-known evidence that this works well at scale comes from Netflix and the introduction of Chaos Monkey. Netflix ensures their own business resilience by purposely taking down production services randomly (Chaos Monkey’s job) and making sure the overall business continues to operate normally.
Assuming that the microservices are well-designed, a security breach in one microservice does not impact the security of others. When used with containers, microservices help protect against distributed denial-of-service (DDoS) attacks by isolating infrastructure takeover from high-volume server requests.
Microservices architecture: your advantage in a fast-changing market
There’s no doubt that microservices architecture enables businesses to launch new services and adapt to changing markets faster. But what will it take to modernize?
A good first step is an architecture assessment – a sanity check of existing platforms, complemented by actionable technology roadmaps. Contact us for a free initial consultation to learn more and see if a microservices approach is right for your business strategy.