Microservices – a New Application Paradigm

PERSPECTIVE

MICROSERVICES – A NEW APPLICATION PARADIGM

Abstract Microservices Architecture is introducing the concept of developing functionality as a number of small self-contained services. This paper intends to clarify the implications of adopting this approach, appropriate usage, and how microservices can change an organization’s approach to integration and delivering functionality through the digital channel. New Integration Model or New Application Paradigm

Microservices is a software architecture is in contrast to the traditional approach can be used to decouple the layers and and delivery paradigm that delivers for software application delivery, which is support the different delivery velocities. functionality by composing a number of to build, integrate, and test applications Microservices is a mechanism to try and small runtime services. Although perceived as a single integrated monolithic push some of this digital agility back into as a new paradigm, the concept can be deployment – even if the application the core functionality, and align well traced back to the early days of the Unix provides a set of service interfaces. The with agile delivery and the DevOps Operating System which was developed as microservices approach facilitates faster operating model. a collection of small, simple, and delivery of smaller incremental changes discrete functions. to an application, at the cost of increased These days the term integration and deployment complexity. With microservices, software functionality Microservices tends to refer is delivered as discrete, lightweight services In recent years, there has been a significant to developing functionality as with a well-defined API, which can then be effort to improve the agility and time-to- a collection of small services, orchestrated to provide a more complete market, for changes to the digital UI layer; each running in its own set of business functionality or simply and at the same time, the underlying core process and accessed via a exposed directly to a mobile or web / functionality has changed at a much slower lightweight interface, such as browser UI. A microservice should be as speed. With Service Oriented Architecture an HTTP RESTful API focused as possible, yet still add value (SOA), supporting technologies like - Fowler instead of just passing information. This API Management and ESB platforms

Microservices – Part of the Digital Economy

The Microservices Architecture is well • Microservices can provide technology Organizations are increasingly looking at aligned to the move towards cloud-based agility and thus improve the business’ microservices as a valuable supplement SaaS offerings and the API economy. In time-to-market to internal application services being some ways, it can also be traced back to delivered through the digital channel. For a service provider, microservices should the early days of SOA with the focus on Instead of extending internal capability, be considered as digital business assets service discovery, and anonymous service external microservices are being and treated accordingly. They need to have usage based on UDDI. What has changed aggregated or enriched, and then a business owner and a business strategy / is the proliferation of RESTful APIs and the provided as value-added microservices to model associated with them. If the focus is popularity of hybrid service integration the outside world. on revenue generation, then services need of cloud SaaS services plus the availability to be promoted and the business needs to Although a Microservices Architecture of virtualised platforms and containers, monitor usage, and simultaneously engage might be initially focused on together with the advanced tools to with the community to ensure the services supplementing internal functionality manage them. are relevant, in demand, and competitive. for users, it also provides opportunities A Microservices Architecture can provide If competitive advantage is the focus, to take an existing service, value-add key technology business opportunities as then the services need to be relevant, or supplement it, and then deliver the a service provider, service consumer, or responsive to change, and have a planned enhanced service out to a different increasingly as both a provider life cycle including obsolescence planning. consumer audience. It can be as and consumer. lightweight as brokering and rebranding As a service consumer you need to be for marketing advantage, or aggregating Microservices support consumer continually checking the market for new • with other services to provide a more enablement, transparency, and choice services, providers, and opportunities functionally rich microservice offering. aligned with your business strategy. • Microservices can extend the utility and reach of your business

Historically, organizations would look to monolithic application suites to solve business problems such as ERP, HCM, Consumer or CRM. Evaluating functionality was Applications based on an overall assessment of a small number of platforms against key business requirements. However, with cloud / SaaS API Management microservice providers, this selection Business Functions Business Functions has become much more complex, but

at the same time, much more flexible. Service rchestration Business Service 4 Organizations are no longer constrained by Business Service 1 Business Service 2 Business Service 3 vendor upgrade schedules, but are instead

able to quickly bring new functionality Entity Service ayer Data Service 4 to the online channel whenever new or Data Service 1 Data Service 2 Data Service 3 enhanced microservices become available. This is particularly valuable for mobile Database Database Database Database and browser digital-applications as they Internal loud are able to quickly make use of new distributed microservices.

