To keep pace with changing market demands and competitor landscapes, as well as innovations from industry leaders like Amazon, Google, and Netflix, businesses of all sizes need to continuously modernize and (at times) re-invent their services and business models. This requires engineers to gain agility in their design, development and deployment processes in order to ultimately speed innovation throughout their companies. To do this, engineers need a way to create applications that are independently deployable and scalable, and which can be improved or replaced without disrupting the business. Migrating to microservices can assist modernizing the ways companies deliver new services.
Why businesses are moving away from the monolith
Industry leaders (and many startups) recognize the need for continuous and sustainable innovation in their businesses. As a result, they are ending their reliance on monolithic applications, because they slow the pace at which developers can add incremental improvements to applications and underlying platforms in response to market demands, customer needs or breakthrough ideas. With monolithic applications, any change or update to an application requires substantial time and resources to build and deploy what is, essentially, a whole new application. Rapid innovation and product evolution is 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), with each individual service performing or supporting a distinct functional set.
Autonomous services that work together, organized around a business domain.
So microservices are basically SOA?
Yes and no. Many developers who favor SOA (service-oriented architecture) position microservices as the next generation of SOA. They see microservices as a more granular way of implementing SOA. 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 compromises by all participants to various standards of communication and data exchange, and installed an enterprise service bus 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.
An argument can be made that microservices have benefitted from the evolution of DevOps and rapid deployment, and that SOA would have derived similar value from them if they were available 10-15 years ago … but that’s a discussion for a different time.
Java microservices apps delivered via Docker through DevOps techniques actually provide much more agility and scalability than SOA applications.
Benefits of microservices
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’s large number of operations into smaller, discrete parts, developers and admins can change one portion of an app while all the other parts continue to run as normal. This is due to each microservice running its own unique process and managing its own database.
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” – Conway’s Law
In addition, services tend to focus on a specific business domain; teams focused around services are responsible for the full stack (from UI to data) and become, by nature, cross-functional. Teams focused around services (functionalities) are preferred to teams focused around architectural layers.
Scalability
The second benefit surrounds scalability, which we touched on earlier. 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? Services can scale independently, saving unnecessary resource costs.
Different services — different platforms
Third, development teams can deploy separate services on different platforms. For example, a travel website’s app for booking new reservations will have far different database and programming language requirements than their applications for confirming existing reservations or checking flight status. The former has extreme database requirements, while the latter rely on small-footprint apps that can likely be written in JavaScript.
The ability to leverage the right tool for the job empowers the aforementioned service teams to implement what they deem to be the best design for their solution.
Resiliency
The fourth benefit covers resiliency and security. The concept of “designed for failure” (Fowler) is important to understand here; distributed systems are not in and of themselves 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, external dependencies must be taken into consideration when designing services. Your services need to be able to operate whether or not external services are operational. Without this very important design pattern, a cascading failure can (and will) happen.
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.
Security
As with resiliency, a security breach in one separate microservice does not impact the security of other microservices (of course, “well-designed” is a pre-requisite here). Microservices minimize the effect of a distributed denial-of-service attack (DDoS attack) when used with containers by isolating infrastructure takeover from large volumes of server requests. That’s important in cloud computing, because the IT / cloud / SaaS industry represented 58% of DDoS mitigation activity and was the most frequently targeted industry for the tenth consecutive quarter in Q1 2017, according to Verisign’s recent report Q1 2017 DDoS Trends.
Conclusion
As business innovators expand their use of the cloud, they are migrating to a microservices architecture to maintain a competitive advantage. In an effort to remain relevant in these fast-changing markets, it might be time to consider modernizing your architecture to look at the advantages provided by a microservices-based approach.
We help our clients identify and implement architectural improvements and new technologies (such as Docker, Pivotal, microservices, etc.) to modernize their technical platforms. Architectural modernization acts as a third-party sanity check of existing platforms coupled with future technology roadmaps to help our clients efficiently deliver on the right strategy.