Chris Haddad, VP of Technology Evangelism, WSO2
Successful businesses seize opportunity without delay. They rapidly expand into new markets, promptly introduce new products, and quickly fine-tune execution. Every business team requires an agile, flexible, and scalable IT solution that adapts while delivering exceptional customer service. Many CIOs find their traditional, monolithic application development model inhibits their ability to rapidly evolve business scenarios. Forward thinking CIOs enable their team to accelerate solutions delivery, operate at the speed of now, and build solutions that evolve with the business pace.
Trail blazing adopters promote a microservices architectural approach, which exhibits exceptional agility, enables rapid evolution, and reduces development cost. CIO’s are evaluating whether early adopter tactics can be applied to their environment. In short, are microservices a promising approach or costly distraction?
Moving from Service Oriented Architecture (SOA) towards microservices requires teams to include additional architectural patterns, modify team collaboration practices, and incorporate new tooling.
SOA Promise and Reality
Over the last twelve years, CIOs invested considerable time, effort, and money into Service Oriented Architecture (SOA). Teams deployed web service infrastructure, defined service interfaces, and secured interactions. SOA initiatives create a services environment that readily connects core business capabilities with partners and customers.
While an SOA approach extends business reach and builds partner ecosystems, many teams do not realize all promised SOA benefits. For example, SOA initiatives do not reduce internal expense and do not improve agility. Teams find they can build connections faster, but they struggle to reduce maintenance budgets and reallocate money towards innovation. The reason?
Application monoliths and tightly coupled service connections continue to impede agile execution and independent evolution.
While SOA was meant to tear down monolithic silos and simplify software portfolios, organizational inertia often impedes progress. Traditional, top-down SOA methodologies, clash with decentralized organizational structures, immature governance practices, and project-centric funding models. A disconnect between SOA methodology and organizational environment minimizes benefits.
Microservice Principles and Practices Achieve CIO Goals
Many CIOs are rethinking how teams can increase agility and reduce development cost. They realize SOA often hits a payback wall, and they are searching for pragmatic recommendations that accelerate delivery.
Microservices are an emerging architectural approach that extends SOA practices and overcomes traditional SOA deficiencies.
Similar to SOA, a microservices approach decomposes individual, monolithic applications into multiple, discrete services. Teams may weave atomic microservices into a useful business process, integration flow, or user experience.
A microservices approach constrains SOA with additional principles and practices. A microservices approach introduces:
• Context Mapping
• Loosely coupled, high cohesion
• Shared nothing architecture
• Full stack, dynamic deployment
• Parallel development
Context Mapping
Complex and monolithic systems slow IT execution. By breaking monoliths into atomic microservices, teams simplify the problem space, work independently, and accelerate execution.
Ideally, the microservice domain model can ‘fit in your head’ and defines a well-understood business capability.
Context
Loosely Coupled, High Cohesion
Tight coupling creates large, monolithic systems. In a monolithic system, business changes require modifying multiple consumers and executing formidable regression test plans. Additionally, a low cohesion system creates a difficult to understand environment by grouping unrelated functions.
While SOA focuses on loosely coupling service consumers and providers from a technical perspective, a microservices approach focuses on loosely coupling services from a business domain perspective. While SOA does not prescribe service capabilities, a microservices approach guides service interfaces towards atomic business capabilities.
Microservices are autonomous, and exhibit low coupling with other microservices. Inside the microservice, each endpoint, resource, and function exhibits high cohesion, and helps implement a single business capability. When microservices are loosely coupled, teams can evolve and update the microservice without impacting other business capabilities.
Shared nothing architecture
Shared nothing architecture creates the ultimate loosely coupled service environment. Atomic microservices stand-alone, function independently, and don’t contain cross-service dependencies. When microservices do not share data, process, or rules, they can operate in parallel, and a microservice failure will not impact others. By preventing cascading dependencies, teams reduce regression testing before deployment and lower development cost.
Full stack, dynamic deployment
To implement shared nothing architecture, teams must unsure each microservice executes on a full stack. Each microservice encapsulates its own database, process server, application server, and integration server.
A microservices approach prescribes exposing the business capability and user interface via a composable service interface. Your team can rapidly compose new user experiences by weaving together “micro-views” on a web page. For example, in our trading application, three distinct microservices generate an account summary, pending orders, and watch list views displayed on the web page.
Parallel, Non-Blocking Development
Project managers accelerate delivery by fielding teams that operate in parallel and don’t block on each other. The microservices approach recommends empowering independent, autonomous teams, and organically composes systems across domain boundaries. By reducing project dependencies and developing without coordination checkpoints, teams can rapidly evolve their business capability.
Migration Roadmap
Migrating from SOA to microservices requires teams to rethink architecture patterns and principles, reshape team collaboration practices, and reinvent the services platform.
Rethink Architecture Patterns and principles
In addition to SOA patterns, a microservices approach layers bounded context pattern, bulkhead pattern, circuit breaker pattern, and single responsibility principle. The additional patterns and principles help teams deliver autonomous, loosely coupled, resilient, and highly cohesive services.
Reshape Team Collaboration Practices
In software development, the mythical man month continues to rule delivery calendars. Larger teams often mean slower delivery. A microservices approach accelerates delivery by creating small teams centered around easy to understand, atomic business capabilities.
Teams may work independently and focus on collaborating with business capability consumers. Teams must publish an explicit service interface contract, and operate as a service provider.
Reinvent the Platform
While many microservices proponents promote a ‘smart endpoints, dumb pipes’ mantra, a microservices approach creates a more dynamic, complex, and distributed service environment. Teams must re-invent the services platform and introduce infrastructure that can automate microservices deployment, assist with service discovery, monitor service performance, and recover from service failure.
Greenfield microservices platforms are emerging that treat services as first-class citizens, containerize business capabilities, maintain system anti-fragility, and dynamically connect clients.
Refactor the Monolith
A microservices approach can be applied in a Greenfield or legacy application environment. Teams must review business capabilities, define bounded domain contexts, and factor out atomic microservices. Size and scope decisions frequently stall SOA initiatives. Follow microservice patterns and principles, take an iterative approach, and don’t treat ‘micro’ as a literal descriptor. Instead, challenge your team to deliver services with correct cohesion and appropriate coupling.
Think Big, Build Small
CIOs constantly pursue two big goals; synchronize IT agility with business demand, and reduce cost to fuel innovation. To accomplish these big goals, build smaller monoliths. Because dividing a single system into more moving parts creates complexity, follow Albert Einstein’s rule:
Everything should be made as simple as possible, but not simpler.
By following microservices design patterns and principles, teams can right-size their service portfolio, increase agility, and reduce cost.
Read Also
New Hr Capabilities To Face Evolving Technologies
Strengthening The Compliance Fortress In The Banking Sector
Navigating Legal Challenges By Adapting To Technological Shifts
Compliance In The Medtech Industry
How Can The American Trade Finance Companies Manage Present (And Future?) Chinese Mineral Export Control Measures?
Optimizing Customer Experiences Through Data-Driven Strategies
Customer-Oriented And Compliance Mindsets In Claims Management