So the new approach in assessing functionality is to look for stability around a core set of services for a minimum viable This effectively moves emphasis away a service provider (having the marketing product (MVP) and then be opportunistic from single source providers towards a and management responsibility). The with enhancements as new services best-of-breed service provider approach. approach also needs to take into account become available for use. When working However, the granularity is much smaller, the MVP functionality aspect to ensure with microservice providers who are emphasising the need to leverage those core services are recognized as core effective at engaging the consumer lightweight engagement approaches and are sustainable in the future. These community, there are options to influence rather than heavyweight contractual MVP services will need to have tighter functionality direction, to better support approaches for usage of services outside of governance around change. new business directions. Thus assessment core, long-term dependencies. criteria will now need to consider The other key consideration for selecting additional aspects such as: This lightweight approach drives microservices is data governance. Privacy organizations to replace traditional legislation and other compliance needs Community engagement • application / asset owner models with a can restrict storage of data off-premises or • Alternative service options more lightweight service owner model outside country boundaries. This is another within the business – both as a service key assessment criterion when assessing Supplier longevity and reliability • consumer (owning the relationship) and as microservice providers

Microservice Architecture focuses on building scalable, distributed applications that support agile deployment – both on-premises and to the cloud. The benefits and complexities of Microservices Architecture need to be carefully considered before taking this approach to delivering application services – Gartner - Olliffe

The increased prevalence of cloud-based an organization’s ESB / orchestration services internally; whereas from the SaaS providers in the enterprise-business- platforms. There is also an increased point of view of a microservice provider, functionality mix has broken down the likelihood that these microservices will API Management platforms are crucial monolithic application approach and be hosted and provided through cloud / to managing service access. An API- increased the need to integrate multiple SaaS providers, which drives an enterprise Management-type platform provides services, applications, and providers, to towards a hybrid integration approach the security and service management support the enterprise. A potential impact to better support external service capabilities to support quality delivery of microservices is to dramatically aggregation, and to integrate external of RESTful microservices, and also increase independent service numbers, microservices into the enterprise. This enables valuable social engagement and with the corresponding increase in results in an increased emphasis on hybrid collaboration functionality to support integration complexity. mediation and orchestration platforms as a engaging the consumer community. key enablement capability within These tools and platforms not only As microservices segment functionality an enterprise. support managing the life cycle of into smaller and simpler services – in order services, but more importantly provide to achieve more complex, integrated As an enterprise acting as a service opportunities to more effectively monetize functionality – they can give rise to a consumer, mediation and orchestration the provided microservices. significant increase in the demands on are crucial to effectively integrating

Managing microservices is heavily monitoring capabilities to handle the ensure all the required microservices dependent on having the right tools complexity. This results in: are deployed correctly and platforms in place. There needs to Requirements for effective distributed A need for comprehensive service be effective support for aspects such as • • management tools and dashboards monitoring to ensure availability of container hot deployment, and tools to microservices, to replace what would support flexible runtime deployment and The need to design for resilience to • have previously been vendor-specific automated monitoring. ensure usability when service application monitoring tools. Also, a availability is beyond the control of As noted above, the use of a Microservices single microservice failure will not be as the enterprise Architecture can increase the complexity obvious as an application failure of providing enterprise functionality. This The need to move towards a more • Changes to operational support as drives a heavy dependency on integration agile, continuous change management • L2 / L3 support will need to be more and operational management technologies and delivery mode to effectively fine-grained at the individual to handle the complexity. At the same manage service life cycle changes and service level time, a Microservices Architecture provides replacement of microservices An accelerated transition from an opportunity to simplify digital service A shift towards a more lightweight • • application asset ownership towards delivery, where there is good alignment release process to align with service ownership between the available microservices and incremental service change versus the user functionality provided. major application replacement / It also reinforces agile delivery and testing In general, an enterprise Microservices upgrade. At the same time, major best practices around automation and Architecture approach requires support deployments can be more complex to continuous delivery. from modern-day, advanced tools and

Microservices and their APIs must Service discovery and definition Data Management be managed as business products, from Ensure microservices are well-defined The usual approach is for each conception to retirement • • and documented, in an online microservice to “own” its data (Gartner • Need to align with business strategy repository or catalog with simple - Thomas) – which matches with the consumer access CRUD-style service interface. This Need to provide a revenue stream or • approach goes back to traditional competitive advantage Microservice granularity Object-oriented principles, which • Need to be marketed and managed as • Services granularity should be aligned have been superseded by SOA business assets with the RESTful API model (CRUD) approaches. This has a tendency to Control service access based on • Services should provide a useful drive microservices APIs towards being business requirements, not business service low-level data services based upon technology constraints data schema, but this approach should Data services should not be exposed • be resisted to ensure alignment with Once microservices are in the wild it is directly unless they provide a • delivering business value rather than impossible to control consumers business function alignment with an underlying • Consumers will often identify ways to Life cycle management data schema use a service that is radically different Services specification must be • Data should be explicitly replicated from how it was originally envisioned • designed to support versioning and where needed, using a master data • Focus on supporting industry-standard eventual depredation management paradigm, rather than identity management protocols, rather relying on implicit propagation Hybrid integration than custom mechanisms which may fail due to service Aggregate, enrich, or orchestrate provider changes Design for service unavailability • microservices at the appropriate Look for opportunities to use in- Need to provide resilient behavior over place in the Architecture (business • • memory data grid technology for microservices by designing for functionality). This is not within the low latency and scaling across flexibility and temporary outages mobile or browser app microservices. This aligns well with the Manage SLAs model of a data microservice, with a • Agree to well-defined service SLAs and small defined set of data rather than proactively manage the performance focusing on a large integrated data model

All modern day digital architectures should • For supplementing the functionality microservices APIs, where appropriate, for be service-enabled through HTTP / SOAP of an out-of-the-box application direct consumption by mobile and browser web services, RESTful APIs, JMS queues, or SaaS service to minimize apps; and where more complex behavior etc. Unless an organization runs on a single customization and thus simplify future is required, vendor APIs are aggregated via application platform, this is essential to application upgrades an internal integration platform to provide support effective integration across the more complex microservices In general, there is real value to enterprise and deliver an integrated user for consumption. an organization in having an API- experience. A Microservices Architecture enabled, service-oriented architecture. is a very specific variation of a service- Microservices provide an added advantage ESB-based Microservice Architecture enabled architecture which is more by also supporting service agility, at the The channels division within a major focused on agility. It can provide significant potential cost of increased integration international bank has embarked on value in a number of areas such as: complexity. This can work well for a journey to transform their existing • For a rapidly changing / growing smaller installations but needs careful technology stack to a next generation business or business group where evaluation around the complexity and risk landscape to help deliver a unified digital time-to-market is key and the core implications for larger installations. experience to all of its online customers. business is more dynamic Infosys provided an innovative channel and changing Infosys Experience with services layer architecture based on Fuse ESB, which has built-in support for Apache • Test the market situations where Microservices functionality needs to be rolled out Camel for orchestration, and Apache CXF in a low-cost manner focused on for hosting web services. The solution is validating the demand Digital Alignment leveraging the loose coupling of OSGi Assisting a leading Australian online bundles and the orchestration capabilities Mobile application development or • trading service provider to move from a of Apache Camel framework to build mash-up browser application centralized application platform over a microservices that allow independent development based on RESTful APIs number of SaaS service providers, to a deployment. Fabric, the clustering and not requiring deep integration more loosely coupled architecture. This was mechanism of Fuse, will ensure that these into existing core systems based on directly exposing the underlying services can then be horizontally scaled on demand.

Fowler, J. L. Microservices. Retrieved from Martin Fowler: http://martinfowler.com/articles/microservices.html

Gartner - Olliffe, G. Assessing Microservice Architecture for Scalable Application Delivery. Retrieved from Gartner: https://www.gartner.com/ doc/2974417/assessing-microservice-architecture-scalable-application

Gartner - Thomas, A. Application Architecture for Digital Business. Retrieved from Gartner Webinars: http://my.gartner.com/portal/server.pt? open=512&objID=202&mode=2&PageID=5553&ref=webinar-rss&resId=2866521&srcId=1-3134301641

About the Author

Peter Jarman Principal Technology Architect , Digital and Integration Services, Infosys

Peter Jarman is a Principal Technology Architect for Digital and Integration Services at Infosys. He has over 30 years’ experience in IT, covering a wide range of business domains. He has significant experience across EAI, BPM, SOA, Digital / Online, Enterprise Architecture, and Solution Architecture, and has published a variety of technical papers on these topics.

or more information contact asusinfosyscom

© 2018 Infosys Limited enaluru India ll its esered Infosys eliees te information in tis document is accurate as of its ulication date suc information is suect to cane itout notice Infosys acnoledes te rorietary rits of oter comanies to te trademars roduct names and suc oter intellectual roerty rits mentioned in tis document Excet as exressly ermitted neiter tis documentation nor any art of it may e reroduced stored in a retrieal system or transmitted in any form or y any means electronic mecanical rintin otocoyin recordin or oterise itout te rior ermission of Infosys Limited and or any named intellectual roerty rits olders under tis document

Infosyscom E I tay onnected